PSC を使用したリージョンフェイルオーバー用のアクティブヘルスチェックを構成する

このページの内容は Apigee に適用されます。Apigee ハイブリッドには適用されません。

Apigee Edge のドキュメントはこちらをご覧ください。

このドキュメントでは、Northbound ネットワークルーティング（クライアントから Apigee へのトラフィック）に Private Service Connect（PSC）を使用する場合に、アクティブヘルスチェックを構成するように Apigee を構成する方法について説明します。アクティブヘルスチェックは、リージョン障害が発生した場合のネットワークトラフィックの損失を防ぐうえで役立ちます。

概要

Apigee Northbound ネットワークルーティングに PSC を使用する場合は、このドキュメントの手順に沿ってアクティブヘルスチェックを構成します。現時点では、PSC はアクティブヘルスチェックのモニタリングをサポートしていません。PSC のこの制限を回避するには、アクティブヘルスチェックの機能を提供する MIG（マネージドインスタンスグループ）を使用するように Apigee のインストール構成を変更します。

ヘルスモニタリングには外れ値検出を使用できます。ただし、リージョンの障害では、外れ値検出がリアルタイムのトラフィックを指標として使用するため、定期的に一定量のトラフィックが失われる可能性があります。外れ値検出では、ライブトラフィックの一部を定期的に再ルーティングして、障害が発生したリージョンの健全性を確認します。

図 1 に、推奨のアーキテクチャを示します。サービスエンドポイントが Apigee インスタンスのサービスアタッチメントに接続し、MIG がトラフィックをサービスエンドポイントにプロキシします。MIG でヘルスチェックのモニタリングを有効にします。

図 1. VPC ピアリングを使用しないアクティブヘルスチェックの Apigee アーキテクチャ。

MIG ベースのヘルスチェックアプローチ

前提条件

このドキュメントで説明する手法は、VPC ピアリングを使用する Apigee インストール、または VPC ピアリングを使用しない Apigee インストールに適用できます。ただし、VPC ピアリングインストールの場合、ここで説明するアクティブヘルスチェックの手法は、ルーティング構成に PSC を使用する場合にのみ適用されます。

このセクションの手順に沿って操作する前に、次のことを行います。

VPC 以外のピアリング インストールの場合:
1. サブスクリプションベースまたは従量課金制のインストール用に Apigee のプロビジョニング手順のステップ 1～6 を行います。現在のところ、コマンドラインインターフェースを使用してこれらの手順を実施することが唯一の選択肢です。
2. ステップ 7 のルーティングの構成をスキップして、代わりに次の手順で操作します。
ルーティングに PSC を使用する VPC ピアリング インストールの場合:
1. サブスクリプションベースまたは従量課金制のインストール用に Apigee のプロビジョニング手順のステップ 1～7 を行います。現在のところ、コマンドラインインターフェースを使用してこれらの手順を実施することが唯一の選択肢です。
2. ステップ 8 のルーティングの構成をスキップして、代わりに次の手順で操作します。

1. Apigee サービスアタッチメント用の PSC サービスエンドポイントを構成する

このステップでは、Apigee インスタンスのサービスアタッチメントを指す PSC Service Endpoint を作成します。

前の手順で作成した Apigee インスタンスからサービスアタッチメントを取得します。

curl -i -X GET -H "Authorization: Bearer $AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

次のサンプル出力では、serviceAttachment 値が太字で表示されています。

{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.82.192.2",
      "port": "443",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-7-0-20220228-190814",
      "ipRange": "10.82.192.0/22,10.82.196.0/28",
      "consumerAcceptList": [
        "875609189304"
      ],
      "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
    }
  ]
}

注: Apigee 組織の作成に使用したプロジェクトの ID は常に consumerAcceptList リストに表示されます。上の出力例では、リスト内の唯一のプロジェクトです。

Private Service Connect エンドポイントを作成するの説明に従って、前の手順でインスタンスレスポンスの本文から取得したサービスアタッチメントを指す PSC サービスエンドポイントを作成します。

2. サービスエンドポイントを参照する MIG を構成する

この手順では、トラフィックをサービスエンドポイントにプロキシする MIG を作成します。その後、MIG でアクティブヘルスチェックを有効にできます。

このタスクに必要な権限

Apigee プロビジョナーに、このタスクを完了するために必要な権限を含む事前定義ロールを付与できます。または、権限をきめ細かく指定して必要最小限の権限を付与することもできます。事前定義ロールとアクセスルーティング権限をご覧ください。

2A. VPC ネットワークのサブネットで限定公開の Google アクセスを有効にする

VPC ネットワークのサブネットで限定公開の Google アクセスを有効にするには、限定公開の Google アクセスを有効にするに記載された手順に沿ってください。

2B. 環境変数を設定する

このセクションの手順では、環境変数を使用して、繰り返し使用される文字列を参照します。続行する前に、これらを設定することをおすすめします。

MIG_NAME=YOUR_MIG_NAME  # A name you provide for the MIG
VPC_NAME=default       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=default     # Private Google Access must be enabled for this subnet
REGION=RUNTIME_REGION        # The same region as your Apigee runtime instance
SERVICE_ENDPOINT_IP=YOUR_SERVICE_ENDPOINT_IP.  ## The endpoint IP of the service endpoint you just created

これらの変数は、残りのプロセスで複数回使用します。複数のリージョンを構成する場合は、固有の値を持つ変数を各リージョンに作成します。

2C. マネージドインスタンスグループを作成する

この手順では、マネージドインスタンスグループ（MIG）を作成して構成します。

次のコマンドを実行して、インスタンステンプレートを作成します。

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$SERVICE_ENDPOINT_IP,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

このコマンドからわかるように、マシンのタイプは e2-medium です。Debian 12 を実行し、20 GB のディスク容量があります。startup-script.sh スクリプトは、ロードバランサから Apigee インスタンスにインバウンドトラフィックを転送するように MIG を構成します。

次のコマンドを実行して、マネージドインスタンスグループを作成します。

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

次のコマンドを実行して、グループの自動スケーリングを構成します。
注: e2-medium インスタンスを含むリージョン MIG は最大 6 Gbps をサポートできますスループット要件を満たさない場合は、VM のサイズを大きくするか、レプリカ数を増やすことを検討してください。
```
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 3 \
--target-cpu-utilization 0.75 --cool-down-period 90
```

次のコマンドを実行して、名前付きポートを定義します。

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

3. ヘルスチェックモニタリングを使用してロードバランサを構成する

次の手順では、ヘルスチェックモニタリングを使用してロードバランサを構成します。

3A. ロードバランサの SSL 証明書と鍵を作成する

単一リージョンとマルチリージョンのどちらにインストールする場合でも、認証情報を作成する必要があるのは 1 回だけです。後のステップで、これらの認証情報をロードバランサのターゲット HTTPS プロキシに関連付けます。

認証情報は以下を使用して作成できます。

認証局から取得した証明書
Google マネージド SSL 証明書
自己署名証明書（本番環境ではおすすめしません）

Google Cloud ロードバランサの SSL 証明書の作成と使用の詳細については、SSL 証明書と SSL 証明書の概要をご覧ください。

次の例では、Google マネージド SSL 証明書を作成します。

次の環境変数を作成します。
```
CERTIFICATE_NAME=YOUR_CERT_NAME
DOMAIN_HOSTNAME=YOUR_DOMAIN_HOSTNAME 
```
登録した有効なドメインホスト名に、DOMAIN_HOSTNAME を設定します。後のステップでは、ロードバランサの IP アドレスを取得し、そのアドレスを指すようにドメイン A レコードを更新します。たとえば、ドメインホスト名は foo.example.com のようになります。
gcloud compute ssl-certificates create コマンドを実行します。
```
gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global
```
証明書のプロビジョニングには最長で 1 時間かかることがあります。プロビジョニングのステータスを確認するには、次のコマンドを実行します。
```
gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"
```
注: 環境グループのホスト名に対して、すべて同じロードバランサの IP アドレスを参照する複数の DNS A レコードを作成できます。

3B. ヘルスチェックの作成

ヘルスチェックを作成します。
```
gcloud compute health-checks create https HEALTH_CHECK_NAME \
--project $PROJECT_ID --port 443 --global \
--request-path /healthz/ingress
```
このヘルスチェックを使用して、バックエンドサービスが実行されていることを確認します。特定のプロキシに対してより高度なヘルスチェックを構成する方法については、ヘルスチェックの実施をご覧ください。
注: ヘルスチェックの作成中に、次のエラーが発生することがあります。
```
ERROR: unrecognized arguments: --global,
```
gcloud components update コマンドを使用して gcloud の更新を試みます。
バックエンドサービスを作成します。
```
gcloud compute backend-services create PROXY_BACKEND_NAME \
--project $PROJECT_ID \
--protocol HTTPS \
--health-checks HEALTH_CHECK_NAME \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global
```
注: Apigee のエンドポイントプロパティのリファレンスに記載されているように、Apigee の Ingress（内部ロードバランサ）にはデフォルトのタイムアウト（300 秒）が設定されています。ロードバランサのバックエンドサービスのタイムアウトを 302 秒に設定すると、長時間実行されているトランザクションがある場合に、Apigee 内で backend-services コマンドを完全に実行できます。この値を 60 秒などより小さい値に設定すると、ロードバランサがリクエストの完了前にタイムアウトし、502 レスポンスが返される可能性があります。
次のコマンドを使用して、バックエンドサービスに MIG を追加します。
マルチリージョン: マルチリージョン設定の場合は、MIG ごとに別々の MIG を作成する必要があります。この手順を繰り返して、各 MIG をバックエンドサービスに追加します。各リージョンに対して適切な REGION 変数と MIG_NAME 変数に置き換えてください。
```
gcloud compute backend-services add-backend PROXY_BACKEND_NAME \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global
```

次のコマンドを使用して、ロードバランシング URL マップを作成します。

gcloud compute url-maps create MIG_PROXY_MAP_NAME \
--project $PROJECT_ID --default-service PROXY_BACKEND_NAME

次のコマンドを使用して、ロードバランシングのターゲット HTTPS プロキシを作成します。

gcloud compute target-https-proxies create MIG_HTTPS_PROXY_NAME \
--project $PROJECT_ID --url-map MIG_PROXY_MAP_NAME \
--ssl-certificates $CERTIFICATE_NAME

3C. 予約済みの IP アドレスを取得してファイアウォールルールを作成する

ロードバランサに IP アドレスを割り当ててから、ロードバランサが MIG へのアクセスを許可するルールを作成する必要があります。この手順は、インストールするリージョンが 1 つのリージョンかマルチリージョンかにかかわらず、1 回のみ行う必要があります。

ロードバランサの IP アドレスを予約します。

gcloud compute addresses create ADDRESSES_NAME \
--project $PROJECT_ID \
--ip-version=IPV4 \
--global

次のコマンドを使用して、グローバル転送ルールを作成します。

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
--project $PROJECT_ID --address ADDRESSES_NAME --global \
--target-https-proxy MIG_HTTPS_PROXY_NAME --ports 443

次のコマンドを実行して、予約済みの IP アドレスを取得します。

gcloud compute addresses describe ADDRESSES_NAME \
--project $PROJECT_ID --format="get(address)" --global

重要な手順: DNS レコードが管理されているサイト、DNS ホスト、または ISP に移動し、ドメインの DNS レコードが Google Cloud ロードバランサの IP アドレスに解決されることを確認します。このアドレスは、最後のステップで返された IP 値です。詳細については、ロードバランサの IP アドレスを指すように DNS A および AAAA レコードを更新するをご覧ください。
次のコマンドを使用して、ロードバランサに MIG へのアクセスを許可するファイアウォールルールを作成します。
```
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy
```
IP アドレス範囲 130.211.0.0/22 と 35.191.0.0/16 は、Google Cloud Load Balancing の送信元 IP アドレス範囲です。このファイアウォールルールにより、Google Cloud Load Balancing から MIG へのヘルスチェックリクエストが可能になります。

Apigee のプロビジョニングが完了しました。サンプルプロキシをデプロイするに移動します。

PSC を使用したリージョン フェイルオーバー用のアクティブ ヘルスチェックを構成する

概要

MIG ベースのヘルスチェック アプローチ

前提条件

1. Apigee サービス アタッチメント用の PSC サービス エンドポイントを構成する

2. サービス エンドポイントを参照する MIG を構成する

このタスクに必要な権限

2A. VPC ネットワークのサブネットで限定公開の Google アクセスを有効にする

2B. 環境変数を設定する

2C. マネージド インスタンス グループを作成する

3. ヘルスチェック モニタリングを使用してロードバランサを構成する

3A. ロードバランサの SSL 証明書と鍵を作成する

3B. ヘルスチェックの作成

3C. 予約済みの IP アドレスを取得してファイアウォール ルールを作成する

PSC を使用したリージョンフェイルオーバー用のアクティブヘルスチェックを構成する

MIG ベースのヘルスチェックアプローチ

1. Apigee サービスアタッチメント用の PSC サービスエンドポイントを構成する

2. サービスエンドポイントを参照する MIG を構成する

2C. マネージドインスタンスグループを作成する

3. ヘルスチェックモニタリングを使用してロードバランサを構成する

3C. 予約済みの IP アドレスを取得してファイアウォールルールを作成する