実際に計測をはじめる前に

すべてを計測できることは理想ではありますが、闇雲に計測するだけではどこを改善するべきか見えにくくなってしまいます。

そこで、実際に計測をはじめる前にSREとしてどこに着目するべきなのかをSREチーム内で認識合わせをするためにSRE本読書会を実施しました。

SRE本読書会の実施

SRE本とは SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームの事です。 Google - Site Reliability Engineering で無料で読むこともできます。

全ての章を読む時間は流石になかったので、SLOの設定に必要と思われた1~9章を範囲としました。

また、読書会は『入門監視』社内読書会を開催しました - Misoca開発者ブログと同じ方法で進めました。Scrapboxと読書会の相性は非常に良いです(個人的感想)。

f:id:mizukmb:20190904172719p:plain — SRE本読書会Scrapboxの様子

計測箇所・可視化方法

ある程度読書会が進めたところで、並行してSREチームとして計測する箇所はどこであるか、どのように計測し可視化すればよいかを検討しました。

応答性能・安定性・運用といった様々な観点から、計測可能な数値を洗い出していきました。さらに、そこから今回のSLOに関わるものに絞って可視化を進めることにしました。以下の項目を可視化することに決定しました。

レスポンスタイム
- 50, 90, 95 パーセンタイルでそれぞれ計測する
リクエスト成功率
- リクエスト数もついでに可視化した

その他の項目についても可視化しようというところまでは決定していますが、ここでは一旦優先順位を下げています (例えばコードカバレッジや一日あたりのリリース数等) 。

可視化のためのツールはRedashを使用しています。Redash 自体の詳細な使い方はここでは説明しませんが、ALBのアクセスログをS3に保存してAthenaでクエリ実行したものをRedashでグラフに出すみたいなことをしています。

ちなみに、Redashサーバは自前で建てていて、これは今年の開発合宿の成果物だったりします。

tech.misoca.jp

開発向けSLOの設定

レスポンスタイム・リクエスト成功率について開発向けのSLOを設定しました。開発向けであるので公表はできませんが、既に達成していたりしてなかったりな感じです。

SLOの設定値については厳しすぎない程度に設定しました。SRE本4章で言及されていますが、SLOが厳しすぎるとチームが超人的な努力に走ってしまうリスクを抑えるためです。

さて、無事にSLOを設定することができました。今後はこのSLOと実際の値を見比べながら、SLO達成のためにパフォーマンス改善を優先するのか、あるいはもっと他の問題をエンジニアリングで解決するのかを決めていくことになります。

最後に、SLO設定後のSREチームにおける変化についてお話します。

SLO設定後の変化

SREチームが取り組む問題の優先順位をSLOベースで決めることができるようになりました。また、SLO改善系のプロジェクトにおいては改善前後の効果予測ができるようになり、プロジェクトが目指すべきゴールの解像度が上がりました。

さらに、プロジェクト終了後に他メンバーへの共有の際、「今回のプロジェクトではこの部分の改善に対してXX%の向上が見られた」といった数値ベースの報告ができるようになり、客観的に見てもどのくらい効果があったのかよりわかりやすく見えるようになったかなと思います。

まとめ

SREチームとしてMisocaのパフォーマンス計測を行い、開発向けのSLOを設定しました。結果として、SLOを軸としてタスクの優先順位を決めたり、どのくらい改善できたのかを数値ベースで共有するといったことができるようになりました。SREチームの働きも、他メンバーにより伝わりやすくなったかなと思います。