API Gateway のロード バランシング スタートガイド

このチュートリアルでは、リクエストを API Gateway にルーティングするグローバル外部アプリケーション ロードバランサを作成する方法について説明します。この構成プロセスでは、グローバル外部アプリケーション ロードバランサと他のサーバーレス プロダクト（Cloud Run、Cloud Functions、App Engine など）との統合を構成する場合と同じ手順に従います。

API Gateway が機能するためにロードバランサは必要ありませんが、ロードバランサを使用するとゲートウェイでロードバランサの利点を活用できます。たとえば、API Gateway でグローバル外部アプリケーション ロードバランサを使用すると、次のことが可能になります。

  • カスタム ドメインを使用する。
  • ネットワーク セキュリティ サービスとして Google Cloud Armor を活用する。
  • 複数のロケーションにあるゲートウェイ間の効率的なロード バランシングを管理する。
  • 高度なトラフィック管理を実装する。

準備

  1. まだ行っていない場合は、Google Cloud CLI をダウンロードしてインストールします。

    gcloud CLI をダウンロードする

  2. gcloud コンポーネントを更新します。

    gcloud components update

  3. API Gateway のクイックスタートに沿って Cloud Run サービスをデプロイし、そのサービスを指すゲートウェイを作成します。

  4. 権限を構成する。

  5. SSL 証明書リソースを追加する。

Cloud Run サービスと API Gateway インスタンスをデプロイする

このチュートリアルでは、「hello-world」サービスを Cloud Run にデプロイし、Cloud Run サービスに転送するゲートウェイを作成して、リクエストをカスタム ドメインに転送するようにグローバル外部アプリケーション ロードバランサを構成します。

このチュートリアルでは API Gateway のバックエンド サービスとして Cloud Run を使用しますが、この手順は API Gateway がサポートするすべてのバックエンド サービスにも適用されます。

API Gateway のクイックスタートが正常に完了すると、Cloud Run サービスを指すデプロイされたゲートウェイ URL が作成されます。

権限を構成する

このチュートリアルでは、Cloud プロジェクトにサーバーレス ネットワーク エンドポイント グループ（NEG）を作成し、グローバル外部アプリケーション ロードバランサを作成します。そのためには、プロジェクトのオーナーまたは編集者のロール、または次の Compute Engine IAM ロールが必要です。

タスク 必要なロール
ロードバランサとネットワーク コンポーネントの作成 ネットワーク管理者
NEG の作成と変更 Compute インスタンス管理者
SSL 証明書の作成と変更 セキュリティ管理者

SSL 証明書リソースを作成する

グローバル外部アプリケーション ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して SSL 証明書リソースを作成します。

  • Google マネージド証明書。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。Google マネージド証明書を作成するには、そのドメインをプロビジョニングするためのドメインと DNS レコードが必要です。ドメインがない場合は、Google Domains から取得できます。また、後のステップで作成したロードバランサの IP アドレスを指すように、ドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書の使用をご覧ください。

  • 自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。

このチュートリアルでは、SSL 証明書リソースがすでに作成されていることを前提としています。

SSL 証明書リソース（または Google マネージド証明書で必要とされるドメイン）を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。

グローバル外部アプリケーション ロードバランサを作成する

  1. API Gateway に対するサーバーレス NEG を使用する

    ネットワーク エンドポイント グループ（NEG）は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、次の図に示すように、API Gateway などのサービスを指すバックエンドです。

    マルチリージョン ゲートウェイのバックエンドとしてのサーバーレス NEG を示す図

    ゲートウェイ用のサーバーレス NEG を作成するには、次のコマンドを実行します。ここで、

    • SERVERLESS_NEG_NAME は、作成するサーバーレス NEG の名前です。
    • GATEWAY_ID はゲートウェイの名前を指定します。
    • REGION_ID は、サーバーレス NEG のデプロイ リージョンです（これはゲートウェイ リージョンと一致する必要があります）。
    gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID

    次に例を示します。

    gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway

  2. バックエンド サービスを作成して、グローバル外部アプリケーション ロードバランサがトラフィックを分散する方法を定義します。

    バックエンド サービスの構成には、次の図に示すように、バックエンドへの接続に使用されるプロトコル、さまざまな配信とセッションの設定、ヘルスチェック、タイムアウトなど一連の値が含まれます。

    バックエンド サービスのバックエンドとしてのサーバーレス NEG を示す図

    次のコマンドを実行してバックエンド サービスを作成します。

    gcloud compute backend-services create BACKEND_SERVICE_NAME --global

    ここで、BACKEND_SERVICE_NAME は新しいバックエンド サービスの名前です。

    次に例を示します。

    gcloud compute backend-services create api-gateway-backend-service --global

    サーバーレス NEG をバックエンドとしてバックエンド サービスに追加するには、次のコマンドを実行します。ここで、

    • BACKEND_SERVICE_NAME はバックエンド サービスの名前です。
    • SERVERLESS_NEG_NAME は、前のステップで作成したサーバーレス NEG の名前です。
    • REGION_ID は、サーバーレス NEG のデプロイ リージョンです（これはゲートウェイ リージョンと一致する必要があります）。
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID

    次に例を示します。

    gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg \
  --network-endpoint-group-region=us-central1

  3. 次の図に示すように、受信リクエストをバックエンド サービスにルーティングするための URL マップを作成します。

    URL マップからバックエンド サービスへのルーティングを示す図

    URL マップを作成するには、次のコマンドを実行します。ここで、

    • URL_MAP_NAME は、作成する URL マップの名前です。
    • BACKEND_SERVICE_NAME はバックエンド サービスの名前です。
    gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME

    次に例を示します。

    gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service

    この URL マップの例では、1 つのゲートウェイを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーは必要ありません。複数のバックエンド サービスを対象とする場合、ホストルールを使用すると、ホスト名に基づいてリクエストを特定のサービスに転送できます。パスマッチャーを使用すると、リクエストパスに基づいてリクエストを特定のサービスに転送します。

    次に例を示します。

    gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2  \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
     
    gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher

    ホストルールとパスマッチャーの詳細については、URL マップのドキュメントをご覧ください。

  4. 次の図に示すように、ターゲット プロキシ用の SSL 証明書を作成します。

    ターゲット プロキシの SSL 証明書を示す図

    グローバル外部アプリケーション ロードバランサを作成するには、HTTP(S) ターゲット プロキシに SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。そのため、Google マネージド証明書を使用することをおすすめします。SSL 証明書リソースを使用せずにこのプロセスをテストし、HTTP ロードバランサを設定する場合は、このステップをスキップできます。

    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

  5. 次の図に示すように、リクエストを URL マップに転送するターゲット HTTP(S) プロキシを作成します。

    HTTP プロキシから URL マップへの転送を示す図

    ターゲット プロキシを作成するには、次のコマンドを使用します。ここで、

    • TARGET_HTTPS_PROXY_NAME は、作成するターゲット HTTP(S) プロキシの名前です。
    • URL_MAP_NAME は、前のステップで作成した URL マップの名前です。
    • 省略可: SSL_CERT_NAME は、作成された SSL 証明書の名前です。
    gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME \
  --url-map=URL_MAP_NAME

    次に例を示します。

    gcloud compute target-https-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert \
  --url-map=api-gateway-url-map

    前述のように、SSL 証明書リソースを作成せずに HTTP ロードバランサを作成できます。これを行うには、次のコマンドを使用します。

    gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME

    次に例を示します。

    gcloud compute target-http-proxies create api-gateway-http-proxy \
  --url-map=api-gateway-url-map

    HTTP プロキシの後続のコマンドを --target-http-proxy フラグと HTTP(S) の対応するフラグ TARGET_HTTP_PROXY_NAME に対応するように変更する必要があります。

  6. 次の図のように、受信リクエストをプロキシに転送する転送ルールを作成します。

    HTTP プロキシへの転送ルールの図

    転送ルールを作成するには、次のコマンドを使用します。ここで、

    • HTTPS_FORWARDING_RULE_NAME は、作成するルールの名前です。
    • TARGET_HTTPS_PROXY_NAME は、HTTP(S) ターゲット プロキシの名前です。
    gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443

    次に例を示します。

    gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443

ロードバランサの IP アドレスで DNS レコードを更新する

カスタム ドメインがある場合は、このステップで、サービスの新しい IP アドレスを指すようにドメインの DNS 設定を行う必要があります。また、Google マネージド証明書を使用してグローバル外部アプリケーション ロードバランサを作成している場合も必要です（ドメインが必要になります）。DNS で使用する場合は、静的 IP アドレスの割り振りと使用をおすすめします。このステップの具体的な手順は、DNS プロバイダによって異なります。

  1. ロードバランサにトラフィックを送信するには、ドメインの DNS レコード（このチュートリアルでは my-app-domain）がロードバランサの IP アドレスを指している必要があります。

    グローバル転送ルールの IP アドレスを確認するには、次のコマンドを使用します。

    gcloud compute forwarding-rules list

  2. ロードバランサの IP アドレスを参照するようにドメインの DNS A または AAAA レコードを更新します。これにより、既存のカスタム ドメイン URL に送信されたトラフィックがロードバランサ経由でルーティングされるようになります。DNS によってこの変更が DNS サーバーに伝播されるまでに、短い場合で数秒、長い場合で数時間を要する可能性があります。

  3. curl を使用して、またはブラウザで URL にアクセスし、ゲートウェイがトラフィックを受信していることを確認します。 例: https://my-app-domain

    テストでは、Cloud Run サービスによって生成されたレスポンスが表示されます。たとえば、「Hello World」HTML ページ、またはバックエンド サービスで直接生成された別の想定されるレスポンスが該当します。 これは、リクエストがロードバランサを通過し、バックエンド サービスがロードバランサにゲートウェイに送信するよう指示していることを表します。

ロードバランサの構成をテストする

ロードバランサを構成したので、転送ルールの IP アドレスにトラフィックを送信できるようになりました。

グローバル転送ルールの IP アドレスを確認するには、次のコマンドを使用します。

gcloud compute forwarding-rules list

curl コマンドを使用して、サービスのさまざまな URL に対するレスポンスをテストします。次に例を示します。

curl https://HOST_URL/hello/
 
curl https://HOST_URL

API Gateway Cloud コンソールを使用して、リクエストが正しいサービスに到達していることを確認できます。

開店おめでとうございます。API Gatewayプレビュー のグローバル外部アプリケーション ロードバランサが正常に構成されました。

クリーンアップ

このクイックスタートで使用したリソースの Google Cloud アカウントが変更されないようにするには、作成した Cloud Load Balancing リソースを削除します。これらのリソースが独自のプロジェクト内で作成されている場合は、プロジェクト全体を削除することもできます。それ以外の場合は、リソースを個別に削除してください。

プロジェクトの削除

次のコマンドを実行します。PROJECT_ID は、プロジェクト ID に置き換えてください。

gcloud projects delete PROJECT_ID

リソースを個別に削除する

ロードバランサ内の各コンポーネントを削除します。

  1. 特定した転送ルールを削除します。

    gcloud compute forwarding-rules delete HTTPS_FORWARDING_RULE_NAME --global

  2. グローバル外部 IP アドレスを削除します。

    gcloud compute addresses delete IP_ADDRESSES --global

  3. ターゲット プロキシを削除します。

    gcloud compute target-https-proxies delete TARGET_HTTP_PROXY_NAME

  4. URL マップを削除します。

    gcloud compute url-maps delete URL_MAP_NAME

  5. バックエンド サービスを削除します。

    gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

  6. （省略可）SSL 証明書を削除します。

    gcloud compute ssl-certificates delete SSL_CERTIFICATE_NAME

サーバーレス NEG を削除します。

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME --region=REGION