第 13 章 コストを最適化したアーキテクチャの設計（20%）
データベースのコスト
この章で学ぶこと
- キャッシュの戦略／データの保持ポリシー
- データベースのキャパシティプランニング（キャパシティユニット）
- データベースの接続とプロキシ
- 適切なユースケースを伴うデータベースエンジン（同種・異種の移行）
- データベースのレプリケーション（リードレプリカ）
| 部品 | 何で決まるか | 下げ方 |
|---|---|---|
| インスタンスの時間 | 大きさ × 稼働時間 | 適正化・リザーブド・止める |
| ストレージ | 確保した容量（または使った量） | 要らないデータを消す・保持期間を短く |
| 入出力（I/O） | 読み書きの回数 | キャッシュを置く・設計を直す |
| バックアップ | 保持しているスナップショットの量 | 保持期間を見直す・手動スナップショットを整理 |
| データ転送 | 外へ出る量 | 同じ AZ に寄せる（第 14 章） |
試験では
マルチ AZ 配置にすると、インスタンスの料金はおよそ 2 倍になる。待機系も課金されるからだ。本番には必要だが、開発環境には要らない。「開発環境のコストを下げたい」でマルチ AZ を外す選択肢は正しい。
| 手 | 効く場面 | 注意 |
|---|---|---|
| リザーブドインスタンス（RDS） | 1 年以上動かし続ける本番 | エンジンとクラスを固定する |
| Aurora Serverless v2 | アクセスに波がある・読めない | 常時高負荷ならプロビジョンドのほうが安い |
| インスタンスを小さくする | 使用率が低い | Performance Insights などで確認してから |
| 開発環境を止める | 夜間・休日 | RDS は最大 7 日間まで停止できる（その後自動で起動） |
| 読み取りをキャッシュへ逃がす | 同じ問い合わせが多い | ElastiCache のほうが安いことが多い |
補足
Aurora にはストレージの課金方式が 2 つある。標準構成は「ストレージ＋ I/O」で課金され、I/O 最適化構成は I/O の課金が無くなるかわりに単価が上がる。入出力が極端に多いワークロードでは後者が安くなる。
DynamoDB はキャパシティモードの選択がそのままコストになる。どちらが安いかは、負荷の形で決まる。
| オンデマンド | プロビジョンド | |
|---|---|---|
| 課金 | リクエストごと | 確保した容量ごと（使わなくても課金） |
| 安くなる場面 | 使わない時間が長い・急な山がある・読めない | 安定して使い続ける |
| 準備 | 不要 | 容量の見積りと Auto Scaling の設定 |
| さらに安く | ― | リザーブドキャパシティ（1 年・3 年） |
| そのほかの手 | 効果 |
|---|---|
| TTL を設定する | 期限切れの項目が自動で消え、ストレージ代が減る |
| Standard-IA テーブルクラス | めったに読まないテーブルのストレージ代が下がる（読み書きは高くなる） |
| スキャンをやめてクエリにする | 読み取りキャパシティの消費が大きく減る |
| 射影を絞る（インデックス） | インデックスのストレージと書き込みコストが減る |
試験では
「使われなくなった古いデータが溜まり続けている」は TTL。手で消す Lambda を書く選択肢より、TTL のほうが簡単で安い。
第 8 章では「読み取りが重い」の手当てを 3 つ見た。コストの目で見ると順位が変わる。
| 手 | コストの性格 |
|---|---|
| キャッシュ（ElastiCache / DAX） | 最も安いことが多い。 元のデータベースを小さいまま保てる |
| リードレプリカ | レプリカの台数ぶんインスタンス料金が増える |
| インスタンスを大きくする | 最も高くなりやすい。 書き込みも重いときの最後の手 |
試験では
「読み取りが重い」かつ「コストを抑えたい」ならキャッシュが先。リードレプリカは台数ぶん素直に課金されるので、同じ問い合わせが繰り返されている場面では割高になる。
| 項目 | 押さえること |
|---|---|
| 自動バックアップ | 保持期間は 1〜35 日。データベースのサイズぶんまでは追加料金がかからない |
| 手動スナップショット | 明示的に消すまで残る（インスタンスを削除しても） |
| 保持期間を長くする | そのぶんストレージ代が増える。要件（RPO）と突き合わせる |
| 別リージョンへのコピー | 転送料とストレージ代がかかる。DR 要件と見合うか確認する |
最後に、最も大きく効くがいちばん手間のかかる手だ。商用エンジンからオープンソース互換へ移すと、ライセンス費用が消える。
| 移行の型 | 使う道具 | 手間 |
|---|---|---|
| 同種（MySQL → RDS MySQL） | AWS DMS だけ | 小さい |
| 異種（Oracle → Aurora PostgreSQL） | DMS ＋ Schema Conversion Tool（SCT） | 大きい（スキーマと SQL の書き換えが要る） |
補足
DMS の継続的な複製（CDC）を使うと、停止時間を最小にできる。全件コピーしたあと差分を流し続け、切り替えの直前まで追従させる。第 10 章で見たものと同じ仕組みで、こちらはコストが目的になる。
| 問題文に出る語 | 答えの方向 |
|---|---|
| 1 年以上動かし続ける本番 | リザーブドインスタンス（RDS） |
| アクセスに波がある・読めない | Aurora Serverless v2 ／ DynamoDB オンデマンド |
| 安定して使い続ける（DynamoDB） | プロビジョンド＋ Auto Scaling（さらにリザーブド） |
| 古いデータが溜まり続ける | TTL |
| めったに読まないテーブル | DynamoDB Standard-IA テーブルクラス |
| 読み取りが重い＋コストも抑えたい | キャッシュ（ElastiCache / DAX） |
| 開発環境のコストを下げたい | マルチ AZ を外す・停止する（最大 7 日） |
| I/O が極端に多い（Aurora） | I/O 最適化構成 |
| Oracle / SQL Server のライセンス費を減らす | DMS ＋ SCT でオープンソース互換へ |
| 停止時間を最小にして移行 | DMS の継続的な複製（CDC） |
シナリオ演習
DynamoDB のテーブルに、1 年以上前のセッション情報が大量に残っている。ストレージ料金を下げたい。
補足
答え：TTL 属性を設定して、期限切れの項目を自動で削除する。
Lambda で定期的に削除する案も動くが、書き込みキャパシティを消費し、運用も増える。TTL による削除は追加料金がかからない。
シナリオ演習
開発環境の RDS が本番と同じマルチ AZ 構成になっている。費用を下げたい。
補足
答え：開発環境ではマルチ AZ 配置を外し、使わない時間は停止する（最大 7 日）。
マルチ AZ は待機系も課金されるのでインスタンス料金がおよそ 2 倍になる。開発環境に本番と同じ可用性は要らない。
この章のまとめ
- データベースの請求の 5 つの部品
- マルチ AZ 配置にすると増えるもの
- RDS を停止できる最長期間
- アクセスに波があるときの Aurora
- 入出力が極端に多いときの Aurora の構成
- 使わない時間が長い DynamoDB のモード
この章の根拠
最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版