サーバーレス NEG を使用すると、外部 HTTP(S) 負荷分散を適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。
サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。
始める前に
- App Engine、Cloud Functions、または Cloud Run（フルマネージド）サービスをデプロイする。
- Google Cloud SDK をインストールする（まだインストールしていない場合）。
- 権限を構成する。
- SSL 証明書リソースを追加する。
App Engine、Cloud Functions、または Cloud Run（フルマネージド）サービスをデプロイする
このページで説明する手順では、Cloud Run（フルマネージド）、Cloud Functions、または App Engine サービスがすでに実行中であることを前提としています。
このページの例では、Cloud Run（フルマネージド）Python クイックスタートを使用して、Cloud Run（フルマネージド）サービスを us-central1 リージョンにデプロイします。このページの残りの部分では、サーバーレス NEG バックエンドを使用してこのサービスにリクエストをルーティングする外部 HTTP(S) ロードバランサを設定する方法を説明します。
サーバーレス アプリをまだデプロイしていない場合、またはサンプルアプリでサーバーレス NEG を試す場合は、以下のいずれかのクイックスタートを使用してください。サーバーレス アプリはどのリージョンでも作成できますが、後でサーバーレス NEG とロードバランサを作成する際は、サーバーレス アプリと同じリージョンで作成する必要があります。
Cloud Run（フルマネージド）
シンプルな Hello World アプリケーションを作成してコンテナ イメージにパッケージ化し、そのコンテナ イメージを Cloud Run（フルマネージド）にデプロイする場合は、クイックスタート: ビルドとデプロイをご覧ください。
サンプル コンテナをすでに Container Registry にアップロードしている場合は、クイックスタート: 事前にビルドされたサンプル コンテナをデプロイするをご覧ください。
Cloud Functions
Cloud Functions: Python クイックスタートをご覧ください。
App Engine
次の Python 3 向け App Engine クイックスタート ガイドをご覧ください。
Google Cloud SDK をインストールする
gcloud コマンドライン ツールをインストールします。このツールのコンセプトとインストールについては、gcloud の概要をご覧ください。
これまで gcloud コマンドライン ツールを実行したことがない場合は、gcloud init を実行して gcloud ディレクトリを初期化します。
権限を構成する
このガイドに沿って作業を進めるには、プロジェクト内でサーバーレス NEG と外部 HTTP(S) ロードバランサを作成する必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM ロールを持っている必要があります。
| タスク | 必要なロール |
|---|---|
| ロードバランサとネットワーク コンポーネントの作成 | ネットワーク管理者 |
| NEG の作成と変更 | Compute インスタンス管理者 |
| SSL 証明書の作成と変更 | セキュリティ管理者 |
外部 IP アドレスの予約
この段階でサービスは実行中なので、顧客がロードバランサにアクセスするために使用するグローバル静的外部 IP アドレスを設定します。
Console
- Google Cloud Console で外部 IP アドレスのページに移動します。
[外部 IP アドレス] ページに移動 - [静的アドレスを予約] をクリックして、IPv4 アドレスを予約します。
example-ipの [名前] を割り当てます。- ネットワーク階層を [プレミアム] に設定します。
- [IP バージョン] を IPv4 に設定します。
- [タイプ] で [グローバル] をオンにします。
- [予約] をクリックします。
gcloud
gcloud compute addresses create example-ip \
--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 レコードが必要です。ドメインがない場合は、Google Domains から取得できます。また、前の手順で作成したロードバランサの IP アドレス（
example-ip）を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。
この例では、SSL 証明書リソースがすでに作成されていることを前提としています。
SSL 証明書リソース（または Google マネージド証明書で必要とされるドメイン）を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。
外部 HTTP(S) ロードバランサの作成
次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run（フルマネージド）サービスに転送します。この例では、Cloud Run（フルマネージド）Python クイックスタートを使用して Cloud Run（フルマネージド）サービスをデプロイします。
サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。
Console
ロードバランサに名前を付ける
- Google Cloud Console で [負荷分散] ページに移動します。
[負荷分散] ページに移動 - [HTTP(S) 負荷分散] で [構成を開始] をクリックします。
- [インターネット接続または内部専用] で [インターネットから自分の VM へ] を選択します。
- [続行] をクリックします。
- ロードバランサの [名前] に「
serverless-lb」と入力します。 - ウィンドウを開いたままにして続行します。
バックエンド サービスの構成
- [バックエンドの構成] をクリックします。
- [バックエンド サービスを作成または選択] プルダウン メニューで、マウスポインタを [バックエンド サービス] に合わせ、[バックエンド サービスを作成] を選択します。
- [名前] を入力します。
- [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
- [バックエンド] の [新しいバックエンド] ウィンドウで、[サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
- [名前] を入力します。
- [リージョン] で、us-central1 を選択します。[Cloud Run] を選択します。
- [サービス名を選択] を選択します。
- [サービス] プルダウンで、ロードバランサを作成する Cloud Run（フルマネージド）サービスを選択します。
- [作成] をクリックします。
- [新しいバックエンド] ウィンドウで、[完了] をクリックします。
- [Cloud CDN を有効にする] を選択します。デフォルトのキャッシュ モードと TTL の設定を維持します。
- [作成] をクリックします。
ホストルールとパスマッチャーを構成する
ホストルールとパスマッチャーは、外部 HTTP(S) ロードバランサの URL マップの構成要素です。
- [ホストとパスのルール] をクリックします。
- デフォルトのホストとパスを保持します。この例では、すべてのリクエストが前の手順で作成したバックエンド サービスに送信されます。
フロントエンドを構成する
- [フロントエンドの構成] をクリックします。
- [名前] を入力します。
HTTPS ロードバランサを作成するには、SSL 証明書（
gcloud compute ssl-certificates list）が必要です。前に説明したように、Google マネージド証明書を使用することをおすすめします。外部 HTTP(S) ロードバランサを構成するには、次のフィールドに値を入力します。以下のオプションが次の値で構成されていることを確認します。
プロパティ 値（値を入力するか、指定されたオプションを選択） プロトコル 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 証明書を使用してテストできます。[完了] をクリックします。
構成の確認
- [確認と完了] をクリックします。
- バックエンド バケット、ホストとパスのルール、フロントエンドを確認します。
- [作成] をクリックします。
- ロードバランサの作成が完了するまで待ちます。
- ロードバランサの名前（serverless-lb）をクリックします。
- ロードバランサの IP アドレスをメモします（次のタスクで使用します）。次のタスクでは
IP_ADDRESSとします。
gcloud
- サーバーレス アプリにサーバーレス NEG を作成します。Cloud Run（フルマネージド）サービスを使用してサーバーレス NEG を作成するには、次のコマンドを実行します。
gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-run-service=CLOUD_RUN_SERVICE_NAMEその他のオプションについては、gcloud compute network-endpoint-groups createのgcloudリファレンス ガイドをご覧ください。 - バックエンド サービスを作成します。
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --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（デフォルト）: 静的コンテンツを自動的にキャッシュに保存します。キャッシュ不可としてマークされている（Cache-Controlレスポンス ヘッダー内のprivate、no-store、またはno-cacheのディレクティブ）レスポンスは、キャッシュに保存されません。動的コンテンツをキャッシュに保存するには、コンテンツに有効なキャッシュ ヘッダーが含まれている必要があります。これは、すべての新しい Cloud CDN 対応バックエンドのデフォルトの動作です。USE_ORIGIN_HEADERS: コンテンツをキャッシュに保存するには、送信元で有効なキャッシュ ヘッダーを設定する必要があります。これらのヘッダーがないレスポンスは Google のエッジでキャッシュに保存されません。リクエストごとに送信元を完全に通過する必要があるため、パフォーマンスに影響が及び、送信元サーバーの負荷が増加する可能性があります。これは、既存のすべての Cloud CDN 対応バックエンドのデフォルトの動作です。FORCE_CACHE_ALL:Cache-Controlレスポンス ヘッダー内のprivate、no-store、またはno-cacheのディレクティブを無視して、すべてのコンテンツをキャッシュに保存します。この結果、ユーザー単位の（ユーザーを特定可能な）限定公開コンテンツがキャッシュに保存される場合があります。これを有効にするのは、限定公開コンテンツまたは動的コンテンツを配信していないバックエンド（Cloud Storage バケットなど）に限定する必要があります。
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 DOMAINセルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
gcloud 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 \ --address=example-ip \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --global \ --ports=443
ロードバランサの IP アドレスを使用するようにドメインの DNS レコードを更新する
まだ行っていない場合は、ロードバランサの IP アドレスを参照するようにドメインの DNS A または AAAA レコードを更新します。これにより、既存のカスタム ドメイン URL に送信されたトラフィックがロードバランサ経由でルーティングされるようになります。
たとえば、example.com のカスタム ドメインがあり、すべてのサービスがこのドメインにマッピングされている場合は、ロードバランサの IP アドレスを参照するように example.com の DNS A または AAAA レコードを更新する必要があります。
DNS レコードを更新する前に、カスタム ドメインのローカル DNS での解決をロードバランサの IP アドレスにすることで、ローカルで構成をテストできます。ローカルでテストするには、example.com がロードバランサの IP アドレスを指すように、ローカルマシン上の /etc/hosts/ ファイルを変更するか、curl --resolve フラグを使用して、curl がリクエストにロードバランサの IP アドレスを使用するように強制します。
example.com の DNS レコードが HTTPS ロードバランサの IP アドレスに解決されると、example.com に送信されたリクエストがロードバランサ経由でルーティングされるようになります。ロードバランサは、その URL マップに従ってリクエストを該当するバックエンド サービスにディスパッチします。さらに、URL マスクを使用してバックエンド サービスが構成されている場合、サーバーレス NEG はそのマスクを使用してリクエストを適切な Cloud Run（フルマネージド）、Cloud Functions、または App Engine サービスにルーティングします。
Google マネージド証明書を使用する場合、既存のサービスを外部 HTTP(S) ロードバランサに移行すると、ダウンタイム（通常は 1 時間以内）が発生する可能性があります。これは、ロードバランサの IP アドレスを指すように DNS レコードを更新するまで、外部 HTTP(S) ロードバランサの SSL 証明書がプロビジョニングされないためです。
ロードバランサをテストする
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。
- Google Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - 作成したロードバランサをクリックします。
- ロードバランサの 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 Console で、[Cloud CDN] ページに移動します。
- 送信元の行の右側で [メニュー] をクリックし、[編集] を選択します。
- Cloud CDN の使用を停止するバックエンド サービスのチェックボックスをオフにします。
- [更新] をクリックします。
送信元のすべてのバックエンド サービスに対して Cloud CDN を削除する
- Cloud Console で、[Cloud CDN] ページに移動します。
- 送信元の行の右側で [メニュー] をクリックし、[削除] を選択します。
- 確認のため、もう一度 [削除] をクリックします。
gcloud
gcloud compute backend-services update BACKEND_SERVICE_NAME \
--no-enable-cdn
Cloud CDN を無効にしても、キャッシュの無効化や消去は行われません。Cloud CDN を無効にして再度有効にすると、キャッシュに保存されたコンテンツの大半はキャッシュに残っています。キャッシュのコンテンツを使用しないようにするには、コンテンツの無効化が必要です。