SREが実現する開発者体験の革新

■ イベント
生成AI時代のSRE【サポーターズCoLab】
https://supporterz-seminar.connpass.com/event/347921/

■ 発表者
技術本部 Strategic Products Engineering Unit SREグループ
Jincheng Zhang

■ 技術本部 採用情報
https://media.sansan-engineering.com/

Transcript

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