マイクロサービス アーキテクチャでは、クライアントが複数のフロントエンド サービスと対話する場合があります。 この事実を考えると、クライアントはどのエンドポイントを呼び出す必要があるかを知る方法を教えてください。 新しいサービスが導入されたとき、または既存のサービスがリファクタリングされるとどうなりますか? サービスは、SSL 終了、相互 TLS、認証、およびその他の懸念事項をどのように処理しますか? API ゲートウェイ は、これらの課題に対処するのに役立ちます。
の図
このアーキテクチャの Visio ファイル をダウンロードします。
API ゲートウェイとは
API ゲートウェイは、クライアントとアプリケーション サービス間の対話を管理するための一元的なエントリ ポイントを提供します。 リバース プロキシとして機能し、クライアント要求を適切なサービスにルーティングします。 また、認証、SSL 終了、相互 TLS、レート制限など、さまざまな横断的なタスクを実行することもできます。
API ゲートウェイを使用する理由
API ゲートウェイは、通信を簡素化し、クライアントとの対話を強化し、一般的なサービス レベルの責任の管理を一元化します。 仲介役として機能し、アプリケーション サービスがクライアントに直接公開されるのを防ぎます。 API ゲートウェイがない場合、クライアントは個々のアプリケーション サービスと直接通信する必要があります。これにより、次の課題が発生する可能性があります。
複雑なクライアント コード: 複雑なクライアント コードが発生する可能性があります。 クライアントは、複数のエンドポイントを追跡し、障害を回復性のある方法で処理する必要があります。
密結合: クライアントとバックエンドの間に結合が作成されます。 クライアントは、個々のサービスの分解を理解し、サービスのメンテナンスとリファクタリングを複雑にする必要があります。
待機時間の増加: 1 回の操作で複数のサービスの呼び出しが必要になる場合があります。 その結果、クライアントとサーバーの間に複数のネットワーク ラウンド トリップが発生し、待機時間が大幅に増加する可能性があります。
の懸念事項の冗長な処理: 各公開サービスでは、認証、SSL、クライアント レート制限などの問題を処理する必要があります。
プロトコルの制限: サービスは、HTTP や WebSocket などのクライアントフレンドリ なプロトコルを公開する必要があります。 この露出により、通信プロトコル オプション 制限されます。
拡張攻撃対象領域の: パブリック エンドポイントは潜在的な攻撃対象領域を増やし、セキュリティ強化を必要とします。
API ゲートウェイを使用する方法
API ゲートウェイは、特定の設計パターンを使用して、アプリケーションの要件に合わせて調整できます。 これらの設計パターンは、ルーティング、要求の集計、横断的な問題などの主要な機能に対処します。
ゲートウェイ ルーティング をします。 API ゲートウェイをリバース プロキシとして使用して、クライアント要求をさまざまなアプリケーション サービスにルーティングできます。 API ゲートウェイはレイヤー 7 ルーティングを使用し、クライアントが使用する単一のエンドポイントを提供します。 アプリケーション サービスからクライアントを切り離す場合は、API ゲートウェイ ルーティングを使用します。
ゲートウェイ集計 をします。 API ゲートウェイを使用して、複数のクライアント要求を 1 つの要求に集約できます。 このパターンは、1 回の操作で複数のアプリケーション サービスを呼び出す必要がある場合に使用します。 API 集計では、クライアントは 1 つの要求を API ゲートウェイに送信します。 次に、API ゲートウェイは、操作に必要なさまざまなサービスに要求をルーティングします。 最後に、API ゲートウェイによって結果が集計され、クライアントに送信されます。 この集計は、クライアントとアプリケーション サービスの間のチャットを減らすのに役立ちます。
ゲートウェイオフロード。 API ゲートウェイを使用して横断的な機能を提供できるため、個々のサービスで提供する必要はありません。 すべてのサービスに責任を負うのではなく、クロスカット機能を 1 か所に統合すると便利です。 API ゲートウェイにオフロードできる機能の例を次に示します。
- SSL 終了
- 相互 TLS
- 認証
- IP 許可リストまたはブロックリスト
- クライアント レート制限 (調整)
- ログ記録と監視
- 応答キャッシュ
- Web アプリケーション ファイアウォール
- GZIP 圧縮
- 静的コンテンツのサービス
API ゲートウェイ のオプション
アプリケーションに API ゲートウェイを実装するためのオプションを次に示します。
リバース プロキシ サーバー をします。 Nginx と HAProxy は、オープンソースのリバース プロキシ オファリングです。 負荷分散、SSL 終了、レイヤー 7 ルーティングなどの機能がサポートされています。 無料版と有料版があり、追加の機能とサポートオプションを提供しています。 これらの製品は、豊富な機能セット、高パフォーマンス、拡張性で成熟しています。
サービス メッシュ イングレス コントローラー。 サービス メッシュを使用する場合は、そのサービス メッシュに固有のイングレス コントローラーの機能を評価します。 Istio や Open Service Mesh などの AKS でサポートされているアドオンを確認します。 Linkerd や Consul Connect などのサードパーティのオープンソース プロジェクトを探します。 たとえば、Istio イングレス コントローラーでは、レイヤー 7 のルーティング、HTTP リダイレクト、再試行、およびその他の機能がサポートされます。
Azure Application Gatewayをします。 Application Gateway は、マネージド負荷分散サービスです。 レイヤー 7 ルーティング、SSL 終了、および Web アプリケーション ファイアウォール (WAF) を実行できます。
Azure Front Doorをします。 Azure Front Door はコンテンツ配信ネットワーク (CDN) です。 グローバルおよびローカルのプレゼンス ポイント (POP) を使用して、アプリケーションの静的および動的な Web コンテンツへの高速で信頼性の高い安全なアクセスをグローバルに提供します。
Azure API Managementをします。 API Management は、外部および内部のお客様に API を発行するためのマネージド ソリューションです。 レート制限、IP 制限、Microsoft Entra ID やその他の ID プロバイダーを使用した認証など、公開 API を管理するための機能が提供されます。 API Management では負荷分散が実行されないため、Azure Application Gateway やリバース プロキシなどのロード バランサーで使用する必要があります。 詳細については、Azure Application Gateway を使用した API Management のに関するページを参照してください。
API ゲートウェイ テクノロジを選択する
API ゲートウェイを選択するときは、次の要因を考慮してください。
すべての要件をサポートします。 必要な機能をサポートする API ゲートウェイを選択します。 前の API ゲートウェイ オプションはすべて、レイヤー 7 ルーティング サポートしています。 ただし、認証、レート制限、SSL 終了など、他の機能のサポートは異なる場合があります。 1 つのゲートウェイがニーズを満たしているかどうか、または複数のゲートウェイが必要かどうかを評価します。
組み込みのオファリングを優先します。 Azure Container Apps や AKS など、プラットフォームによって提供される組み込みの API ゲートウェイとイングレス ソリューションは、セキュリティと制御の要件を満たすたびに使用します。 組み込みオプションに必要な柔軟性がない場合にのみ、カスタム ゲートウェイを使用します。 カスタム ソリューションでは、そのライフサイクルを効果的に管理するために、GitOps などのガバナンス モデルが必要です。
適切なデプロイ モデルを選択します。 運用オーバーヘッドを削減するには、Azure Application Gateway や Azure API Management などのマネージド サービスを使用します。 汎用リバース プロキシまたはロード バランサーを使用する場合は、アーキテクチャに合わせてデプロイします。 汎用 API ゲートウェイは、専用の仮想マシンにデプロイすることも、イングレス コントローラー オファリングの AKS クラスター内にデプロイすることもできます。 ワークロードから API ゲートウェイを分離するには、それらをクラスターの外部にデプロイできますが、このデプロイにより管理の複雑さが増します。
変更を管理します。 サービスを更新したり、新しいサービスを追加したりするときに、ゲートウェイ ルーティング規則の更新が必要になる場合があります。 サービス、SSL 証明書、IP 許可リスト、およびセキュリティ構成を追加または変更するときにルーティング規則を管理するプロセスまたはワークフローを実装します。 コードとしてのインフラストラクチャと自動化ツールを使用して、API ゲートウェイ管理を効率化します。
次の手順
前の記事では、マイクロサービス間、およびマイクロサービスとクライアント アプリケーションの間で インターフェイスについて説明しました。 これらのインターフェイスは、各サービスを自己完結型の不透明なユニットとして扱います。 マイクロサービス アーキテクチャの重要な原則は、サービスがデータの管理方法に関する内部の詳細を公開してはいけないということです。 この方法は、次の記事の対象となるデータの整合性と整合性を維持するために大きな影響を与えます。
マイクロサービス の データに関する考慮事項
関連リソース
- マイクロサービス 用の API を設計する
- マイクロサービス アーキテクチャ を設計する
- ドメイン分析を使用してマイクロサービス をモデル化する
- マイクロサービスの評価と準備の