横断組織から見たリクルートのインフラの歴史と目指すべきクラウド活用像

2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、宮地の資料です。

Transcript

1. 横断組織から見たリクルートの インフラの歴史と目指すべきクラウド活用像 プロダクトディベロップメント室 インフラソリューションユニット 宮地 克弥
2. 宮地 克弥 🎮💻📷🚗🐶🏕が好き 経歴 / Career 2017年リクルートホールディングス（現リクルート）新 卒入社。『Airシフト』『Airワーク』『ゼクシィ縁結び』 『社内基盤システム』『レジュメ』などの複数のプロダ クトにてインフラエンジニアとして開発に携わる。 現在はCCoEとして複数のプロダクトの開発/運用支援に 携わりつつクラウド利活用における横断施策の模索と推 進を行っている 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 インフラソリューションユニット サイトリライアビリティエンジニアリング部 クラウドアーキテクトグループ 自己紹介
3. 目次 • 自己紹介 • リクルートの開発体制とインフラの歴史 • リクルートにおけるインフラ選定とクラウドを使う理由 • CCoEの取り組み
4. リクルートの歴史 リクルート公式サイトより 約60年の歴史がある会社であり、紙メディアを始め、メディア形態や業務領域を変革し、現在では SaaSやマッチングプラットフォームの展開を行なっている
5. リクルートにおける開発体制の多様さ プロダクトの種類や開発体制は様々な形が存在する https://speakerdeck.com/rtechkouhou/duo-yang-nabizinesudomein-sabisuhuezuga-hun-zai-suruzhong- defalsezu-zhi-zhan-lue-toji-shu-zhan-lue?slide=14 より
6. 開発組織の体制 主に事業側組織と横断組織に分かれており、自身の所属する組織は 横断組織に位置している 事業組織A 事業組織B 事業組織C 事業組織D 横断組織 クラウドアーキテクト グループ
7. リクルートにおけるインフラの選択肢
8. リクルートにおけるインフラの選択肢 Private Cloud上で動くPaaS環境 パブリッククラウド
9. リクルートにおけるインフラの選択肢 Private Cloud上で動くPaaS環境 ->標準化されたアーキテクチャを採用したい パブリッククラウド ->標準化の枠に収まらないアーキテクチャや、個別最適化を行いたい
10. 事業組織から見た時の責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private PaaS 事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア 責任分界点
11. 事業組織から見た時の責任分界点 責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private PaaS 事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* Private PaaS • 標準化されたアーキテクチャに 乗っかることで、 最小の責任範囲になる • 標準化されていないものを選ぶ 際の難易度がとても高い Public Cloud • 広い権限を持つことで、 個別最適化を行いやすい • 責任を持つべき範囲が広くなる DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア
12. Public Cloudを選択する上で重要なこと 責任 広い権限には責任が伴う PaaSが担ってくれた部分は自分たちで守る必要がある 責任を果たすための体制 責任を果たす為に様々なスキルを持つメンバーが必要 これらを持つ覚悟を持ったプロダクトを CCoEが全力で支援する
13. CCoEの取り組み
14. CCoEの取り組み CCoEとして、大きく二つの活動を実施 • プロダクト開発支援 • 横断活動
15. SREチームの 立ち上げ 最適なプロダクト 構築 事業にとって最適なプロダクト構築と SREチームの立ち上げの実施 構築後も安定してプロダクト運用が出来る 体制を目指す プロダクト開発支援
16. 技術だけじゃなく多様な観点から選定と実装を担う 最適なプロダクト構築に必要な要素 プロダクトの要件 チームのスキルセット 社内ルール準拠 事業としてのチャレンジ
17. 技術力 SRE文化 チーム運営 将来的な運用を担うチームをプロダクト構築を通して立ち上げる SREチームの立ち上げの実施 https://www.oreilly.co.jp/books/9784873117911/
18. SREチーム立ち上げと最適なプロダクト構築をプロジェクトを通して実現する 時間 インフラの関与度 カットオーバー CAGプロダクト支援 事業側開発メンバー リリースに向けて徐々に開発メンバーに役割移管を行い、 プロダクト側で自立出来るよう徐々に移行する 難しい問題には、CAGがスポット支援 アドバイスや解決をする 設計／構築／運用設計を開発メンバーと協業し、技 術力の向上とチーム運営のナレッジを伝授する Step 2：CAG＋事業側開発T伴走での移管 Step 3：事業側開発主導DevOps Step 1：CAG ＋事業側開発Tでの構築 取り組み 方針 狙い 新規プロダクトの構築支援方針 *CAG: クラウドアーキテクトグループの略称
19. 横断的な活動
20. 利用可能なナレッジ 個々のナレッジ 蓄積 人に依存した支援は持続性・質・スケールに課題がある ナレッジを蓄積し、利用可能な状態へ変換することで持続可能なエコシステムを 構築する 横断組織としての課題 展開 複数組織でのナレッジ活用 派生
21. ナレッジの利用には大きく3パターンがある 形式化による知識移転 必要なタイミングで手に入れる 体験による知識移転 手を動かしながら学ぶ 新規プロダクト構築を通した育成 ex: Policy as Code, モブ/ペアプロ 暗黙化による知識移転 裏側を知らずとも利用出来る 共通パーツ ex: メールGW, ウィルススキャン これらを使い分け、クラウド利活用に必要なナレッジを獲得するための 高速道路を構築する ドキュメント化 ex: プロジェクトの進め方, チーム運営, SRE文化,アセスメント 利用可能なナレッジの蓄積
22. 体験による知識移転 プロダクトチーム 暗黙化による知識移転 スキルの底上げ 最適なアーキテクチャ 形式化による知識移転 必要なタイミングで獲得 プロダクトごとに機能差異が無い ものは再利用 ナレッジ活用のイメージ
23. 事例: IaCによる共通テンプレートの導入と学び IaCを使えば誰でもProduction Readyな構築を出来るようTerraformの moduleをテンプレートとして提供
24. 事例: IaCによる共通テンプレートの導入と学び 効果 • 1から作るよりも少ない知識で構築を進められた • テンプレートを呼び出すだけなので、素早く構築できる • 有識者のレビューコストの低下 課題 • 利用が増えると個別要件が増え、土管化してしまう • 一定の有識者はmoduleのキャッチアップにコストがかか る • EOSLや新規機能追加によるメンテナンスコストが高い • 良くも悪くも裏側を知らずに使えるので、障害等が発生し た時に対応が難しい。 aurora用の変数の一部 Trivyを利用したPolicy as codeの検証
25. 事例: TrivyによるPolicy as Code 効果 • CICDとルールの導入のみのため、入れやすく外しやすい • PRを通した自動レビューが出来るため、学習しながら Productionに向けたコードが書ける • カスタムルールによって社内ルールもチェックできる • 対応不要なルールもコメントにWhyを残せるので管理が容易 課題 • ルールの整備のため、いつかTrivy側での対応が必要だった • PRは積極的に受けて入れてもらえるのでとても助かった • 強制力が薄いため運用とセットで広める必要がある。
26. 定期的なイベント実施や情報提供によって、布教活動とクラウドを利 用する人たちの横の繋がりを構築していく AWS Gameday 勉強会 利用可能なナレッジ (インナーソース活動) ナレッジの蓄積/活用を支えるコミュニティ活動 情報発信
27. 基盤チームとの協業 プロダクトへの支援の中でクラウド利活用を支えるために全体に適用す べきものをフィードバックし、実現に向けて協業を行う セキュリティ ガバナンス レピュテーション リスク
28. 取り組みの全体像 プロダクトA プロダクトB プロダクト C 中央レポジトリ クラウド コミュニティ 利用 FB(issue報告/PR) ・ナレッジ共有 ・取り組み共有 ・アップデート情報 Gamedayや勉強会で 繋がりを構築 クラウドアーキテクト グループ 蓄積 クラウド基盤チーム 協業 プロダクト構築 チーム立ち上げ 蓄積 利用可能なナレッジ (インナーソース)