可用性は、サービスやシステムが「使いたいときに使える」状態をどれだけ保てるかを表す指標や性質です。24時間営業のコンビニがいつ行っても開いているように、可用性の高いシステムは、障害やメンテナンスで止まる時間が短く、利用者がいつアクセスしても動いている状態に近づきます。
実際に動いていた時間の割合を記録した数字は稼働率と呼ばれ、可用性と同じ意味で使われることも多い言葉です。ただ、可用性のほうは「止まりにくく作られているか」という設計上の性質まで含みます。「99.9%」がおよそ何時間の停止にあたるかは、稼働率の記事で換算表にまとめました。
止まりにくさはどこで作るか
可用性は、障害が起きないことを祈って上げるものではありません。障害は起きる前提で、止まる範囲と時間を小さくするように設計します。
まず探すのは、1か所が止まるとサービス全体が落ちる場所（単一障害点）です。サーバーを複数台にして、1台が落ちても残りで動き続けられる構成にする。ヘルスチェックで異常な1台を見つけて自動的に切り離し、監視で問題を早めに検知する。それでも止まったときに素早く戻せるよう、復旧の手順と担当の体制を用意しておきます。
見落としやすいのがメンテナンスです。計画した停止も、利用者から見れば止まっている時間に変わりありません。サービスを止めずに新しい版へ入れ替えるデプロイの方法も検討しておきましょう。
どこまで止めないかは費用と相談
可用性は、上げるほど設計と運用のコストがかさみます。「絶対に止まってはいけない」システムと、「多少止まっても許容できる」システムでは、必要な投資がまったく違います。決済や医療のように止まると困るシステムほど、高い値が求められます。
だから最初に、そのサービスにどれだけの可用性が本当に必要かを決めます。チームで目標値（SLO）を合意し、そこから必要な構成と運用を逆算する。目標がないまま「なるべく止まらないように」と進めると、足りないか過剰かのどちらかになりがちです。外部サービスを使うなら、その目標とSLAの保証値が釣り合っているかも確かめます。