ネットショッピングしようとしたら「サービスが一時停止しています」って画面が出て、結局買えなかった……なんて経験、ない？ あるいは、試験前夜に調べ物しようとしたら学校のサイトがダウンしてて焦った、とかさ。実はそういう「使いたいときに使えるか」問題、IT業界には専門の言葉があって、それが可用性なんだよね。この記事を読めば、可用性って何か・なんで大事なのか・どうやって上げるのかが、スッキリわかるよ。
- 可用性とは「使いたいときに使える状態かどうか」を示す指標で、稼働率（パーセント）で表されることが多い
- 一般的に99.9%（スリーナイン）が最低ラインとされ、重要なサービスほどより高い稼働率が求められる
- 可用性を上げるには冗長化・障害対策・監視などの仕組みが必要で、コストとのトレードオフが常に存在する
もうちょっと詳しく
可用性は、ITの世界では「セキュリティの3大要素」のひとつとして数えられているよ。その3つとは、情報が正しい人だけに見える機密性、情報が改ざんされていない完全性、そしてサービスがいつでも使える可用性。この3つをまとめて「CIA」（Confidentiality・Integrity・Availability の頭文字）って呼ぶんだ。可用性を高めるためには、サーバーを複数台用意して一台壊れても大丈夫にする「冗長化」、障害を素早く検知して自動で切り替える「フェイルオーバー」、そして定期的なバックアップと復旧訓練が欠かせない。個人のパソコンでも、大事なファイルのバックアップをとっておくのは、自分の情報の可用性を守ることにつながるよ。
可用性はセキュリティの「CIA」の一角！ 機密性・完全性と並ぶ超重要な概念だよ。
⚠️ よくある勘違い
→ 可用性はあくまで「使える時間の割合」の話。処理速度や応答の速さは「パフォーマンス」という別の概念で、可用性とは直接関係ないよ。
→ たとえ処理が遅くても、ちゃんとサービスが動いていれば可用性は高い。速さと安定性は別物として考えよう。
[toc]
可用性とは何か？ 基本をしっかり理解しよう
「使えること」がどれだけ大事か
たとえば、学校の近くに売れてるたい焼き屋さんがあるとしよう。味は最高なんだけど、行くたびに「本日は準備中」の札が出てることが多い……。そうなると、どんなに美味しくても「あそこは当てにならない」って思われちゃうよね。Webサービスやシステムも同じで、どれだけ便利な機能があっても、いざ使おうとしたら動いていない状態が続くと、ユーザーは離れていってしまうんだよ。
可用性（かようせい）は英語で “Availability”（アベイラビリティ）と言って、「システムが使用可能な状態にある時間の割合」のことを指すんだ。つまり、「サービスが稼働している時間 ÷ 全体の時間」で計算される数値のことだよ。この数値が高いほど、「いつ使っても繋がる、止まらない、安定している」ということになる。
身近なところにある可用性の話
可用性って、実は日常のあちこちにある考え方だよ。たとえばこんな場面を考えてみて。
- ATM：夜中に現金が必要になって銀行のATMに行ったら「只今利用できません」……これは可用性が低い状態。
- 電車：大雨で電車が止まって学校に遅刻した。つまり電車の可用性が一時的に低下した。
- 動画配信サービス：みんなが一斉に年末の特番を見ようとしてサーバーがダウン。アクセスできない状態＝可用性の低下。
- 病院の救急：どんな時間でも急患を受け入れられる体制が整っている＝可用性が高い。
こうして見ると、「当たり前のように使えること」の裏には、可用性を維持するための大きな努力があることがわかるよね。
稼働率の数字って何を意味するの？ ナインの世界を覗いてみよう
パーセントでみる稼働率の現実
可用性を表すときは、よく「稼働率（かどうりつ）」というパーセントが使われるよ。つまり、「全体の時間のうち、ちゃんと動いていた時間の割合」のことだね。一見すると99%って高そうだけど、実際に計算してみると話が変わってくる。
- 99%（ツーナイン）：年間で約87.6時間（約3.6日！）止まっていいことになる
- 99.9%（スリーナイン）：年間で約8.7時間止まっていい
- 99.99%（フォーナイン）：年間で約52.6分しか止まれない
- 99.999%（ファイブナイン）：年間で約5.26分しか止まれない
99%と99.999%では、許容される停止時間が実に1000倍以上違うんだ。銀行のシステムや救急病院の電子カルテみたいに「1分でも止まったら命に関わる・大損害になる」ものは、ファイブナイン以上を目指す場合もあるよ。逆に、社内の連絡ツールなんかだとスリーナインで十分な場合もある。何にどれだけの可用性が必要かを考えることが、システム設計の第一歩なんだよ。
稼働率の計算式を覚えよう
稼働率は難しい計算式じゃないから安心してね。こんな感じで求めるよ。
- 稼働率（%）＝（稼働時間 ÷ 総時間）× 100
- 例：1年間（8760時間）のうち8752時間動いてたら → 8752÷8760×100 ≒ 99.9%
この数字を見るだけで「このサービスはどれくらい信頼できるか」がわかるから、契約書や仕様書に「SLA（Service Level Agreement：サービスレベル合意）」という形で書いてあることも多い。つまり、「うちのサービスは最低99.9%は動かすことを約束します」という取り決めのことだよ。
なぜ可用性は下がる？ 障害の原因を知っておこう
ハードウェア障害：機械はいつか壊れる
どんな優秀なサーバーも、物理的な機械である以上、いつかは壊れる。ハードディスクが壊れる、電源が落ちる、ネットワーク機器が故障する……こういった「ハードウェア障害」は、可用性を下げる最も古典的な原因だよ。コンビニで例えると、冷蔵ショーケースが突然壊れてアイスが売れなくなるイメージ。機械が壊れること自体は防げないから、壊れたときの対策をあらかじめ準備しておくことが大事になるんだ。
ソフトウェアのバグ・設定ミス
プログラムのバグや、設定ファイルの書き間違いも、システムを止める大きな原因になるよ。「アップデートしたら急に動かなくなった」という経験、スマホアプリでもあるよね。あれの大規模版が企業システムで起きると、何百万人もの人が一気に使えなくなる事態になる。2016年に起きた某SNSの大規模障害も、設定変更のミスが原因だったと言われているよ。
アクセス集中（トラフィック過多）
人気アーティストのライブチケットが販売解禁された瞬間、チケットサイトがダウンした……なんてニュース、聞いたことない？ 短時間に大量のアクセスが集中すると、サーバーが処理しきれずにクラッシュすることがあるんだ。これを「スパイク（急激なアクセス増加）」って言って、可用性に大きな影響を与える要因のひとつだよ。普段は余裕があるシステムも、想定外の量のリクエストが来ると一気にパンクすることがある。
自然災害・停電
地震・台風・洪水・大規模停電。これらは人間の力ではコントロールできないけど、データセンターが被害を受けると、そこで動いているサービス全体が止まってしまう。だからこそ、地理的に離れた場所に複数のデータセンターを持つ「地理的冗長化」が重要視されるんだよ。つまり、東日本のデータセンターが被害を受けても、西日本のデータセンターで続けられる仕組みを持つということ。
可用性を高める3つの主要な方法
冗長化（じょうちょうか）：同じものを複数用意する
可用性を高める最もポピュラーな方法が「冗長化」だよ。つまり、同じ役割を持つサーバーやネットワーク機器を複数用意しておいて、1台が壊れても別の1台が自動的に引き継ぐ仕組みのことだよ。飛行機のエンジンに似ているかもしれない。旅客機は普通エンジンを2〜4基積んでいて、1基が止まっても飛び続けられるよね。あの考え方をシステムに適用したのが冗長化なんだ。
具体的な冗長化の種類としては、こんなものがあるよ。
- サーバーの冗長化：同じWebサーバーを2台以上動かして、片方が落ちても別の1台が対応する
- ネットワーク回線の冗長化：インターネット回線を2社から引いて、1社の回線が切れても別の回線で繋がる
- データセンターの冗長化：地理的に離れた場所に複数のデータセンターを持つ
- 電源の冗長化：UPS（無停電電源装置）や自家発電機を用意して停電に備える
フェイルオーバー：自動で切り替える仕組み
冗長化で複数の機器を用意しても、切り替えが手動だと人が気づいて操作するまでの数分間がロスになる。そこで活躍するのが「フェイルオーバー」だよ。つまり、障害が起きたことを自動検知して、自動でバックアップ側に切り替える仕組みのことだよ。人間が寝ている深夜3時にサーバーが落ちても、自動でフェイルオーバーが動いてくれれば、ユーザーはほとんど気づかないレベルで復旧できる。「障害 → 自動検知 → 自動切り替え」のサイクルを素早くすることが、可用性を守る鍵なんだ。
監視とアラート：早期発見が命
病気と同じで、システムの問題も「早期発見・早期対処」が大事だよ。24時間365日、システムの状態を自動で監視して、異常があったら担当者にすぐ通知する仕組みを「監視（モニタリング）」って言う。たとえば「サーバーのCPU使用率が90%を超えた」「エラーが急増した」「応答時間が通常の3倍になった」といった変化を検知して、エンジニアのスマホにアラートを飛ばすんだ。早めに気づければ、完全にダウンする前に対処できることが多い。これは定期的な健康診断で病気を早期発見するのと同じ考え方だよ。
ビジネスと可用性：なぜ企業はここまで気にするの？
ダウンタイム＝直接的な損失
可用性が下がって「ダウンタイム（システムが停止している時間）」が発生すると、企業にとって直接的な金銭的損失につながる。オンラインショップがダウンしている1時間、売上は0円だよね。大手ECサイトだと、1分間のダウンで数百万円の損失になることもある。さらに、ユーザーからの信頼も失われるから、長期的な損失はさらに大きい。「また落ちた、このサービスには頼れない」と思ったユーザーは競合他社のサービスに乗り換えてしまうよ。
SLA（サービスレベル合意）という約束
企業同士でシステムを使ったり提供したりするとき、「SLA（Service Level Agreement）」という契約を結ぶことが多い。つまり、「このサービスは月間99.9%以上の稼働率を保証します。下回ったら料金を返金します」といった約束を文書にしたものだよ。クラウドサービス（AWSやGoogleCloudなど）は公式にSLAを公開していて、それ以下になったら返金や補償をするルールを決めているよ。
クラウド時代の可用性
最近は自社でサーバーを持つより、AWSやAzureなどの「クラウドサービス」を使う企業が増えているよ。クラウドの良いところのひとつが、可用性を高めるための機能が最初からたくさん用意されているところ。サーバーの自動スケールアップ（アクセスが増えたら自動でサーバーを増やす）や、複数のデータセンターに自動でデータを分散させる機能など、かつては大企業しか実現できなかった高可用性の仕組みが、中小企業でも手軽に使えるようになったんだよ。
可用性の考え方は、ITに関わるすべての人が知っておきたい基礎知識だよ。ふだん何気なく使っているサービスの裏には、「いつでも使えること」を守るためのエンジニアたちの工夫と努力がある。次に「つながらない！」となったとき、そのシステムが可用性をどう守ろうとしているか、ちょっと想像してみてね。
