Flex Gateway の複数リージョンデプロイメント
Flex Gateway を複数のリージョンにインストールして、レイテンシーを低減し、ライブフェールオーバーを確実に実行します。ほとんどの実装は、複数の Flex Gateway または複数の Flex レプリカを使用して設定できます。どちらを選択するかによって、Redis 共有ストレージ、ポリシー、ログに関する考慮事項が異なります。Flex レプリカについての詳細は、「Flex レプリカ」を参照してください。
以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。
実装図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。
実装 1: 2 つの個別のリージョンで同じ API を使用する高可用性
実装 1 では、リージョン固有ではないトラフィックに対して高可用性を提供します。DNS サービスはアクティブ-アクティブフェールオーバー用に設定されます。つまり、常に各リージョンでトラフィックを処理します。
実装 1A: クロスリージョン Flex Gateway
この実装では、次のようになります。
-
1 つの Flex Gateway には、複数のリージョンに分散する Flex レプリカがあります。
-
Flex Gateway は Anypoint Platform に 1 回登録され、複数のリージョンと可用性ゾーンにデプロイされます。
-
各 Flex Gateway のログとメトリクスは Anypoint Platform で統合されます。
-
DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。
-
Gateway にデプロイされた API は、すべてのリージョンおよび可用性ゾーンで使用できます。
-
アップストリームサービスやポリシーを含む API 設定はすべてのリージョンで同じです。アップストリームサービスはリージョンに依存しない必要があります。つまり、DNS がローカルであるか、DNS にリージョンへの参照がないかのいずれかです。
-
Redis クラスターをリージョン間で複製する必要があります。複製しない場合、Redis 共有ストレージを使用できません。Redis の複製は、トラフィックがリージョン固有でない場合に必要です。
-
唯一のクロスリージョントラフィックは Redis 同期です。
次の図では、異なるリージョンおよび可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。
実装 1B: リージョン固有の Flex Gateway
この実装では、次のようになります。
-
各リージョンに個別の Flex Gateway があり、すべてのリソースが独立したエンティティとして存在します。
-
リージョンごとに個別の Flex Gateway が登録されます。
-
リージョン固有の各 API インスタンスには、Anypoint Platform の個別のメトリクス、アラート、ログがあります。
-
設定がリージョン間で似ている場合でも、ポリシーはリージョン固有です。
-
DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。
-
API デプロイメントは Flex Gateway ごとに固有です。リージョンでサポートされる API ごとに、API インスタンスをリージョンの Flex Gateway にデプロイする必要があります。
-
API グループはコントラクト (アクセス要求) をリージョン間で共有できます。設定で API グループが必要でない場合があります。
-
Redis 共有ストレージでは同期は不要です。
-
クロスリージョントラフィックはありませんん。
次の図では、すべての API が重複しているため、同一の設定は不要です。
実装 2: API の障害回復
この実装は、実装 1A: クロスリージョン Flex Gatewayと似ています。ただし、DNS サービスがアクティブ-パッシブのため、スタンバイリージョンは、プライマリリージョンが健全でなくなった場合のみトラフィックを受信します。この実装では、実装 1A よりも設定の複雑さが軽減されます。
フェールオーバー中のキャッシュ損失が受け入れられる場合、Redis 同期は不要です。
次の図では、異なる可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。リージョン B は高可用性を提供しますが、リージョン A が健全でない場合のみトラフィックを受信します。
実装 3: 最も近いリージョンへのトラフィックの転送
実装 3A: 同じポリシーを使用する API へのトラフィックの転送と実装 3B: 異なるポリシーを使用する API へのトラフィックの転送の両方で、Flex Gateway は最も都合の良いリージョンにトラフィックを転送して、レイテンシーを低減します。ポリシー要件に従って実装を選択します。
実装 3A: 同じポリシーを使用する API へのトラフィックの転送
この実装は実装 1A: クロスリージョン Flex Gatewayと似ており、考慮事項は同じです。ただし、要求が特定のリージョンに送信されるため、Redis の複製は不要です。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。
実装 3B: 異なるポリシーを使用する API へのトラフィックの転送
この実装は実装 1B: リージョン固有の Flex Gatewayと似ており、考慮事項は同じです。リージョン固有のゲートウェイをデプロイし、必要なポリシーを各 API に適用します。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。
| SLA のレート制限をすべてのリージョンに適用するには、すべてのリージョンでレート制限が同じである必要があります。コントラクトを統合するには、API グループを使用します。 |