Part 4 実行環境と運用・動画
第17章 オブザーバビリティとSRE
動画台本ナレーション全文
Slide 01. オブザーバビリティとSRE
第17章では、何か起きたときにログや数字から状況を追う見方を学びます。オブザーバビリティは、外から得られる情報を使って、システムの中で何が起きているかを調べられる状態のことです。SREは Site Reliability Engineering の略で、サービスを安定して使えるようにエンジニアリングで支える考え方です。この章では専門組織の話ではなく、自分が作った機能を観察し、問題を説明し、改善PRにつなげることに集中します。
Slide 02. この章で持ち帰ること
この章で持ち帰ってほしいことは三つです。一つ目は、リリース後も品質づくりは続くと理解することです。二つ目は、ログ、メトリクス、トレースを使い分けて、勘ではなくデータで調査することです。三つ目は、遅い、失敗する、使いにくいといった問題を、修正前と修正後の数字で説明できる改善PRにすることです。
Slide 03. 第16章との接続
第16章では、AWSへデプロイし、リリース手順書を書く流れを扱いました。第17章では、その後を見ます。自動実行が成功し、App Runnerが起動中になっても、利用者にとって快適とは限りません。データ量、通信、DB、外部サービス、設定差分によって問題が起きます。出した後に観察し、学び、直すところまでが品質づくりです。
Slide 04. リリース後も品質づくりは続く
テストが通り、デプロイできても、本番の利用状況で初めて見える問題があります。支援ステータス一覧が遅い。更新APIがたまに失敗する。ログはあるが、どのリクエストか追えない。こうした問題は、作ったエンジニアも向き合う必要があります。運用を丸投げするのではなく、自分の変更が実際にどう動いているかを見る姿勢を持ちます。
Slide 05. monitoringとobservability
monitoringは、あらかじめ決めた指標や状態を監視することです。たとえばエラー率が高い、CPUが高い、というような既知の問題に気づくのに向いています。observabilityは、得られる情報から内部で何が起きているかを調べられる状態です。きれいなグラフ画面を作ることが目的ではありません。問題が起きたときに説明できることが目的です。
Slide 06. ログ
ログは、個別の出来事を読むために使います。いつ、どの画面やAPIで、どのリクエストが、どんな状態になり、どれくらい時間がかかったのか。エラーなら、調査に必要な背景情報を残します。ただし、password、token、secret、個人情報は出してはいけません。ログは後から読むための実装です。未来の自分やチームが調査できる形で出します。
Slide 07. メトリクス
メトリクスは、状態や傾向を数値で見るために使います。リクエスト数、エラー率、レイテンシ、CPU、メモリなどです。個別の出来事を読むログに対して、メトリクスは全体の変化を見るのが得意です。いつから遅くなったか。どの時間帯に失敗が増えたか。デプロイ前後で変化したか。感想ではなく、数値と時間で見ます。
Slide 08. トレース
トレースは、1つのリクエストが複数の処理を通る流れを見るために使います。Webの入口、認可確認、DB問い合わせ、外部API呼び出しのうち、どこで時間がかかったかを追いやすくなります。OpenTelemetryやAWS X-Rayのような仕組みを使うと、この流れを集められます。この章では本格構築ではなく、リクエストの通り道を見る考え方として扱います。
Slide 09. request idとtrace id
ログ、メトリクス、トレースは、それぞれ単独でも役に立ちます。ただし、request idやtrace idでつながると、調査しやすくなります。request idは、1つのリクエストを追うための識別子です。trace idは、分散した処理の流れを追うための識別子です。支援ステータス一覧が遅いとき、そのリクエストのログ、トレース、関連するメトリクスを結びつけます。
Slide 10. 構造化ログ
構造化ログは、ログを文章だけでなく、key-valueの形で出す方法です。まずは request_id、endpoint、status、duration_ms のように、調査でよく見る項目を分けます。こうすると検索や集計がしやすくなります。debug、info、warn、error のレベルも、緊急度に合わせて使います。ログは多ければよいのではなく、調査に使える形で出すことが大事です。
Slide 11. ログに出してはいけないもの
ログには、出してはいけないものがあります。password、access token、session token、secret key、個人情報、AWS account id、内部URLなどです。第14章と第16章で扱ったsecret管理とつながります。ログは調査に便利ですが、長く保存されたり、複数人が見たりします。便利さのために、漏らしてはいけない情報を混ぜないようにします。
Slide 12. App Runnerのログ
第16章の標準構成では、App RunnerでWebアプリを動かします。App Runnerのログは、CloudWatch Logsで確認します。大きく分けると、デプロイや起動のログと、アプリが実行中に出したログがあります。デプロイ直後は、サービスの状態、起動ログ、アプリのエラー、リクエストが届いているかを見ます。
Slide 13. CloudWatchのメトリクス
CloudWatchのメトリクスでは、App Runner serviceのリクエスト数、レスポンス状態、レイテンシ、CPU、メモリなどを確認します。ログが個別の出来事を見るものなら、メトリクスは全体の傾向を見るものです。デプロイ後に遅くなったのか、5xxエラーが増えたのか、アクセスが増えたのかを見ます。第16章のリリース手順書には、ログとメトリクスの確認まで含めます。
Slide 14. 基本指標
まず見る基本指標は四つです。レイテンシはどれくらい遅いか。エラー率はどれくらい失敗しているか。トラフィックはどれくらい使われているか。サチュレーションは余裕がどれくらい残っているかです。DBがある場合は、問い合わせ時間、接続数、ロック、CPU、保存容量も見ます。問題調査では、どの指標がいつからどれくらい変わったかを見ます。
Slide 15. SLI
SLIは Service Level Indicator の略で、サービスの信頼性を測る指標です。重要なユーザー行動から考えます。たとえば、メンターが支援ステータス一覧を開けること。これを、一覧APIが成功し、1秒以内に返る割合、のように測れる形にします。SLIは、CPUが何パーセントかだけではなく、利用者の体験に近いものから選びます。
Slide 16. SLO
SLOは Service Level Objective の略で、SLIに対して置く目標値です。たとえば、支援ステータス一覧のリクエストの99パーセントが、7日間で1秒以内に成功する、というたたき台です。最初から全機能にSLOを置く必要はありません。重要なユーザー行動から少しずつ始めます。用語を暗記するより、期待する体験を測れる形にすることが大事です。
Slide 17. ダッシュボード
ダッシュボードは、見る人と使う場面を決めて作ります。すべての数値を並べると、重要な異常が見えにくくなります。最初は、使える状態か、エラー率、レイテンシ、アクセス量、リソースの余裕、デプロイ履歴くらいに絞ります。目的は、見た人が次に何をすべきか分かることです。きれいなグラフを増やすことではありません。
Slide 18. アラーム
アラームは、鳴ったら行動できるものに絞ります。エラー率が一定以上なら、直近のリリースとエラーログを見る。p95レイテンシが1秒を超えたら、遅いAPIの調査手順へ進む。鳴っても誰も見ないアラームや、頻繁に鳴りすぎるアラームは、だんだん無視されます。条件、時間窓、見る人、最初の行動をセットで決めます。
Slide 19. ケース: 遅いAPI
ここからは、支援ステータス一覧APIが遅くなるケースに絞って考えます。データ件数が増えたあと、一覧表示がいつもより遅くなりました。ログは出ていますが、request idがなく、1件のリクエストを追いにくい状態です。ダッシュボードにはCPUとメモリしかなく、利用者がどれくらい待っているかも見えません。この状況を、感覚ではなく観察データで調べます。
Slide 20. 再現条件
遅い、という言葉は曖昧です。まず再現条件を書きます。どのAPIか。どの環境か。データ件数はどれくらいか。いつ実行したか。どのリリースやimage tagか。入力条件は何か。再現できるかを確認すると、調査が始めやすくなります。感想をそのまま直すのではなく、調べられる形に分解します。
Slide 21. before計測
修正前の状態を計測します。p50、p95、p99レイテンシ、エラー率、リクエスト数を見ます。p50は中央値に近い代表値、p95は遅い側の上位5パーセントを除いた境目、p99はさらに遅い側まで見る指標です。平均だけを見ると、少数の遅いリクエストを見落とすことがあります。修正前を残すと、修正後に本当に改善したか説明できます。
Slide 22. 原因候補
原因は決めつけず、候補を複数出します。DBの問い合わせが遅い。N+1 queryが起きている。外部APIが遅い。データ量が増えた。順番に処理していて待ち時間が積み上がっている。cacheが効いていない。デプロイ差分で処理が変わった。候補を出したら、ログ、メトリクス、トレース、コード差分、DBの問い合わせ内容で確認します。思いつきで直すより、証拠で絞ります。
Slide 23. ログで見る
ログでは、対象リクエストのendpoint、status、duration、request id、error messageを見ます。どの時刻に遅いリクエストが出たか。エラーと遅さが同時に起きているか。特定のユーザーや入力条件に偏っていないか。ただし、個人情報をそのまま出してはいけません。ログが足りない場合は、改善PRで観測点を追加することも価値があります。
Slide 24. メトリクスで見る
メトリクスでは、悪化した時刻と範囲を見ます。全体のレイテンシが上がったのか、特定のendpointだけなのか。エラー率は増えたのか。アクセスが急増したのか。CPUやメモリに余裕はあるのか。デプロイ履歴と重ねると、リリース後から悪化したかを見やすくなります。数字は単独ではなく、時間と文脈で読みます。
Slide 25. トレースで見る
トレースがある場合は、リクエスト全体の中でどのspanが長いかを見ます。spanは、処理の区間を表す単位です。認可確認が長いのか、DB問い合わせが長いのか、外部APIが長いのか。トレースがない場合でも、request idと処理時間つきのログで近い調査はできます。この章では、完璧な基盤より、どこで詰まっているかを説明できることを重視します。
Slide 26. 改善PR
改善PRには、症状、再現条件、計測方法、原因、修正内容、修正前と修正後、残した課題を書きます。速度改善も、機能変更と同じようにレビューされます。ログやメトリクスを追加しただけでも、次の調査を楽にする価値があります。測定方法が変わっただけで速く見えていないかも確認します。数字と差分で説明しましょう。
Slide 27. インシデント対応
インシデントは、利用者や事業に影響する問題です。まず影響範囲を把握します。次に、止血、復旧、連絡、調査を進めます。慌てて直すことだけが対応ではありません。誰が何を見るか、どこに記録するか、いつ共有するかを決めます。すべてを一人で抱えず、事実を集めながら判断します。
Slide 28. インシデントレビュー
インシデントレビュー、またはpostmortemは、責めるためではなく再発を減らすために行います。何が起きたか。いつ検知したか。利用者影響は何か。暫定対応と恒久対応は何か。検知、調査、連絡、復旧で何を改善できるか。タイムラインを書くと、事実と解釈を分けやすくなります。次の対応は、実行できる粒度にします。
Slide 29. AIに調査を手伝わせる
AIは、ログ要約、原因候補、調査手順、改善案、PR本文、インシデントレビューの下書きに使えます。ただし、秘密情報、個人情報、AWS account id、内部URLは貼りません。ログは個人情報やIDを伏せてから使います。AIが出した原因候補は、メトリクス、ログ、トレース、再現手順、コード差分で確認します。それっぽい説明を、そのまま事実として書かないようにします。
Slide 30. Exercise 1-3
一つ目の演習では、観察したいユーザー行動を一つ選び、何を測ればよいかを書きます。成果物は observability-goals.md です。二つ目では、ログ、メトリクス、トレース、request id、ログに出さないものを整理します。成果物は telemetry-plan.md です。三つ目では、ダッシュボードとアラームを使って、誰が最初に何を見るかを書きます。成果物は slo-and-alert-note.md です。
Slide 31. Exercise 4-5と第18章への接続
四つ目の演習では、遅いAPIを調査し、症状、原因候補、修正前後の数字を使って改善PRの説明を書きます。成果物は slow-api-investigation.md です。五つ目では、小さなインシデントレビューを書き、何が起きたか、次に何を直すかを整理します。成果物は incident-review-note.md です。次の第18章では、AIの出力も候補として扱い、根拠と評価で確かめる見方へ進みます。