先に要点
可用性(止まらなさ)は、高ければ高いほど良い ── と思いがちですが、上げるほどコストと複雑さが跳ね上がります。大事なのは「最大限止まらないこと」ではなく、「このシステムにとって必要な分だけ止まらないこと」です。
このページでは、可用性の段階と、どこまで上げるべきかを「止まると どれだけ困るか」から決める考え方を整理します。
可用性は「止まると どれだけ困るか」で決める
最初にやるのは技術選定ではなく、影響の言語化です。
- 5分止まったら、誰がどれだけ困るか
- 1時間止まったら、売上や信頼にどれだけ響くか
- 復旧に半日かかっても許されるのか、許されないのか
個人ブログなら数時間止まっても大事にはなりません。決済が走るサービスなら数分の停止が痛い。この差が、必要な可用性の段階を決めます。技術から入ると過剰になりがちなので、影響から逆算します。
可用性の段階
止まりにくさには段階があります。上に行くほど強くなりますが、コストと運用の複雑さも増えます。
| 段階 | 内容 | 向く対象 |
|---|---|---|
| 単一構成 | 1台で動かす。落ちたら止まる | 個人・検証・止まっても困らないサイト |
| 冗長化 | 同じものを複数用意し、1台落ちても継続 | 止まると困る一般的なサービス |
| マルチAZ | 物理的に離れた区画に分散。区画障害でも継続 | 止められない業務・決済系 |
| マルチリージョン | 地理的に離れた地域に分散。地域障害でも継続 | 大規模・極めて高い可用性が要る場合 |
多くのシステムは、単一構成か冗長化で十分です。マルチAZ以上は、止められない要件が明確にあるときに初めて検討します。DBを冗長にする具体はDBサーバーを分ける必要性、マネージドDBでの自動切替はRDS / Aurora の違いと選び方が参考になります。
「9」のコストを知る
可用性は「99.9%」のように表され、9が増えるほど止まる時間が短くなります。
99% (ツーナイン)
年間で約3.6日止まる計算。多くの個人・小規模はこれで十分。
99.9% (スリーナイン)
年間で約8.8時間。一般的なサービスの目安。冗長化が要る。
99.99% (フォーナイン)
年間で約52分。マルチAZや高度な運用が要り、コストが跳ねる。
ポイントは、9を1つ増やすたびに、必要な手間とお金は段違いに増えることです。「とりあえず高く」ではなく、影響に見合う段階を選びます。過剰な可用性は、可用性が古いまま放置されるリスク(サーバーのOSが古いとどうなる？)とは別に、運用負荷だけを増やします。
よくある質問
Q. 可用性は高ければ高いほど良いのでは？
A. いいえ。上げるほどコストと運用の複雑さが跳ね上がります。必要なのは「最大限止まらないこと」ではなく「このシステムに必要な分だけ止まらないこと」です。止まったときの影響に見合わない高可用性は、性能ではなく出費と手間だけを増やします。
Q. うちのサービスはどの段階が適切ですか？
A. 「何分止まったら、誰が、どれだけ困るか」を言語化すると決まります。数時間止まっても問題ないなら単一構成、止まると困るが復旧待ちは許されるなら冗長化、数分の停止も許されないならマルチAZ、と影響から逆算します。技術から入ると過剰になりがちです。
Q. 冗長化とマルチAZは何が違いますか？
A. 冗長化は「同じものを複数用意して1台落ちても継続する」こと全般を指します。マルチAZは、その複数を「物理的に離れた区画(アベイラビリティゾーン)」に分散する構成で、区画全体の障害でも継続できます。マルチAZの方が強い代わりに、コストと設計の複雑さが増します。
Q. 小規模なら可用性は気にしなくていいですか？
A. 過剰に作り込む必要はありませんが、最低限のバックアップと復旧手段は持っておきます。単一構成でも、データのバックアップと「落ちたらどう戻すか」の手順があれば、多くの小規模サービスは十分です。可用性を上げるより先に、まず「戻せる」ことを確保するのが現実的です。
関連する考え方
- 構成選びの総論: 構成の選び方（総論）
- 冗長化の具体: DBサーバーを分ける必要性
- マネージドでの自動切替: RDS / Aurora の違いと選び方