このページでは、リクエストをサーバーレス バックエンドに転送する外部 HTTP(S) ロードバランサの作成方法を説明します。ここでのサーバーレスという用語は、次のサーバーレス コンピューティング プロダクトを指します。
- App Engine
- Cloud Functions
- Cloud Run
HTTP(S) ロード バランシングと API Gateway の統合により、サーバーレス バックエンドで Cloud Load Balancing のすべての機能を利用できるようになります。詳細については、API Gateway の HTTP(S) ロード バランシングをご覧ください。API Gateway にトラフィックを転送するように HTTP(S) ロード バランシングを構成するには、API Gateway の HTTP(S) ロード バランシング スタートガイドをご覧ください。この機能はプレビュー版です。
サーバーレス NEG を使用すると、外部 HTTP(S) ロード バランシングを適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。
サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。
始める前に
- App Engine、Cloud Functions、または Cloud Run のサービスをデプロイする。
- まだ行っていない場合は、Google Cloud CLI をインストールします。
- 権限を構成する。
- 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 CLI をインストールする
Google Cloud CLI をインストールします。このツールのコンセプトとインストールについては、gcloud の概要をご覧ください。
gcloud CLI を実行したことがない場合は、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 \
--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 レコードが必要です。ドメインがない場合は、Google Domains から取得できます。詳しくは、Google Domains スタートガイドをご覧ください。また、前の手順で作成したロードバランサの IP アドレス（
example-ip）を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。
この例では、SSL 証明書リソースがすでに作成されていることを前提としています。
SSL 証明書リソース（または Google マネージド証明書で必要とされるドメイン）を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。
ロードバランサを作成する
次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run サービスに転送しています。この例では、Cloud Run Python クイックスタートを使用して Cloud Run サービスをデプロイしています。
サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。
Console
構成を開始する
- Google Cloud Console で、[ロード バランシング] ページに移動します。
- [HTTP(S) ロード バランシング] で [構成を開始] をクリックします。
- [インターネット接続または内部専用] で [インターネットから自分の VM へ] を選択します。
- [グローバル / リージョン] で、[グローバル HTTP(S) ロードバランサ（従来型）] を選択します。
- [次へ] をクリックします。
- ロードバランサの [名前] に「
serverless-lb」と入力します。 - ウィンドウを開いたままにして続行します。
バックエンド サービスの構成
- [バックエンドの構成] をクリックします。
- [バックエンド サービスを作成または選択] プルダウン メニューで、マウスポインタを [バックエンド サービス] に合わせ、[バックエンド サービスを作成] を選択します。
- 名前を入力します。
- [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
- [バックエンド] の [新しいバックエンド] ウィンドウで、[サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
- 名前を入力します。
- [作成] をクリックします。
- [新しいバックエンド] ウィンドウで、[完了] をクリックします。
- [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 証明書を使用してテストできます。 |
| （省略可）HTTP から HTTPS へのリダイレクトを有効にする | このチェックボックスを使用して、ポート 80 からポート 443 へのリダイレクトを有効にします。 このチェックボックスをオンにすると、HTTPS ロードバランサと同じ IP アドレスを使用し、HTTP リクエストをロードバランサの HTTPS フロントエンドにリダイレクトする追加の部分的な HTTP ロードバランサが作成されます。 このチェックボックスは、HTTPS プロトコルが選択されていて、予約済みの IP アドレスが使用されている場合にのみ選択できます。 |
構成の確認
- [確認と完了] をクリックします。
- バックエンド バケット、ホストとパスのルール、フロントエンドを確認します。
- [作成] をクリックします。
- ロードバランサの作成が完了するまで待ちます。
- ロードバランサの名前（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 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 \ --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
Google Domains を使用している場合は、Google Domains のヘルプページで詳細をご確認ください。
ロードバランサをテストする
ロードバランサを構成したので、ロードバランサの 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 を無効にして再度有効にすると、キャッシュに保存されたコンテンツの大半はキャッシュに残っています。キャッシュのコンテンツを使用しないようにするには、コンテンツの無効化が必要です。