SideCarは死んだのか？

編集者 |イーサン

企画 |趙雲

サイドカーの概念は、コンテナとマイクロサービスの世界では非常に一般的になっているため、サイドカーをクラウドネイティブ テクノロジー スタックの自然で健全な一部と考えるのは簡単です。

しかし、一歩引いて考えてみると、Sidecar は必ずしもそれほどエレガントではありません。マイクロサービスの規模が肥大化すると、サイドカー モデルも革新する必要があります。

最近のバイクにはサイドカーが付いているものがほとんどないのと同じです。結局のところ、サイドカーと呼ばれる理由は、それ自体には収まらないものを運ぶ必要がある場合に、バイクのサイドカーに取り付けることができるからです。しかし、サイドカーはオートバイの容量制限の問題を解決する一方で、速度を大幅に低下させ、操縦を困難にします。

サービスメッシュのサイドカーパターン

サービス メッシュは、分散アプリケーションのコンポーネントの接続、保護、監視に役立つテクノロジー スタックのレイヤーです。通常、モノリシック アプリケーションは、依存関係やプロセス間通信の複雑なネットワークなしで単一のプロセスとして実行されるため、サービス メッシュを使用しません。ただし、モノリシック アプリケーションをマイクロサービス アーキテクチャに移行する場合、3 つの大きな課題が発生します。まず、個別のマイクロサービス間の相互通信の課題に対処する必要があります。 2 番目に、マイクロサービス トランザクションが安全であることを確認する必要があります。 3 番目に、各マイクロサービスから観測可能性データを収集する効果的な方法が必要です。マイクロサービスの管理コストは莫大です。これらの問題がマイクロサービス自体のコード内で直接検出され、処理される場合、開発者は接続性、セキュリティ、および可観測性を処理するために、各マイクロサービス内でカスタム コードを面倒に記述して保守するのに多くの時間を費やすことになります。

サービス メッシュは、集中管理されたサービスを提供することでこの問題を解決します。本質的に、サービス メッシュを使用すると、開発者はマイクロサービスの接続、セキュリティ、および監視の管理に必要な作業の多くを、マイクロサービス自体内でこれらのタスクを処理するのではなく、専用のインフラストラクチャ レイヤーに「アウトソーシング」できます。このように、サービス メッシュはマイクロサービスの管理方法を簡素化し、標準化するのに役立ちます。もちろん、サービス メッシュはマイクロサービスと直接通信したり統合したりすることはできません。そこで「サイドカー パターン」が登場します。サイドカーは、サービス メッシュがマイクロサービスと通信する方法になります。

サイドカー モードでは、各マイクロサービスのビジネス ロジックをホストするメイン アプリケーション コンテナーに加えて、特別なサイドカー コンテナーをデプロイする必要があります。サイドカーは、マイクロサービスの管理を担当するサービス メッシュ プロキシをホストします。サイドカー コンテナとメイン コンテナを同じポッドで実行すると、両方ともサービス メッシュで定義されたガバナンス ルールを適用できます。サイドカー パターンは、コンテナーとしてデプロイされ、Kubernetes を使用してオーケストレーションされる分散アプリケーション内のマイクロサービスを管理する場合に適しています。サービス メッシュを単一のアプリケーション コンテナーに接続するためのより優れたテクノロジがない場合、実際のマイクロサービスと一緒にサイドカー コンテナーをデプロイすることは、サービス メッシュをマイクロサービス アーキテクチャにオーケストレーションするシンプルで簡単な方法です。

Istioが人気なのも理由がある

現在では、Linkerd や Traefik など、多くのサービス メッシュが存在します。しかし、おそらく最も人気のあるソリューションは、Kubernetes 中心のスタック用に設計されたオープンソースのサービス メッシュである Istio です。

出典: istio.io

Istio は、2 つの主要コンポーネントを提供することでサービス メッシュを実装します。1. 個々のマイクロサービスと対話するために Envoy プロキシを実行する Sidecar コンテナーに依存するデータ プレーン。 2. コントロール プレーンは、サービス検出を提供し、構成を適用し、トラフィックを保護するための集中プロセスとして実行されます。

Istio はオープンソースの性質と Kubernetes に適した設計により、これまでに何千ものクラウドネイティブ ホスティング スタックの中核を成すツールとなっています。

サイドカー依存の問題

Istio や Sidecar モデルに依存するその他のサービス メッシュは多くの実用的な問題を解決しますが、多くの問題の種も撒き散らします。 Sidecar は完璧な解決策ではありません。分散アプリケーションの大規模な接続、保護、監視の管理ニーズに直面している Istio のようなサービス メッシュには、リソース消費量が多いこととパフォーマンスが低いことという2 つの重要な問題があります。

1. リソースオーバーヘッド

分散ホスティング環境では、各マイクロサービスでサイドカー コンテナを隣り合わせて実行する必要があり、実行中のコンテナの合計数が 2 倍になります。つまり、アプリケーションはより多くのリソースを消費することになります。

サイドカー コンテナー自体によって消費されるリソースに加えて、オーケストレーターによってサイドカーの管理の負担も加わります。同時に、開発者は Sidecar を展開および更新するときに、より多くのネットワーク帯域幅を消費することになります。

つまり、Sidecar を実行すると、かなりの量のリソースが占有され、実際のアプリケーションで使用できるリソースが削減され、ピーク需要時にパフォーマンスが低下する可能性があります。もちろん、ワークロードを処理するには最終的にはより多くのノード (またはリソース割り当てが高いより高価なノード) が必要になるため、ホスティング コストも上昇します。

2. パフォーマンスとレイテンシー

Sidecar をホストするコストに加えて、Sidecar コンテナーは各マイクロサービスに出入りするネットワーク トラフィックに介入する必要があり、必然的にパフォーマンスが低下します。アプリケーションがリクエストを受信して​​応答する前に、すべてのパケットがサイドカーを通過する必要があるため、レイテンシが増加し、ユーザー エクスペリエンスに悪影響を与える可能性があります。

サイドカーモードでの Istio のパフォーマンス

サイドカー コンテナのパフォーマンス オーバーヘッドはどれくらいですか? Istio 自体によって記録された関連データを見てみましょう。 Istio のデータによると、各 Envoy プロキシは 1,000 件のリクエストごとに 0.35 vCPU と 40 MB のメモリを消費します。もちろん、パフォーマンスのオーバーヘッドは、Istio を具体的に何のために構成するかによって異なります (使用する機能が多いほど、オーバーヘッドは高くなります)。

したがって、マイクロサービスが 10 個あり、各マイクロサービスに Envoy サイドカーをデプロイする場合、それらをホストするために追加の 3.5 個の vCPU と 400 MB のメモリが必要になります。これは、サイドカーを実行するための追加の VM インスタンスと同等に簡単に変換できます。 (Istio によると、それでも追加の 1 つの vCPU と 1.5 GB のコントロール プレーンを使用する必要があります。) また、Istio によると、各プロキシ コンテナーによって 90 パーセンタイルのレイテンシが平均 2.65 ミリ秒長くなることに注意してください。つまり、Sidecar を使用すると、応答速度も同じだけ遅くなります。

2.65 ミリ秒は短いように思えるかもしれませんが、1 ミリ秒も無駄にできないネットワークの世界では、特に真のリアルタイムで実行する必要があるアプリケーションの場合、非常に大きな混乱を招く可能性があります。

eBPF をベースにした「ボーダレスカー」の実装

開発者や IT チームは、サイドカー コンテナーによって発生するパフォーマンスとレイテンシーのコストを必要悪と見なすことがよくあります。サイドカー パターンでサービス メッシュを使用する方が、サービス メッシュを使用せずに各マイクロサービスで管理するよりもはるかに簡単なので、ホスティングに多額の費用を支払ったり、パフォーマンスの低下を受け入れたりして、サービス メッシュ内でマイクロサービス管理を集中化しても構わないと考えています。

しかし、今日では、より良い世界が実現可能になっています。eBPF により、カーネル モジュールを扱ったり、カーネル ソース コードを変更したりすることなく、超効率的で超安全な動的コードを Linux カーネルで直接実行できるようになりました。

サービス メッシュを必要とするエンジニアにとって、これは、eBPF を使用することで、従来はサイドカー コンテナを使用して実装されていたマイクロサービス ガバナンスを、eBPF プログラムを介してカーネル内で処理できることを意味します。 eBPF プログラムは Kubernetes クラスター内のすべての (Linux ベースの) ノードで実行できるため、別個のサイドカーとして実行することなく、カーネル内で直接マイクロサービスの接続、セキュリティ、および可観測性を管理できます。このアプローチには、Istio などの従来のサービス メッシュに比べて大きな利点があります。

• パフォーマンス: eBPF プログラムは最小限のリソースしか消費しないため、サイドカー アーキテクチャを使用する場合と比較して、サービス メッシュの実行のオーバーヘッドが大幅に削減されます。
• シンプルさ: eBPF ベースのサービス メッシュにより、サイドカー コンテナのセットを展開して管理する必要がなくなります。
• 可視性と制御: カーネル内で直接実行することにより、eBPF プログラムは、コンテナー内からアクセスできるデータとそのデータに対して実行できる制御に関して、事実上無制限の範囲を持ちます。この点で、eBPF に基づくメッシュは、サイドカー コンテナーに依存するメッシュよりも強力になります。

eBPF を活用して従来のサービス メッシュの欠点を解決するというのは、比較的新しいアイデアです。現在、開発者はこの戦略にますます注目しており、Cilium はすでにこれを実装しています。

Cilium: eBPF に基づくノード プロキシ モードの高速化

eBPFの明るい未来

サービス メッシュ ソリューションの「潜在的なストック」として、eBPF は、開発者が分散アプリケーションのセキュリティ、監視、管理に対処する方法において「新星」になりつつあります。これにより、開発者はサイドカー モデルから解放され、既存のプロキシ テクノロジを既存のカーネル名前空間の概念に統合できるようになり、ネイティブで効率的なサービス メッシュ実装パラダイムが提供されます。

eBPF は、可観測性のための豊富なデータの収集を容易にし、コンテナ内およびコンテナ間で流れるデータに必要なセキュリティを提供することに加えて、サービス ネットワーキングにおける「カーネル レベル」のイノベーションにも使用でき、現在エージェントによって実行されている多くの機能をオフロードして、よりシンプルで効率的、かつリソースをあまり消費しない方法でマイクロサービス間のやり取りを管理します。

サイドカーは消えてしまうのでしょうか？

常に「サイドカー」を採用してきた Istio でさえ、その限界を認識していると言わざるを得ません。 9 月 7 日、Istio は新しいデータ プレーン モードである Ambient Mesh を発表しました。このモードのハイライトは、サイドカー中心のアーキテクチャをキャンセルし、サイドカーを使用しないアプローチに置き換えながら、ゼロトラスト セキュリティ、テレメトリ、トラフィック管理という Istio のコア機能を維持することです。

Istio の担当者は次のように語っています。「当初から、Istio アーキテクチャの重要な機能の 1 つは Sidecar の使用でしたが、Sidecar モデルではアプリケーションと Istio データ プレーン間の完全な分離が提供されないため、侵入度が高く、リソースの使用率が不十分で、トラフィックが中断されるなどの問題が発生します。ユーザーには、侵入度が低く、使いやすいオプションが必要です。」もちろん、これは「サイドカー モデル」に依存する Istio やサービス メッシュが廃止されることを意味するものではありません。 Istio コントロール プレーンは依然として存在するものの、データ プレーンはサイドカー コンテナーで実行される Envoy プロキシではなく、eBPF プログラムによって駆動される世界を想像することができます。 Istio は、サービス検出と構成管理のための強力なテクノロジーを多数開発しており、これらの機能は eBPF ベースのサービス メッシュで引き続き注目されるでしょう。バイクにサイドカーを取り付けたのと同じように、今後数年で「サイドカー モデル」も徐々に時代遅れになることが予想されます。スピードと効率を優先する企業や開発者は、再び eBPF を採用し、Sidecar の制限から解放されるでしょう。

参考リンク

https://www.groundcover.com/blog/istio-service-mesh

https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

https://istio.io/latest/blog/2022/introducing-ambient-mesh/