[論文レビュー] Dissecting Service Mesh Overheads

Xiangfeng Zhu, Guozhen She+10 more|arXiv (Cornell University)|Jul 2, 2022

Cloud Computing and Resource Management被引用数 6

ひとこと要約

この論文では、サイドカー操作を独立したコンponent（例：IPC、ソケット書き込み、プロトコルパースィング）としてモデル化することで、サービスメッシュのオーバーヘッドを構成的（compositional）に分析するツールであるMeshInsightを紹介する。その結果、構成やワークロードに応じてオーバーヘッドは大きく変動し、遅延は最大で185%増加し、CPU使用率は92%上昇する。HTTP/gRPCモードではプロトコルパースィングが主な要因となり、TCPモードではIPCおよびソケット操作が支配的であることが明らかになった。

ABSTRACT

Service meshes play a central role in the modern application ecosystem by providing an easy and flexible way to connect different services that form a distributed application. However, because of the way they interpose on application traffic, they can substantially increase application latency and resource consumption. We develop a decompositional approach and a tool, called MeshInsight, to systematically characterize the overhead of service meshes and to help developers quantify overhead in deployment scenarios of interest. Using MeshInsight, we confirm that service meshes can have high overhead -- up to 185% higher latency and up to 92% more virtual CPU cores for our benchmark applications -- but the severity is intimately tied to how they are configured and the application workload. The primary contributors to overhead vary based on the configuration too. IPC (inter-process communication) and socket writes dominate when the service mesh operates as a TCP proxy, but protocol parsing dominates when it operates as an HTTP proxy. MeshInsight also enables us to study the end-to-end impact of optimizations to service meshes. We show that not all seemingly-promising optimizations lead to a notable overhead reduction in realistic settings.

研究の動機と目的

• 多様な構成とアプリケーションワークロードにわたるサービスメッシュのパフォーマンスオーバーヘッドを体系的に特徴づけること。
• サイドカーにおける主なオーバーヘッド要因（例：IPC、ソケット操作、プロトコルパースィング）を同定すること。
• 完全な構成をデプロイせずにエンドツーエンドのパフォーランス影響を推定できるようにすること。
• Unixドメインソケットやゼロコピー書き込みといった最適化の実世界での有効性を評価すること。
• 機能とパフォーマンスのトレードオフを踏まえた意思決定を、サービスメッシュおよびアプリケーション開発者に支援すること。

提案手法

• サイドカー・プロキシの動作を、読み取り、書き込み、IPC、プロトコルパースィングといった独立したコンponentに分解する。
• コールグラフ、リクエストレート、メッセージサイズを用いてアプリケーションワークロードをモデル化し、エンドツーエンドのオーバーヘッドを推定する。
• 実際のEnvoyサイドカーのデプロイを用いて、コンponentレベルのオーバーヘッドを測定・定量する測定駆動型アプローチを採用する。
• TCP、HTTP、gRPCモードといった異なるサービスメッシュ構成で、サイドカー動作のインストルメンテーションおよびプロファイリングに用いるツールチェーンを活用する。
• Linuxカーネル機能（Unixドメインソケット、ゼロコピー書き込み）を活用し、パフォーマンス向上を評価する。
• コンponentレベルの測定結果とワークロードモデルを統合することで、完全なデプロイなしにシステム全体のパフォーランス影響を予測する。

実験結果

リサーチクエスチョン

• RQ1 異なる構成において、サービスメッシュサイドカーにおける遅延およびCPUオーバーヘッドの主な要因は何か？
• RQ2 アプリケーション固有の特性（例：リクエストレート、メッセージサイズ、コールグラフ）は、サービスメッシュのパフォーマンスにどのように影響するか？
• RQ3 一般的な最適化（例：Unixドメインソケット、ゼロコピーI/O）は、実世界のシナリオでエンドツーエンドのオーバーヘッドをどの程度低減できるか？
• RQ4 プロキシモードごとに、プロトコルパースィングのオーバーヘッドとシステムレベルの操作（例：IPC、ソケットI/O）のオーバーヘッドを比較するとどうなるか？
• RQ5 完全なデプロイなしに、構成的モデリングアプローチでエンドツーエンドのパフォーマンスを正確に予測できるか？

主な発見

• サービスメッシュのオーバーヘッドは著しく変動し、構成やアプリケーションに応じて遅延は30–185%増加し、CPU使用率は41–92%上昇する。
• HTTP/gRPCモードでは、プロトコルパースィングが合計オーバーヘッドの62–73%を占め、パフォーマンスの主要なボトルネックとなっている。
• TCPモードでは、IPCおよびソケット書き込み操作がオーバーヘッドの主な要因であり、合計でパフォーマンスコストを支配している。
• 個々のフィルタは、ベースラインオーバーヘッドに対して3%から85%の追加遅延をもたらすことがあり、フィルタの効率に著しいばらつきがあることが示された。
• Unixドメインソケットやゼロコピー書き込みといった最適化はオーバーヘッドを低減するが、その実世界での影響は文脈依存であり、一様に有益とは限らない。
• 同じ構成下でも、異なるアプリケーションでオーバーヘッドは桁違いに異なるため、アプリケーションに応じたパフォーマンス分析の必要性が強調される。