一般記事

APIゲートウェイとサービスメッシュの違い

この記事を読むのに必要な時間:およそ 6 分

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

注:この説明の後に,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つ以上の製品に上記のすべての処理を実装するバンドルされたソリューションを提供します。

著者プロフィール

Marco Palladino

発明者,ソフトウェア開発者および企業家。非常に幅広く採用されているオープンソースAPIプラットフォーム,Kongの共同創立者兼CTO。

Kong社について:
Kongは,APIゲートウェイとサービスメッシュ製品をKong GatewayとKumaで提供。どちらの製品もオープンソースで無料でダウンロード可能。

Kongは,スタートアップ企業からFortune 500にランクされる大企業まで,テクノロジチームが特定のアーキテクチャに依存することなく最新のソフトウェアアーキテクチャとクラウドアプリケーションを接続できる,最先端のサービスコントロールプラットフォームを提供。Kongの顧客は,Cargill,WeWork,SoulCycle,Yahoo! Japan,VerifoneおよびJust Eatを含む,さまざまな分野にわたっている。