サーバーダウン

🐾 猫で例えると？

タワーの上で前足を垂らし、眠る茶トラ。ここで「呼び掛けても、今は返事をもらえない」場面を想像すると、サービスを使えない状態のイメージになります。実際のサーバーダウンは原因を調べる必要があり、予定されたスリープや停止とは区別します。

💻 IT現場における「サーバーダウン」とは？

利用者から見て応答がなくても、サーバー本体が完全停止したとは限りません。猫に呼びかけが届いていないのか、猫が休んでいるのかを分けるように、DNS、接続、HTTP応答、アプリ内部を順に確認します。

障害の影響はサービスの用途によって異なります。運用では、監視の通知先、切り分け手順、利用者への案内方法をあらかじめ決め、担当者の記憶だけに頼らない形にします。

⚠️ サーバーダウンの仕組みと注意点

サーバーがダウンする原因は様々ですが、代表的なものは以下の3つです。

1. リソースの枯渇（過負荷）
テレビやSNSで紹介され、想定を超えるアクセスが集中した結果、CPUやメモリの限界を超えて処理が追いつかなくなるケースです。サイバー攻撃によって意図的に引き起こされることもあります。

2. ハードウェアやネットワークの障害
サーバー本体の部品の故障や、データセンターの回線トラブル、停電など、物理的な要因でシステムが停止するケースです。

3. アプリケーションのバグ（ソフトウェアの不具合）
プログラムの欠陥により、無限ループに陥ったりメモリの解放忘れが発生したりしてシステムが自滅するケースです。茶トラへのちょっかいが度を越して、アメショがマジギレしてシステム全体を巻き込んでダウンするようなものです。

# HTTPの応答例
200 OK                  # 要求が成功
404 Not Found           # 対象のリソースが見つからない
500 Internal Server Error # サーバー内部で予期しない問題
503 Service Unavailable # 一時的に処理できない（過負荷や保守など）

503は「処理できない」というHTTP応答が返っている状態です。接続そのものが失敗する場合や、時間内に応答が届かないタイムアウトとは異なります。また、503だけで過負荷と断定せず、保守設定や上流サービスのログも確認します。

🛠️ サーバーダウンを防ぐためのポイント

「サーバーはいつか必ず落ちるもの」という前提に立ち、落ちてもサービスを継続できる可用性の高いシステムを設計することが重要です。

• 冗長化： 複数のサーバーを用意しても、データ同期、切替判定、共有する依存先まで考えなければ復旧できません。実際に切り替える試験で、許容する停止時間やデータ損失を満たすか確認します。
• 容量を調整する： オートスケーリングには起動時間と上限があります。CPUだけでなく待ち行列や応答時間も見て、急増への余裕、流量制限、縮退動作を組み合わせます。
• フェイルセーフ設計： 雷の音に驚いた茶トラが瞬時にソファーの下へ潜り込むように、異常を検知した際は被害を最小限に抑えるよう、システムを安全に停止・縮退稼働させる設計が求められます。

眠る茶トラを見ていると休ませたくなりますが、サービスの停止には利用者への影響があります。「絶対に止まらない」ことを前提にせず、停止を検知する方法、切り替え先、復旧手順を用意し、実際に復旧できるかを確認しておきましょう。