Contents
Four Golden Signals の最新解釈（2025 年版）
本セクションでは、Four Golden Signals が 2025 年においても可観測性の核であることを示し、各シグナルとビジネスインパクトの結びつきを簡潔に整理します。
なぜ重要か：4 つの指標は最小限のメトリクスでサービス全体の健全性を把握でき、監視コストと信頼性向上のバランスを取るための出発点となります。
結論：Golden Signals は「顧客体験 ⇔ SLO 設定」の橋渡しとして活用すべきです（Splunk 解説）。
1. レイテンシ
レイテンシは エンドツーエンドの応答時間 を示し、ユーザー体感速度に直結します。
- 測定対象：HTTP リクエスト遅延、DB クエリ時間、外部 API 呼び出しなど。
- 推奨閾値：p99 latency < 0.2 秒（200 ms）。
計算例（SLO 達成度）
[
\text{ErrorBudget} = (1 - \text{SLO}) \times T
]
たとえば SLO が 99.9%（(T = 30) 日）であれば、エラーバジェットは
[
0.001 \times 30\,\text{days} = 43.2\,\text{minutes}
]
この時間内にレイテンシが閾値超過した分だけ消費されます。
2. トラフィック
トラフィックは リクエスト数やメッセージ投入量 を測定し、容量計画の根拠となります。
- 測定対象：RPS、TPS、キュー投入件数など。
- 閾値例：過去 7 日平均 ±20% を超えるとスケールアウト／インを検討。
3. エラー
エラーはシステム障害の直接指標です。
- 測定対象：HTTP 5xx、例外スロー数、バックエンド失敗率。
- 閾値例：5xx エラー率 > 0.1%（= 0.001）で SLO に影響。
4. サチュレーション
リソース使用率が上限に近づくとサービス品質が低下します。
- 測定対象：CPU、メモリ、ディスク I/O、ネットワーク帯域。
- 自動対策例：CPU 利用率 > 80% の瞬間にスケールアウトをトリガー。
メトリクス選定と SLI／SLO 設計の 3 原則
この章では、顧客価値・観測可能性・実装コスト の三本柱でメトリクスを絞り込み、具体的な SLI／SLO を作成する手順を示します。
重要性：適切に設計された SLI/SLO がエラーバジェット管理の基盤となり、意思決定を数値化できます（Wikipedia – Site Reliability Engineering）。
1. 顧客価値の抽出
| ビジネスゴール | 対応シグナル | 推奨 SLI |
|---|---|---|
| レスポンス遅延に対する不満削減 | Latency | p99 latency < 0.2 s |
| 障害時の復旧速度向上 | Error & Saturation | 5xx error rate < 0.001、CPU < 80% |
2. 観測可能性の確認
- Prometheus exporter が既存か：
request_duration_seconds_bucketが出力されていれば追加実装は不要。 - 欠損メトリクス は Lambda／Cloud Function 経由でカスタムメトリクス化。
3. 実装コストの評価
| 手段 | 初期工数 | 維持工数 |
|---|---|---|
| CloudWatch カスタムメトリクス | 低（CLI） | 中（アラート調整） |
| Prometheus exporter | 中（バイナリ配布） | 低（自動ロールアップ） |
| GCP Monitoring のカスタム指標 | 高（gcloud） | 中（Terraform 管理） |
ツール別メトリクス設定例
以下は Prometheus/GMP, AWS CloudWatch, Google Cloud Monitoring での実装サンプルです。すべて IaC（Terraform）に変換可能です。
Prometheus / GMP のウィンドウベース SLO ルール
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# slo_rules.yaml groups: - name: slo.rules rules: - record: job:latency:p99_5m expr: histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[5m])) by (le)) - alert: LatencySLOViolation expr: job:latency:p99_5m > 0.2 # 0.2 秒 = 200 ms for: 2m labels: severity: critical annotations: summary: "Latency SLO violation" description: "p99 latency exceeded 200 ms." |
ポイント：
exprの単位は 秒 であることに注意し、0.2 が 200 ms を正しく表します。
AWS CloudWatch のメトリクスフィルターとアラーム
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# フィルタ作成（ERROR 行をカウント） aws logs put-metric-filter \ --log-group-name /aws/lambda/my-service \ --filter-name ErrorCountFilter \ --filter-pattern '"ERROR"' \ --metric-transformations metricName=ErrorCount,metricNamespace=MyService,metricValue=1 # アラーム作成（5 分間の合計が閾値を超えたら通知） aws cloudwatch put-metric-alarm \ --alarm-name MyService-ErrorRate \ --metric-name ErrorCount \ --namespace MyService \ --statistic Sum \ --period 300 \ --evaluation-periods 2 \ --threshold 5 \ --comparison-operator GreaterThanThreshold \ --actions-enabled |
Google Cloud Monitoring のダッシュボードとアラートポリシー
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "displayName": "SLO Dashboard", "gridLayout": { "columns": "2", "widgets": [ { "title": "Latency (p99)", "xyChart": { "dataSets": [{ "timeSeriesQuery": { "prometheusQuery": { "query": "histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[5m])) by (le))" } }, "plotType":"LINE"}] } }, { "title": "Error Rate", "xyChart": { "dataSets": [{ "timeSeriesQuery": { "metricFilter": "metric.type=\"custom.googleapis.com/http_error_rate\"" }, "plotType":"STACKED_AREA"}] } } ] } } |
|
1 2 3 4 5 6 7 8 9 |
# エラー率が 0.1% 超えたら通知 gcloud monitoring policies create \ --notification-channels=$CHANNEL_ID \ --condition-display-name="High HTTP error rate" \ --condition-filter='metric.type="custom.googleapis.com/http_error_rate"' \ --condition-comparison=COMPARISON_GT \ --condition-threshold-value=0.001 \ --condition-duration=300s |
IaC（Terraform / Ansible）ベストプラクティス
Terraform の構造例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# providers.tf provider "aws" { region = var.aws_region } provider "google"{ project = var.gcp_project, region = var.gcp_region } # cloudwatch_alarm.tf resource "aws_cloudwatch_metric_alarm" "error_rate" { alarm_name = "myservice-error-rate" metric_name = "ErrorCount" namespace = "MyService" statistic = "Sum" period = 300 evaluation_periods = 2 threshold = 5 comparison_operator = "GreaterThanThreshold" alarm_actions = [aws_sns_topic.alerts.arn] } # gcp_dashboard.tf resource "google_monitoring_dashboard" "slo" { dashboard_json = file("${path.module}/dashboard.json") } |
ベストプラクティス
- variables.tf にすべての環境変数（リージョン、プロジェクト名）を集約。
- モジュールは monitoring, alert, exporter で分割し、再利用性とテスト容易性を確保。
- CI パイプラインで terraform fmt -check && terraform validate && terraform plan -out=plan.out を実行し、コードレビュー前に差分確認。
Ansible Playbook（Node Exporter デプロイ）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
--- - name: Deploy Prometheus node exporter hosts: monitoring_nodes become: yes vars: exporter_version: "1.6.1" tasks: - name: Download archive get_url: url: "https://github.com/prometheus/node_exporter/releases/download/v{{ exporter_version }}/node_exporter-{{ exporter_version }}.linux-amd64.tar.gz" dest: /tmp/node_exporter.tar.gz mode: '0644' - name: Extract archive unarchive: src: /tmp/node_exporter.tar.gz dest: /opt/ remote_src: yes - name: Install systemd service copy: dest: /etc/systemd/system/node_exporter.service content: | [Unit] Description=Prometheus Node Exporter Wants=network-online.target After=network-online.target [Service] ExecStart=/opt/node_exporter-{{ exporter_version }}.linux-amd64/node_exporter Restart=always [Install] WantedBy=default.target notify: Reload systemd - name: Enable and start service systemd: name: node_exporter.service enabled: yes state: started handlers: - name: Reload systemd command: systemctl daemon-reload |
varsにバージョンだけを変更すれば全ノードの一括アップグレードが可能。notifyで冪等性（idempotency）を担保し、エラー時はロールバックしやすくなる。
メトリクス命名・タグ付けとコスト最適化（2026 年版）
命名規則
|
1 2 |
service:component:metric_name |
| 要素 | 例 |
|---|---|
| service | order、payment |
| component | api、db、worker |
| metric_name | latency_seconds、error_count |
必須ラベル：env, region, team（例: env=prod, region=asia-northeast1, team=backend）
コスト削減策
- 保持期間の階層化
- 0–7 日 → 1 分粒度
- 8–30 日 → 5 分粒度
-
31 日以降 → 1 時間粒度
-
不要メトリクスの自動削除（Prometheus の
DELETE_SERIESAPI と Terraform のnull_resourceを組み合わせ） -
集計窓の見直し
-
高頻度カウンタは
rate(...[5m])に切り替えることで、クエリ回数と保存データ量を 80 % 程度削減。 -
タグベース課金レポート
- AWS Cost Explorer の
Tagフィルタで月次レビューし、未使用ラベルのメトリクスを除外。
実装検証フロー（CI/CD への組み込み）
- ローカルユニットテスト
-
promtool test rules slo_rules.yamlで SLO ルールが期待通り評価されるか確認。 -
ステージング環境へデプロイ
-
Terraform で CloudWatch / GCP Dashboard を作成し、
aws cloudwatch put-metric-data/gcloud monitoring metrics writeでサンプルデータを送信。 -
アラート発火テスト
-
故意に閾値超過（例：Latency = 0.5 s）を送信し、SNS/メールが届くことを確認。
-
CI パイプライン自動化（GitHub Actions の例）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
name: Monitoring CI on: push: paths: - '**/*.tf' - '**/*.yml' jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Terraform fmt & validate run: | terraform fmt -check terraform validate - name: Apply to staging (plan only) env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }} run: terraform plan -out=plan.out |
このフローにより、設定ミスやメトリクスのドリフトを プルリクエスト時点で検出 でき、運用開始前に品質が保証されます。
まとめ
- Four Golden Signals は顧客体験と SLO の橋渡しとして不可欠。
- 3 原則（顧客価値・観測可能性・実装コスト） に基づきメトリクスを選定し、エラーバジェット計算式で数値化。
- Prometheus / CloudWatch / GCP Monitoring の具体的設定例と IaC（Terraform／Ansible）活用により、監視の自動化・再現性を確保。
- 統一命名＋タグ付け と保持期間階層化で 2026 年以降のクラウド課金を最小化。
- CI/CD に組み込んだ検証フロー が、設定ミスやデータドリフトを早期に発見し、信頼性向上につながります。
この流れで段階的に取り組めば、SRE メトリクスの設計・実装・運用が一貫したベストプラクティス として確立でき、サービス全体の可用性とコスト効率を同時に最適化できます。