Sansan株式会社 部署 名前 全てのアプリケーションが "On Best Practice"な 世界を実現する基盤を目指して Sansan技術本部 Sansan技術本部 研究開発部アーキテクトグループ 加藤慶彦

加藤慶彦 X: @discord_tech MLOps Engineer 慶應義塾大学大学院理工学研究科開放環境科学専攻博士後期課 程単位取得退学。 新卒で不動産系IT企業に入社し、Platform Engineerとして全社 基盤のKubernetes clusterの開発に携わる傍ら、実験基盤、実 行基盤、運用基盤から成るMLOps基盤を構築するプロジェクト を立ち上げる。 2023年8月にSansanに入社。 現在はTakowasaチームにてアプリケーション基盤Chassisの開 発に従事。

- Sansan プロダクト紹介

- Eight プロダクト紹介

- Bill One / Contract One プロダクト紹介

プロダクト紹介 データプロダクト、データ活用アプリケーションを提供した未来に思いを馳せる / TakayukiSaruta https://note.com/srt_taka/n/n2d1928848122

Circuit以後の開発 研究開発部Kubernetes基盤「Circuit」 6 Circuit以前の開発 Platform as a productの取り組み / Yuichi Kanbayashi https://speakerdeck.com/sansan_randd/platform-as-a-product-initiative-platform-engineering-at-sansan-r-and-d

共通化したモジュールの更新が難しい 共通化されたモジュール、Streamlitのデザイン等のアップデートを行おうとすると 全アプリケーションの動作確認をする必要がある ライブラリーアップデートも然り 新しいベストプラクティスが反映し辛い Kubernetesチームが新しい手法を導入する 例えば... Istioを導入し、従来のALB + TGBの方法をやめる 浮上してきた問題 7 ALB TGB Ingress Gateway Virtual Service

全アプリケーションが “On Best Practice”な状態を保つ！！！ 決意 8

名前の由来 Circuitで走る車の枠を表現するシャシー 実体 - chassisctl 作ったもの「Chassis」 9 chassisctl manifests actions manifests Application Repo Circuit Repo

運用が肥大化する要因は少しの手間の作業にある 最初は小さいからまあいいかで進めている （理想論）全ての作業を自動化する 開発者が認知負荷を受ける範囲を狭くする ただし、気にしたい開発者はコントロールができる 設計哲学 10

結論: 初手はアプリケーション固有の対応をしつつ、自動化を進める 設計哲学 11 基盤起因の新機能 Circuitで新機能が追加される ↓ chasssictlをupdateする ↓ on-chassisなアプリケーションをupdate アプリケーション起因の新機能 アプリケーション側で新機能が必要になる ↓ アーキテクトor開発者が変更を追加 ↓ chassisctlをupdateする ↓ chassisctlからの生成に切り替える ↓ on-chassisなアプリケーション全体で利用可能に

kubernetesリソースの自動生成 + 自動更新 解決策 12 chassisctl chassis_config.toml fixed_version = "latest" repository_name = "eightcard/randd_hello_chassis" namespace = "samples" [[applications]] name = "randd_hello_chassis" directory = "." service_type = "deployment" environments = ["development", "staging", "production"] env = [{ name = "TARGET", value = "Chassis" }] include_entrusted_data = false use_istio_sidecar = false port = 8080 [applications.pr] enabled = true environments = ["development", "staging", "production"] [applications.pr.used_resources] url_mode = "host" … service_account.yaml deployment.yaml service.yaml gateway.yaml vs.yaml buildコマンド

哲学を守る設計 - 生成されるmanifestsはauto配下に、開発者によるカスタマイズはmanual配下に - チームはmanual配下を無くすようにchassisctlをアップデートする 工夫している点 13 chassisctl auto manual base base overlays 生成 開発者 overlays

Pull Request Environment (Ephemeral Environment) + Auto E2E による更新の安全性の保証 解決策 14 PRを作成 Actions PR Envを作成 URLを返す

Pull Request Environment (Ephemeral Environment) + Auto E2E による更新の安全性の保証 解決策 15 PRを作成 Actions PR Env E2E Job E2EのJobを作成 E2Eテスト 結果を返す

Pull Request Environment (Ephemeral Environment) + Auto E2E による更新の安全性の保証 解決策 16 PRを作成 Actions Takowas a チーム Application Repos chassisctl Repo PRを作成し、 CIを見る

開発者が初回使うときの流れ (無い場合) リポジトリを作成する ↓ chassisctl init を実行する ↓ 自動でPRが各リポジトリに作成される (Circuitの設定のRepo、インフラ定義のRepo、chassisctlのRepo、アプリケーションのRepo) ↓ 各PRがApproveされたらMergeする ↓ サンプルアプリケーションが動き始めるので、自分のアプリに合わせてカスタマイズする 作ったもの「Chassis」 17 chassisctl PR PR PR

開発時の流れ コード、chassis_config.tomlを更新し、chassisctl build ↓ アプリケーションの更新のPRを作成する ↓ PR環境を確認しながら修正 ↓ CIのE2Eテストを通っていることを確認し、Reviewを始める ↓ Mergeされるとimage更新のPRが作成されるのでリリース承認フローを回す ↓ 承認されたらMergeし、リリース 作ったもの「Chassis」 18 chassisctl yaml郡 actions郡 PR

chassisctlのアップデートの流れ chassisctlにupdateのPRを作成する ↓ CIでchassisctlのrepoにあるtarget_list.tomlに記載のあるrepoへPRを作成する ↓ 各ApplicationのrepoでPRが作成される ↓ ApplicationのrepoのCIが通っていたらchassisctlのCIをOKとする ↓ Reviewの後、mergeされたら再度各repoにPRを作成 ↓ 全アプリケーションが最新の状態に保たれる 作ったもの「Chassis」 19 takowasa team PR PR PR

残っている課題、ロードマップ - E2Eテストの結果のリッチ化 - Batchのシャドーテスト機能 - Metrics, Logs, Tracesの収集自動化 - リソースの自動設定 - LLMによるエラー解説 - カナリアリリースの自動化 - リリース承認フローの自動化 今後の課題、展望 20

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/

No content