マネージドとセルフ管理の線引き

参考: スケールしないならセルフ管理も視野に入れていい、という話

コンテナを載せる先として、マネージド（ECS on Fargate、Cloud Run）と、VM に Docker を置いて docker-compose で上げる自前運用のどちらを選ぶか。「スケールしないならセルフ管理も視野に入る」はよく言われるが、その線引きを整理した。

昔、師匠が「初心者のEC2、中級のECS、玄人のEC2」と言っていた。後半のEC2は箱一台をdocker-composeで自前運用する側の話で、安く握る話でもあるし、型に乗らない構成を分かったうえで選ぶ話でもある。

マネージドの反対語

managed の対になる語は self-hosted か self-managed。AWS のドキュメントでは unmanaged も使う（EC2 は unmanaged compute という扱い）。日本語では「自前運用」で通じる。

何を選ぶか

表1: 選定フロー

手順	判断すること	結果
1	分単位の停止が許されない（SLA・契約で縛られている）	セルフを除外 → マネージド
2	復旧できる人が自分1人しかいない	セルフを除外 → マネージド
3	パッチ適用や構成変更の証跡を外部に提出する必要がある	セルフを除外 → マネージド
4	負荷の変動が大きい（ピークと谷の比が大きい）	マネージド
5	上記すべてに当てはまらない	セルフ管理でよい

既定はマネージド。 手順1〜4 のどれか1つでも当たればセルフは選べず、全部外れたときだけセルフが候補になる。

「スケールしない」は手順4に相当するので、必要条件を1つ挙げているにすぎない。手順1〜3 はスケールと無関係にセルフを潰す。

手順1〜4 が全部外れた場合も、行き先は生 VM だけではない。Lightsail や Fly.io、Railway のように、VM 程度の値段でホスト管理を持たない層がある。生 EC2 を積極的に選ぶ理由は「マネージドの型に乗らない構成を抱えている」に絞られる。

判断の根拠

表2: 4軸

軸	問い	セルフ管理でよい	マネージドにすべき
復旧時間	深夜にホストが飛んだとして、何時間止められるか	数時間〜翌営業日で許される	分単位。SLA・契約で縛られている
復旧の担い手	それを戻せる人は何人いるか	自分以外にも戻せる、または止まっても誰も困らない	自分1人。休むと詰む
証跡の提出	パッチ適用や構成の証跡を外部に出す必要があるか	ない	ある。証跡を自前で作る手間がマネージド差額を超える
負荷の形	使用率のピークと谷の比はどれくらいか	ほぼ平坦（常時稼働）	変動が大きい。谷の分をセルフでは削れない

コストの比べ方

比べるのはインスタンス単価の差ではなく、差額と自分の時給。

マネージド差額（月額） vs 自前運用にかかる時間（月） × 時給

月 5,000 円しか浮かないのに、パッチ当てや監視、復旧に月 3 時間使うなら赤字になる。月 10 万円浮くなら、月 10 時間払っても黒字。

個人開発や検証環境でセルフが強く見えるのは、差額が大きいからというより、この時給を自分でゼロと見なせるから。業務で同じ計算をすると大抵ひっくり返る。