$30 off During Our Annual Pro Sale. View Details »

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

Shoji Shirotori
September 28, 2023

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

Shoji Shirotori

September 28, 2023
Tweet

More Decks by Shoji Shirotori

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. © 2023 Wantedly, Inc.
    会社紹介

    View Slide

  4. © 2023 Wantedly, Inc.

    View Slide

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

    View Slide

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

    View Slide

  7. © 2023 Wantedly, Inc.
    アーキテクチャ全体

    View Slide

  8. © 2023 Wantedly, Inc.
    アーキテクチャ全体

    View Slide

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

    View Slide

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

    View Slide

  11. © 2023 Wantedly, Inc.
    Infrastructure Squad とは
    機能とプラクティスをプラットフォームとして提供していく

    View Slide

  12. © 2023 Wantedly, Inc.
    開発組織の全体像

    View Slide

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

    View Slide

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

    View Slide

  15. © 2023 Wantedly, Inc.
    アーキテクチャ全体

    View Slide

  16. © 2023 Wantedly, Inc.
    アーキテクチャ全体
    信頼性が問題になる箇所は他にもたくさんある

    View Slide

  17. © 2023 Wantedly, Inc.
    アーキテクチャ全体







    View Slide

  18. © 2023 Wantedly, Inc.
    アーキテクチャ全体







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

    View Slide

  19. © 2023 Wantedly, Inc.
    アーキテクチャ全体







    ● マイクロサービス化 / 戻し
    ● データ不整合解消
    ● Ruby YJIT 有効化
    ● フロントエンド領域の安全な
    ライブラリアップデート運用の構築
    ● E2E テストの導入
    ● 推薦システムの精度モニタリング
    ● ジョブ基盤のモニタリング
    それぞれのチームで信頼性に向き合っている
    技術と興味範囲が異なるので解決方法も様々

    View Slide

  20. © 2023 Wantedly, Inc.
    アーキテクチャ全体







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

    View Slide

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

    View Slide

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

    View Slide

  23. © 2023 Wantedly, Inc.
    障害対応の心構え - Wantedly Engineering Hanbook

    View Slide

  24. © 2023 Wantedly, Inc.
    障害対応の心構え - Wantedly Engineering Hanbook

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. © 2023 Wantedly, Inc.
    ご清聴ありがとうございました

    View Slide

  36. © 2023 Wantedly, Inc.

    View Slide