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

概要と動機

一つのプログラムを多くのサービスに分割した瞬間、新しい問いが現れます。サービス間のトラフィックと、外から入ってくるトラフィックを、誰が管理するのか。この問いには、悪い答え方があります。認証、リトライ、タイムアウト、レート制限、ログといった同じ関心事を、手作業ですべてのサービスに散らすこと。良い答え方もあります。それらの関心事を、すべてのサービスが無料で引き継ぐ共有の層に押し込むこと。本章は、そのような二つの層についてです。APIゲートウェイは玄関口にあり、クライアントから入ってくるトラフィックを管理します。サービスメッシュはサービスの間にあり、それらの間を流れるトラフィックを管理します。両者は関連する問題を異なる場所で解決し、二つを混同することは、よくある高価な間違いです。

業界は、トラフィックの二つの方向を羅針盤の比喩で名付けています。南北のトラフィックは、システムの境界を越えるトラフィックです。モバイルアプリ、ブラウザ、呼び込むパートナー。東西のトラフィックは、システムの内側に留まるトラフィックです。一つのリクエストを満たすために、サービスAがサービスBを呼び、サービスBがサービスCを呼ぶ。APIゲートウェイは南北の専門家で、サービスメッシュは東西の専門家です。その区別を鋭く保つことが、本章で最も有用な単一の考えです。それがどの道具がどの方針を所有するかを教え、同じ仕事を二度することを防ぐからです。

大きなチームにとって、これらの層は、方針を百回ではなく一度だけ徹底する方法です。認証、転送中の暗号化、レート制限が共有の層にあるとき、セキュリティの修正は、百のバックログを待つのではなく、層をデプロイした日にすべてのサービスに出荷されます。企業と政府の設定では、その集中こそがしばしば要点です。監査人は、アクセスが確認され、トラフィックが暗号化される、単一の証明可能な場所を求め、共有のゲートウェイやメッシュは、まさにその方針の徹底点を与えます。本章は、3.2章のアーキテクチャスタイル、3.3章の分散システムの現実、3.13章のネットワーキングの基礎の上に築かれ、それらを、誰がトラフィックを扱うかについての具体的な指針に変えます。

主要原則

南北(ゲートウェイ)を東西(メッシュ)から分け、それぞれにその方向を所有させます。
横断的関心事を共有の層に押し込み、サービスごとではなく一度だけ書くようにします。
サービスの数が、サービスごとの配線をより大きなコストにしたときにだけ、サービスメッシュを採用します。
関心事ごとに、方針の徹底点を一つ定義します。ゲートウェイとメッシュに同じ仕事をさせてはいけません。
サービスを薄く保ちます。プラットフォームがトランスポートを扱い、サービスがビジネスロジックを扱います。
ネットワーク上の位置に基づく信頼より、アイデンティティに基づくゼロトラストのネットワーキングを好みます。
メッシュの運用上の複雑さを目を開いて買い、それが見返りをもたらすかを測定します。

推奨事項

APIゲートウェイが何をするかを理解する

APIゲートウェイは、サービスの前に座り、外の世界からのあらゆるリクエストを仲介する、単一の入口です。最も単純には、賢いリバースプロキシ(クライアントのリクエストを受け取り、適切なバックエンドに転送するサーバー)ですが、ゲートウェイは、転送よりはるかに多くを行うことでその名を稼ぎます。パス、ホスト、ヘッダーに基づいて、各リクエストを正しいサービスにルーティングします。呼び出し元を認証し(誰であるかを検証する)、リクエストを認可する(何をしてよいかを確認する)ので、その背後のサービスは、リクエストがすでに玄関口を通ったと信頼できます。レート制限(時間あたりのクライアントごとのリクエストの上限)とクォータ(より長い窓での合計使用量の上限)を徹底し、一つのうるさい、あるいは乱用するクライアントが他を飢えさせないようにします。

ゲートウェイはトラフィックを整形もします。リクエストの変換は、ヘッダーを書き換え、プロトコル間を翻訳し、古いクライアントの形式を新しいサービスの期待に適応させます。API合成により、ゲートウェイは一つの受信リクエストを複数のサービスにファンアウトして、応答を一つに縫い合わせられるので、クライアントは六つではなく一つの呼び出しで済みます。バージョニングのサポートにより、APIのv1とv2を並べて動かし、各クライアントを期待するバージョンにルーティングでき、誰も壊さずに進化する余地を買えます。これらの関心事を縁に集中させることで、サービスはビジネスロジックに集中し続け、入ってくるすべてを観察し、保護し、絞る場所が一つ得られます。ゲートウェイが前に立つAPIの設計は2.3章の主題で、それが行うアイデンティティの確認は4.7章に依拠します。

異なるクライアントにはバックエンド・フォー・フロントエンドのパターンを使う

単一の汎用APIは、しばしばウェブアプリ、モバイルアプリ、パートナーの統合に同時に仕え、そのすべてに少しずつ下手に仕えます。モバイルのクライアントは、帯域と電池が乏しいので、小さなペイロードと少ないラウンドトリップを望みます。ウェブのクライアントは、よりおしゃべりで豊かな応答を扱えます。パートナーは、決して驚かせない安定した契約を望みます。バックエンド・フォー・フロントエンド(BFF)パターンは、この緊張を、各クラスのクライアントに、そのニーズに合わせて調整された独自の薄いゲートウェイを、背後の共有サービスの前に与えることで解決します。

BFFは、より狭い読み手を持つゲートウェイです。モバイルのBFFは、アプリが一つの効率的な呼び出しをするよう応答を合成して削り、ウェブのBFFはより完全な形を公開し、パートナーのBFFは、ゆっくり動く、慎重にバージョン管理された契約を保持します。各チームは、他を待たずに自分のBFFを進化させられ、それがしばしば本当の勝利です。クライアントのチームを互いから切り離すからです。コストは、動く部品が増え、BFFにわたるロジックがいくらか重複することなので、クライアントのニーズが本当に分岐する場合のためにこのパターンを取っておきます。すべてのクライアントが同じものを望むなら、一つのゲートウェイのほうが単純で優れています。

サービスメッシュが何をするかを理解する

サービスメッシュは、サービス間の東西のトラフィックを、それらのサービスにコードを変えるよう求めずに管理します。古典的なメッシュは、サイドカーのプロキシ(各サービスのインスタンスと並んで動き、そのネットワークトラフィックのすべてを傍受する小さなプロキシのプロセス)をデプロイすることで動きます。サービスは別のサービスと直接話していると思っていますが、実際にはローカルのサイドカーと話し、サイドカーが本物のネットワーク呼び出しを扱います。すべてのリクエストが今やプラットフォームが制御するプロキシを流れるので、メッシュは、同期を保つべき共有ライブラリなしに、あらゆる言語の、あらゆるサービスにわたって、振る舞いを一様に徹底できます。

何を徹底するのでしょうか。第一に、相互TLS(mTLS)です。すべての接続の双方が証明書を提示してトラフィックを暗号化するので、サービス間の呼び出しは既定で認証され、非公開です。第二に、トラフィック管理です。カナリアリリースのために、メッシュはトラフィックの小さな割合を新しいバージョンに移し、テストのためにヘッダーでトラフィックを分け、トラフィックをシャドウのサービスにミラーできます。第三に、レジリエンスです。リトライ、タイムアウト、サーキットブレーキング(2.20章のパターン)が、各サービスにコード化されるのではなく、方針で設定されて、プラットフォーム層で適用されます。第四に、オブザーバビリティです。すべてのリクエストがプロキシを通るので、メッシュはすべてのサービス間のトラフィックについて一貫したメトリクス、ログ、分散トレースを発し、9.2章のオブザーバビリティの実践に流れます。サービスの作者はこれらを何も書かずに、すべてを得ます。

サイドカーのパターンとサイドカーレスの代替を知る

サイドカーのモデルは優雅ですが、無料ではありません。各サービスのインスタンスは、メモリとCPUを消費する追加のプロキシコンテナを動かし、あらゆる呼び出しが二つの追加のネットワークの跳躍(ローカルのサイドカーへ、リモートのサイドカーから出て)を行い、わずかなレイテンシを加えます。少数のサービスでは、このオーバーヘッドは見えません。何千ものポッドにわたっては、コンピュートの請求書とレイテンシの予算の本物の項目になります。そのコストが、サイドカーレス、あるいはプロキシレスのアプローチの波を駆動しました。

二つの方向が重要です。一つは、メッシュの機能をポッドごとのサイドカーからノードごとのプロキシに移すもので、同じマシン上の多くのサービスがそれぞれ自分のものを動かす代わりに、一つのプロキシを共有し、いくらかの隔離を大きなオーバーヘッドの低下と交換します。もう一つのプロキシレスのアプローチは、薄いライブラリやランタイムを通じて、メッシュのロジックをサービスに直接埋め込み、言語ごとの依存というコストで、追加の跳躍を完全に取り除きます。より新しい展開は、eBPF(Linuxカーネル内でサンドボックス化されたプログラムを動かす技術)を使って、メッシュの機能の一部をオペレーティングシステムのカーネルに押し込むもので、ユーザー空間のプロキシより少ないオーバーヘッドで、方針を徹底しテレメトリを集められます。今日、一つの勝者に賭ける必要はありません。サイドカーの税が本物であること、代替が存在すること、そしてプラットフォームの選択が、後でそれらを採用する道を閉ざすべきでないことは知っておく必要があります。これらのパターンは、8.3章のコンテナオーケストレーションの基盤の上に乗ります。

メッシュがその複雑さに見合うときを決める

サービスメッシュは強力で、運用するのは本当に複雑です。運用するコントロールプレーン、アップグレードするプロキシ、ローテーションする証明書、リクエストが行方不明になったときにデバッグする新しい層を加えます。その複雑さは、これらの関心事を、サービスごと、言語ごとに手で配線することが、メッシュを運用するよりコストがかかるほど、十分なサービスがあるときに、買う価値があります。おおまかなシグナルは、規模と多言語の多様性です。いくつかの言語で書かれた数十、数百のサービスで、mTLSとリトライのための共有ライブラリを一貫して保つのが悪夢になる場合です。その規模では、メッシュは、一様性と証明可能なセキュリティで元を取ります。

数個のサービス、単一の言語、小さなチームでは、メッシュはその複雑さに見合いません。控えめなシステムなら、良いライブラリやフレームワークが、完全なメッシュよりはるかに少ない運用の負担で、mTLS、リトライ、メトリクスを与えられ、プレーンなゲートウェイと妥当なクライアントライブラリで、必要なものすべてをカバーできることがよくあります。規模が求める前に、流行だからとメッシュを採用することは、持っていない問題を解決するインフラを一年運用して費やす、よくある方法です。ゲートウェイから始め、コードやライブラリでレジリエンスのパターンを加え、サービスと言語の数が、サービスごとのアプローチをより高価にしたときに、メッシュに手を伸ばします。これは、クラウドと分散システムの章(3.11章と3.3章)が何度も戻る、同じ「複雑さに見合うか」という規律です。

ゲートウェイとメッシュが重なる所での二重処理を避ける

ゲートウェイとメッシュは重なり、その重なりこそチームが自らを傷つける所です。どちらもリトライでき、どちらもタイムアウトを徹底でき、どちらもアイデンティティを確認でき、どちらもテレメトリを集められます。ゲートウェイがリクエストを三回リトライし、メッシュもすべての内部の跳躍で三回リトライすると、一つのクライアントのリトライが数十のバックエンド呼び出しに爆発し、小さな瞬断をリトライの嵐に変えます。両方の層がタイムアウトを徹底し、内側のものが外側のものより長いと、外側は諦め、内側は誰も読まない応答のために働き続け、労力を無駄にします。

修正は、書き留められ合意された明確な分業です。各関心事をちょうど一つの層に割り当てます。ゲートウェイは南北の関心事を所有します。エンドユーザーの認証、外部のレート制限とクォータ、リクエストの変換、クライアントのためのAPI合成。メッシュは東西の関心事を所有します。サービス間のmTLS、内部のリトライとサーキットブレーキング、サービスのバージョン間のトラフィックのシフト。関心事がどちらにも住みうる所では、所有者を一つ選び、もう一方の層は通過させます。外側のタイムアウトが、それが待つ内側の仕事より常に長くなるよう、リトライの予算とタイムアウトの階層を設定します。目標は、すべてのリクエストが、各関心事を扱うちょうど一つの場所を持ち、偶然にリトライされたり、認証されたり、ログに残されたりするリクエストがないことです。

ゲートウェイとメッシュを、ゼロトラストの方針の徹底点として扱う

これらの層を動かす最も深い理由は、セキュリティアーキテクチャです。ゼロトラストとは、どこから来たかによってリクエストが信頼されることはなく、自分のネットワークの内側でも、すべてのリクエストが自分のアイデンティティと認可を証明しなければならない、という原則です。古いモデルは、すでに境界の内側にあるものを何でも信頼し、それは、一つの侵害されたサービスが自由に動き回れることを意味しました。ゼロトラストは、ネットワーク上の位置の信頼を、あらゆる跳躍でのアイデンティティに基づく信頼に置き換え、ゲートウェイとメッシュは、そのアイデンティティが確認される自然な徹底点です。

ゲートウェイは外部のアイデンティティの方針の徹底点です。何かがサービスに届く前に、エンドユーザーやパートナーを検証します。メッシュはワークロードのアイデンティティの方針の徹底点です。すべてのサービスが暗号学的なアイデンティティを得て、mTLSがあらゆる呼び出しでそれを証明し、方針がどのサービスがどのサービスと話してよいかを決めます。両者が合わさって多層防御を与え、リクエストは縁で一度、サービスの間でもう一度確認されるので、一つのサービスの侵害が、残りへの自由な移動を与えることはありません。マルチクラスターとマルチリージョンのデプロイでは、メッシュはこのアイデンティティの織物をクラスターの境界をまたいで広げられるので、あるクラスターのサービスは、ローカルで使うのと同じmTLSの保証で、別のクラスターのサービスに認証でき、足跡が広がっても一貫したゼロトラストのネットワーキングを与えます。ここでのアイデンティティの基礎は、4.7章に直接つながります。

トレードオフ: 長所と短所

アプローチ	長所	短所
APIゲートウェイ	認証、レート制限、合成、バージョニングの一か所	スケールして高可用に保つべき単一の隘路
バックエンド・フォー・フロントエンド	各クライアントが調整された、独立して進化するAPIを得る	運用するゲートウェイが増える。BFF間でロジックが重複する
サービスメッシュ(サイドカー)	コードの変更なしに一様なmTLS、リトライ、オブザーバビリティ	プロキシのオーバーヘッド、レイテンシ、運用するコントロールプレーン
サイドカーレス / プロキシレスのメッシュ	ポッドごとのサイドカーより低いオーバーヘッドとレイテンシ	成熟度が低い。隔離が弱い、あるいは言語ごとの依存
ライブラリベースのレジリエンス	運用が簡単。追加のインフラなし	言語ごとの重複。規模で一貫して保つのが難しい
クラスターをまたぐメッシュ	あらゆる所で一貫したゼロトラストのアイデンティティ	相当な運用とネットワーキングの複雑さ

中心的な緊張は、一様性と運用コストです。共有の層は、一貫性、証明可能なセキュリティ、一度書く方針を買いますが、運用し、スケールし、保護し、デバッグしなければならない本物のシステムであり、すべてのリクエストの経路に自らを挿入します。規模とニーズで解決してください。ゲートウェイは、外部のクライアントを持つ瞬間にほぼ常に見返りがあります。それが集中させる関心事は避けられないものだからです。メッシュは、サービスと言語の数がサービスごとの配線をより高価な道にする、後の時点で見返りをもたらします。その閾値より下では、ライブラリとプレーンなゲートウェイが、コストの何分の一かで利益のほとんどを与えます。上では、メッシュの一様性がその重さに見合います。どちらの方向の間違いも、ニーズではなく流行に基づく採用です。早すぎるメッシュは一年の無駄な準備作業で、遅すぎるメッシュの見送りは、百の一貫しない手作りのmTLSの実装です。

チームで議論すべき問い

各横断的関心事(認証、リトライ、タイムアウト、レート制限、暗号化、テレメトリ)について、どの単一の層が所有し、全員が推測せずに所有者を名指しできますか。これは二重処理を防ぐ問いで、ほとんどのチームは明示的に答えたことがなく、それは答えがサービスごと、作者ごとに異なることを意味します。左側に具体的な関心事の一覧、上に層(クライアントライブラリ、ゲートウェイ、メッシュ、個々のサービス)を並べ、一緒に格子を埋めてください。一つの関心事に二つのセルが確認される所が、起こりかけているリトライの嵐とタイムアウトの逆転です。空の行は、誰も扱っていない関心事です。成果物は、ちょうど一つの層が各関心事を所有し、他が通過させると言う、すべてのチームが見られる場所に公開された、一つの合意された表です。その表は、どんなゲートウェイやメッシュの設定よりも価値があります。二つの層が互いに戦うのを防ぐものだからです。
サービスメッシュを正当化するのに十分なサービスと言語の多様性が本当にあるか。それとも、持っていない問題を解決するために、コントロールプレーンを買おうとしているのか。メッシュは重大な運用上のコミットメントで、多くのチームにとっての誠実な答えは、良いライブラリとゲートウェイのほうが今日はよく役立つ、というものです。サービスの本当の数、それらが書かれている言語の数、重複したネットワーキングのロジックが今実際にどれだけ痛いかの誠実な評価を持ち込んでください。それから反対側を持ち込んでください。誰がメッシュを運用し、そのプロキシをアップグレードし、証明書をローテーションし、リクエストを誤ってルーティングしたときに呼び出されるのか。サービスごとの配線の痛みが、メッシュを運用するコストより小さいなら、答えは待つことです。数十の多言語のサービスにわたる一貫しないmTLSとリトライのコードに溺れているなら、メッシュはその価値を稼ぎます。要点は、カンファレンスの発表がメッシュをどう見せたかではなく、証拠で決めることです。
今日のゼロトラストの境界はどこにあり、一つの内部サービスが侵害されたら何が起こりますか。 多くのシステムは、すでにネットワークの内側にあるものを信頼し続けており、それは、一つの侵害されたサービスが横方向に動いて他のすべてに届きうることを意味し、チームはインシデントの間にしかこれを発見しないことがよくあります。影響範囲を誠実にたどってください。攻撃者がサービスの一つを所有したら、何を呼び出せ、何を読め、何がそれを止めるか。サービス間の呼び出しがどう認証され暗号化されているかについての現在の答えを持ち込み、どの呼び出しがmTLSで守られ、どれが同じネットワーク上にいることに基づく平文の信頼かを具体的にしてください。その後の行動は、あらゆる跳躍でのアイデンティティに基づくアクセスの意図した計画で、ゲートウェイが外部のアイデンティティを、メッシュやその同等物がワークロードのアイデンティティを確認し、侵害が壊滅的ではなく封じ込められるようにします。完全なメッシュを動かす準備ができていなくても、信頼の境界が本当にどこにあるかを名指しすることが、最初の誠実な一歩です。
APIゲートウェイの層が今失敗したら、システムのどれだけが暗転し、その失敗を想定で片付けず、テストしましたか。 ゲートウェイは非常に多くを集中させるので、その障害は背後のすべてをオフラインにし、大きなチームは、まさにそれが、そうでなくなるまで静かに働くために、その冗長性への投資が不足しがちです。引き合う力を量ってください。単一の単純なゲートウェイは推論しやすく運用が安いですが、水平にスケールされたマルチゾーンの層は、コストがかかり、独自のフェイルオーバーの設定と複雑さを加えます。議論に本物の数字を持ち込んでください。今日いくつのインスタンスが、いくつの可用性ゾーンにわたって動いているか、フェイルオーバー時間は何か、最後にゲートウェイを意図して殺すゲームデーを実施したのはいつか。稼働時間の約束や法定のサービスレベルを負う企業や政府のプラットフォームでは、障害に対する契約上または規制上のペナルティを加えてください。冗長性のない玄関口は、背後のすべてのサービスとすべての市民に代わって、静かに受け入れた可用性のリスクだからです。
メッシュが実際に課すサイドカーの税を測定しましたか。そしてサイドカーレスやeBPFの代替の計画を持っていますか。それとも、盲目的に払っていますか。規模では、ポッドごとのプロキシのオーバーヘッドは、コンピュートとレイテンシで見えなくなくなり、予算の本物の項目になりますが、多くのチームは、そのコストを測ったことなく、何千ものサイドカーを動かしています。緊張は、一方にサイドカーのモデルの成熟度と隔離があり、もう一方に、ノードごとのプロキシ、プロキシレスのライブラリ、カーネルのeBPFのアプローチの低いオーバーヘッドがあり、後者はより新しく、いくらかの隔離を手放すか、言語ごとの依存を加えることです。測定された数字を持ち込んでください。フリート全体でプロキシが消費するメモリとCPU、跳躍ごとに加わるテールレイテンシ、メッシュが表すコンピュートの請求書の割合。何千ものポッドにわたってメッシュを動かす大きな企業や、予算の精査のもとにある政府のプラットフォームでは、これは監督がいずれ尋ねる支出の決定なので、税を知り、プラットフォームの選択がより安い代替を開いたままにしているかを知ることは、基本的なデューデリジェンスです。
各クライアントのクラスは本当に独自のバックエンド・フォー・フロントエンドを必要としているか。それとも、実は同じものを望むクライアントのために、ゲートウェイ間でロジックを重複させようとしているのか。 BFFパターンは、クライアントのチームを切り離し、それぞれが調整された契約を進化させられるようにしますが、新しいBFFごとに、運用し、保護し、同期を保つべきゲートウェイがもう一つ増え、それらの間の重複したロジックは、静かに保守の税になります。相反する考慮は、チームの自律とクライアント固有の効率と、多くのほぼ同一のゲートウェイの運用コストとずれです。クライアントのニーズが本当にどれだけ分岐するかの証拠を持ち込んでください。ペイロードのサイズ、ラウンドトリップの数、バージョニングの周期、単一の共有ゲートウェイのもとで、一つのクライアントの変更が別のクライアントをどれだけ頻繁にブロックしたか。多くのクライアントのチームを持つ大きな組織や、公共のウェブアプリ、モバイルアプリ、パートナーの統合に同時に仕える政府のプラットフォームでは、誠実な問いは、分岐が増殖を正当化するかです。すべてが同じ形を望むクライアントごとのBFFは、何年も保守するために払う乱立だからです。

セクター別の視点

スタートアップ。 APIゲートウェイを出荷し、メッシュは省いてください。少数のサービスと小さなチームでは、単一のゲートウェイが認証、レート制限、合成を扱い、共有のクライアントライブラリが、コントロールプレーンのコストの何分の一かで、mTLSとリトライを与えます。最も乏しい資源はエンジニアリングの注意なので、運用できないメッシュは堀ではなく負債です。ゲートウェイを、一つのノードが死んでも生き延びるのに十分な冗長性に保ち、サービスの数と言語の多様性が実際にその問いを強いるときにだけ、メッシュを見直します。

小規模事業者。 メッシュを動かすプラットフォームチームはいないので、ホスティングのプラットフォームやゲートウェイ製品が最初から与えるものに頼ってください。マネージドなTLS、組み込みのレート制限、自分でパッチを当てるものではなくホスト型のゲートウェイ。選択を買うか作るかとして枠づけ、買います。マネージドなAPIゲートウェイは、自前のものを運用するエンジニアの時間より安いからです。内部のサービス間の暗号化を、人員を配置するプロジェクトではなく、プラットフォームが提供する機能として扱います。

大企業。 多くのチームと言語にわたる数百のサービスでは、メッシュはその複雑さを稼ぎ、本当の仕事はガバナンスです。ゲートウェイとメッシュが関心事を二重に処理しないための、書かれた分業、一様なmTLSとテレメトリ、プロキシのアップグレードと証明書のローテーションを所有するプラットフォームチーム。監査人は、アクセスと暗号化のための単一の証明可能な徹底点を求めるので、インターフェースを標準化し、方針を、チームが再実装するのではなく引き継ぐものにします。サイドカーの税を本物の予算項目として管理し、後でより安いアプローチから締め出されないよう、サイドカーレスの選択肢を開いたままにします。

政府。 調達規則、透明性、公的な説明責任がアーキテクチャを形づくります。ゲートウェイとメッシュを、規制当局が期待するゼロトラストの背骨として扱います。すべての市民とパートナーが玄関口で認証され、すべての内部呼び出しがワークロードのアイデンティティで認証され暗号化され、各徹底点の監査証跡が、アクセスがどこで確認され、トラフィックがどこで暗号化されたかを証明します。調達規則が禁じうる独自のロックインより、オープン標準と可搬な設定を好み、適切な所では、プラットフォームが各境界を越える市民のデータをどう守るかを公開します。

事例

スタートアップ。 12人のスタートアップは、単一のAPIゲートウェイの背後で八つのサービスを運用しています。ゲートウェイはすべての南北の仕事を扱います。トークンの確認でユーザーを認証し、プランごとのレート制限を徹底して無料のユーザーがシステムを圧倒できないようにし、いくつかのおしゃべりなエンドポイントを、モバイルに優しい単一の呼び出しに合成します。東西のトラフィックには、意図してサービスメッシュを省きます。二つの言語の八つのサービスは、コントロールプレーンを正当化しないからです。代わりに、共有のクライアントライブラリとプラットフォームに組み込まれた証明書管理からmTLSとリトライを得て、軽量なエージェントでトレースを集めます。後でより厳しいペイロードのニーズを持つ専用のモバイルクライアントを加えたとき、既存のウェブゲートウェイの隣にモバイルのバックエンド・フォー・フロントエンドを導入します。毎年メッシュの問いを見直し、まだそれが見返りをもたらす閾値を越えていない、と正しく決め続けます。

大企業。 多国籍の銀行は、多くのチームと言語にわたる数百のサービスを運用し、ここではサービスメッシュがその複雑さを稼ぎます。すべてのサービスが既定でワークロードのアイデンティティとmTLSを得るので、どのチームも暗号のコードを書かずに、すべての内部トラフィックが認証され暗号化され、単一の証明可能な徹底点を求めるセキュリティ組織と監査人の両方を満たします。メッシュは一様なリトライ、タイムアウト、サーキットブレーキングを方針で適用し、カナリアリリースのためにトラフィックを段階的にシフトするので、悪いデプロイは全員に届く前に1パーセントのユーザーに触れるだけです。APIゲートウェイの層が外部とパートナーのトラフィックの前に立ち、認証、クォータ、バージョニングを所有し、内部のリトライはメッシュにのみ、外部のレート制限はゲートウェイにのみ住むという、固い書かれたルールを持つので、二つの層がリクエストを二重に処理することはありません。すべてのプロキシからの一貫したテレメトリが、中央のオブザーバビリティのプラットフォームに流れ、一人のオンコールのエンジニアが、数十のサービスの跳躍にわたってリクエストをたどれます。

政府。 国の税務当局は、市民向けの申告プラットフォームをモダナイズし、ゲートウェイとメッシュを、規制当局が求めるゼロトラストアーキテクチャの背骨として扱います。APIゲートウェイは管理された玄関口です。すべての市民とパートナーがそこで認証され認可され、外部のレート制限が申告期限の急増の間システムを守り、古いクライアントの形式は縁で変換されるので、レガシーの統合が動き続けます。その背後で、サービスメッシュがすべての内部サービスに暗号学的なアイデンティティを与え、すべての呼び出しでmTLSを徹底するので、ネットワークの内側にいるというだけで信頼されるサービスはなく、アクセス方針はどのサービスがどのサービスを呼べるかを明示的に列挙します。プラットフォームがレジリエンスのために複数のデータセンターにまたがるので、メッシュは同じアイデンティティと暗号化の保証をクラスターをまたいで広げ、全国で一貫したゼロトラストのネットワーキングを与えます。すべての徹底点が監査証跡を発するので、当局は監督機関に、アクセスがどこで確認され、トラフィックがどこで暗号化されたかを正確に証明できます。

ビジネスケース: 動機、ROI、TCO

ゲートウェイの見返りは見えやすく、通常は大きなものです。すべてのサービスが認証、レート制限、リクエストのログを再実装する代わりに、縁で一度築けば、すべてのサービスがそれを引き継ぎます。セキュリティの修正や新しいレート制限の方針は、百ではなく一回のデプロイで出荷され、脆弱性を閉じるまでの時間を短縮し、検査する場所が一つなので、あらゆる監査のコストを下げます。合成とバージョニングの機能は、クライアントのラウンドトリップを削り、呼び出し元を壊さずにAPIを進化させられるので、レイテンシのコストとチーム間の調整の税の両方を減らします。外部のクライアントを持つほとんどどんなシステムでも、ゲートウェイはすぐに元を取ります。

サービスメッシュには、より微妙なビジネスケースがあります。その総所有コストは本物で継続的だからです。プロキシのコンピュートとレイテンシ、コントロールプレーンを運用するエンジニア、新しい層をデバッグする学習曲線に払います。そのコストは、代替(mTLS、リトライ、テレメトリの、サービスごと、言語ごとの実装)がより大きく、さらに悪いことに、セキュリティのギャップと障害を生む形で一貫しないときに、正当化されます。高い規模では、メッシュは百の脆い手作りの解決策を、一つの一様で証明可能なものに変え、ROIは、少ないセキュリティインシデント、トラフィックのシフトによるより速く安全なデプロイ、劇的に良いオブザーバビリティとして現れます。その規模より下では、誠実な計算はしばしばライブラリとゲートウェイを支持し、規律ある動きは待つことです。リーダーシップに論拠を示すには、ゲートウェイを彼らがすでに追跡している指標(脆弱性を是正する時間、監査のコスト、APIの調整オーバーヘッド)に結びつけ、メッシュを、セキュリティインシデントの封じ込め、デプロイの安全性、それが置き換える多言語の重複のコストに結びつけてください。

アンチパターンと落とし穴

必要になる前のメッシュ: 少数のサービスで完全なサービスメッシュを採用し、まだ持っていない問題を解決するためにコントロールプレーンを買うこと。
二重のリトライ: ゲートウェイとメッシュの両方がリトライし、一つのクライアントの呼び出しが、障害を増幅するバックエンドのリトライの嵐に増えること。
タイムアウトの逆転: 内側のタイムアウトが外側より長く、呼び出し元は諦めるが、呼ばれた側は誰も読まない応答のために働き続けること。
モノリスとしてのゲートウェイ: ビジネスロジックをゲートウェイに詰め込み、すべてのチームが変更のために調整しなければならない共有のボトルネックになること。
単一障害点: 冗長性のない一つのゲートウェイのインスタンスを動かし、玄関口の障害が背後のすべてのサービスを落とすこと。
ネットワークを信頼する: 境界の内側のあらゆるものを安全として扱い、一つの侵害されたサービスが横方向に動いてすべてに届けること。
重なるオーナーシップ: 書かれた分業がなく、同じ関心事が偶然に両方の層で扱われ、どちらが権威あるかを誰も知らないこと。
BFFの乱立: クライアントが同じものを望むのに、クライアントごとにバックエンド・フォー・フロントエンドを立ち上げ、利益なしにゲートウェイを増やしロジックを重複させること。
サイドカーの税の無視: コンピュートとレイテンシのオーバーヘッドを測らずに何千ものサイドカーをデプロイし、予算がどこへ行ったのか不思議がること。

成熟度モデル

レベル1、開始: サービスは共有の層なしに互いに直接話します。認証、リトライ、タイムアウトは、サービスごとに手でコード化されて一貫しません。内部のトラフィックはしばしば平文で、ネットワーク上にいることで信頼され、方針を徹底したりトラフィックを観察したりする単一の場所がありません。決定は反応的で、問題が表面化するにつれて、サービスごとに行われます。
レベル2、発展: APIゲートウェイが外部のトラフィックの前に立ち、認証、レート制限、ルーティングを集中させますが、東西の関心事は、採用が不均一な共有ライブラリで扱われます。一部のサービスにはmTLSがあり、多くにはありません。チームは南北対東西の区別を認識していますが、オーナーシップは非公式で、実践はチームごとに異なります。
レベル3、標準化: 南北と東西の関心事が、組織全体に適用される書かれた分業できれいに分けられています。ゲートウェイは外部のアイデンティティ、クォータ、合成を所有し、メッシュや一貫したライブラリの層が、内部のmTLS、リトライ、テレメトリを所有します。重なりは解決されて、どの関心事も二重に処理されず、内部のトラフィックは既定で暗号化されアイデンティティが確認され、標準は文書化され、各チームの裁量に任されるのではなく徹底されています。
レベル4、管理: トラフィックの層が、ベースラインに対して測定され、制御されています。コンピュートと跳躍ごとのテールレイテンシでのサイドカーの税、エラーバジェットに対するゲートウェイとメッシュの可用性、リトライの増幅とタイムアウトの逆転のインシデント、内部呼び出しの割合としてのmTLSのカバレッジ、フリート全体に方針の変更を押し出す時間を追跡します。指標が判断をゲートします。プロキシのアップグレード、新しいリトライの予算、カナリアのルールは、直感ではなくベースラインに対するデータで判断され、標準からのずれは修正を引き起こします。
レベル5、オーケストレーション: ゲートウェイとメッシュは、クラスターとリージョンをまたいですべての跳躍でアイデンティティが確認される、成熟したゼロトラストアーキテクチャの方針の徹底点です。トラフィックのシフトが安全な漸進的デリバリーを駆動し、オブザーバビリティは一様で豊かで、組織は、見返りのある所でサイドカーレス、プロキシレス、eBPFのアプローチを継続的に評価し採用します。トラフィックの層は、セキュリティ、デリバリー、キャパシティ計画と統合され、規模、言語、リスクの状況の変化に応じて適応します。

議論のためのアイデア

単一のAPIゲートウェイが今ダウンしたら、いくつのサービスが到達不能になり、玄関口を冗長にする計画は何ですか。
システムで、現在ゲートウェイとサービス(あるいはライブラリ)の両方で扱われている関心事はどれで、二重に処理されていないことをどう証明しますか。
何個のサービスと言語で、チームはメッシュがついにその複雑さを稼いだと合意し、その線からどれだけ離れていますか。
攻撃者が明日一つの内部サービスを侵害したら、他のどのサービスに届き、どのアイデンティティの確認がそれを止めますか。
サイドカーレスやeBPFベースのメッシュのアプローチは、プラットフォームにとってもう十分成熟していますか。そして決めるために何を測定しますか。
分岐したクライアントのそれぞれは、本当に独自のバックエンド・フォー・フロントエンドを必要としていますか。それとも、共有のままでいられるロジックを重複させようとしていますか。

要点

南北のトラフィック(APIゲートウェイが扱う)を東西のトラフィック(サービスメッシュが扱う)から分けます。それぞれがその方向を所有し、混同は二重処理を引き起こします。
ゲートウェイは、ルーティング、認証、認可、レート制限、クォータ、リクエストの変換、合成、バージョニングを集中させるので、サービスは薄いままで、方針は一か所に住みます。
サービスメッシュは、サービスのコードを変えずに、古典的にはサイドカーのプロキシを通じて、mTLS、トラフィックのシフト、プラットフォームレベルのリトライとサーキットブレーキング、一様なオブザーバビリティを与えます。
サービスと言語の数が、サービスごとの配線をより高価な道にしたときにだけ、メッシュを採用します。それより下では、ライブラリとゲートウェイが勝ち、サイドカーの税は、観察する価値があるほど本物です。
ゲートウェイとメッシュを、ゼロトラストアーキテクチャの方針の徹底点として扱い、各横断的関心事をちょうど一つの層に割り当て、クラスターをまたいですべての跳躍でアイデンティティを確認します。

参考文献とさらなる読み物

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices