Slide 1
Slide 1 text
SRE & Platform / Platform Engineer
Toshinori Sugita
50以上のマイクロサービスを支えるアプリケーション
プラットフォームの設計・構築の後悔と進化
株式会社LegalOn Technologies
Slide 2
Slide 2 text
2
杉田 寿憲 / @toshi0607
株式会社LegalOn Technologies
Platform engineer
Application platform Tech Lead
自己紹介
Slide 3
Slide 3 text
法とテクノロジーの力で、
安心して前進できる社会を創る。
新しいことに挑戦したい。社会の課題を解決したい。
夢がある。私たちはそれぞれに、前に進みたいという素朴な願いを有しています。
LegalOn Technologiesは「法」と「テクノロジー」の力で、
人々が願いに向かって安心して前進できる、より良い社会を創っていきます。
Purpose
LegalOn Technologiesが目指すもの
Slide 4
Slide 4 text
4
プロダクトラインナップ
法務・契約業務支援
法務業務
学習支援
契約業務
経営支援
AIレビューサービス ※LegalOn Technologies 米国法人が提供
AI契約書チェックツール
オンライン法務学習支援サービス
AI契約管理システム
契約学習メディア「契約ウォッチ」
社長向けお悩み相談メディア
「ちょこっと弁護士Q&A」
意思決定プロセスマネジメントシステム
Slide 5
Slide 5 text
5
プロダクトラインナップ
法務・契約業務支援
法務業務
学習支
援
契約業務
経営支援
AIレビューサービス ※LegalOn Technologies 米国法人が提供
AI契約書チェックツール
オンライン法務学習支援サービス
AI契約管理システム
契約学習メディア「契約ウォッチ」
社長向けお悩み相談メディア
「ちょこっと弁護士Q&A」
意思決定プロセスマネジメントシステム
Slide 6
Slide 6 text
6
「LegalOn Cloud」の開発期間は1年間しかなかった！？
2023年3月 4月 8月 2024年
2～3月
β版提供開始
4月
正式版
リリース
キック
オフ
ディスカバリー
要件定義
基礎設計
実現性検証
実装
テスト
脆弱性
診断
記者
会見
Slide 7
Slide 7 text
7
1
2
3
工夫 1年でリリースするための工夫
後悔 直面している課題と後悔
進化 マルチプロダクト・リージョンをサポートする
プラットフォームへの進化のための取り組み
LegalOn Technologiesのアプリケーションプラットフォーム
Slide 8
Slide 8 text
8
1
2
3
工夫 1年でリリースするための工夫
後悔 直面している課題と後悔
進化 マルチプロダクト・リージョンをサポートする
プラットフォームへの進化のための取り組み
LegalOn Technologiesのアプリケーションプラットフォーム
Slide 9
Slide 9 text
9
既存プロダクトを移行するのではなく、実現したいコンセプトに基づいた新設計・新技術ス
タックで開発する
工夫 ～LegalOn Cloud開発の特徴～
一からの構築
3〜4年かけて開発した既存プロダクトの機能に加え、新たな機能を1年で開発してリリース
する
開発期間の短さ
製品機能を開発するチームや、認証、通知などの基盤を開発するチームが同時多発的に開発
する
50以上のマイクロサービスで構築
Slide 10
Slide 10 text
10
サービス横断的な課題をプラットフォームで解決することで、
各チームが探索と実装に集中できるようにする
工夫 ～LegalOn Cloud開発の特徴～
開発ライフサイクルをカバーする標準ツールを整備
開発言語やデータベースなど、サービス毎に自由に技術選定しないことで、
開発や運用の速度や品質を高める
一定の構成でサービスを開発
共通のデプロイ機構や一貫したデプロイ方法をとりながらも、
サービス毎にバージョン管理してボトルネックを減らす
各チーム自律的に開発・デプロイ可能な環境を構築
Slide 11
Slide 11 text
11
工夫 ～アーキテクチャ～
● 共通のGKEクラスタ
● 個別のProject
● レイヤーアーキテクチャ
Gateway
Cloud Load
Balancing
Functional
Service
Fundamental
Service A
Functional
Service
Functional
Service
Fundamental
Service B
Data
Service C
GKE
Pub/Sub
Project A
Pub/Sub Secret
Manager
Project B
Slide 12
Slide 12 text
12
工夫 ～リポジトリ構成～
schema/
proto/
service-a
service-b
services/
service-a
service-b
Application
kubernetes/
platform/
services/
service-a
service-b
terraform
platform/
services/
service-a
service-b
Infra
Slide 13
Slide 13 text
13
工夫 ～CI/CD～
App repo
Infra repo
Namesapce
loc-ns-file-prd
Namesapce
loc-ns-billing-prd
…
Namespace
xxx-ns-svc-a-prd
Namespace
xxx-ns-svc-b-prd …
GKE (Application)
Namesapce
loc-ns-file-prd
Namesapce
loc-ns-billing-prd
…
GKE (DevOps)
push image
fetch manifest
sync
observe
GKE Project
notify
Slide 14
Slide 14 text
14
工夫 ～ソフトウェア開発ライフサイクルに応じた取り組み～
Build Test Deploy Operate
Platform Infrastructure
Proto生成コード管理
言語毎のテンプレート
言語毎のライブラリ
CIテンプレート
Playwright Job
GitOpsデプロイ
DBマイグレーション
単発Jobの実行
モニタリングダッシュボード
ログベースアラート
Production Readiness Check
Kubernetes管理
DB管理
サービスメッシュ
Web Application Firewall
Slide 15
Slide 15 text
15
工夫 ～ソフトウェア開発ライフサイクルに応じた取り組み～
Build Test Deploy Operate
Platform Infrastructure
Proto生成コード管理
言語毎のテンプレート
言語毎のライブラリ
CIテンプレート
Playwright Job
GitOpsデプロイ
DBマイグレーション
単発Jobの実行
モニタリングダッシュボード
ログベースアラート
Production Readiness Check
Kubernetes管理
DB管理
サービスメッシュ
Web Application Firewall
Slide 16
Slide 16 text
16
Proto定義とコード生成は、各チームがAPI合意のために開発の初期に利用
全利用言語向けの生成コードを、
ライブラリとして利用できる環境構築が即座に必要
工夫 ～Protocol Buffers生成コードの管理～
buf CLIとBuf Schema Registry（BSR）を利用した
高開発体験マネージドProto管理基盤を構築
Slide 17
Slide 17 text
17
工夫 ～Protocol Buffers生成コードの管理～
ProtoファイルをBSRに
アップロード
➤サポートされた言語と
プラグインに応じたSDKが
利用可能
Slide 18
Slide 18 text
18
工夫 ～Protocol Buffers生成コードの管理～
複数バージョンのプラグインから生
成されたSDKがホストされており、
ダウンロード時にバージョン指定が
可能
buf CLIにビルドツール、フォー
マッター、リンター、破壊的変更
ツールが含まれており、ローカルで
のフィードバックを容易に獲得
Slide 19
Slide 19 text
19
工夫 ～Protocol Buffers生成コードの管理～
bufbuild/buf-actionがCIで必要
なbuf CLI機能を内包しているた
め、最低限のCIのセットアップも
数行で済む
Slide 20
Slide 20 text
20
工夫 ～サービステンプレート～
アプリケーションリポジトリで50サービスがアプリケーションを初期化す
る
アプリケーションテンプレート
共通ライブラリ
開発ツール
サービス用GitHub Actions workflow
初期化用スクリプト
Slide 21
Slide 21 text
21
● $ go run tools/service-new/main.go -n
SERVICE_NAME -l LANGUAGE
● Kubernetes上で動作するgRPCサーバー
用のアプリケーションテンプレートを開
発
● リンター、DBコンテナ、Pub/Subエミュ
レータ、DBスキーママイグレーションな
ど、ローカル開発に必要なツール一式を
同梱
● 言語毎に最低限必要なCIをComposite
Actionで標準利用でき、サービス固有で
必要なCIはサービスオーナーが追加
工夫 ～サービステンプレート～
.github/
actions
go-test
go-lint
go-build-and-push
workflows
service-a.test-and-lint.yml
service-a.build-and-push.yml
service-a.xxx.yml (固有CI)
services/
service-a
Application
Slide 22
Slide 22 text
22
工夫 ～デプロイの段階的移行～
開発初期はPRマージでどんどんデプロイしたいが、
QAや本番リリースが近づくにつれ厳密にバージョン管理したい
Argo CD Image Updaterによるコンテナイメージ追加をトリガーとするデプロイ
＋
Argo CDのGitOpsによるデプロイ
Slide 23
Slide 23 text
23
工夫 ～デプロイの段階的移行～
Dev
QA
Prd
PRマージ + Image Updater
PRマージ + Image Updater
PRマージ + Image Updater
Gitタグ打ち + GitOps Gitタグ打ち + GitOps
Gitタグ打ち + GitOps
PRマージ + Image Updater
Slide 24
Slide 24 text
24
工夫 ～DBスキーママイグレーション～
アプリケーションのフレームワークや言語非依存で、
Argo CDと併用できる必要がある
ローカル開発でも利用するpsqldefを利用したスクリプトを実行するKubernetes Jobを
Argo CDのpre-syncで実行する
Slide 25
Slide 25 text
25
工夫 ～DBスキーママイグレーション～
services/
service-a/
db/
query/
schema.sql
Application
Pre-sync
Sync
Job
Deployment
Argo CD
Slide 26
Slide 26 text
26
1
2
3
工夫 1年でリリースするための工夫
後悔 直面している課題と後悔
進化 マルチプロダクト・リージョンをサポートする
プラットフォームへの進化のための取り組み
LegalOn Technologiesのアプリケーションプラットフォーム
Slide 27
Slide 27 text
27
直面している課題と後悔
単一プロダクト・単一リージョン展開
マルチプロダクト・マルチリージョンをサポートするプラットフォーム
意思決定プロセスマネジメントシステム ※LegalOn Technologies 米国法人が提供
Slide 28
Slide 28 text
28
直面している課題と後悔
人的拡張性
プロダクト的拡張性
地域的拡張性
Slide 29
Slide 29 text
29
直面している課題と後悔
人的拡張性
● GKE各Namespace内のマイクロサービス用インフ
ラ構築はSREメンバーが担っていた
● サービス名、利用するコンテナ、ワークロード、
利用する外部サービス、接続先などをヒアリング
し、TerraformとKuternetes manifestを記述す
る
● 新規採用技術スタックが多い中、開発初期はコン
テナイメージビルドより後工程を極力意識しない
状態にしていた
Slide 30
Slide 30 text
30
直面している課題と後悔
人的拡張性
今後これまで以上に多くの価値を高品質かつ迅速に届ける必要がある
SREメンバーへの個別サービスインフラ構築依頼構造
徐々に開発者からSREメンバーへのインフラ構築依頼構造はセルフサービスに変わりつつあるが、
マイルストーン実現のためのインフラ構築に多くのパワーを割いておりスケールしない。
横断的課題の解決にも時間を割きづらい。
Slide 31
Slide 31 text
31
直面している課題と後悔
地域的拡張性
● Google Cloud Project IDは30文字の制
限がある中で、他プロダクトととの区
別、Kubernetes Namespaceとの対応関
係、環境区分を表現
● Kubernetes Namespaceはサービス名を
通じてGoogle Cloud Project IDとの対
応関係を表現
サービス
● Google Cloud Project ID
○ [product]-[service]-[stage]-[env]
○ xxx-ns-example-dev-sdbx
● Kubernetes Namespace
○ [service]-[stage]
○ example-dev
プラットフォームコンポーネント
● Google Cloud Project ID
○ [product]-[component]-[env]
○ xxx-example-live
● Google Cloud Project ID
○ plt-[component]
○ xxx-example
Slide 32
Slide 32 text
32
直面している課題と後悔
地域的拡張性
Slide 33
Slide 33 text
33
直面している課題と後悔
地域的拡張性
リージョン拡大に耐えられないプラットフォーム構造
Google Cloud Project IDなど、後から変更しづらい部分に国やリージョンの概念を表現しておら
ず、サポートする地域を追加しづらいプラットフォーム構造になっている。同じ構成で無理に追
加すると、CI/CDなどの開発・運用コストが地域拡大毎に線形に増加する。
さらに、サービス提供地域が拡大しても各地のレギュレーションに準拠した分離要件を維持する
必要がある。
Slide 34
Slide 34 text
34
直面している課題と後悔
プロダクト的拡張性
.github/
actions/
go-test
go-lint
go-build-and-push
workflows/
schema/
proto/
service-a
services/
service-a
kubernetes/
platform/
services/
service-a
service-b
terraform
platform/
services/
service-a
service-b
Slide 35
Slide 35 text
35
直面している課題と後悔
プロダクト的拡張性
LegalOn TechnologiesはLegalOn Cloud以外にも複数のプロダクトを提供している
プロダクト追加の度に一からプラットフォーム構築が必要な構造
LegalOn Cloud向けに準備した開発テンプレート（アプリケーションコードやCI）、APIスキーマ
管理、インフラなどは本来プロダクトに依存しないもの。現状LegalOn Cloudに密結合な状態に
なっておりLegalOn Cloud以外で利用できない。モジュール化しなければコピーもしくは再作成
が必要であり、PMFまでの貴重な時間を車輪の再発明に割くことになってしまう。
Slide 36
Slide 36 text
36
後からなら何とでも言えるが・・・
マルチプロダクト・マルチリージョンをサポートする
アプリケーションプラットフォームの夢は
最初から見ていただけに悔しい…！
直面している課題と後悔
Slide 37
Slide 37 text
37
1
2
3
工夫 1年でリリースするための工夫
後悔 直面している課題と後悔
進化 マルチプロダクト・リージョンをサポートする
プラットフォームへの進化のための取り組み
LegalOn Technologiesのアプリケーションプラットフォーム
Slide 38
Slide 38 text
38
直面している課題と後悔を乗り越え、
マルチプロダクト・マルチリージョンをサポートする
アプリケーションプラットフォームに進化させる！
プラットフォーム進化への取り組み
Slide 39
Slide 39 text
39
プラットフォームの目指す方向性を明確にし、
開発者が認知負荷低く、自律的に開発できるしくみを整える
人的拡張性の確保
Slide 40
Slide 40 text
40
開発者にゴールデンパスと堅牢なインフラを提供し、
創造的な開発に集中できるようにする
人的拡張性の確保 ～アプリケーションプラットフォームのビジョン（v1.0）～
Slide 41
Slide 41 text
41
現在 LegalOn Technologiesの開発者 が 既存・新規のプロダクトやプラットフォーム開発、新し
い地域へのサービス提供 を望むとき、 開発に必要なツール一式やサービス提供に必要なインフラ
を再構築したり、SRE & Plarformメンバーに都度依頼したりしなければならない。
この状況は、車輪の再発明や開発・運用上のボトルネックを生み、開発者やSRE & Plarformメン
バーが本来集中すべき顧客への迅速な価値提供や開発体験の向上に時間を割けないため、受け入
れられない。
我々は、サービスやプラットフォーム開発に必要なインフラを1ヶ月で構築し、開発者が1日で開
発を開始でき、認知負荷低く自律的に開発・運用できる 世界を夢見ている。
我々は 開発ライフサイクル全体をカバーするゴールデンパスと信頼性が高くセキュアでスケーラ
ブルなインフラの提供 を通じて、そのような世界を実現するつもりである。
人的拡張性の確保 ～アプリケーションプラットフォームのビジョンステートメント（v1.0）～
Slide 42
Slide 42 text
42
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
Interface Build Test Deploy Operate
Platform Infrastructure
Proto生成コード管理
言語毎のテンプレート
言語毎のライブラリ
CIテンプレート
Playwright Job
ドキュメント
サポート
Production readiness
check
GitOpsデプロイ
DBマイグレーション
単発Jobの実行
LegalOn Cloud
開発者
モニタリングダッシュボード
ログベースアラート
Kubernetes管理
DB管理
サービスメッシュ
Web Application Firewall
Slide 43
Slide 43 text
43
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
Interface Build Test Deploy Operate
Platform Infrastructure
Proto生成コード管理
言語毎のテンプレート
言語毎のライブラリ
CIテンプレート
Playwrightデプロイ時
自動実行
継続的負荷試験
ドキュメント
サポート
Production readiness
check
トレーニング
オフィスアワー
サービスカタログ
GitOpsデプロイ
DBマイグレーション
単発Jobの実行
Feature flag
依存関係のあるJobの実行
LegalOn Cloud
開発者
モニタリングダッシュボード
SLOベースのアラート
エラー発生時のログ、メトリ
クス、トレース連携
脆弱性通知
コスト把握
暫定権限昇格
Kubernetes管理
DB管理
コスト最適化
セキュリティ認証対応
各種法令準拠
サービスメッシュ
Web Application Firewall
CDN
XXX開発者 YYY開発者
Slide 44
Slide 44 text
44
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
ゴールデンパスのカバレッジ向上
● ゴールデンパスは、Plan -> Build -> Test -> Deploy -> Operateの
ソフトウェア開発ライフサイクルにおいて、標準的に利用できる
ツールやプロセス
● 素早く、迷わず開発・運用できるようにする
● 開発基盤、プロジェクト推進、IT & Secutiryなどのチームと協力し
て進める
Slide 45
Slide 45 text
45
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
開発ライフサイクル各ステップの開発体験向上
● 開発者が自律的に開発・運用できるように、開発ライフサイクル各
ステップの課題を解決し、利用に必要なスキルを身につけるサポー
トをする
● ツール開発・インフラ抽象化、ドキュメント整備、トレーニング、
サポート、オフィスアワーを通じて実現する
Slide 46
Slide 46 text
46
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
高信頼性インフラの安定運用
● プラットフォームを提供するためのサービス横断的なインフラを開
発し、堅牢な状態を維持する
● 可用性、性能・拡張性、運用・保守性、セキュリティ、レギュレー
ション準拠、コストなど、非機能要件 +αを担保・最適化する
Slide 47
Slide 47 text
47
人的拡張性の確保 ～アプリケーションプラットフォームの基本方針～
プロダクト・地域の拡大
● プロダクトが増えても一貫した開発体験と非機能要件 +α 準拠を維
持する
● サービス提供地域が増えても一貫した開発体験と非機能要件 +α 準
拠を維持する
Slide 48
Slide 48 text
48
幅広いユースケースをサポートし、ビジョンを実現するためには
「なんでも柔軟にできる」を目指さない、目指せない
人的拡張性の確保 ～アプリケーションプラットフォームのPrinciple & Practice～
Slide 49
Slide 49 text
49
人的拡張性の確保 ～アプリケーションプラットフォームのPrinciple & Practice～
個別最適よりも全体最適
選択と集中
プラットフォームのプラットフォーム
Slide 50
Slide 50 text
50
人的拡張性の確保 ～アプリケーションプラットフォームのPrinciple & Practice～
個別最適よりも全体最適
● 8割のユースケースをカバーするデフォルトを提供する
○ エッジケースを無理に抽象化・標準化せず、基本要素と組み合わせて利用でき
るようにする（例: starter-kitとサービス固有リソース）
● 同一ユースケース実現のために複数手段を提供しない
○ 開発・サポートを集中させ、開発体験を高める
● 課題を解くべき場所を比較衡量する
○ アプリケーション？インフラ？プロセス？課題に対する異なる領域のアプロー
チを俎上に載せる
Slide 51
Slide 51 text
51
人的拡張性の確保 ～アプリケーションプラットフォームのPrinciple & Practice～
プラットフォームのプラットフォーム
● アプリケーションプラットフォーム以外のプラットフォームが
プラットフォームを提供するためのプラットフォームインフラやコンポーネント
を提供する
● 複雑で専門性の高いサブシステムの開発と運用を担うチームの認知負荷を低減す
る
Slide 52
Slide 52 text
52
人的拡張性の確保 ～アプリケーションプラットフォームのPrinciple & Practice～
選択と集中
● OKRとThe Six Week Cycle
○ 目先の問題解決だけでなく、解決に複数のステップを要するより大きく長期的
な問題を解決することにも意識を向ける
○ 限られた時間の中で、解決することで大きな成果が得られる課題にフォーカス
する
● TVP (Thinnest Viable Platform)
○ 作らずに目的が果たせるなら作らない
Slide 53
Slide 53 text
53
アプリケーションプラットフォームを
開発者をユーザーとするプロダクトとして継続的に育てる
（Platform as a Product）
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 54
Slide 54 text
54
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
本資料は、複写、引用または第三者の閲覧に供される際は株式会社LegalOn Technologiesの了承を得てください。また、当該資料の利用により直接又は間接に生じた損害や損失等について、株式会社LegalOn Technologiesは一切の責任を追いません。 ©LegalOn Technologies, Inc. all rights reserved.
Slide 55
Slide 55 text
55
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Akupara（アクパーラ）
● インド神話に登場する亀の王
● 輪となった大蛇の上に大きな亀がおり、その背中には複数の巨象が
いる。巨象達の背中の上に大地が乗っている
● LegalOn Technologiesのプロダクトや他のプラットフォームをわけ
へだてなくどっしり支えるプラットフォームに思いを馳せて
本資料は、複写、引用または第三者の閲覧に供される際は株式会社LegalOn Technologiesの了承を得てください。また、当該資料の利用により直接又は間接に生じた損害や損失等について、株式会社LegalOn Technologiesは一切の責任を追いません。 ©LegalOn Technologies, Inc. all rights reserved.
Slide 56
Slide 56 text
56
実在する課題を最適な方法で確実に解決するために、
定性的・定量的に課題を把握し、機能追加や改善を周知する
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 57
Slide 57 text
57
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
デベロッパーサーベイ
課題の投稿・投票
ユーザーインタビュー
ベータテスト
リリース
ニュースリリース
Slide 58
Slide 58 text
58
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
● デベロッパーサーベイ
○ 四半期毎に開発ライフサイクル上のユースケースの実現具合の評
価と課題把握を行う
● ユーザーインタビュー
○ デベロッパーサーベイでインタビューに同意いただいた開発者に
対して行う
○ オフィスアワー時や取り組む課題に直面しているチームや個人に
随時行う
Slide 59
Slide 59 text
59
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
● 課題の投稿と投票
○ GitHub public roadmapのようなボードで課題投稿、👍による投
票、実際に困ったシーンの共有やディスカッションができるよう
にする
● ベータテスト
○ 全体利用開始前にインターフェースや機能に問題がないかの検証
に協力してもらう
● ニュースリリース
○ 新しく利用できるようになったゴールデンパス、改善されたユー
スケース、活用事例を周知する
Slide 60
Slide 60 text
60
● 開発ライフサイクルでサポートされるユースケース
● ユースケースを実現するアプリケーションプラットフォーム
の機能やツールセット
● ユースケースの実現を阻害する課題
● 課題の優先度と解決時期
人的拡張性の確保 〜ロードマップの可視化〜
開発者にとってAkuparaが
「自分たちの開発ライフサイクル上の課題を継続的に解決してくれるプロダクト」
になるように可視化する
Slide 61
Slide 61 text
61
アプリケーションプラットフォームのロードマップ
Slide 62
Slide 62 text
62
プラットフォームをプロダクトとして提供することで、
開発者がSRE & Platformメンバーへの依頼を介さずに
開発ライフサイクルを認知負荷低く、自律的に回せるようにする
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 63
Slide 63 text
63
Build
Service A
Module Aチーム
Test
Build
Service B
Test
Module Bチーム
Deploy config Operate
SRE & Platform
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 64
Slide 64 text
64
Build
Service A
Module Aチーム
Test
Build
Service B
Test
Module Bチーム
Deploy Operate
Deploy Operate
Platform
SRE & Platform
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 65
Slide 65 text
65
Service Infra
Kubernetes, Service Mesh, etc.
SRE & Platform
Service Tenant
K8s Namespace, Service Account, GCP project, Pub/Sub,
etc.
Service Workload
K8s Deployment, k8s Service, K8s HPA, K8s PDB, etc.
プロダクトチーム
Starter-kit
Terraform
k8s_gen
Kustomize
Layer & components
Developer
Interface
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
Slide 66
Slide 66 text
66
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
プロダクトチーム プラットフォームチーム
責
任
範
囲
● 自サービス固有のアプリケーショ
ンとインフラの構築
● テスト
● CIワークフロー設定
● CD設定
● トラブルシューティング
● SLOの維持
● プロダクトチームの責任範囲達成のた
めにツールセット提供
● 共通インフラの運用
● 問題解決のサポート
● 信頼性を担保するためのプラクティスの
イネーブルメント
Slide 67
Slide 67 text
67
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
● チームの状況やコンポーネントに応じて段階的にインタラクション
を変化させる
● コラボレーション -> ファシリテーション ->
X-as-a-Service/Self-service
図は『チームトポロジーズ 』chapter 7より
プロダクトチーム
プラットフォームチーム
Slide 68
Slide 68 text
68
プラットフォームのビジョンに基づいた構造への移行
地域的拡張性の確保
Slide 69
Slide 69 text
69
地域的拡張性の確保 ～Google Cloud Projectと関連リソースの新命名規約の採用～
サービス
● Google Cloud Project ID
○ [product]-[service]-[stage]-[env
]
○ xxx-ns-example-dev-sdbx
● Kubernetes Namespace
○ [service]-[stage]
○ example-dev
プラットフォームコンポーネント
● Google Cloud Project ID
○ [product]-[component]-[env]
○ xxx-example-live
● Google Cloud Project ID
○ plt-[component]
○ xxx-example
サービス
● Google Cloud Project ID
○ [product]-[service]-[country]-[stage]
○ xxx-example-jp-dev
● Kubernetes Namespace
○ Google Cloud Project IDと同一
プラットフォームコンポーネント
● Google Cloud Project ID
○ [product]-[service]-[country]-[env]
○ xxx-example-jp-sdbx
● Kubernetes Namespace
○ Google Cloud Project IDと同一
プラットフォームコンポーネント（地域横断）
● Google Cloud Project ID
○ [product]-[service]-[env]
○ xxx-example-sdbx
● Kubernetes Namespace
○ Google Cloud Project IDと同一
Slide 70
Slide 70 text
70
地域的拡張性の確保 ～インフラ、サービス、フォルダ構成の大移動～
Slide 71
Slide 71 text
71
プロダクト横断的なコンポーネントの特定と切り出し
プロダクト的拡張性の確保
Slide 72
Slide 72 text
72
プロダクト的拡張性の確保 ～コンポーネントの洗い出し～
Slide 73
Slide 73 text
73
プロダクト横断的なProto管理基盤への移行
xxx-app
BSR
yyy-app
zzz-pf
upload .proto
fetch .proto
use .proto
internally
GitHub
Packages
akp-proto
yyy-app
xxx-pf
build .proto and
upload generated code
zzz-app
use package use package
Slide 74
Slide 74 text
74
拡張性のあるプラットフォームをつくるために
DevOpsやセルフルサービスなど、方向性を明示する。
開発者とプラットフォームで最適な関係を探っていく。
過渡期であっても理想とする姿を示して進む
ハードパーツの設計は中長期を見据える
不確実性はあるにせよ、後から変更しづらい部分は短期スコープで意思決定しない。
もしくは移行を覚悟する。
個別最適化にあらがう
デリバリーのスケジュールやチームの責務から個別最適化の力学は働きやすい。
コンポーネントの特定のユースケースとらわれず全体を見据える。
Slide 75
Slide 75 text
75
Platform Engineering Advent Calendar 2024
https://qiita.com/advent-calendar/2024/platform-engineering
Slide 76
Slide 76 text
76
Google Cloud Next Tokyo '24
https://cloudonair.withgoogle.com/events/next-tokyo-24?talk=d1-app-02
Slide 77
Slide 77 text
77
Google Cloud 顧客事例
https://cloud.google.com/blog/ja/topics/customers/legalon-techno
logies-unifying-product-infrastructure-with-google-cloud
Slide 78
Slide 78 text
株式会社LegalOn Technologies
https://legalontech.jp/