Git と API

Platform City を構成する情報には、大きく分けて 2 つの種類が存在します。クラスタ基盤を支える「静的な設定」と、参加者ごとに生成される「動的なテナントデータ」です。前者は Git を唯一の信頼できる情報源（Single Source of Truth）として管理し、後者は API を通じて動的に投入されます。これらを単一の手法で一括りにせず明確に分離しているのは、両者のライフサイクルと更新頻度が根本から異なるためです。

クラスタ基盤の設定は GitOps で宣言的に管理する

共有ロードバランサー（ALB）の構成、監視基盤、デプロイメントの制御機構、街の区画定義といったインフラの根幹に関わる設定は、すべて Git リポジトリ上で宣言的に管理されています。

あらゆる基盤の変更は Git へのコミットやマージリクエストを通じて行われ、クラスタ側の状態は ArgoCD などの GitOps ツールによって自動的に同期されます。クラスタ上のリソースを kubectl 等で直接手作業で変更しても、Git との差分が検知され、自動的に正規の状態へとロールバック（巻き戻し）されます。

この運用の最大の強みは、Git リポジトリを閲覧するだけで現在のインフラ環境の全貌が完全に把握でき、誰がいつどのような理由で変更を加えたのかという変更履歴が厳密に残る点にあります。基盤構成は変更頻度が比較的低く、変更ごとにレビューと承認を挟む価値が高いため、GitOps による静的管理が極めて適しています。

動的なテナント情報は API 経由で即時プロビジョニングする

一方で、参加者がエージェントから onboard を実行するたびに生成されるテナント情報は、性質がまったく異なります。

もしテナントの追加まで GitOps で管理しようとすると、新しい参加者が増えるたびに Git へのコミット、MR の作成、CI による検証、マージ、そしてクラスタへの同期という重いパイプラインを回さなければなりません。100 人以上の参加者が一斉にオンボーディングを開始するイベントにおいて、Git を書き込みキューとして使用することは深刻なボトルネックを引き起こします。

そのため、テナントの生成は制御プレーンの API を通じて直接実行されます。onboard が呼び出されると、API が即座にテナントのカスタムリソースを作成し、GitLab 上のグループやプロジェクト、専用の公開サブドメイン、リソース Quota などを瞬時に払い出します。人間の承認はもちろんのこと、Git への直列なコミット待ちに阻まれることもありません。

API 投入後のリソースもコントローラが自律的に調和させる

API 経由で動的に投入されたテナント情報であっても、作られっぱなしで放置されるわけではありません。Kubernetes の Custom Resource（CR）として保持されたテナント定義に基づき、コントローラ（Operator）が Kubernetes Namespace や RBAC 権限、ネットワークポリシーなどの実リソースを自動的にプロビジョニングし、期待される状態とのズレが生じれば自律的に修復（Reconcile）します。

Git リポジトリを経由しない動的データであっても、このコントローラの継続的な調和ループによってシステムの冪等性と堅牢性が保証されています。

このアーキテクチャの境界線は、檻と自律 で述べた決定論的なシステム設計の思想と深く結びついています。静的な構成管理は Git に、動的なデータプレーンは API に――それぞれの特性に応じた最適な責務分離を行うことで、高い俊敏性と堅牢性の両立を実現しています。