RDS インスタンスクラスの選択基準 — db.t・db.m・db.r 比較
RDS のインスタンスクラスは EC2 タイプの前に db. が付いた形なので、規則は同じに見えます。ところが選択基準は異なります。データベースではメモリがそのままキャッシュなので、m と r を分ける軸が EC2 よりメモリ側に傾き、t のクレジット枯渇はサービス全体の遅延に直結します。結論を先に書くと、開発・検証は db.t4g、本番は db.m8g から始めて、ワーキングセットがメモリを超える実測が見えたら db.r8g に移ります。 EC2 側の命名規則とファミリーの一般論は EC2 インスタンスファミリー比較 で扱いました。料金は us-east-1、MySQL、Single-AZ のオンデマンド基準です。
名前は同じ規則、サポートはエンジンごとに異なります #
db.m8g.large は EC2 の m8g.large と同じハードウェアです。ファミリー(t・m・r)、世代の数字、属性の文字(g=Graviton、i=Intel)の読み方も同じです。異なる点は二つです。
- エンジンとバージョンによって使えるクラスが異なります。 現行の Graviton4 世代(db.m8g・db.r8g)は PostgreSQL、MySQL、MariaDB でサポートされ、エンジンバージョンの下限(MySQL 8.0.32 以上、PostgreSQL 13.8 以上など)があります。Oracle、SQL Server はサポートクラスの一覧が別です。クラスを選ぶ前に、コンソールで該当エンジン・バージョンの選択肢として実際に表示されるかをまず確認します。
- c 系がありません。 データベースでは vCPU 対メモリ 1:2 の需要がないため、選択肢は実質的に t、m、r とハイメモリ(db.x2g)です。
同じハードウェアなのに料金が 2 倍の理由 #
m8g.large(EC2)が 1 時間あたり約 $0.090、db.m8g.large(RDS MySQL)が約 $0.168 です。差額が管理の料金です。自動バックアップとポイントインタイムリカバリ、マイナーバージョンのパッチ適用、Multi-AZ フェイルオーバーのオーケストレーション、スナップショット管理がインスタンス料金に折り込まれています。EC2 に自分で DB を載せればハードウェア料金は半分ですが、この運用をすべて自分で行うことになるので、単純な料金比較は成立しません。
注意すべきはここに加算される項目です。Multi-AZ はスタンバイインスタンスの分だけ料金が 2 倍になり、ストレージとプロビジョンド IOPS は別課金です。RDS のストレージも gp3 がデフォルトになり、選択の論理は EBS と同じなので gp3 vs io2 の基準がそのまま適用できます。バックアップ・運用側の実務は AWS 中級 #4 で扱いました。
db.t — 開発用には正解、本番では時限付き #
db.t4g と db.t3 は EC2 の t と同じバーストモデルです。db.t4g.micro が 1 時間あたり約 $0.016 で最も安く、無料利用枠の対象なので、学習・検証用としては正解です。
本番では事情が異なります。アプリケーションサーバーのクレジット枯渇はそのサーバーだけが遅くなりますが、データベースのクレジット枯渇は、その DB を参照するすべてのサービスの遅延に広がります。 トラフィックが増えてクエリが詰まり始める時点が、ちょうど CPU がベースラインを超える時点なので、最も忙しい瞬間に最も遅くなる構造です。db.t で本番をしのいでいるなら CPUCreditBalance にアラームを設定し、枯渇のグラフが見えた時点で db.m に移ります。
db.m vs db.r — バッファプールが分ける基準 #
| クラス | vCPU | メモリ | 時間あたり料金 | プロファイル |
|---|---|---|---|---|
| db.t4g.micro | 2 | 1GiB | 約 $0.016 | 開発・検証 |
| db.m8g.large | 2 | 8GiB | 約 $0.168 | 汎用 |
| db.r8g.large | 2 | 16GiB | 約 $0.239 | メモリ中心 |
データベースではメモリがバッファプールとキャッシュです。RDS MySQL はデフォルト設定でインスタンスメモリの 75% を InnoDB バッファプールに割り当てるので、クラスのメモリがそのままキャッシュサイズです。頻繁に読むデータ(ワーキングセット)がバッファプールに収まれば読み取りはメモリで完結し、収まらなければその分がディスク I/O にあふれます。
したがって判定の指標は CPU ではなく、このあふれです。FreeableMemory が底に張り付き、ReadIOPS がトラフィックの増加より急に上がっていれば、ワーキングセットがメモリを超えた合図です。このとき db.m のサイズを上げるか db.r に移るかでは、同じメモリ基準なら r が安くなります。 16GiB が必要なとき、db.r8g.large が約 $0.239、db.m8g.xlarge(4vCPU)が約 $0.336 です。DB の CPU が遊んでいるなら、r は同じキャッシュを 7 割の料金で提供します。逆に書き込み中心で CPU とコミットのスループットがボトルネックなら、m のサイズを上げるほうが正しい選択です。
Graviton への移行 — EC2 より簡単です #
EC2 での Graviton 移行は ARM ビルドの確認が必要でした(チェックリスト 参照)が、RDS は事情が異なります。エンジンのバイナリを AWS が管理しているので、アプリケーション側で変えるものがありません。 クライアントは以前と同じプロトコルで接続するだけなので、db.m6i から db.m8g への移行はクラス変更 1 回です。Intel クラス(db.m6i など)を維持する理由は、エンジンやバージョンが Graviton クラスをまだサポートしていない場合くらいです。
世代の更新も同じ操作です。クラス変更は再起動を伴うのでダウンタイムが発生しますが、Multi-AZ 構成ならスタンバイを先に変更してフェイルオーバーする方式で、中断は数十秒程度に縮まります。変更の実務手順は AWS 実践 #2 で扱いました。
選択の手順 — 実測が先です #
- 現在の消費量を測ります: CloudWatch の
CPUUtilization、FreeableMemory、ReadIOPS・WriteIOPS、DatabaseConnectionsを見ます。クエリ単位のボトルネックは Performance Insights(デフォルト有効、7 日分無料)で確認します。チューニングで解決する問題(インデックス漏れ、N+1)をクラス増強で覆い隠していないかが先です。 - 環境を分けます: 開発・検証は db.t4g で足り、夜間・週末の停止まで組み合わせれば料金はさらに減ります(常時点検リスト 参照)。
- 本番のクラスを決めます: db.m8g から始め、
FreeableMemoryの底打ちとReadIOPSの急増が見えたら db.r8g に移ります。r でも足りない大型のインメモリ要件だけが db.x2g のようなハイメモリに進みます。 - サイズを決めます: バッファプールにワーキングセットが収まる最小のメモリを基準にし、小さく始めて上げます。Multi-AZ の有無とストレージ IOPS はクラスとは別に決めます。
- コミットを掛けます: 長期運用が確定した本番 DB はリザーブドインスタンスでオンデマンド比の料金を大きく下げます。Graviton4 クラス(db.m8g・db.r8g)も対象です。
まとめ #
- RDS のクラスは EC2 と同じ命名規則に
db.接頭辞です。ただしエンジン・バージョンごとにサポートクラスが異なるので、コンソールの実際の選択肢の確認が先です。 - 同じハードウェアでも管理込みで EC2 の 2 倍ほどです。Multi-AZ でさらに 2 倍、ストレージ・IOPS は別課金です。
- db.t は開発・検証用です。本番 DB のクレジット枯渇は全サービスの遅延に広がるので、
CPUCreditBalanceのアラームと併せて時限付きでだけ使います。 - db.m と db.r はバッファプールで分けます。
FreeableMemoryの底打ちとReadIOPSの急増が合図で、同じメモリなら r が m のサイズ増強より安くなります。 - Graviton 移行は RDS のほうが EC2 より簡単です。アプリ変更なしのクラス変更 1 回で、Multi-AZ なら中断も数十秒程度です。