API ゲートウェイを調べる
ソリューションには、複数のフロントエンド サービスとバックエンド サービスが含まれている場合があります。 このシナリオでは、クライアントが呼び出すエンドポイントを知る方法を教えてください。 新しいサービスが導入されたとき、あるいは既存のサービスがリファクタリングされたときは何が起こるのでしょうか。 サービスは、SSL 終了、認証、その他の問題をどのように処理しますか?
API Management ゲートウェイ (データ プレーンまたはランタイムとも呼ばれます) は、API 要求のプロキシ、ポリシーの適用、テレメトリの収集を担当するサービス コンポーネントです。
API ゲートウェイは、クライアントとサービスの間に配置されます。 それは、要求をクライアントからサービスにルーティングするリバース プロキシとして機能します。 また、認証、SSL 終了、レート制限など、さまざまな横断的なタスクを実行することもできます。 ゲートウェイをデプロイしない場合、クライアントはバックエンド サービスに直接要求を送信する必要があります。 ただし、サービスをクライアントに直接公開する際には、いくつかの潜在的な問題があります。
- 複雑なクライアント コードが発生する可能性があります。 クライアントは、複数のエンドポイントを追跡し、回復力のある方法で障害を処理する必要があります。
- クライアントとバックエンドの間に結合が作成されます。 クライアントは、個々のサービスがどのように分解されるかを知る必要があります。 これにより、クライアントの保守が困難になり、サービスのリファクタリングも困難になります。
- 1 回の操作で複数のサービスを呼び出す必要がある場合があります。
- 各公開サービスでは、認証、SSL、クライアントレート制限などの問題を処理する必要があります。
- サービスは、HTTP や WebSocket などのクライアントフレンドリ なプロトコルを公開する必要があります。 これにより、通信プロトコルの選択が制限されます。
- パブリック エンドポイントを使用するサービスは潜在的な攻撃対象であり、セキュリティを強化する必要があります。
ゲートウェイは、クライアントをサービスから切り離すことで、これらの問題に対処するのに役立ちます。
マネージドとセルフホステッド
API Management は、マネージド ゲートウェイとセルフホステッド ゲートウェイの両方を提供します。
マネージド - マネージド ゲートウェイは、すべてのサービス レベルのすべてのAPI Management インスタンスに対して Azure にデプロイされる既定のゲートウェイ コンポーネントです。 マネージド ゲートウェイを使用すると、API を実装するバックエンドがホストされる場所に関係なく、すべての API トラフィックが Azure を通過します。
セルフホステッド - セルフホステッド ゲートウェイは、既定のマネージド ゲートウェイのオプションのコンテナー化されたバージョンです。 これは、API バックエンドがホストされているのと同じ環境で Azure からゲートウェイを実行する要件があるハイブリッドおよびマルチクラウドのシナリオに役立ちます。 セルフホステッド ゲートウェイを利用すると、ハイブリッド IT インフラストラクチャを使用しているお客様は、オンプレミスおよびクラウドに渡ってホストされている API を Azure 内の単一の API Management サービスから管理できるようになります。