詳解システム・パフォーマンス - 第11章：クラウドコンピューティング

クラウド環境固有のパフォーマンス問題

ベアメタルと異なり、クラウドではホスト側の状況がパフォーマンスに影響する。
自分のアプリが正常でも、ホスト（ハイパーバイザー）や隣のインスタンスが原因で遅くなることがある。

Steal Time（steal）

ハイパーバイザーが CPU を奪って他の VM に使わせている時間。
自インスタンスの CPU が必要なのに使えない状態 = クラウド固有のボトルネック。

# steal time の確認
vmstat 1 5
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
# r  b   ...                                              us sy id wa st
# 1  0   ...                                               5  2 80  2 11  ← st=11% !

# st 列が steal time（%）
# > 5% → ノイジーネイバーの影響あり
# > 20% → 深刻。インスタンスタイプの変更やリージョン変更を検討

# mpstat でコア別 steal を確認
mpstat -P ALL 1 5
# CPU  %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
#   0   10.0    0.0   5.0     0.0   0.0    0.0    15.0   70.0  ← steal 高い

ノイジーネイバー（Noisy Neighbor）

同一ホスト上の他のインスタンスがリソースを過剰に使用し、自分のインスタンスが影響を受ける問題。

検出方法

# CPU steal の確認
vmstat 1 | awk '{print $16}'  # st 列を抽出（5%超えで疑う）

# ネットワーク帯域がスロットリングされていないか
# AWS: CloudWatch で NetworkIn/Out を確認
# 急激なスループット低下 → ネットワークスロットリング

# ディスク I/O のスロットリング（クラウドプロバイダーによって IOPS 制限がある）
iostat -xz 1
# %util が低いのに await が高い → IOPS スロットリングの可能性
# AWS EBS: IOPS 制限に引っかかっていないか CloudWatch で確認

対策

# 短期的対策
# - インスタンスを停止・再起動（別のホストに移動する可能性）
# - リージョン・AZ の変更

# 長期的対策
# - 専有ホスト（Dedicated Host）を使う
# - 時間帯を変える（夜間に処理を分散）
# - CPU クレジットがあるか確認（AWS T系インスタンス）

AWS T系インスタンスの CPU クレジット

T系（t3, t4g 等）は通常時は CPU を制限し、バーストできる仕組みがある。

# CloudWatch でCPU クレジット残量を確認
# CPUCreditBalance が 0 に近い → バースト不可能

# CPU クレジット消費を確認
# CPUCreditUsage が高い → クレジットを消費している

# 対策：T系からM系（汎用）またはC系（コンピューティング最適化）へ変更

コンテナのリソース分析

Docker / Kubernetes のコンテナは cgroups でリソースを制限する。

CPU の制限と確認

# コンテナのCPU制限を確認（Docker）
docker inspect <container_id> | grep -i cpu
# "CpuShares": 1024       ← 相対的なCPU割り当て
# "NanoCpus": 2000000000  ← 2 CPU に制限

# コンテナ内から見た制限
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us    # -1 = 無制限
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us  # 通常 100000 (100ms)
# quota / period = CPU 数の制限
# 例: quota=200000, period=100000 → 2 CPU まで

# cgroup v2 の場合
cat /sys/fs/cgroup/cpu.max
# 200000 100000 → 2 CPU

# Kubernetes の場合（Pod の設定）
kubectl describe pod <pod-name> | grep -A2 "Limits\|Requests"

# コンテナの実際のCPU使用状況
docker stats <container_id>
# または Kubernetes
kubectl top pods

メモリの制限と確認

# Docker のメモリ制限確認
docker inspect <container_id> | grep -i memory
# "Memory": 536870912   ← 512MB に制限

# コンテナ内から見た制限
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
cat /sys/fs/cgroup/memory/memory.usage_in_bytes

# メモリ使用量が制限に近いか
# OOM が発生するとコンテナが強制終了される
docker stats --no-stream <container_id>
# MEM USAGE / LIMIT: 490MiB / 512MiB  ← 危険な状態

# コンテナの OOM 確認
dmesg | grep -i "kill process"
docker events --filter event=oom

仮想化のオーバーヘッド

ゲスト内での観測ツールの制限

ツール	ゲスト内での制限
`perf`	PMC（ハードウェアカウンタ）が使えないことがある
`dmesg`	ホストのハードウェアエラーが見えない
ストレージレイテンシ	ハイパーバイザーを経由するため予測困難
`steal time`	ホスト側の状況がゲストに影響

# PMC が使えるか確認
perf stat -e cycles sleep 1
# エラーが出る場合：ハイパーバイザーが PMC を許可していない
# → perf -e cpu-clock を使う（ソフトウェアカウンタ）

# 仮想化の種類を確認
systemd-detect-virt
# kvm / xen / vmware / none（ベアメタル）

クラウドネイティブな観測

# AWS CloudWatch Metrics
# - CPUSurplusCreditBalance: T系のクレジット状況
# - NetworkPacketsOut: パケット数（PPS 制限に引っかかっていないか）
# - VolumeReadOps/WriteOps: EBS の実際の IOPS

# GCP Cloud Monitoring
# - cpu/utilization: CPU 使用率
# - disk/write_bytes_count

# 外部から観測する重要性
# ゲスト内のツールだけでは見えない問題がある
# → SaaS モニタリング（Datadog, New Relic 等）との併用が効果的

クラウドのパフォーマンスチェックリスト

□ vmstat で steal time（st列）を確認（> 5% でノイジーネイバー疑い）
□ iostat で await が高いのに %util が低くないか（IOPSスロットリング疑い）
□ コンテナのメモリ使用量が制限に近づいていないか（OOM直前）
□ Kubernetes: kubectl top で CPU/メモリの実際の使用状況を確認
□ T系インスタンスの場合：CPU クレジット残量を確認
□ CloudWatch / Cloud Monitoring で外部からも確認
□ perf が PMC を使えるか確認（仮想化環境での制限）
□ ネットワーク帯域がスロットリングされていないか