案件で学んだSRE実践

Transcript

1. 案件で学んだ SRE実践 鈴木尚毅
2. 本日話すこと 主に案件で学んだ SRE関連のことや 社内で展開していきたい部分を共有します
3. SLI / SLO とは？ SLA Service Level Agreement サービス提供者と利用者の間で 交わされる契約上の取り決め SLO Service Level Objective サービスがどの程度の信頼性を 維持するか具体的な目標を定義す るもの SLI Service Level Indicator SLOを定義する際に 使用される具体的な指標
4. モニタリング手法の比較 なぜゴールデンシグナルを採用したか Golden Signals RED USE 提唱 Google SRE Tom Wilkie Brendan Gregg 適用範囲 システム全体 APIレイヤー インフラレイヤー 指標 レイテンシー(時間) トラフィック(リクエスト量) エラー サチュレーション(飽和性) Rate Errors Duration Utilization Saturation Errors 向いている用途 サービス全体の 信頼性監視 マイクロサービス のリクエスト監視 CPU・メモリ等 リソース監視 → システム全体を横断的に監視でき、 SLI定義の土台として最適なゴールデンシグナルを採用
5. SLI / SLO 定義と運用 ゴールデンシグナルからエラーレート・レイテンシーをSLIとして選定 エラーレート 5xx応答 / 全リクエスト数 レイテンシー 応答時間 定義フロー 1 CUJの特定 → 2 WebTransaction を紐付ける → 3 SLOの目標値設定 SLIの選択 組織的な合意 → 4 継続的な見直し、改善 エラーバジェット枯渇時の自動通知 バジェット残量が閾値を下回ると、 Slackチャンネルに自動通知 CUJ(クリティカルユーザージャーニー)：サービス価値提供の中で最も重要な操作や体験の流れ エラーバジェット：許容できる障害やエラーの量を数値化したもので、100%-SLOで算出される
6. こんな感じで定義してます
7. SLI / SLO 導入して良かったこと 判断基準を数値で議論できるようになった 信頼性やユーザー体験を数値化できる エラーバジェットで優先順位が明確になる バジェット残量を見て新機能開発かバグ修正を優先するかを判断できる ダッシュボードでステークホルダーと共有 エンジニア以外にも信頼性の状況を可視化し、共通認識を持てるようになった
8. 可観測性の向上 Metrics システムの健全性を 定量的に把握 CPU / Memory Logs イベント・エラーの 詳細記録 構造化ログ導入 ログレベル標準化 Traces リクエストの流れを追跡 分散トレーシング ボトルネック特定
9. Core Web Vitals(コアウェブバイタル ) Googleが定義するWebサイトの「ユーザー体験（UX）」を評価するための3つの重要指標の総称 LCP Largest Contentful Paint < 2.5s 読み込みパフォーマンスの尺度 INP Interaction to Next Paint < 200ms 応答性の尺度 CLS Cumulative Layout Shift < 0.1 視覚的安定性の尺度 ダッシュボードで実現していること 時系列推移を可視化 閾値超過時に確認できるように可視化 リリース前後のパフォーマンス比較に活用
10. イメージ
11. 今後の社内展開 : AWS Application Signals バックエンドの可観測性を実現 Application Signals とは CloudWatch配下のAPM機能。OpenTelemetryベースで、SLI/SLOの自動計測・ダッシュボード・分散トレーシングを提供 導入方法 1. エージェント導入 ECSタスク定義に CloudWatch Agentを追加 → 2. 自動計装 OpenTelemetry SDKで アプリを自動計装 → 3. SLO設定 コンソールからSLI/SLOを 定義・ダッシュボード生成 活用例 SLOダッシュボード 可用性・レイテンシーのSLO達成率をリア ルタイム監視 サービスマップ マイクロサービス間の依存関係とボトル ネックを可視化 トレース分析 遅延リクエストのトレースをドリルダウンし て根本原因特定 ※OpenTelemetry：アプリケーションからログ、メトリクス、分散トレースといった可観測性（オブザーバビリティ）データを収集・生成・エクスポートするための標準化さ たオープンソースフレームワーク
13. 今後の社内展開 : CloudWatch RUM フロントエンドのリアルユーザー体験を計測・可視化 ※(料金高くなりがちなので検討中) CloudWatch RUM とは 実際のユーザーのブラウザからパフォーマンスデータを収集。 導入方法 1. App Monitor作成 AWSコンソールから RUM App Monitorを作成 → 2. スニペット埋め込み 生成されたJSスニペットを HTML <head> に追加 → 3. ダッシュボード確認 CWV・エラー・セッションが 自動で可視化される 活用例 CWVモニタリング LCP・INP・CLSを継続的にトラッキング ページ別分析 遅いページ・エラー頻発ページを特定 リリース影響確認 デプロイ前後のパフォーマンス比較
14. 料金シミュレーション 月間リクエスト数ベースの概算（東京リージョンも同額） Application Signals $1.50 / 100万シグナル（全リージョン共通） 初回トライアル 毎月の無料枠 月間 1万 req 月間 10万 req シグナル数 3ヶ月 or 100Mシグナル なし 〜4万 〜40万 Signals料金 $0 − $0.06 $0.60 X-Ray 10万トレース/月 10万トレース/月 $0 (枠内) $0 (枠内) 合計 $0 $0 (X-Rayのみ) ≈ $0.06 ≈ $0.60 CloudWatch RUM $1.00 / 10万イベント（1訪問≈20イベント・全リージョン共通） 初回トライアル 毎月の無料枠 月間 1万 訪問 月間 10万 訪問 イベント数 100万イベント (1回限り) なし 20万 200万 合計 $0 $0 該当なし ≈ $2 / 月 ≈ $20 / 月
15. まとめ 社内の運用体制もっとよくしたい