API Gatewayとサービスメッシュを使い分けよう
永遠のテーマAPI Gatewayとサービスメッシュの使い分け！
説明に挑戦してみましょう。挑戦ですのでコメント歓迎です。
今回ハイライトしたいのは特にサービスメッシュのルーティングや認可などの、機能比較でいうとAPI Gatewayと似た機能の部分です。
サービスメッシュとは
サービスメッシュを知らない方は「各サービスに配置するリバースプロキシみたいなの」と考えていただくとイメージがつかみやすいです。(実際にはこの説明では雑すぎて詳しい人には怒られます。)
ルーティングの制御
セキュアなHTTP通信の担保
HTTP通信品質の対策 (HTTPタイムアウト対策やサーキットブレーカーなど)
認可
とこう書くとAPI Gatewayと似ているので混乱する方が多いんです。
海外のカンファレンスなどでもAPI Gatewayとサービスメッシュの違いなどは頻繁に触れられる話題だったりします。
サービスメッシュの説明を読んで違いを考えましょう。
最初の部分から位置付けを引用すると
オープンソース・プロジェクトの Istio を始めとするサービスメッシュは、アプリケーションのさまざまな部分が互いにデータをどのように共有するかを制御する方法です。
かつ
サービスメッシュはアプリケーションに直接組み込まれた専用インフラストラクチャ層であり、この点は同様に通信を管理するその他のシステムとは異なります。
この「アプリケーションに直接組み込まれた」というのがポイント。
API Gatewayは端的にいうと他のシステムとの間の責任分界点を明確にするためのものです。
サービスメッシュはそうではなく、アプリケーションの一部になってマイクロサービスアーキテクチャ内の連携を補佐するためのものです。
ではどう使い分けるか、という話をする前に、なんでこんな機能が求められたのか、少し背景を想像してみましょう。
そうするとすんなり理解できます。
API Gatewayのジレンマ
API Gatewayの持つべき責務はこちらに書きました。
この先の内容に必要な分だけ簡単にご紹介すると、
API Gatewayにはインテグレーションサービスのソリューション (Camelなど) と一体型のものと、分離されたものがあるよ
なぜ分離されたものが出てきたかというと、APIの利活用が進む中でAPI Gatewayが複数システムを後ろに抱えることになり、会社標準のAPIセキュリティを考えなければいけなくなったからだよ
分離することでAPI Gatewayチームは会社標準を考え、インテグレーションサービスチームはシステムのAPIのユーザビリティに特化できるようになったよ
さてこの文脈で改めてAPI Gatewayの役割を眺めてみてください。ポイントは会社標準かアプリケーション固有かです。
認証 (SSOのSP/RP側の役割も含め)
APIプラン (クライアントごとのアクセス可能範囲の定義)
URLごと、HTTPメソッドごとの認可
URLごとの流量制御
これおかしくないですか?
URLごと、HTTPメソッドごとの認可
これはバックエンドのアプリケーションや保持するデータの特性から定義されるもので、完全にアプリケーション固有の文脈なんです。
前の記事には書きませんでしたが、APIのバージョン並行稼働を可能にするルーティングルールの定義なんかもAPI Gatewayでもサービスメッシュでもできるのですが、これもどちらかというとアプリケーション固有の文脈の話ですよね。
ではこれら認可やルーティングルールをAPI Gateway側に実装すると想定し、チーム間にどんなインタラクションが必要か想像しましょう。
インテグレーションチームあるいはバックエンドのシステム側がAPI Gatewayに適用したい設定をまとめる
API Gatewayチームに作業依頼
API Gatewayチームで実装
リクエスト元チームで動作確認
トラブル発生時の切り戻しの準備その他当日対応
さてこれらは以下のリスクがあります。
依頼してどのくらいで対応してもらえるでしょうか
作業依頼内容の記述ミス
作業結果の正確性
トラブル発生時の切り戻しのスピード感
典型的なプロセスの問題はチーム間のハンドオーバーにあるんです。
これでは開発したもののリリースできるスピードに大きく影響を与えます。
サービスメッシュでジレンマを解消しよう
これを発生させずに認可やルーティングルールを実装するにはどうしたらいいでしょうか。
バックエンドの開発者が直接設定できるようにしたらいいじゃないか！
というのがサービスメッシュの発想です。
ではこれでAPI Gatewayとサービスメッシュの使い分けの原則が分かったんじゃないでしょうか。
会社標準として定義するものは原則API Gateway、アプリケーションの都合で定義するものは原則としてサービスメッシュと考えます。
使い分けガイドラインを決める=開発者に委譲したい部分を決める
とはいえ少し不安が残る部分がありますよね。
例えばAPIのバージョンごとに適切なPodやサービスにHTTPリクエストがルーティングされるようにルーティングルールを作成する部分をAPI Gatewayチーム側でやりたい組織はおそらく少ないでしょう。API Gatewayチームは言われた通りに実装するしかなく、実装の結果意図した通りに動いているか確認できるのは開発者です。であれば一番正解をわかっている人が直接定義できるのが望ましいです。
ではマイクロサービスが持つ情報資産へのアクセスをRBACやABAC、スコープなどで制限する部分はどうですか?
元々の要件は開発者側から来るものではありますが、万が一これらが誤って削除されてしまった時のインパクトを考えると日々開発者が触れる部分にこれらの定義があると不安になることがあるかもしれません。
CI/CDパイプラインがきっちりしていれば、設定ミスをしたのであればテストで引っかかるからAPI Gatewayよりむしろ安全だ！と言えるかもしれません。
組織の現状において何がベストかを考えてルール化することをおすすめします。
考え方に迷ったら、Scaled Agileの意思決定の分散化の分析用マトリックスを使ってみるのはいかがでしょうか。
サイトから画像を引用します。
これは意思決定の権限を委譲するときの分析方法として紹介されているものです。
なんらかの決定権限を、頻度 (Frequency)、緊急度 (Time Critical)、および影響度 (Economics of scale) でスコアリングすることで素案を作るものです。
サービスメッシュの場合もどんな時にサービスメッシュが使えるかをDecisionsのところに書き出し、頻度 (定義の更新頻度)、緊急度 (急いで反映したい場合および切り戻しを急ぎたい場合)、および影響度 (万が一ミスが起こったときのインパクト) などをスコアリングすることで素案を作ることができるかと思います。
素案が出たら議論をしながら調整するだけです。
定着支援はきちんと計画を！
開発者がサービスメッシュを使いこなせるようになるにはハードルがあります。残念ながらこう言った便利なツールがあればみんなが勝手に使ってくれるわけではありません。
みなさん自分が想像できて自信を持ってできると言い切れるものを使うんです。自信を持ってサービスメッシュが使えると言えるようになるまではサポートが必要です。
「今日からサービスメッシュ使い始めます！」という開発チームと、「もう5年使ってるしどの設定をするときはどうYAML書けばいいか調べなくてもわかるよ」な開発チームとでは使える範囲も粒度も大きく異なります。
プラットフォームチームからの支援などをもらいつつ、定着支援を実施することを強くお勧めします。