Contents
SREの基本原則
SRE（サイトリライアビリティエンジニアリング）は、ITシステムの信頼性と可用性を確保するための実践的なフレームワークです。特にサービスレベル契約（SLA）や障害復旧時間（MTTR）などの数値目標を明確に設定し、運用品質を定量化することがポイントです。
信頼性とSLAの基礎知識
SREではシステムの「信頼性」や「SLA」といった専門用語がよく使われます。以下に簡単な定義を説明します：
- 信頼性：システムが設計通りに動作する確率のこと。例えば99.95%の可用性は、1年間に4.38時間のダウンタイムを許容することを意味します。
- SLA（Service Level Agreement）：顧客との契約として、サービスの性能や利用可能な時間を数値化した保証です。
信頼性の基準例
| 項目 | 値 | 補足 |
|---|---|---|
| 可用性 | 99.95%（※1） | 年間4.38時間のダウンタイム許容 |
| MTTR | 10分以内 | 障害発生から復旧までの目標時間 |
| SLA違反時 | ペナルティ付き | 設定により異なります |
重要ポイント： SLAは単なる数値ではなく、顧客との信頼関係を構築するための契約です。過度な目標設定は運用負担に繋がります。※1: 具体的な数値は社内データに基づく例です。
カオスエンジニアリングとは
カオスエンジニアリングは、本番環境で意図的に障害を注入し、システムの耐障害性を検証する手法です。近年ではAWS FIS（Fault Injection Simulator）やGoogle Cloudのツールなど、実践が容易な自動化ツールが登場しています。
主な手法と適用範囲
カオスエンジニアリングは以下の4つのステップで構成されます：
- 仮説の設定（例: 「ネットワーク遅延を5秒注入した場合、サービスが正常に復旧するか」）
- シナリオ設計（注入する障害の種類・タイミングを定義）
- 実行と観測（メトリクスやログをリアルタイムで監視）
-
分析と改善（異常発生時のレスポンスプロトコルを見直す）
-
適用範囲の例
- ネットワーク障害（DNS破壊、帯域制限）
- サービス停止（APIエンドポイントのシャットダウン）
- 資源枯渇（CPU使用率100%への注入）
実務例： AWS FISを使い、Lambda関数に「リクエスト遅延」を5分間注入し、サービスの再起動処理が適切に行われているかを検証します。この際、リアルタイム監視ツール（例: Grafana）で状況を確認しながら、異常発生時の対応プロトコルを検証します。
シナリオ設計と実践課題
本日の実践課題として、「ネットワーク遅延を注入した場合の復旧プロセス」を設計しましょう。カオスエンジニアリングでは、想定外の障害に備えるためのシナリオ設計が不可欠です。
仮想環境でのシナリオ構築手順
- 障害タイプ選定（例: ネットワーク遅延、サービス停止）
- 注入条件設定（どのコンポーネントに、いつ、どれだけの影響を加えるか）
-
ツール選定（AWS FISやChaos Monkeyなど、自社開発ツールも利用可能）
-
具体的な設計例
| 障害タイプ | 注入対象 | 時間設定 | 目的 |
|----------------|----------------|------------------|--------------------------|
| ネットワーク遅延 | APIゲートウェイ | 10分間 | リトライロジックの検証 |
| サービス停止 | DBサーバー | 5分後 | フェイルオーバー処理確認 |
注意事項： 実行前は必ず本番環境と区別した仮想環境でテストを行い、影響範囲を限定することが重要です。
Automated Testing手法
カオスエンジニアリングの自動化は、CI/CDフローに統合することで効率化が可能です。スクリプトによる検証は、リリース前段階での品質確保に直結します。
CI/CD連携のベストプラクティス
- テストケースをバージョン管理（Gitリポジトリ内にシナリオ定義ファイルを保存）
- 失敗時のフィードバックループ構築（異常検出時にJiraなどに自動通知）
-
パラメータの動的調整（注入強度を環境ごとに変更可能）
-
スクリプト自動実行の工夫例
- パイプライン内でのテスト実行（GitHub ActionsやGitLab CIで構成）
- 自動リセット機能（異常発生時にもシステムは元に戻るよう設計）
- ログの即時収集（CloudWatch LogsやPrometheusなどと連携）
インシデントレスポンスフロー
カオスエンジニアリングで発生した障害への対応プロトコルは、実際のインシデントと同様の手順を想定する必要があります。チーム間の連携テンプレートを持つことで、迅速な復旧が可能になります。
シナリオ実行時の対応プロトコル
- 緊急時連絡網（Slack/Teamsで即時通知）
- 影響範囲の特定（メトリクスダッシュボードで確認）
-
復旧手順の実行（既定のPlaybookに従う）
-
チーム連携テンプレート例
- 指揮体制：リードエンジニアが責任を持つ
- ロール分担：監視チーム→復旧チーム→分析チーム
- 事後分析：根本原因を特定し、対応策を文書化
メトリクスモニタリング戦略
カオスエンジニアリングの効果を測定するには、リアルタイムでKPIを可視化することが不可欠です。警報閾値の設計や異常検知基準が重要になります。
異常検知基準の設定
-
代表的なメトリクス例
| メトリクス | 正常範囲 | 警告条件 |
|------------------------|------------------|--------------------|
| HTTP 5xxエラー率 | ≤0.1% | ≥0.5%でアラーム |
| リクエスト遅延（p99） | ≤200ms | ≥500msで警告 |
| CPU使用率（平均） | ≤70% | ≥90%で緊急アラーム | -
ダッシュボード活用法
- GrafanaやDatadogでリアルタイムグラフを表示
- カオステストの結果を過去データと比較して分析
実践アドバイス： メトリクスの「基準値」は、過去の運用データから統計的に算出するのがベストです。一時的な異常を見逃さないよう、動的閾値設定も検討しましょう。
まとめ
- SREでは、信頼性と可用性の定量化（SLA/MTTR）が基本原則
- カオスエンジニアリングは、仮想環境での障害注入テストで耐障害性を検証する手法
- 実践には、シナリオ設計×自動化ツール（例: AWS FIS、自社製品）の活用が不可欠
- メトリクス監視は、KPIの可視化と異常検知基準の明確化を軸に実施
- 個人・チームレベルでのインシデントレスポンスプロトコルの整備が必要