Aurora Serverless v2 vs プロビジョンド — 料金構造と選択基準

読了 6分

Aurora を使うと決めた次の質問が容量モデルです。インスタンスサイズを選ぶプロビジョンドと、負荷に応じて容量が上下する Serverless v2 のどちらかを選びます。結論を先に書くと、アイドル時間が長いか負荷の予測が立たないワークロード(開発・テスト、新規サービス、スパイク型)は Serverless v2、負荷が常時均一な本番はプロビジョンド + コミットが安くなります。 常時高負荷の基準で見ると Serverless v2 の時間単価は同等のプロビジョンドの 2 倍を超えるため、サーバーレスという名前ではなく使用率で判断する必要があります。Aurora 自体を使うかどうかは Aurora vs RDS で扱いました。料金は us-east-1 基準です。

一目でわかる比較 #

項目Serverless v2プロビジョンド
課金単位ACU 時間(約 $0.12、標準構成)インスタンス時間
容量調整秒単位で自動(0.5 ACU 刻み)手動(インスタンスクラス変更)
最小容量0 ACU(自動一時停止あり)インスタンス常時稼働
アイドルコスト0 に近づく(ストレージ料金のみ)インスタンス料金が常時発生
コミット割引Database Savings Plans(最大約 35%)RI・Database SP(最大数十 %)
常時高負荷の単価プロビジョンドの 2 倍以上基準
スパイク対応自動(数秒で増設)手動(再起動・フェイルオーバーを伴う)

ACU 課金 — 使った分ではなく確保した分 #

Serverless v2 の課金単位は ACU(Aurora Capacity Unit)です。1 ACU はおおよそメモリ 2GiB とそれに比例する CPU・ネットワークに相当し、標準構成で ACU 時間あたり約 $0.12 です。クラスターに最小・最大 ACU を設定しておくと、負荷に応じて 0.5 ACU 刻みの調整が秒単位で行われます。

注意すべきは、請求が実際のクエリ量ではなく、その時点で確保されている ACU に対して行われることです。バッファプールにデータが載っているとアイドル状態でも ACU が下限まで下がらないことがあり、思ったより請求が来る第一の原因になります。最小 ACU に余裕を持たせる設定はもっと直接的です。最小 8 ACU に設定したクラスターは負荷と無関係に時間あたり約 $0.96、月約 $700 が下限の料金になります。この時点の Serverless v2 は自動拡張つきの固定費インスタンスで、サーバーレスのコスト利点は消えています。

0 ACU の設定はこの構造の反対側です。最小を 0 にすると、接続が切れて指定時間が過ぎたあと自動一時停止になり、コンピューティング料金が 0 になってストレージ料金だけが残ります。再び接続が来ると再開まで十数秒かかるため、夜間に空く開発・テスト DB にはそのまま正解で、ユーザー向けサービスには最初のリクエストの遅延を受け入れられるときだけ使います。

損益分岐 — 使用率の計算 #

同等の容量で比較すると構造が見えます。メモリ 16GiB の db.r6g.large(月約 $190、オンデマンド)と 8 ACU 常時確保(月約 $700)を並べると、Serverless v2 が同じ金額になるのは 1 日約 6.5 時間だけ 8 ACU で回り、残りは 0 に近いパターンです。おおよそ平均使用率 25〜30% が境界で、プロビジョンドにコミット割引まで掛けると境界はさらに下がります。 負荷が 1 日の 3 分の 1 以上常時かかる DB ならプロビジョンドが合い、業務時間だけ動く社内システムやトラフィックのまだ小さい新規サービスなら Serverless v2 が合います。

コミットは両側にあります。プロビジョンドのインスタンスは RI で、Serverless v2 は Database Savings Plans(1 年コミットで最大約 35% 割引)で下げられます。常時の下限負荷がある Serverless v2 クラスターなら、その下限の分だけ SP を掛ける選択肢もあります。コミットの一般原則は RI vs Savings Plans で扱いました。

ストレージと I/O の料金は 2 つのモデルで同じです。標準構成は保存 GB 月あたり約 $0.10 に I/O 100 万件あたり約 $0.20 がつき、I/O の比重が大きければ I/O-Optimized 構成(コンピューティング・ストレージ単価は高く、I/O 無課金)が逆転します。請求書で I/O 項目がコンピューティングの 25% を超えたら I/O-Optimized を検討する、というのが通用している基準です。

ハイブリッド — ライターとリーダーを別モデルで #

1 つのクラスターの中でプロビジョンドのインスタンスと Serverless v2 のインスタンスを混在できる点が、実務では最も有用です。典型的な構成は、下限の負荷を支えるプロビジョンドのライター(RI 適用)+ トラフィックに応じて増減する Serverless v2 のリーダーです。書き込みは予測でき読み取りは波打つサービスで、固定費はコミットで安く固定し、変動分だけ ACU で払う構造になります。逆にマイグレーション中なら、先に Serverless v2 のリーダーを付けて実測の ACU 曲線を確保してから本体のモデルを決める手順が安全です。

選択の手順 #

  1. 負荷曲線から見ます: CloudWatch で CPU・接続数の 1 日の曲線を見ます。アイドル区間が長ければ Serverless v2、常時平らならプロビジョンドの候補です。
  2. 開発・テストは 0 ACU で確定します: 自動一時停止で夜間・週末のコンピューティング料金が消えます。再開の十数秒はこの用途では問題になりません。
  3. 常時負荷は同等のプロビジョンド + コミットと比較します: 平均 ACU × $0.12 × 730 時間を計算してインスタンス料金と並べます。平均使用率 30% を超えるならプロビジョンド側がおおむね安くなります。
  4. 最小 ACU を必要以上に上げません: 下限を上げた分だけ固定費になります。コールドなバッファプールによる最初のクエリの遅延が問題なら、最小を 1〜2 ACU の範囲で調整し、それ以上は実測で決めます。
  5. 読み取りの拡張はハイブリッドで解きます: プロビジョンドのライター + Serverless v2 のリーダーの組み合わせが、固定費と変動費をそれぞれ最適化します。

まとめ #

  • Serverless v2 は ACU 時間あたり約 $0.12 で、確保した容量に課金されます。アイドルが長ければ圧倒的に安く、常時高負荷ではプロビジョンドの 2 倍を超えます。
  • 0 ACU の自動一時停止ができたことで、開発・テスト DB は Serverless v2 がそのまま正解になりました。対価は再開までの十数秒です。
  • 境界は平均使用率 25〜30% です。それより上ならプロビジョンド + RI、下なら Serverless v2 で、Database SP はサーバーレス側のコミット手段です。
  • 最小 ACU を高く取った瞬間、サーバーレスは固定費に変わります。下限の設定は実測の曲線を見て決めます。
  • プロビジョンドのライター + サーバーレスのリーダーのハイブリッドが、予測できる書き込みと波打つ読み取りをそれぞれ安く処理する実務の正解になることが多いです。
X