SREとは何か、AWSでどう始めるか

Transcript

1. #jawsug #jawssonic2026 SREとは何か、 AWSでどう始めるか JAWS-UG SRE支部 Koki Tamura
2. 自己紹介 プロフィール ・ SRE、Platform、セキュリティあたりの仕事をしてます ・ いまの仕事はほぼ Google Cloud（AWS はたまに） ・ 車の整備士 → 工場の管理者 → エンジニア 最近好きなもの Koki Tamura JAWS-UG SRE / 富山支部 X：@koki_tamuramaro ・ 早インパラ ・ マジックスパイス（スープカレー）
3. SRE とは何か 運用を「人の手作業と勘」から「コードと数字」に置き換え、 開発スピードと信頼性を両立させること 本日話すこと ： ・ 前半： 3 つの問いで、SRE の考え方を説明 ・ 後半： AWS のどのサービスで始めるかを紹介
4. 「信頼性」って、具体的に何? 信頼性は、CPU使用率やメモリの閾値ではなく、「相手への影響」で測る サービスの信頼性（相手: 利用者） 届ける仕組みの信頼性（相手: 開発者） ・ リクエストが成功する（可用性） ・ CI/CD が安定して通る ・ 速く返ってくる（レイテンシー） ・ 安全に戻せる（ロールバック） ・ データが正しい・失われない ・ 同じソースから同じものを作れる （再現可能なビルド）
5. SRE って、こんな感じ 用語はこれから順に説明します 観点 いままで SRE アラート CPU やメモリの閾値で鳴る ユーザー影響（SLO）で鳴る 手作業 手順書を人が実行 ソフトウェアで置き換える 障害後 報告書で終わり 個人を責めない振り返りで仕組みを直す 開発と運用 運用は止めたくない、開発は早く出したい エラーバジェットで同じ数字を見る ① 観測する SLI を測る ② 決める → SLO / エラーバジェット ③ 減らす → トイルを自動化 ④ 学ぶ → ポストモーテム
6. できているか、3 つの問いで確かめてみよう 前ページの回し方、あなたのチームでできていますか？ 答えに詰まるなら、まだ仕組みが入っていないだけ... 仕組みには名前がついています！ 1. このサービスの信頼性の目標値、チームの誰かが即答できますか？ 2. 運用の手作業、チームで数えたことがありますか？ 3. 前回の障害のあと、組織として何が変わりましたか？
7. 問い 1 の仕組み — SLI / SLO / エラーバジェット 問い 1: 目標値を即答できますか？ エラーバジェットが「信頼性と開発スピードの両立」の仕組み 開発・運用・プロダクトで事前に合意して使う SLI = 測るもの SLO = SLI の目標値 エラーバジェット = 100% − SLO まず「何で測るか」を決める その SLI に置く目標値 目標に届かなくてよい分が 例: リクエスト成功率、レイテンシー の p90（遅い側 1 割の境目） → （または値の範囲） 例: 30 日間で成功率 99.9% → 「許容する失敗の量」 99.9% なら 1,000 回に 1 回（30 日で約 43 分） Google の公開例: 直近 4 週間でエラーバジェットを超過したら、最優先の障害対応とセキュリティ修正を除く全ての変更・リリースを止める
8. 問い 2 の仕組み — トイル （Toil） 問い 2: 手作業を数えたことがありますか？ トイル = 手作業・繰り返し・自動化できる作業 場当たり的で、価値が積み上がらず、サービスが育つほど増える トイルの例 トイルではない ・手動再起動 ・自動化の仕組みを作る ・ログの目視確認 ・SLO を設計する ・手順書デプロイ ・障害の振り返りを書く ・依頼ベースの権限発行 ・オンコール体制を設計する まず、チームの時間の何割がトイルかを数えるところから Google は運用作業全体に上限 50% を置いていますが（社内ルール）、 真似るのは数値そのものより、「上限を置く」という考え方です
9. 問い 3 の仕組み — ポストモーテム 問い 3: 障害のあと、何が変わりましたか？ 障害の記録で、何が起きたか・影響・対応・根本原因・再発防止を書く 個人を責めず、直すのは仕組み 書くきっかけ（代表例） ・ユーザーに影響が出た ・データが失われた ・オンコールで人が呼ばれた ・監視が異常を見逃した ポストモーテムの鉄則は、個人を責めないこと 責めると情報が隠れて、同じ障害が繰り返される
10. オンコールも、設計の対象 3 つの問いの答えが決まると、夜の呼ばれ方も決まる 当番表ではなく、「呼ぶ基準」と「負荷の上限」を設計する ・ 呼ぶ基準： SLO への影響が出たときに呼ぶ ・ CPU 使用率のようなリソース閾値だけでは夜中に呼ばない ・ 負荷の上限： Google の例では、12 時間シフトで対応は最大 2 件 ・ オンコールは業務の 25% まで
11. まとめると、SRE 表の右側の回し方、それが SRE（4 つの括り方は公式ではなく今日の整理） 観点 いままで SRE アラート CPU やメモリの閾値で鳴る ユーザー影響（SLO）で鳴る 手作業 手順書を人が実行 ソフトウェアで置き換える 障害後 報告書で終わり 個人を責めない振り返りで仕組みを直す 開発と運用 運用は止めたくない、開発は早く出したい エラーバジェットで同じ数字を見る ① 観測する SLI を測る ② 決める → SLO / エラーバジェット ③ 減らす → トイルを自動化 ④ 学ぶ → ポストモーテム
12. よくある誤解 5 つ ✖ SLA と SLO は同じもの → SLA は顧客との契約、SLO はチームが決める目標で、別物 ✖ SLO は 100% を目指す → SLO に 100% は置かない → 桁を増やすほどコストは跳ね上がるのに、ユーザーはその差に気づけない ✖ サービスの信頼性は高いほど良い → 上げすぎも問題で、ユーザーが障害が起きない前提で使用する → そのため、維持するのに手一杯になり、新しい開発が止まってしまう ✖ SLO は現状の実績値をそのまま置く → SLO はユーザーが困らない水準を、チームで決める ✖ SRE は運用チームの改名 → SRE は考え方ごと変える取り組みで、ソフトウェアエンジニアリングで運用の問題を解く
13. 続きを学ぶ場所 — JAWS-UG SRE 支部 運営メンバー Mary 北浦 ふるや これなが たむら #jawsug_sre
14. 次回は横浜支部とのコラボLT会！ 開催日時： 2026/09/18 （金） 19：00〜 会場 ： みなとみらい（YAMAHA MOTOR Regenerative Lab） お気軽にご参加くださいー！！ LTもお待ちしてます！！
15. 後半 — AWS のどこから？ 責任共有モデルで範囲を絞る AWS を使う場合、クラウド「内」の信頼性は利用側が担う ここに 4 つ (① 観測する ② 決める ③ 減らす ④ 学ぶ） の流れを当てはめる クラウド「の」信頼性 クラウド「内」の信頼性 AWS が担う 利用側の組織が担う リージョン / AZ / ハードウェア アーキテクチャ / デプロイ マネージドサービスの中身 監視 / 障害対応
16. 4 つの流れ × AWS の地図 4 つの流れは今日の整理。深掘りするのは 3 つだけ ① 観測する ② 決める ③ 減らす ④ 学ぶ ＋ 検証 AI と回す Application CloudFormation / CloudWatch FIS（障害注入） AWS DevOps OTel Signals SLO CDK / Terraform investigations Resilience Hub Agent（運用調査） （計測の共通規格） （SLO の推奨値 / （インシデントレポート・ （構成評価） AWS Security なぜなぜ分析付き） ARC zonal shift Agent（セキュリティ） （AZ 退避） AWS FinOps Agent Application Signals RUM（実ユーザー） 消費ペース警報） （IaC） SSM Automation Synthetics runbook （外形監視） EventBridge + （コスト・Preview） Logs / Alarms Lambda AWS MCP Server Managed Grafana / CodeDeploy 自動 （AIからAWSを操作） Prometheus ロールバック Kiro（AI 開発環境） Auto Scaling AWS だけで始めるなら まず（最小） 慣れたら（＋α） AI に任せる SLO の叩き台・Alarms・investigations + Application Signals + IaC + Runbook + 外形監視（Synthetics） + DevOps Agent で調査を AI に 土台: Well-Architected（AWS 公式の設計ガイド： 信頼性 / 運用上の優秀性）
17. 「観測する」= モニタリング + オブザーバビリティ 地図の「① 観測する」列の読み方 SLO を守るには両方必要 モニタリング オブザーバビリティ あらかじめ決めた項目を監視して、 想定していなかった障害でも、 何が起きたかに気づく なぜ起きたかをあとから追える 例: 1 つのリクエストに ID（trace ID）を振り、 ログと処理の記録をつないで 1 件ずつ追える
18. 深掘り：観測・決める — Application Signals 計測エージェントを入れるだけで、成功率とレイテンシーなどが取れる ・ 対応言語： Java / Python / .NET / Node.js ・ SLIとしても使用できる、成功率とレイテンシーが取得できる ・ SLO 推奨: 過去 30 日の数字を見て、SLO の案を出してくれる ・ トレースも自動で取れて、遅いリクエストを trace ID で 1 件ずつ追える ・ バーンレート（= バジェットを使う速度）が速すぎるときだけアラーム
19. 深掘り：減らす — 手順書を Runbook に 本番への変更は、チームの承認プロセスに乗せる 見つけたトイルは、次にやるときにコードにする Before After 手順書を見ながら手で 6 ステップ（一般例） ・ SSM Automation Runbook なら、 ・ ボタン 1 つで実行できる 状況確認 → 対象を停止 → 設定変更 → 再起動 → 動作確認 → 記録 → ・ AI の調査（investigations）が、 ・ 実行すべき Runbook を提案してくれる
20. 深掘り：学ぶ — そして AI AI はテレメトリだけでも調査できる だが過去の障害記録（コンテキスト）があるほど、原因の絞り込みが速い CloudWatch investigations のインシデントレポート / なぜなぜ分析（5Whys） アラームに紐付けると、AI が仮説とタイムラインを残す それを基にポストモーテムを書ける 調査を任せられる AI エージェント AWS DevOps Agent（運用の調査・修復案、環境を変更する操作は人が承認してから実行） Security Agent（セキュリティ）/ FinOps Agent（コスト・Preview）
21. AWS だけで始めるなら ① まず（最小） SLO の叩き台・Alarms・investigations 画面: アラームを起点に investigations が原因を調べた結果 アラームが鳴ったら、AI が原因候補を出す やること 3 つ SLO の叩き台: 例「API 応答の成功率が月間 99.9%」 Alarms: その数字をしきい値にして置く investigations: 鳴ったらアラームから調査を始める 画面の見方 上: AI が ALB の 503 エラーと相関づけた所見 下: 起点になった外形監視のアラーム この所見を基に調査を実施することができる
22. AWS だけで始めるなら ② 慣れたら（＋α） + Application Signals + IaC + Runbook + 外形監視（Synthetics） 画面: Application Signals の SLO 詳細（外形監視の成功率が SLI） 残りのエラーバジェットが、数字で見える 足すもの Application Signals: SLO の達成率と残りバジェット 外形監視（Synthetics）: 成功率を SLI にする IaC / Runbook: 監視の設定と手順書もコードに置く 画面の見方 朝に失敗した分、残りのエラーバジェットは 82%（36 分） 達成率は目標 99.9% を上回り、状態は正常 減りが速いときだけアラームが鳴り、調査が始まる
23. AWS だけで始めるなら ③ AI に任せる + DevOps Agent で調査を AI に 「調べて」で、AI が原因と対策をまとめる やること DevOps Agent: Agent Space に AWS アカウントをつなぐ アラームか「調べて」の一言で調査が始まる 環境を変える操作は、人が承認してから実行する 画面の見方 根本原因をインフラ側の変更まで特定した ECS の起動失敗から外形監視の失敗まで因果でつないだ 対策も短期・中期・長期で提案してくれます 画面: DevOps Agent の調査結果
24. 専任の SRE がいなくても SRE は、専任がいなくても始められる ・ SRE は、専任を雇わないと始められない話ではなく ・ 今のチームの回し方を変える話 ・ ひとり目から始めた事例が、コミュニティに多数ある
25. たとえば、こんな始め方 環境もチームも違うので、あくまで一例 最初は「見る」から始める 信頼性の積み上げは、観測が土台になる 1 見る 2 書く 3 出す 直近 30 日の 5xx（サーバーエラー）とリクエスト数を眺める ユーザー影響で鳴るアラーム 1 本の提案と、SLO の叩き台を 1 枚に チームの場に持ち込む（変更は組織のプロセスで）
26. 信頼性と開発スピードは、気合と徹夜ではなく、 組織で合意した数字と仕組みで両立できる AWS には、そのためのサービスが揃っています まずは「信頼性の目標値」をチームで話すところから始めましょう