Slide 1
Slide 1 text
Sansan株式会社
部署 名前
SREが実現する開発者体験の⾰新
~Platform Engineering による
全社横断Platform Orbitの挑戦~
Sansan株式会社
Jincheng Zhang (JC)
Slide 2
Slide 2 text
Jincheng Zhang (JC)
Sansan株式会社
Strategic Products Engineering Unit SREグループ
- 2022年中途⼊社 / データエンジニア → SRE
- 全社データ分析基盤を作ったあと、R&D部⾨でEKS基盤に
関わり、今は全社向けPlatformを構築・推進中
- ⾃称⽇中英トリリンガル
- 筋トレにハマってる
@aibazhang 🌐 kinjo.tech
Slide 3
Slide 3 text
会社概要
2
本社
神⼭ラボ
Sansan Innovation Lab
社 名 Sansan株式会社
所在地 本社
東京都渋⾕区桜丘町1-1 渋⾕サクラステージ 28F
グループ
会社
Sansan Global Pte. Ltd.（シンガポール）
Sansan Global Development Center, Inc.（フィリピン）
Sansan Global (Thailand) Co., Ltd.（タイ）
ログミー株式会社
株式会社ダイヤモンド企業情報編集社
クリエイティブサーベイ株式会社
株式会社⾔語理解研究所
従業員数 1,789名（2024年11⽉30⽇時点）
2007年6⽉11⽇
設 ⽴
⽀店：関⻄⽀店、福岡⽀店、中部⽀店
サテライトオフィス：Sansan神⼭ラボ、Sansan Innovation Lab、
Sansan⻑岡ラボ
拠 点
寺⽥ 親弘
代表者
Slide 4
Slide 4 text
働き⽅を変えるDXサービス
請求
⼈や企業との出会いをビジネスチャンスにつなげる「働き⽅を変えるDXサービス」を提供
ビジネスフローにおけるさまざまな分野でサービスを展開
名刺管理
名刺DX
営業
営業DX
契約
契約DX 経理DX
個⼈向けDX
法⼈向けDX
必要な情報を
すぐに⾒つけられる
情報の管理がしやすく
すぐに共有できる
情報を分析・活⽤しやすく
データに基づいた判断ができる
SansanのDXサービスの活⽤で変わる働き⽅
Slide 5
Slide 5 text
- Platform Engineeringとは
- 社内Platform Orbitの詳細
- 今後の展望
- まとめ
話すこと
Slide 6
Slide 6 text
Platform Engineeringとは
Slide 7
Slide 7 text
SRE, DevOps
Platform Engineering
バズワードが多すぎ問題
Slide 8
Slide 8 text
SRE vs. DevOps
「Seeking SRE: Conversations about Running Production Systems at Scale」より引⽤
Slide 9
Slide 9 text
SRE vs. DevOps
- DevOps
> Forward: 開発者のLaptop -> Production
> ソフトウェアデリバリーの⾃動化をすることで、プロダクトの開発速度を上げる
- SRE
> Backward: Production -> Laptop
> 本番環境の安定性を⾼めるために、パイプラインの改善をする
関⼼事の⽅向性が異なる
Slide 10
Slide 10 text
DevOps vs. Platform Engineering
- DevOps
> インフラ周りの⾯倒を⾒ながら、⽂化を変え、開発者の仕事を楽にする
- Platform Engineering
> 開発者にリソースを与え、開発者が⾃分で運⽤できるようにする
⽅向性は同じだが、⽂化は異なる
Slide 11
Slide 11 text
採⽤チームから⾒ると
みんなサーバを管理する⼈
Slide 12
Slide 12 text
違いを理解しておくのは
重要だが、こだわりすぎ
る必要はない
Slide 13
Slide 13 text
Platformについて
もう少し深く考えよう
Slide 14
Slide 14 text
Platformとは
- “Platforms are a collection of services that help companies get their
software running in front of their customers”*
- 企業が⾃社のソフトウェアを顧客の前で稼働させるのを⽀援するサービス
の集合体
- Platformの要素
> API-first: 全サービスとやり取りできる共通APIを提供
> SDK: アプリ開発しやすいように、APIをSDK化して提供
> CLI: CI/CD、結合テスト、運⽤のためにCLIを提供
> UI: ⾒やすいダッシュボード
*「Platform Engineering on Kubernetes」より引⽤
Slide 15
Slide 15 text
クラウドサービスはPlatform
例えばGoogle Cloud
- API-first: Google Cloud APIs
- SDK: google-cloud-python, google-cloud-go, google-cloud-java
- CLI: gcloud
- UI: Dashboard（いわゆるコンソール）
Slide 16
Slide 16 text
KubernetesもPlatform
Platformを作るためのPlatform or Meta Platform
- API-first: Kubernetes APIs
- SDK: client-go
- CLI: kubectl
- UI: Kubernetes Dashboard, k9s
Slide 17
Slide 17 text
Platform Engineering
開発者がより快適に開発・運⽤できるよう、
Platformを設計・構築・運⽤する領域
*トイル：繰り返し発⽣する⼿間のかかる作業
Slide 18
Slide 18 text
Platformチームと開発チームの関係
顧客ではなく、パートナーに近い
→ Platformチームが開発チームからFBを受け取り、Platformを継続的に改善
→ Platformチームと開発チームのシナジーが組織全体のソフトウェアデリバリ
ーを加速
Slide 19
Slide 19 text
Sansanの話
Slide 20
Slide 20 text
背景
Sansanのプロダクト開発において、開発者の認知負荷の増⼤、運⽤者
のトイル対応の増加が課題となっていた
- Terraform管理の難しさ
- CI/CDパイプラインの属⼈化
- セキュリティとコスト管理への意識不⾜
- ダッシュボードの管理不⾜
- …
Slide 21
Slide 21 text
開発者の認知負荷軽減、リードタイム削減、品質向上を⽬的に、
社内Platform Orbitを⽴ち上げた
- 2024年8⽉に始動
- 2025年2⽉には⼀部のプロダクトで実運⽤を開始
- 今後も、他プロダクトへ順次展開予定
Orbitの誕⽣
Slide 22
Slide 22 text
Orbitのアーキテクチャ
*2025年3⽉時点
Slide 23
Slide 23 text
デプロイフロー（詳細）
Slide 24
Slide 24 text
背景（再掲）
Sansanのプロダクト開発において、開発者の認知負荷の増⼤、運⽤者
のトイル対応の増加が課題となっていた
- Terraform管理の難しさ
- CI/CDパイプラインの属⼈化
- セキュリティとコスト管理への意識不⾜
- ダッシュボードの管理不⾜
- …
Slide 25
Slide 25 text
対策
- Compute / Network / Security といった部分は Platform 側で⼀括管理
- アプリケーションにリソースの調整やhttp routeなどの設定を⾏う
- 開発者はOrbitが提供する Terraform module を使って、Cloud Logging,
Cloud SQL, GCS, Service Account(Workload Identity Pool), Secret
Manager を構築できる
Terraform管理の難しさ
Slide 26
Slide 26 text
Orbitのアーキテクチャ
*2025年3⽉時点
Slide 27
Slide 27 text
対策
- CI/CD パイプラインをテンプレートとして提供し、開発者がすぐに利⽤
できるように整備
- GitHub Actionsのreusable workflow, composite actionsを利⽤
- copier を活⽤することで、新規作成やテンプレートの更新追従を効率化
- Argo CD によるGitOpsを導⼊し、デプロイを⾃動化
- Manifestにあるimage tagの更新はGitHub Actionsから⾏う
CI/CDパイプラインの属⼈化
Slide 28
Slide 28 text
デプロイフロー（⼀部）
Slide 29
Slide 29 text
対策
- GKE Autopilot を採⽤し、本番環境に適したセキュリティ設定や各種ベ
ストプラクティスを⾃動適⽤
- CIパイプラインでは、kubescapeによるマニフェストの脆弱性スキャン
を実施
- こちらもテンプレートとして提供している
- Google GroupベースでGoogle Cloud, Kubernetes, Argo CDの権限を
⼀括管理
セキュリティ管理への意識不⾜
Slide 30
Slide 30 text
対策
- 検証環境ではSpotインスタンスを活⽤
- 夜間は全検証環境のWorkloadを⾃動停⽌し、無駄なリソース利⽤を削減
- NamespaceまたはWorkloadによってコストを按分し、明確に管理
コスト管理への意識不⾜
Slide 31
Slide 31 text
今後の展望
Slide 32
Slide 32 text
全社展開！！！
Slide 33
Slide 33 text
Platformとは（再掲）
- “Platforms are a collection of services that help companies get their
software running in front of their customers”*
- 企業が⾃社のソフトウェアを顧客の前で稼働させるのを⽀援するサービス
の集合体
- Platformの要素
> API-first: 全サービスとやり取りできる共通APIを提供
> SDK: アプリ開発しやすいように、APIをSDK化して提供
> CLI: CI/CD、結合テスト、運⽤のためCLIを提供
> UI: ⾒やすいダッシュボード
*「Platform Engineering on Kubernetes」より引⽤
Slide 34
Slide 34 text
Platformの責務範囲 from Mauricio Salatino⽒
*「Platform Engineering on Kubernetes」より引⽤
Slide 35
Slide 35 text
- GitOps Sync: Argo CD
- Provisioning Cloud Resources: Terraform
- Service Pipelines: GitHub Actions
- Platform APIs
- なし
- 利⽤者にcopier, yaml, GitHub Actions, Skaffoldの習得してもらう必要が
ある
現状
Slide 36
Slide 36 text
- 共通APIは未整備 → ツールの習得が必須
- Self-service には、まだ時間と取り組みが必要
- Self-service化 ≠ トイルを開発側に渡す
- ドキュメントはあるけど、アクセス性や分かりやすさには課題
- リソース割り当ての最適化
全社展開に向けて現在の課題
Slide 37
Slide 37 text
- Platform Engineeringとは開発者がより快適に開発・運⽤できるよう、
Platformを設計・構築・運⽤する領域
- Sansanの開発課題を解決するため、「Orbit」というPlatformを構築
し、⼀部のプロダクトで実運⽤スタート
- CI/CDパイプラインやコンピューティング、ネットワーク、セキュリティ、
コストといった領域の課題をある程度解決
- Self-service化や共通APIの提供など、まだまだ多くのチャレンジが残っ
ている
まとめ
Slide 38
Slide 38 text
SRE・プラットフォームエンジニア
を募集しています
https://open.talentio.com/r/1/c/sansan/pages/77237
Slide 39
Slide 39 text
No content