「Web サービスは、24 時間 365 日止まらず動いているのが当たり前」——私たちは、いつからそう考えるようになったのでしょうか。
本シリーズのテーマは、24/365 稼働で得られるものはセキュリティ脅威に見合うかです。常時稼働を無条件に否定するのではなく、その便益と代償を、セキュリティ・運用・事業の視点から考えます。
技術的には、計画停止が有効な選択肢になり得る。復旧手順を日常的に検証することにも価値がある。運用者の負荷や、無停止を実現するための複雑性も無視できない。――
それでも、現場だけで「このサービスは定期的に止めます」と決めることはできません。停止すれば、利用者の作業が中断したり、売上や業務に影響が出たりする可能性があります。最後に必要なのは、サービスに求める可用性を、事業上の価値とリスクに基づいて決めることです。
1. 可用性は、高ければ高いほどよいのか
可用性の目標を高く設定することには、費用がかかる場合があります。追加のインフラ、運用自動化、検証環境、複雑な切り替え手順、保守のための追加作業などです。その費用を払う価値があるかどうかは、サービスによって異なります。
例えば、緊急時にも利用できなければ人命や安全に影響するサービスと、利用者が翌朝まで待てる社内向けサービスでは、停止の許容度は同じではありません。オンライン販売のサービスでも、注文を受け付けられない時間の損失と、重大な侵害を受けた場合の損害を比較する必要があります。
時間ベースで単純計算した場合、年間の可用性 99.9 % は約 8 時間 46 分、99.99 % は約 53 分の停止に相当します。ただし、これは計画停止も停止時間に含める前提の概算です。実際の SLA では計画メンテナンスを稼働率の計算対象外にする場合もあります。契約上の数字だけでなく、利用者が実際に利用できなかった時間も別に把握しなければ、サービスの実態が見えなくなります。
Google の SRE の考え方も、可用性は無制限に高めるものではなく、サービスの目的と事業が許容するリスクに合わせて決めるべきだとしています。目標を高めるほど、他の改善に使える費用や時間が減ることがあるからです。
したがって「すべてのサービスを 99.9 % にする」といった一律の答えも、逆に「すべてのサービスを 99.99 % 以上にする」という答えも適切ではありません。考えるべきなのは、そのサービスに必要な水準です。
2. メンテナンスウィンドウを決めるための五つの問い
経営層、サービス責任者、運用チームは、少なくとも次の問いを一緒に検討する必要があります。
第一に、停止すると誰にどんな影響があるのか。
利用者が停止時間を避けられるか、代替手段があるか、業務が中断したときの損失はどれくらいかを確認します。停止の影響が大きいなら、全面停止以外の方法も検討します。
第二に、どれくらい早く更新や修正を実行する必要があるのか。
重大な脆弱性が公表されたとき、次の定期メンテナンスまで待てるとは限りません。緊急更新の判断基準と実施権限をあらかじめ決め、必要なら通常のメンテナンス日程を待たずに対応できるようにしておきます。
第三に、停止以外の方法はあるのか。
段階的に更新する、冗長構成を利用する、一部の機能だけを止めるなど、選択肢を比較します。どの方法が最適かはシステムの構造とサービス要件によって変わります。
第四に、総コストはどう違うのか。
インフラ費用だけでなく、開発・検証・運用にかかる時間、夜間対応、停止による損失、障害や侵害からの復旧費用も比較します。計画停止が必ず安くなるわけではありませんが、無停止のために支払っている費用を見えるようにすることには意味があります。
第五に、復旧できることを確かめているか。
起動手順が動くこと、信頼できる状態から環境を再構築できること、バックアップを復元できること、復旧後のデータを確認できることをテストします。テストで見つかった問題と、その是正状況を記録しておきます。
3. 顧客との約束を、数字だけで終わらせない
メンテナンスウィンドウを運用に組み込むなら、利用者にいつ、何が使えなくなるのかを明確に伝える必要があります。SLA や利用規約で保守時間をどう扱うかも、サービスの性質と契約に合わせて整理します。
ただし、計画停止を稼働率の計算から除外すれば、それだけで顧客の信頼が高まるわけではありません。利用者が実際に受ける影響、通知の方法、停止時間の長さ、予定外の停止が発生した場合の説明を透明にすることが重要です。
顧客に伝えるべきなのは「安全のためだから止めます」という一言だけではありません。なぜ保守時間が必要なのか、利用者にどのような影響があるのか、どのように復旧を確認するのかを、わかりやすく説明することです。
経営側も、現場に「絶対に止めるな」と求めるだけではなく、必要な保守と緊急対応を実施できる判断基準や権限を用意する必要があります。一方、現場も、停止の必要性を技術用語だけで説明するのではなく、事業への影響、リスク、費用、代替策に置き換えて示すことが求められます。
計画停止の目的は、停止を正当化することではありません。事業に必要な可用性を守りながら、更新と復旧を確実に行える運用をつくることです。
結び：守るべきは、稼働率という数字だけではない
24/365 の稼働が、すべてのサービスにとって過剰だというわけではありません。止まることの影響が極めて大きく、高い可用性が事業要件であるなら、そのための仕組みへの投資は合理的です。
一方で、必要性が明確でないまま高い可用性を目指し、保守や更新の余地を狭め、複雑性と運用負荷を積み上げているなら、その方針は見直す価値があります。計画停止は万能なセキュリティ対策ではありません。しかし、必要なときに安全に止め、検証し、復旧できる設計は、組織の選択肢を増やします。
シリーズを通じて考えてきたのは、「止めるべきか、止めないべきか」という二択ではありません。その可用性によって得られる価値は、追加の費用、複雑性、セキュリティ上の制約、運用者への負荷に本当に見合っているかという問いです。
稼働率の数字だけではなく、必要な更新を適時に行えること、信頼できる環境へ戻れること、そしてそれを担う人たちが持続可能な形で運用できること。これらを含めて判断するとき、24/365 は慣習ではなく、目的に合った選択になります。
参考資料