はじめに
AWSでDBを運用するうえで、まず押さえておきたいリソース系とパフォーマンス系の用語をまとめました。
特に「CPU使用率は分かるけど、IOPS？コンカレンシー？」となっている方向けの内容です。
4大リソース：CPU / RAM / ストレージ / SWAP
CPU
CPUの計算処理能力。
- CPUUtilization：CPU使用率。70〜80%超えが続いたら危険信号
- vCPU：物理コアではなく仮想CPU。インスタンスタイプ選定の基準
-
CPUクレジット（CPUCreditBalance / CPUCreditUsage）
- T系インスタンス（t3, t4g等）でのみ重要
- バースト型でクレジットを消費する仕組み
- クレジット切れで性能制限がかかる
- ⚠️ 本番DBでT系は基本NG
RAM（メモリ）
データやインデックスを一時的に保持する領域。
- FreeableMemory：空きメモリ。少なすぎるとSWAP多発
-
バッファキャッシュ / バッファプール：データをメモリ上にキャッシュする領域
- MySQL：
innodb_buffer_pool_size - PostgreSQL：
shared_buffers - 一般的にRAMの 70〜80% を割り当てる
- MySQL：
- キャッシュヒット率：99%以上が理想。低いとディスクI/Oが増えて遅くなる
ストレージ（いわゆる”ROM”）
DBの裏では EBS（Elastic Block Store） が動いています。
EBSボリュームタイプ
| タイプ | 特徴 |
|---|---|
| gp3 | 汎用SSD。今のデフォルト。IOPSとスループットを独立に設定できる |
| gp2 | 旧世代の汎用SSD。容量に応じてIOPSが決まる |
| io1 / io2 | 高IOPS用。ミッションクリティカル向け |
| io2 Block Express | 超高性能。最大256,000 IOPS |
関連メトリクス
- FreeStorageSpace：空き容量。20%切ったらアラートが定番
- ストレージ自動拡張：足りなくなるとDB停止するので、必ずONにする
SWAP
メモリ不足時にディスクを仮想メモリとして使う仕組み。
- SwapUsage：SWAP使用量
- 増え続けていたら RAM不足のサイン ⚠️
- 一時的に使うのはOK、常用するとI/Oが増えてDBが激遅になる
- 対処：インスタンスタイプをメモリ多めに変更 / バッファプール設定見直し
ディスクI/O：IOPSとスループット
CPU・RAMと並ぶ重要リソース。
| 用語 | 意味 | イメージ |
|---|---|---|
| IOPS | 1秒あたりの読み書き回数 | 1秒に何回コップで水をすくえるか |
| スループット | 1秒あたりのデータ転送量（MB/s） | 1秒に何リットル運べるか |
関連メトリクス
-
ReadIOPS/WriteIOPS -
ReadThroughput/WriteThroughput -
DiskQueueDepth：I/O待ちキュー。詰まりの兆候
レイテンシー vs コンカレンシー vs スループット
混同しやすい3つの用語をまとめて整理。
一言で言うと
- レイテンシー（Latency） = 1つの処理にかかる時間（速さ）
- コンカレンシー（Concurrency） = 同時に処理できる数（量）
- スループット（Throughput） = 単位時間あたりの処理件数
レストランで例える
レイテンシー = 1人のお客さんが注文してから料理が出てくるまでの時間
コンカレンシー = 同時に何人のお客さんをさばけるか
スループット = 1時間で何人のお客さんを回せるか
単位の違い
| 用語 | 単位 | 例 |
|---|---|---|
| レイテンシー | 時間（ms、秒） | クエリ応答 20ms |
| コンカレンシー | 個数 | 同時接続 100、同時実行 50 |
| スループット | 件数/時間 | 1000 req/sec |
ざっくり関係式
スループット ≒ コンカレンシー ÷ レイテンシー
トレードオフ
- コンカレンシーを上げすぎるとレイテンシーが悪化（CPUやロック競合のため）
- RDS Proxyのコネクションプーリングはこのバランスを取る仕組み
覚え方
レイテンシーは「速さ」、コンカレンシーは「広さ」
1台の車のスピード（レイテンシー）と、道路の車線数（コンカレンシー）
ネットワーク
CPU/RAM/ストレージに並ぶ第4のリソース。
- NetworkReceiveThroughput / NetworkTransmitThroughput：ネットワーク帯域
- インスタンスタイプによって帯域上限が異なる
- 例：t3.medium = 最大5Gbps、r5.large = 最大10Gbps
- 大量データ転送時にボトルネックになることがある
インスタンスタイプの読み方
| ファミリー | 用途 | 例 |
|---|---|---|
| t系 | バースト型・小規模 | t3.medium |
| m系 | 汎用バランス | m5.large |
| r系 | メモリ最適化（DB向き） ⭐ | r5.xlarge |
| x系 | 超メモリ特化 | x2idn |
| c系 | CPU最適化 | c5.large |
DBは r系（メモリ最適化） が定番。
末尾の文字の意味
-
r5→ Intel -
r5a→ AMD（少し安い） -
r6g/r7g→ Graviton（ARM）。安くて速い。最近のおすすめ -
r5d→ ローカルNVMe SSD付き
監視で押さえるべき主要メトリクス
これだけ見ておけばまず安心、というやつ。
| メトリクス | 何を見る | 目安 |
|---|---|---|
CPUUtilization |
CPU使用率 | 70-80%以下 |
FreeableMemory |
空きメモリ | 余裕を保つ |
FreeStorageSpace |
ストレージ空き | 20%以上 |
ReadIOPS / WriteIOPS
|
ディスクI/O回数 | プロビジョン値以下 |
DatabaseConnections |
コネクション数 | max_connectionsの70%以下 |
SwapUsage |
SWAP使用量 | できるだけ0 |
ReadLatency / WriteLatency
|
I/Oレイテンシー | 数ms以下 |
DiskQueueDepth |
I/O待ち | 低いほど良い |
実務でハマりがちなパターン
リソース起因のトラブル定番。
- ストレージ枯渇でDB停止
- 自動拡張ONにしてないと夜中に呼び出される
- バッファプール小さすぎてキャッシュヒット率低下
- パラメータグループで調整
- gp2の容量小さくてIOPS不足
- gp3に変更すれば解決することが多い
- T系インスタンスでクレジット枯渇
- 本番でT系を使ったときの典型事故
- SWAP多用でレイテンシー悪化
- メモリ増やすか設定見直し
- コネクション枯渇
- Lambdaの大量起動が原因なら RDS Proxy で解決
まとめ表
| リソース | AWS用語 | 主要メトリクス |
|---|---|---|
| CPU | vCPU、CPUクレジット | CPUUtilization |
| RAM | バッファプール | FreeableMemory |
| ストレージ | EBS（gp3/io2等） | FreeStorageSpace |
| SWAP | - | SwapUsage |
| ディスクI/O | IOPS、スループット | ReadIOPS、WriteIOPS |
| ネットワーク | 帯域 | NetworkThroughput |
おわりに
リソース系の用語を押さえると、CloudWatchのダッシュボードを見たときに何が起きているかが一気に分かるようになります。
次はインデックスやトランザクション分離レベルなど、クエリ・パフォーマンス側の用語も整理していきたいと思います！
間違いやアドバイスがあればコメントで教えていただけると嬉しいです 🙏