Database Cost Optimization

ゴール

最終的に、

RDSだから高い
Auroraだから安い
DynamoDBだからサーバーレスで安い

のようにサービス名だけで判断せず、

使用パターン
+
キャパシティモデル
+
ストレージ
+
I/O
+
アイドルキャパシティ
+
コミットメント

から、データベースごとのコスト要因を特定できることがゴールです。

1. データベースサービスの再選択から始めない

データベースの選択では、

リレーショナル
キー・バリュー
アクセスパターン
整合性
互換性
パフォーマンス

などを既に確認しています。

したがって、ここでは、

Amazon RDS
Amazon Aurora
Amazon DynamoDB

の特徴をもう一度比較するのではありません。

まず、

要件を満たすデータベースアーキテクチャ

を前提に、

そのアーキテクチャを
どう課金効率よく動かすか

を考えます。

2. データベースコストは使用パターンを課金単位へ変換する

最初に確認するのは、

ピーク性能

だけではありません。

例えば次のような利用パターンを確認します。

24時間ほぼ一定

昼間だけ高負荷

短時間だけ急増

長時間アイドル

読み取り中心

書き込み中心

I/Oが非常に多い

データ量だけ大きく
アクセスは少ない

これを各サービスの、

課金されるキャパシティ

へ変換します。

3. Amazon RDSでは課金される容量を分解する

Amazon RDSのコストを見るときは、

RDSの月額

という1つの数字にまとめず、代表的には、

DBインスタンス

ストレージ

プロビジョンド IOPS

ストレージスループット

バックアップなどの追加利用

へ分解します。

例えば、

CPUは低い
+
メモリにも大きな余裕
+
ストレージIOPSも余っている

のに、

大きなDBインスタンス
+
高いプロビジョンド IOPS

を維持しているなら、

利用量
<
購入しているキャパシティ

というコスト差分があります。

4. RDSでは各項目を別々に適正化する

データベース 適正サイジングでは、

DBインスタンスだけ縮小

すれば終わりではありません。

例えば、

コンピューティング
ストレージ
IOPS
スループット

は別々に確認します。

DBインスタンス
→ CPU / メモリ

ストレージ
→ 実データ量 / 増加率

IOPS
→ 実I/O負荷

スループット
→ 実データ転送量

という対応で見ます。

つまり、

大きなDBインスタンス

だけではなく、

余っているプロビジョンド キャパシティ

を探します。

5. RDS Storage Auto Scalingはコスト ガードレールも必要

Amazon RDSではストレージの自動スケーリングを利用できます。

これは、

ストレージ不足
↓
自動拡張

に有効です。

しかし重要なのは、

一度増えた割り当て済みストレージ
↓
自動では縮小しない

ことです。

そのため、

最大 ストレージ しきい値

を、

とにかく最大値

へ設定すればよいわけではありません。

例えば異常処理によって一時的に大量のデータが生成されると、

予想外のストレージ拡張
↓
拡張後のキャパシティが残る
↓
継続コストが増える

可能性があります。

したがって、

通常のデータ増加
+
異常増加時のガードレール

を考えて上限を設定します。

6. 安定したRDS / AuroraではリザーブドDBインスタンスを評価する

長期間継続して使用するプロビジョンド DBインスタンスでは、

リザーブドDBインスタンス

を評価できます。

リザーブドDBインスタンスは、

専用の物理DBを予約する

という意味ではありません。

基本的には、

条件に一致する
On-Demand DBインスタンス 使用量
↓
割引料金を適用

する料金上の仕組みです。

期間は、

1年
3年

があります。

ここでも既習のコミットメント判断と同じく、

現在使っている

だけではなく、

期間中も利用が続く確度

を確認します。

7. リザーブド割引が適用される範囲を混同しない

リザーブドDBインスタンスを購入しても、

データベースに関する
すべての料金

が割引されるわけではありません。

例えばAuroraでは、リザーブドDBインスタンスの割引とは別に、

ストレージ
バックアップ
I/O

などの料金があります。

したがって、

DBインスタンス 割引
↓
データベース 総コスト全体が
同じ割合で下がる

とは考えません。

データベースコストモデルでは、

どの課金項目に
割引が適用されるのか

を確認します。

8. AuroraではプロビジョンドとAurora Serverless v2を使用パターンで比較する

Auroraでは、

プロビジョンド DBインスタンス

だけでなく、

Aurora Serverless v2

も利用できます。

Aurora Serverless v2では、

最小 ACU
最大 ACU

の範囲を指定し、

データベース 負荷
↓
ACU キャパシティ

を変化させます。

そのため、

高負荷と低負荷の差が大きい
+
利用量が変化する

ようなワークロードでは、

最大負荷に合わせた
プロビジョンド キャパシティを
常時維持する

場合と比較できます。

9. Aurora Serverless v2だから必ず安いわけではない

サーバーレスという名前だけで、

常に従量課金で最安

とは判断しません。

例えば、

24時間
高い負荷が安定して継続

するなら、Aurora Serverless v2でも、

高いACUを
長時間使用

する可能性があります。

したがって、

プロビジョンド
vs
Aurora Serverless v2

では、

平均キャパシティ
ピークキャパシティ
低負荷時間
アイドル時間
キャパシティ変動

を比較します。

10. Aurora Serverless v2では最小 ACUがコスト 下限になる

Aurora Serverless v2では、

最小 ACU

より低くスケールしません。

例えば、

通常
1〜2 ACU程度

ピーク
16 ACU

のワークロードに、

最小
8 ACU

を設定すると、低負荷時にも、

8 ACU

を維持します。

したがって、

最小 ACU
↓
パフォーマンス余力
+
コスト 下限

として扱います。

単純に最小値を下げればよいわけでもありません。

低いキャパシティでは、

スケールアップ速度
ワーキングセット
接続要求

などへの影響も確認します。

11. Aurora Serverless v2のAuto-pauseをコストモデルへ入れる

対応するAuroraバージョンでは、

最小 キャパシティ
0 ACU

を設定すると、一定時間ユーザーアクティビティがない場合に、

Auto-pause

を利用できます。

一時停止中は、

DBインスタンス キャパシティ

に対する料金は発生しません。

ただし、

ストレージ
その他のクラスター コスト

までゼロになるわけではありません。

また、

ユーザー 接続が残っている

など、Auto-pauseできない条件があります。

そのため、

開発環境
検証環境
社内システム
長時間アイドルになるDB

などでは、

アイドル時間
+
再開遅延許容
+
Auto-pause可能条件

を確認します。

12. Aurora StandardとAurora I/O-Optimizedを比較する

Auroraでは、

Aurora Standard

と、

Aurora I/O-Optimized

というストレージ構成があります。

Aurora Standardでは、

DB キャパシティ
+
ストレージ
+
読み取り / 書き込み I/O

を考慮します。

Aurora I/O-Optimizedでは、

読み取り / 書き込み I/O

への追加料金がありません。

その代わり、キャパシティ料金の構造が異なります。

AWSでは、

I/O支出
>=
Aurora データベース 総支出の25%

の場合、

Aurora I/O-Optimized

を有力な候補としています。

13. I/O-Optimizedは「I/Oが多そう」で決めない

例えば、

Aurora 総コスト
10,000 USD

そのうちI/O
800 USD

なら、

I/O比率
8%

です。

この場合、

I/Oがある

という理由だけでI/O-Optimizedへ変えるのではありません。

一方、

Aurora 総コスト
10,000 USD

I/O
3,200 USD

なら、

32%

なので、I/O-Optimizedを比較する価値が高くなります。

判断するのは、

I/O リクエスト数

そのものより、

I/Oが総コストへ
どの程度影響しているか

です。

14. DynamoDBではキャパシティモードがコストモデルそのもの

DynamoDBでは、

オンデマンドキャパシティモード

と、

プロビジョンドキャパシティモード

があります。

技術的なスケーリング特性は既習です。

ここではコスト面から、

オンデマンド
→ 実際の読み取り / 書き込み リクエストに応じた課金

プロビジョンド
→ プロビジョンド キャパシティに応じた課金

という違いを使います。

15. ピークだけでDynamoDB キャパシティモードを決めない

例えば、

ピーク
10,000 requests/s

だとしても、

ほぼ24時間10,000

なのか、

1日5分だけ10,000
それ以外は数百

なのかでコストモデルは異なります。

見るべきなのは、

消費済み キャパシティ
+
プロビジョンド キャパシティ
+
使用率
+
低トラフィック期間
+
トラフィック変動

です。

つまり、

最大値

だけではなく、

キャパシティを
どれだけ効率よく使えるか

を確認します。

16. DynamoDB プロビジョンドでは使用率をコスト シグナルとして使う

プロビジョンドキャパシティでは、

プロビジョンド
-
消費済み

の差が大きいほど、未使用キャパシティが増えます。

例えば、

プロビジョンド
1,000 WCU

消費済み
平均250 WCU

の状態が長時間続くなら、

使用率
約25%

です。

これは、

パフォーマンス余力

である一方、

未使用コスト

でもあります。

DynamoDB Auto Scalingを使う場合も、

目標 使用率

が低すぎると、余剰キャパシティを多く維持しやすくなります。

17. DynamoDB Auto Scalingはコストとスロットリング リスクの交換条件

例えば、

目標 使用率
30%

なら、高い余裕を持たせます。

しかし、

未使用 キャパシティ

も増えやすくなります。

逆に、

目標 使用率
非常に高い

場合は、コスト効率は上がりやすい一方、

トラフィック急増
↓
Auto Scaling反映までの時間
↓
スロットリング リスク

を確認する必要があります。

そのため、

目標 使用率

は、

低いほど安全
高いほど安い

という単純な値ではありません。

トラフィック形状
+
急増
+
スロットリング 許容度
+
コスト

を合わせます。

18. DynamoDB StandardとStandard-IAを分ける

DynamoDBではキャパシティモードとは別に、

テーブルクラス

があります。

代表的には、

DynamoDB Standard
DynamoDB Standard-IA

です。

Standardでは、

スループット コスト

が相対的に低く、Standard-IAでは、

ストレージ コスト

を下げる代わりに、

読み取り / 書き込み コスト

が高くなります。

したがって、

On-Demand
vs
プロビジョンド

と、

Standard
vs
Standard-IA

は別の判断です。

19. DynamoDB Standard-IAはストレージ中心で評価する

例えば、

数TB保存

読み取り
月数回

更新
ほとんどなし

なら、

ストレージ コスト

が主要なコスト要因になりやすくなります。

この場合、

DynamoDB Standard-IA

を評価します。

一方、

保存量は小さい

読み取り・書き込みが大量

なら、

スループット コスト

が主要になります。

この場合は、

Standard-IAのストレージ削減額

だけを見て変更しません。

AWSでは、DynamoDB Standardを使用しているテーブルで、

ストレージ コスト
>=
テーブル月額総コストの約50%

を占める場合、

DynamoDB Standard-IA

を評価する目安になります。

逆に、

ストレージ コスト
<
テーブル月額総コストの約50%

で、読み取り・書き込み料金の比重が大きい場合は、Standardの料金バランスが適する可能性があります。

つまり比較するのは、

ストレージ コスト
vs
スループット コスト

そのものではなく、

ストレージ コスト
÷
テーブル月額全体 コスト

です。

20. テーブルクラスを変更してもアクセスパターンは変わらない

DynamoDB StandardとStandard-IAでは、

性能
可用性
耐久性

を下げてコストを削減する仕組みではありません。

同じDynamoDB APIを使用できます。

違うのは主に、

ストレージと読み取り / 書き込みの
料金バランス

です。

したがって、

Standard-IA
=
遅いDynamoDB

とは考えません。

21. 「サーバーレス = アイドル時ゼロ コスト」ではない

データベース サーバーレスでは、

サーバーを管理しない

ことと、

料金が常にゼロまで下がる

ことを分けます。

例えば、

Aurora Serverless v2

最小 ACU
Auto-pause
ストレージ

がコスト要因になります。

DynamoDB On-Demand

読み取り リクエスト
書き込み リクエスト
ストレージ
インデックス

がコスト要因になります。

つまり、

サーバーレス
=
コスト要因が消える

のではなく、

コスト要因が
使用量ベースへ変わる

と理解します。

22. データベースごとのコスト要因を比較する

重要なのは、

データベース名

ではなく、

そのデータベースで
何に課金されているか

です。

23. 同じ「変動するワークロード」でもコスト要因は違う

例えば、

Aurora

平日昼間
高負荷

夜間
低負荷

なら、

プロビジョンド キャパシティ
vs
Aurora Serverless v2 ACU 使用量

を比較します。

DynamoDB

普段
低トラフィック

キャンペーン
大きく急増

なら、

プロビジョンド キャパシティ 使用率
vs
On-Demand リクエスト 使用量

を比較します。

同じ、

変動が大きい

という要件でも、課金されるキャパシティモデルは異なります。

24. データベースコスト最適化のアンチパターン

25. SAP-C02での判断フロー

1. データベースアーキテクチャは要件を満たしているか
   ↓
既習の判断を前提

2. 使用パターンを確認
   ↓
安定
変動
急増
アイドル
読み取り / 書き込み比率

3. コスト要因を分解
   ↓
コンピューティング
ACU
ストレージ
IOPS
I/O
読み取り / 書き込み キャパシティ

4. Amazon RDS
   ↓
DBインスタンス
ストレージ
IOPS / スループットを適正化

5. RDS / Aurora プロビジョンド
   ↓
長期安定利用なら
リザーブド DBインスタンスを評価

6. Aurora
   ↓
プロビジョンド
vs
サーバーレス v2

7. Aurora Serverless v2
   ↓
最小 / 最大 ACU
アイドル時間
Auto-pause可能性

8. Aurora I/O コストを確認
   ↓
I/O比率が高い
→ I/O-Optimizedを評価

9. DynamoDB
   ↓
On-Demand
vs
プロビジョンド

10. プロビジョンド
    ↓
消費済み vs プロビジョンド
目標 使用率
Auto Scalingを確認

11. DynamoDB ストレージ コストを確認
    ↓
ストレージ中心
→ Standard-IAを評価

12. 各項目のコストを合算

13. パフォーマンス / 可用性要件を
    壊していないことを確認

14. 最もコスト効率の高いな
    キャパシティモデルを選択

まとめ

データベースコスト最適化では、

データベースサービス

そのものより、

使用パターン
↓
キャパシティモデル
↓
課金項目

を確認します。

Amazon RDSでは、

DBインスタンス
ストレージ
IOPS / スループット

を個別に適正化します。

ストレージ Auto Scalingでは、

スケールアップできる
+
スケールダウンできない

ことをコスト ガードレールへ反映します。

長期安定利用では、

リザーブドDBインスタンス

を評価します。

Amazon Auroraでは、

プロビジョンド
vs
Aurora Serverless v2

を使用パターンで比較します。

さらに、

Aurora Standard
vs
Aurora I/O-Optimized

をI/O コスト比率から判断します。

DynamoDBでは、

On-Demand
vs
プロビジョンド

と、

Standard
vs
Standard-IA

を別々に判断します。

最終的に見るのは、

データベースの名前

ではなく、

どのキャパシティを
どの程度
どの時間だけ使い
どの課金項目へ
料金を払っているか

です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• Amazon RDS — Reserved DB instances
• Amazon RDS — Managing capacity automatically with storage autoscaling
• Amazon Aurora — Aurora Serverless v2
• Amazon Aurora — Scaling to Zero ACUs with automatic pause and resume
• Amazon Aurora — Aurora Standard and Aurora I/O-Optimized
• Amazon DynamoDB — Throughput capacity modes
• Amazon DynamoDB — Evaluate your table capacity mode
• Amazon DynamoDB — Evaluate Auto Scaling settings
• Amazon DynamoDB — DynamoDB table classes
• AWS Well-Architected Framework — Cost-effective resources