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

by Shoji Shirotori

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2023 Wantedly, Inc. アーキテクチャ全体 ● マイクロサービス化 / 戻し ● データ不整合解消 ● Ruby YJIT 有効化 ● フロントエンド領域の安全なライブラリアップデート運用の構築 ● E2E テストの導入 ● 推薦システムの精度モニタリング ● ジョブ基盤のモニタリングしかし『データドリブン』で判断しているのは同じエラーレートやレイテンシの他、インシデント発生数や問い合わせ件数なども

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Slide 36

Slide 36 text