Apigee を複数リージョンに拡張する

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

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

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

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

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

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

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

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

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

それぞれの手順は、次のセクションで説明します。

前提条件

お使いのネットワークで、重複しない 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 暗号鍵についてをご覧ください。

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

  1. 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
  2. 次の例のように、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
  3. 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 アドレスを予約します。詳細と重要な考慮事項については、ピアリングの範囲についてもご覧ください。

  1. 次の環境変数を作成します。 
    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）が作成されるため、このネットワークを使用できます。ただし、テスト以外のネットワークには、デフォルト ネットワークの使用はおすすめしません。

  2. 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 アドレスの範囲を作成すると、そのアドレスを解放するまで、アドレスがプロジェクトに関連付けられます。

  3. 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

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

    gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
     
     gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID
  4. ピアリング範囲の名前を取得します。
    gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
  5. 次のコマンドを使用して、ピアリングされたネットワークに、新しく予約された範囲を追加します。$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

    6. 更新された 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"]

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

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 AP へ個別に呼び出しを行い、各環境をアタッチする必要があります。1 回の呼び出しで複数の環境をアタッチすることはできません。

ルーティングを構成する

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

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

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

概要

次の図は、マルチリージョン PSC の北方向のアーキテクチャの概要を示しています。

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

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

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

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

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

  1. 新しい NEG を作成します。
    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"
    }
  ]
}

    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 または他のエンティティによって共有され、使用できます。 サブネットが指定されていない場合、ネットワーク エンドポイントは、ネットワーク エンドポイント グループが作成されたリージョン内の任意のサブネットワークに属している可能性があります。
      • PROJECT_ID すでに Apigee 組織に関連付けられている Cloud プロジェクト、または Apigee ランタイム インスタンスが作成されたときに consumerAcceptlist に含まれている Cloud プロジェクト。
  2. 本番環境の Apigee ロードバランサのバックエンド サービスの名前を取得します。
    gcloud compute backend-services list --project=$PROJECT_ID
  3. 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: ネットワーク エンドポイント グループの名前。
  4. （省略可）バックエンド サービスに外れ値検出トラフィック ポリシーを設定すると、フェイルオーバー シナリオを自動的に処理できます。詳しくは以下をご覧ください。

最終設定をテストする

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

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

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

概要

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

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

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

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

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

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

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

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

  2. 環境変数を設定します。

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

    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
  3. マネージド インスタンス グループを作成します。このステップでは、マネージド インスタンス グループ（MIG）を作成して構成します。
    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. 次のコマンドを実行して、グループの自動スケーリングを構成します。 
      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
  4. 本番環境の Apigee ロードバランサのバックエンド サービスの名前を取得します。
    gcloud compute backend-services list --project=$PROJECT_ID
  5. 次のコマンドを使用して、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 は、バックエンド サービスの名前に置き換えます。

最終設定をテストする

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 のダウンタイムをゼロにします）。

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