ダウンタイムなしでの Apigee インスタンスの再作成

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

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

このドキュメントでは、API 管理のダウンタイムやデータ損失を発生させずに、Apigee インスタンスを再作成する方法について説明します。

はじめに

2022 年 1 月 25 日より前に作成された Apigee インスタンスには、インターネットプロトコル（IP）アドレス空間が不足しているため、Apigee ワークロードをスケーリングし、API トラフィックの増加や、インスタンスへの 10 個以上の環境の追加はできません。

2022 年 1 月 24 日に、Apigee はこの問題に対処するための機能強化を導入しました。この機能強化により、VPC ネットワークと Apigee をピアリングするために必要な IP 範囲が縮小され、プライベートで利用されるパブリック IP（PUPI）を使用して、ワークロードの上限を引き上げることができます。

ご対応のお願い

2022 年 1 月 25 日より前に作成された Apigee インスタンスがある場合は、このドキュメントで説明するように、新しいインスタンスに置き換えることをおすすめします。古いインスタンスを再作成しないと、スケーリングの問題が発生する可能性があります。また、インスタンスに追加できる環境の数は、引き続き 10 に制限されます。また、インスタンスで定期的な更新が停止され、API サービスに影響する可能性があります。

インスタンスの作成日の確認

Apigee インスタンスの作成日を確認するには:

組織内のすべての Apigee インスタンスの詳細を一覧表示します。

AUTH="Authorization: Bearer $(gcloud auth print-access-token)"

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

ここで

AUTH は、署名なしトークンを含む認証ヘッダーです。gcloud のデフォルトプロジェクトが PROJECT_ID に設定されていることを確認してください。
PROJECT_ID は、Apigee をプロビジョニングしたときに作成した Cloud プロジェクト ID です。

出力例:

{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.117.200.2",
      "port": "443",
      "createdAt": "1642698826000",
      "lastModifiedAt": "1655745226000",
      "diskEncryptionKeyName": "projects/myproject/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-8-0-apigee-33",
      "ipRange": "10.117.200.0/22,10.81.174.192/28",
      "consumerAcceptList": [
        "myproject"
      ],
      "serviceAttachment": "projects/z11f28c6f3104980e-tp/regions/us-west1/serviceAttachments/apigee-us-west1-lbko"
    }
  ]
}

各インスタンスについて、Unix タイムスタンプをデコードして日付を取得し、createdAt フィールドの値を確認します。
- 2022 年 1 月 25 日以降にインスタンスが作成された場合は、そのインスタンスに対して何もする必要はありません。
- 2022 年 1 月 25 日より前にインスタンスを作成した場合は、このドキュメントの説明に沿ってインスタンスを置換することをおすすめします。

再作成手順について

ダウンタイムがなく、データ損失も発生させずにインスタンスを再作成するには、まず新しい（拡張された）リージョンに新しいインスタンスを作成し、その新しいインスタンスに API トラフィックを送信する必要があります。次に、既存のインスタンスをドレインして削除し、削除したのと同じリージョンに再作成します。

Apigee には、インスタンスの再作成と構成に必要なすべての手順を実行する一連のスクリプトが用意されています。スクリプトへのリンクは、このドキュメントの後半で紹介します。

前提条件

インスタンスの再作成手順を始める前に:

そもそも Apigee インスタンスがどのように作成されたかを理解しておく必要があります。インスタンスを再作成する手順は、元のインスタンスの構成方法によって異なります。
少なくとも 2 つのリージョンで Apigee をプロビジョニングする資格が必要です。十分な利用資格があるかどうか不明な場合は、手順に沿って新しいリージョンにインスタンスを作成します。適切な利用資格がない場合、試行は失敗し、制限エラーが発生します。その場合は、Apigee サポートに連絡して、リージョンの上限を引き上げるための一時的な例外規定を受けてください。すでに 2 つ以上のリージョンの利用資格がある場合は、再作成プロセス中にインスタンスの縮小で本番環境ワークロードを実行しないように、一時的な例外規定を受けることをおすすめします。
インスタンスを再作成するプロセスには、古いインスタンスの削除が含まれます。拡張されたリージョンに新しいインスタンスを作成しないと、ダウンタイム、ランタイムデータ（KVM、キャッシュデータ、割り当てデータ、KMS データなど）の損失が発生します。したがって、ダウンタイムやデータ損失なしにインスタンスを再作成するには、リージョン拡張が必要です。
新しいインスタンスを作成するには、プロジェクトに /22 ブロックと /28 ブロックの追加の IP 範囲用のスペースが必要です。ネットワークのサイズ設定もご覧ください。この範囲は、インスタンスの再作成が完了した後で追加のリージョンが削除されるときにリリースできます。/22 ブロックは構成可能であることにご留意ください。Apigee が使用する /28 ブロックを選択できます。選択しない場合は、使用可能なブロックから Apigee によって自動的に割り当てられます。

インスタンスの再作成

Apigee には、インスタンスを再作成するために必要なすべての手順を実行する一連のスクリプトが用意されています。

前提条件を満たしていることを確認します。
GitHub からスクリプトをダウンロードします。
Git リポジトリの README ファイルの手順に沿って、新しいインスタンスを作成します。
新しい Apigee インスタンスを指すように、上りと下りの接続を再構成します。ノースバウンドの変更についてとサウスバウンドの変更についてをご覧ください。

ノースバウンドの変更について

ノースバウンドとは、外部または内部のクライアントからロードバランサを経由する Apigee への API トラフィックを指します。インスタンスを削除して再作成すると、インスタンスのノースバウンド IP アドレスと Private Service Connect（PSC）サービスアタッチメント ID が変化します。

提供されているスクリプトを使用すると、ロードバランサのバックエンドが再構成されます。インスタンスのネットワークルーティングがマネージドインスタンスグループ（MIG）で構成されている場合、提供されたスクリプトがトラフィックを Apigee エンドポイントにプロキシする MIG を再作成し、既存のバックエンドサービスにバックエンドとして MIG を接続します。ルーティングが Private Service Connect（PSC）で構成されている場合、スクリプトはネットワークエンドポイントグループ（NEG）を Apigee のサービスエンドポイントアタッチメントに再作成し、新しい NEG を既存のバックエンドサービスにバックエンドとして接続します。

古いインスタンスに関連付けられている環境グループのホスト名レコードを変更する必要はないことにご留意ください。

サウスバウンドの変更

サウスバウンドとは、Apigee から API プロキシターゲットサービスへの API トラフィックを指します。

インスタンスを削除して再作成すると、専用のサウスバウンド NAT IP アドレスがリリースされます。そのため、NAT 用に新しい IP アドレスを予約して有効にし、ターゲットエンドポイントでファイアウォール / 許可リストを再構成する必要があります。必要に応じて、提供されているスクリプトのいずれかでこの NAT 再構成を処理します。