マネージドが高く見える理由
一言でいうと
マネージドサービスの値段は、料金表を直接比べるといつも高く見えます。抜けている項目があるからです。私たちの時間と、私たちができなくなることです。
なぜ必要なのか
「RDSはEC2に自分で入れたものの2倍」という比較が、会議でよく出ます。数字は合っています。ところが、その比較表には、こんな行がありません。
| 抜けている項目 | 自前運用なら |
|---|---|
| パッチの計画・適用 | 四半期ごとに数日、夜間作業 |
| バックアップの設定・検証 | 初期構築 + 復旧リハーサル |
| 冗長化の構成 | レプリケーション設定・フェイルオーバーテスト |
| モニタリング | メトリクス収集・アラートルールの作成 |
| 障害対応 | 明け方の呼び出し。頻度は低いが、0ではありません |
| バージョンアップ | 数年に1回、毎回大きな作業 |
これを人の時間に換算すると、たいてい料金の差額を超えます。特に、チームが小さいほどそうです。3人のチームで1人がDB運用に20%を使えば、それは人件費の6–7%で、たいていのマネージドの料金差額より大きくなります。
マネージドを選ぶことの例外
ただし、いつもマネージドが答えとは限らない
逆方向の計算もしなければなりません。
- 規模が非常に大きければ、自前運用の単位コストがはるかに低くなります。数百台の規模では、専任の人員を置くほうが安くなります。
- 負荷が特殊なら、マネージドの既定の設定が合いません。チューニングの余地がなく、お金だけで解決することになり、それのほうが高くつきます。
- すでにうまくやれているなら、わざわざ移す理由はありません。うまく動いているものを変えるのにも、コストがかかります。
判断を数字にする方法
3行だけ書いてみると、たいてい結論が出ます。
1. 월 요금 차액 = ( 관리형 − 직접 ) 원
2. 직접 운영에 드는 월 인시(person-hours)
3. 인시 × 시간당 비용 = 숨은 비용 원
2+3 이 1 보다 크면 관리형이 싸다.
ここに1行を加えると、正確になります。その時間にできなかったことの値打ちです。DBの面倒を見ていて作れなかった機能があれば、それが本当のコストです。
マネージドに移すときに確認するリスト
- 必要なバージョンと拡張がサポートされているか
- 接続数・性能の上限が自分たちの負荷に耐えられるか
- バックアップの保持と復旧時間(RTO)が、要件に合っているか
- ログとメトリクスを、必要なだけ見られるか
- メンテナンスウィンドウを自分たちで決められるか
- 出るときに、データをどう取り出すか
6つ目を最初に確認するチームはまれで、あとでいちばん高くつきます。
自前運用で実際にかかるもの
マネージドと自前運用の料金表だけを比べると、いつも自前運用が安く見えます。料金表にないものも一緒に数えて、初めて比較が成り立ちます。
| 項目 | 自前運用 | マネージド |
|---|---|---|
| インスタンス・ストレージ | 料金表どおり | 料金表どおり(たいてい1.5–3倍) |
| 高可用性の構成 | 待機ノードのコスト + 構成の時間 | 含まれる(またはスイッチ1つ) |
| バックアップ・復旧リハーサル | 人が設計・検証 | 含まれる。ポイントインタイムリカバリーはクリック1つ |
| バージョンアップ | 四半期ごとに計画・リハーサル・作業ウィンドウ | ウィンドウを選べば完了 |
| 当番 | 人が明け方に起きる | たいてい起きない |
| モニタリング・アラート | 構築・維持 | 標準のダッシュボード |
いちばん大きい項目は、最後の3つです。DBのバージョンアップ1回にエンジニア2日かかるとすれば、年4回で8日です。人件費を1日60万ウォンとすると、480万ウォンです。インスタンス数台分の値段です。
判断を数字1行で
자체 운영 총비용 = 인프라 + (연간 운영 시간 × 시간당 인건비) + 사고 비용 기댓값
관리형 총비용 = 인프라(비싼 값) + (남는 시간 × 그 시간에 만들 가치)
最後の項が核心です。マネージドを買うことは、時間を買うことであり、その時間にプロダクトを作れるなら、得な取引です。逆に、人員が十分にいて、特殊なチューニングが必要なら、自前運用が合っています。
ロックイン(lock-in)を値段に換算する
マネージドの本当の代償は、料金ではなく離れにくさです。ただし、これにも程度があります。
| 種類 | ロックインの程度 | 例 |
|---|---|---|
| 標準プロトコルそのまま | 低い | マネージドPostgreSQL・Redis・Kafka |
| 標準 + 独自の拡張 | 中程度 | Aurora、ElastiCacheの拡張機能 |
| 完全な独自API | 高い | DynamoDB、Firestore、サーバーレス関数 |
1行目は、事実上ロックインがありません。同じプロトコルを使う別の場所にダンプして移せばよいのです。ロックインが心配なら、標準プロトコルのマネージドから使います。独自APIを使うときは、その利点が移行コストを上回るか、先に計算します。
現場での姿
- 料金だけを比べて自前運用にしました → 6か月後に担当者が退職し、誰もわからない状態になりました。
- マネージドに移したら、接続数の上限に引っかかりました → 事前の確認漏れです。
- マネージドのコストが膨らんで元に戻そうとしたら、データの書き出しが途方もなく難しいと気づきました → 6つ目を見ていませんでした。
次に見ること
最後に、クラウドに移すべきでないものについて話します。