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