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

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

Recruit
March 25, 2024

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

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

Recruit

March 25, 2024
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. 宮地 克弥 🎮💻📷🚗🐶🏕が好き 経歴 / Career 2017年リクルートホールディングス(現リクルート)新 卒入社。『Airシフト』『Airワーク』『ゼクシィ縁結び』 『社内基盤システム』『レジュメ』などの複数のプロダ クトにてインフラエンジニアとして開発に携わる。

    現在はCCoEとして複数のプロダクトの開発/運用支援に 携わりつつクラウド利活用における横断施策の模索と推 進を行っている 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 インフラソリューションユニット サイトリライアビリティエンジニアリング部 クラウドアーキテクトグループ 自己紹介
  2. 事業組織から見た時の責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private PaaS

    事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア 責任分界点
  3. 事業組織から見た時の責任分界点 責任分界点 DC ネットワーク ストレージ HW 仮想化 データ アプリ Private

    PaaS 事業組織 コスト/ガバナンス 横断組織 OS* ミドルウェア* Private PaaS • 標準化されたアーキテクチャに 乗っかることで、 最小の責任範囲になる • 標準化されていないものを選ぶ 際の難易度がとても高い Public Cloud • 広い権限を持つことで、 個別最適化を行いやすい • 責任を持つべき範囲が広くなる DC ストレージ HW 仮想化 データ アプリ Public Cloud クラウド ベンダー 事業組織 コスト/ガバナンス 横断組織 ネットワーク OS ミドルウェア
  4. SREチーム立ち上げと最適なプロダクト構築をプロジェクトを通して実現する 時間 インフラの関与度 カットオーバー CAGプロダクト支援 事業側開発メンバー リリースに向けて徐々に開発メンバーに役割移管を行い、 プロダクト側で自立出来るよう徐々に移行する 難しい問題には、CAGがスポット支援 アドバイスや解決をする

    設計/構築/運用設計を開発メンバーと協業し、技 術力の向上とチーム運営のナレッジを伝授する Step 2:CAG+事業側開発T伴走での移管 Step 3:事業側開発主導DevOps Step 1:CAG +事業側開発Tでの構築 取り組み 方針 狙い 新規プロダクトの構築支援方針 *CAG: クラウドアーキテクトグループの略称
  5. ナレッジの利用には大きく3パターンがある 形式化による知識移転 必要なタイミングで手に入れる 体験による知識移転 手を動かしながら学ぶ 新規プロダクト構築を通した育成 ex: Policy as Code,

    モブ/ペアプロ 暗黙化による知識移転 裏側を知らずとも利用出来る 共通パーツ ex: メールGW, ウィルススキャン これらを使い分け、クラウド利活用に必要なナレッジを獲得するための 高速道路を構築する ドキュメント化 ex: プロジェクトの進め方, チーム運営, SRE文化,アセスメント 利用可能なナレッジの蓄積
  6. 事例: IaCによる共通テンプレートの導入と学び 効果 • 1から作るよりも少ない知識で構築を進められた • テンプレートを呼び出すだけなので、素早く構築できる • 有識者のレビューコストの低下 課題

    • 利用が増えると個別要件が増え、土管化してしまう • 一定の有識者はmoduleのキャッチアップにコストがかか る • EOSLや新規機能追加によるメンテナンスコストが高い • 良くも悪くも裏側を知らずに使えるので、障害等が発生し た時に対応が難しい。 aurora用の変数の一部 Trivyを利用したPolicy as codeの検証
  7. 事例: TrivyによるPolicy as Code 効果 • CICDとルールの導入のみのため、入れやすく外しやすい • PRを通した自動レビューが出来るため、学習しながら Productionに向けたコードが書ける

    • カスタムルールによって社内ルールもチェックできる • 対応不要なルールもコメントにWhyを残せるので管理が容易 課題 • ルールの整備のため、いつかTrivy側での対応が必要だった • PRは積極的に受けて入れてもらえるのでとても助かった • 強制力が薄いため運用とセットで広める必要がある。
  8. 取り組みの全体像 プロダクトA プロダクトB プロダクト C 中央レポジトリ クラウド コミュニティ 利用 FB(issue報告/PR)

    ・ナレッジ共有 ・取り組み共有 ・アップデート情報 Gamedayや勉強会で 繋がりを構築 クラウドアーキテクト グループ 蓄積 クラウド基盤チーム 協業 プロダクト構築 チーム立ち上げ 蓄積 利用可能なナレッジ (インナーソース)