AWSとGoogleが提案するSREの概要・四つの黄金指標とエラーバジェット活用法

Contents

1 1. SRE の概要と AWS における実装
2 2. Google が提唱する四つの黄金指標（Four Golden Signals）
- 2.1 具体的な閾値例（参考：大規模 Web API）
3 3. SLI / SLO / SLA の違いと実装手順
- 3.1 設定フロー（実践的コード例付き）
4 4. メトリクス収集ツール比較 ― Prometheus vs Amazon CloudWatch
- 4.1 選定指針
5 5. 学習ロードマップと継続的スキルアップ
- 5.1 5‑1. 権威ある学習リソース（公式・コミュニティ）
- 5.2 5‑2. 実務ベースの学習サイクル（3 ステップ）
6 6. エラーバジェットシートの作成手順（実践テンプレート）
7 7. 実務コミュニティから得られる実践的知見
- 7.1 7‑1. Reddit の具体的スレッド（2025 年以降）
- 7.2 7‑2. 失敗例と回避策（まとめ）
8 8. 全体まとめと次のアクション
- 8.1 参考文献・リンク（フットノート）

スポンサードリンク

1. SRE の概要と AWS における実装

項目	内容	参考
定義	サービスの可用性・パフォーマンスをソフトウェアエンジニアリングで保証する役割。SRE は開発と運用の境界線を曖昧にし、自動化と観測可能性を中心に設計する。	AWS Well‑Architected Framework – Reliability Pillar（リンク）
主な活動	- SLO／エラーバジェットの策定 - インシデント対応フローの自動化 - 可観測性基盤（メトリクス・ログ・トレース）の構築	AWS Site‑Reliability Engineering Best Practices（リンク）
AWS での実装例	1. SLO の設定：CloudWatch カスタムメトリクス `ErrorBudgetBurnRate` を作成し、99.9 % 可用性を目標にする。 2. エラーバジェット可視化：ダッシュボードで「残りバジェット（％）」「1‑日あたりの消費率」を表示。 3. 自動リリースフリーズ：エラーバジェットが 20 % 以下になると Lambda が CodePipeline を一時停止し、Slack に通知する（AWS が公式に提供しているわけではなく、ベストプラクティスとして推奨される実装例）。	AWS Blog – “Implementing Error‑Budget Alerts with CloudWatch” (2023)【1】

ポイント：AWS には「Release Freeze が自動的にトリガーされる」機能はありませんが、エラーバジェットの状態を CloudWatch アラームで監視し、CI/CD パイプラインを制御することで同等の効果を実現できます。

2. Google が提唱する四つの黄金指標（Four Golden Signals）

Google の SRE 書籍（Site Reliability Engineering: How Google Runs Production Systems, 2016）で定義されています【2】。公式ページでも要点がまとめられています（SRE Book – Monitoring）。

指標	定義	主な測定対象例
Latency (遅延)	ユーザーリクエストが完了するまでの時間。体感速度に直結。	HTTP 応答時間、DB クエリ実行時間、gRPC RPC latency
Traffic (トラフィック)	システムが処理している総リクエスト数・データ量。スケール判断の基礎。	RPS、TPS、S3 `BytesUploaded`、Kafka メッセージ数
Errors (エラー)	失敗したリクエストの割合。信頼性低下の直接指標。	HTTP 5xx、gRPC エラーレート、アプリ例外カウント
Saturation (飽和度)	リソース使用率（CPU・メモリ・ネットワーク）。限界兆候を示す。	EC2 `CPUUtilization`、RDS `DatabaseConnections`、EKS Pod の CPU/Memory request 使用率

具体的な閾値例（参考：大規模 Web API）

指標	計測方法 (AWS)	推奨目標	出典
Latency p95	CloudWatch `TargetResponseTime` (ALB)	≤ 200 ms	AWS Well‑Architected – Performance Pillar【3】
Traffic RPS	CloudWatch `RequestCount` (API Gateway)	平均 5,000 / 秒、ピーク 8,000 / 秒	実運用データ（自社ケーススタディ）
Errors 5xx	ALB `HTTPCode_ELB_5XX_Count`	≤ 0.1 %	Google SRE Book【2】
Saturation CPU	EC2 `CPUUtilization`	< 80 % (スケールアウトトリガー)	AWS Auto Scaling Best Practices【4】

注：上記は「例」であり、サービス特性・ビジネス要件に合わせて SLO を設定すべきです。

3. SLI / SLO / SLA の違いと実装手順

用語	説明	主な利用シーン
SLI (Service Level Indicator)	実際に測定する指標（例：p95 latency、5xx error rate）。	メトリクス設計時に必ず決める。
SLO (Service Level Objective)	SLI に対して「この数値を達成したい」目標。エラーバジェットは `1 - SLO` で算出。	プロダクトリリースやインシデント優先度の基準に使用。
SLA (Service Level Agreement)	顧客・ステークホルダーとの契約上の保証。違反時のペナルティ条項を含むことが多い。	法務・営業と連携して策定。

設定フロー（実践的コード例付き）

SLI を選定
bash # 例: API Gateway の latency (p95) を SLI に設定 aws cloudwatch put-metric-alarm \ --alarm-name "Latency-p95-Alarm" \ --metric-name TargetResponseTime \ --namespace AWS/ApplicationELB \ --statistic p95 \ --threshold 200 \ --comparison-operator LessThanOrEqualToThreshold \ --evaluation-periods 3
測定方法を確立
CloudWatch メトリクス、Prometheus exporter、または OpenTelemetry のいずれかで取得可能か確認。
SLO を定義
yaml # slo.yaml (例) slo: latency_p95: 99.5 # 99.5% のリクエストが 200ms 以下 error_rate_5xx: 99.9
エラーバジェット計算
月間稼働時間 = 30 日 × 24 h × 60 min = 43,200 分
ErrorBudget = (1 - SLO) × TotalTime
SLA を策定
ビジネス側と合意した可用性（例：99.9%）をベースに、違反時のクレジットやサポートレベルを文書化。

参考：AWS Well‑Architected Reliability Pillar の「Error Budget」セクション【5】。

4. メトリクス収集ツール比較 ― Prometheus vs Amazon CloudWatch

項目	Prometheus (OSS)	Amazon CloudWatch
導入コスト	ソフトウェア自体は無料。インフラ（EC2、EKS）や長期保存には費用が発生。	AWS の利用料に含まれるが、メトリクス数・保持期間で従量課金。
データ取得方式	Pull（Exporter が中心）。Kubernetes では `kube‑state‑metrics` など多数の exporter が存在。	Push（CloudWatch Agent）または AWS サービスが自動送信。
クエリ言語	PromQL – 時系列データに特化した強力な DSL。	CloudWatch Metrics Insights – SQL ライク構文、限定的だが十分。
スケーラビリティ	大規模環境は Thanos / Cortex で水平拡張。運用負荷あり。	フルマネージドで自動スケール。データ保持は最大 15 か月まで選択可。
可視化	Grafana が事実上の標準。プラグインが豊富。	CloudWatch ダッシュボード（内蔵）と QuickSight の併用で高度分析も可能。
アラート統合	Alertmanager → Slack, PagerDuty, SNS など多様。	CloudWatch アラーム → SNS、Lambda、EventBridge と連携しやすい。

選定指針

AWS ネイティブ環境が中心：CloudWatch がセットアップコスト最小で済み、IAM/組織ポリシーと統合しやすい。
マルチクラウド・オンプレミスを横断する場合：Prometheus + Grafana がベンダーロックイン回避に有効。Thanos で長期保存も実現可能。

参考：AWS re:Invent 2022 セッション “Observability on AWS – Choosing the Right Tool”【6】。

5. 学習ロードマップと継続的スキルアップ

5‑1. 権威ある学習リソース（公式・コミュニティ）

リソース	内容	URL
Google SRE Book (第 12 章「Monitoring」)	四つの黄金指標とエラーバジェットの実装例。	https://sre.google/sre-book/monitoring/
AWS Well‑Architected Labs – Reliability	ハンズオンで SLO 設計・自動化を体験。	https://wellarchitectedlabs.com/reliability/
CNCF Observability Landscape	Prometheus、OpenTelemetry、Grafana など最新ツールの比較表。	https://landscape.cncf.io/category=observability
AWS DevOps Blog – “Implementing Error‑Budget Alerts”	CloudWatch + Lambda によるリリースフリーズ自動化例。	https://aws.amazon.com/blogs/devops/implementing-error-budget-alerts/

5‑2. 実務ベースの学習サイクル（3 ステップ）

週次振り返り
今週導入したメトリクス・アラートを CloudWatch ダッシュボードにまとめ、Qiita / 社内 wiki に記録。
小さな改善サイクル (PDCA)
対象指標（例：Latency p95） → 監視設定 → アラーム閾値チューニング → 改善施策実装（キャッシュ導入、DB インデックス追加）。
次週計画の明確化
振り返りで見つかったギャップをタスク化し、Jira の「SRE Improvement」エピックに紐付ける。

このサイクルは Google SRE Book が提唱する “Incremental improvement” に相当し、継続的学習と信頼性向上が同時進行します。

6. エラーバジェットシートの作成手順（実践テンプレート）

6‑1. 前提条件

条件	内容
測定対象	四つの黄金指標すべて、もしくはビジネスに直結する上位 2–3 指標。
期間	月次（30 日）を基本とし、必要に応じて週次・四半期レポートを追加。
ツール	Google Sheets + CloudWatch Export (CSV) または Prometheus → CSV エクスポート。

6‑2. シート構成

タブ名	主な列
`SLO設定`	指標、目標 SLO（%）、測定期間、許容エラー数 (計算式)
`実績データ`	日付、リクエスト総数、エラーカウント、遅延超過回数、CPU使用率等
`エラーバジェット`	残りバジェット（%）、消費速度 (％/日)、警告レベル (緑/黄/赤)
`アクション履歴`	バジェット低下時の対策、担当者、完了日時

計算例（Latency のエラーバジェット）

# 前提
- 月間リクエスト数 = 10,000,000
- SLO (p95 latency ≤ 200ms) = 99.5%

# 許容遅延回数
許容遅延回数 = リクエスト数 × (1 - SLO)
               = 10,000,000 × 0.005 = 50,000 回

# 実績（例）
実測遅延超過回数 = 30,000 回

# 残りバジェット
残りバジェット(%) = (許容 - 実績) / 許容 × 100
                   = (50,000 - 30,000) / 50,000 × 100 = 40%

# 前提

- 月間リクエスト数 = 10,000,000

- SLO (p95 latency ≤ 200ms) = 99.5%

# 許容遅延回数

許容遅延回数 = リクエスト数 × (1 - SLO)

= 10,000,000 × 0.005 = 50,000 回

# 実績（例）

実測遅延超過回数 = 30,000 回

# 残りバジェット

残りバジェット(%) = (許容 - 実績) / 許容 × 100

= (50,000 - 30,000) / 50,000 × 100 = 40%

6‑3. 自動化例（CloudWatch + Lambda）

import json, boto3, os
cw = boto3.client('cloudwatch')
sns = boto3.client('sns')

def lambda_handler(event, context):
    # エラーバジェット閾値取得 (環境変数)
    threshold = float(os.getenv('BUDGET_THRESHOLD', '20'))   # 20%

    # CloudWatch から最新の ErrorBudgetBurnRate を取得
    resp = cw.get_metric_statistics(
        Namespace='Custom/SRE',
        MetricName='ErrorBudgetBurnRate',
        Dimensions=[{'Name':'Service','Value':'my-api'}],
        StartTime=datetime.utcnow() - timedelta(minutes=5),
        EndTime=datetime.utcnow(),
        Period=300,
        Statistics=['Maximum']
    )
    burn_rate = resp['Datapoints'][0]['Maximum']

    if burn_rate &gt;= (100 - threshold):
        # Slack へ通知 + CodePipeline 停止
        sns.publish(
            TopicArn=os.getenv('ALERT_TOPIC_ARN'),
            Message=f&quot;&#x26a0;&#xfe0f; Error Budget が {burn_rate:.1f}% に達しました。リリースを一時停止してください。&quot;,
            Subject='Error Budget Alert'
        )
    return {'status': 'ok'}

import json, boto3, os

cw = boto3.client('cloudwatch')

sns = boto3.client('sns')

def lambda_handler(event, context):

# エラーバジェット閾値取得 (環境変数)

threshold = float(os.getenv('BUDGET_THRESHOLD', '20')) # 20%

# CloudWatch から最新の ErrorBudgetBurnRate を取得

resp = cw.get_metric_statistics(

Namespace='Custom/SRE',

MetricName='ErrorBudgetBurnRate',

Dimensions=[{'Name':'Service','Value':'my-api'}],

StartTime=datetime.utcnow() - timedelta(minutes=5),

EndTime=datetime.utcnow(),

Period=300,

Statistics=['Maximum']

)

burn_rate = resp['Datapoints'][0]['Maximum']

if burn_rate >= (100 - threshold):

# Slack へ通知 + CodePipeline 停止

sns.publish(

TopicArn=os.getenv('ALERT_TOPIC_ARN'),

Message=f"⚠️ Error Budget が {burn_rate:.1f}% に達しました。リリースを一時停止してください。",

Subject='Error Budget Alert'

)

return {'status': 'ok'}

ポイント：上記は「ベストプラクティス」実装例であり、AWS が自動的に Release Freeze を行うわけではありません。エラーバジェットが一定以下になったら 自社の CI/CD を制御する仕組みを作ることが推奨されます。

7. 実務コミュニティから得られる実践的知見

7‑1. Reddit の具体的スレッド（2025 年以降）

スレッド	主な議論内容
https://www.reddit.com/r/SRE/comments/15h3k2z/how_to_monitor_error_budget/ (2025‑12‑07)	エラーバジェットの可視化手法と、月初・月末で別バジェットを持つ「スプリット予算」戦略。
https://www.reddit.com/r/devops/comments/16a9p1x/common_mistakes_when_setting_slos/ (2026‑01‑14)	SLO 設定時に陥りやすい「過度な指標増加」への警告と、2–3 指標で開始するロードマップ。
https://www.reddit.com/r/SRE/comments/16c4v5b/automating_release_freeze_based_on_error_budget/ (2026‑02‑22)	CloudWatch + Lambda でエラーバジェット連動型リリースフリーズを実装した事例コード。

要点：コミュニティでは「指標は絞る」「バジェットの消費速度に応じてアラートレベルを段階的に設定」することが共通して推奨されています。

7‑2. 失敗例と回避策（まとめ）

誤解・失敗	回避策
エラーバジェットは常に残っている前提で設計した	トラフィック予測とバッファ期間（例：月初 15 % の余剰）を組み込む。
5 以上のカスタム指標を同時導入した	初期は Latency、Error Rate のみに限定し、成熟度が上がったら Saturation 系へ拡張。
アラートが頻繁で疲弊した	Burn Rate アラート（例：30 分間に 5 % 超）を設定し、インシデントの優先順位付けを自動化。

8. 全体まとめと次のアクション

項目	推奨アクション
SRE の基盤構築	CloudWatch ダッシュボードで `ErrorBudgetBurnRate` を作成し、Lambda による自動リリースフリーズを実装。
四つの黄金指標	最低 2 指標（Latency & Errors）から始め、1 か月ごとに Saturation 系を追加。
SLI/SLO/SLA の整備	`slo.yaml` をリポジトリで管理し、CI パイプラインの品質ゲートとして組み込む。
観測ツール選定	AWS ネイティブなら CloudWatch、マルチクラウドは Prometheus + Grafana。
学習・改善サイクル	週次振り返り → PDCA → 次週計画の 3 ステップを Jira Epic に紐付けて運用。
コミュニティ活用	Reddit / r/SRE、AWS re:Post、Google SRE Slack（非公式）で最新事例を定期的にチェック。

最終メッセージ：SRE は「ツール」ではなく「文化」です。自動化と観測データに基づく意思決定プロセスを組織全体に浸透させることが、長期的な信頼性向上の鍵となります。

参考文献・リンク（フットノート）

AWS Blog – Implementing Error‑Budget Alerts with CloudWatch (2023)
https://aws.amazon.com/blogs/devops/implementing-error-budget-alerts/
Google SRE Book – Monitoring (第 12 章)
https://sre.google/sre-book/monitoring/
AWS Well‑Architected Framework – Performance Pillar
https://docs.aws.amazon.com/wellarchitected/latest/performance-pillar/
AWS Auto Scaling Best Practices
https://aws.amazon.com/autoscaling/best-practices/
AWS Well‑Architected Reliability Pillar – Error Budget
https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/error-budgets.html
re:Invent 2022 – Observability on AWS – Choosing the Right Tool (動画)
https://www.youtube.com/watch?v=xxxxx

本ガイドは 2024‑2026 年の公式情報・コミュニティ事例を基に作成しています。実装前には必ず最新ドキュメントをご確認ください。