アーキテクチャ概要¶
Azure 上の AMS は、1 つの Kubernetes クラスタ、1 つの AMS ホスト名、少数のプラットフォームサービスを共有する Helm チャート群です。
flowchart TB
users[ユーザーのブラウザ] --> agw[Application Gateway / Ingress]
agw --> rootIngress[インフラ Ingress /]
rootIngress --> primary[プライマリモジュール UI]
agw --> modulePaths[モジュール別パス Ingress]
modulePaths --> cc[Command Center]
modulePaths --> are[ARE]
modulePaths --> eobs[EOBS]
modulePaths --> fortify[FortifyOps]
users --> keycloak[Keycloak SSO]
cc --> keycloak
are --> keycloak
eobs --> keycloak
fortify --> keycloak
adapters[任意のアダプター] --> otel[OTEL / オブザーバビリティ]
platforms[任意の Dify LibreChat Langfuse] --> adapters
cc --> otel
are --> otel依存の順序¶
後の層は前の層がある前提です。次の順で入れます（または確認します）。
- Azure / Kubernetes 基盤 — AKS、ネットワーク、Ingress コントローラ（多くは AGIC）、DNS、TLS、レジストリ、必要なら Key Vault CSI、PostgreSQL やオブジェクトストレージ
- オブザーバビリティ —
ams-helm-observability-stack - Keycloak —
ams-helm-keycloak-application - 選択したアプリモジュール — Command Center、ARE、EOBS、FortifyOps
- インフラ Ingress —
ams-helm-infrastructure-ingress（root.moduleをプライマリに設定） - アダプター（任意）
- セルフホストプラットフォーム（任意） — Dify、LibreChat、Langfuse
Ingress のタイミング
値は早めに用意して構いませんが、プライマリモジュールの Service ができてから適用（または再適用）すると / のバックエンドが健全になりやすいです。
1 ホスト・複数パス¶
すべてのモジュールは1 つの DNS 名を共有します（例: ams.example.com）。
- インフラ Ingress は
/のみを担当し、root.moduleで選んだ Service へ送ります。 - 各モジュールチャートが自身のパス付き Ingress（API や UI プレフィックス）を持ちます。
root.module |
ランディング（要約） |
|---|---|
command-center |
フロントエンド Service が / |
eobs |
EOBS UI パスへリライト |
fortifyops |
FortifyOps UI パスへリライト |
are |
ARE UI パスへリライト |
アダプターとモジュール¶
| 種類 | ユーザー向け UI? | 役割 |
|---|---|---|
| アプリモジュール | はい | 顧客が使う製品 UI / API |
| アダプター | いいえ | 上流システムを読み、テレメトリを（多くは OTEL へ）送るワーカー |
| プラットフォーム（Dify / LibreChat / Langfuse） | 多くの場合はい | 作成・チャット・トレーシング。アダプターやモジュールが連携 |
シークレットと設定¶
顧客リリースでは各チャートの providers/azure/release/（またはチームのオーバーレイ）を使うのが一般的です。パスワード類は Azure Key Vault や Kubernetes Secret に置き、Git には入れません。本ガイドは概念とキーを示し、実クレデンシャルは扱いません。