R&Dのアプリケーション基盤 “Circuit”について / About "Circuit", R&D's application platform

◉ 研究開発職 採用情報
募集中のポジションや関連記事など
https://media.sansan-engineering.com/

◉ Sansan Tech Blog
Sansanのものづくりを支えるメンバーのテックブログ（R&Dメンバーの連載も多数）

https://buildersbox.corp-sansan.com/

Transcript

1. Sansan株式会社 部署 名前 R&Dのアプリケーション基盤 “Circuit”について Sansan技術本部 Sansan技術本部 ML Platform Team
2. 研修の⽬的 1 研究開発部のアプリケーション基盤 “Circuit” について知る Q1. Circuitってなに？ Q2. Circuitは何のためにある？ Q3. どんな設計？ Q4. 開発の流れは？ Q5. 何ができる？
3. Q1. Circuitってなに
4. A. R&Dのアプリケーション基盤の名前です 技術： - Kubernetes(k8s) - コンテナオーケストレーション 場所： - AWS EKS - k8sをいい感じにAWS上で使えるようにするサービス Q1. Circuitってなに 3
5. コンテナ化した システムを いい感じに 空きのあるマシンに 載せて実行してくれる ヤツ Kubernetesとは
6. Q2. Circuitは何のためにある？
7. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Q2. Circuitは何のためにある？ 6
8. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Q2. Circuitは何のためにある？(背景) 7
9. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Q2. Circuitは何のためにある？(背景) 8
10. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Q2. Circuitは何のためにある？(背景)
11. 最も大事な こと ~最速でリ リースする ためにある ~ 最も⼤事なこと ~最速でリリースするためにある~
12. A.絶え間なく生まれる研究員による成果を 最速でリリースするため 手段としてEKS(K8s)を選んだに過ぎない Q2. Circuitは何のためにある？ 11
13. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Kubernetes使ってるって言いたい 小難しいことをして仕事している感を出したい 社内で扱っていない技術を使ってイキりたい 研究員に仕事を押し付けたい Q2. Circuitは何のためにある？ 12
14. A.絶え間なく生まれる研究員による成果を 最速でリリースするため Kubernetes使ってるって言いたい 小難しいことをして仕事している感を出したい 社内で扱っていない技術を使ってイキりたい 研究員に仕事を押し付けたい Q2. Circuitは何のためにある？ 13
15. A.絶え間なく生まれる研究員による成果を 最速でリリースするため [よろしくない例] Circuit使っても全然リリース出来ないんだが？ Q2. Circuitは何のためにある？ 14
16. 絶え間なく生まれる研究員による成果を 最速でリリースするため [よろしくない例] ECS, App Runner使ったほうが速いんだが？ Q2. Circuitは何のためにある？ 15
17. 絶え間なく生まれる研究員による成果を 最速でリリースするため [よろしくない例] とにかく使いにくいんだが？ 何のために⽣まれた？ 16
18. 絶え間なく生まれる研究員による成果を 最速でリリースするため ユーザの声を教えてくれ！もっともっと良くなるぞ！ Q2. Circuitは何のためにある？ 17
19. 最も大事な こと ~最速でリ リースする ためにある ~ こんなような話どこかで聞いたな？
20. 機械学習が組み込まれたサービスを利⽤する⼈の視点 - お金を払って利用する顧客，フリーでアプリを利用するユーザ 重要視すること - 自分の環境における精度（全体ではない）．体験が全て - 使い心地 > 予測結果が使いやすいものか？直感に沿うか？ > レイテンシなどの UI/UX に関連する部分 - 自分のデータが勝手に使われていないか？ 感覚的に気持ち悪くないか？ 重要視しないこと - どのようなアルゴリズムが使われているか - 機械学習が使われているかどうか ユーザの視点 R&D研修より抜粋
21. Q2. Circuitは何のためにある？ 20 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai “Platform Enginerringへの招待” というスライドにいいことが書いてある
22. Q2. Circuitは何のためにある？ 21 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai ❝ プラットフォームにとって、価値があるかないかを判断す るのは『プラットフォームの利用者』 開発者に価値を提供できなければ、そのプラットフォーム は失敗している ❞
23. Q3. どんな設計？
24. 最も大事な こと ~最速でリ リースする ためにある ~ Kubernetes⽤語整理
25. コンテナ化した システムを いい感じに 空きのあるマシンに 載せて実行してくれる ヤツ (再掲)Kubernetesとは
26. Podとは Container Container Kubernetesアプリケーションの最小実行単位。Podの中に複数コンテナをい れることもできる。
27. Podが実行される環境。実体はEC2インスタンスやGoogleComputeEngine Nodeとは
28. Nodeの集合 Clusterとは
29. 既存のノードに空きがあるならそこに入る 新しくPodを実⾏したい NodeのvCPU: 40 vCPU: 10 vCPU: 10 vCPU: 10 vCPU: 10 Pending Pods
30. 既存のノードに空きが無いならPodの要求リソースに見合うノードが自動で立ち上がる （Cluster Autoscalerが機能している場合） 新しくPodを実⾏したい NodeのvCPU: 40 vCPU: 10 vCPU: 10 vCPU: 10 vCPU: 10 NodeのvCPU: 20 vCPU: 10 vCPU: 10 New
31. マニフェストを書いてクラスターに適用する マニフェストはリソース定義のこと マニフェストはyaml (json)で記述できる どうやってPodをクラスターに追加するのか
32. 定期バッチのPodをクラスターに追加するマニフェスト例
33. 最も大事な こと ~最速でリ リースする ためにある ~ リソース管理の話
34. マニフェスト(リソースを定義したYAML)は ほぼ 全てGitHubで管理されている 宣⾔的なリソース管理 33 GitHubにないリソースをこっそり作るなよぉという話
35. 名前空間/アプリ名/アプリタイプ/….. ディレクトリ構成 34 名前空間 アプリ名 アプリタイプ(batch,api..) 環境
36. 環境間で共通設定と独⾃設定を分けている Kustomizeというツールを用いて設定のマージを実現 ディレクトリ構成 35 共通設定(マニフェスト) 本番環境独自の設定 (マニフェスト)
37. 最も大事な こと ~最速でリ リースする ためにある ~ デプロイの話
38. Gitを「信頼できる唯一の情報源」とする プルリクエストをmainにマージ＝デプロイ ArgoCDというツールでGitOpsを実現 GitOps 37 今からリリースします！(どきどき)というお遊戯がないという話
39. Gitを「信頼できる唯一の情報源」とする。 プルリクエストをmainにマージ＝デプロイ。 ArgoCDというツールでGitOpsを実現。 GitOps 38 このタコが定期的にGitHubを監視 差分があればCircuitにデプロイする 私、監視されている
40. ArgoCDのUIはCircuitの状態確認に便利。 GitOps 39 画像はArgoCDのドキュメントから引用
41. 最も大事な こと ~最速でリ リースする ためにある ~ クラスタ⾃体の話
42. １つのクラスタで運用 「どのクラスタ使えばいいんだろう」が基本無い(ようにしたい) 開発者はクラスタを気にしなくて良い設計 Circuitは環境毎に１つ バージョンアップ時は一時的に２つになる 名前空間でプロダクトを分離する シングルクラスタマルチテナント 41
43. 概ねプロダクト単位になっている - eight - sansan - ︙ 名前空間 42
44. K8sは年3回リリースがある 雑に言うと2種の更新方法 - in-place - ブルーグリーンデプロイ ← Circuitはこっち EKSのバージョン更新(アーキテクト向け) 43
45. in-place 失敗しても前の家には戻れない in-placeなバージョン更新 44 リフォーム
46. ブルーグリーンデプロイ 失敗したら前の家に戻れる ブルーグリーンデプロイなバージョン更新 45 新しい家を建てて 引っ越す
47. ブルーグリーンデプロイなバージョン更新
48. 最も大事な こと ~最速でリ リースする ためにある ~ 機密情報管理
49. ブルーグリーンデプロイなバージョン更新 マニフェストに機密情報を書かない External Secrets Operatorなるもので AWSのSecrets Managerに保存する GitHubに機密情報はNG
50. Q3. 開発の流れは？
51. 最も大事な こと ~最速でリ リースする ためにある ~ アプリ構築初回
52. A.研究員とArchitectが連携して開発するよ Q3. 開発の流れは？ 51
53. A.研究員とArchitectが連携して開発するよ Q3. 開発の流れは？ 52 ↑ ボトルネックになりがちな所 ↑ デプロイ作業が マージであることに注目 ↑ テンプレートで楽ちん
54. 最も大事な こと ~最速でリ リースする ためにある ~ 継続的なアルゴリズム修正
55. イメージをECRにプッシュすると自動でPRができるぞ Q3. 開発の流れは？ 54 ↑ 自動！
56. Q5. 何ができる？
57. できる - 単発のバッチ - 定期実行バッチ - データの集計とか学習とか - 変則的な手動実行もできる - API、Webアプリケーション - オートスケール - 使用量が増えたらPodを増やす - 負荷分散 - まんべんなくリクエストをPodに割り振る Q5. 何ができる？ 56
58. できない、まだイマイチ - GPUインスタンスの利用 - できなくはないが不整備 - サーバーレス化 - 利用がないシステムはPodを0個までスケールイン - 主にコスト削減 - Comming Soon! Q5. 何ができる？ 57 ※我々ML PlatformチームなのでGPU対応は今後必ずやります
59. 選べるデプロイ⽅法 について語る
60. 新しいバージョンのコードを本番環境にリリースのは不安 - ちゃんと起動するかな？ - 利用負荷に耐えられるかな? - 失敗したら過去のバージョンにすぐ戻せるかな？ - 精度は改善するかな？ Q5. 何ができる？ 59
61. ローリングアップデート 基本はコレ 起動を確認して１つ１つPodが入れ替わっていく(人要らず) Q5. 何ができる？ 60 new versions old versions シフト 交代の時間や 帰りまーす
62. ブルーグリーンデプロイ 古いバージョンはデプロイ後もしばらく待機 待ってる間は古いバージョンにすぐ戻せる(要人間) Q5. 何ができる？ 61 new versions old versions 仕事は交代するけど 店長のNGでたらすぐ 戻ってきて ええよ Argo Rolloutsを利用 ※ここでの店長とは運用者を指す
63. カナリアリリース 任意の割合で部分的にリリース 確認しながら少しずつリリースが進められる(要人間) Q5. 何ができる？ 62 new version old versions とりあえず１人だけ交 代するわ 店長のOKでたら次の Pod呼ぶわ Argo Rolloutsを利用 ※ここでの店長とは運用者を指す
64. プログレッシブデリバリー 任意の割合で部分的にリリース 何らかの指標を確認して少しずつリリースが進む (人要らず) Q5. 何ができる？ 63 new version old versions とりあえず１人だけ交 代するわ 精度のメトリクス見て、 良さそうだったら次 Pod呼ぶわ Argo Rolloutsを利用
65. 研究開発をドライブする Circuit 🚗=33
66. - 仮説検証を高速ぐるぐるしたい - 研究開発をドライブしたい - Gokart(研究開発部でよく使っているOSS)が走る場所 Appendix: なんでCircuit？ 65
67. ArgoCD Image Updater追加 Appendix: Circuitの歴史 66 2021/10 2022/05 2022/07 2022/12 2023/02 アプリ初リリース STG環境のCircuit誕生 MLPチーム誕生 Argo Rollouts追加 初のクラスタ更新開始 EKS作成を決意 本番環境のCircuit誕生