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

SalesForceを内製化!? ~ HR事業を支える顧客管理基盤のインフラを大公開 ~

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
Avatar for Kobujee_53 Kobujee_53
September 29, 2026

SalesForceを内製化!? ~ HR事業を支える顧客管理基盤のインフラを大公開 ~

月末 Tech Lunch Online #17(2026/9/30)登壇資料。
約7年運用した Salesforce を、人材事業に合わせて内製した CRM「Orion」に置き換えた話を、Google Cloud のインフラ面から紹介します。
GKE Autopilot でアプリチームが触る範囲を Deployment に限定した運用分担、AlloyDB の閉域接続(PSC)・Read Pool の読み書き自動振り分け・Managed Connection Pooling の活用、そして「マネージドを選ばなかったら何が必要だったか」の比較まで。少人数・短期間で基幹システムのインフラをシンプルかつ堅牢に作るための選択をまとめました。

Avatar for Kobujee_53

Kobujee_53

September 29, 2026

More Decks by Kobujee_53

Other Decks in Programming

Transcript

  1. PROFILE ⾃⼰紹介 奥 琉之介 株式会社Hajimari ∕ GOAT Cloud事業部 技術責任者 以前はSREチーム⽴ち上げ

    アプリ〜インフラ横断で開発‧運⽤ 最近は新規事業⽴ち上げ Google パートナー事業でSA業務 𝕏 @Kobujee_53 Google Cloud導⼊頑張った軌跡が 記事になりました ⽉末 Tech Lunch Online#17 AWS から G 移⾏した oogle Cloud へ 理由 AI Profe ssionals ↗ 02 / 14
  2. CRM ⼈材事業の業務に合わせて CRM を再設計 Salesforce での管理 ⼈材事業で必要な管理 顧客 単⼀の顧客(取引先)が中⼼ ⼈材と企業、両⾯に顧客がいる

    業務の単位 商談 ⼈と企業のマッチング 7年の結果 オブジェクトとカラムが増加し、 運⽤が属⼈化 業務フローから再モデリング システム 連携 CRM 単体で完結 登録 → CRM → 営業管理 → 稼働管理の中⼼に CRM ⽉末 Tech Lunch Online#17 03 / 14
  3. CRM CRM を内製化した理由 課題 約7年の運⽤で属⼈化 オブジェクトとカラムが増加 再設計 業務フローを → 再モデリング

    CRM をプロダクト連携の中⼼へ 移行 開発‧移⾏含めて → 2年弱をかけ、9⽉に 完全移⾏を達成 Orionとは ⼈材事業の顧客管理基盤 ⽉末 Tech Lunch Online#17 04 / 15
  4. GKE GKE Autopilot と Cloud Run Jobs の使い分け 常駐プロセス 単発のジョブ

    選定理由: 常駐プロセスがある∕スケール設定の⾃由度∕ノード運⽤を持たない API+常駐のジョブキュー バッチ‧重い処理 GKE Autopilot Cloud Run Jobs アプリのデプロイは CI/CD で⾃動化。 Deployment 以外の k8s リソースは SRE が管理 Terraform に1⾏追加でデプロイ可能 → CI/CD で反映 多重実⾏の防⽌‧リトライ‧タイムアウトはマネージドサービスに任せ、API とはリソースを分離 ⽉末 Tech Lunch Online#17 08 / 15
  5. ALLOYDB AlloyDB の閉域接続とアクセス制御 → ネットワーク構成は最⼩限にし、IAM で「誰が繋げるか」を制御 VPC 内(インターネット非公開) GKE Autopilot(API)

    → ETL(別プロジェクト) → Cloud Build (Private Worker Pool) → 踏み台 (IAP + Auth Proxy + Workload Identity) → Private Service Connect AlloyDB → Primary Read Pool 接続経路を集約 プロジェクト単位で接続を許可 ⽉末 Tech Lunch Online#17 11 / 15
  6. ALLOYDB Read Pool と Primary の接続を分離 アプリケーションの DB Client 層で接続先を⾃動で選択できる仕組みを作成

    処理の種類に応じて Read Pool / Primary へ振り分ける 参照系の処理 書き込み系 書き込み直後の検証 → → Read Pool 書き込みを拒否 型チェック + ランタイム Managed Connection Pooling PgBouncer 互換の コネクションプール Primary 遅延による誤判定を防⽌ Managed の機能を活⽤ 参照系の接続では書き込みメソッドが型から消えている(create / createMany… が型エラー) ⽉末 Tech Lunch Online#17 12 / 15
  7. MANAGED マネージドを選ばなかったら、何が必要だったか 領域 今回の選択 選ばなかった場合に必要だったこと API 実⾏基盤 GKE Autopilot GKE

    Standard:ノードプール設計‧アップグレード‧ パッチ適⽤を SRE が継続運⽤ バッチ Cloud Scheduler + Cloud Run Jobs k8s CronJob / Job:アプリチームが新しいリソース種を学習、 多重実⾏対策を⾃前で DB AlloyDB(Primary + Read Pool、 Managed Connection Pooling) Cloud SQL または⾃前 PostgreSQL:PgBouncer を⾃前運⽤、 レプリカ振り分けとフェイルオーバーを⾃前設計 閉域接続 Private Service Connect (プロジェクト単位で許可) VPC ピアリング網:本番‧ETL‧リハーサル間で CIDR 調整、 推移的ピアリング不可の回避 シークレット External Secrets + Workload Identity k8s Secret の⼿動配布、または SA キーの配布 LB / TLS Gateway API (マネージド LB‧証明書) Ingress controller と証明書更新を⾃前運⽤ ⾃前で運⽤しているミドルウェア(ノード‧プーラー‧LB‧証明書)はゼロ ⽉末 Tech Lunch Online#17 13 / 15
  8. GKE / ALLOYDB まとめ GKE:アプリチームの操作範囲を Deployment に限定。 バッチは Cloud Run

    Jobs に分け、SRE が可⽤性とスケーリングを継続的に調整 AlloyDB:閉域接続‧読み書き分離‧接続管理の、レイヤーごとに Managed の 機能をフル活⽤ マネージドサービスの活⽤でインフラをシンプルかつ堅牢に ⽉末 Tech Lunch Online#17 14 / 15