Red Hat が Istio 1.20 をリリースしたとき、話題は WebAssembly プラグイン、改善されたテレメトリ、そして長らく約束されていたマルチクラスター連携といった、キラキラした新機能ばかりだった。特に Red Hat エコシステム、すなわち OpenShift に深く根差している Kubernetes ユーザーにとって、これは次なる大きな飛躍となるはずだった。その約束は？ より強力に、より制御可能に、そして… あらゆる面で進化すること。小規模なデプロイメントなら、おそらくそうなのだろう。だが、実際にこれを限界まで引き上げようとしたら、どうなるか？ そこからが、この話が面白く——そして高価になる部分だ。
これは Istio が良いか悪いかの話ではない。Kubernetes のツールボックスにおける標準的な存在であり、テックカンファレンスでの静電気のようにどこにでもある。いつも通り、本当に問われるべきは、実際に踊り始めるときに誰がツケを払うのか、ということだ。そして Istio 1.20 と OpenShift の場合、その請求書は誰も予想していたよりも高く、速く積み上がっているようだ。
パフォーマンスの代償
マーケティング資料は、我々皆が目にしてきたものだ。企業は最新リリースを記念碑的な前進だと喧伝するのが大好きだ。しかし、何千ものポッドを管理していると、わずかな非効率性でさえ、壊滅的なオーバーヘッドへと積み重なる。そして、まさに最近のベンチマーク研究が掘り下げたのは、まさにその点だ。Istio 1.20.1 を Red Hat OpenShift 4.14 上で検証している。彼らは AWS 上に標準的な 8 ノードクラスターを構築し、Nginx Plus Web サービスをロードした後、1,000 ポッドから 10,000 ポッドへと負荷を上げたときに何が起こるかを見た。結果は、スムーズでコスト効率の良い運用を期待していた人々にとっては、決して見栄えの良いものではない。
彼らが発見したのは、Istio 1.20 の目玉機能——Wasm プラグイン検証や、より強力なテレメトリパイプラインといったもの——が無料では手に入らないということだ。1,000 ポッドの時点で、コントロールプレーン (istiod) は約 2 vCPU と 6GB の RAM で稼働していた。これは管理可能だろう？ さて、10,000 ポッドまで早送りしてみよう。突然、istiod はなんと 8 vCPU と驚異の 24GB RAM を要求し始めたのだ。これはベースラインから CPU で 300%、メモリで 400% の増加だ。さらに注目すべきは、これが同規模の Istio 1.19 の 2 倍であることだ。増分改善もかくや、という感じだ。
そして、コントロールプレーンだけではない。すべてのポッドが、より強力な Envoy サイドカーの負担を背負うことになる。Istio 1.20 では、前バージョンと比較して、サイドカーあたり 15% のメモリと 8% の CPU が追加で必要になる。1,000 ポッドでは、クラスターに 18GB の追加 RAM が投入されることになる。これを 10,000 ポッドにスケールさせると、サイドカーをサポートするためだけに、インフラ全体で 180GB のメモリと驚愕の 800 vCPU コアが追加で必要になる。この表は、厳しい現実を物語っている。
| Scale (Pods) | Avg Sidecar Memory (MB) | Avg Sidecar CPU (vCPU) | Total Sidecar Resource Cost (Relative to No Istio) |
|---|---|---|---|
| 1,000 | 138 | 0.14 | 1.2x |
| 5,000 | 141 | 0.16 | 1.8x |
| 10,000 | 145 | 0.18 | 2.3x |
これは単なるわずかな上昇ではない。Istio を実行するために必要なリソースフットプリントの根本的な増加であり、複雑なトラフィックポリシーを適用する前の話だ。
レイテンシの静かな侵食
レイテンシは分散システムの悩みの種だ。わずか数ミリ秒の違いが、応答性の高いアプリケーションと、もたつくアプリケーションを分けることになる。低トラフィックレベル (同時リクエスト 100 件) では、Istio 1.20 は p99 レイテンシにわずか 3ms の追加となる。しかし、これは最良のシナリオだ。これを同時リクエスト 5,000 件まで押し上げると、ベンチマークによれば、サービスメッシュなしのベースラインと比較して p99 レイテンシが著しく 22% も増加している。さらに悪いことに、同負荷下での Istio 1.19 と比較しても 12% の増加だ。どうやら、新しいデフォルトのテレメトリ処理が、たとえその派手なテレメトリ機能を使っていなくても、すべてのリクエストにオーバーヘッドを追加しているようだ。高性能スポーツカーを買ったのに、ベースモデルにはパラシュートが常時展開されているようなものだ。
運用上の頭痛の種
生のリソース消費量やレイテンシを超えて、運用コストがある。設定伝搬を覚えているだろうか？ これは、ルーティングルールの更新のような変更を加えてから、それがすべてのポッドに実際に反映されるまでの時間だ。Istio 1.20 では、このウィンドウは 1,000 ポッドでの 2 秒から、10,000 ポッドに達すると 45 秒という氷河期のような遅延へと広がる。そしてアップグレードは？ 短時間で終わるメンテナンスウィンドウは忘れよう。5,000 ポッドクラスターでのアップグレードは、Istio 1.20 では 10.5 分かかったが、1.19 では 8 分だった。大規模なデプロイメントでは、以前は必要なかったかもしれないメンテナンス期間の計画が必要になり、運用上の摩擦がさらに一層増えることになる。
そしてテレメトリそのものだ。Istio 1.20 は、デフォルトで 12 個の新しいメトリクスを放出する。良いことだが、5,000 ポッドを超えるクラスターでは、Prometheus テレメトリの量が驚異の 40% も増加する可能性がある。多くの ops チームがそうするように、30 日分のメトリクスを保持している場合、ストレージコストが約 35% 増加することになる。そして、もし新しい Wasm プラグインを実際に 使用 することにしたら？ プラグイン 1 つにつき、さらに 10ms のレイテンシと 5% のサイドカーメモリ追加だ。これは、「あると便利」な機能の連鎖が、静かにインフラの請求書を膨らませていく。
「Istio 1.20 は、デフォルトで 12 個の新しいデフォルトメトリクスを有効にし、5,000 ポッド以上のクラスターでは Prometheus テレメトリの量を 40% 増加させます。」
今後の道 (どうしても進むなら)
この文章は、単に悪口を言うためだけにあるわけではない。OpenShift 上の Istio を既に選択した人々にとっては、いくつかの賢明なアドバイスも提供している。不要な機能を無効にすることは当然——Wasm 検証を使用しないなら、オフにすればいい。Istiod およびサイドカーにハードなリソース制限を設定することで、暴走する消費を防ぐことができる。Istio リビジョンを使用してゼロダウンタイムアップグレードを行うのは標準的なプラクティスだが、言及する価値はある。そして、OpenShift の Node Tuning Operator を使ってワーカーノードを最適化すれば、Envoy サイドカーのオーバーヘッドをいくらか削減できる。メトリクスをソースでフィルタリングすることも、テレメトリ量を大幅に削減できる。これらは、すべて良い、実践的なステップだ。
しかし、私がここで得た教訓は、20 年にわたる技術トレンドの移り変わりを見てきた経験から、複雑なシステムにおける機能肥大化の避けられない結果を目にしているということだ。Istio 1.20 は確かに、より高機能になっている。しかし、その複雑性の増加とデフォルト設定は、ある一定のポイントを超えてスケールさせるときに、重大で、しばしば隠されたパフォーマンスとコストのペナルティを伴う。オープンソースの「無料」は、これらの強力なツールを大規模で効果的に実行するために必要なエンジニアリング時間とインフラコストには及ばない、ということを思い出させる。もしあなたが綿密にベンチマークとチューニングを行っていなければ、お金——そしてパフォーマンス——をテーブルの上に置きっ放しにしている可能性が高い。
これは Istio の終焉か？ まったくそうではない。多くの人にとって、依然として事実上の標準だ。しかし、高スケールの OpenShift 環境にデプロイを計画している人々にとっては、深刻な警告信号だ。高度な機能の約束は魅力的だが、ベンチマーク結果は厳しい現実を浮き彫りにしている：Istio 1.20 を OpenShift 上でスケールさせるコストは、当初予想していたよりもはるかに高くなる可能性があり、パフォーマンスの低下や予期せぬインフラの急増を避けるためには、慎重な計画と積極的な最適化が求められる。
