アラート設計
障害対応は「気づく」ところから始まります。ユーザーから「ログインできない」と連絡が来てから動くのでは遅い。ユーザーより先に気づく仕組みがアラート設計です。
アラートの3層構造
全てをアラートにすると通知疲れで無視されます。重要度に応じて3層に分けます。
「 ページング」とは、PagerDuty 等のツールを通じて 電話・SMS・アプリ通知で担当者を即座に呼び出す ことです。語源は pager（ポケットベル。病院で医師を緊急呼び出しするための小型無線端末）から来ています。現在はスマートフォンへの電話・SMS・プッシュ通知に置き換わっていますが、「page する」「ページングする」という用語はそのまま使われています。
┌─ ページング（即時対応が必要）──────────────────────────────┐
│ │
│ PagerDuty / Opsgenie → 電話 / SMS / アプリ通知 │
│ → 深夜でも担当者を呼び出す │
│ → 対応しないとユーザー影響が拡大する │
│ → 応答がなければ次の担当者に自動エスカレーション │
│ │
│ 例: 5xx エラー率 > 5% │
│ 全インスタンス Unhealthy │
│ DB 接続不能 │
│ │
├─ アラート（勤務時間中に対応）───────────────────────────────┤
│ │
│ Slack / メール │
│ → 勤務時間中に確認して対応 │
│ → 放置すると障害に発展する可能性 │
│ │
│ 例: 5xx エラー率 > 1%（5分間） │
│ p95 レイテンシ > 通常の3倍 │
│ DB コネクションプール使用率 > 80% │
│ │
├─ 情報（ダッシュボードで確認）──────────────────────────────┤
│ │
│ CloudWatch Dashboard / Grafana │
│ → 通知しない、ダッシュボードで定期確認 │
│ → トレンドの把握、キャパシティプランニング │
│ │
│ 例: リクエスト数の推移 │
│ DB ストレージ使用量 │
│ テナント別のアクティブユーザー数 │
│ │
└─────────────────────────────────────────────────────────────┘
監視すべきメトリクス
以下は Web サービス（特に認証サービス等の基盤サービス）での例です。サービスの特性に応じてカスタマイズしてください。
ページング（即時対応）
| メトリクス | 閾値 | 期間 | 理由 |
|---|---|---|---|
| 5xx エラー率 | > 5% | 3分 | 多くのユーザーがエラーを受けている |
| Running インスタンス数 | = 0 | 1分 | サービス完全停止 |
| DB Writer 接続不能 | > 0 | 1分 | DB に書き込めない |
| ヘルスチェック全失敗 | 全ターゲット Unhealthy | 1分 | LB がリクエストを転送できない |
アラート（勤務時間中に対応）
| メトリクス | 閾値 | 期間 | 理由 |
|---|---|---|---|
| 5xx エラー率 | > 1% | 5分 | エラーが増加傾向 |
| p95 レイテンシ | > 1秒 | 5分 | ユーザー体感に影響 |
| DB コネクションプール使用率 | > 80% | 5分 | 枯渇の予兆 |
| キャッ シュ メモリ使用率 | > 80% | 10分 | セッション保存に影響 |
| アプリ再起動回数 | > 2回 | 10分 | アプリがクラッシュしている |
| DB レプリカラグ | > 10秒 | 5分 | Reader の遅延 |
| Certificate 有効期限 | < 14日 | 1日1回 | 証明書切れでサービス停止 |
情報（ダッシュボードのみ）
| メトリクス | 確認頻度 | 用途 |
|---|---|---|
| リクエスト数（RPS） | 日次 | トラフィックの傾向 |
| テナント別 RPS | 週次 | 特定テナントの急増検知 |
| DB ストレージ使用量 | 週次 | キャパシティプランニング |
| パーティションサイズ | 週次 | アーカイブの必要性判断 |
アラート設計のアンチパターン
❌ 全部ページングにする
結果: 毎晩3回起こされる → 通知疲れ → 本当の障害を見逃す
対策: ページングは「ユーザー影響が確実にある」ものだけ
他はアラート（Slack通知）で十分
❌ 閾値が厳しすぎる
結果: 正常なスパイクでもアラートが鳴る → オオカミ少年
対策: 過去のデータから正常範囲を把握してから閾値を設定
最初は緩めに設定して、徐々に調整
❌ 原因ではなく症状だけを監視
❌ 「CPU 使用率 > 80%」だけ監視
→ CPU が高い原因は？ 正常な負荷増？ バグ？ 攻撃？
✅ 「CPU > 80%」+「5xx 増加」+「レイテンシ悪化」をセットで
→ 複数メトリクスの相関で判断
❌ アクションがないアラート
❌ アラートが鳴った → で、何をすればいいの？
✅ アラートにランブックのリンクを含める
→ 「このアラートが鳴ったら → {ランブック URL} の手順に従う」
監視ツールの選択肢
ここまでの設計方針は、どの監視ツールでも同じ考え方で実装できます。
主要な監視ツール
| ツール | 特徴 | アラート通知先 | 向いているケース |
|---|---|---|---|
| CloudWatch | AWS ネイティブ。追加導入不要 | SNS → Slack / Email / Lambda | AWS 中心の環境 |
| Datadog | 統合監視。APM / ログ / メトリクスが1画面 | PagerDuty / Slack / Email / Webhook | マルチクラウド、詳細な分析 |
| Grafana + Prometheus | OSS。カスタマイズ性が高い | AlertManager → Slack / PagerDuty | コスト重視、Kubernetes 環境 |
| New Relic | APM に強い。トレーシング | PagerDuty / Slack / Email | アプリケーション性能の可視化 |
ページングツール
| ツール | 特徴 |
|---|---|
| PagerDuty | 業界標準。オンコールローテーション、エスカレーションポリシー |
| Opsgenie | Atlassian 製。Jira / Confluence と統合 |
| VictorOps (Splunk On-Call) | チャット統合、タイムライン機能 |
3層と監視ツールの対応
ページング: 監視ツール → PagerDuty → 電話 / SMS
アラート: 監視ツール → Slack / Teams / メール
情報: 監視ツール → ダッシュボード（通知なし）
どのツールを使っても、3層に分ける設計方針は変わりません。ツール固有の設定方法は各ツールのドキュメントを参照してください。
まとめ
アラート設計の原則:
1. 3層に分ける（ページング / アラート / 情報）
2. ページングは「ユーザー影響が確実」なものだけ
3. 閾値は過去データに基づいて設定
4. アラートにはアクション（ランブック ）を紐づける
5. 定期的に閾値を見直す（通知疲れ or 見逃しがないか）
次のステップ
- 初動対応: アラートが鳴った後の最初の5分