SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE

© 2023 Wantedly, Inc.
SRE を実践するための
プラットフォームの作り方と技術マネジメント
SRE NEXT 2023
Sep. 29 2023 - Shoji Shirotori @irotoris

View Slide

About Me
白鳥昇治 @irotoris
Infrastructure Squad at Wantedly, Inc.
Infra/SRE <- Data Engineer <- Infra
❤ Kubernetes, BigQuery, Go, Python

View Slide

会社紹介

View Slide


View Slide

話すこと
● ウォンテッドリーの開発組織における信頼性に対する取り組みの紹介
● みんなが SRE をやるためのプラットフォーム開発例
● 今ウォンテッドリーの SRE について考えていること

View Slide

アーキテクチャ全体

View Slide

Infrastructure Squad とは
Infrastructure Squad の基本戦略
プロダクト開発によって生み出された価値を継続的に提供するシステム基盤の維持
/高度化
● アプリ/システムが優れていてもシステム基盤が不安定だと困る
● システム基盤の裏側をアップデートすることでシステム基盤の性能やできること増やしていく
プロダクト開発と運用 (DevOps) を高速に行うためのプラットフォームと文化の提供
● 開発がスケールしていくためにインフラ作業やレビューがボトルネックにならないことが重要
Infra Squad 4人 / エンジニア約40人

View Slide

Infrastructure Squad でやる SRE っぽいこと
● システム基盤のスケーリングやネットワークの安定化、弾力性の向上
● Kubernetes や PostgreSQL / Redis / Elasticsearch メンテナンス
● Infrastructure as Code 整備
● モニタリングアラート整備
● オブザーバビリティ環境の整備
● SLI/SLO策定、見直し運用
● インシデントレスポンスの整備
● ポストモーテム企画運用
● 障害対応（オンコール）
これらを Infra Squad で整備して自分たちで実際に使っていき信頼性向上にコミットする
整備したものを開発組織全体で使ってケイパビリティをあげていく

View Slide

機能とプラクティスをプラットフォームとして提供していく

View Slide

開発組織の全体像

View Slide

開発組織の全体像
プロダクト Squad
基盤 Squad
ドメイン横断の技術領域 Chapter
Squad と Chapter のマトリクス型の組織

View Slide

新しくできた Quality Control Squad
ユーザーの価値を突き詰めたからこそ誕生した内部品質を向上させる Quality Control Squad |
Wantedly Engineer Blog

View Slide


View Slide

信頼性が問題になる箇所は他にもたくさんある

View Slide


View Slide


● マイクロサービス化 / 戻し
● データ不整合解消
● Ruby YJIT 有効化
● フロントエンド領域の安全な
ライブラリアップデート運用の構築
● E2E テストの導入
● 推薦システムの精度モニタリング
● ジョブ基盤のモニタリング

View Slide


それぞれのチームで信頼性に向き合っている
技術と興味範囲が異なるので解決方法も様々

View Slide


しかし『データドリブン』で判断しているのは同じ
エラーレートやレイテンシの他、インシデント発生数や問い合わせ件数なども

View Slide

ちなみに Embedded SRE は...?
プロダクト開発している Squad にSRE の役割を明示的に入れてみる？
考察
● ウォンテッドリーのプロダクト開発 Squad は目的別で設立・解散を繰り返す
○ コードベースに対して Squad で触る範囲が毎回異なりオーナーシップが発生しにくい
○ 結果的に CronJob 失敗通知メンション先になってしまった (?)
○ Squad 解散でいつのまにか Embedded SRE ごと消える
○ チームの状態が変化しにくい技術領域 Chapter や基盤 Squad にオーナーが移管される
● 実際にちゃんと Embedded SRE できているプロダクト開発
○ コードベースの範囲と Squad ゴールが一致している
○ 比較的息が長いプロダクト開発 Squad

View Slide

各チームの連携の仕方
● 週一のポストモーテム / インシデントレビュー会
○ 各領域横断でメンバーが参加
○ SLO / エラーバジェットを確認
○ 発生中のインシデントの対応状況について確認
○ ポストモーテムを共有して再発防止策について議論
■ 議論して出てきた再発防止アイディアは、各技術領域 Chapter や基盤 Squad に issue
化して委任される。複数チームで進めることもある。
● 実際の障害対応
● 個別課題があれば各チーム積極的に対話・共有
最近は Biz やカスタマーサポートのトラブルでも
ポストモーテムを書くようになった

View Slide

障害対応の心構え - Wantedly Engineering Hanbook

View Slide

ウォンテッドリーの信頼性に対する取り組みまとめ
● Infra Squad がインフラの自動化や SLI/SLO の策定など SRE プラクティスを進めてきた
● Infra Squad 以外の技術・担当領域でもそれぞれで信頼性に対して向き合っている
○ 技術領域で問題解決の方法は当然異なるが、データドリブンであることは共通していそう
○ みんなとても協力的、失敗を許容する文化
● ポストモーテム会や個別のチーム同士の対話の中で信頼性に対する取り組みが共有される

View Slide

話すこと

View Slide

みんなが SRE をやるためのプラットフォーム開発
実際にウォンテッドリーのインフラ・プラットフォームを開発してきてよかったこと、気づき
● コンピューティング基盤は Infra Squad が唯一の共通基盤として管理する戦略
● マイクロサービスには共通のオブザーバビリティ関連の設定が入るように整備している
● マイグレーションをやり切り、一つのツールを使い倒すことの重要性
● 信頼性に向き合ってる人にアンケートをとる

View Slide

コンピューティング基盤は Infra Squad が共通基盤として管理する戦略
Pros
● 基盤全体の裏側をアップデートしていくことで出る効果の高さ
○ 稼働する全マイクロサービスに恩恵がある
● インフラの職能・専門性で信頼性に影響範囲大きくコミットできる
Cons
● 基盤変更のアジリティと影響範囲の広さ
○ ただしこれ自体が SRE で解決できる問題

View Slide

コンピューティング基盤は Infra Squad が共通基盤として管理する戦略
● ウォンテッドリーでは Kubernetes / AWS ベースの基盤になっている
● 全マイクロサービスのインフラの設定 (k8s manifest)も安定的にコンテナを動かすための設定をテンプ
レートとして提供している
● 他のサービスで得た知見と全体に適用できるように継続的・統合的に管理している

View Slide

マイクロサービスには共通でオブザーバビリティ関連の設定が入るように整備する戦略
マイクロサービス共通ライブラリ "servicex" の存在
● 新しくサービスを作る際に考えることを減らし本来実現したいドメインに集中できるようにするため、
Wantedly のすべてのマイクロサービスが備えるべき機能を扱いやすい・統一的な形で提供する共通ラ
イブラリ。
● このライブラリを使っておけば、たとえばログやオブザーバビリティ、 A/Bテストといった必須便利設定が
共通で入るため、システム全体で信頼性に対する問題の調査に一貫性がでる。
● これがデータドリブンに SRE をやっていくことに一役買っている。
マイクロサービス共通ライブラリ "servicex" の紹介 - Wantedly Engineering Handbook

View Slide

マイグレーションをやり切り、一つのツールを使い倒すことの重要性
● 機能が重複する同じようなツールを入れてると認知負荷と管理コストが高い
○ 使ってるものが違うとプラクティスが貯まらない
○ 「それもう古いやつで最新こっち使ってください」で手戻り
● 新しい技術の PoC とマイグレーションコスト
○ 新しいものはその背景と問題設定を確認しよう、 PoC することで問題を捉えることも出来る
○ なにが置き換わりうるのか、今あるものを進化させたほうが効果あるんじゃない？は考える
● こまめに最新にアップデートしておくことも大事
○ 信頼性自体もそうだが、いろいろ手を入れたくなったときに ”ヤクの毛刈り” が発生する

View Slide

信頼性に向き合ってる人にアンケートをとる
● 信頼性の問題を解決するためにプラットフォームとしてどんな問題があるのかを知る
● なにをどう解決したらいいかを考える元ネタになる

View Slide

話すこと

View Slide

今ウォンテッドリーの SRE について考えていること
ウォンテッドリーでも横断 SRE チームを組成する必要がでてきたかもしれない？と思っている
● 守りたい「信頼性」という言葉の定義、認識がズレていないか？
● なぜ障害が起きたか？問題の本質はどこか？を議論して捉えることが難しいという課題
● 再発防止や施策のトラッキングが各チームに任されていることで、全体が見えにくい課題
● 各領域で実践して良かった SRE プラクティスもっと組織全体で共有して浸透させたい
これらを解決するのは SREチーム（組織）の在り方なのか？基盤の戦略なのか？を考えている

View Slide

ご清聴ありがとうございました

View Slide


View Slide

SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE

SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE

Shoji Shirotori

More Decks by Shoji Shirotori

Other Decks in Technology

Featured

Transcript