EurekaのSREチームの実践してきた事と未来像

ある企業における、数年間においてのSREチームの取り組みと紆余曲折の歴史（最前線.....?)
課題感や取り組みがどのように変化していったか などを赤裸々に語っています。

Transcript

1. © 2021 eureka, Inc. All Rights Reserved. EurekaのSREチームの実践してきた 事と未来像 MIDAS TECH STUDY #5 2021年12月21日
2. © 2021 eureka, Inc. All Rights Reserved. About Me masashi.yamamoto (@marnie0301) • 株式会社エウレカ ◦ 2015年に入社 ◦ 2017 機能開発チーム→SREチームに移籍 ◦ 2020~ Head of SRE
3. © 2021 eureka, Inc. All Rights Reserved. 3 恋活・婚活マッチングアプリ オンライン結婚相談所サービス 真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け Pairsは日本で最も使われている恋活・婚活 マッチングアプリ 日本人特有の交際相手探し、恋愛に対する障壁を和らげ るために設計 24時間365日オペレーターが待機し公的身分証明書の 確認、お問い合わせ、パトロール監視に対応 登録からお相手の紹介まで全てスマホで利用可能 プロのコンシェルジュチームによる24時間サポート 毎月20名(紹介10名+検索10名)のお相手候補 出典：MMD研究所xスマートアンサー「2020年マッチングサービス ・アプリの利 ⽤実態調査」より 

4. © 2021 eureka, Inc. All Rights Reserved. Agenda • 今日話すこと ◦ ある企業における、数年間においてのSREチームの取り組みと紆余曲折の歴史（最前線.....?) ▪ 課題感や取り組みがどのように変化していったか • あまり深く話さないこと ◦ 各要素技術についてはあまり深くふれていません。
5. © 2021 eureka, Inc. All Rights Reserved. エウレカのSREチームの変遷 (黎明期 2017~) • インフラチームが改名する形でスタート ◦ この頃のメンバー構成はインフラエンジニア数名/AIエンジニア/アプリケーションエンジニアetc.. ▪ SREやっていくぞいという立て付けはありつつ、寄り合い所帯感 • 守備範囲はインフラほぼ全て＋一部開発＋AI+プロジェクト支援 • この時期は一言でいうと、マイナスを0にしていた時期 2017/x~ 黎明期　 SREチーム発足 • まずはマイナスを０に • 課題山積み.. 2018/x~ 成長期 • 人数が減る • なーに、勢いでカバーだ！ 2020/3~ 成熟期への移行 • 表面化する成長痛 • チーム再構築
6. © 2021 eureka, Inc. All Rights Reserved. 当初のチームミッション • 会社の目指すビジネスの実現の阻害要因を 全て排除する ◦ 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす ◦ ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する ◦ 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する ◦ 適切なキャパシティプランニングを行い、利益率向上へ寄与する ◦ 顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をおこなう ◦ 事業価値最大化にむけた施策の技術サポートを行う → ”全て”が示す通り、必要ならなんでもする特殊チームみたいな意味合いも強かった。
7. © 2021 eureka, Inc. All Rights Reserved. 当時はシステム構成にそもそも課題が山積み • スケールアウトが遅い・しんどい・つらい ◦ データストア(MySQL on EC2)のSlaveを追加する際は、サーバーにsshして心温まる手作業 ◦ DynamoDBはしょっちゅうスロットリング.. ◦ アプリケーションサーバーは起動後にAnsibleでレシピを流すので。サービスインが長い（たまに壊れる) • 常時流れてるエラーログと良く鳴る狼アラート... ◦ 慣れた人はいつも流れてるログを脳内でフィルタリング ◦ 心臓に悪い、反応できる人は特定の人だけ ◦ そもそもサーバー入ってみるの... • セキュリティ系の取り組みもしてはいたが、ベストプラクティスへの追随や改善フロー構築など色々やるべき事は山積み • 単一障害点なビルドサーバー、飼い主不明のコンポーネント、カオスなネットワーク構成…..
8. © 2021 eureka, Inc. All Rights Reserved. まずはひたすらにシステム面の大きな課題を解決する • スケールアウトが容易になる技術・コンポーネントの採用 ◦ データストア: MySQL on EC2 → AuroraMySQL, KVS は Elasticacheに移行 ◦ EC2: Packer+Ansible+Terraformによる Golden Image Modelへの移行 • 徹底したエラーレベルの整理と不要なログの排除の実施 ◦ アクションが必要なエラーと件数レベルで傾向をみたいFYIなログのレベル整理、不要なログ排除 ◦ CloudLogging+Slackへの通知への移行 • その他もろもろ(自前ビルドサーバー → codeBuild,ネットワーク再構築,etc…)
9. © 2021 eureka, Inc. All Rights Reserved. エウレカのSREチームの変遷 (2018/x~) • だいぶ平和になってきたが、まだまだ課題は残っている • AIチームが分離したり、異動・退職などでだいぶ人が減る... ◦ 人が半分くらい減った ▪ 守備範囲は変わらず、インフラほぼ全て＋一部開発＋プロジェクト支援＋一部問い合わせ対応etc.. ▪ 勢いでカバーだぜ！！！ • あい変わらず、各メンバーが元気に各個撃破し続けるカウボーイチーム 2017/x~ 黎明期　 SREチーム発足 • まずはマイナスを０に • 課題山積み.. 2018/x~ 成長期 • 人数が減る • なーに、勢いでカバーだ！ 2020/3~ 成熟期への移行 • 表面化する成長痛 • チーム再構築
10. © 2021 eureka, Inc. All Rights Reserved. 人数が減ったが、前以上にシステム面での改善を積み上げていた時期 • EC2 から ECS Fargateへの全面的な移行 • セキュリティ ◦ AWS WAFへの移行とOWASP準拠のルール導入 ◦ GuardDutyの全アカウントへの導入 ◦ CloudTrail,VPCFlowLogなどの証跡、ログ集約 ◦ 専任チーム立ち上げ支援/外部診断テストの修正作業 • 可観測性の向上、アラートの再整備 ◦ Datadog,DatadogAPMの導入と整備 • 自前のデータパイプラインを撤廃してマネージドサービスに移行 • データベースサーバーのパフォーマンス改善 (r5.8xlargeが3台近く減らせた) ◦ Aurora Peformance Insightsで支配的なクエリを抽出して改善 • 様々なマイグレーション ◦ CDN,DeployPipeline,ElasticSearch,etcetc…
11. © 2021 eureka, Inc. All Rights Reserved. この頃、Developerと共同の取り組みもスタート • パフォーマンス定点観測会のスタート ◦ バックエンド開発チームとSREチームが週次で行う改善サイクル ▪ Datadogによる週次のメトリクス確認 ▪ errorRate,データベース負荷,5xxの発生などの重要指標を確認 ◦ 重要性に応じて原因分析と修正タスクを積み消化する活動 • 一定の成果を生む ◦ 未成熟なマイクロサービスは目に見えてSLOを改善できた。 ◦ 一方で主要サービスはほとんどの場合達成していた。 • 1年近く続いた結果、休止 • SLOを達成しているのに工数を支払い続けることへの不満やモチベーションの低下 ◦ でも問題はおきていた。 ▪ SLOが全量リクエストに対する失敗率なので、数が少ない重要操作が失敗しても修正が必要なものが検 知できない ◦ SLOが正直役に立ってなくて、重要な問題は勘が良い人が掘り当てていたり..
12. © 2021 eureka, Inc. All Rights Reserved. エウレカのSREチームの変遷 (2020/x~) • この頃、チームの責任者に着任 • 2017~2020までの取り組みでだいぶシステム全体は改善されてきたぞ〜 • 熱意のある新しいメンバーもjoin！ ◦ そろそろ脳筋個人突破をやめよう。 ◦ もう少しSREの関心を組織にガイドできるようにがんばっていくぞい! • ...のはずが.......? 2017/x~ 黎明期　 SREチーム発足 • まずはマイナスを０に • 課題山積み.. 2018/x~ 成長期 • 人数が減る • なーに、勢いでカバーだ！ 2020/3~ 成熟期への移行 • 表面化する成長痛 • チーム再構築
13. © 2021 eureka, Inc. All Rights Reserved. 表面化してきた各種の課題(成長痛） • 並列して走る大型プロジェクトへのサポートや参画（場合によっては開発も主導）でリソース枯渇 ◦ メンバーはセキュリティチームの立ち上げに奔走や大型プロジェクトに捕まったり.... ◦ あれ、、僕しか残ってな(ry • SREボトルネック問題 ◦ 2017~2020に各個撃破をし続けて戦端が拡張し続けた結果、SREの特定の担当しか分からない領域が増える ◦ 作ったあとのメンテナンスコスト... ◦ 拡大する規模に対して、勢いではカバーしきれていない状況に。 ▪ SRE門番モデルと勢い駆動の限界 ▪ 機能しきらない移譲と改善サイクル • 不明瞭なチームアイデンティティ ◦ 遅々として進まない各種システムへの改善活動とメンバーの疲弊・モチベーションダウン →　俺たちの取り組みは、、無駄だったのか、、、、？
14. © 2021 eureka, Inc. All Rights Reserved. そんなわけはない • これまでの取り組みを基に現状を分析する ◦ Good ▪ システムはよりレジリエンスな状態に近づいている • スケーラビリティの確保 • コンテナ化やAPM導入、アラート整備などによる各種改善 • セキュリティチームの立ち上げやベストプラクティスへの追従 ▪ やや判断基準や意思決定に難はあったが、確かに品質向上に貢献したDevと共同での改善会 ◦ Bad ▪ 拡大する責務とメンテナンスコスト ▪ 結局一部の個人プレイ任せなので拡大に弱い ▪ 不明瞭なアイデンティティ ▪ 外的なリソース要求に依存しすぎる →　戦い方を変えるべき。
15. © 2021 eureka, Inc. All Rights Reserved. Team Rebuild 1. チーム全体で、何でも屋になりつつあるSREの役割をもう一度俯瞰して考え直す 2. 不明瞭なアイデンティティを再定義する a. チームに必要なアイデンティティ i. 企業にもたらす価値とミッションの定義 ii. 全員で言語化をする 3. ミッションを実現するために必要な具象化されたゴールとリソース戦略 a. やることとやらないことの定義 b. 理想ゴールの定義と剥離の抽出
16. © 2021 eureka, Inc. All Rights Reserved. 1. SREを考える • そもそものSREのもたらす大きな価値自体は突き詰めるとシンプル ◦ SLOの向上 ▪ レジリエンスのあるシステム構成 ▪ サイクル化された改善の取り組み ◦ 変更速度の最大化 ▪ 各要素（テスト/ビルド/デプロイ)のリードタイムの短縮 ▪ 移譲容易性
17. © 2021 eureka, Inc. All Rights Reserved. 2-a. 不明瞭なチームアイデンティの再定義 • トップレベルのミッション(会社の目指すビジネスの実現の阻害要因を全て排除する ) を廃止 ◦ 全てを自分たちが直接やるのは無理で、逆に組織のスケールを妨げる事になる。 ◦ SRE門番モデルの限界なので、むしろ責務を分散していく方向に考える。 ◦ むしろ全員で守るための仕組み作りをリードする事が現実的にこのミッションを成し遂げる。 • チームメンバー全員でSREの役割、会社にとっての価値をひたすら言語化する
18. © 2021 eureka, Inc. All Rights Reserved. 2-a. 出来上がった新しいチームのヴィジョンとミッション • エウレカSREチームの目指すビジョン (Vision) ◦ 安心安全(セキュアに、安定して）使い続けられるシステムの構築 /設計を開発チームと実現する ◦ サービスのスケールをより加速できるような、開発のための環境や自動化の仕組み作りを提供する • チームのミッション (Mission) ◦ SREチームはサービスの信頼性と安全性の向上を通して、顧客の体験の質を高める事に責務を持つ ▪ SREチームはサービスの信頼性を向上する為の仕組みの提供に責務を負う ▪ クラウドインフラにおけるセキュリティ項目の実装とガイドを行う ◦ SREチームは変更速度の最大化に寄与する ▪ 開発生産性への寄与 ▪ SREは組織とビジネスの拡大を妨げない為に、 SREのロールをセルフサービス化するガイドの責務を担う ◦ SREチームはサービスのスケールを阻害しない（むしろ加速させる）ためのチームである ▪ Embedded SREとしてプロジェクトの迅速な遂行 を伴走してサポートする責務 ▪ 社内システムを除くプロダクトのスケールを阻害しないインフラストラクチャの構築 /運用 ▪ 自動化の推進による人的リソースの圧迫に対する削減 ◦ SREは常に新しい技術とシステム設計・アプローチへの挑戦と投資を行う
19. © 2021 eureka, Inc. All Rights Reserved. 3-a.リソース戦略とやらないことの定義 • 外部向け工数とシステム改善・仕組み作りの工数を分離 ◦ 40%は外部工数,10%はToil/日常運用,50%はシステム改善とSREとしての取り組みに充当させる ▪ Toil工数が10%を超えるようなら、Toil改善に力を傾ける ▪ 外部工数がこれ以上必要でも、内部工数からは削らない（必要なら採用） • やらないことを定義して、他チームへの譲渡を進める ◦ 直接的な機能開発・問い合わせ対応は開発チームに移譲。 ◦ コーポレート関係をコーポレートチームに移譲。 ◦ データ関連はデータマネージメントチームに移譲。 →　関係各所、CTOと話し合って、このポジショニングに移行
20. © 2021 eureka, Inc. All Rights Reserved. 3-b.次にゴール設計の前に....全体を俯瞰 • 一度SREとしての取り組みを俯瞰して対応状況や、要素を整理して目線を合わせたり.. • 最近はマインドマップを作ったりもしていました。
21. © 2021 eureka, Inc. All Rights Reserved. 3-b. 現状とゴールの剥離を考える • システムの信頼性の短期的な向上については一定の成果が出せている ◦ 開発者との継続的な改善サイクルの再開が必要 ▪ 品質を表現する最上位指標であるSLOが意思決定材料になっていないので早期に解決が必要。 ◦ そも信頼性向上は割と終わりがない(マイグレーション、変更が起き得る限り) • 一方で変更速度への貢献と、組織の拡大に対して信頼性を維持することに対してはビハインドしている ◦ 個人のマンパワーの限界によるボトルネック化(SRE門番モデルの限界) ◦ より移譲や環境構築を容易にする組織的な取り組みやシステム構成の変更が必要 ◦ わかりやすい仮想的な目標値の設定 ▪ もっとも開発ラインの拡大が起き得るマイクロサービス化に耐えうる組織としての土台作り • 注：別にマイクロサービスアーキテクチャを採用するわけではないです。 →　マイクロサービスチーム化が行われても、耐えうるような組織作りと要素技術の整備をしていこう。
22. © 2021 eureka, Inc. All Rights Reserved. [now]新しいゴールを目指して鋭意進行中 • 信頼性の向上させる取り組みを個人で行うのではなく、組織にガイドする ◦ PostMortemの文化作り ◦ SLOをCUJを定義した上で、CUJ別の指標にUpdate ◦ 避難訓練のシナリオ準備と実施 ◦ etc • 移譲のしやすい仕組み作り、新規環境を構築しやすい技術の採用 ◦ そもそもの開発生産性を示すメトリクスの定義と取得 ◦ Policy as Code ◦ プロダクション環境に必要な関心ごとのガイドドキュメント化 ▪ β版をチーム内で運用中 ◦ Platform化しやすい技術への移行検討 ◦ いろいろ
23. © 2021 eureka, Inc. All Rights Reserved. おわり • ある企業におけるフェーズ別（黎明期・成長期・成熟期）でのSREチームの役割とゴール観の変化との向き合いを描いてみ ました。SREチームの導入を検討している方の何かのヒントになれば幸いです。
24. © 2021 eureka, Inc. All Rights Reserved.