Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. About Me 白鳥 昇治 @irotoris Infrastructure

    Squad at Wantedly, Inc. Infra/SRE <- Data Engineer <- Infra ❤ Kubernetes, BigQuery, Go, Python
  2. © 2023 Wantedly, Inc. 話すこと • ウォンテッドリーの開発組織における信頼性に対する取り組みの紹介 • みんなが SRE

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

    をやるためのプラットフォーム開発例 • 今ウォンテッドリーの SRE について考えていること
  4. © 2023 Wantedly, Inc. Infrastructure Squad とは Infrastructure Squad の基本戦略

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

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

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

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

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

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

    各領域横断でメンバーが参加 ◦ SLO / エラーバジェットを確認 ◦ 発生中のインシデントの対応状況について確認 ◦ ポストモーテムを共有して再発防止策について議論 ▪ 議論して出てきた再発防止アイディアは、各技術領域 Chapter や基盤 Squad に issue 化して委任される。複数チームで進めることもある。 • 実際の障害対応 • 個別課題があれば各チーム積極的に対話・共有 最近は Biz やカスタマーサポートのトラブルでも ポストモーテムを書くようになった
  11. © 2023 Wantedly, Inc. ウォンテッドリーの信頼性に対する取り組みまとめ • Infra Squad がインフラの自動化や SLI/SLO

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

    をやるためのプラットフォーム開発例 • 今ウォンテッドリーの SRE について考えていること
  13. © 2023 Wantedly, Inc. みんなが SRE をやるためのプラットフォーム開発 実際にウォンテッドリーのインフラ・プラットフォームを開発してきてよかったこと、気づき • コンピューティング基盤は

    Infra Squad が唯一の共通基盤として管理する戦略 • マイクロサービスには共通のオブザーバビリティ関連の設定が入るように整備している • マイグレーションをやり切り、一つのツールを使い倒すことの重要性 • 信頼性に向き合ってる人にアンケートをとる
  14. © 2023 Wantedly, Inc. コンピューティング基盤は Infra Squad が共通基盤として管理する戦略 Pros •

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

    Kubernetes / AWS ベースの基盤になっている • 全マイクロサービスのインフラの設定 (k8s manifest)も安定的にコンテナを動かすための設定をテンプ レートとして提供している • 他のサービスで得た知見と全体に適用できるように継続的・統合的に管理している
  16. © 2023 Wantedly, Inc. マイクロサービスには共通でオブザーバビリティ関連の設定が入るように整備する戦略 マイクロサービス共通ライブラリ "servicex" の存在 • 新しくサービスを作る際に考えることを減らし本来実現したいドメインに集中できるようにするため、

    Wantedly のすべてのマイクロサービスが備えるべき機能を扱いやすい・統一的な形で提供する共通ラ イブラリ。 • このライブラリを使っておけば、たとえばログやオブザーバビリティ、 A/Bテストといった必須便利設定が 共通で入るため、システム全体で信頼性に対する問題の調査に一貫性がでる。 • これがデータドリブンに SRE をやっていくことに一役買っている。 マイクロサービス共通ライブラリ "servicex" の紹介 - Wantedly Engineering Handbook
  17. © 2023 Wantedly, Inc. マイグレーションをやり切り、一つのツールを使い倒すことの重要性 • 機能が重複する同じようなツールを入れてると認知負荷と管理コストが高い ◦ 使ってるものが違うとプラクティスが貯まらない ◦

    「それもう古いやつで最新こっち使ってください」で手戻り • 新しい技術の PoC とマイグレーションコスト ◦ 新しいものはその背景と問題設定を確認しよう、 PoC することで問題を捉えることも出来る ◦ なにが置き換わりうるのか、今あるものを進化させたほうが効果あるんじゃない?は考える • こまめに最新にアップデートしておくことも大事 ◦ 信頼性自体もそうだが、いろいろ手を入れたくなったときに ”ヤクの毛刈り” が発生する
  18. © 2023 Wantedly, Inc. 話すこと • ウォンテッドリーの開発組織における信頼性に対する取り組みの紹介 • みんなが SRE

    をやるためのプラットフォーム開発例 • 今ウォンテッドリーの SRE について考えていること
  19. © 2023 Wantedly, Inc. 今ウォンテッドリーの SRE について考えていること ウォンテッドリーでも横断 SRE チームを組成する必要がでてきたかもしれない?と思っている

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