編集

ゲートウェイ ルーティング パターン

Azure Application Gateway

単一のエンドポイントを使用して複数のサービスまたは複数のサービス インスタンスに要求をルーティングします。 このパターンは次の場合に役立ちます。

  • 単一のエンドポイントで複数のサービスを公開し、要求に基づいて適切なサービスにルーティングする
  • 負荷分散または可用性を目的として、1 つのエンドポイントで同じサービスの複数のインスタンスを公開する
  • 1 つのエンドポイントで同じサービスの異なるバージョンを公開し、異なるバージョン間でトラフィックをルーティングする

コンテキストと問題

クライアントで複数のサービス、複数のサービス インスタンス、またはその両方の組み合わせを使用する必要がある場合は、サービスが追加または削除されたときにクライアントを更新する必要があります。 次のシナリオで考えてみましょう。

  • 複数の異種サービス - 電子商取引アプリケーションが、検索、レビュー、カート、チェックアウト、注文履歴などのサービスを提供しています。 クライアントが対話する必要のある API がサービスごとに異なり、クライアントはサービスに接続するために、各エンドポイントを把握する必要があります。 API が変更された場合、クライアントも更新する必要があります。 サービスを複数の個別のサービスにリファクタリングする場合は、サービスとクライアントの両方でコードを変更する必要があります。
  • 同じサービスの複数のインスタンス - システムで、同じリージョンまたは異なるリージョンで同じサービスの複数のインスタンスを実行する必要がある場合があります。 負荷分散のために、または可用性要件を満たすために、複数のインスタンスを実行できます。 需要に合わせてインスタンスがスピンアップまたはスピンダウンされるたびに、クライアントを更新する必要があります。
  • 同じサービスの複数のバージョン - デプロイ戦略の一環として、既存のバージョンと共に新しいバージョンのサービスをデプロイできます。 これは Blue/Green デプロイと呼ばれます。 これらのシナリオでは、新しいバージョンと既存のエンドポイントにルーティングされるトラフィックの割合が変更されるたびに、クライアントを更新する必要があります。

解決策

一連のアプリケーション、サービス、またはデプロイの前にゲートウェイを配置します。 アプリケーションのレイヤー 7 ルーティングを使用して、要求を適切なインスタンスにルーティングします。

このパターンでは、クライアント アプリケーションは単一のエンドポイントについて認識し、単一のエンドポイントと通信するだけで済みます。 以下は、ゲートウェイ ルーティング パターンが、コンテキストと問題のセクションで概説した 3 つのシナリオにどのように対処するかを示しています。

複数の異種サービス

検索サービス、チェックアウト サービス、注文履歴サービス、カート サービス、レビュー サービスの前にあるゲートウェイの図。

ゲートウェイ ルーティング パターンは、クライアントが複数のサービスを使用しているこのシナリオで役立ちます。 サービスが統合、分解、または置き換えられた場合、クライアントを必ずしも更新する必要はありません。 引き続きゲートウェイに要求することができ、ルーティングだけが変更されます。

また、ゲートウェイにより、クライアントからバックエンド サービスを抽象化できるので、ゲートウェイの背後でバックエンド サービスの変更を可能にしながら、クライアント呼び出しをシンプルに保つことができます。 クライアント呼び出しは、クライアントの予想される動作を処理する必要がある 1 つまたは複数のサービスにルーティングできるので、クライアントを変更せずに、ゲートウェイの背後でサービスを追加、分割、再構成できます。

同じサービスの複数のインスタンス

リージョン 1 の検索サービスとリージョン 2 の検索サービスの前にあるゲートウェイの図。

弾力性はクラウド コンピューティングにおいて重要です。 サービスは、増加する需要を満たすためにスピンアップしたり、需要が少ないときにスピンダウンしてコストを節約したりすることができます。 サービス インスタンスの登録と登録解除の複雑さは、ゲートウェイにカプセル化されています。 クライアントは、サービスの数の増減を認識していません。

サービス インスタンスは、1 つまたは複数のリージョンにデプロイできます。 Geode パターンでは、複数リージョンのアクティブ/アクティブ デプロイによって待機時間が短縮され、サービスの可用性が向上する方法が詳しく説明されています。

同じサービスの複数のバージョン

検索サービス バージョン 1 と検索サービス バージョン 1.1 の前にあるゲートウェイの図。

このパターンは、更新プログラムをユーザーにロールアウトする方法を管理できるため、デプロイに使用できます。 サービスの新しいバージョンをデプロイするときは、既存のバージョンと並行してデプロイできます。 ルーティングにより、クライアントに提示するサービスのバージョンを制御できるため、更新プログラムのロールアウトが増分、並列、完全のいずれであるかを問わず、さまざまなリリース戦略を使用する柔軟がもたらされます。 新しいサービスのデプロイ後に問題が見つかった場合、ゲートウェイで構成変更を行うことで、クライアントに影響を及ぼすことなく、簡単に元に戻すことができます。

問題と注意事項

  • ゲートウェイ サービスによって、単一障害点が生じる可能性があります。 可用性の要件が満たされるように、適切に設計されていることを確認します。 実装では、回復性とフォールト トレランス機能を検討してください。
  • ゲートウェイ サービスによって、ボトルネックが生じる可能性があります。 ゲートウェイが負荷を処理できる十分なパフォーマンスを備えており、成長予測に合わせて簡単に拡張できることを確認します。
  • サービスの連鎖的なエラーが発生しないように、ゲートウェイに対してロード テストを実行します。
  • ゲートウェイ ルーティングはレベル 7 です。 IP、ポート、ヘッダー、または URL に基づくことができます。
  • ゲートウェイ サービスは、グローバルまたはリージョンにできます。 Azure Front Door はグローバル ゲートウェイですが、Azure Application Gateway はリージョンです。 ソリューションでサービスの複数リージョンのデプロイが必要な場合は、グローバル ゲートウェイを使用します。 トラフィックの分散方法をきめ細かく制御する必要があるリージョン ワークロードがある場合は、Application Gateway の使用を検討してください。 たとえば、仮想マシン間でトラフィックを分散したいとします。
  • ゲートウェイ サービスは、その前にあるサービスのパブリック エンドポイントです。 ゲートウェイまたはプライベート仮想ネットワーク経由でのみサービスにアクセスできるようにして、バックエンド サービスへのパブリック ネットワーク アクセスを制限することを検討してください。

このパターンを使用する状況

このパターンは次の状況で使用します。

  • クライアントが、ゲートウェイの背後でアクセスできる複数のサービスを使用する必要がある場合。
  • 単一のエンドポイントを使用することで、クライアント アプリケーションを簡素化する場合。
  • 外部でアドレス指定可能なエンドポイントから内部仮想エンドポイントに要求をルーティングする必要がある場合 (VM のポートをクラスターの仮想 IP アドレスに公開する場合など)。
  • クライアントが、待機時間または可用性の利点を得るために、複数のリージョンで実行されているサービスを使用する必要がある場合。
  • クライアントが、さまざまな数のサービス インスタンスを使用する必要がある場合。
  • クライアントが複数のバージョンのサービスに同時にアクセスするデプロイ戦略を実装する場合。

このパターンは、1 つか 2 つのサービスしか使用しない単純なアプリケーションには適していないことがあります。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ゲートウェイ ルーティングパターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。

重要な要素 このパターンが柱の目標をサポートする方法
信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 ゲートウェイルーティングを使用すると、システム内の健全なノードだけにトラフィックをルーティングできます。

- RE: 05冗長性
- RE: 10 ヘルスモニタリング
オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 ゲートウェイルーティングを使用すると、バックエンドから要求を切り離すことができます。これにより、バックエンドは高度な展開モデル、プラットフォーム移行、および転送中のドメイン名解決と暗号化の単一管理ポイントをサポートできます。

- OE:04 ツールとプロセス
- OE:11 安全な配備の実践
パフォーマンスの効率化は、スケーリング、データ、コードを最適化することによって、ワークロードが効率的にニーズを満たすのに役立ちます。 ゲートウェイルーティングを使用すると、システム内のノード間でトラフィックを分散して負荷を分散できます。

- PE:05 スケーリングとパーティショニング

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

例

ルーターとして Nginx を使用して、さまざまな仮想ディレクトリに存在するアプリケーションの要求を、それぞれバックエンドの異なるコンピューターにルーティングするサーバーの構成ファイルの簡単な例を次に示します。

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

次の Azure サービスを使用して、ゲートウェイ ルーティング パターンを実装できます。