AWSで始めるサイト信頼性エンジニアリング（SRE）実装ガイド

SRE の基本概念と AWS で活用すべき 4 要素

AWS は SRE を「ソフトウェアツールでインフラタスクを自動化し、信頼性を維持する手法」として公式ドキュメントで紹介しています（AWS SRE の概要 – AWS Japan）。本節では、AWS 環境で特に重要になる SLI／SLO・エラーバジェット・インシデント対応・自動化 の 4 要素を実装観点から整理します。

SLI／SLO とエラーバジェットの設定方法

SLI（Service Level Indicator）と SLO（Service Level Objective）は、信頼性を数値で測定・管理する土台です。AWS では CloudWatch カスタムメトリクスとアラーム機能だけで一連のフローを自動化できます。

• メトリクス設計
• アプリケーション側で PutMetricData を呼び出し、成功率や P95 レイテンシなどを CustomNamespace/SuccessRate の形で送信。

• メトリクスは 1 分粒度で取得できるため、短時間の変動も即座に捕捉可能です。

• SLO 定義例
  yaml
# CloudFormation で SLO をパラメータ化する例
Parameters:
DesiredSuccessRate:
Type: Number
Default: 99.9 # 月間目標成功率（％）

• エラーバジェット計算

• エラーバジェット = 1 − SLO（例：99.9 % の SLO ⇒ 0.1 % = 約43 分/30 日）。

• CloudWatch アラームで「残量 < 20 %」を検知し、SNS → Lambda に通知させると自動的に対策が走ります。

• 可視化

• ダッシュボードに SuccessRate と ErrorBudgetRemaining をウィジェットとして配置し、日次・週次でトレンドを確認できるようにします。

ポイント：CloudWatch のカスタムメトリクスとアラームだけで SLI／SLO・エラーバジェットのループが完結するため、外部ツールへの依存を最小化できます。

インシデント対応プロセスの設計

インシデントは「検知 → 通知 → 自動 Runbook 実行 → 復旧」というシンプルなフローに落とし込むことで、MTTR（Mean Time To Recovery）を大幅に短縮できます。

• 自動検知
• CloudWatch アラームが閾値超過時に SNS トピックへ通知。
• Runbook の自動起動
• SNS → Systems Manager Automation が事前定義した Runbook（例：EC2 再起動、Auto Scaling グループの容量調整）を実行。
• 担当者への即時連携
• AWS Chatbot と PagerDuty の統合により、Slack にインシデント概要が自動投稿され、PagerDuty 上でインシデントが生成されます。

ポイント：Runbook の自動化がインシデントフローの中心になることで、人為的ミスと復旧遅延を同時に削減できます。

自動化による信頼性向上のポイント

IaC（Infrastructure as Code）と CI/CD を組み合わせて「設定 → デプロイ → 監視」までをコードで管理すると、変更ミスや構成ドリフトが根本的に防げます。

• IaC の選択肢
• CloudFormation（ネイティブ）または Terraform（マルチクラウド対応）。

• テンプレート内で AWS::CloudWatch::Alarm と AWS::SSM::AutomationDocument を組み込み、リソースと自動化手順を一体管理。

• CI/CD パイプライン

• CodePipeline のステージ構成例：Source → Build → Canary Deploy → Monitoring (エラーバジェット) → Approve/Reject → Prod Deploy。

• カナリアリリース中に CloudWatch アラームがエラーバジェットを消費し始めたら自動的にデプロイを停止します。

• テスト自動化

• cfn‑nag や taskcat によるテンプレート検証、aws-sam-cli のローカル統合テストでリリース前に品質保証。

ポイント：自動化は信頼性向上だけでなく、運用コスト削減とデプロイ速度の高速化を同時に実現します。

AWS Well‑Architected Framework の Reliability Pillar と実装チェックリスト

AWS Well‑Architected Framework – Reliability Pillar は、システムが障害から回復しつつ SLA を維持できるかを評価する指標です。本節では、Reliability Pillar の主要項目と、AWS ネイティブで実装可能なチェックリストを提示します。

Reliability Pillar の主要項目

ポイント：上記チェックリストをプロジェクトごとに実施し、未達項目は優先的に改善することで、Reliability Pillar に準拠した堅牢な基盤が構築できます。

可観測性の構築：CloudWatch と X‑Ray／OpenTelemetry

可観測性は 「何が起きているかを正確に把握できる」 ことが前提です。AWS のサービスだけで完結させる場合でも、メトリクス・ログ・トレースの３層を揃える必要があります。

CloudWatch での SLI 計測とダッシュボード作成手順

まずは CloudWatch にカスタムメトリクスとして SLI を送信し、可視化まで自動化する流れを示します。

1. メトリクス定義
2. アプリ側で PutMetricData を呼び出し、SuccessRate（成功率）や LatencyP95（95 パーセンタイル遅延）を送信。
3. アラーム設定
4. 「エラー率 > 0.5 %」または「P95 遅延 > 300 ms」の閾値で CloudWatch アラームを作成し、SNS トピックへ通知。
5. ダッシュボード構築
6. AWS::CloudWatch::Dashboard リソースで以下のウィジェットを定義（例は JSON 形式）。
   json
{
"widgets": [
{"type":"metric","x":0,"y":0,"width":12,"height":6,
"properties":{"metrics":[["CustomNamespace","SuccessRate"]],"period":60,"stat":"Average"}},
{"type":"metric","x":0,"y":7,"width":12,"height":6,
"properties":{"metrics":[["CustomNamespace","LatencyP95"]],"period":60,"stat":"p95"}}
]
}
7. 自動デプロイ
8. 上記 JSON を CloudFormation テンプレートに埋め込み、スタック更新時にダッシュボードが自動的に再構成されます。

ポイント：メトリクス収集から可視化・アラートまでをコードで管理すると、人為的設定ミスが排除され、一貫した SLI 監視基盤が実現します。

分散トレーシングに X‑Ray と OpenTelemetry を組み合わせる

マイクロサービス間の遅延やエラーはトレースでしか把握できません。AWS X‑Ray はサーバーレス・EC2 どちらでも利用可能です。一方、OpenTelemetry はベンダーに依存しない標準仕様として広く採用されています。

• 導入フロー
• 各サービスに OpenTelemetry SDK（Java, Python, Node.js 等）を組み込み、OTEL_EXPORTER_OTLP_ENDPOINT=aws-xray:2000 を環境変数で設定。
• ADOT Collector（AWS Distro for OpenTelemetry）を ECS/Fargate タスクとしてデプロイし、受信したトレースを X‑Ray にエクスポート。

• X‑Ray コンソールのサービスマップで全ノードの呼び出し関係とレイテンシ分布を確認。

• ベストプラクティス

• サンプリング率は「デフォルト 5 %」から始め、負荷が許す範囲で 10〜20 % に段階的に引き上げる。
• トレース ID をリクエストヘッダー（X-Amzn-Trace-Id）で伝搬させ、障害時の因果関係解析を容易にする。

ポイント：OpenTelemetry と X‑Ray のハイブリッド構成は、ベンダーロックインを回避しつつ AWS の可視化機能を最大限活用できる最適解です。

インフラ自動化とフェイルオーバー設計（IaC・Auto Scaling・Route 53・ELB）

信頼性の根幹は、インフラ構成そのものがコードで管理され、障害時に自律的に切り替えられることです。本節では CloudFormation で実装できる主要パターンを具体例とともに示します。

CloudFormation で可観測性・リライアビリティ設定をコード化

以下は SRE に必要なダッシュボード、Auto Scaling、Route 53 ヘルスチェックを一括でデプロイする最小構成です。

ポイント：このテンプレートは「監視」「自動復旧」「ヘルスチェック」の３要素をコードで一元管理でき、スタックの再デプロイだけで全環境に適用可能です。

Auto Scaling と ELB によるスケールアウト／フェイルオーバー構成

実運用で必要になる設定項目とベストプラクティスを整理します。

この構成を採用すれば、単一 AZ の障害だけでなくリージョンレベルの障害にも自動的に切り替えられ、サービス継続性が大幅に向上します。

インシデント対応とリリース制御：Systems Manager・Chatbot／PagerDuty・カナリアデプロイ

信頼性を保つためには インシデントの迅速な復旧 と リスクの高い変更を抑止する仕組み が不可欠です。以下では、AWS のマネージドサービスだけで実装できるフローを紹介します。

Runbook の作成と Automation の活用

Runbook は「手順書」をコード化したものです。Systems Manager Automation で管理すれば、担当者は UI 上の 「実行」 ボタン一つで復旧処理が走ります。

• 作成手順
• Systems Manager コンソール → Automation → Create document を選択し、YAML/JSON 形式で aws:restartEc2Instance や aws:ssm:sendCommand などのアクションを記述。
• 作成したドキュメントにバージョンタグ（例：v1.0）と説明コメントを必ず付与し、Git リポジトリで管理。

• 自動トリガー
• CloudWatch アラーム → SNS → Systems Manager Automation（上記 Runbook）を紐付け、障害検知と同時に復旧作業が開始されるように設定。

ポイント：Runbook のコード化により手順の標準化・履歴管理が可能となり、ヒューマンエラーが大幅に減少します。

Chatbot と PagerDuty による自動通知フロー

インシデント情報をリアルタイムで開発チームへ共有し、同時に外部のインシデント管理ツール（PagerDuty）にも連携させます。

1. Chatbot 設定
2. AWS Chatbot コンソールで Slack ワークスペースと接続し、SNS トピックを購読。通知は「プレフィックス付きメッセージ」で重要度を示す。
3. PagerDuty 連携
4. SNS → Lambda 関数（Python）で PagerDuty Events API に POST。イベントの routing_key はシークレットマネージャーから取得し、認証情報をコードに埋め込まない。

1. フロー全体図
2. CloudWatch アラーム → SNS → (① Slack via Chatbot、② PagerDuty インシデント生成) → 担当者が対応 → 完了後に SNS で 復旧通知 を送る。

ポイント：同時多方面への自動通知は情報の抜け漏れを防ぎ、インシデント解決までの時間短縮につながります。

エラーバジェット連携によるリリース制御とカナリアデプロイ

エラーバジェットが一定以下になると、新規リリースを自動的に保留し、安全性を確保します。

• トリガー設定

• CloudWatch アラームで「エラーバジェット残量 < 20 %」を検知したら SNS → Lambda が StopExecution API を呼び出す。

• カナリアデプロイの実装

• CodeDeploy の Blue/Green または Canary デプロイタイプで、トラフィック比率を 5 %→25 %→100 % と段階的に拡大。各ステップでヘルスチェックとエラーバジェットの再評価を実施。

• 自動復旧

• カナリアテスト中に SLO が破られた場合は Lambda がデプロイをロールバックし、同時に SNS で関係者へ警告を送信。

ポイント：エラーバジェットと CI/CD の連携により、品質が確保されていないコードの本番投入を防ぎ、サービス全体の安定性を守ります。

次のステップ

以下のアクションを順次実行すれば、AWS ネイティブだけで完結する SRE 基盤 が構築できます。

1. 4 要素のベースライン策定
2. SLI／SLO・エラーバジェットを CloudWatch カスタムメトリクスで測定し、ダッシュボード化。
3. Reliability Pillar のギャップチェック
4. 前述のチェックリストを使用して未実装項目を洗い出し、優先度別にタスク化。
5. IaC と CI/CD パイプラインの整備
6. CloudFormation（または Terraform）でインフラ全体をコード化し、CodePipeline に Canary デプロイとエラーバジェット評価ステップを追加。
7. 自動化 Runbook の作成
8. 主要インシデント（EC2 障害、RDS ストレージ不足等）ごとに Automation Document を用意し、SNS → Automation の自動フローを構築。
9. 可観測性の拡張
10. OpenTelemetry Collector と X‑Ray の統合で分散トレーシングを有効化し、ログ・メトリクスと一元的に可視化。

最終目標：これらの実装が完了すれば、障害時の復旧時間（MTTR）短縮、変更リスク低減、運用コスト削減という SRE の三大効果を同時に享受できるはずです。

参考リンク

これらを参照しながら、組織の要件に合わせて段階的に導入していくことを推奨します。