技術本部 サービスリライアビリティグループ（SRG）の小沢です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

SRGではリモートワーク中心のメンバーが多いため、組織活性化を目的として、Zoomを使って気になるニュースについての雑談や最近起きた障害の共有、他部署のゲストを呼んで交流などを行う SRG Chatting というイベントを週一で開催しています。今回は、初めての取り組みとして社外の方にゲスト参加していただきました。

きっかけ

チーム内でSRE活動を行う機会も増えてきて、e34.fmのSRE回が話題になったこともあり、より具体的な話が聞きたいと思い、e34.fmのホストで、TopotalのCTOである吉川(@rrreeeyyy)さんにゲストをお願いしました。昔同じ職場で働いていたこともあり、ご快諾いただきました。

SRGチーム以外にも参加希望者がいたため、e34.fm リスナーの方やSREに興味がある方、誰でも参加できる全体の勉強会として開催することになりました。

当日の内容

当日は吉川さんが作ったスライドを見ながらLT形式で話していただき、気になったことがあれば随時、質疑応答を行うスタイルで行いました。
SREのプラクティスは本に書いてあるけど、SREを既存のチームに導入するプラクティスはあまり聞かないので、 どのようにSREという形でチーム内に組み込むのかそのプラクティスを中心に話していただきました。

Embedded SREの取り組み

引用元: https://speakerdeck.com/rrreeeyyy/cookpad-tech-kitchen-service-embedded-sres

リニューアルプロジェクトに参画した際に、 Embedded SREとしてではなく開発の同僚として参画し、具体的には以下のSREのような振る舞いをすることで、 機能開発だけでなくSREのプラクティスも導入していったそうです。

• DesignDocsで設計やパフォーマンスに気をつけて問題になる箇所を洗い出ししてから開発することや、 DesignDocsをサービス目線に立って、どう書くかという文化を根付かせた
• プロジェクト参加時には実現したい機能とUIデザインの大枠は決まっていたので、自分自身のドメイン知識をしっかりつける意味でも、時間をかけてDesignDocsを書いた
• なぜそうするのか、そうしないのかが文章に残っている状態になり、 意思決定の際などに開発メンバーがDesignDocsを見るような文化をつくることができた

Design Docsの書き方

引用元: https://speakerdeck.com/rrreeeyyy/cookpad-tech-kitchen-service-embedded-sres?slide=9

以下について人間の感情を含めて文章に残すことで 優先順位付けの判断材料にもなると言われていたのが印象的でした。

• 何をなぜ作るのか、どのように使われる想定なのか
• アーキテクチャをどうするか、なぜそうするのか
• データストアを何にするのか、何にしないのか
• 古いシステムとの共存をどのように実現するか

また自分自身が事業ドメインを理解するためにもDesign Docsを書くことが重要だと学びました。
Design Docsを書いて広めていくことで社内によりよいDesign Docsが溜まっていく動きもよいと思いました。

負荷試験

引用元: https://speakerdeck.com/rrreeeyyy/cookpad-tech-kitchen-service-embedded-sres?slide=19

本番環境で負荷試験を行うことでしか気づけない問題もあるので本番環境で実施したそうです。
実際に連携先のサービスでキャパシティが足りないという問題を発見できたとのことでした。
実施する上で注意したのはSLOに影響が出ないのを前提とし、影響が出そうになったらすぐに止められるよう状態にしていたそうです。

SLI/SLOの導入

新規サービス開発ということで信頼性の指標を確立するためにSLI/SLOを決める契機となったそうです。

• • 導入の仕方

• • • • エンドポイントレベルで少しずつ導入を進めたところ、3~4くらいのエンドポイントがビジネスに影響することがわかったので、最初は小さなマイクロサービスからはじめていった

• SLI/SLO導入のメリット
  • 開発のリリースへの心理的な負担を下げることに繋がり、 エラーバジェットを守っている限りは、全てのコミットにSREがレビューをしなくても開発者側で自走でき、 SREのレビューがボトルネックにならなくなった

質疑応答

Q.Emebedded SREの動き方やチームへの受け入れられ方はどのように行ったのか
A.はじめはEmbedded SREとして参加したわけではなく、開発者の一人として参加して、 Design Documentを書いて，サービスの信頼性を確認してから開発を進めるといったSREライクな動きをチームメンバーに紹介して浸透させていった。

Q.DesignDocsの更新はいつまで行われるのか
A.サービスのリリースまでは変更があれば更新していた。

Q.SLI/SLOをどのように決めたか
A.プロダクトオーナーと合意を取りつつ直近のエラーレートの傾向から値を決めた。定期的にSLI/SLOを見直して値を修正を行うのが大事。SLI/SLOを元に監視の閾値も見直すためにそのことについても予め合意を取っておくこと。

Q.マイクロサービス、エンドポイントに対してSLI/SLOを決めるか
A.信頼性クラスA,B,Cなど決めて事業影響の高いものに対して導入を決めた。

Q.本番環境での負荷試験でサービス影響が出るかもしれないことで難色を示されたらどう説明するのか
A.負荷試験を実行しても問題ない環境が前提の上、カオスエンジニアリングの話などをして実際にサービス間連携などで問題を洗い出す際には本番環境での実施がよいなどの説明をした。

終わりに

吉川さんのSREを“ちゃんとやる”ための知識や動き方が大変勉強になり、 自分自身も今後はSREやっていくぞ！という気持ちになった充実した会でした。 SREについて話していただきありがとうございました。
SREエンジニアの助けが借りたい方はぜひTopotalさんにご連絡してみてください。