適用対象: すべての API Management レベル
マイクロサービスは API を構築するのに最適です。 Azure Kubernetes Service (AKS) を使用して、マイクロサービス ベースのアーキテクチャをクラウドに迅速にデプロイして運用できます。 その後、 Azure API Management を使用して、マイクロサービスを内部および外部で使用するための API として発行できます。 この記事では、API Management を使用して AKS マイクロサービス ベースのアーキテクチャを API として発行するためのオプションについて説明します。 Kubernetes、API Management、Azure ネットワークに関する基本的な知識を前提としています。
バックグラウンド
マイクロサービスを使用するための API として発行する場合、マイクロサービスとそれらを使用するクライアント間の通信を管理するのは困難な場合があります。 横断的な問題には、認証、承認、調整、キャッシュ、変換、監視が含まれます。 これらの問題は、マイクロサービスが内部クライアントと外部クライアントのどちらに公開されているかに関係なく適用されます。
API ゲートウェイ パターンによって、これらの問題に対処します。 API ゲートウェイは、マイクロサービスのフロント ドアとして機能し、マイクロサービスからクライアントを切り離し、セキュリティの別の層を追加し、横断的な問題を処理する負担を取り除くことでマイクロサービスの複雑さを軽減します。
API Management は、API ゲートウェイのニーズを解決するためのターンキー ソリューションです。 時間をかけずに、マイクロサービス用の一貫性のある最新のゲートウェイを作成し、マイクロサービスを API として公開することができます。 完全ライフサイクル API 管理ソリューションとして、API 検出、API ライフサイクル管理、API 分析用のセルフサービス開発者ポータルなど、追加の機能も提供します。
AKS と API Management を一緒に使用すると、マイクロサービス ベースの API のデプロイ、公開、セキュリティ保護、監視、管理を行うためのプラットフォームが提供されます。 この記事では、API Management と組み合わせて AKS をデプロイするためのいくつかのオプションについて説明します。
Kubernetes Services と API
Kubernetes クラスターでは、コンテナーはポッドにデプロイされます。ポッドは一時的なもので、ライフサイクルがあります。 ワーカー ノードが失敗すると、ノードで実行されているポッドは失われます。 そのため、ポッドの IP アドレスはいつでも変更できます。 ポッドとの通信に依存することはできません。
この問題を解決するため、Kubernetes にはサービスの概念が導入されています。 Kubernetes Service は、ポッドの論理グループを定義し、それらのポッドの外部トラフィックの露出、負荷分散、およびサービス検出を可能にする抽象化レイヤーです。
API Management を使用してマイクロサービスを API として発行する準備ができたら、Kubernetes のサービスを API Management の API にマップする方法を検討する必要があります。 このマッピングには、設定された規則はありません。 最初に、ビジネス機能またはドメインをマイクロサービスに設計およびパーティション分割した方法によって異なります。 たとえば、サービスの背後にあるポッドが特定のリソース (Customer など) に対するすべての操作を担当する場合は、サービスを 1 つの API にマップできます。 リソースに対する操作が複数のマイクロサービス (GetOrder や PlaceOrder など) にパーティション分割されている場合は、API Management で複数のサービスを 1 つの API に集約できます。 (次の図を参照)。
マッピングも進化する可能性があります。 API Management はマイクロサービスの前にファサードを作成するため、マイクロサービスを時間の経過と同時にリファクタリングして適切なサイズにできます。
AKS の前面に API Management をデプロイする
AKS クラスターの前に API Management をデプロイするためのオプションがいくつかあります。
AKS クラスターは常に仮想ネットワークにデプロイされますが、API Management インスタンスは必ずしも仮想ネットワークにデプロイされるとは限りません。 API Management がクラスター仮想ネットワーク内に存在しない場合、AKS クラスターは、接続する API Management のパブリック エンドポイントを発行する必要があります。 その場合は、API Management と AKS の間の接続をセキュリティで保護する必要があります。 言い換えると、クラスターにアクセスできるのは API Management を通じてのみであることを確認する必要があります。 次のセクションでは、AKS の前に API Management をデプロイするためのオプションについて説明します。
オプション 1: サービスをパブリックに公開する
NodePort、LoadBalancer、または ExternalName サービスの種類を使用して、AKS クラスター内のサービスをパブリックに公開できます。 その場合、サービスはパブリック インターネットから直接アクセスできます。 クラスターの前に API Management をデプロイした後、マイクロサービスで認証を適用して、すべての受信トラフィックが API Management を通過することを確認する必要があります。 たとえば、API Management では、クラスターに対して行われる各要求にアクセス トークンを組み込むことができます。 各マイクロサービスは、要求を処理する前にトークンを検証する必要があります。
このオプションを使用すると、特にマイクロサービスに認証ロジックが既に実装されている場合に、AKS の前に API Management をデプロイする最も簡単な方法が提供される場合があります。
長所:
- API Management をクラスター仮想ネットワークに挿入する必要がないため、API Management 側での簡単な構成
- サービスが既に公開されていて、認証ロジックがマイクロサービスに既に存在する場合、AKS 側を変更する必要はありません
短所:
- エンドポイントがパブリックに可視化されるため、潜在的なセキュリティ リスクが発生する
- 受信クラスター トラフィックのエントリ ポイントが 1 つ作成されない
- 重複する認証ロジックでマイクロサービスが複雑になります
オプション 2: イングレス コントローラーをインストールする
オプション 1 の方が簡単かもしれませんが、前述のように、顕著な欠点があります。 API Management インスタンスがクラスター仮想ネットワークに存在しない場合、相互 TLS 認証 (mTLS) は、API Management インスタンスと AKS クラスターの間の双方向でトラフィックがセキュリティで保護され、信頼されるようにするための堅牢な方法です。
相互 TLS 認証は、API Management によって ネイティブにサポートされます 。 イングレス コントローラーをインストールすることで、Kubernetes で有効にすることができます。 (次の図を参照)。その結果、認証はイングレス コントローラーで実行され、マイクロサービスが簡略化されます。 さらに、専用 IP アドレスをサポートするサービス レベルでは、API Management の IP アドレスをイングレス 許可リストに追加して、API Management のみがクラスターにアクセスできるようにします。
長所:
- API Management をクラスター仮想ネットワークに挿入する必要がないため、API Management 側で簡単に構成できます。mTLS はネイティブにサポートされています
- イングレス コントローラー レイヤーでの受信クラスター トラフィックの保護を一元化する
- 公開さるクラスター エンドポイントが最小になるので、セキュリティ リスクが軽減されます
短所:
- イングレス コントローラーをインストール、構成、保守し、mTLS に使用される証明書を管理する必要があるため、クラスター構成の複雑さが増します。
- API Management Standard v2 または Premium レベルを使用しない限り、イングレス コントローラー エンドポイントがパブリックに可視化されるため、セキュリティ リスクが追加されます
API Management を使用して API を発行する場合、サブスクリプション キーを使用してこれらの API へのアクセスをセキュリティで保護するのは簡単で一般的です。 公開された API を使用する必要がある開発者は、これらの API を呼び出すときに、有効なサブスクリプション キーを HTTP 要求に含める必要があります。 そうしないと、呼び出しは API Management ゲートウェイによってすぐに拒否されます。 バックエンド サービスには転送されません。
API にアクセスするためのサブスクリプション キーを取得するには、開発者にサブスクリプションが必要です。 サブスクリプションは、基本的にサブスクリプション キーのペアの名前付きコンテナーです。 公開されている API を使用する必要がある開発者は、サブスクリプションを取得できます。 API パブリッシャーからの承認は必要ありません。 API の公開元は、API ユーザー用のサブスクリプションを直接作成することもできます。
オプション 3: クラスター仮想ネットワーク内に API Management をデプロイする
場合によっては、規制上の制約や厳密なセキュリティ要件を持つお客様は、一般に公開されているエンドポイントのためにオプション 1 と 2 を使用できない場合があります。 他の場合、AKS クラスターとマイクロサービスを使用するアプリケーションは同じ仮想ネットワーク内に存在する可能性があるため、すべての API トラフィックが仮想ネットワーク内に残るため、クラスターをパブリックに公開する理由はありません。 これらのシナリオでは、API Management をクラスター仮想ネットワークにデプロイできます。 API Management Developer、Premium、Premium v2 (プレビュー) レベルでは、 クラスター仮想ネットワークへの挿入がサポートされます。
仮想ネットワークへの API Management のデプロイには、外部と内部の 2 つのモードがあります。 現在、外部モードは、API Management のクラシック レベルでのみ使用できます。
API コンシューマーがクラスター仮想ネットワークに存在しない場合は、外部モードを使用する必要があります。 (次の図を参照)。このモードでは、API Management ゲートウェイはクラスター仮想ネットワークに挿入されますが、外部ロード バランサー経由でパブリック インターネットからアクセスできます。 このアーキテクチャは、外部クライアントがマイクロサービスを使用できるようにしながら、クラスターを完全に隠すのに役立ちます。 さらに、ネットワーク セキュリティ グループ (NSG) などの Azure ネットワーク機能を使用して、ネットワーク トラフィックを制限できます。
すべての API コンシューマーがクラスター仮想ネットワーク内に存在する場合は、内部モードを使用できます。 (次の図を参照)。このモードでは、API Management ゲートウェイはクラスター仮想ネットワークに挿入され、内部ロード バランサーを介してこの仮想ネットワーク内からのみアクセスできます。 パブリック インターネットから API Management ゲートウェイまたは AKS クラスターに到達する方法はありません。
いずれの場合も、AKS クラスターはパブリックに表示されません。 オプション 2 とは異なり、イングレス コントローラーは必要ない場合があります。 シナリオと構成によっては、API Management とマイクロサービスの間でやはり認証が必要になる場合があります。 たとえば、サービス メッシュを使用する場合は、常に相互 TLS 認証が必要です。
長所:
- AKS クラスターにパブリック エンドポイントがないため、最も安全なオプションを提供します
- パブリック エンドポイントがないため、クラスターの構成が簡略化されます
- 内部モードを使用して、仮想ネットワーク内で API Management と AKS の両方を非表示にする機能を提供します
- NSG などの Azure ネットワーク機能を使用してネットワーク トラフィックを制御する機能を提供します
短所:
- 仮想ネットワーク内で動作するように API Management をデプロイおよび構成する複雑さが増します