Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自己完結な開発者組織を支える プラットフォーム作り
Search
Recruit
PRO
March 07, 2024
Technology
4
570
自己完結な開発者組織を支える プラットフォーム作り
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、田中の資料です。
Recruit
PRO
March 07, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
6
1.1k
Curiosity & Persistence
recruitengineers
PRO
2
110
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
230
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
97
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
92
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
130
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
71
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
79
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
97
Other Decks in Technology
See All in Technology
技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025
shogogg
7
1.7k
LINE API Deep Dive Q1 2025: Unlocking New Possibilities
linedevth
1
150
Javaの新しめの機能を知ったかぶれるようになる話 #kanjava
irof
3
4.8k
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
350
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
1.9k
LINE Notify互換のボットを作った話
kenichirokimura
0
170
Restarting_SRE_Road_to_SRENext_.pdf
_awache
0
140
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
130
ソフトウェア開発現代史: なぜ日本のソフトウェア開発は「滝」なのか?製造業の成功体験とのギャップ #jassttokyo
takabow
2
1.4k
Redefine_Possible
upsider_tech
0
220
Reactを段階的に覗いてみる
ytaisei
2
930
Go の analysis パッケージで自作するリファクタリングツール
kworkdev
PRO
1
370
Featured
See All Featured
Building Applications with DynamoDB
mza
94
6.3k
The Pragmatic Product Professional
lauravandoore
33
6.5k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Practical Orchestrator
shlominoach
186
10k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
We Have a Design System, Now What?
morganepeng
51
7.5k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Transcript
自己完結な開発者組織を支える プラットフォーム作り プロダクトディベロップメント室 販促まなび領域プロダクトディベロップメントユニット 田中 京介 (@kyontan)
田中 京介 温泉, 登山, 旅行 経歴 / Career 2021年リクルート新卒入社。SREとして、マッチングサ ービス『ゼクシィ縁結び』や教育系サービス『スタディ
サプリ』および『Quipper』の開発体験の改善やパブリッ ククラウドの活用最適化などに従事。 全社の改善提案制度『Ring Dash』においては、労務部 署と連携し勤怠記録の自動化を実現し初代グランプリを 受賞した。社外でもJANOG 51 や情報科学若手の会など 複数のカンファレンスの運営に携わる 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 販促まなび領域プロダクトディベロップメントユニット 小中高BtoCプロダクト開発部 小中高SREグループ
今日伝えたいこと スタディサプリのSREチームでは、 プロダクトを素早く安全に届けるため、自己完結チームを志向しています • この目標を達成するために、私たちSREは 自己完結チームを支えるプラットフォームと文化をつくっています • プラットフォームと文化という2つの切り口から、 取り組んでいること、その背後にある考えを紹介します
プロダクトについて
PHILOSOPHY プロダクトについて 学びたい、学んでよかったと 思える人を増やすために、 学びをもっと新しく。 CONCEPT
(提供中サービスの一部) プロダクトについて
プロダクトについて 本セッションで扱う範囲
技術的な概要 • マイクロサービスの集合体 • 54のマイクロサービス (as of 2024-02-16) • Ruby:
21, Go: 13, Node.js: 9, Python: 7, Elixir: 2, Rust: 1 • 開発チーム (Team Topologies の用語で分類, 包含関係にあるチームも含む) • Stream-aligned Team: 19 • Complicated Subsystem Team: 1 • Platform (& Enabling): 4 Team Topologies: https://teamtopologies.com/key-concepts
技術的な概要 • コード: monorepoで管理 • ソースコード, Kubernetesマニフェストを単一のGitリポジトリで管理 • GitHub Actions
(with self-hosted runner) + ArgoCD • https://github.com/quipper/monorepo-deploy-actions • Kubernetes Pod数 (≒ コンテナ数): ピーク時で約2,500 • 月間リリース回数: 208 (2024-01-17 - 2024-02-16)
Vision 最高の学習プロダクトを作り続けられる開発組織の実現 Mission 自己完結チームがプロダクトを素早く安全に届け続けるための プラットフォームと文化を作る SREチームの Vision / Mission ブログ記事:
https://blog.studysapuri.jp/entry/sre-vision-mission-values
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る
None
自己完結チームとは? スタディサプリの開発チームにおける造語 「自己完結チームとは、 自分たちに必要な問題解決を できる限り自分たちで行うことができる チームである」
なぜ自己完結チームを志向するのか? ユーザーへ、より素早く価値を提供できるはずだから 自己完結であるチームは、たとえば以下のことを達成できる • リリースに必要な手順を全て自分たちだけで完遂できる • 必要なデータベースなどを自分たちでセットアップできる • 問題が生じたとき、それを自分たちで検知し、修正できる
自己完結チームに求められる要素 • 自分たちでサービスが観測可能 (Observable) である • サービスがどのように動いており、今どのような状態にあるのかを自分たちで 把握し、説明できること • 何か問題が生じたときに、それを自分たちで検知し、原因を追求できること
• 自分たちでサービスが制御可能 (Controllable) である • 自分たちが必要なタイミングでサービスがリリースできること • 要求される仕様変更や、トラフィックの増加などの内外要因の 変化に対して、自分たちで対応が可能であること 自己完結チームの実現には、このほかにも多くの要素を満たす必要がある
SREの取り組み プラットフォームをつくる 文化をつくる
SREの取り組み プラットフォームをつくる 文化をつくる
プラットフォームを作る • セルフサービス化を目指す • 開発者はサービスをできる限り自分たちでコントロールできる状態 • SRE はリリースの可否を判断する存在ではない
プラットフォームを作る 手作業は極力避ける。PRを作り、CIが通れば安全である状態 • 10以上の SaaS を単一の terraform repository で管理 •
tfaction による GitOps の実現 • PRを作ればplan結果が表示され, マージすれば apply される • 安全でない・望ましくない設定は CI が通らないように • 誰がレビューしても同じ品質になるように
プラットフォームを作る 開発生産性を向上するための取り組み • qall-k8s • Kubernetes 上にある各開発者向けの独立した環境 VS Codeや RubyMine
等で直接コードを編集でき、即座に反映される • 本番との差分が小さな環境において、高速に開発ができる • Pull Request 環境 • PRごとに独立した検証環境が起動する仕組み • 負荷試験などの検証環境としても活用 ブログエントリ: https://blog.studysapuri.jp/entry/2023/03/17/studysapuri-development (“qall-k8s” で検索)
プラットフォームを作る 開発環境と本番環境の差分を小さくする • 開発用データベースは日次で本番からマスキングして同期 • オブジェクトストレージはマスキングして開発環境へコピー • パフォーマンス問題などに早期に気付くことができる
プラットフォームを作る 可観測性なくしてオーナーシップは生まれない • 定量的な信頼性指標としてのSLOの合意・運用 • より早く問題に気付きたい → SLO burn-rate などの手法を布教
• アクション可能なアラートのみを設定する • 即座に対応しなくてよい問題はオンコールなどの 割込みとは別の枠組みで対応する • 点ではなく線で捉える SLO burn-rate に関するブログエントリ: https://blog.studysapuri.jp/entry/slo-burn-rate-monitoring
プラットフォームを作る 観測可能な多くの情報を Datadog へ集約 リリース回数, GitHub PRのオープン数 CI の実行時間・待ち時間・成功率 AWSのコスト,
AWS Security Hub の非準拠リソース 10分後に試験を受ける予定のユーザー数 (!) … • 多種多様なカスタムメトリクスを収集 • APM や RUM, Continuous Profiler 等も積極的に導入中
SREの取り組み プラットフォームをつくる 文化をつくる
文化をつくる 地道な ”Enabling” の活動 • 開発者にとって身近な存在になる • SREはどうしても権限が強く気軽に聞きづらい存在と認知されがち • 積極的に聞きにいく
• 「最近なにか不満感じてないですか?」「これできたら便利ですか?」 • 困っていそうなチームがいれば積極的にモブしにいく • 「月刊SRE」: 最近の変更などを周知・アピールする
文化をつくる フィードバックを得る • 半年ごとにサーベイを実施し、開発者の 悩み・やりたいことを知る • 「最近困ったことはありますか?」 • 「XXで分からないことがあったらどこから調べますか?」 •
「より自己完結なチームになるために足りていない要素はなんですか?」 • 「プラットフォームにあるXXの機能はどのくらい知っていますか?」 • … • サーベイ→アクション→サーベイ→… のフィードバックループ
文化をつくる 過去の失敗を繰り返さないためにゲートを設ける • 開発設計レビュー • Design Doc等を記述し、アーキテクチャ上の問題などを洗い出す • 最近はチーム横断で、幅広いレビューが行えるように進化 •
Production Readiness Checklist • リリース前に実施する • スケーラビリティや可観測性が備わっているか確認する ブログエントリ: https://blog.studysapuri.jp/entry/2020/01/30/production-readiness-with-all
文化をつくる • 自己完結チームでないチームが、自己完結チームになるために • 自己完結チームが、より自己完結になれるように
まとめ (再掲) スタディサプリのSREチームでは、 プロダクトを素早く安全に届けるため、自己完結チームを志向しています • この目標を達成するために、私たちSREは 自己完結チームを支えるプラットフォームと文化をつくっています • その取り組みの一部や、背景にある考えを紹介しました •
開発者が自分たちでサービスを観測可能 & 制御可能であること • 開発者とコミュニケーションを取り続ける、地道なEnablingの活動 • フィードバックを得て取り組み方を常に見直し続けること
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る