〜世代変更・サイズ最適化・SQL改善で“静かに効くDBコスト”〜
（前々回） 序章：コスト削減 - コストと戦う未来の僕へ -
（前回）コスト削減 - EC2編 - 🚀
AWS の中でも RDS（Aurora含む）は桁が大きいサービス。
EC2より高いぶん、削れるとインパクトも大きい。
ただ、DBは“触るの怖い”の典型。
だけど実務で向き合っていくうちに、
RDSは、改善できる余地がめちゃくちゃ大きいサービス
＝やればやるほどコストが落ちる
ということに気づいた。
今回は、実際にやったこと・感じたことを中心に
実務ベースでまとめます。
🎯 結論：RDS / Aurora で削減するなら見るべきはこの4つ
| # | 削減ポイント | 効果 |
|---|---|---|
| 1 | 世代変更（例：r7g → r8g） | 性能UP・コスパ改善。ただしリージョン影響大。 |
| 2 | インスタンスタイプを1つ下げる | RDSこそ最大の削減ポイント。月の削減幅がデカい。 |
| 3 | ストレージ最適化（IOPS / Backtrack / 容量管理） | “気づかない課金”の本丸。改善効果が継続する。 |
| 4 | SQL改善（スロークエリ / INDEX / 取得量最適化） | 負荷が減り、結果的にインスタンスサイズを下げられる。 |
🧪 僕が実際にやったこと（実務ベース）
✔ 世代変更：本当は r8g にしたかったが r7g を採用
今回のプロジェクトでは r8g を使いたかったものの、
東京リージョンと諸条件の兼ね合いで r7g を選択。
結果として：
- 性能は20〜30%改善
- ただし 料金は少し上がる
世代更新は確かに重要だが、
この経験で改めて気づいた。
RDSの本命は“世代”ではなく“サイズを落とせるかどうか”。
世代変更は“土台づくり”。
本当の削減は、その先にある。
✔ RDSこそ、インスタンスタイプを1つ落とすのが鍵
EC2以上に、RDSは サイズを落としたときのインパクトが大きい。
例：
r7g.4xlarge → r7g.2xlarge
→ 単純計算で インスタンス代が約半額に近づく
→ 月間数万円〜十数万円が動くことも珍しくない
ただし、いきなり落とすのは危険。
そこで必要になるのが “DB負荷の根本改善”。
🔍 インスタンスサイズを落とすために行った改善（実務）
✔ Performance Insights でスロークエリを炙り出す
RDSの負荷のほとんどは “数本の重いクエリ” が支配している。
- CPU が跳ねるクエリ
- 待機時間が多いクエリ
- JOIN で無駄に重くなるクエリ
これらを Performance Insights で可視化し、
一つずつ改善 → 負荷がみるみる下がる。
✔ INDEX の改善（付けすぎ／足りないの両方を解消）
INDEX がないと Full Scan 祭り。
INDEX が多すぎると更新が重くなる。
- WHERE に必要な INDEX
- JOIN に必要な INDEX
- 不要 INDEX の削除
これだけで CPU / IO の両方が軽くなる → サイズダウンの余地が増える。
✔ 取得量の見直し（チャンク処理・部分取得・段階取得）
でかいクエリ 1 発で DB に大ダメージが入ることがよくある。
そこで：
- 大量取得 → チャンク（分割）処理へ
- 巨大JOIN → 段階処理に変更
- 必要カラムだけに絞る
- LIMITの使い方を見直す
これを徹底しただけで、
CPU負荷が明確に下がり、1サイズ落とせる余地ができた。
✔ クエリ回数そのものを減らす（N+1撲滅・キャッシュ導入）
1回のクエリが軽くても、回数が多ければ重い。
- キャッシュの活用
- 結果セットの再利用
- N+1 の解消
- API集約サーバでまとめて取得する設計
これもインスタンス最適化に直結した。
💳 RDSは SP ではなく RI の方が相性がいい（重要）
EC2 編では SP（Savings Plans）を推したけれど、
RDS に関しては RI（Reserved Instances）が圧倒的に向いていると感じている。
理由はシンプル：
▶ DB は「止められない前提」
夜間停止で節約できる EC2 と違い、
RDS は 24時間稼働が基本。
▶ DB の負荷は安定しており、変動が小さい
Compute SP のように柔軟性は不要で、固定割引モデル（RI）の方が割引効率が高い。
▶ RI は RDS 専用の割引 → SP より深い割引になることが多い
まとめると：
| 観点 | SP | RI（RDS向き） |
|---|---|---|
| 適用柔軟性 | 高い（EC2含む） | 低い（DB固定向き） |
| 割引率 | 1年で約36%前後 | DBはさらに深く効くケース多い |
| 稼働特性 | 変動に強い | 固定稼働に強い＝RDS向き |
結論：RDSはRIでガッチリ割引をとるのが実務上は最適解になりやすい。
🤔 RI の“1年 or 3年”問題もあるけれど…
✔ 3年一括が最も割引率は高い
しかし…
✔ DBは世代更新の進化幅が大きい（r7 → r8 → r9…）
- 新世代が毎年出る
- 性能が20〜30%改善することもある
- 価格が下がることもある
- リージョン対応が遅れる場合もある
そのため、
3年固定は“旧世代にロックイン”されるリスクが大きい。
僕の結論は：
RIは基本 1年カーブを採用し、毎年“世代・サイズ”を見直すのが最強。
EC2と同じく、柔軟性を残すほうがトータルで得。
⚠ 見落としがちだけど強力：ストレージ・IOPS の最適化
RDSはインスタンス代だけでなく、
ストレージ課金が地味に高い。
チェックポイント：
- Provisioned IOPS が高すぎないか？
- General Purpose (GP3) に落とせないか？
- Backtrack が必要なのにONのままになってないか？
- 長期バックアップの日数が多すぎないか？
- 冗長に取られた自動バックアップが残ってないか？
ストレージは 減らした分だけずっと安くなるので、改善効果が継続する。
🎯 まとめ：RDSは「改善＝直接コストが下がる」世界
- 世代変更は土台の最適化
- 本命は インスタンスサイズを落とすこと
- そのためには SQL改善が最も効果的
- ストレージ・IOPS は“気づかない課金”の本丸
- RDSは SPよりRIの方が圧倒的に相性がいい
EC2より怖いけど、削れるときのインパクトはもっと大きい。
未来の自分へ：DBの改善はゆっくりでいいので、確実に続けよう。
🔜 次回
『コスト削減 - EFS・S3 編 -』
不意にたまってしまうストレージコストを削減したい！！
次回も“静かに効くコスト改善”を掘っていきます。