SLI向上のためにパフォーマンス定点観測会をやってきた話
この記事は eureka Advent Calendar 2018 21日目の記事です。
eureka SREチームの原田です。この記事ではPairsのSLI向上のためSREチームとAPIチームで週次で開催している「パフォーマンス定点観測会」について紹介したいと思います!
なぜやっているのか
eurekaのSREチームではチーム戦略の一つとして「99.95%の可用性を目標に、事業的な機会損失の最小化をめざす」を掲げており、これの実現のためにパフォーマンス観測MTGをはじめました。 ( チーム戦略の詳細は、こちらの記事を御覧ください! オンラインデーティングサービス「Pairs」を支えるSREチームの秘密 )
またSREチームだけではどうしても実装の中身がわからずに適切なアクションが取れない、ということが多かったので、APIチームも巻き込んだ会議体になりました。
どうやっているのか
ツール
- BigQueryに集約してある各種ログを、Google CloudDatalabを利用して整形、週次でレポート生成、S3+CloudFrontでホスティング
- レポートだけではできないアドホックな調査は BigQuery, Redash, Datadogなどを利用
- レスポンスのステータスコード件数を用いて SLI (サービスレベル指標) を設定し、 SLO (サービスレベル目標) を 99.95 % とする
会議の回し方
- 週1回、APIチーム + SREチーム 10数名でのミーティング
- 3チームにわかれてレポートを確認、考察、タスク候補洗い出し
- 最後に集まって出た問題を共有、優先度付けTODOをだす
3チームに分かれているのは、並列にしたほうが時間節約できる、人数少ないほうが手を動かしたり自発的にやりやすくなる、という理由から始まりました。
なにを見ているのか
日台韓Pairsおよびマイクロサービス群について、以下の項目をそれぞれ見ています。
SLI (nginx log)
SLI = (1-[499/500/502/503/504の総数]/リクエスト総数)
何はともあれSLO (サービスレベル目標) の99.95を達成できているかを確認します。その後、どこかの時点からSLIが下がったままになっていないか(だいたい何らかのデプロイ起因)、極端なスパイクがあるか(だいたいインフラ起因)も確認します。
5xx系ステータスカウント (nginx log)
SLIを掘り下げてステータス別に見ていきます。また5xx/499の内訳がどのエンドポイントから出ているかも見ます。
エンドポイント別 Resptime / Size / Count (nginx log)
前週および四半期の平均と比較して悪化していないかを、前週比でソートして見ています。当初はResptime,Size,Countの値でソートしていたのですが、異常検知という意味合いでは過去との比率を見るようになりました。
よくあるパターンとしては、特定のエンドポイントで全体のトレンドより極端にResptimeが上がっている (リリース起因のことが多い)、件数が極端に上がっている (クライアント側の実装が変わって不必要に叩きすぎている) 等が検知できています。
アプリケーション/バッチタスクのエラー (error log)
エラーの件数、前週比を見ています。ここが一番エラーつぶしというわかりやすいアクションに結びつきやすいです。これまでなかった新しいエラー、定常的に出ているエラーを件数多いものから対応していきます。単純に件数だけでなく、ユーザーへの影響度合いも意識します。(例. 決済、登録などのエンドポイントは他より優先的に対応する)
結果と学び
SLI99.95の達成
実際にパフォーマンス観測会で抽出したタスクを一年間こなしてきたことで、当初は未達だったSLI99.95を達成できるようになり、現在は99.99以上を維持できています。
共通認識を持てた
デプロイ時にパフォーマンスやエラーを意識する会話がAPIチームのサーバーサイドエンジニアから出るようになったり、またSRE側からこんなエラー出てるよ!という会話をする際に使える共通のツールや認識を持てました。
タスクは3つまで
各チームが新規施策のタスクをメインで持っているなか、パフォ会で抽出し1週間でこなせるタスクは3つが限度でした。 逆に言うと必ず毎週継続してリソースを割くことが担保できており、優先度の会話がなされる (ある意味どうでもいいようなエラーに過剰に時間を使うこともなくなった) のも良いことでした。
おわりに
本記事ではeureka SRE & API Teamのパフォーマンス定点観測会の取り組みについて紹介させていただきました。参考になれば幸いです。