オンラインデーティングサービス「Pairs」を支えるSREチームの秘密

こんにちは!エウレカのSREチーム責任者の恩田です。

今回は、利用率No.1*のオンラインデーティングサービスである「Pairs」のセキュリティやインフラを支えるSREチームのことを、みなさんにもっと広く知っていただくために、私自らご紹介していきたいと思います。

*恋活・婚活マッチングアプリの利用状況調査結果より

今回の記事では、SREチームのミッションや戦略、そして去年1年間で行ってきたチーム開発プロセス改善についてご紹介します。

SREの存在意義

エウレカのSREチームは、ミッションを「会社の目指すビジネスの実現の阻害確立を上げる要因を全て排除する事」と定義しています。このミッションを実現するために、我々は以下6つの戦略をもとに日々行動しています。

1:99.95%の可用性を目標においた事業機会損失の最小化
2:ブランドイメージ失墜につながるクリティカルなセキュリティ/プライバシーリスクの撲滅
3:自己修復可能なインフラ基盤、および運用の自動化による少数精鋭での運用体制の確立
4:定期的なキャパシティプランニングに基づく予算管理と利益率向上への寄与
5:顧客価値提供を最速化するリリースエコシステムの改善と安定化
6:適切なデータマネジメントを支える分析基盤の構築、運用による事業意思決定の最大合理化

2018年5月の時点で、SREチームは6名のエンジニアで編成されています。

開発プロセスの課題

技術的なカバー領域の広さと他チームからの依頼の多さも相まって、SREチームは常に部門間の優先度判断を迫られる立場にあります。

例を上げると、「(Global Dev)メッセージ画面なんか表示遅くね?」、「(Finance)サーバコストを去年比で2%下げてほしい」、「(SRE)最近なんか新しいエラーで始めたな… 」、「(BI)分析ログが欠損しているから直してほしい」、「(Native Dev)PUSH配信今より早くできない?」、「(Japan Dev) rollback用のslackインタフェースつくってよ」「(Board)ねえそういえば他社でこんな情報漏洩あったけど、うち大丈夫?」、「(CXO)ねえねえ○○やりたいんだけど」 、「(QA)ステージング環境のデータだとキャンペーン開催検証しづらいからなんとかして」etc.

上記は一例ですが、日々自他チームから噴出するさまざまな課題に対して、明確な意思決定の基準が存在しない状態でした。このような状態が続き、以下のような課題が発生していました。

  • 優先度に関する議論が毎日発生し、議論が発散
  • 選択と集中ができておらず、マルチタスクによるエンジニアの生産性が悪化
  • 技術負債の定義と改善が行われず、ビジネス拡大に運用工数が比例
  • 定量指標に基づく優先度判断がされておらず、正しい方向に向かっているかわからない
  • 他チームに説明責任を果たしておらず、SREチーム自体がセクショナリズムを引き起こしている

このように、優先度判断と意思決定に関するプロセスが整っておらず、改善が急務でした。なぜ優先度判断の精度ではなくプロセスに特に危機感を感じたかというと、「横断チームはその振る舞いひとつでセクショナリズムを増長し、開発組織全体の流れを悪化させうるから」と考えていたためです。

すべての課題を馬力で全部かたっぱしから、もひとつの考え方です。しかし、現実にはビジネス課題は会社を運営している限り無限に増え、かつその量が工数を上回ることは絶対にありえません。

何かを優先するためには、何かを犠牲(今やらないという意思決定)にしなければいけません。そして、これら一つひとつにポジティブな説明責任を果たすこと(「やれない」ではなく、「いつやれるのか」、「なぜ今対応すべきじゃないのか」、「何と天秤にかけた結果判断なのか」)が求められていました。

なにより、貴重なエンジニアリソースを「重要ではない課題」の解決にかける余裕はありません。常に全体最適な意思決定のもと、最小工数で最大効果を出し続けること。そして、それを持続可能な状態にすることを理想として、開発プロセス改善に着手しました。

意思決定における戦略

全体最適な意思決定を行い、かつ高い生産性を両立するチームと開発プロセスを設計するために、まず以下6つの指針を定めました。

1:意思決定の場を統一し、迅速かつ最小工数で最善の意思決定を行えるようにする
2:課題抽出のプロセスを構築し、全課題をプロダクトバックログ上で可視化する
3:数字による意思決定を是とし、それを実現する定量化基盤を整える
4:課題の対応状況の透明化を行い、工数配分の説明責任を果たす
5:ROIで優先度を比較できない施策は、四半期ごとにロードマップとして定義して一定工数を確保する
6:技術戦略を超えて事業戦略から判断すべきものは、事業戦略を優先とする

SREチームバックログで可視化されるべきビジネス課題は、以下6つに紐づくものとして定義しました。

1:可用性
2:パフォーマンス
3:セキュリティ
4:運用負荷
5:コスト最適化
6:事業施策に紐づくもの

このうち、1〜5を自チームの開発プロセス内で抽出する仕組みを整えました。これと事業施策タスクをマージしたSREバックログを構築し、これらを逐次優先度判断の土俵にのせ、各開発スプリントで開発メンバーがそのタスクに集中できる体制にしました。

では次に、バックログに載せるビジネス課題を抽出するための仕組みを紹介します。

可用性とパフォーマンスの課題抽出

SLI(サービスレベル指標)としてAggregated Availability(Successful request/total request)を採用し、これらの時間推移を可視化しました。この値を週一のチームミーティングで定点観測しています。

現在、チーム目標をSLO99.95%と設定しており、日々トレンドの観測を行っています。また、アプリケーションエラーはDevチームと協働で前週比の確認を行っています。SLOの低下や顕著なエラー増加が見られた場合、ステータスを記載して調査&対応タスクとしてバックログに積みます。

また、サービスのレイテンシも同時に可視化しています。しかし、レイテンシは目標設定が難しく、形骸化すると考え、あえてサービスレベル目標は設定せず、トレンドの把握のみを行っています(顕著なLatency悪化などの異常検知はMackerelのアラートで検知しています)。

傾向として悪化が見られれば、調査 + 対応タスクをバックログに積みます。技術的には、Fluentd x StackDriver x CloudPubSubで集めたnginxログをJupyterでレポート化しています。

*れらのレポートは、Bigqueryに集約した各種ログをGoogle CloudDatalabを利用して整形し作成しています。また、このレポートは社員のみ閲覧環境な形でホスティングすることで、全社員が見れるようにしています。

*余談ですが、我々のアーキテクチャはAWSのベストプラクティスにズブズブに乗っかった形で構築しており、乱暴な言い方をすれば「金で殴れば可用性を買える」アーキテクチャを是として設計をしています。サチュエーションでパフォーマンスが悪化した際に、迅速な退路が常に確保されていることを正義として、最悪コスト投下で逃げれる体制を全サービス環境において整えています。

コストの課題抽出

AWS, GCP, CDNなどのコストの推移を日次で把握できる体制を整え、かつそれを週一のチームミーティングで定点観測します。

具体的には、予算に対するBehind/Ahead、トラフィック増起因以外のコスト増があるか、もしあれば、ドリルダウンして意図したものかをチェックします。最後に、対応が必要と判断したらバックログにチケットを作成します。

例)GCP関連コストのレポート・イメージ

また、これらレポートをベースにFinanceメンバーへコストレポーティングを逐次行っており、情報の透明化と予算に対するBehindがあれば状況の透明化を図っています。

*技術的にはAWSのコストエクスプローラのレポート整理したり、redashでGCP可視化してるだけで大したことはやってません。

セキュリティ・プライバシー関連の課題抽出

新たに発見された脆弱性のレポートと、対応必要性の有無を検討するミーティングを週次で行っています。具体的には、1:AWS Inspectorで検知した脆弱性、2:メンバーからの「これやばいんじゃね?」的なエスカレーション(法令遵守等やその他プラットフォームリスクなど)を事前に議事録として作成、ミーティングにおいて対応可否判断とバックログチケット作成を行っています。

Inspectorはタグでフラグを立てたインスタンスに対して、lambda経由で定期実行する仕組みになっており、本番環境含め毎日実行&レポートを作成しています。Inspectorで前週〜今週にかけ検知されたリスクは、セキュリティレポート担当がミーティングまでに対応必要有無のジャッジと、判断材料を事前に用意してミーティングに臨むことで時間を圧縮しています。

*Inspectorのレポート・イメージ

また、チーム外向けの指標としては、エウレカが参画しているMatchグループ全体で利用しているリスクアセスメント方式による可視化を行なっており、これをもとにチーム外向けのレポートと啓蒙、およびチーム状況の説明をおこなっています。

*リスクアセスメント図・イメージ

運用負荷の課題抽出

チームの生産性をテーマにした振り返りをKPT法で2週間に一度行っており、運用負荷課題と対応方針を洗い出します。また、ここで抽出する課題は「1週間以内に必ず終わらせられるものをひとつ」をルールとし、振り返りごとに抽出した課題は必ずその次の振り返りまでに解消できるよう工数を確保します。

また、ちょっとしたコツですが、必ず最初に「この2週間に起きた事実」をまず全員で書き出し、それに紐づける形でKeep(チームとして文化にしたいこと)、Problem(課題)を抽出しています。

*振り返り・イメージ

意思決定サイクルと選択と集中

これまで紹介してきた仕組みによって抽出された課題と事業施策がチケットとして起票されたチームバックログをもとに、週1回の意思決定ミーティングで対応優先度を決定します。また、1週間はその優先度に従い各自がタスクを完遂することに全力を向けてもらい、差し込みを許容しないことで生産性を上げるよう工夫しています。

また、スプリントの最後に成果物レビューの場を設定し、ビジネス課題の解決が行われているか成果物ベースで確認するサイクルを回すようにしました。

*障害の一次対応などは例外。ただし、恒久対応は必ずチームバックログにいれ、SLOを元に他タスクと常に天秤にかけて優先度を判断しています。

このミーティングの意思決定内容とそのプロセス(判断に至るまでの議論内容)を議事録として残すことで、なぜ今案件Aをやり案件B、Cを次週に回すのか、といった背景を全て透明化しています。

また、ROIやSLOで判断できないセキュリティ対応などは、四半期ごとのロードマップとして大枠の対応スケジュールを定義&常にチームにおいて一定工数を割り当てることを担保しています(*情報セキュリティ/プライバシー対応はエウレカとして最重要の経営課題と認識しており、上記のように短期的利益にとらわれず優先的に対応する体制をとっています)。

おわりに

今回は、SREチームのミッションや戦略、そして去年1年間でおこなってきたチーム開発プロセス改善について紹介しました。次回は、SREチームが目指すシステムの理想形、それを実現する設計思想と具体例についてお話します。


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

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

また、間もなく2018年度のサマーインターン生の募集も開始します!

こちらも併せて、たくさんのご応募をお待ちしております!


Instagramはじめました**

株式会社エウレカ's job postings
Anonymous
21558966 1423784621062239 3551026260573168269 n
C295017e a900 4f0e 872a 216348c31683
23032622 1552731781460376 5352242146880661191 n
6a68192d 4f93 4bad 921b 900f08ef2a08?1557111891
2bc46d73 9f1d 49c0 9e16 1bc2cb6ff236?1555392716
6 Likes
Anonymous
21558966 1423784621062239 3551026260573168269 n
C295017e a900 4f0e 872a 216348c31683
23032622 1552731781460376 5352242146880661191 n
6a68192d 4f93 4bad 921b 900f08ef2a08?1557111891
2bc46d73 9f1d 49c0 9e16 1bc2cb6ff236?1555392716
6 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more

Page top icon