Performance BaselineとBottleneckを特定する

前提

以下は既習として扱います。

• 正常時のパフォーマンスベースラインを持つ
• KPIが悪化した時間帯とメトリクスを比較する
• 高い利用率だけでボトルネックと断定しない
• Amazon CloudWatchなどで必要なメトリクスを取得する

このページではこれらを再講義しません。

新しく見るのは、CPU・メモリ・I/O・ネットワークでは、性能制約を示す証拠がそれぞれ異なるという点です。

1. 同じ「性能悪化」でも見る証拠は異なる

例えば利用者向けレイテンシーが悪化していても、確認する証拠は資源ごとに異なります。

重要なのは、すべての資源に同じ判定方法を当てはめないことです。

2. CPUは比較対象の1つとして扱う

CPUの制約判断そのものは既習です。

ここではCPUを、メモリ・I/O・ネットワークと並ぶ比較対象の1つとして扱います。

例えばCPU使用率が高く見えても、それだけを理由に他の資源メトリクスを調べずに原因を確定してはいけません。

反対にCPU使用率が低い場合でも、メモリやI/Oなど別の資源に性能制約が存在する可能性があります。

3. メモリでは「CPUとは別の圧迫状態」を見る

メモリ不足はCPU使用率だけでは判断できません。

例えば、

正常時
利用可能メモリ 8GiB
スワップほぼなし

問題発生時
利用可能メモリ 300MiB
スワップ増加

という変化があれば、メモリ圧迫を調査する根拠になります。

確認対象には、

利用可能メモリ

メモリ使用率

スワップ使用量

ページング

などがあります。

ここでは必要なOS内部メトリクスは取得済みとします。

重要なのは、

CPUに余裕がある
=
メモリにも余裕がある

ではないことです。CPUとメモリは別の資源として読み分けます。

4. I/Oでは「どの性能上限へ到達したか」を見る

ストレージI/Oでは、

IOPS

スループット

I/Oレイテンシー

を区別します。

対応条件を満たすAmazon EBSボリュームでは、

VolumeIOPSExceededCheck

VolumeThroughputExceededCheck

も利用できます。

VolumeIOPSExceededCheck

1の場合、その期間中にアプリケーションがボリュームのプロビジョニングされたIOPS性能を超える処理を継続的に要求したことを示します。

VolumeThroughputExceededCheck

1の場合、その期間中にアプリケーションがボリュームのプロビジョニングされたスループット性能を超える処理を継続的に要求したことを示します。

したがって、

VolumeIOPSExceededCheck = 1
VolumeThroughputExceededCheck = 0

と、

VolumeIOPSExceededCheck = 0
VolumeThroughputExceededCheck = 1

では、制約を示している性能軸が異なります。

この2つを単に「EBSが遅い」とまとめないことが重要です。

なお、これらのメトリクスはすべてのEBS利用形態で利用できるわけではありません。マグネティック（standard）を除く、Nitroインスタンスに接続された対応ボリュームなどが対象で、Multi-Attachが有効なボリュームではサポートされません。

5. NetworkIn / NetworkOutは転送レートそのものではない

Amazon EC2では、NetworkIn、NetworkOutをCloudWatchで確認できます。

ただし、NetworkOutの値をそのまま1.6 Gbpsのような転送レートとして扱うことはできません。

NetworkOutは、指定された期間中にインスタンスから送信されたBytesです。

例えば1分間のNetworkOutのSumが、

12,000,000,000 Bytes

なら、

12,000,000,000
÷ 60秒
=
200,000,000 Bytes/秒

です。

bit/秒へ換算すると、

200,000,000
× 8
=
1,600,000,000 bit/秒

≒ 1.6 Gbit/秒

となります。

このように、インスタンスのネットワーク性能と比較する場合は、期間内のBytesから転送レートへ換算して比較します。

6. ネットワークでは性能条件と単位を揃える

ネットワークのメトリクスを見るときは、NetworkOutが大きいだけでは不十分です。

確認したいのは、

CloudWatchで取得した値
↓
比較可能な転送レートへ変換
↓
使用中のインスタンスのネットワーク性能条件と比較

です。

つまり、CloudWatch側のBytes / Periodと、インスタンス側のGbpsなどの性能条件のように単位が異なる場合は、そのまま比較せず揃えます。

このページでは、ネットワークが原因かどうかを一般論として再判定するのではなく、ネットワーク制約を調査するときに正しい測定値を作ることに責任を限定します。

7. 問題発生時間に合わせて期間と統計を見る

短時間だけ発生した問題に対して長時間の平均値だけを見ると、変化が平均化される場合があります。

例えば、

13:20〜13:30
p95レイテンシー悪化

という事象に対して、

13:00〜14:00
CPUUtilization Average

だけを見ても、13:20〜13:30の状態を十分に表していない可能性があります。

そのため、

問題発生時間
+
期間
+
統計

を対応させます。

ここでの目的はCloudWatch統計機能そのものを覚えることではありません。KPIとリソースメトリクスが同じ事象を比較できる時間粒度になっているかを確認することです。

8. 資源ごとの証拠を整理する

こうすると、「CPUが高い」「EBSが遅い」「NetworkOutが多い」という曖昧な表現ではなく、どのメトリクスがどの性能制約を示しているのかを切り分けられます。

9. 複数の制約を同時に観測した場合

実環境では、メモリ圧迫とI/O性能上限超過のように複数の異常が同時に現れる場合があります。

この場合、現在のデータだけで1つの主原因へ確定できるとは限りません。

必要なら、

より細かい時間粒度

追加メトリクス

アプリケーション側の計測

などを使って候補をさらに絞ります。

複数の証拠が存在するのに、数値が最も大きい資源だけを機械的に主原因と決めないことが重要です。

10. このページで決めないこと

このページの終了地点は、CPU・メモリ・I/O・ネットワークについて、どの資源に制約を示す証拠があるかを説明できるところまでです。

例えばCPU側に制約を確認できても、

水平スケーリング

垂直スケーリング

インスタンスファミリー変更

Auto Scaling

配置方法変更

のどれを採用するかはまだ決めません。

次の学習では、特定したコンピューティング側の制約に対して、どの改善方式を選択するかを扱います。

11. まとめ

このページでは、ベースラインの作成方法や一般的なボトルネック分析を再説明するのではなく、資源ごとに異なる制約の証拠を読み分けることを扱いました。

CPU
→ CPU側の処理能力を確認

メモリ
→ 利用可能メモリやスワップを確認

I/O
→ IOPS / スループット / Exceeded Checkを区別

ネットワーク
→ Bytesを必要な転送レートへ換算

さらに、問題発生時間・期間・統計を揃えて、KPIとリソースメトリクスを比較できる状態にします。

最終的には、「値が高い」ではなく、「どの性能制約を示す証拠が観測されたか」を説明できるようにします。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon EC2 User Guide — CloudWatch metrics that are available for your instances
• Amazon EBS User Guide — Amazon CloudWatch metrics for Amazon EBS
• Amazon EBS User Guide — Amazon EBS I/O characteristics and monitoring