SRENEXT2022 組織にSREを実装していくまでの道のり

© 2021 eureka, Inc. All Rights Reserved.
組織にSREを実装していくまでの道のり
SRE NEXT 2022
2022年05月15日

View Slide

About Me
masashi.yamamoto (@marnie0301)
● 株式会社エウレカ
○ 2015年に入社
○ 2017 機能開発チームからSREチームに移籍
○ 2020~ Head of SRE

View Slide

© 2021 eureka, Inc. All Rights Reserved. 3
恋活・婚活マッチングアプリオンライン結婚相談所サービス
真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け
Pairsは日本で最も使われている恋活・婚活
マッチングアプリ
日本人特有の交際相手探し、恋愛に対する障壁を和らげ
るために設計
24時間365日オペレーターが待機し公的身分証明書の
確認、お問い合わせ、パトロール監視に対応
登録からお相手の紹介まで全てスマホで利用可能
プロのコンシェルジュチームによる24時間サポート
毎月20名(紹介10名+検索10名)のお相手候補
出典：MMD研究所xスマートアンサー「2020年マッチングサービス・アプリの利⽤実態調査」より  

View Slide

Agenda
● 今日話すこと
○ チーム立ち上げフェーズから数年間におけるSREチームの自身の取り組みの紹介(~2020)
○ SREフェーズ移行期の到来と戦略の変更(2021~)
● あまり話さないこと
○ 各要素で扱われている技術についてはあまり深くふれません。

View Slide

エウレカ SREチーム
● 2017年に設立
● チームミッション(2017~2020)
○ 会社の目指すビジネスの実現の阻害要因を”全て”排除する
■ 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす
■ ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する
■ 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する
■ 適切なキャパシティプランニングを行い、利益率向上へ寄与する
■ 顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をおこなう
■ 事業価値最大化にむけた施策の技術サポートを行う

View Slide

2017~2020におけるSREの主な戦場と責務
● 機能開発以外ほとんど全部
● コーポレート関連やデータ関連も有り、結構煩
雑...

View Slide

SREの文化の浸透云々の前にそもそも課題が山積み
● スケールアウトが遅い・しんどい・つらい
○ データストア(MySQL on EC2)のSlaveを追加する際は、サーバーにsshして心温まる手作業
○ DynamoDBはしょっちゅうスロットリング..
○ アプリケーションサーバーは起動後にAnsibleでレシピを流す形式,サービスインが長い（たまに壊れる)
● 常時流れてるエラーログと良く鳴る狼アラート
...
○ 慣れた人はいつも流れてるログを脳内でフィルタリング
○ 心臓に悪い、反応できる人は特定の人だけ
● その他、etcetc…,セキュリティ系のベストプラクティスへの追随や改善フロー構築、単一障害点なビルドサーバー、
飼い主不明のコンポーネント、カオスなネットワーク構成
…..

View Slide

まずはSREチーム自身が運用負荷を減らし、未来の時間を作る
● より柔軟なシステム構成への移行
○ スケーラビリティ不足の解消
■ MYSQL on EC2 → Aurora
■ Golden AMI Model,ECS Fargate移行+AutoScaling
● 監視・オブザーバビリティ地盤づくり
○ 徹底したエラーレベルの整理と不要なログの排除の実施
○ Datadog Dashboard、APMなど主要メトリクス整備
○ 狼アラートの再整備
● 運用コストの削減
○ 一部コンポーネントのサーバーレス移行
○ マネージドシステムの積極採用

View Slide

開発チームと協調した品質改善取組の試験運用
● パフォーマンス定点観測会のスタート
○ バックエンド開発チームとSREチームが週次で行う改善サイクル(1h~2h)
■ 週次のメトリクス確認(errorRate,データベース負荷,5xxの発生)などの重要指標を確認
○ 重要性に応じて原因分析と修正タスクを積み、余力で消化
● 一定の成果
○ 未成熟なマイクロサービスは目に見えてSLOを改善できた。
○ 一方で主要サービスはほとんどの場合達成していた。
● 1年近く続いた結果、休止
○ SLOを達成しているのに工数を支払い続ける判断基準が不明瞭なことによるモチベーションの低下
■ SLOが全量リクエストに対する失敗率なので、数が少ない重要操作が失敗しても修正が必要なものが検知でき
ない。(SLOは達成できているが、普通に問題は起きていた。)
■ SLOが正直役に立ってない。重要な問題は勘が良い人が掘り当てていた。

View Slide

改善が進む一方、綻びが目立ち始める
● SREボトルネック問題
○ 個人プレイの積み重ねが続いた結果、SREの特定の担当しか触れない領域が増える
○ 拡大するシステム規模に対してカバーしきれない
■ 機能しきらない移譲と改善サイクル
■ 複数並列で起き続けるドメイン知識の必要な問題をチーム外から把握し続けるのは至難
○ 限られた人しかアラート対応できない
● 外的要求への対応+広すぎる守備範囲によるリソースが枯渇
○ メンバーがセキュリティチームの立ち上げに奔走や大型プロジェクトに捕まったり.... (ひとり時代)
○ 上記のボトルネックも加わりさらにスパイラル。
● 不明瞭なチームアイデンティティ
○ SRE本来の活動が進まない事による葛藤・モチベーションダウン

View Slide

● 順調に事業が成長していく前提において、システムは時間と共により高水準な事を求められていく
○ 複雑性、ワークロードやデータ量の規模、求められる信頼性やセキュリティなどの要求
○ 激化する競争で生き残る為の変更速度の維持
● 構成する各コンポーネントへのアップデートや変更要求は繰り返し行われるもの
システム開発とその運用はそもそも長期戦

View Slide

● そもそもSREに限らずエンジニア採用は難しい
○ 競争激化
○ 求める職掌が多いほど、難易度をさらに向上させる
○ 開発チームの規模も拡大していく
■ 開発ラインが並行する中、ライフサイクルの外から全てを把握し続けるするのは至難
人が足りないなら採用がんばればいいんじゃない？
チーム戦略のアップデートが必要

View Slide

ここまで(2017~2020)のSRE実施フェーズを振り返る
● フェーズ1 消化活動 → フェーズ2 門番 (Seeking SRE 22.4から引用)
● 問題自体を減らす事による悪循環からの脱出
● プロダクトリリースに対する確認や干渉
● SREの取り組みはほぼ全てチームに集約されている。
○ ゆえにスケーラブルではないし、ボトルネックにもなっていた。

View Slide

チームではなく組織でSREを実践していくフェーズへの移行
● 門番ではなく、パートナー・触媒としての役割への移行 (Seeking SRE 22.4から引用)
● 共通の指標を一緒に守っていくパートナーシップの関係
● SLOの再構築(本スライドでは割愛)
● 自分たちで全てを守らない
● 組織にSREの機能をインストールするフェーズへの移行
● SRE機能のガイドとそれを実現するプラットフォーム化をチームの焦点におく

View Slide

Vision,Mission,Valueの再定義
● Vision
○ 自律的にリライアビリティとアジリティを両立するプロダクト開発組織の実現
● Mission
○ SREプラクティスを開発組織にインストールする
● Value
○ Metrics First
○ Draw a Blueprint
○ No Blame
○ Learning Animal
○ Change Agent

View Slide

Mission達成のための取り組み全体像

View Slide

インストールするべきSRE機能
● SLI/SLO
● Monitoring/Alert
● Capacity Planning
● Incident Response & Postmotem
● Peformance analysis & Optimization

View Slide

インストールの実現方法
● Install SRE
● SREアセスメント
● プロダクション環境チェックシート
● Enabling & Embed SRE
● Platform Engineering
● SLO,Monitoring/Alert の運用を支援するメトリクス収集基盤の構築・運用
● Capacity Planningを支援するためのLoadTestを簡単に行える基盤整備
● インシデント対応~ポストモーテム完了までのタイムライン管理をChatOpsのインターフェースでの提供
● パフォーマンス最適化を行うための観測情報やアプローチの整備
● 移譲やセルフサービス化に適した技術の採用(Policy as Code,etc)
● などなど

View Slide

実現の為のリソース戦略と開発組織の協力
● 外部向け工数とシステム改善・仕組み作りの工数を分離
○ 40%は外部工数,10%はToil/日常運用,50%はシステム改善とSREとしての取り組みに充当させる
■ Toil工数が10%を超えるようなら、Toil改善に力を傾ける
■ 外部工数がこれ以上必要でも、内部工数からは削らない（必要なら採用）
● 他チームへの責務譲渡
○ 直接的な機能開発・問い合わせ対応は開発チームに移譲。
○ コーポレート関係をコーポレートチームに移譲。
○ データ関連は新設したデータマネージメントチームに移譲。
■ ➡ チームではなく、技術組織全体の理解と協力と採用活動の結果

View Slide

まとめ
● チームの役割やリソース戦略は組織や事業の規模に合わせてアップデートしていく事が望ましい
○ 結局地道な積み重ね
○ まずは自分たちが小さく実践を繰り返し、プラクティスや課題感への習熟を深める
○ SREはチーム完結ではなく、開発組織全体の理解と協調が必要
● 取り組みはまだまだ始めたばかりなので、また年内目処にアウトプットできたら... :)

View Slide

前半部分の取り組みの歴史や変遷をより詳しく知りたい方はこちら :)
https://speakerdeck.com/marnie0301/eurekafalsesretimufalseshi-jian-sitekitashi-towei-lai-xiang

View Slide

SLO改善・再構築の別スライドもぜひ :)
https://speakerdeck.com/takumiogawa/slozai-ding-yi

View Slide

セルフサービス化の取り組み資料
https://speakerdeck.com/fukubaka0825/steps-toward-self-service-operations-in-eureka-at-sre-next-2022-1-da1455f1-f727-4d73-84e5
-ced5ae517202

View Slide


View Slide

SRENEXT2022 組織にSREを実装していくまでの道のり

SRENEXT2022 組織にSREを実装していくまでの道のり

marnie0301

More Decks by marnie0301

Other Decks in Technology

Featured

Transcript