こんにちは、エウレカのSREチームでリーダーをしている山本（@marnie0301）です。今回は、エウレカのSREチームが今までどんなことをしてきたか、どんなチームなのかなどをご紹介できればと思っています。

はじめに

まずはじめに、SREとはサイト・リライアビリティ・エンジニアリングの略称です。SREという言葉の起源は、2003年にGoogle社が発足したチームの取り組みを起点として以降、同社が継続して実践してきたプラクティスの集合とシステム管理・運用におけるアプローチ（役割）です。

SREという概念やプラクティスにおいてとても有名な書籍である「Site Reliability Engineering」には、SREの責務や概念について以下のように説明がなされています。

SREとはソフトウェアエンジニアに運用チームの設計を任せた時にできあがるもので、ソフトウェア開発エンジニアないし、ソフトウェアエンジニアとして十分なスキルを有したエンジニアで構成する事で、複雑なオペレーションの自動化を行い、信頼性とスケーラビリティを保つことを目的としています。

“自動化”という言葉と“信頼性”という言葉は、一見かけ離れているイメージを受けるかもしれませんが、大規模なシステムにおける手作業や繰り返しの単純作業は効率を下げるだけではなく、人的なエラーを誘発することを防ぐことができます。

SREの役割やワークフローは組織の形やプロダクトの形により異なりますが、共通的に責務・関心事は以下であると述べられています。

• サービスの可用性/信頼性の向上・担保
• 開発や運用の効率性を担保するための自動化
• 変更管理
• モニタリング
• 緊急対応とそのオンコール体制の構築
• キャパシティプランニング

エウレカにおけるSREの役割（2016〜2020）

では、ここからは具体的にエウレカにおいてどのようにSREチームが発足したかを交えながら、SREの役割についてご紹介します。

エウレカのSREチームは、2016年に当時のリーダーであった恩田がオライリーの魔導書に出会ったことを起源に、技術基盤チーム（システム全体で横断的に使われる機能やベース部分の開発を担当していたチーム）とインフラチームが融合することで生まれたチームでした。

SREは、最近では日本でもよく求人を見かける人気のある単語なのですが、包含する意味も領域も広いため、概して何をするチームなのか？SREってなんなのか？という部分で混乱しがちです。先に紹介した「Site Reliability Engineering」では、とても参考になるプラクティスや考え方をたくさん紹介してくれていますが、実際に自分の会社にそのまま適用しようとしてもなかなかうまくはいきません。そのままでは上手く機能しないので、エウレカではまずSREチームの役割を定義することからはじめました。

まず、チーム結成時にエウレカにおけるSREチームのミッションと存在意義の定義を行いました。当時のチームの存在意義と課題感は以下のようなものです。

• 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす
• ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する
• 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する
• 適切なキャパシティプランニングを行い、利益率向上へ寄与する
• 顧客価値提供を最速化するためのリリースエコシステムの改善と安定化を行う
• 事業価値最大化にむけた施策の技術サポートを行う

また、システムの評価指標としては、RASISのような指標を設けて、RASISを意識したシステムになっているかということを議論しながらシステムの改善に取り組んできました。

これらを一言でまとめた責務は、「会社の目指すビジネスの実現の阻害確立を上げる要因を全て排除すること」というシンプルで広義なものとなっています。

より詳細にチーム結成当時の課題感や方向性について知りたい方は、過去に恩田が書いた記事を読んでみてください。

エウレカSREチームの取り組みの事例

次に、チーム発足当初から私たちがSREとして行ってきた業務やプロジェクトをご紹介させていただきます。

業務の一例を以下に列挙します。

• SLO/SLIの定義とメトリクス収集による可視化
• 全サービスへのIaCの適用とその継続的な改善（terraform,packer+ansible,dockerfile）
• • eurekaにおけるここ一年のTerraform Component Delivery Processの変化 〜急成長していくProduct基盤のProductivity,Security,Privacyとの向き合い方
  • Pairs Infra 2017
• スケーラビティを確保できるインフラ
• 全面的なVM→コンテナへの移行作業
• サブシステム、関連システムのサーバーレス化、sqs+lambdaを用いた分散処理環境の構築
• • 例：Cloudfront+Lambda@edgeを利用してサーバーレスに画像をリサイズ・変換して返却するCDNを構築したお話
• デプロイパイプラインの整備（ChatOpsにより煩雑な手動作業を代替、サーバーレスコンポーネントによるリリースノート自動作成）
• データベースやアプリケーションサーバーの負荷軽減のためのアプリケーションのコード修正やクエリ/テーブル構造の修正
• 常時上下・一定しないトラフィックに対するスケーラビリティの確保
• Datadogを中心とした外形監視・パフォーマンスモニタリング・APMなどによる可観測性の向上
• アプリケーションエンジニアと共に行うパフォーマンス観測会
• AWS SSO+Okta連携による権限管理のスマート化
• AWSOrganaizationを利用したAWS GuardDuty,AWS Config,AWS CloudTrailなどのセキュリティ検知・監査証跡用のコンポーネントの全アカウントへの導入・整備
• KMSを利用したS3,DynamoDBの暗号化とttlを利用したデータ保存における暗号化とリテンションの仕組みの構築
• GCPにおけるCloudPubSub + CloudDataflowを利用したデータ処理基盤の構築・運用
• 新規インフラ構築業務

etc... とまあ、いっぱいありすぎるのでだれか手伝ってください

運用者はシステムに対する変更をなるべく避けたくなるものですが、エウレカでは、問題検知の仕組み（アラート・モニタリング）を成熟させることやロールバックを容易にする仕組みを用意することで上記のようなダイナミックな修正に日々チャレンジを続けています。

SREの関心ごとである、自動化・SLO/SLIの定義・モニタリング、オブザーバービリティの向上と言ったところを主軸にしつつ、新基盤の構築・実装、GCPを利用したデータのETL基盤の構築などなど、自動化や信頼性に閉じないような様々な業務を行なってきました。

また、プロダクトに対する技術的な取り組みだけでなく、ポストモーテムの文化を組織に醸成するための障害対応のフロー構築やリード、テンプレートの作成や障害チケットを切るだけで自動的に関係者がSlack channelに集められるような仕組みの構築を行なうことで障害時の対応をスムーズにする、といったような取り組みも行っています。

変化していくSREチームの責務やあり方

先のようなスローガンとミッション定義の元、広範囲にわたって暴れ回ってきた私たちですが、課題がないわけではありませんでした。例えば、役割が幅広すぎるがゆえにそれぞれの領域への投資が薄くなってしまう、SREチーム自体に責務が集中しすぎてボトルネックになってしまうなどの、副作用を課題として感じることがしばしば多くなってきました。

そこで今回、SREチームの役割について以下のように再定義をしました。

• どういう価値を企業に提供するのか？の再定義
• リソース配分に一定のポリシーを持つ（後述する50%ルールの採用）
• やらないことの定義
• • 例えば、データ基盤業務はデータ基盤チームが設立したので移譲
  • インフラ構築業務や運用業務の一部は自動化を推進＆他チームへの管理移譲などなど

振り返って、これまでの体制が間違っていたか？というと、そうではありません。むしろ、SREというロールが重要とすることを意識しつつ、役割に囚われすぎずに組織やプロダクトに必要なことが実行できてきたからです。SREが役割という組織的なデザインを含むものである以上、プロダクトのフェーズにより組織の人数やアーキテクチャの形、またSREチーム自体の習熟度によって、まわりのチームとの関わり方や責務の分担、あり方は変わって当たり前と考えています。

例えば、マイクロサービスアーキテクチャを採用している企業であれば、マイクロサービスに属するSRE（ないしSREのようなロール）をチームに内包することと、横断組織としての共通的なルールづくりの支援やツールの提供など役割を明確に分離するようなデザインを採用している企業もありますし、組織の変遷に沿ってSREのあり方を変えていくことはむしろ自然であり、前向きなことです。

今では、もう少し定期的にあり方を振り返っていってもよかったなと捉えています。このあり方や定義も永続的ではなく、半年や1年といった周期で、改善しながら変化させていくものと考えています。

エウレカのSREチームが大事にしていること

ここまではSREの概論と、チームがしてきたことや歩みの部分にフォーカスをしてきましたが、ここからは実際に働いているSREチームメンバーや文化観についてフォーカスしてお話ししていければと思います。

ポストモーテムの文化の醸成

障害が起きてしまった後に、失敗から学ぶことは非常に重要であると考えています。ポストモーテムは、ノウハウや仕組みの共有の場になるとともに、システムの課題点を明らかにするために重要なワークとして、エウレカではテンプレートの用意やフローの整備などについても、SREチームでリードし文化が根付くように率先して行っています。

開発者と共通の目標設定やゴールに向けて歩んでいく重要性

SREチームが一方的に「品質、品質」と述べて、頭上から開発チームに接していては、結局問題は解決しません。エウレカのSREチームでは、パフォーマンス定点観測会の取り組みという仕組みをBack-endチームと共通で運用し、一緒の指標（SLO/SLI）を見て、改善ポイントを探すことや関心ごとを一緒にもてるように心がけてきました。

この仕組みは、2019〜2020年の1年間において毎週実施され、様々な不具合や改善点の抽出に役に立ちました。反面で、どこまで品質に投資し続けるのか？という点については、常々議論が起き、課題がありました。ここで用いていたSLOが、リクエスト全体に対する5xxの割合というものであったため、SLOは達成されているけど、微細なエラーに投資し続けるのは過剰な投資なのでは？といったような議論が生まれたりもしました。

2021年現在は、システムをユーザーが問題なく使えていることを指し示すような重要指標を、新しいSLOに定義し直すことで品質への過剰投資にならないような共通の指標をBack-endチームと一緒に構築していっています。

50%の工数を自発的なシステムの改善と技術的な挑戦にあて、作業計画と提案のロードマップを自分たちで構築する

このワークは、自分たちがSREとしてシステムの信頼性を支える、良くしていくための責任を持つエンジニアであり続けることと、「Site Reliability Engineering」にも記載のある継続的なエンジニアリングへの注力への保証を実際のチームの行動と仕組みとして形にしたものです。

まず、リソースの配分として、50%を外部の依頼への対応（フィーチャーチームに必要なインフラ構築、セキュリティ監査）などと繰り返し発生する運用作業（Toil）として割り振ることにしています。
次に残る50%については、SREチーム全員がシステムの運用者として、自分たちで課題定義を常に行い、ロードマップを自分たちで構築しています。

具体的には、以下のようなワークを行っています。

• SREチームに所属するメンバーは、全員システムの改善点や変更するべき点、あるべき姿などを常時思いつきしだいチケットを起票する
• 起票者はビジネスやプロダクトに対する影響・得られるものを記載する
• チームメンバーで各アイテムを列挙し、得られる利益やリスクに応じて優先順位をつける
• 概算工数からロードマップに組み込む

新しい技術の採用や、全体感が大きすぎて初期提案がつくりづらいなどによって、挑戦や改善の機会を損なうことのないよう思いつきで起票して良いことにしています。
起票時点で正確な工数を出すことが難しい、または利益や実現性が仮説ベースになってしまうようなもの、大きすぎるアイテムについても検証が必要な部分についてチームで話し合い、PoCのスコープを適切に意識して挑戦することの方が重要であると考えているからです。

SREのエッセンスを大事にしつつ、常に変化・改善し続けること

エウレカではSREという役割や原典に必要以上に固執はしませんが、一方で「Site Reliability Engineering 」で述べられているような、魅力的なエンジニア像と大きく複雑な責務に対しても継続的に向き合っていくことを考えています。

上に述べた他の事柄の通り、システムだけでなく、仕組みや自分たちの考え方、チームのあり方も常に変わっていくことが大事だと思っていますし、当たり前のことだと考えていきたいと思っています。

エウレカのSREの魅力① 〜成長し続けるプロダクト〜

せっかくなので、今回はエウレカのSREの魅力についても触れておこうと思います。

エウレカが開発している恋活・婚活マッチングアプリ「Pairs」は、国内トップクラスのシェア・ユーザー数のサービスとして順調な成長を連続していることにより、求められる水準や品質や難易度が上がっていくところが面白いところかなーと、個人的には思います。

2016年頃と比較すると、単純なリクエスト数は数倍以上の量になっていますし、TVメディア露出のような短期でトラフィックがスパイクするようなことも増えていきます。ユーザー数の増加という観点では、億件を軽く超えるようなテーブルもありますので、データ量の問題から再設計や分割・シャーディングなどの検討から、データストアの再選定が必要があるテーブルもあります。

また、「Pairs」は日本・台湾・韓国の3ヶ国に展開していますが、各リージョンにおける機能の再利用や、今後も展開エリアが増える場合などを考えると、一部機能のMicroService化などの推進の検討などもなされていますし、より展開しやすいようなアカウント管理や効率性を損なわないようなインフラ・アプリケーションのデプロイの構築なども課題になってきます。

セキュリティ要件の監査・管理もより重要になってきており、適切な権限設計をしつつ、AWSアカウントの環境別の分離やシステム別の切り出しなども進める必要や、暗号化などの今までとは違うリソースの使用量のある機能も増えてきていたり... などなど、列挙するとキリがないのですが！このように、規模やシステムが拡大していくが故の制約やニーズ（課題）と向き合える機会はなかなかなく、エンジニアとして退屈させてくれない題材をプロダクトが提供し続けてくれる事は魅力のひとつだと考えています。

エウレカのSREの魅力② 〜熱量のあるメンバー〜

そしてもう一つの魅力は、一緒に働くメンバーです。今、企業に必要な価値を提供できているかどうか？という原点を大事にしつつ、今以上に価値を提供するためにSREのエッセンスを活かせないのか？という検討や、技術的なinputを続けられる熱量のあるメンバーが揃っているのも、エウレカの環境の良いところだと個人的には思います。

例えば、こんな感じにふらふらっとチームランチで100ページくらいの本をワイワイ議論しながら読んでみたり...

また、チーム外の交流も盛んなので、AIを専門とするチームやデータ基盤を専門とするチームとも技術的な会話や議論がよくできているのも良いところです。

まとめ & We Are Hiring!

ここまでで、エウレカのここ数年のSREチームの歩みとこれからの取り組みについて紹介させていただきました。

さて、最後にエウレカのSREチームでは現在エンジニアを募集しております！終始真面目な口調で書いてしまいましたが、実際には和気あいあいとカジュアルに楽しく、これらの課題と向き合う集団ですし、エヴァの話で朝会が数分のびたりするファニーなところもありますので、ぜひ本記事を読んでご興味を持っていただけた方は、怖がらずまずは募集要項を確認していただけたらと思います。

カジュアル面談なども歓迎ですので、TwitterなどでDMくださっても大丈夫です :)

＝＝＝
最後までお読みいただき、ありがとうございます。

エウレカのSREチームでは、新たなメンバーを募集しています！私たちと一緒に『Pairs』を、アジアを代表するオンラインデーティングサービスに成長させたいという方は、ぜひエントリーください。

たくさんのご応募、お待ちしております！