なぜAPIマネジメントとサービスメッシュは異なるユースケースを補完するパターンなのか

長年にわたり、APIマネジメント（APIM）とAPIゲートウェイは、データセンターの内部と外部の両方で最近のAPIユースケースを実装するために使用されてきた主要テクノロジでした。APIゲートウェイテクノロジは、業界で「フルライフサイクルAPI管理」と呼ばれる、より大きく包括的なユースケースを獲得し、この10年の間に大きく発展しました。このテクノロジは、リクエストのデータプレーンのAPIトラフィックを接続し、安全にして管理するランタイムだけでなく、より広い意味でAPIの作成、テスト、文書化、マネタイズ、モニタリングおよび全体的な公開を可能にする一連の機能であり、最初から最後まで幅広いユーザーペルソナを対象としています。つまり、（⁠RESTfulまたはそうでない）APIの公開と利用を可能にするネットワークランタイムの管理だけでなく、ユーザーおよび顧客に製品としてのAPIを作成して提供するフルライフサイクルがあります。

その後2017年頃に、業界から別のパターンであるサービスメッシュが登場しました。その直後から、業界はこのパターンとAPIゲートウェイパターンの利用方法を正しく把握することに失敗し、大きな混乱が始まりました。これは、既存のAPIMベンダーのリーダーシップの欠如により、サービスメッシュが既存のAPIMユースケースをどのように補完するか適切に提示できなかったことが原因でした。サービスメッシュは大手クラウドベンダー（Google、Amazon、Microsoft）により広範な業界への販売が開始され、この新しいパターンの開発者マーケティングは実際のメインストリームユーザーの採用よりも先行したため、実際に存在したサービスメッシュ（開発者マーケティング）と存在しなかったサービスメッシュ（テクノロジの実装）について業界で誤解が生じたことも原因です。さまざまな人がこの新しいパターンについて話題にしましたが、正しく理解していた人はごくわずかでした。

時間とともに、テクノロジの実装はサービスメッシュの本来の構想に追い付き、多くのユーザーがパターンを実装して利用するようになりました。その結果、サービスメッシュであるもの（とないもの）およびサービスメッシュの世界観におけるAPIゲートウェイ（およびAPIM）の役割について理論的に説明できるようになりました。

多くの人々が既にAPIゲートウェイとサービスメッシュの違いについての説明を試みており、APIゲートウェイはNorth-Southトラフィックを扱いサービスメッシュはEast-Westトラフィックを扱う、と一般に伝えられています。この説明は正確ではなく、逆に、両方のパターンの根本的な誤解を強調しています。

ここでは、APIゲートウェイとサービスメッシュの違いと、これらのパターンを使用するケースについて実際的および客観的に説明します。

APIゲートウェイ

APIゲートウェイパターンは、すべてのリクエストが基本的なAPIを利用するために経由する必要があるネットワークの追加のホップについて記述します。この意味から、APIゲートウェイを集中型デプロイと呼ぶ人もいます。

すべてのAPIリクエストの実行パスで、APIゲートウェイはクライアントからのリクエストを受信するデータプレーンであり、それらのリクエストを基本的なAPIに最終的にリバースプロキシする前にトラフィックポリシーやユーザーポリシーを施行できます。また、元のクライアントにリクエストをプロキシする前に、基本的なAPIから受け取った応答にポリシーを（ほとんどのケースで）施行できます。

APIゲートウェイでは、ビルトインコントロールプレーンでデータプレーンが行うことを管理して構成するか、データプレーンとコントロールプレーンの両方を同じプロセスにバンドルできます。個別のコントロールプレーンを利用するほうが良いのは確かですが、我々がデプロイするAPIゲートウェイノードの数は管理可能なサイズであることが多く、既存のCI/CDパイプラインで更新を行うことができたため、一部のAPIゲートウェイ実装ではデータプレーンとコントロールプレーンを同じプロセスにバンドルしました。

APIゲートウェイは、クライアントやAPIから分離された独自のインスタンス（独自のVMホストまたはPod）でデプロイされます。残りのシステムから完全に分離され、独自のアーキテクチャ層で動作するため、APIゲートウェイのデプロイは非常に単純です。

APIゲートウェイは、通常、内部と外部のサービスコネクティビティの両方およびNorth-South（データセンターの外部の）トラフィックとEast-West（データセンターの内部の）トラフィックの両方について3つの主要APIユースケースをカバーします。

1．製品としてのAPI

最初のユースケースは、他の開発者、パートナーまたはチームが利用する製品としてAPIをパッケージします。 構築するクライアントアプリケーションは、組織の外部（モバイルアプリケーションなど）からまたは同じ会社の内部（別のチームや別の事業部門により構築された別の製品など）からのリクエストを開始できます。いずれにしても、クライアントアプリケーションは利用している（APIを公開している）製品の範囲の外部で動作します。

製品としてAPIを提供する場合、APIゲートウェイはクライアントからAPIサービスへのリクエストを管理する一般的な要件（認証/認可ユースケース、帯域制限、開発者オンボーディング、マネタイズやクライアントアプリケーションガバナンスなど）を含みます。これらは、ユーザーがどのようにAPI製品を使用するかポリシーが管理する、基本的なプロトコルの管理の範囲をはるかに超えるL7ユーザーポリシーにより実装される高レベルのユースケースです。

APIゲートウェイにより公開されるAPIはHTTPプロトコル（REST、SOAP、GraphQL、gRPCなど）で動作し、クライアントアプリケーションがデータセンターの内側で動作する場合はNorth-Southトラフィック、外側で動作する場合はEast-Westトラフィックになります。モバイルアプリケーションはAPIゲートウェイに対してNorth-Southトラフィックを実行しますが、利用しているAPIと同じデータセンターにデプロイされている組織内の別の製品はEast-Westトラフィックを実行します。トラフィックの向きは基本的に無関係です。

APIゲートウェイは、利用するクライアントを更新することなく時間とともに基本的なAPIを変更できる抽象化層としても使用されます。これは、クライアントアプリケーションが組織の外部の開発者により構築され、最新のAPIへの更新を決定しても更新を強制できないシナリオで特に重要です。この場合は、APIゲートウェイを使用することにより、基本的なAPIが時間とともに変化しても、クライアントアプリケーションとの下位互換性を維持できます。

2．サービスコネクティビティ

2つ目のユースケースは、クライアントとAPIゲートウェイ間およびAPIゲートウェイとAPI間のネットワークトラフィックを接続し、安全にし、暗号化し、保護して観察するネットワークポリシーを施行します。これらのポリシーは、ユーザーエクスペリエンスをコントロールするのではなく、基本的なネットワークトラフィック上で動作するため、L7トラフィックポリシーと呼ばれます。

リクエストがAPIゲートウェイで処理されると、ゲートウェイ自身が基本的なAPIにリクエストを行い応答を得る必要があります（ゲートウェイは結局のところリバースプロキシです⁠）⁠。通常は、相互TLSによりリクエストを安全にし、リクエストを記録して、ネットワーク通信を全面的に保護して観察します。ゲートウェイはロードバランサの役割も果たし、HTTPルーティングのような機能を実装して、異なるバージョンのAPIへのリクエストのプロキシ（Blue/Greenデプロイおよびカナリアデプロイユースケースも可能）およびフォールトインジェクションなどをサポートします。

APIゲートウェイは、利用可能なインターフェイスを公開している限り、それらがどのように構築されるか想定しないため、APIゲートウェイで公開している基本的なAPIは任意のアーキテクチャ（モノリシックまたはマイクロサービス）で構築できます。ほとんどの場合、APIはHTTPプロトコル（REST、SOAP、GraphQL、gRPCなど）で利用可能なインターフェイスを公開しています。

3．フルライフサイクルAPI管理

APIゲートウェイの3つ目のユースケースはAPI管理の広範なコンテキストの大きなパズルの1ピースです。

API、ユーザーとクライアントアプリケーション、実行時のトラフィックの管理は、API戦略を成功させるために必要な多くのステップの一部にすぎません。APIは、作成し、文書化し、テストしてモックにする必要があります。実行した後は、APIを監視および観測して、異常な使用法を検出する必要があります。さらに、製品としてAPIを提供する場合、エンドユーザーがアプリケーションを登録し、認証情報を取得してAPIの利用を開始するポータルをAPIが提供する必要があります。

エンドツーエンドでAPIライフサイクルのさまざまなポイントに関わる（そして異なるペルソナがライフサイクルの異なる部分を担当する）この広範なエクスペリエンスは、フルライフサイクルAPI管理と呼ばれ、ほとんどのAPIMソリューションはAPIゲートウェイに接続してポリシーを施行する1つ以上の製品に上記のすべての処理を実装するバンドルされたソリューションを提供します。

サービスメッシュ

サービスメッシュでは、システムで実行している2つ以上のサービス間のコネクティビティを構築する方法を根本的に改善するパターンを特定します。サービスが別のサービス（例えば、データベースを利用するモノリスや別のマイクロサービスを利用するマイクロサービス）にネットワークリクエストを送信するたびに、リクエストを安全かつ観測可能にすることにより、そのネットワークリクエストに対処します。

パターンとしてのサービスメッシュは、（⁠モノリシックやマイクロサービス指向の）任意のアーキテクチャおよび任意のプラットフォーム（VM、コンテナ、Kubernetesなど）に適用できます。

この点で、サービスメッシュは新しいユースケースを追加しませんが、サービスメッシュを導入する前に管理していた既存のユースケースを適切に実装できます。サービスメッシュを実装する前も、アプリケーションチームはセキュリティ、可観測性、エラー処理などのトラフィックポリシーをアプリケーション内に実装して、アプリケーションが送信または受信するアウトバウンドまたはインバウンドのネットワークリクエストのコネクティビティを強化していました。アプリケーションチームは、自身のサービスで多くのコードを記述することにより、これらのユースケースを実装していました。つまり、異なるチームが異なるプログラミング言語で何度も繰り返して同じ機能を実装して、組織にネットワークコネクティビティの管理における断片化とセキュリティリスクをもたらしていたのです。

サービスメッシュパターンでは、任意のサービス（構築したサービスだけでなくデプロイしたサードパーティのサービスを含む）により行われたインバウンドまたはアウトバウンドのリクエストのネットワーク管理を、すべてのインバウンドおよびアウトバウンドのネットワークリクエストを管理するアウトプロセスアプリケーション（プロキシ）にアウトソーシングしています。プロキシはサービスの外部に存在するため、任意の言語またはフレームワークで記述された任意のサービスをサポートします。プロキシはすべてのリクエストの実行パス上にあるため、データプレーンプロセスです。ユースケースの1つはエンドツーエンドでmTLS暗号化と可観測性を実装するため、プロキシの1つのインスタンスをすべてのサービスとともに実行して、アプリケーションチームが余分な作業を行うことなく、これらの機能をシームレスに実装できるようにします。

データプレーンプロキシはすべてのサービスのすべてのレプリカとともに実行されるため、サービスメッシュを（集中型デプロイのAPIゲートウェイパターンと対比して）分散型デプロイと呼ぶ人もいます。ネットワークにホップを追加してレイテンシを最小限に抑えるため、実行しているサービスと同じマシン（VM、ホスト、Pod）でデータプレーンプロキシを実行します。理想的には、プロキシのメリットが十分あり、レイテンシが十分低い場合、組織にサービス間のネットワークコネクティビティの管理における断片化をもたらすよりも、プロキシを利用するほうを選択すべきです。

プロキシアプリケーションは、リクエストが発信の場合はプロキシとして機能し、リクエストが着信の場合はリバースプロキシとして機能します。サービスの各レプリカでプロキシアプリケーションの1つのインスタンスを実行するため、システムでは多くのプロキシを実行することになります。これらをすべて構成するには、施行する構成と動作の真実を語る資料として機能し、プロキシに接続して構成を動的に伝えるコントロールプレーンが必要です。コントロールプレーンはプロキシにのみ接続するため、サービス間のリクエストの実行パス上にはありません。

サービスメッシュパターンは、すべてのサービスの各インスタンスにデータプレーンプロキシをデプロイし、アプリケーションをデプロイするとき実質的にCI/CDジョブを更新する必要があるため、APIゲートウェイパターンよりも処理が多くなります。サービスメッシュには他のデプロイパターンもありますが、最高の可用性を保証し、すべてのサービスのすべてのレプリカに一意のIDを（mTLS証明書で）割り当てることができる上記のパターン（サービスレプリカあたり1つのプロキシ）が業界標準と見なされています。

サービスメッシュでは、基本的に1つの主要ユースケースに対処しています。

1．サービスコネクティビティ

ネットワーク管理をサードパーティのプロキシアプリケーションにアウトソーシングすることにより、チームは独自のサービスにネットワーク管理を実装する必要がなくなります。プロキシを利用して、組織が採用しているがゼロから構築していないデータベースなどのサードパーティのサービスを含む、デプロイするすべてのサービスとワークロードに、相互TLS暗号化、ID、ルーティング、ロギング、トレーシング、ロードバランシングなどの機能を実装できます。

組織内のサービスコネクティビティは多くのプロトコルで実行されるため、完全なサービスメッシュの実装はHTTPだけでなく他のTCPトラフィックも（North-SoutまたはEast-Westに関係なく）理想的にサポートします。サービスメッシュは広範なサービスをサポートしてL4/L7トラフィックポリシーを実装しますが、APIゲートウェイはこれまでL7ポリシーにのみ焦点を当ててきました。

概念的には、サービスメッシュはシステムで動作しているワークロードの非常に単純なビューですが、すべてがサービスであり、サービスは互いに対話できます。APIゲートウェイはリクエストを受信および送信するサービスでもあるため、APIゲートウェイはメッシュ内のサービス間の1つのサービスと言えます。

すべてのサービスのすべてのレプリカにはデータプレーンプロキシが必要です。データプレーンプロキシは実質的にロードバランサであり、他のプロキシ（他のサービス）への発信リクエストをルーティングできるため、L4/L7ルーティング機能を実行できるようにサービスメッシュのコントロールプレーンは各プロキシのアドレスを知っている必要があります。アドレスは、サービス名などの任意のメタデータに関連付けることができます。そうすることにより、サービスメッシュはサードパーティのソリューションを必要としないビルトインサービスを本質的に提供します。サービスディスカバリツールはメッシュの外部の通信には使用できますが、メッシュの内部のトラフィックには使用できません。

APIゲートウェイ対サービスメッシュ

ユースケースを見ると、APIゲートウェイとサービスメッシュの間に重複する領域があり、それがサービスコネクティビティユースケースであることが分かります。

サービスメッシュが提供するサービスコネクティビティ機能は、APIゲートウェイが提供するAPIコネクティビティ機能と競合しています。しかし、サービスメッシュにより提供される機能はより包括的（L4+L7、すべてのTCPトラフィック、HTTPやAPIだけでなくすべてのサービス）であるため、ある意味、より完全です。しかし、上の図から分かるように、サービスメッシュで提供されないユースケースもあります。「⁠製品としてのAPI」ユースケースとフルライフサイクルAPI管理はAPIゲートウェイパターンに属しています。

サービスメッシュは広範なユースケース（L4+L7）のサービスコネクティビティ要件をすべて提供するため、APIゲートウェイ（L7のみ）の事項を引き継ぐと考えるのは当然です。この結論はサービスメッシュデプロイモデルを利用できる場合にのみ当てはまるものです。これから説明するように、常にそうとは限りません。

2つのパターン間の重要な相違点はデプロイモデルです。サービスメッシュパターンでは、プロキシデータプレーンをすべてのサービスのすべてのレプリカとともにデプロイする必要があります。チームが独自の製品または事業部門の範囲内でサービスメッシュをデプロイする場合は特に問題ありませんが、範囲外にプロキシをデプロイする場合は次の理由により実装が難しくなります。

1. 異なる製品、チーム、事業部門でソフトウェアの構築、実行およびデプロイの方法が根本的に異なる場合、プロキシアプリケーションを組織内のすべての製品のすべてのサービスとともにデプロイしようとすると反対されることがあります。
2. すべてのデータプレーンプロキシはコントロールプレーンとの接続を開始する必要がありますが、組織の製品、チームまたは事業部門の境界の外部にデプロイされたサービスからコントロールプレーンへのアクセスが許可されない場合やアクセスができない場合もあります。
3. 組織の外部の開発者、顧客またはパートナーにより構築されたサードパーティアプリケーションの場合、すべてのサービスをコントロールできないため、データプレーンプロキシをすべてのサービスとともにデプロイすることは不可能です。
4. 同じサービスメッシュでデプロイされたサービスは、互いに利用する有効なTLS証明書を提供するために同じCA（認証局）を使用する必要がありますが、異なる製品やチームに属するサービス間でのCAの共有は不可能な場合や望ましくない場合があります。この場合は、中間のAPIゲートウェイ経由で互いに通信できる2つの（それぞれ独自のCAを使用する）サービスメッシュを作成します。

APIゲートウェイとサービスメッシュはさまざまなユースケースに焦点を当てています。ほとんどの組織では製品/ユーザーとサービスコネクティビティの両方のユースケースを実装する必要があるため、両方のユースケースが使用されると仮定して、APIゲートウェイを使用するかサービスメッシュを使用するか判断するチートシートを用意しました。

チートシート

APIゲートウェイは、分岐ポイント経由で内部または外部のクライアント/ユーザーに「製品として」APIを提供し、フルライフサイクルAPIMプラットフォーム経由でどのように公開およびオンボーディングされるか管理する場合に使用します。クライアントと基本的なAPIの間の抽象層を作成する場合にも使用します。

サービスメッシュは、すべてのサービスで採用および施行できる分散型サイドカーデプロイ経由で、システムで実行しているすべてのサービス間で信頼性があり、安全で観測可能なL4/L7トラフィックコネクティビティを構築する場合に使用します。すべてのサービスの2地点間のコネクティビティを作成する場合にも使用します。

ほとんどの場合、組織は両方のユースケースを使用するため、APIゲートウェイとサービスメッシュが同時に使用されます。

例：金融機関

上記の図から、次の例を考えてみましょう。

1つの組織に異なる製品を構築する異なるチームが存在することは非常に一般的であり、これらの製品間で情報をやり取りすることもよくあります。この金融機関には銀行業務を扱う「銀行製品」と株式市場の取引を扱う「取引製品」があり、2つの製品間で情報を共有するために互いに通信する必要があります。

これらのチームは、製品を構築しているサービス間のサービスコネクティビティを向上するため、ロードマップのあるポイントでサービスメッシュを実装することを決定します。異なるチームが異なる速度で実行するため、2つの「サービスメッシュA」と「サービスメッシュB」を実装します。

高可用性になるように、両方の製品が2つの異なるデータセンター「DC1」と「DC2」にデプロイされていると仮定します。

銀行チームは銀行内の顧客、取引チームに製品としてサービスを提供するため、オンボーディングするチームが内部APIゲートウェイを経由する外部ユーザーであるかのようにポリシーをセットアップします。両方の製品を利用するモバイルチームも、エッジAPIゲートウェイ経由で利用する必要があります。アーキテクチャは次のようになります。

APIゲートウェイはメッシュの一部であることに注意してください。メッシュの一部でないと、メッシュ内でサービスを利用できるID（TLS証明書）が提供されません。これまで説明したように、APIゲートウェイはネットワークリクエストを送信および受信できるサービス間の1つのサービスにすぎないのです。

参照記事：

The Difference Between API Gateways and Service Mesh

翻訳：エクセルソフト株式会社（えくせるそふとかぶしきがいしゃ）

エクセルソフト株式会社は、ソフトウェア開発ツールを中心に、世界中の優れたソフトウェアを日本およびアジアにおいて販売しています。エンタープライズ向けにモダンアーキテクチャのためのサービスコントロールプラットフォームを提供するKongを含む幅広い製品を提供し、今日のコンピューター ユーザーの多様なニーズに応えています。Kong製品の詳細、価格、ライセンス体系、デモの依頼などについては、お気軽にお問い合わせください。エクセルソフト株式会社はKongのGold Partnerです。