このページでは、リクエストをサーバーレス バックエンドにルーティングする外部アプリケーション ロードバランサを作成する方法を説明します。ここでのサーバーレスという用語は、次のサーバーレス コンピューティング プロダクトを指します。
- App Engine
- Cloud Run 関数
- Cloud Run
外部アプリケーション ロードバランサと API Gateway の統合により、サーバーレス バックエンドは Cloud Load Balancing のすべての機能を活用できるようになります。トラフィックを API Gateway にルーティングするように外部アプリケーション ロードバランサを構成するには、API Gateway の外部アプリケーション ロードバランサ スタートガイドをご覧ください。API Gateway の外部アプリケーション ロードバランサ サポートはプレビュー版です。
サーバーレス NEG を使用すると、外部アプリケーション ロードバランサを適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。
サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。
始める前に
- App Engine、Cloud Run 関数、または Cloud Run のサービスをデプロイする。
- まだ行っていない場合は、Google Cloud CLI をインストールする。
- 権限を構成する。
- SSL 証明書リソースを追加する。
App Engine、Cloud Run 関数、または Cloud Run のサービスをデプロイする
このページで説明する手順では、Cloud Run、Cloud Run 関数、または App Engine のサービスをすでに実行中であることを前提としています。
このページの例では、Cloud Run Python クイックスタートを使用して、Cloud Run サービスを us-central1 リージョンにデプロイしています。このページの残りの部分では、サーバーレス NEG バックエンドを使用してこのサービスにリクエストをルーティングする外部アプリケーション ロードバランサを設定する方法を説明します。
サーバーレス アプリをまだデプロイしていない場合、またはサンプルアプリでサーバーレス NEG を試す場合は、以下のいずれかのクイックスタートを使用してください。サーバーレス アプリはどのリージョンでも作成できますが、後でサーバーレス NEG とロードバランサを作成する際は、サーバーレス アプリと同じリージョンで作成する必要があります。
Cloud Run
シンプルな Hello World アプリケーションを作成してコンテナ イメージにパッケージ化し、パッケージ化したコンテナ イメージを Cloud Run にデプロイする場合は、クイックスタート: ビルドとデプロイをご覧ください。
サンプル コンテナをすでに Container Registry にアップロードしている場合は、クイックスタート: 事前にビルドされたサンプル コンテナをデプロイするをご覧ください。
Cloud Run 関数
Cloud Run 関数: Python クイックスタートをご覧ください。
App Engine
次の Python 3 向け App Engine クイックスタート ガイドをご覧ください。
Google Cloud CLI をインストールする
Google Cloud CLI をインストールします。このツールのコンセプトとインストールについては、gcloud の概要をご覧ください。
gcloud CLI を実行したことがない場合は、gcloud init を実行して gcloud ディレクトリを初期化します。
権限を構成
このガイドに沿って作業を進めるには、プロジェクト内でサーバーレス NEG と外部 HTTP(S) ロードバランサを作成する必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM ロールを持っている必要があります。
| タスク | 必要なロール |
|---|---|
| ロードバランサとネットワーク コンポーネントの作成 | ネットワーク管理者 |
| NEG の作成と変更 | Compute インスタンス管理者 |
| SSL 証明書の作成と変更 | セキュリティ管理者 |
外部 IP アドレスを予約
この段階でサービスは実行中なので、顧客がロードバランサにアクセスするために使用するグローバル静的外部 IP アドレスを設定します。
コンソール
Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。
[静的外部 IP アドレスを予約] をクリックします。
[名前] に「
example-ip」と入力します。[ネットワーク サービス ティア] で [プレミアム] を選択します。
[IP バージョン] で [IPv4] を選択します。
[種類] で [グローバル] を選択します。
[予約] をクリックします。
gcloud
gcloud compute addresses create example-ip \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global
予約された IPv4 アドレスをメモします。
gcloud compute addresses describe example-ip \
--format="get(address)" \
--global
SSL 証明書リソースを作成
HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して SSL 証明書リソースを作成します。
Google マネージド証明書。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。Google マネージド証明書を作成するには、そのドメインをプロビジョニングするためのドメインと DNS レコードが必要です。また、前の手順で作成したロードバランサの IP アドレス（
example-ip）を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。
この例では、SSL 証明書リソースがすでに作成されていることを前提としています。
SSL 証明書リソース（または Google マネージド証明書で必要とされるドメイン）を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。
ロードバランサを作成する
次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run サービスに転送しています。この例では、Cloud Run Python クイックスタートを使用して Cloud Run サービスをデプロイしています。
サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。
Console
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [アプリケーション ロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
- [グローバルまたはシングル リージョンのデプロイ] の場合、[グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
- [ロードバランサの世代] で [従来のアプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- ロードバランサの名前に「
serverless-lb」と入力します。 - ウィンドウを開いたままにして続行します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。
- [名前] に名前を入力します。
-
HTTPS ロードバランサを作成するには、SSL 証明書（
gcloud compute ssl-certificates list）が必要です。前述のように、Google マネージド証明書を使用することをおすすめします。
- [完了] をクリックします。
外部アプリケーション ロードバランサを構成するには、各フィールドを次のように指定します。
以下のオプションが次の値で構成されていることを確認します。
| プロパティ | 値（値を入力するか、指定されたオプションを選択） |
|---|---|
| プロトコル | HTTPS |
| ネットワーク サービス階層 | プレミアム |
| IP バージョン | IPv4 |
| IP アドレス | example-ip |
| ポート | 443 |
| 証明書 | 既存の SSL 証明書を選択するか、新しい証明書を作成します。 HTTPS ロードバランサを作成するには、HTTPS プロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。 Google マネージド証明書を作成するには、ドメインが必要です。ドメインの A レコードは、ロードバランサの IP アドレス（この例では example-ip）に解決される必要があります。Google Cloud マネージド証明書を使用することをおすすめします。これらの証明書は Google Cloud で自動的に取得、管理、更新されます。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。 |
| 省略可: HTTP から HTTPS へのリダイレクトを有効にする |
このチェックボックスを使用して、HTTP から HTTPS へのリダイレクトを有効にします。 このチェックボックスをオンにすると、HTTPS ロードバランサと同じ IP アドレスを使用し、HTTP リクエストをロードバランサの HTTPS フロントエンドにリダイレクトする追加の部分的な HTTP ロードバランサが作成されます。 このチェックボックスは、HTTPS プロトコルが選択されていて、予約済みの IP アドレスが使用されている場合にのみ選択できます。 |
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケット] リストで、[バックエンド サービスを作成] をクリックします。
- [名前] に名前を入力します。
- [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
- [バックエンド] セクションの [新しいバックエンド] で、[サーバーレス ネットワーク エンドポイント グループを作成] を選択します。
- [名前] に名前を入力します。
- [作成] をクリックします。
- [新しいバックエンド] セクションで、[完了] をクリックします。
- [Cloud CDN を有効にする] を選択します。
- 省略可: キャッシュ モードと TTL の設定を変更します。
- [作成] をクリックします。
ルーティング ルール
ルーティング ルールは、トラフィックの転送方法を決定します。ルーティングを構成するには、ホストルールとパスマッチャーを設定します。これは外部アプリケーション ロードバランサの URL マップの構成要素です。
-
[ホストとパスのルール] をクリックします。
- デフォルトのホストとパスを保持します。この例では、すべてのリクエストが前の手順で作成したバックエンド サービスに送信されます。
構成の確認
- [確認と完了] をクリックします。
- すべての設定を確認します。
- 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
- [作成] をクリックします。
- ロードバランサの作成が完了するまで待ちます。
- ロードバランサの名前（serverless-lb）をクリックします。
- ロードバランサの IP アドレスをメモします（次のタスクで使用します）。次のタスクでは
IP_ADDRESSとします。
gcloud
- サーバーレス アプリにサーバーレス NEG を作成します。
その他のオプションについては、
gcloud compute network-endpoint-groups createのgcloudリファレンス ガイドをご覧ください。 - バックエンド サービスを作成します。
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=LOAD_BALANCING_SCHEME \ --global \ --enable-cdn \ --cache-mode=CACHE_MODE \ --custom-response-header='Cache-Status: {cdn_cache_status}' \ --custom-response-header='Cache-ID: {cdn_cache_id}'CACHE_MODE を次のいずれかに置き換えて、キャッシュ モードを設定します。
CACHE_All_STATIC（デフォルト）: 静的コンテンツを自動的にキャッシュに保存します。USE_ORIGIN_HEADERS: コンテンツをキャッシュに保存するには、送信元で有効なキャッシュ ヘッダーを設定する必要があります。FORCE_CACHE_ALL:Cache-Controlレスポンス ヘッダー内のprivate、no-store、またはno-cacheのディレクティブを無視して、すべてのコンテンツをキャッシュに保存します。
Cloud CDN が認識するキャッシュ ディレクティブ、および Cloud CDN によってキャッシュされないコンテンツについては、キャッシュ可能なコンテンツとキャッシュに保存できないコンテンツをご覧ください。
- サーバーレス NEG をバックエンドとしてバックエンド サービスに追加します。
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME \ --network-endpoint-group-region=us-central1 - 受信リクエストをバックエンド サービスに転送するための URL マップを作成します。
gcloud compute url-maps create URL_MAP_NAME \ --default-service BACKEND_SERVICE_NAMEこの URL マップの例では、1 つのサーバーレス アプリを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーを設定する必要はありません。複数のバックエンド サービスを対象とする場合、ホスト名に基づいてリクエストを特定のサービスに転送するにはホストルールを使用します。また、パスマッチャーを設定すると、リクエストパスに基づいてリクエストを特定のサービスに転送できます。
-
HTTPS ロードバランサを作成するには、HTTPS ターゲット プロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。
Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。
Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --domains DOMAINgcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --certificate CRT_FILE_PATH \ --private-key KEY_FILE_PATH -
URL マップにリクエストを転送するターゲット HTTP(S) プロキシを作成します。
HTTPS ロードバランサの場合は、HTTPS ターゲット プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS 負荷分散用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --ssl-certificates=SSL_CERTIFICATE_NAME \ --url-map=URL_MAP_NAME - 受信リクエストをプロキシに転送する転送ルールを作成します。
HTTPS ロードバランサの場合:
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL \ --network-tier=PREMIUM \ --address=example-ip \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --global \ --ports=443
ドメインをロードバランサに接続する
ロードバランサが作成されたら、ロードバランサに関連付けられた IP アドレスをメモします（例: 30.90.80.100）。ドメイン登録サービスを使用して A レコードを作成し、ドメインがロードバランサを参照するようにします。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。たとえば、www.example.com と example.com に A レコードを作成するには、次のようにします。
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。
ロードバランサをテストする
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
作成したロードバランサをクリックします。
ロードバランサの IP アドレスをメモします。
HTTPS ロードバランサの場合は、ウェブブラウザを使用して
https://IP_ADDRESSに移動し、ロードバランサをテストします。IP_ADDRESSは、ロードバランサの IP アドレスに置き換えます。helloworldサービスのホームページが表示されます。
結果に問題があり、Google マネージド証明書を使用している場合は、証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。
テストに自己署名証明書を使用した場合、ブラウザに警告が表示されます。自己署名証明書を受け付けるためには、ブラウザで明示的に設定する必要があります。警告は無視してクリックし、実際のページを表示します。キャッシュ レスポンスを確認するには、ローカルマシンのコマンドラインから curl を使用します。IP_ADDRESS は、ロードバランサの IPv4 アドレスに置き換えます。
curl -v -o/dev/null https://IP_ADDRESS
Google マネージド証明書を使用している場合は、ロードバランサの IP アドレスを指すドメインをテストします。例:
curl -v -o/dev/null -k -s 'https://DOMAIN:443' --connect-to DOMAIN:443:IP_ADDRESS:443
自己署名証明書を使用する場合は、
-kフラグも指定する必要があります。curl の-kオプションを指定すると、自己署名証明書を使用している場合に curl が機能します。 独自のサイトをテストする場合にのみ、-kパラメータを使用してください。通常の状況下では有効な証明書が重要なセキュリティ手段となります。証明書の警告は無視しないでください。出力には、レスポンスがキャッシュから配信されたことを示すために構成したカスタム ヘッダー
Cache-IDとCache-Statusが含まれます。HTTP/2 200 cache-status: hit cache-id: SEA-b9fa975e
出力には、キャッシュ ヒットがあったことを示すレスポンス ヘッダーが含まれます。つまり、サーバーレス アプリ内の静的アセットは、Cloud CDN エッジ キャッシュからユーザーに配信されたものです。
cache-statusヘッダーは、Cloud CDN にキャッシュされていないレスポンスのdisabled値を示しています。キャッシュに保存されたレスポンスの場合、cache-statusヘッダー値はhit、miss、またはrevalidatedになります。
Cloud CDN を無効にする
Console
単一のバックエンド サービスに対して Cloud CDN を無効にする
Google Cloud コンソールで、[Cloud CDN] ページに移動します。
送信元の行の右側で [メニュー ] をクリックし、[編集] を選択します。
Cloud CDN の使用を停止するバックエンド サービスのチェックボックスをオフにします。
[更新] をクリックします。
送信元のすべてのバックエンド サービスに対して Cloud CDN を削除する
Google Cloud コンソールで、[Cloud CDN] ページに移動します。
送信元の行の右側で [メニュー ] をクリックし、[削除] を選択します。
確認のため、もう一度 [削除] をクリックします。
gcloud
gcloud compute backend-services update BACKEND_SERVICE_NAME
--no-enable-cdn
Cloud CDN を無効にしても、キャッシュの無効化や消去は行われません。Cloud CDN を無効にして再度有効にすると、キャッシュに保存されたコンテンツの大半はキャッシュに残っています。キャッシュのコンテンツを使用しないようにするには、コンテンツの無効化が必要です。