こんにちは、メルペイSREでEngineering Managerをしている @tjun です。
この記事は Merpay Tech Openness Month 2021 1日目の記事です。
以前SRE NextでSREチームの話をしたのですが、その後の話を発表するちょうどいい場がなかったのでblogとして書くことにしました。チームとしてはまだまだ道半ばですが、この記事がこれからSREチームを作っていく人の参考になったらいいなと思います。

はじめに

SREとは？

SREのあり方は、組織やシステムの規模やアーキテクチャ、扱うサービスによって変わると思います。SRE本はもちろん参考にするのですが、Googleのやり方が自分たちの会社でそのまま上手くいくとは限らないので、根っこの部分の考え方や文化を参考にしながら、実践の方法は自分たちの組織に合わせて適用していく必要があります。

SREって何？インフラエンジニアと何が違うの？という疑問はよく聞かれます。Operationをソフトウェアエンジニアリングで解決すること、という定義もありますが、自分が一番しっくりきたのは、 The SRE I Aspire to Beで紹介されているような、ReliabilityとVelocityのバランスを作る役割、という考え方です。
SREとは名前の通りReliability（信頼性）を作るチームですが、Reliabilityだけを追求するとリリースを取り締まりできるだけリリースをさせないこと、失敗をさせないことがゴールとなってしまいます。しかし、サービスの成功のためには新たな機能を出してお客さまに満足して使ってもらう必要があります。そこで、ReliabilityとVelocityのバランスを組織で決めて、実現を目指すのがSREだと思っています。
そのために、SLO(Service Level Objective=信頼性の目標)やErrorBudgetで目指すべきReliabilityを合意して追いかけたり、ErrorBudgetの消費を抑えるためにIncident ResponseやObservabilityを整えたり、小さく失敗するためにCanary ReleaseやChaos Engineeringのような仕組みがあったり、自動化することでProductivityを高めたり、などさまざまなプラクティスが出てきていて、コードを書くだけでなく組織とのコミュニケーションが求められる役割だと思っています。

信頼性(=Reliability)も一つの機能として考えると、メルペイは金融サービスなので信頼性はとても重要な機能となります。お客さまにサービスを使っていただいてより多くの価値を提供するためにも、信頼性とサービスの成長のバランスを作っていくというのがSREの重要な役割だと考えています。それは同時に、サービスのお客さまの満足度と開発者の満足度を高める役割でもあります。

メルペイSREの運用環境

メルペイのSREチームが運用を行う環境にはいくつか特徴があります。

• マイクロサービスアーキテクチャで60以上のマイクロサービスが存在している。各マイクロサービスは開発者が運用を行い、SREはそのサポートをしたり、共通のインフラの運用を担当している
• Microservices Platformというメルカリグループ共通のMicroservices基盤があり、KubernetesクラスタやCI/CDパイプラインなどはMicroservices Platform Teamが構築・運用を行っている
• メルペイは金融サービスであるため、信頼性はとても重要

そのため、SREだけでサービスを運用しているわけではなく、開発者やMicroservices Platform Teamなどのチームと連携しながら運用を行っています。

チームの立ち上げと変化

自分がSREチームに入ってから、自分やチームがどんなことをやってきたかを簡単に説明します。
ざっくり以下のようなタイムラインになります。

• 2018年4-10月 SREチームのはじまり
  • Microservices Platformへのキャッチアップをしたり、インフラを設計構築したり
  • この頃はチームというよりはSRE個人の集まりという感じで、各メンバーがサービスリリースに必要なことをひたすらやっていました
• 2018年11-2019年3月 メルペイリリース・混乱時代
  • メルペイが2019年2月リリースなので、リリース前にはさまざまな課題が出てきたり、リリース後も落ち着かない状態が続いていた
  • リリース前後でいろいろなトラブルがあり、1.5人くらいでオンコールを回すという辛い時期
• 2019年4-6月 運用が回り始めた
  • 新しく入ったメンバーのキャッチアップが進み、オンコール当番も4人で回せる状態になった
• 2019年後半 チームの拡大 4→7人へ
  • 少しずつドキュメントなども整っていき、チーム感が出てきた
• 2021年8月時点では13人のチーム

このように見てみると、最初はSRE個人が、インフラ（GCP, Kubernetesまわりなど）でサービスリリースに必要なことを手を動かしてやっていたところからスタートし、サービスをリリースしたあとは日々の運用を回しながら、少しずつ組織を拡大し、組織として動けるようになってきました。

チームの進化と拡大

SREチームのメンバーが増え、改善が進むことでチームが以下のように変わっていきました。

運用負荷の軽減

サービスリリース直後はさまざまなオペレーションにおいてSREの作業が必要で、運用負荷が高い状態でした。
その後メンバーが増加したというのもありますが、不要なアラートの削減、オペレーションの自動化・ツール化や、開発者によって実行可能な仕組みの構築などにより、運用負荷をかなり改善することができました。たとえばデータベースに関するSREのオペレーションについては、半年かけて60%程度削減できています。

知識の共有

以前は属人化していた知識も共有が進みました。
ドキュメントを書いていくのももちろん重要です。それに加えてオンコールのシャドウイングのような体制をつくり、すでにオンコールに入っている人が新たに入る人に対して開発者からのリクエスト対応やアラート対応を教えたりペアプロ的に一緒に作業することで、知見の共有が進みました。

また、毎日の朝会ではオンコール当番がDatadogダッシュボードを事前に確認し気になった点を共有してチームで確認したり、Google Docsで管理されたオンコール当番Noteを作成して日々のアラートを記入したり、週1回のチームミーティングでオンコール当番がその週のインシデントを共有したり、さまざまな取り組みによりオンコール当番間の情報共有も進んできました。

Proactiveな活動が増加

メルペイのリリース後しばらくは、開発者からのリクエスト対応やさまざまなオペレーションやアラート・インシデント対応、新機能リリースのサポートなど、目の前の仕事に追われるような短期的な視点のReactiveな活動が多かったです。SREメンバーが増えたこと、またさまざまな自動化や仕組み化によるSREオペレーションの削減、マイクロサービスの品質が上がることによってアラート数が減ったこと、などの要因から未来のためのProactiveな活動ができるようになってきました。例えば、アラート対応をするだけではなく、アラート数を削減するような活動ができたり、データベースの台数を調整するようなオペレーションをする代わりに自動で調整するような仕組みを開発する、などの取り組みが進んでいます。

Embedded SRE

Embedded SREとは、機能開発するチームに入ってチームの一員としてサービスの信頼性に関わる活動をする関わり方です。
Embedded SREを始める前はマイクロサービスを全体的に広く見て活動し、サービス共通の課題を中心に対応する、または開発者から何か要望があった場合はその課題に対して取り組む、という体制でした。
半年前から、一部のSREメンバーは開発チームに対してEmbedded SREとして入っています。開発者とコミュニケーションして各チーム、各マイクロサービスの課題をヒアリングし、開発者だけでは改善が難しかった課題に一緒に取り組む活動を始めています。

このように、以前は日々のオペレーションに追われ目の前の課題に対応するので精一杯でしたが、さまざまな改善が進んだことで今では先のことを考えた動きができるようになってきました。

SREのEngineering Managerとしてやってきたこと

メルペイにおけるEngineering Manager（以下EM）の役割は、 Merpay Tech Openness Month 2021 の明日(9/2)の記事でyoichiさんが書いてくれることになっているので、ぜひ読んでいただけたらと思います。
前章までで紹介してきたチームの変化の中で、自分のSREのEMとしての動きも変わってきました。チームが4人以下の時代は、95%の時間はSREのプレイヤーあるいはTech Leadのような仕事をしていました。サービスのリリースに向けた作業やリリース初期の運用でやることがいっぱいあり、それらの優先度を決めて率先して動くような役割を行っていました。その後はチームの拡大とともに少しずつ役割が変わり権限移譲も進んでいき、この記事が出ている2021年9月1日時点ではSREチームのEMも3人に増えて、今はマネージャーのマネージャーとしての役割も担当しています。

メルペイにおけるSREのEMは、SREチームのEMとしての役割に加えてメルペイ全体のサービス運用を設計して実行していく役割も持っています。特にサービスリリースするまでにどのようなことに関わってきたか、思い出してみると以下のようなものがありました。

オンコール制度の設計

メルペイはマイクロサービスアーキテクチャを採用していて、今では60以上のマイクロサービスから構成されています。エンジニアのチームが複数のマイクロサービスの開発と運用を担当しているため、オンコール当番としてアラートを受けるのはSREだけではありません。そのため、組織としてどのような体制で、どのようなルールのもとオンコールを行うのか、決める必要がありました。
例えば、当番は1週間のローテーションにする、最低3人以上で回すようにする、週末や深夜に対応したらどうなるか、など人事や労務とも相談しながら制度を決めるということをやりました。また、オンコール体制を考える上で How we do on-call at Monzo などの記事を参考にして、開発者とSREがどのような協力体制でオンコールを回すか検討・設計しました。

インシデント対応フローの整備

オンコール当番となったSREや開発者がアラートを受けたときに原因や影響範囲を調査するのですが、お客さまへの影響がある程度大きい場合にはインシデントとして対応して、お客さまへの案内を出したり、パートナーの事業者さまへ連絡する必要が出てきます。
そこで、どの程度の影響が出た場合にインシデントとして扱いエスカレーションするのか、基準やエスカレーション方法、インシデントレポートのテンプレートを決めました。

SLO(Service Level Objective)の布教

金融サービスとして信頼性を追求すること、一方でスマホ決済サービスとして利用していただくためのさまざまな機能を提供・追加していくことを両立させるためには、それらのバランスを考える必要があります。どのような場合にアラートを鳴らして対応するのか、それとも許容するのか、基準が必要となります。
そのために、SLOという考え方をSRE以外の開発者やPM(Product Manager)にも知ってもらって、各マイクロサービスでSLOを決めていく必要があると考えました。自分たちでドキュメントを書いたり社内の全体集会で発表したりなどの布教活動を行い、ある程度理解してもらえたのかなと思います。

リリース・運用ルールの策定

安全にサービスをリリース・運用するために、いくつかのルールを決めています。
例えば、リリースしていいのは月曜から木曜日の夕方18時まで、とか、エンジニアが１人でリリースできないようにするためにリリース時にはマネージャーの承認が必要、などのルールを定めています。
運用においてもある程度のルールが必要で、例えば本番データベースに対するアクセスについては、クエリレビューが必須となる運用ツールを使ったり、SREにおいても普段は権限を持っておらず必要に応じて権限を承認してもらって作業するためのツールを使ったり、などの制限をしています。

参考:

• Spanner にクエリをレビューして実行する gchammer | メルカリエンジニアリング
• 権限をQray -SREへの一時的な本番環境権限付与のしくみ- | メルカリエンジニアリング

SREチームの今後について

これまで説明したようにメルペイのSREチームは少しずつ改善が進んではいますが、今後もまだまだチャレンジしたいことがあります。メルペイを利用するお客さまに金融サービスとしての高い信頼性を提供し続ける、そして開発者とSREが協力して健全に運用でき、新機能の開発に集中できる世界を目指しています。

今後の活動として考えている方向性としては例えば以下のようなものがあります。

1. Reliable and scalable Infrastructure

   • クラウドや外部システムの障害・リクエストの急増などの外部要因にも堅牢なサービスインフラの提供
   • 金融サービスとしての信頼性を提供するインフラ

2. Develop microservices reliability

   • Embedded SREとしてマイクロサービスの信頼性を高めるためのさまざまな活動を増やす
   • Make SLO Actionable: SLOを基準とした運用の標準化
   • Production-ready guardrail:マイクロサービスをリリースする前に高い信頼性になるような仕組みを作る

3. Improve developer productivity

   • Make OnCall Healthy: オンコールが簡単になり、より少ない負担で運用できるようにする
   • Learn from Incidents: 常に障害から学習・改善しつづけることで、同じ障害を繰り返さない
   • Operation automation: 運用を可能な限り自動化・コード化していく

今まで以上にSREとしてプロジェクトを持ち、設計・実装しながら信頼性と生産性を改善していきたいと考えています。
また、暗号資産やブロックチェーンに関するサービスの企画・開発を行うことを目的に、メルカリの子会社として2021年4月に株式会社メルコインが設立されましたが、メルペイSREの一部のメンバーはメルコインを現在担当して、インフラの検討・設計を行っています。

引き続き高い信頼性が求められる分野で、メルペイ・メルコインSREとしてサービスや組織に貢献していくためには、チームを大きくしていく必要があります。
メルペイ・メルコインSREのメンバー、マネージャーどちらも採用中ですので、興味がある人はご連絡ください。この記事の下部に採用ページへのリンクがあります。

そして、直前のアナウンスにはなりますが、明日2021/9/2にメルカリのSREと合同で、最近の取り組みを紹介するオンラインイベントを開催します。ぜひご参加ください、質問も大歓迎です。

• mercari / merpay SRE Tech Talk – connpass

また、Merpay Tech Openness Month 2021では引き続きメルペイの技術やエンジニア組織に関する発信を行っていきます。明日は 「メルペイEngineering Managerの役割」by yoichi になります。よろしくおねがいします。

メルペイ・メルコインSREで採用中のポジション

• Engineering Manager, Site Reliability [Mercoin / Merpay]
• Software Engineer, Site Reliability [Mercoin / Merpay]

この記事を書くにあたり参考にした記事や動画

• How to Build Your SRE Team
• Building and Scaling Your SRE Team | PagerDuty
• The Many Shapes of Site Reliability Engineering | by Rob Cummings | Slalom Build | Medium
• The SRE I Aspire to Be
• Scaling SRE Organizations: The Journey from 1 to Many Teams | USENIX