『詳解 システム・パフォーマンス 第2版』を読む:第11章 クラウドコンピューティングの全容

Progress 4 / 13
目次

はじめに

[!NOTE] この記事は、筆者が鈍器本を読みながら書き殴った個人的な読書メモをAIに食べさせ、ブログ用に読みやすく再構成させたものです。

これまで「2章 メソドロジ」や「5章 アプリケーション」などでパフォーマンス分析の土台を整理してきましたが、今回は現代のエンジニアにとって避けては通れない「11章 クラウドコンピューティング」です。

クラウドは一瞬でサーバーを構築・破棄できる魔法のような仕組みですが、その裏では「仮想化のオーバーヘッド」や「他テナントとのリソース競合」といった、物理サーバー時代には存在しなかったクラウド特有の強烈なパフォーマンスの闇が生み出されています。

今回も、細かい仕様の羅列はバッサリ切り捨て、現場で「なぜかクラウド上でだけアプリが遅い!」となったときに見返すためのサバイバル術だけを抽出しておきます。


1. 最大の敵「見えないリソース競合(うるさい隣人)」

クラウド(KVM等のハードウェア仮想化やコンテナ)の最大の特徴は、見知らぬ他テナントと同じ物理サーバーを共有する「マルチテナンシー」です。

  • 「うるさい隣人(Noisy Neighbor)」問題: 同じ物理ホストにいる別のテナントがCPUキャッシュ(L1やLLC)を汚染したり、デバイスの割り込み処理でこちらのCPUを奪ったりしてきます。
  • 見えない恐怖: セキュリティの都合上、ゲストOSの内部からは**「他のテナントが何をしていて、どれくらいリソースを食っているか」が絶対に観測できません**。自分は何も悪いことをしていないのに急にレイテンシが跳ね上がる、というのがクラウドの恐ろしい日常です。
  • 「st(Steal Time)」で証拠を掴む: 他のテナントのことは直接見えなくても、top コマンド等で表示されるCPU使用率の st(Steal Time)の項目を見ることで、「ハイパーバイザー(や他のうるさい隣人)に自分たちのCPU時間をどれだけ奪われているか」という間接的な証拠を掴むことができます。

2. クラウドを乗りこなす「2つの機能と罠」

クラウドならではのリソース管理の仕組みを知らずに運用すると、思わぬ落とし穴にハマります。

バースティング(Bursting)

「シェア」や「帯域幅」の制限を超えて、他テナントがアイドル状態のときに一時的にリソースを限界突破して借りられる仕組みです。便利ですが、「普段はバースティングのおかげで速かったのに、他のテナントが忙しくなった途端に急激に遅くなる」というパフォーマンスのブレ(ばらつき)を生む原因にもなります。

オーバープロビジョニングのリスク

AWSのASG(Auto Scaling)などで負荷に応じて自動でサーバーを増やすのは素晴らしいですが、罠もあります。たとえばDoS攻撃などの異常なリクエストを「正常な負荷の増加」と勘違いし、高額なコストでサーバーが無限にスケールし続けてしまうリスクです。スケーリングの条件(上限)は必ず精査しておく必要がありますね。


3. コンテナ特有の「CPU抑制(Throttling)」を見抜く

Linuxコンテナ(OS仮想化)は非常に軽量ですが、コンテナの視界を縛る「名前空間」と、物理リソースを縛る「cgroup」というソフトウェア制限によって動いています。物理限界よりも先に、この「cgroupによる帯域幅制限」に引っかかって遅くなることがよくあります。

自分が設定したコンテナが帯域幅制限に引っかかっているかは、/sys/fs/cgroup/.../cpu.stat などのファイルを見れば一発でわかります。

  • throttled_time(抑制時間の合計)が増えているか?: ここが増え続けている場合、物理CPU自体はスカスカなのに、「自分たちに設定されたCPU上限」に達して無理やり待たされている(帯域幅抑制)状態です。これを解決しない限り、いくらコードを改善してもスループットは伸びません!

4. 可観測性ツールの「ダマシ」に注意

Linuxの従来型ツール(topuptime など)は、ハードウェアの物理リソースを見るように作られており、コンテナの「ソフトウェアによる制限(cgroupなど)」には無頓着です。

コンテナ内から uptime を叩いても、出てくるのは「コンテナ独自のロードアベレージ」ではなく**「ホスト全体のロードアベレージ」**だったりします。「コンテナの中から見ている数値が、実は自分のものではないかもしれない」という疑いの目をもつことが、トラブルシューティングの第一歩になります。

  • 恐怖!ホストとコンテナでPIDが違う(名前空間の罠) セキュリティ上、コンテナ内(PID名前空間)では自分が「PID 1」のように見えていても、ホストOS側から見ると全く別の巨大なPID(例: 24500)が割り当てられています。もしホスト側にアクセスしてプロファイリングしようとする場合、「コンテナの中のプロセスを探そうとしても、ホスト側で見るとPIDが全然違って見つけられない…」という名前空間の罠に絶望することがあります。

おわりに

この章を読むことで、クラウドでベンチマークを取る際に「なぜ何もしていないのにレイテンシが跳ね上がるのか(うるさい隣人)」、「なぜ想定スループットが出ないのか(コンテナのCPU帯域幅抑制)」といった疑問を、論理的に解き明かせるようになります。

正直なところ、自分で知っていた以外の細かい仮想化の仕組みは一度では到底頭に入りきらなかったです(多分)。軽い興味で読み始めたら予想以上に重厚でしたが、クラウドで謎の遅延に遭遇したときは、とりあえず「cgroupの throttled_time とうるさい隣人の影響」を最初に疑う筋肉はついたと思います!