これはAVA Hostingを否定的に評価するための記事ではありません。
開発者として過ごす、ある一日の記録です。サーバーの挙動がおかしい。ありがちな原因を調べても説明がつかない。そして最後に、Linuxのメトリクスが何が起きているのかを教えてくれました。
使っていたのはAVA Hostingの小規模なKVM VPSです。
1 vCPU
2 GB RAM
25 GB NVMe通常の本番ワークロードを動かしていました。Nginxは起動していました。backendも動いていました。メモリには余裕があり、ディスクも満杯ではありません。
それでも、サーバーは処理に追いつけていませんでした。
そこで通常の本番トラフィックを流したまま、60秒間のパッシブな計測を行いました。stress testも、人工的なHTTP floodも、disk benchmarkも実行していません。
結果は次のとおりです。
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11決定的だったのは、CPU stealが32.73%だったことです。ここで診断の方向が完全に変わりました。
なぜ意外だったのか
AVA Hostingは現在、VPSを“Guaranteed resources — no sharing”と説明しています。またVPS関連ページでは、vCPUをfixedまたはdedicated allocationとして説明し、他の顧客の影響で性能が左右されないとしています。Linux VPSの説明ではさらに踏み込み、同じホスト上の別tenantがCPU-intensiveな処理をしても、自分のinstanceにsteal timeを発生させることはないとしています。別ページには、CPU stealはhypervisorレベルで排除されるという説明もあります。
かなり具体的な主張です。単に1 vCPUとだけ書いてCPUの割り当て方法には触れていないサービスではありません。私のVM内でLinuxが示していたものと、まさに同種のCPU contentionから保護されると明示的に説明されていました。
CPU stealとは何か
stealは、仮想化環境でLinuxが記録する通常のCPUメトリクスです。guest側に実行可能な処理があるにもかかわらず、virtual CPUが実際には実行されていなかった時間を示します。
これは、アプリケーション自身がCPUを使い切っている状態とは異なります。もしuser/systemが約100%、stealが0%、idleが0%なら、単純にワークロードがより多くの計算能力を必要としていると判断していました。
ところが今回、CPU時間の約3分の1がstealとして記録されていました。
guest内部からAVAのhypervisorを見ることはできません。physical nodeの負荷、隣接VMの数、CPU pinning方針、overcommit ratioも分かりません。分かるのはLinuxがVMに報告した事実です。処理待ちの仕事があるのに、vCPUが繰り返し実行されていませんでした。
一瞬だけのスパイクではなかった
CPUの悪いサンプルが1回出ただけなら、それほど重くは見ません。そのため60秒間連続で計測しました。stress test、人工的なHTTP flood、disk benchmarkは意図的に実行していません。
1秒ごとの値は繰り返し次のようになっていました。
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00計測終了直前でも同じ傾向でした。
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.0060秒全体の平均は次のとおりです。
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%つまり、短時間のscheduler上の揺らぎではありません。ほぼ1分を通してstealは30%前後かそれ以上で、CPU idleは0%のままでした。
感覚的に言えば、1分間の32.73%は約19.64秒です。VPSが19.64秒間連続して停止したという意味ではありません。vCPUがscheduleされなかった短い時間が積み重なり、合計でその程度になったということです。
backendのキューが減らなかった
CPUの問題はアプリケーション側にも現れていました。計測前のbackendのlisten queueは次の状態でした。
Recv-Q: 168
Send-Q: 51160秒後:
Recv-Q: 166
Send-Q: 511168か166かという細かな数字は重要ではありません。重要なのは、キューが実質的に減っていないことです。1分間処理を続けても、backendは遅れを取り戻せませんでした。
CLOSE-WAITも多数ありました。ただし、これだけを根拠にホスト側の問題とは考えません。application側のconnection handlingでも発生し得るからです。それでも全体像は一貫していました。
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingプロセスは生きていました。しかしシステムは健全ではありませんでした。
RAMとディスクは明確なボトルネックではなかった
一般的な原因も確認しました。メモリは次の状態でした。
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBまだかなりのメモリが利用可能で、この挙動を説明するような明確なOOMイベントもありませんでした。
ファイルシステムは:
24 GB total
14 GB used
9.4 GB available
60% usedCPU I/O waitの平均は0.00%でした。一方でCPU pressureは約99%に張り付き、1 vCPUのVMでload averageは3.5〜4前後、runnable queueは最大11に達していました。
複数のメトリクスが同じ方向を示していました。RAMやstorageで詰まっているというより、CPU実行時間が足りていない状態です。
AVAの説明との食い違い
この部分が、私には最も興味深いところです。
AVAは“Guaranteed resources — no sharing”と説明しています。他の顧客によって性能が影響されないとも述べています。Linux VPSの説明では他tenantがsteal timeを発生させないとし、別ページではCPU stealをhypervisorレベルで排除するとしています。
ところが私のAVA VPSでは:
Average CPU steal: 32.73%VM内部から、なぜこうなったかを正確に証明することはできません。意図的なoversellingを証明することも、特定の隣接workloadを特定することも、AVA側ホストのCPU構成を再現することもできません。
すべてのAVA Hosting VPSが同じ挙動をするとも主張していません。私が計測したのは1台です。
ただし、私が実際に測定した挙動と、これらの具体的なCPU isolationの説明を両立させるのは非常に難しい、とは言えます。この話に必要なのはそこまでです。
なぜアップグレードしなかったのか
単純な対応なら、vCPUを増やすことです。
もしstealがほぼ0%で、アプリケーションが単純に1 coreを使い切っていたのであれば、アップグレードは合理的です。しかし今回は、観測したCPU時間のおよそ3分の1がstealでした。
最初のvCPUの実行時間がこれほど大きく「利用できなかった時間」として記録されている理由を理解しないまま、追加のvirtual CPUに料金を払う気にはなれませんでした。そのためVPSを解約し、返金を依頼しました。
AVAは全額をすぐに返金した
ここは良かった点です。
AVA Hostingは全額を返金しました。処理も速く、CPUの測定結果について何日も議論するようなことはありませんでした。問題を説明して返金を求めると、そのまま返金されました。
この対応には感謝しています。
したがって、私の経験には二つの別々の結論があります。提供されたVPSには深刻なCPU availabilityの問題があった。そしてAVAの返金対応は適切だった。どちらも事実です。
この経験から得たこと
今では、1 vCPU / 2 GB RAM / NVMe / KVMのようなスペックだけでVPSを判断しません。その数字が示すのは何がprovisionされたかであり、実際の負荷時にCPUをどれほど安定して使えるかではありません。
新しいVMでは、早い段階で次のような確認をします。
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60AVA Hostingでの経験から得た一番大きな教訓は、1 vCPUでは足りない、ということではありません。プロセスが起動していて、RAMに余裕があり、ディスクも正常に見えていても、その下にまったく別の問題が隠れていることがあるということです。
今回、Linuxはそれを非常に分かりやすく示していました。
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA HostingはCPUリソースを共有なしと説明し、隣接workloadによるstealは起きないとしています。しかし、私のVPSが報告した値は違いました。
私はVPSを解約しました。AVAは全額を素早く、争うことなく返金しました。
このデバッグの一日は、そこで終わりました。