50以上のマイクロサービスを支えるアプリケーションプラットフォームの設計・構築の後悔と進化 #CNDW2024 / regrets and evolution of application platform

CloudNative Days Winter 2024の登壇資料です。
https://event.cloudnativedays.jp/cndw2024

動画のアーカイブはこちらです。
https://event.cloudnativedays.jp/cndw2024/talks/2421

Transcript

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