詳細ガイド
データベースとIOPSのスケーリング・シミュレーター：マネージドデータベースの費用がユーザーあたり売上を追い越すとき
業界のエグゼクティブ分析
マネージドデータベースは、スタックの中で人々が最も忘れたい部分であり、請求書が届くとき、向こうから思い出させてきます。最初は小さなインスタンスと小さなディスクから始まります。やがてユーザーが増え、機能がクエリを増やし、テーブルに履歴が溜まると、安かったプランが請求書で最大の行になります。ウェブサーバーと違って、データベースは安価な同一のマシンを足して拡張するわけではありません。より大きなインスタンスへ移り、プロビジョニングしたスループットを足し、すべてをレプリカに複製することで拡張します。その一つひとつの段階が、コストを何倍にもします。
この問題の構造は、売上がなめらかに伸びる一方で、コストは階段状に跳ね上がることです。インスタンスのサイズは倍々になり、2から4、8、16vCPUと進むたびに、価格もおおよそ倍になります。ストレージとIOPSは別に課金され、レプリカがそのすべてを倍加させます。インスタンスが倍になっても、ユーザーあたりの売上は倍になりません。ユーザーが3万人のときは余裕で黒字の事業が、次の1万人のユーザーから得る利益を、一段上のサイズが帳消しにしてしまうことがあります。
ドミノモデルは、その連鎖を追います。ユーザー数と1,000人あたりのIOPSが、ストレージ層へのピーク時の需要を決めます。計算の要件がインスタンスのサイズを決め、それがレプリカ、ストレージ、プロビジョニングしたスループットとともに請求額を決めます。請求額は売上に占める割合となり、それが最終的に利益を決めます。インデックスの不十分なクエリ一つで、ユーザー数が変わらなくても最初の箱が3倍になることがあります。クエリの最適化が、それ以降のすべての箱を下げる最も安価な方法であることが多いのは、このためです。
氷山は、誰もが目にするインスタンスと、請求額を予想以上に大きくする余分な項目を切り分けます。目に見えるのは、プライマリインスタンスとストレージです。水面下には、計算とストレージを繰り返すレプリカ、ディスクに含まれる基準値を超えるプロビジョニングIOPS、数週間保持されるバックアップ、ゾーン間でデータを複製する通信があります。それぞれ別の見出しで課金されるため、計画時に過小評価しやすいものです。シミュレーターで、ユーザーが増えるにつれてご自身の構成がどう振る舞うか、そしてデータベースがどこで負担できなくなるかを試してください。
計算式と方法論の設計図
このモデルは1か月です。ピーク時のIOPS需要は、ユーザー1,000人単位の数に、1,000人あたりのIOPSとピーク係数2.5を掛けたものです。必要な計算資源は、ユーザーあたり0.0005vCPUで、最小2を下限として2の累乗のインスタンスサイズに切り上げます。すべてのレプリカは、プライマリインスタンス、ストレージ、プロビジョニングIOPSを繰り返します。プロビジョニングIOPSは、3,000の基準値を超える分が課金されます。ストレージ、バックアップ、ゾーン間のレプリケーションが合計に加わり、その他のコストは売上の40%とします。
- ピーク時のIOPS
- I = ユーザー数 ÷ 1000 × 1000人あたりのIOPS × 2.5
- ストレージ層がピーク時に維持しなければならない、1秒あたりの操作数です。
- インスタンスのサイズ
- V = 2^切り上げ(log₂(max(2, ユーザー数 × 0.0005)))
- プライマリのvCPU数で、2の累乗のサイズで提供されます。
- データベース費用
- D = (1 + レプリカ数) × (V × 単価 + IOPS費用 + ストレージ) + バックアップ + ゾーン間通信
- すべてのノードで繰り返される計算、スループット、ストレージに、バックアップとレプリケーションを加えたものです。
- プロビジョニングIOPS
- max(0, I − 3000) × ノードあたり$0.10
- ディスクに含まれる量を超えるスループットで、ノードごとに課金されます。
- 純利益
- 純額 = 売上 × (1 − 40%) − D
- 月次の結果です。破綻点は、これがゼロになるところです。
連鎖する弾力性
レプリカとユーザーあたりのIOPSが、最も弾力的な入力値です。どちらも、すべてのノードに掛かるからです。ユーザーあたりの売上は、利益率全体に比例します。ユーザー数は、売上と、より大きなインスタンスへの段階的な移行の両方を通じて結果を変えるため、成長は無条件の勝利ではありません。
実例に基づく3つのケーススタディ
自己資金で始めるスタートアップ
最小限のデータベースで動く小さな製品
若い製品が、3,000人のユーザー、レプリカ1台、ユーザーあたりの軽いデータを持っています。ユーザーあたりの売上は高く、インスタンスは最小サイズです。読み込むと、初期にはデータベースがごくわずかな費用にすぎないことと、高いユーザーあたりの売上が成長の余地を与えることがわかります。
成長中の中堅企業
効率的なクエリを持つ大規模なユーザー基盤
30万人のユーザーを抱える製品が、インデックスとキャッシュでユーザーあたりのIOPSを低く保ち、レプリカ2台で運用しています。請求額は絶対額では大きいものの、売上に占める割合は控えめです。読み込むと、クエリが最適化されているとき、規模が味方する様子がわかります。
ブラックスワン級の危機
重いクエリと多すぎるレプリカ
ユーザー基盤が大きく、ユーザーあたりの売上が低い製品が、インデックスのないクエリ、5台のレプリカ、ユーザーあたり多量の保存データで運用しています。プロビジョニングIOPSとレプリカがすべてのコストを倍加させます。読み込むと、データベース費用が売上を上回る様子と、どの変数がその月を立て直すかがわかります。
業界ベンチマーク一覧
| 指標 | 危険ゾーン | 業界平均 | 上位10%のエリート水準 |
|---|---|---|---|
| 売上に占めるデータベース費用の割合 | 35%超 | 8〜15% | 6%未満 |
| アクティブユーザー1人あたりの月間データベース費用 | $0.25超 | $0.05〜0.12 | $0.04未満 |
| 一般的なSaaSのレプリカ数 | 読み取りの明確な必要なく4台以上 | 1〜2台 | スタンバイ1台と、目的を絞ったリードレプリカ |
| ピーク時に実際に使われるプロビジョニングIOPSの割合 | 30%未満 | 50〜70% | 70〜85% |
| バックアップの保持期間 | 数か月分のフルスナップショット | 7〜14日 | アーカイブ付きの段階的な保持 |
変数とレバー
アクティブユーザー数
通常月にデータベースへ負荷をかけるユーザーの数です。
レバー: ユーザーが増えれば常に利益率が良くなると決めつけないでください。ユーザーあたりの売上が、次のインスタンスサイズを賄えるかを確認します。
ユーザーあたりの月間売上
アクティブユーザー1人から得る月平均の売上です。
レバー: 料金プランの段階化でユーザーあたりの売上を上げてください。ユーザーあたりのデータベースコストは、利用量とストレージとともに増えます。
ユーザー1,000人あたりのピーク時に影響するIOPS
ユーザー1,000人ごとに発生する、1秒あたりの読み取りと書き込みの平均操作数です。クエリの設計とインデックスが、最も大きく動かします。
レバー: 不足しているインデックスを追加し、頻繁に読むデータをキャッシュし、書き込みをまとめてください。IOPSを減らせば、ディスクとインスタンスの大型化をどちらも避けられることが多いです。
vCPUあたりの月額料金
使用するインスタンスクラスについて、マネージドデータベースがvCPU1つあたりに請求する月額です。
レバー: インスタンスファミリーを比較し、負荷が予測できるようになったら、予約容量を契約してください。
リードレプリカとスタンバイ
読み取りやフェイルオーバーのための、データベースの追加コピーです。それぞれが、計算、ストレージ、IOPSのコストを繰り返します。
レバー: レプリカを一つずつ見直してください。フェイルオーバー用のスタンバイを1台残し、リードレプリカは、読み取りが本当に必要とするときにだけ追加します。
ユーザーあたりの保存データ量（GB）
インデックスを含め、各ユーザーが加えるデータベースストレージの平均ギガバイト数です。
レバー: 古い行をより安価なストレージにアーカイブし、保持期間の上限を設定し、大きな列を圧縮してください。
このシミュレーターの使い方
- 1現実的なプリセットから始めるか、ユーザー数、ユーザーあたりの売上、現在のインスタンスの詳細を入力します。
- 2五つのドミノの箱を見て、IOPSの需要とインスタンスのサイズのどちらが先に赤くなるかを確認します。
- 3「破綻点を探す」を押して、利益を消してしまう負荷やレプリカ数を確認します。
- 4現在の構成と最適化の計画を、24か月のグラフで比較します。
- 5次のインスタンスの段階に進む前に、四半期ごとに遅いクエリと未使用のレプリカを見直します。
避けたい間違い
- データベース費用がユーザー数に比例して増えると仮定すること。実際には階段状に増え、レプリカとともに倍加します。
- より大きなシステムから設定をコピーしたために、ワークロードが使う量をはるかに超えてIOPSをプロビジョニングすること。
- どのクエリも使っていないリードレプリカを維持し、計算とストレージに2倍、3倍の費用を払うこと。
- 負荷を生んだ遅いクエリと不足しているインデックスを調べる前に、インスタンスを大きくすること。
よくある質問
IOPSとは何で、なぜ課金されるのですか。
IOPSは1秒あたりの入出力操作数で、ストレージ層が実行する読み取りと書き込みの回数です。ストレージの階層によっては基準値を含み、それを超えるプロビジョニングしたスループットに課金されます。事業者の最新のルールを確認してください。
リードレプリカはいつ追加すべきですか。
読み取りが明らかに支配的でプライマリがボトルネックのとき、または地理的なレイテンシやフェイルオーバーが必要なときです。習慣でレプリカを足すと、請求額全体が倍加します。
なぜ特定のユーザー数でコストが跳ね上がるのですか。
インスタンスは固定のサイズで提供されるため、しきい値を超えると、価格がおおよそ倍の次のサイズに移ります。このモデルは、2の累乗のサイズを使って、そうした跳ね上がりを示しています。
大きなインスタンスのほうが、レプリカを増やすより優れていますか。
書き込みには、通常は大きなプライマリが答えです。読み取りには、レプリカやキャッシュが役立ちます。適切な組み合わせはワークロードによって異なるため、拡張する前に計測してください。
データベースが負担できなくなるユーザー数はどのように見つけますか。
「破綻点を探す」を押してください。ツールは各入力値を悪化する方向へ動かし、月次利益がゼロになる値を報告します。
どのくらい正確ですか。
説明用の価格を使った教育目的のモデルであり、技術的な見積もりでも助言でもありません。定数を事業者の最新の価格と、実測した負荷に置き換えてください。
これは前提条件を明示した、教育目的の計画モデルです。財務、税務、法律に関する助言ではありません。入力値はご自身の数字に置き換え、重要な判断は必ず資格を持つ専門家に確認してください。