パフォーマンス定点観測会の取り組み

エウレカでは「パフォーマンス定点観測会」と称してバックエンドエンジニアとSREが週次でメトリクスを確認し,システムの品質観測と改善を行っています. この会を2年間ほど継続する中で,溜まってきた知見を紹介します.
https://sre-lounge.connpass.com/event/151290/

Transcript

1. パフォーマンス定点観測会の取り組み Daichi Harada from eureka, Inc.
 2019.10.29 / SRE Lounge #11

2. DAICHI HARADA - @kai_ten_sushi / @dharada1 - SRE at eureka, Inc. - 2018 年新卒入社 - 好き - Terraform / AWS / Datadog / Go - 勉強中 - Kubernetes / Fastly / Go
3. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
4. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
5. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
6. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
7. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
8. eureka, Inc. - 事業 - Pairs ( 日本 / 台湾 / 韓国 ) - Couples - Pairs エンゲージ ← ❗❗
9. 今日お話しすること - エウレカの「パフォ会」の取り組み - どうやっているのか - なにを見ているのか - やってみてわかったこと - まとめ
10. 「パフォ会」とは？
11. 「パフォ会」とは？ - パフォーマンス定点観測会、通称「パ フォ会」 - プロダクトの可用性・パフォーマンス向 上などを目的とした週次 MTG - 2 年ほど継続、ツールや会議設計を 徐々にブラッシュアップしている https://medium.com/eureka-engineering/performance-mee ting-api-and-sre-3c5e07a6d017
12. 「パフォ会」とは？ - 2 つの MTG を水曜日に連続で実施 - API & SRE パフォーマンス定点観測会 - (15:00 〜 , 30 分 ) - SRE パフォーマンス定点観測会 - (15:30 〜 , 30 分 ) - 参加者 - バックエンドエンジニア、 SRE - 水曜日にやる理由 - サービスの性質から、週末と平日のトラフィックの 傾向が異なる - 水曜なら直近の週末と平日の傾向どちらも確認 できる - 緊急の対応があっても木金で対応可能
13. 「パフォ会」とは？ - ファシリテーターは交代制 - 職責ごとに異なる観点 / 自分ごと化 - メトリクスを 1 週間分確認 - 基本的に Datadog に集約、パフォ会用のダッシュボードを用意している - 基本上から見ていくだけで終わるような設計 - 一部見れないものは、各サービスの管理画面で確認 - 観測結果からタスク抽出 - 同時に走らせていいのは 3 つまでという制限 - 事業上のタスクとの優先度判断が難しい -> 3 タスク分の工数ラインを確保 - 逆に、どうでもいい枝葉の問題に取り組みすぎることも防げている
14. API & SRE Performance Meeting
15. API & SREパフォ会 - 可用性の SLI / SLO - エラーログ - Response time - DB パフォーマンス - toil の棚卸し
16. SLI / SLO - SLI - ( 総リクエスト数 - 5xx 系で返った数 ) / 総リクエスト数 - ≒ 全リクエストのうち正常に返せた割合を評価 - SLO - 99.95 - 直近 1 年ほどは継続して達成し続けている
17. エラーログ - エラーログ件数の推移およびエラーメッセージの内訳 - エラー時にはほぼ 5xx を返すので、 SLI の悪化に直結する - 見慣れないエラーが出始めていないか、急に増えたものがないか確認
18. エンドポイント毎のResponse Time - 特に検索系 GET の主要エンドポイントのパフォーマンス悪化に注視している - 開発が盛んに行われており、パフォーマンスの変動が大きい - 検索は Pairs の肝なので、ユーザー体験に直結する - 集計方法 - BigQuery に溜めた nginx のアクセスログを Lambda で集計 - Datadog のカスタムメトリクスとして送信、可視化している
19. DBパフォーマンス - SQL クエリの質がコストとパフォーマンスに直結している - 悪化の検知 + 改善によるコスト・パフォーマンス向上どちらもしたい - スロークエリ件数推移 / デッドロック件数推移
20. DBパフォーマンス - Aurora の Performance Insights - クエリをグルーピングしてくれて、どの クエリが計算資源を食っているかひと 目でわかる - ( この結果は Datadog に Integration で きない ...)
21. toil - 背景 - API + SRE で Oncall 対応を受け持っ ていて、若干担当分野が違う - ( これだけやや他のアジェンダと毛色 が違う ) - 目的 - うまく toil を減らせないか会話する場 にしている
22. SRE Performance Meeting
23. SREパフォ会 - バジェットとコスト - インフラメトリクス - アラートのトレンド
24. コスト - 従量課金のコスト把握 - AWS/GCP/Akamai/Fastly/Datadog … - 傾向の変化がないか、あれば先週加 えた変更やサービス成長で説明がつ くか？ - クラウドパケ死を防ぐ - バジェット - 予算との Behind/Ahead も今後見てい く ( 予定 .)
25. インフラのメトリクス - 断捨離とキャパシティプランニング - 余っているリソースを断捨離したり、リクエスト傾 向を見て余剰分を積んだり - パフォーマンスの異常検知 - インフラ目線での Deep Dive. - API & SRE で見ている SLI の悪化の原因になるよ うなものはないか？ - e.g. DynamoDB の Throttling が起きていたため先程のパフォ 会で出てた特定のエラーの原因になっていた - コストパフォーマンスは悪化してないか？ - リソースの使用率や、オートスケールした台数を確認 - e.g. とくにリクエスト数は増えていないがピーク時にオートス ケールしたコンテナ台数が増加している
26. アラートの断捨離 - Datadog Triggered Monitors 確認 - 鳴り続けているアラートはないか？ - SSL 証明書の期限切れ監視などもここで - Datadog Monitor Trends 確認 - 鳴ったアラートののトレンド確認できる - どのアラートが何回鳴ったかカウント - 曜日 × 時間帯のヒートマップ - 週毎のアラート件数 - 不要なアラートは断捨離していく https://app.datadoghq.com/monitors/triggered https://app.datadoghq.com/report/monitor
27. わかってきたこと
28. 指標化は本当に大切。 - SLI - SLI からブレイクダウン可能な形で、メトリクスが可視化されてること。 - 「そもそもなにを見るか」が会の参加者全員にわかりやすくなければ、伝わらな い / 意識してもらえない . - KPI Tree のようなものを作ってもいいかも - SLO - 合意された目標に対して behind してるのかどうか一発でわかるようにしておかな いと、会話が水掛け論になってしまう
29. とはいえいったん議題に載せてみるのも大事。 - まずは「定期的に見てみる」アクション化 - あえて指標 / 目標を定めてなかったり、発散するための場にするための 議題もある ( 課題感やナレッジ共有の場として使いたい ) - まずは「見てみる」という行動を継続すると、次のアクションが定まること もある - 最初からパーフェクトでなくていい - 注意：会のシンプルさとのトレードオフ - ただ見てるだけだと先述の通り会話が空中分解しがちなので、バランス は大事 - シンプルにしないと全員には伝わりづらい
30. 目標・会議体を常に見直していく - 課題感が常に変わっている - エラーログを整理したい , SQL の質を上げたい , アラートの断捨離をした い , コストを最適化したい , etc. - 指標化と目標設定、注力する部分の見直しが必要 - 達成できた指標は観測を続けつつ、観測コスト / 注力度を下げていく - 新たな課題に対しては SLI の設定を都度やる - 見直しをした結果、参加者が置いてけぼりにならないよう注意
31. ツールの集約の大事さ - 準備コストは下げたい - 毎週のルーチンなので、準備コストは極限まで下げたい - 生ログをパースしたり、毎回のクエリ実行 / レポート生成があるとつらい - ルーチン作業より本質的な原因特定の作業に時間を使いたい。 - なるべく一箇所にまとまっていると扱いやすい - ( エウレカでは ) Datadog に集約している - 準備時間ほぼゼロ ( ダッシュボードひらくだけ ) - メトリクスを有機的に組み合わせてシューティング可能 - 例外 - がんばって Lambda を書いてカスタムメトリクス送るしかないもの - 有用だけど Datadog に送る術がないもの -> 柔軟に対応
32. まとめ
33. まとめ - エウレカでは週次の「パフォ会」に取り組んでいる - バックエンドエンジニア / SRE で同じ目標を追う - 指標化と行動目標 - 指標化 ... 合意形成と意思決定のための道具 - 行動目標 ... まずは続けていくことが大切 - 注力すべき点は変わっていく - 指標 / 目標、会議体の見直しを継続する - ツールは集約してラクをする - 本質的な仕事に時間を使う
34. まとめ