コールセンターのシステムや、突発的なキャンペーンサイトなど、「いつ、どのくらいのアクセスが来るか全く読めない」状況に遭遇したことはありませんか？
従来のデータベース（RDS）だと、ピークに合わせて大きなインスタンスを常に動かしておく必要があり、コストが無駄になりがちです。かといって、小さいインスタンスだとピーク時にパンクしてしまいます。
私は模擬試験でこの「予測不能な負荷」への対策を問われ、「マルチAZにすればいいのかな？」と迷って不正解。実は、可用性（マルチAZ）とは別に、「キャパシティそのものが伸び縮みする」最強の解決策があったんです。
データベースの「自動伸縮」を実現する仕組み
その正解こそが、Amazon Aurora Serverlessです。
通常のAuroraやRDSは、予め「db.t3.medium」のようにインスタンスのサイズを決めますが、Aurora Serveerlessは違います。
- インスタンス管理が不要
サーバーのサイズを選ぶのではなく、最小と最大の「キャパシティ範囲（ACU）」を指定するだけ。 - 勝手にスケーリング
負荷が増えたら自動でパワーアップし、落ち着いたら自動でパワーダウン。アクセスがゼロになれば、完全にシャットダウンして料金を最小化することすら可能です（※viの場合）。 - コスト最適
「使った分だけ」の秒単位課金。不規則なアクセスがある環境では、これが一番安上がりになります。
試験で狙われる「Aurora Serverless v2」の凄さ
最新のv2では、さらに試験に出やすいポイントが強化されています。
- 高速なスケーリング
一瞬で数十万のトランザクションを処理できるレベルまで、滑らかに（きめ細かく）スケールします。 - フル機能のサポート
サーバーレスなのに「マルチAZ」や「リードレプリカ」も利用可能。高可用性を保ちつつ、負荷にも強いという「いいとこ取り」ができます。
【比較表】RDS vs Aurora vs Aurora Serverless
試験で「どのDBを選ぶべきか」迷った時の判断基準です。
| 特徴 | Amazon RDS | Amazon Aurora | Amazon Aurora Serverless |
| スケーリング | 手動（または数分かかる） | リードレプリカで読込拡張 | 自動（高速に伸縮） |
| 負荷の予測 | 予測可能な場合に最適 | 大規模・高性能向け | 予測不能・不規則 |
| 管理の手間 | 普通 | 低い | 極めて低い |
試験で役立つ！キーワード判別法
問題文に以下のフレーズがあれば、迷わずAurora Serverlessを選びましょう！
- 「不規則なDBアクセスが発生する」
- 「ピーク時の予測が困難」
- 「コスト最適かつスケーラブルなOLTP処理」
- 「使用頻度が低い、または変動が激しい」
今回の学び：攻略の格言
「読めない負荷にはサーバーレス。ACUが勝手に伸び縮みして、コストも性能も守ってくれる！」
あとがき：一歩ずつ、合格へ
最後まで読んでいただき、ありがとうございました！
今回の問題を通して、「可用性（マルチAZ）」と「スケーラビリティ（Serverless）」は別次元の話だということに改めて気づかされました。ネットワークを二重化しても、処理能力が足りなければシステムは止まってしまいます。
「いつ来るかわからない嵐」に備えて高い壁を作るのではなく、嵐に合わせて形を変える柳のようなシステム。そんな柔軟な設計ができるようになると、アーキテクトとしての視界がぐっと広がる気がします。
それでは、次回の記事でお会いしましょう！
