24時間動き続けるシステムを運用するための参考アーキテクチャです。どのツールが優れているかではなく、何を監視すべきか、そしてどのアラートなら人を起こす価値があるのかに焦点を当てます。
これは参考アーキテクチャであり、導入事例ではありません。このページに顧客名や特定案件の数値は含まれていません。
課題
社外の顧客に提供しているシステムで、停止すれば売上と信用の両方を失う。エンジニアは少人数で、3交代を組めるほどの人数はいない。現状、障害に最初に気づく手段として最も多いのは、顧客からの電話です。
監視の4つの層
第1層 — 生きているか
外部から、1分間隔で、複数の地域から確認します。これが絶対的な最低ラインです。複数地域から見ることで、本当の障害と、一部のネットワーク経路の問題を区別できます。
第2層 — サーバー資源
CPU、メモリ、ディスク空き容量、データベース接続数。ディスクの空き容量枯渇は障害原因として意外なほど多く、同時に最も予防が容易です。80%で通知してください。
第3層 — アプリケーションの挙動
応答時間、エラー率、リクエスト数。重要なのは平均ではなく95パーセンタイルと99パーセンタイルです。平均は問題を隠します。利用者の95%が200ミリ秒で応答を得ていて、残り5%が8秒待たされていても、平均値は良好に見えます。その間、顧客の5%は悪い体験をしています。
第4層 — 業務指標
この層は省略されがちですが、障害を最初に検知するのはしばしばこの層です。1時間あたりの注文数、ログイン成功数、決済件数。技術指標がすべて正常なのに注文が突然ゼロになったなら、技術監視では見えない形で何かが壊れています。
業務指標は、技術監視が見逃すものを捉える
サーバーは正常、データベースも高速、ログにエラーなし。しかし購入ボタンの表示が崩れていて誰も押せない。すべての表示が緑のまま、売上はゼロです。これを捉えられるのは業務指標だけです。
アラート設計 — 本当の問題は「多すぎること」
1日に50件のアラートを出すシステムは、やがて本物を含めてすべて無視されるようになります。監視が機能しなくなる最も一般的な原因は、ツールの不足ではなく、雑音の多さです。
| 深刻度 | 条件 | 対応 |
|---|---|---|
| 重大 | サービス停止、またはデータが危険にさらされている | 電話。時間帯を問わず人を起こす |
| 警告 | 性能が落ちているが提供は継続、または閾値に接近 | メッセージ通知。営業時間内に対応 |
| 情報 | 注目すべき異常 | ダッシュボードに記録し、週次で確認 |
原則は一つです。即座の対応が必要なものだけが人を起こしてよい。それ以外は朝まで待ちます。何度も鳴るのに一度も対応が必要にならないアラートがあれば、閾値を直すか、そのアラートを削除してください。
バックアップ — 最も重要な項目
実務上の基準は、データの写しを3つ、2種類の媒体に置き、うち1つを別の物理的な場所に保管することです。
ただしバックアップの設定より重要なのは、復元を定期的に試すことです。一度も復元したことのないバックアップは、バックアップではなく思い込みです。多くの企業が、バックアップが壊れていたことを、必要になった日に知ります。
最低限の頻度は、四半期に一度、隔離した環境への全体復元テストを行い、実際にかかった復元時間を記録することです。その数字が、最悪の場合に事業が止まる時間です。
運用手順書
よくある障害の種類ごとに、短い1ページを用意します。どう見分けるか、何をすぐ確認するか、どの手順を踏むか、いつ上位者に引き継ぐか。
良い手順書の基準はこうです。システムを作っていない人が、深夜3時に読んで、障害を解消できる。書いた本人にしか辿れないなら、その手順書は役割を果たしていません。
進め方
- バックアップと復元テスト。 議論の余地なく最初です。最悪の事態から救えるのはこれだけです。
- 外部からの死活監視。 安価で、すぐ導入でき、即座に価値が出ます。
- 資源監視と基本のアラート。 ディスク、メモリ、接続数。
- ログの集約。 障害のたびに各サーバーへログインしなくて済むようにします。
- 業務指標とダッシュボード。 エンジニアだけでなく事業部門も見られる形で。
- 運用手順書。 実際の障害が起きるたびに書き足していきます。
ご用意いただきたいもの
- 監視対象システムの一覧と、売上への影響度による順位づけ
- 御社の基準 — 何分止まったら「重大」とみなすか
- 営業時間外のアラート受信者と、応答がない場合の引き継ぎ順序
- 過去の障害記録があれば、その一覧
インフラ構築とソフトウェア開発の実務経験に基づいて執筆しています。スポンサーや製品の宣伝は含みません。