はじめに
こんにちは。ソウゾウでソフトウェアエンジニア (SRE) をやっているnakaです。「メルカリShops [フライング] アドベントカレンダー2022」の3日目を担当します。ソウゾウがサービスの安定性を保つために行っている取り組みを紹介したいと思います。
ソウゾウのオンコール
1日目のソウゾウのMove Fastを支える仕組みにもありますが、ソウゾウのエンジニアは基本的に全員ソフトウェアエンジニアとして働いています。自分の得意領域だけでなく、様々な領域にチャレンジできる環境です。一方で、特定の人に特定の領域だけを任せないことによりチャレンジングな場面も出てきます。その一つが、オンコールです。ソウゾウでは、すでに数十ものマイクロサービスが動いていて、その数は日々増え続けています。オンコールは、この増え続けるマイクロサービスの安定性を担保するとても重要な役割を担っています。
ソウゾウのオンコール体制は、プライマリーとセカンダリーがあり1週間毎に担当メンバーが交代するようになっています。ほとんどのソフトウェアエンジニアがこのローテーションに入っていて、すべてのマイクロサービスをオンコールの対象としています。マイクロサービスは数十もあるので、一度も開発に携わったことがないサービスのアラートも一時対応する必要があります。もちろん、入社していきなりオンコール担当になることはありませんが、それでも自分の番が回ってくるときまでに、すべてのサービスに精通しておくことはほぼ不可能です。
ソウゾウのオンコールの課題
すべてのマイクロサービスに対して第一次対応をプライマリーとセカンダリーの2人で行うので、アラート対応の回数が多いです。アラートの見直しや不要アラートの削減が必要になります。
また、アラートの対応をするときに、自分が詳しくないサービスの問題に直面することが多々あります。この場合、知見を持ったメンバーへ対応をお願いしたり、聞くことになりますが、ローテーションをしていると、同じ事象を別のメンバーが受け、同じ質問を何度も同じメンバーにしてしまうということがあります。
オンコール担当者が、直面している事象が過去に起こったことがあるのかどうか確認するには、過去のやり取りをSlackで検索するくらいしかありませんでした。軽く検索してわからなければ、知っている人に聞いたほうが速く解決できるので、詳しい人に聞きながら解決するという方法に頼ってきました。
しかし、現状のやり方では、オンコール担当の人も知見を持っている人も負荷は減っていきません。マイクロサービスは日に日に増えていくので、オンコールの負荷を軽減していかないといずれ対応がしきれなくなってしまいます。
一方で、過去のやり取りを見てみるととても有用な情報がたくさんあるのに、アラートチャンネルのチャット上でやり取りしているせいで情報が流れてしまい、その有用な情報が有効活用できていないという課題がありました。
オンコール改善に関するSREの取り組み
現在、ソウゾウでは3人のSREメンバーがいますが、直近2四半期では、「全員が主体的にオンコールを行えるような仕組みを作ろう」と活動してきました。
活動の前半では、アラートの粒度を細かくすることで、取りこぼしていた問題を明らかにしたり、無駄なアラートがならないように閾値を調整したり、モニタリングシステム自体の改善を進めることができました。
活動の後半では、アラートが鳴った後の対応を改善していくためのPlaybookの導入に取り組みました。
今回は活動の後半にあたるPlaybookの導入について、より詳細な内容を紹介していきます。
Playbookとは
Playbookとは、インシデントやアラートが起こったときに、自動的に回復できない場合に、どのように対応して影響を軽減するかを教えてくれるドキュメントのことです。
Playbookを作成することで、オンコールに必要となる知見を蓄えることができ、オンコール担当者の後ろ盾になるだけでなく、同様のアラートが鳴るたびに聞かれていたメンバーの負荷軽減にもつながります。
Playbook導入
Playbookをゼロの状態から導入していくために、大まかに以下の3つに導入ステップを分けました。
- Playbookの定義（フォーマット、場所、連携方法）
- 具体的なPlaybookの作成
- ソウゾウ全体への展開
Playbookの定義は、メルカリグループですでに導入しているものを参考にしつつ、ソウゾウで使っている独自のモニタリングツールに連携できるようにしました。
具体的には、Wikiにページを作成して、そのリンクをコードで管理されているモニタリングのロジックの中に埋め込み、アラートメッセージから飛べるようにしました。
モニタリングのコードと一緒にPlaybookを書くのが理想的ではあると考えつつも、導入時はPlaybookを書くことへのハードルを下げるほうが重要だと思い、Reviewなしに作成・編集が自由に行えるWikiを採用しました。
Playbookの中には、以下の8項目があります。
- 緊急度：Critical か Warning
- 影響範囲：誰に対してどんな影響があるか
- 何が起きたか：発生した事象
- なぜそれが起きたか：発生した原因
- 誰に連携するのか：知見を持っている人やチーム
- 調査の仕方：どこの何を見ると詳細の原因を知れるのか
- 影響を軽減するためのアクション：リデプロイやロールバックなど具体的なアクション
- 過去に起きた事例：関連するチケットや過去の対応履歴へのリンク
それぞれの項目は、オンコール担当者が一時対応するために必要な情報となっています。
具体的なPlaybookの作成は、上記のテンプレートに則って、実際に直近起こったアラートの中で人のアクションが必要となるものをピックアップして、いくつか作成しました。例えば、支払いに不整合が発生したことに起因するアラートに関しては、非同期での復旧の仕組みがあるため、後から復旧されたかどうかを確認する方法がPlaybookに載っているので、オンコール担当者がスムーズに対応ができます。
いくつかのPlaybookが揃ったところで、ソウゾウ全体への展開をしました。SREでPlaybookを導入したとしても、Playbookを作成・更新するという文化が根付かなくては、意味がないので、どのようにソウゾウ全体を巻き込んで行けるのかが重要になります。
週一で開催している、エンジニアが全員参加するミーティングで目的と作成の仕方を共有しました。
さらに、アラート対応している場面で、Playbookに残しておくと良さそうなやり取りがあるときには、Playbookにしてもらえるように促してきました。
Playbookの現状と今後
Playbookは導入してまだ1ヶ月ほどではありますが、「Playbook使いました。」や「Playbookがあって助かりました。」という声を何人かから聞けてとても良かったと思います。一方で、Playbookのないアラートは依然として多数をしめているので、今後もPlaybookを作成していく取り組みを継続していきたいと思います。
SREでは、アラートのPlaybookカバレッジを、オンコールの負荷軽減に関する目標の一つに設定しました。そして、Playbook文化を浸透させていくために、オンコールの引き継ぎの際には、オンコール担当中に対応した中で、Playbookにしておいたほうがいいものはありませんかと確認して、大事な対応方法の知見を蓄積できる文化を創り出す後押しをしています。
まとめ
今回は、ソウゾウにおける主体的にオンコールをしていけるようにするための一つの取り組みを紹介しました。
株式会社ソウゾウではメンバーを大募集中です。メルカリShopsの開発やソウゾウに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。
Software Engineer
Software Engineer, Site Reliability
Software Engineer (Internship) – Mercari Group （※新卒採用に応募するにはまずインターンへの参加をお願いしています。）
またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちら の申し込みフォームよりぜひご連絡ください！
