複数のリージョンへの Apigee の拡張

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

Apigee Edge のドキュメントを表示する。

Apigee の組織は、複数のリージョンにわたって拡張できます。複数のリージョンに拡張することで次の領域を改善できます。

高可用性: 1 つのリージョンで障害が発生しても、トラフィックは残りのリージョンで処理されるため、API の全体的な可用性が向上します。
大容量: リージョンを追加すると、API トラフィックを処理する追加の容量が提供されます。1 つの環境に大きな負荷をかけることなく、予期しないトラフィックの急増にも対応でき、API 全体の容量を増やすことができます。
低レイテンシ: リージョンを追加すると、地理的に近いリージョンでリクエストを処理することでクライアントの全体的なトランザクションレイテンシを短縮できます。

このドキュメントでは、Apigee を新しいリージョンに追加する方法と、Apigee をリージョンから削除する方法について説明します。

Apigee を新しいリージョンに追加する

リージョンごとに使用できるランタイムインスタンスは 1 つのため、新しいリージョンを追加するには、そのリージョンにまったく新しいインスタンスを作成する必要があります。

新しいリージョンを追加する一般的なプロセスは次のとおりです。

前提条件で説明しているとおり、使用可能なピアリングネットワークに適切な IP アドレス範囲があることを確認してください。また、上限で説明されているとおり、アカウントで新しいリージョンをサポートできることを確認してください。
環境変数を定義する
新しいキーリングと鍵を作成する
新しいアドレス範囲を予約する
新しいインスタンスを作成する
環境を新しいインスタンスに接続する
ルーティングを構成する

それぞれの手順については、以降のセクションで説明します。

前提条件

お使いのネットワークで、重複しない IP アドレス範囲として /22 および /28 が利用可能なことを確認してください。また、他のリージョンで使用されている範囲も確認してください。

上限

デフォルトでは、初期組織は通常 1 つのリージョンで作成されます。2 つ目（または後続）のリージョンを作成するかどうかを決める際には、ライセンス資格で許可されている場合にのみ、リージョンを追加できる点に注意してください。必要であれば、組織パックを購入できます。

サブスクリプションベースの料金モデルを採用している場合、複数のリージョンに拡張できるように、追加の組織単位の購入が必要になることがあります。サブスクリプションの利用資格をご覧ください。
従量課金制の料金モデルを使用している場合、複数のリージョンに拡大すると、従量課金制のリージョンの追加で説明されているように追加料金が発生します。
評価アカウントは 1 つのリージョンに制限されています。2 つ目のリージョンに拡張することはできません。

さらに詳しい内容については、従量課金制の概要をご覧ください。

組織に 10（ハイブリッドの場合は 11）を超えるリージョンは設定できません。

環境変数を定義する

このドキュメント全体で使用されるコマンドの整合性を保つため、次の環境変数を定義することをおすすめします。

export NEW_REGION_LOCATION="NEW_REGION_LOCATION"
export NEW_INSTANCE_NAME="NEW_INSTANCE_NAME"
export NETWORK_NAME"=NETWORK_NAME"
export DISK_KEY_RING_NAME="YOUR_DISK_KEY_RING_NAME"
export DISK_KEY_NAME="YOUR_DISK_KEY_NAME"
export PROJECT_ID=YOUR_PROJECT_ID
export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

ここで

NEW_REGION_LOCATION は、新しいインスタンスの物理的なロケーションです。有効な値は、任意の Compute Engine リージョンです。詳細については、リージョンとゾーンをご覧ください。例: us-west1
NEW_INSTANCE_NAME は、新しいリージョンの名前です。これは組織に対して一意である必要があります。例: my-instance-2
NETWORK_NAME は、組織のピアリングネットワークの名前です。たとえば、my-network のようにします。サービスネットワーキングを構成するをご覧ください。
DISK_KEY_RING_NAME はディスクキーリングの名前です。
DISK_KEY_NAME はディスクリングの名前です。
AUTH は、署名なしトークンを含む Authentication ヘッダーを定義します。このヘッダーは、Apigee API を呼び出すときに使用します。トークンは一定期間経過すると期限切れになります。期限が切れた場合は、同じコマンドを使用して簡単に再生成できます。詳細については、print-access-token コマンドのリファレンスページをご覧ください。
PROJECT_ID は Cloud プロジェクト ID です。
PROJECT_NUMBER は、Cloud プロジェクトの Cloud プロジェクト番号です。

新しいキーリングと鍵を作成する

各リージョンには、ネットワーク固有のディスク暗号鍵が必要です。新しいリージョン用に別のキーリングを作成することもおすすめします。組織内のすべてのインスタンスが同じデータベース暗号鍵を共有するため、新しいデータベース暗号鍵を作成する必要はありません。

詳細については、Apigee 暗号鍵についてをご覧ください。

新しいディスク暗号キーリングと鍵を作成するには:

gcloud コマンドを使用して、新しいディスクキーリングを作成します。
```
gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
```
ディスクキーリングがインスタンスと同じロケーションに設定されていることを確認します。各インスタンスとキーリングには、それぞれ独自のロケーションが必要です。
```
gcloud kms keyrings list \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
```
```
gcloud kms keyrings describe $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
```

次の例のように、kms keys create コマンドを使用して、新しいディスクキーを作成します。

gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

鍵は、その鍵パスで参照できます。鍵パスは、次のコマンドで取得できます。

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

鍵パスは次のようになります。

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

gcloud kms keys add-iam-policy-binding コマンドを実行して、Apigee サービスエージェントが新しい鍵を使用するためのアクセス権を付与します。次に例を示します。

gcloud kms keys add-iam-policy-binding $DISK_KEY_NAME \
  --location $NEW_REGION_LOCATION \
  --keyring $DISK_KEY_RING_NAME \
  --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project $PROJECT_ID

鍵が Apigee サービスエージェントにバインドされていることを確認します。

gcloud kms keys get-iam-policy $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \  
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keys describe $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \  
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

新しいアドレス範囲を予約する

ピアリングネットワークのアドレス範囲に IP アドレスを予約します。詳細と重要な考慮事項については、ピアリングの範囲についてもご覧ください。

次の環境変数を作成します。
```
NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME
```
ここで
- NEW_RANGE_NAME_22 は、作成する CIDR /22 の IP アドレス範囲の名前です。範囲の名前は自由に設定できます。例: google-svcs-new_22
- NEW_RANGE_NAME_28 は、作成する CIDR /28 の IP アドレス範囲の名前です。範囲の名前は自由に設定できます。例: google-svcs-new_28
- NETWORK_NAME は、アドレスを予約するネットワークリソースの名前です。
  Google により、新しいプロジェクトごとにデフォルトネットワーク（名前は default）が作成されるため、このネットワークを使用できます。ただし、テスト以外のネットワークには、デフォルトネットワークの使用はおすすめしません。
  
  注: このセットアッププロセスをテストしない場合は、default の使用はおすすめしません。本番環境では、デフォルトネットワークの組織を使用しないでください。

CIDR /22 のネットワーク IP 範囲を作成します。

gcloud compute addresses create $NEW_RANGE_NAME_22 \
  --global \
  --prefix-length=22 \
  --description="Peering range for Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

成功すると、gcloud は次のレスポンスを返します。

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs-new].

作成されたコンピューティングアドレスを確認します。

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

gcloud compute addresses describe $NEW_RANGE_NAME_22 \
  --global \
  --project=$PROJECT_ID

IP アドレスの範囲を作成すると、そのアドレスを解放するまで、アドレスがプロジェクトに関連付けられます。

CIDR /28 のネットワーク IP 範囲を作成します。この範囲は必須で、トラブルシューティングの目的で Apigee によって使用されます。カスタマイズや変更はできません。

gcloud compute addresses create $NEW_RANGE_NAME_28 \
  --global \
  --prefix-length=28 \
  --description="Peering range for supporting Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

作成されたコンピューティングアドレスを確認します。

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

 gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID

ピアリング範囲の名前を取得します。

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

次のコマンドを使用して、ピアリングされたネットワークに、新しく予約された範囲を追加します。$NEW_RANGE_NAME_22 と $NEW_RANGE_NAME_28 は新しい範囲名、ORIGINAL_RANGE_NAME_1 と ORIGINAL_RANGE_NAME_n は前のコマンドで返された予約済みのピアリング範囲名です。
```
gcloud services vpc-peerings update --service=servicenetworking.googleapis.com \
  --network=$NETWORK_NAME \
  --ranges=$NEW_RANGE_NAME_22,$NEW_RANGE_NAME_28,ORIGINAL_RANGE_NAME_1,ORIGINAL_RANGE_NAME_n \
  --project=$PROJECT_ID
```

更新された VPC ピアリングの変更を確認します。

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

新しいインスタンスを作成する

Instances API を使用してリージョンの新しいインスタンスを作成します。

VPC ピアリングを使用する場合

Apigee が VPC ピアリングを使用するように設定されている場合は、次の API 呼び出しを使用してインスタンスを作成します。

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$NEW_INSTANCE_NAME"'",
    "location":"'"$NEW_REGION_LOCATION"'",
    "diskEncryptionKeyName":"KEY_PATH",
    "ipRange":"IP_ADDRESS_1/28, IP_ADDRESS_2/22"  # OPTIONAL
  }'

ここで

KEY_PATH は、新しいキーリングと鍵を作成するで作成したディスク暗号鍵の鍵パスです。
IP_ADDRESS_* は、Apigee インスタンスの作成に使用される /22 および /28 範囲の CIDR IP アドレスです。ipRange は省略可能です。このフィールドを指定しない場合、Apigee は Service Networking から使用可能な /22 および /28 の CIDR ブロックを自動的にリクエストします。Apigee instances API もご覧ください。

Apigee で新しい Kubernetes クラスタを作成して起動し、そのクラスタに Apigee リソースをインストールして、ロードバランシングを設定する必要があるため、このリクエストには 20 分ほどかかることがあります。

VPC ピアリングを使用しない場合

Apigee が VPC ピアリングを使用するように設定されていない場合は、次の API 呼び出しを使用してインスタンスを作成します。

curl -X POST -H "$AUTH" \
  -H "Content-Type:application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]      
  }'

ここで

KEY_PATH は、新しいキーリングと鍵を作成するで作成したディスク暗号鍵の鍵パスです。Apigee instances API もご覧ください。
consumerAcceptList（省略可）Apigee VPC のサービスアタッチメントにプライベート接続できる Google Cloud プロジェクト ID のリストを指定します。サービスアタッチメントは、Google Cloud Private Service Connect で使用されるエンティティであり、サービスプロデューサー（この場合は Apigee）がサービスをコンシューマー（この場合は、所有している 1 つ以上のクラウドプロジェクト）に公開できるようにします。デフォルトでは、Apigee 組織にすでに関連付けられている Cloud プロジェクトが使用されます。例: "consumerAcceptList": ["project1"、"project2", "project3"]

鍵パスを見つける方法

鍵パスは、次のコマンドで取得できます。

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

鍵パスは次のようになります。

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

timer: インスタンスの作成オペレーションが完了するまでに約 30 分かかります。

ランタイムインスタンスの作成リクエストのステータスを確認するには、次のコマンドを実行します。ステータスが ACTIVE の場合、次のステップに進みます。

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

追加の説明やトラブルシューティング情報など、ランタイムインスタンスの作成の詳細については、ステップ 5: Apigee ランタイムインスタンスを作成するをご覧ください。

環境を新しいインスタンスに接続する

インスタンスの作成後は、環境を接続する必要があります。そうしないと、API リクエストに応答できません。

環境はインスタンス間で共有されます。このため、既存の環境を新しいリージョンに接続します。新しいリージョンに新しい環境を定義しません。元の環境と同じホストに対して同じベースパスを提供している新しいリージョンに新しい環境を定義すると、ランタイム呼び出しによって HTTP 503 エラーが返されることがあります。

新しいリージョンに環境を設定する場合、環境グループに環境を接続する必要はありません。それらの環境はすでにグループに追加されているからです。必要なのは、環境を新しいインスタンスに接続することだけです。

環境を新しいリージョンに接続するには、次の例のように Instances attachment API を使用します。

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME/attachments \
  -d '{
    "environment":"ENVIRONMENT_NAME"
  }'

環境のリストを取得するには:

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

Instances Attachment API へ個別に呼び出しを行い、各環境を接続する必要があります。1 回の呼び出しで複数の環境を接続することはできません。

ルーティングを構成する

新しいリージョンのネットワークルーティングは、マネージドインスタンスグループ（MIG）または Private Service Connect（PSC）ベースの構成を使用して構成できます。

PSC ルーティングを構成する

次の手順では、PSC を使用して新しいリージョンでルーティングを構成する方法について説明します。

概要

次の図は、マルチリージョン PSC のノースバウンドアーキテクチャの概要を示しています。

マルチリージョン PSC ルーティングの図。

図 1: PSC を使用したノースバウンドマルチリージョンアーキテクチャ

図 1 に示すように、プロジェクト内にネットワークエンドポイントグループ（NEG）を作成し、新しい Apigee インスタンスが存在するリージョンのサービスアタッチメントと通信します。すべてのリージョンの Apigee NEG は、Apigee 本番環境のグローバル外部ロードバランサのバックエンドサービスに接続されます。

（省略可）一時的なロードバランサを使用してテストする

続行する前に、一時的なロードバランサ（LB）と NEG を設定して新しいリージョンの Apigee と通信し、新しいインスタンスをテストすることもできます。API トラフィックをテスト LB に正常に送信したら、一時 LB を削除し、NEG を Apigee 本番環境 LB のバックエンドサービスに接続します。

新しいインスタンスをテストする手順は次のとおりです。

ステップ 8: ルーティングを構成するの外部ルーティング（PSC）の説明に従って、新しいリージョンにグローバル / リージョンロードバランサをプロビジョニングします。この手順では、新しい NEG の作成と一時的な LB のバックエンドサービスの追加も行います。
外部クライアントから API プロキシをテストします。外部ルーティングを使用してテストするには、サンプルプロキシをデプロイするをご覧ください。
テストが完了したら、一時的なロードバランサを削除します。NEG を削除する必要はありません。次に説明するように再利用が可能です。ロードバランシングの設定をクリーンアップするをご覧ください。

新しいリージョンのネットワークエンドポイントグループを作成する

新しいリージョンのネットワークエンドポイントグループ（NEG）でロードバランサを作成して構成するには、次の操作を行います。

新しい NEG を作成します。
注: テスト中に作成した NEG を削除しなかった場合は、再利用できます。その場合は、この手順をスキップしてステップ 2 に進みます。
1. 前の手順で作成したインスタンスからサービスアタッチメントを取得します。
```
curl -i -X GET -H "$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/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
    }
  ]
}
```
  注: Apigee 組織の作成に使用したプロジェクトの ID は常に consumerAcceptList リストに表示されます。上の出力例では、リスト内の唯一のプロジェクトです。
2. 前の手順でインスタンスレスポンスの本文から取得したサービスアタッチメントを参照する NEG を作成します。
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=TARGET_SERVICE \
  --region=$NEW_REGION_LOCATION \
  --network=NETWORK_NAME \
  --subnet=SUBNET_NAME \
  --project=PROJECT_ID
```
  次のように置き換えます。
  - NEG_NAME: ネットワークエンドポイントグループの名前。
  - TARGET_SERVICE: 接続するサービスアタッチメント。例: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
  - NETWORK_NAME:（省略可）NEG を作成するネットワークの名前。このパラメータを省略すると、default プロジェクトネットワークが使用されます。
  - SUBNET_NAME: プロデューサーへのプライベート接続に使用されるサブネットの名前。サブネットサイズは小さくすることができます。PSC NEG にはサブネットから 1 つの IP のみが必要です。Apigee の場合、リージョンごとに必要な PSC NEG は 1 つだけです。サブネットは、VM または他のエンティティによって共有され、使用できます。サブネットが指定されていない場合、ネットワークエンドポイントは、ネットワークエンドポイントグループが作成されたリージョン内の任意のサブネットワークに属している可能性があります。
    注: --network パラメータを指定する場合は、--subnet も指定する必要があります。
  - PROJECT_ID: すでに Apigee 組織に関連付けられている Cloud プロジェクト、または Apigee ランタイムインスタンスが作成されたときに consumerAcceptlist に含まれている Cloud プロジェクト。
本番環境の Apigee ロードバランサのバックエンドサービスの名前を取得します。
```
gcloud compute backend-services list --project=$PROJECT_ID
```
NEG をバックエンドとしてバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$NEW_REGION_LOCATION \
  --global --project=$PROJECT_ID
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- NEG_NAME: ネットワークエンドポイントグループの名前。
（省略可）バックエンドサービスに外れ値検出トラフィックポリシーを設定すると、フェイルオーバーシナリオを自動的に処理できます。詳細については、以下をご覧ください。

最終設定をテストする

API プロキシを呼び出します。サンプルプロキシをデプロイするをご覧ください。

MIG ルーティングを構成する

次の手順では、マネージドインスタンスグループ（MIG）を使用して新しいリージョンでルーティングを構成する方法について説明します。

概要

次の図は、マネージドインスタンスグループ（MIG）を使用したマルチリージョンのノースバウンドアーキテクチャの概要を示しています。

マルチリージョン PSC のノースバウンドアーキテクチャの図。

図 2: MIG を使用したノースバウンドマルチリージョンアーキテクチャ

図 2 に示すように、プロジェクトに MIG を作成して、新しい Apigee インスタンスが存在するリージョンにデプロイされたロードバランサと通信します。すべてのリージョンの MIG プロキシは、Apigee の本番環境グローバル外部ロードバランサのバックエンドに接続されます。

（省略可）一時的なロードバランサを使用してテストする

続行する前に、一時的なロードバランサと MIG を設定して新しいリージョンの Apigee と通信し、新しいインスタンスをテストすることもできます。API トラフィックをテスト LB に正常に送信したら、一時 LB を削除し、MIG を Apigee 本番環境 LB のバックエンドサービスに接続します。

新しいインスタンスをテストする手順は次のとおりです。

ステップ 8: ルーティングを構成するの外部ルーティング（MIG）の説明に従って、新しいリージョンにグローバル / リージョンロードバランサをプロビジョニングします。
外部クライアントから API プロキシをテストします。外部ルーティングを使用してテストするには、サンプルプロキシをデプロイするをご覧ください。
テストが完了したら、一時的なロードバランサを削除します。MIG を削除する必要はありません。次に説明するように再利用が可能です。ロードバランシングの設定をクリーンアップするをご覧ください。

新しいリージョンのマネージドインスタンスグループ（MIG）を作成する

新しいリージョンの MIG を作成して構成するには、次の操作を行います。

VPC ネットワークのサブネットで限定公開の Google アクセスを有効にします。

VPC ネットワークのサブネットで限定公開の Google アクセスを有効にするには、限定公開の Google アクセスを有効にするの説明に従ってください。
環境変数を設定します。

このセクションの手順では、環境変数を使用して、繰り返し使用される文字列を参照します。続行する前に、これらを設定することをおすすめします。
```
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=YOUR_VPC_NAME       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=YOUR_SUBNET_NAME     # Private Google Access must be enabled for this subnet
NEW_REGION_LOCATION=YOUR_NEW_REGION      # The same region as your new Apigee runtime instance
APIGEE_ENDPOINT=APIGEE_INSTANCE_IP        # See the tip below for details on getting this IP address value
```
ヒント: 正しい Apigee インスタンスの IP アドレスを取得するには、次の例のようにインスタンス API を使用します。
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
Apigee は、インスタンスに関する詳細を返します。次に例を示します。
```
{
  "instances": [
    {
      "name": "my-runtime-instance",
      "location": "us-west1",
      "host": "10.16.0.2",
      "port": "443"
    },
    ...
  ]
}
```
$APIGEE_ENDPOINT 環境変数に割り当てることができるインスタンス IP アドレスは、host 項目の値です。この例での値は 10.16.0.2 です。

マルチリージョンインストールでは、API 呼び出しが各リージョンのロケーションのインスタンスの詳細を返します。
マネージドインスタンスグループを作成します。この手順では、マネージドインスタンスグループ（MIG）を作成して構成します。
注: テスト中に作成した MIG を削除していない場合は、再利用できます。その場合は、この手順をスキップしてステップ 3 に進みます。
1. 次のコマンドを実行して、インスタンステンプレートを作成します。
```
gcloud compute instance-templates create $MIG_NAME \
  --project $PROJECT_ID \
  --region $NEW_REGION_LOCATION \
  --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=$APIGEE_ENDPOINT,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 を構成します。
2. 次のコマンドを実行して、マネージドインスタンスグループを作成します。
```
gcloud compute instance-groups managed create $MIG_NAME \
  --project $PROJECT_ID --base-instance-name apigee-mig \
  --size 2 --template $MIG_NAME --region $NEW_REGION_LOCATION
```
3. 次のコマンドを実行して、グループの自動スケーリングを構成します。
  注: e2-medium インスタンスを含むリージョン MIG は最大 6 Gbps をサポートできますスループット要件を満たさない場合は、VM のサイズを大きくするか、レプリカ数を増やすことを検討してください。
```
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --max-num-replicas 3 \
  --target-cpu-utilization 0.75 --cool-down-period 90
```
4. 次のコマンドを実行して、名前付きポートを定義します。
```
gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
```
本番環境の Apigee ロードバランサのバックエンドサービスの名前を取得します。
```
gcloud compute backend-services list --project=$PROJECT_ID
```
次のコマンドを使用して、MIG をバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --project $PROJECT_ID --instance-group $MIG_NAME \
  --instance-group-region $NEW_REGION_LOCATION \
  --balancing-mode UTILIZATION --max-utilization 0.8 --global
```
BACKEND_SERVICE_NAME は、バックエンドサービスの名前に置き換えます。

注: ロードバランサのヘルスチェックが『VPC ピアリングを使用して有料組織をプロビジョニングする』のステップ 8e「グローバルロードバランサを作成する」のサブステップ 1「ヘルスチェックの作成」で説明されているとおりに構成されていることを確認してください。

最終設定をテストする

API プロキシを呼び出します。サンプルプロキシをデプロイするをご覧ください。

リージョンの追加

Apigee 環境に複数のリージョンを追加すると、API の高可用性、容量の増加、レイテンシの低減を実現できます。マルチリージョンデプロイでは、XLB が各リージョンのヘルスチェックを行うため手動フェイルオーバーが不要となり、高可用性がサポートされます。複数のリージョンが同じ API を同時に提供する場合は、容量が大きくなります。また、API クライアントが複数のリージョンにある場合、クライアントに近いリージョンから API を提供することで、レイテンシを短縮し、パフォーマンスを向上させることができます。

例: マルチリージョンデプロイで可用性、容量、レイテンシを改善

アクティブ / アクティブのマルチリージョンデプロイでは、トラフィックは 2 つのリージョンから同時に送信されます。ステップ 8: ルーティングを構成するセクションで、外部ルーティング（MIG）タブのステップ 8e(3) で説明されているように、各リージョンの MIG のバックエンドサービスを同じ外部 HTTPS ロードバランサ（XLB）に追加します。詳細については、新しいリージョンのマネージドインスタンスグループ（MIG）を作成するをご覧ください。

リクエスト数が特定のバックエンドに設定された上限を超えない限り、各リクエストに対して XLB はクライアントに最も近いリージョンを選択します。外部ロードバランサがトラフィックをルーティングする方法の詳細については、グローバルロードバランシングによるアプリケーションの処理能力の最適化をご覧ください。

従量課金制のリージョンの追加

従量課金制の料金モデルでは、環境の Apigee ゲートウェイノードの最小数を設定できます。これにより、リージョンで障害が発生した場合でも、リージョンを常に追加容量で稼働させ、すぐにフェイルオーバートラフィックに対応できます。

Apigee ゲートウェイノードの最小数の設定

2 つのアクティブリージョン（それぞれに 4 つの Apigee ゲートウェイノード）から通常の API トラフィックをすべて処理できるようにするには、各リージョンに少なくとも 8 つのノードが必要です。これは、1 つのリージョンを失った場合に直ちに対応するためのものです。API トラフィックの処理に必要なノード数を決定する方法については、Apigee ノードについてをご覧ください。ノードの最小数は環境ごとに設定されますが、適用されるのはリージョンごとです。たとえば、最小値を 8 に設定した場合、各リージョンに少なくとも 8 ノードが設定されます。

費用

上記の例では、少なくとも 16 個の Apigee ゲートウェイノード（8 ノード x 2 リージョン）の費用が発生します。追加のトラフィックを処理するためにノード数が自動的に増加し、最大トラフィックまで費用が増える可能性があります。

リージョンからの Apigee の削除

API トラフィックの処理から Apigee インスタンスを除外する場合は、次の手順に沿ってサービスが中断しないようにします（API のダウンタイムをゼロにします）。

バックエンドサービスでコネクションドレインを有効にします。コネクションドレインとは、バックエンドがバックエンドサービスから削除されたときに、既存の進行中リクエストを完了するための時間を確保するプロセスです。
重み付けされたラウンドロビンルーティングポリシーを介して、この Apigee リージョンにトラフィックを転送するように Cloud DNS が構成されている場合は、DNS ルーティングポリシーとヘルスチェックを管理するで説明されているように DNS 構成を削除します。
バックエンドサービスから MIG バックエンドを切断します。これとコネクションドレインにより、Apigee インスタンスで新しいトラフィックを受信せずに、処理中のリクエストを完了できるようにします。
Apigee インスタンスとそれに対応する MIG を削除します。インスタンスを削除するをご覧ください。

複数のリージョンへの Apigee の拡張

Apigee を新しいリージョンに追加する

前提条件

上限

環境変数を定義する

新しいキーリングと鍵を作成する

新しいアドレス範囲を予約する

新しいインスタンスを作成する

VPC ピアリングを使用する場合

VPC ピアリングを使用しない場合

鍵パスを見つける方法

環境を新しいインスタンスに接続する

ルーティングを構成する

PSC ルーティングを構成する

概要

（省略可）一時的なロードバランサを使用してテストする

新しいリージョンのネットワーク エンドポイント グループを作成する

最終設定をテストする

MIG ルーティングを構成する

概要

（省略可）一時的なロードバランサを使用してテストする

新しいリージョンのマネージド インスタンス グループ（MIG）を作成する

最終設定をテストする

リージョンの追加

例: マルチリージョン デプロイで可用性、容量、レイテンシを改善

従量課金制のリージョンの追加

Apigee ゲートウェイ ノードの最小数の設定

費用

リージョンからの Apigee の削除

新しいリージョンのネットワークエンドポイントグループを作成する

新しいリージョンのマネージドインスタンスグループ（MIG）を作成する

例: マルチリージョンデプロイで可用性、容量、レイテンシを改善

Apigee ゲートウェイノードの最小数の設定