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 25, 2024
Technology
1
150
横断組織から見たリクルートのインフラの歴史と目指すべきクラウド活用像
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、宮地の資料です。
Recruit
PRO
March 25, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
SIerでの経験が活きた!『SUUMO』『ゼクシィ』担当PdMの企画プロセスを紐解く〜プロデザ!〜
recruitengineers
PRO
0
67
事業目的とのプロトコル変換
recruitengineers
PRO
4
96
Boosting Hotel Profits: The Power of Enhanced Cancellation Predictions
recruitengineers
PRO
3
670
ヘルススコアの改善の過程で起きた嬉しい変化
recruitengineers
PRO
4
720
スクラム開発導入による 他組織を巻き込んだ開発生産性向上の取り込み
recruitengineers
PRO
3
380
大公開!SUUMOの裏側 -データ組織の取り組みLT会-
recruitengineers
PRO
4
120
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
recruitengineers
PRO
5
160
組合せ最適化による問題解決の実践的アプローチ
recruitengineers
PRO
8
1.4k
社内のAI活用事例と活用促進のための取り組みを大公開!
recruitengineers
PRO
4
710
Other Decks in Technology
See All in Technology
How to Think Like a Performance Engineer
csswizardry
4
590
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
LINE WORKSへ簡単通知!Incoming Webhookアプリの紹介
mmclsntr
0
110
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
620
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8k
AutomatedLabを使って内部ペンテストを勉強しよう! -やられ社内ネットワークの自動構築-
n_etupirka
1
610
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
120
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
The Mythical Team-Month
searls
217
43k
Designing with Data
zakiwarfel
96
5k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
Building Your Own Lightsaber
phodgson
101
5.9k
Why Our Code Smells
bkeepers
PRO
332
56k
4 Signs Your Business is Dying
shpigford
178
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
90
47k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
353
29k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.3k
Transcript
横断組織から見たリクルートの インフラの歴史と目指すべきクラウド活用像 プロダクトディベロップメント室 インフラソリューションユニット 宮地 克弥
宮地 克弥 🎮💻📷🚗🐶🏕が好き 経歴 / Career 2017年リクルートホールディングス(現リクルート)新 卒入社。『Airシフト』『Airワーク』『ゼクシィ縁結び』 『社内基盤システム』『レジュメ』などの複数のプロダ クトにてインフラエンジニアとして開発に携わる。
現在はCCoEとして複数のプロダクトの開発/運用支援に 携わりつつクラウド利活用における横断施策の模索と推 進を行っている 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 インフラソリューションユニット サイトリライアビリティエンジニアリング部 クラウドアーキテクトグループ 自己紹介
目次 • 自己紹介 • リクルートの開発体制とインフラの歴史 • リクルートにおけるインフラ選定とクラウドを使う理由 • CCoEの取り組み
リクルートの歴史 リクルート公式サイトより 約60年の歴史がある会社であり、紙メディアを始め、メディア形態や業務領域を変革し、現在では SaaSやマッチングプラットフォームの展開を行なっている
リクルートにおける開発体制の多様さ プロダクトの種類や開発体制は様々な形が存在する https://speakerdeck.com/rtechkouhou/duo-yang-nabizinesudomein-sabisuhuezuga-hun-zai-suruzhong- defalsezu-zhi-zhan-lue-toji-shu-zhan-lue?slide=14 より
開発組織の体制 主に事業側組織と横断組織に分かれており、自身の所属する組織は 横断組織に位置している 事業組織A 事業組織B 事業組織C 事業組織D 横断組織 クラウドアーキテクト グループ
リクルートにおけるインフラの選択肢
リクルートにおけるインフラの選択肢 Private Cloud上で動くPaaS環境 パブリッククラウド
リクルートにおけるインフラの選択肢 Private Cloud上で動くPaaS環境 ->標準化されたアーキテクチャを採用したい パブリッククラウド ->標準化の枠に収まらないアーキテクチャや、個別最適化を行いたい
事業組織から見た時の責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private PaaS
事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア 責任分界点
事業組織から見た時の責任分界点 責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private
PaaS 事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* Private PaaS • 標準化されたアーキテクチャに 乗っかることで、 最小の責任範囲になる • 標準化されていないものを選ぶ 際の難易度がとても高い Public Cloud • 広い権限を持つことで、 個別最適化を行いやすい • 責任を持つべき範囲が広くなる DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア
Public Cloudを選択する上で重要なこと 責任 広い権限には責任が伴う PaaSが担ってくれた部分は自分たちで守る必要がある 責任を果たすための体制 責任を果たす為に様々なスキルを持つメンバーが必要 これらを持つ覚悟を持ったプロダクトを CCoEが全力で支援する
CCoEの取り組み
CCoEの取り組み CCoEとして、大きく二つの活動を実施 • プロダクト開発支援 • 横断活動
SREチームの 立ち上げ 最適なプロダクト 構築 事業にとって最適なプロダクト構築と SREチームの立ち上げの実施 構築後も安定してプロダクト運用が出来る 体制を目指す プロダクト開発支援
技術だけじゃなく多様な観点から選定と実装を担う 最適なプロダクト構築に必要な要素 プロダクトの要件 チームのスキルセット 社内ルール準拠 事業としてのチャレンジ
技術力 SRE文化 チーム運営 将来的な運用を担うチームをプロダクト構築を通して立ち上げる SREチームの立ち上げの実施 https://www.oreilly.co.jp/books/9784873117911/
SREチーム立ち上げと最適なプロダクト構築をプロジェクトを通して実現する 時間 インフラの関与度 カットオーバー CAGプロダクト支援 事業側開発メンバー リリースに向けて徐々に開発メンバーに役割移管を行い、 プロダクト側で自立出来るよう徐々に移行する 難しい問題には、CAGがスポット支援 アドバイスや解決をする
設計/構築/運用設計を開発メンバーと協業し、技 術力の向上とチーム運営のナレッジを伝授する Step 2:CAG+事業側開発T伴走での移管 Step 3:事業側開発主導DevOps Step 1:CAG +事業側開発Tでの構築 取り組み 方針 狙い 新規プロダクトの構築支援方針 *CAG: クラウドアーキテクトグループの略称
横断的な活動
利用可能なナレッジ 個々のナレッジ 蓄積 人に依存した支援は持続性・質・スケールに課題がある ナレッジを蓄積し、利用可能な状態へ変換することで持続可能なエコシステムを 構築する 横断組織としての課題 展開 複数組織でのナレッジ活用 派生
ナレッジの利用には大きく3パターンがある 形式化による知識移転 必要なタイミングで手に入れる 体験による知識移転 手を動かしながら学ぶ 新規プロダクト構築を通した育成 ex: Policy as Code,
モブ/ペアプロ 暗黙化による知識移転 裏側を知らずとも利用出来る 共通パーツ ex: メールGW, ウィルススキャン これらを使い分け、クラウド利活用に必要なナレッジを獲得するための 高速道路を構築する ドキュメント化 ex: プロジェクトの進め方, チーム運営, SRE文化,アセスメント 利用可能なナレッジの蓄積
体験による知識移転 プロダクトチーム 暗黙化による知識移転 スキルの底上げ 最適なアーキテクチャ 形式化による知識移転 必要なタイミングで獲得 プロダクトごとに機能差異が無い ものは再利用 ナレッジ活用のイメージ
事例: IaCによる共通テンプレートの導入と学び IaCを使えば誰でもProduction Readyな構築を出来るようTerraformの moduleをテンプレートとして提供
事例: IaCによる共通テンプレートの導入と学び 効果 • 1から作るよりも少ない知識で構築を進められた • テンプレートを呼び出すだけなので、素早く構築できる • 有識者のレビューコストの低下 課題
• 利用が増えると個別要件が増え、土管化してしまう • 一定の有識者はmoduleのキャッチアップにコストがかか る • EOSLや新規機能追加によるメンテナンスコストが高い • 良くも悪くも裏側を知らずに使えるので、障害等が発生し た時に対応が難しい。 aurora用の変数の一部 Trivyを利用したPolicy as codeの検証
事例: TrivyによるPolicy as Code 効果 • CICDとルールの導入のみのため、入れやすく外しやすい • PRを通した自動レビューが出来るため、学習しながら Productionに向けたコードが書ける
• カスタムルールによって社内ルールもチェックできる • 対応不要なルールもコメントにWhyを残せるので管理が容易 課題 • ルールの整備のため、いつかTrivy側での対応が必要だった • PRは積極的に受けて入れてもらえるのでとても助かった • 強制力が薄いため運用とセットで広める必要がある。
定期的なイベント実施や情報提供によって、布教活動とクラウドを利 用する人たちの横の繋がりを構築していく AWS Gameday 勉強会 利用可能なナレッジ (インナーソース活動) ナレッジの蓄積/活用を支えるコミュニティ活動 情報発信
基盤チームとの協業 プロダクトへの支援の中でクラウド利活用を支えるために全体に適用す べきものをフィードバックし、実現に向けて協業を行う セキュリティ ガバナンス レピュテーション リスク
取り組みの全体像 プロダクトA プロダクトB プロダクト C 中央レポジトリ クラウド コミュニティ 利用 FB(issue報告/PR)
・ナレッジ共有 ・取り組み共有 ・アップデート情報 Gamedayや勉強会で 繋がりを構築 クラウドアーキテクト グループ 蓄積 クラウド基盤チーム 協業 プロダクト構築 チーム立ち上げ 蓄積 利用可能なナレッジ (インナーソース)