質問の歴史

サービスメッシュアーキテクチャは、マイクロサービスの通信の複雑さに対処するために、モノリシックAPIゲートウェイからサイドカー型ソリューション（IstioやLinkerdなど）進化しました。企業がベンダーロックインを避けてレジリエンスを高めるためにマルチクラウド戦略を採用するにつれて、異種クラウドプロバイダー間でこれらのメッシュをフェデレートする必要性が重要になりました。初期の試みは、中央集権型制御プレーンまたはVPNハブアンドスパークモデルに依存しており、これらは許容できないレイテンシや、グローバルアプリケーションのシングルポイントオブフェイリャを招いていました。この質問は、金融取引プラットフォームや厳格なレイテンシSLAおよびオフライン能力を必要とするIoTデプロイメントで直面する課題を統合しています。

問題

AWS、Azure、GCP間でサービスメッシュをフェデレートすることは、互換性のないネットワーク抽象化、異なるCNI実装、独自のアイデンティティシステムのため独自の障害を示します。クロスクラウドトラフィックは通常、公共インターネットまたは高価な専用接続を経由し、50ms未満の要件に違反する変動レイテンシやパケット損失を引き起こします。非対称ネットワークパーティション中（AWS us-east-1はGCP europe-west1に到達できますが、Azure southeast-asiaには到達できない場合）、ワークロードが中央集権型OIDCプロバイダーに依存している場合、ゼロトラストmTLS認証を維持することは不可能です。また、一時的なエッジノード（5G MECデバイスや自律走行車両ユニットなど）は永続的なアイデンティティを欠き、中央集権型制御プレーンへの長期接続を維持できないながらも、手動介入なしにセキュリティ境界に即座に加入する必要があります。

解決策

ネットワークトポロジーから切り離されたワークロードIDのために、SPIFFE/SPIREを利用した分散型Istioプライマリプライマリフェデレーショントポロジーを実装します。

各クラウドに地域のイングレスゲートウェイを展開し、Envoyプロキシとして設定し、レイテンシを考慮したルーティングおよびクロスクラスター負荷分散のためにWASMフィルターを使用します。地域のゲートウェイ間でWireGuardまたはIPsecトンネルを確立し、トランスポート層でトラフィックを暗号化しつつ、サービスレベルmTLSのためにサイドカー間の直接通信を許可します。各地域にSPIREサーバーを設定し、S3バケットに公開されたフェデレート信頼バンドルを持ち、パーティション中のSVID認証を可能にします。エッジノードには、S3ホスティング構成およびSTS一時的資格情報を介してブートストラップするIstio環境メッシュztunnelエージェントを利用し、近隣の地域ゲートウェイと相互TLSを確立します。

日常の状況

グローバル高頻度取引プラットフォームは、AWS us-east-1の注文実行サービスをGCP europe-west1のリスク分析マイクロサービスおよびAzure southeast-asiaの顧客ポートフォリオデータに接続する必要がありました。ビジネスの命令は、アービトラージ損失を防ぐために、クロスクラウドリスクスコアリング呼び出しに50ms未満の往復レイテンシを要求しました。北米とヨーロッパの間でシミュレートされた海底ケーブルの切断中、会社のオンプレミスデータセンターに存在する既存のIPSec VPNハブがボトルネックとなり、レイテンシが180msに増加し、取引が12分間停止しました。

問題の説明

レガシーアーキテクチャは、認証のために中央集権型F5ロードバランサクラスタとActive Directory Domain Servicesに依存しており、単一の障害点を作成していました。ネットワークパーティションが発生したとき、Azureワークロードは中央のADサーバーに対してJWTトークンを検証できず、認証の失敗が連鎖的に発生しました。さらに、取引フロアの新しい5Gエッジコンピュートノード（NVIDIA Jetsonデバイスを実行している）は、市場データをローカルで処理するためにメッシュに参加する必要がありましたが、標準のIstioサイドカー型モデルはデバイスの2GB RAM制限を超え、VPN証明書を手動で発行するのに45分かかりました。

解決策A：中央集権型ポリシー管理を伴うネイティブクラウドトランジットピアリング

このアプローチは、AWS Transit GatewayピアリングをAzure Virtual WANおよびGCP Cloud Interconnectと組み合わせ、完全メッシュネットワークトポロジーを作成します。すべてのクロスクラウドトラフィックは、Palo AltoまたはFortinetアプライアンスによって管理される中央集権型企業ファイアウォールクラスターを経由します。設定は、クラウド地域がスケーリングしたときに接続を維持するためにBGPルートプロパゲーションに依存しています。

**利点：**ネイティブな統合は、100Gbpsまでの高帯域幅と、ネイティブクラウドツールまたはAviatrixコントローラーによるコンプライアンス監査のための中央集権的な可視性を提供します。このアプローチは、既存のネットワークエンジニアリング作業フローに最小限の変更で済みます。
**欠点：**データのエグレスコストは、クロスクラウドトラフィックに対し$0.09を超え、取引プラットフォームのボリュームで月額500Kドルを超える予測請求が発生します。このアーキテクチャは、サーバー間で80-120msのレイテンシを追加するファイアウォールクラスターにおける通過点を導入し、50ms未満の要件を満たさなくなります。また、静的IPアドレスやBGPピアリング機能のない一時的なエッジノードに対する入会ルートはありません。

解決策B：CiliumクラスターのメッシュとeBPFデータプレーン

このアーキテクチャは、すべてのKubernetesクラスターにCiliumを展開し、カーネルレベルの負荷分散およびWireGuard暗号化にeBPFを利用します。Cilium ClusterMeshは、各クラウドのetcdクラスター間でKubernetesエンドポイントを同期させることにより、マルチリージョンサービスディスカバリを可能にします。このデータプレーンは、全くiptablesを迂回し、処理オーバーヘッドをミリ秒未満のレベルに減少させ、サイドカーなしでHubbleによる可観測性を提供します。

**利点：**eBPFは、非常に高い性能を提供し、CPUオーバーヘッドを最小限に抑え、レイヤー4トラフィックのためのEnvoyサイドカーの必要性を排除します。このソリューションは、透過的な暗号化と詳細なネットワークポリシーを通じて優れたセキュリティを提供します。
**欠点：**Ciliumは、Azure CNIオーバーレイモードや既存のCalicoポリシー実装と互換性のない同種のCNI設定が必要です。クラウドの境界を越えたBGPピアリングは、クラウドネットワークチームとの複雑な調整が必要で、取引プロトコルに必要な詳細なgRPCメソッドレベルルーティングが欠けています。エッジノードのサポートは限られており、Ciliumは頻繁に再起動するデバイスには適していません。

解決策C：SPIFFEおよび環境メッシュを用いた分散型Istioフェデレーション

各クラウドが独自のistiod制御プレーンを維持し、FluxまたはArgoCDを使用してGitOpsパイプラインで同期するIstioプライマリプライマリフェデレーションを採用します。ワークロードアテステーションのためにSPIREを実装し、S3バケットにあるフェデレート信頼バンドルを持ち、パーティション耐性のためにCloudFrontエッジキャッシングを利用します。エッジノードでは、リソースを節約するためにサイドカーの代わりにIstio環境メッシュのztunnelエージェントを使用します。地域ゲートウェイは、クラウド間でWireGuardトンネルを確立し、Envoyサイドカーがインターネットハブを通ることなく直接通信できるようにします。

**利点：**Envoyサイドカーは、gRPCルーティング、サーキットブレイキング、金融プロトコルに必要な再試行ポリシーを含む高度なトラフィック管理を可能にします。ネットワークパーティション中にSVIDがS3で公開されたバンドルに対して検証されるため、SPIFFEアイデンティティがローカルにキャッシュされ、ネットワークの分断に耐えられます。Ztunnelは、ノードごとに50MBのRAMを消費する一方で、ポッドごとには100MBを必要とし、大規模なデバイスもフルに参加できるようにします。
**欠点：**オペレーショナルの複雑さが大幅に増加し、チームは3つの独立した制御プレーンを管理する必要があり、EKS、AKS、GKE間のCRDバージョンの互換性を確保する必要があります。初期のブートストラップには、クロスクラウドS3アクセスのためのIAMロールの設定が必要です。

選ばれた解決策とその根拠

解決策Cは、WireGuardトンネルを介した直接のEnvoyサイドカー間通信によって厳しい50ms未満のレイテンシ要件を唯一満たすことができました。中央集権型OIDCプロバイダーに依存することなく、SPIFFEベースのアイデンティティを利用することで、パーティション中のゼロトラストセキュリティ保証を維持しました。このアーキテクチャは、環境メッシュztunnelを介してリソース制約のあるエッジノードを収容しましたが、解決策AとBは、いずれかのコスト、レイテンシ、またはエッジ制約に失敗しました。

結果

実装後、クロスクラウドレイテンシは38ms P99で安定し、50ms SLAを十分に満たしました。その後の予期しないAWSとAzure間のパーティション中、システムはキャッシュされたSVIDを使用し、スティールバットセーフルールを採用して94%のトランザクションスループットを維持しました。エッジノードのプロビジョニング時間は、手動のS3ブートストラップスクリプトにより、45分から90秒に短縮されました。月額ネットワーキングコストは、ネイティブトランジットゲートウェイピアリング推定に比べて60%削減され、約300Kドルの節約となりました。

候補者が見落としがちなこと

**質問：**ネットワークパーティション中に地域のSPIREサーバーが到達できない場合、SPIREはどのようにワークロードの偽装を防ぎますか？

**回答：**各ノードで稼働しているSPIREエージェントは、X.509 SVID証明書と公開鍵信頼バンドルのローカルキャッシュを保持します。ワークロードがmTLSを確立しようとする際、ピアは生のサーバーを照会するのではなく、ローカルにキャッシュされたバンドルに対してSVIDを検証し、パーティション中に認証が成功するようにします。SVIDは短いTTL（通常5分）を含み、ワークロードの特定の秘密鍵にバインドされ、キャッシュされた証明書が攻撃者に傍受されても再利用攻撃を防ぎます。パーティション中に参加する新しいワークロードは、AWS IAMインスタンスアイデンティティドキュメントやTPM EK証明書などのノードレベルのアテステーターを使用して、ローカルエージェントによってアテステーションされ、クロスクラウド接続が必要ありません。

**質問：**Istio環境メッシュは、従来のサイドカー注入と比較して一時的なエッジノードのリソース消費をどのように減らしますか？

**回答：**従来のIstioは、各アプリケーションポッドにEnvoyサイドカーコンテナを展開し、各インスタンスで約100MBのRAMと0.5vCPUを消費しますが、これはNVIDIA Jetsonのようなリソース制約のあるエッジデバイスまで浪費します。環境メッシュでは、ノード自体にztunnelをDaemonSetとして展開し、すべてのポッドがメッシュからのmTLSの終了とレイヤー4ルーティングを共有し、実質的に各ワークロードのオーバーヘッドをゼロに引き下げます。Ztunnelは、効率的なパケットリダイレクションのためにeBPFを利用してカーネルレベルでの、iptables経由のコストを回避します。エッジノードが頻繁にメッシュに参加したり離れたりする場合でも、ztunnelは地域ゲートウェイへの単一の永続的接続プールを維持し、数百の個々のサイドカーの初期化につながる接続確立の嵐やメモリスパイクを排除します。

**質問：**複数のクラウドフェデレーションにおける独立したIstio制御プレーン間で構成のドリフトを防ぐにはどうしますか？

**回答：**VirtualServiceおよびAuthorizationPolicyマニフェストを、フェデレートGitリポジトリに保管された単一のソースで真実と見なすGitOpsパイプラインを実装します。各地域の制御プレーンは、クラウド間でAWS CodeCommitのクロスリージョンレプリケーションやGitLab Geoを使用して複製されたこのリポジトリから構成を取得します。OPA（Open Policy Agent）承認Webhookを使用して、リポジトリの状態から逸脱するローカル修正を拒否します。CI/CDパイプラインで定期的にIstio構成分析ツールを実行し、デプロイ前にEKS、AKS、GKEクラスター間のCRDバージョンのズレを検出し、厳密な整合性を確保します。