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

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

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]-[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と同一
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-technologies-un ifying-product-infrastructure-with-google-cloud
78. 株式会社LegalOn Technologies https://legalontech.jp/