Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Daichi Harada
October 29, 2019

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

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

Daichi Harada

October 29, 2019
Tweet

More Decks by Daichi Harada

Other Decks in Technology

Transcript

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

    2019.10.29 / SRE Lounge #11


    View full-size slide

  2. DAICHI HARADA
    - @kai_ten_sushi / @dharada1
    - SRE at eureka, Inc.
    - 2018
    年新卒入社
    -
    好き
    - Terraform / AWS / Datadog / Go
    -
    勉強中
    - Kubernetes / Fastly / Go

    View full-size slide

  3. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  4. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  5. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  6. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  7. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  8. eureka, Inc.
    -
    事業
    - Pairs (
    日本
    /
    台湾
    /
    韓国
    )
    - Couples
    - Pairs
    エンゲージ ← ❗❗

    View full-size slide

  9. 今日お話しすること
    -
    エウレカの「パフォ会」の取り組み
    -
    どうやっているのか
    -
    なにを見ているのか
    -
    やってみてわかったこと
    -
    まとめ

    View full-size slide

  10. 「パフォ会」とは?

    View full-size slide

  11. 「パフォ会」とは?
    -
    パフォーマンス定点観測会、通称「パ
    フォ会」
    -
    プロダクトの可用性・パフォーマンス向
    上などを目的とした週次
    MTG
    - 2
    年ほど継続、ツールや会議設計を
    徐々にブラッシュアップしている
    https://medium.com/eureka-engineering/performance-mee
    ting-api-and-sre-3c5e07a6d017

    View full-size slide

  12. 「パフォ会」とは?
    - 2
    つの
    MTG
    を水曜日に連続で実施
    - API & SRE
    パフォーマンス定点観測会
    - (15:00

    , 30

    )
    - SRE
    パフォーマンス定点観測会
    - (15:30

    , 30

    )
    -
    参加者
    - バックエンドエンジニア、
    SRE
    -
    水曜日にやる理由
    -
    サービスの性質から、週末と平日のトラフィックの
    傾向が異なる
    -
    水曜なら直近の週末と平日の傾向どちらも確認
    できる
    -
    緊急の対応があっても木金で対応可能

    View full-size slide

  13. 「パフォ会」とは?
    -
    ファシリテーターは交代制
    -
    職責ごとに異なる観点
    /
    自分ごと化
    -
    メトリクスを
    1
    週間分確認
    -
    基本的に
    Datadog
    に集約、パフォ会用のダッシュボードを用意している
    -
    基本上から見ていくだけで終わるような設計
    -
    一部見れないものは、各サービスの管理画面で確認
    -
    観測結果からタスク抽出
    -
    同時に走らせていいのは
    3
    つまでという制限
    -
    事業上のタスクとの優先度判断が難しい
    -> 3
    タスク分の工数ラインを確保
    -
    逆に、どうでもいい枝葉の問題に取り組みすぎることも防げている

    View full-size slide

  14. API & SRE Performance Meeting

    View full-size slide

  15. API & SREパフォ会
    -
    可用性の
    SLI / SLO
    -
    エラーログ
    - Response time
    - DB
    パフォーマンス
    - toil
    の棚卸し

    View full-size slide

  16. SLI / SLO
    - SLI
    - (
    総リクエスト数
    - 5xx
    系で返った数
    ) /
    総リクエスト数
    -
    ≒ 全リクエストのうち正常に返せた割合を評価
    - SLO
    - 99.95
    -
    直近
    1
    年ほどは継続して達成し続けている

    View full-size slide

  17. エラーログ
    -
    エラーログ件数の推移およびエラーメッセージの内訳
    -
    エラー時にはほぼ
    5xx
    を返すので、
    SLI
    の悪化に直結する
    -
    見慣れないエラーが出始めていないか、急に増えたものがないか確認

    View full-size slide

  18. エンドポイント毎のResponse Time
    -
    特に検索系
    GET
    の主要エンドポイントのパフォーマンス悪化に注視している
    -
    開発が盛んに行われており、パフォーマンスの変動が大きい
    -
    検索は
    Pairs
    の肝なので、ユーザー体験に直結する
    -
    集計方法
    - BigQuery
    に溜めた
    nginx
    のアクセスログを
    Lambda
    で集計
    - Datadog
    のカスタムメトリクスとして送信、可視化している

    View full-size slide

  19. DBパフォーマンス
    - SQL
    クエリの質がコストとパフォーマンスに直結している
    -
    悪化の検知
    +
    改善によるコスト・パフォーマンス向上どちらもしたい
    -
    スロークエリ件数推移
    /
    デッドロック件数推移

    View full-size slide

  20. DBパフォーマンス
    - Aurora

    Performance Insights
    -
    クエリをグルーピングしてくれて、どの
    クエリが計算資源を食っているかひと
    目でわかる
    - (
    この結果は
    Datadog

    Integration

    きない
    ...)

    View full-size slide

  21. toil
    -
    背景
    - API + SRE

    Oncall
    対応を受け持っ
    ていて、若干担当分野が違う
    - (
    これだけやや他のアジェンダと毛色
    が違う
    )
    -
    目的
    -
    うまく
    toil
    を減らせないか会話する場
    にしている

    View full-size slide

  22. SRE Performance Meeting

    View full-size slide

  23. SREパフォ会
    -
    バジェットとコスト
    -
    インフラメトリクス
    -
    アラートのトレンド

    View full-size slide

  24. コスト
    -
    従量課金のコスト把握
    - AWS/GCP/Akamai/Fastly/Datadog …
    -
    傾向の変化がないか、あれば先週加
    えた変更やサービス成長で説明がつ
    くか?
    -
    クラウドパケ死を防ぐ
    -
    バジェット
    -
    予算との
    Behind/Ahead
    も今後見てい

    (
    予定
    .)

    View full-size slide

  25. インフラのメトリクス
    -
    断捨離とキャパシティプランニング
    -
    余っているリソースを断捨離したり、リクエスト傾
    向を見て余剰分を積んだり
    -
    パフォーマンスの異常検知
    -
    インフラ目線での
    Deep Dive.
    - API & SRE
    で見ている
    SLI
    の悪化の原因になるよ
    うなものはないか?
    - e.g. DynamoDB

    Throttling
    が起きていたため先程のパフォ
    会で出てた特定のエラーの原因になっていた
    -
    コストパフォーマンスは悪化してないか?
    -
    リソースの使用率や、オートスケールした台数を確認
    - e.g.
    とくにリクエスト数は増えていないがピーク時にオートス
    ケールしたコンテナ台数が増加している

    View full-size slide

  26. アラートの断捨離
    - Datadog Triggered Monitors
    確認
    -
    鳴り続けているアラートはないか?
    - SSL
    証明書の期限切れ監視などもここで
    - Datadog Monitor Trends
    確認
    -
    鳴ったアラートののトレンド確認できる
    -
    どのアラートが何回鳴ったかカウント
    -
    曜日
    ×
    時間帯のヒートマップ
    -
    週毎のアラート件数
    -
    不要なアラートは断捨離していく
    https://app.datadoghq.com/monitors/triggered
    https://app.datadoghq.com/report/monitor

    View full-size slide

  27. わかってきたこと

    View full-size slide

  28. 指標化は本当に大切。
    - SLI
    - SLI
    からブレイクダウン可能な形で、メトリクスが可視化されてること。
    -
    「そもそもなにを見るか」が会の参加者全員にわかりやすくなければ、伝わらな

    /
    意識してもらえない
    .
    - KPI Tree
    のようなものを作ってもいいかも
    - SLO
    -
    合意された目標に対して
    behind
    してるのかどうか一発でわかるようにしておかな
    いと、会話が水掛け論になってしまう

    View full-size slide

  29. とはいえいったん議題に載せてみるのも大事。
    -
    まずは「定期的に見てみる」アクション化
    -
    あえて指標
    /
    目標を定めてなかったり、発散するための場にするための
    議題もある
    (
    課題感やナレッジ共有の場として使いたい
    )
    -
    まずは「見てみる」という行動を継続すると、次のアクションが定まること
    もある
    -
    最初からパーフェクトでなくていい
    -
    注意:会のシンプルさとのトレードオフ
    -
    ただ見てるだけだと先述の通り会話が空中分解しがちなので、バランス
    は大事
    -
    シンプルにしないと全員には伝わりづらい

    View full-size slide

  30. 目標・会議体を常に見直していく
    -
    課題感が常に変わっている
    -
    エラーログを整理したい
    , SQL
    の質を上げたい
    ,
    アラートの断捨離をした

    ,
    コストを最適化したい
    , etc.
    -
    指標化と目標設定、注力する部分の見直しが必要
    -
    達成できた指標は観測を続けつつ、観測コスト
    /
    注力度を下げていく
    -
    新たな課題に対しては
    SLI
    の設定を都度やる
    -
    見直しをした結果、参加者が置いてけぼりにならないよう注意

    View full-size slide

  31. ツールの集約の大事さ
    -
    準備コストは下げたい
    -
    毎週のルーチンなので、準備コストは極限まで下げたい
    -
    生ログをパースしたり、毎回のクエリ実行
    /
    レポート生成があるとつらい
    -
    ルーチン作業より本質的な原因特定の作業に時間を使いたい。
    -
    なるべく一箇所にまとまっていると扱いやすい
    - (
    エウレカでは
    ) Datadog
    に集約している
    -
    準備時間ほぼゼロ
    (
    ダッシュボードひらくだけ
    )
    -
    メトリクスを有機的に組み合わせてシューティング可能
    -
    例外
    -
    がんばって
    Lambda
    を書いてカスタムメトリクス送るしかないもの
    -
    有用だけど
    Datadog
    に送る術がないもの
    ->
    柔軟に対応

    View full-size slide

  32. まとめ
    -
    エウレカでは週次の「パフォ会」に取り組んでいる
    -
    バックエンドエンジニア
    / SRE
    で同じ目標を追う
    -
    指標化と行動目標
    -
    指標化
    ...
    合意形成と意思決定のための道具
    -
    行動目標
    ...
    まずは続けていくことが大切
    -
    注力すべき点は変わっていく
    -
    指標
    /
    目標、会議体の見直しを継続する
    -
    ツールは集約してラクをする
    -
    本質的な仕事に時間を使う

    View full-size slide