VM のみの展開（OpenShift なし）
すべてのサイトが Kubernetes を運用しているわけではありません。ハイパーバイザー （VMware、Proxmox、Nutanix、KVM/OpenStack）のみを利用でき、通常の 仮想マシン を 好む場合、DuoKey は VM のみのトポロジーで展開できます。コンポーネントは OpenShift リファレンスアーキテクチャ と同じで、OpenShift クラスターの 代わりに VM 上のコンテナ（Podman/Docker）としてパッケージされます。
スタックは小規模です。React フロントエンド（UI）、単一のバックエンドである Cockpit API（DKE / KMS / KMIP / ACME-EST / XKS の各エンドポイントをまとめて提供）、 PostgreSQL、Redis、シークレット用の OpenBao、加えて GitOps （ArgoCD / GitLab）、オプションの Harbor レジストリ、可観測性のための VictoriaMetrics / VictoriaLogs、そして展開に必要な場合には専用の鍵保管バックエンドと してのオプションの DuoKey MPC KMS クラスター（3 ノード以上）で構成されます。
鍵の保管はデフォルトで組み込みの Software Vault を使用するため、追加で展開する クラスターはありません。専用またはハードウェアに支えられた鍵保管層が必要な場合は、 オプションの DuoKey MPC KMS（DuoKey 独自のマルチパーティ計算クラスター。3 ノード以上、 鍵はシェアに分割され、単一のノードが完全な鍵を保持することは決してありません）または Securosys HSM を追加してください。 前提条件 → 鍵の保管 を参照してください。
DuoKey MPC KMS は DuoKey 独自 のクラスター（サードパーティの Sepior TSM ではありません） であるため、これを追加しても MongoDB、Audit Node、KMaaS ポータルは不要 です（これらは Sepior 固有のコンポーネントです）。フロントエンドは Angular ではなく React です。
- OpenShift — 大規模／エンタープライズ 規模、自己修復、オートスケーリング、 GitOps 主導の運用に推奨されます。 リファレンスアーキテクチャ を参照してください。
- VM のみ — パイロット、標準、中規模 の展開、あるいは Kubernetes プラットフォームを 持たないサイト向けの軽量な構成です。クラスターに依存する代わりに、VM/LB 層で HA を 自ら担います。このページではそのモデルを説明します。
単一サイトのアーキテクチャ
ステートレスな層（UI と API）は ロードバランサー VIP の背後に配置され、別々の ハイパーバイザーホスト上で N+1 のレプリカとして稼働します。ステートフルな層はそれぞれ 独自の HA を持ちます（PostgreSQL のプライマリ + レプリカ、OpenBao Raft、Redis Sentinel）。
ステートレスな UI と API はロードバランサー VIP の背後で N+1 構成で稼働します。API は鍵の保管、PostgreSQL、Redis、OpenBao と通信し、その傍らで ArgoCD と可観測性スタックが動作します。
VM のロールとサイジング
各行は VM あたり のサイズと、高可用性構成における 最小台数 を示します。数値は 前提条件 のコンポーネント別サイジングと一致しています。
| ロール | 台数（HA） | VM あたり vCPU | VM あたり RAM | ディスク | 備考 |
|---|---|---|---|---|---|
| ロードバランサー / リバースプロキシ | 2 | 2 | 4 GB | 20 GB | アクティブ／スタンバイの VIP（keepalived）。HAProxy / Nginx / F5 |
| Cockpit UI（React フロントエンド） | 2 | 2 | 4 GB | 20 GB | ステートレスな SPA |
| Cockpit API バックエンド | 3 | 4 | 8 GB | 20 GB | Cockpit の管理機能 + DKE / KMS / KMIP の鍵エンドポイント。ホットパスです |
| DuoKey MPC KMS ノード（オプション） | 3 | 4 | 8 GB | 20 GB | 鍵保管バックエンドとして追加する場合のみ。CPU バウンドな共同計算のため、同一サイトに配置してください |
| PostgreSQL（Cockpit + オプションの MPC） | 3 | 6 | 16 GB | 100 GB SSD | プライマリ 1 + レプリカ 2。単一プロセスで、DB／ユーザーを分離します |
| Redis | 3 | 4 | 8 GB | 50 GB | Sentinel（またはクラスター）。パススルーキャッシュ |
| OpenBao | 3 | 2 | 4 GB | 20 GB SSD | Raft 統合ストレージ |
| VictoriaMetrics（モニタリング） | 1 | 4 | 12 GB | 200 GB | メトリクス + Grafana。プライマリ DC のみ |
| VictoriaLogs（ロギング） | 1 | 4 | 12 GB | 600 GB | 中央ログ / 監査。プライマリ DC のみ |
| Harbor（レジストリ、オプション） | 1 | 1 | 8 GB | 200 GB | エアギャップ用イメージミラー。プライマリ DC のみ |
| GitOps — ArgoCD / GitLab（オプション） | 1 | 1 | 4 GB | 100 GB | Git ソースからマニフェストを同期します |
各 HA セット（PostgreSQL、OpenBao、Redis、MPC ノード、API レプリカ）は 別々のハイパーバイザーホスト／アンチアフィニティグループ に分散し、単一ホストの障害が クォーラムや、ある層のすべてのレプリカを失わせないようにしてください。
これは LIGHT のリファレンスサイジングであり、オプション の DuoKey MPC KMS を 含めた構成で示しています。単一の PostgreSQL プロセスが、MPC が存在する場合には Cockpit データベースと MPC データベースの両方を提供します（DB／ユーザーは分離）。PostgreSQL は CPU 負荷が軽く（ストアドプロシージャのないシンプルなデータストアです）、DuoKey MPC ノードは Sepior TSM よりも必要な CPU が少なく、Redis はパススルーキャッシュで、ログの保持 期間は切り詰めています。デフォルトの Software Vault を使用する場合は、MPC の行を丸ごと 削除してください。最終的な数値は DuoKey と確認してください。
ユーザー数によるサイジング階層
計画を立てやすくするための目安の VM 台数であり、契約上のマッピングでは ありません。 最終的なサイジング（ドキュメントの利用状況、ピーク時同時実行数、可用性目標）は DuoKey と 検証します。
| 階層 | ユーザー数 | UI VM | API VM | MPC ノード（オプション） | データ層 | 備考 |
|---|---|---|---|---|---|---|
| パイロット / PoC | 1,000 以下 | 2 | 2 | 0 または 3 | PG×3、Bao×3、Redis×3 | 最小構成の HA、レプリカを削減 |
| 標準 | 10,000 以下 | 2 | 3 | 0 または 3 | PG×3、Bao×3、Redis×3 | リファレンスとなる VM HA |
| 大規模 | 50,000 以下 | 3 | 6 | 0 または 3〜5 | PG×3（スケール済み）、Redis クラスター | まず API（追加している場合は MPC も）をスケールします |
| エンタープライズ | 100,000 以上 | 個別対応 | 個別対応 | 個別対応 | マルチサイト | 通常は DC 間のアクティブ／パッシブ |
OpenShift のサイジング階層 と同様に、 これらは出発点です。Cockpit API は DKE の鍵操作におけるホットパスであるため、高負荷時は 最初にスケールしてください。オプションの DuoKey MPC KMS を鍵保管バックエンドとして 追加している場合、そのノードも同様に CPU バウンドであり、API と併せてスケールします。
サイト内の高可用性
| 層 | HA の仕組み |
|---|---|
| ロードバランサー / リバースプロキシ | フローティング VIP（keepalived/VRRP）を持つ 2 台の VM。アクティブ／スタンバイ |
| Cockpit UI / API | ステートレス で、VIP の背後に N+1 レプリカ。LB のヘルスチェックが異常なバックエンドを除外します |
| DuoKey MPC KMS（オプション） | 別々のホスト上の 3 ノード以上。クラスターは、完全な鍵を露出させることなくノードの喪失に耐えます |
| PostgreSQL | プライマリ 1 + レプリカ 2 で自動フェイルオーバー（Patroni/repmgr）。VIP はプライマリに追従します |
| OpenBao | 3 ノードの Raft クォーラム。自動アンシールを推奨します |
| Redis | 自動的なプライマリ選出のための Sentinel（またはクラスター） |
Geo ロードバランシングによるマルチサイト HA
データセンターレベルの回復性を確保するには、3 つのサイト にわたって データセンターごとに独立したスタック を運用し、その前段に Geo ロードバランサー (GSLB) を配置します。GSLB は各サイトのローカル LB VIP を ヘルスチェックし、正常なサイトへユーザーを誘導します。各サイト内ではローカルの ロードバランサーが UI と API の VM に負荷を分散します。 PostgreSQL は 3 つのサイト間でレプリケート され、オプションの DuoKey MPC KMS を 鍵保管バックエンドとして使用する場合は、同時にアクティブなデータセンターを 1 つに限定した （アクティブ／パッシブの）サイトごとのクラスター として稼働します。
ヘルスチェック付きの GSLB がユーザーをアクティブなデータセンターに誘導します。3 つのサイトはそれぞれ独立したスタックを実行し、PostgreSQL は全サイト間でレプリケートされ、オプションの DuoKey MPC KMS（追加した場合）はサイトごとのクラスターとして稼働します（同時にアクティブな DC は 1 つ）。
トポロジーの選択肢
| モード | 仕組み | 使用する場面 |
|---|---|---|
| アクティブ／パッシブ（3 DC） | 1 つのデータセンターがサービスを提供し、残りの 2 つは PostgreSQL/OpenBao がレプリケートされたウォームスタンバイです。GSLB はトラフィックを次の正常な DC にフェイルオーバーします。 | 3 つの DC におけるデフォルト。特にサイト間リンクが 低速または長距離 の場合に使用します。レイテンシーのガイダンス を参照してください |
| アクティブ／アクティブ（メトロ） | 複数のサイトがサービスを提供し、PostgreSQL は 5 ms 以下 のメトロリンク上で 同期 レプリケーションを使用します | 高速で信頼性の高いメトロリンク上でのみ使用します |
設計上の原則
- MPC の配置（追加する場合）: オプションの DuoKey MPC KMS を鍵保管バックエンドとして 使用する場合は、サイトごとのクラスター として運用します（同時にアクティブな DC は 1 つ）。単一クラスターをサイト間にストレッチするのは、低レイテンシーが検証済みの リンク（2 ms 以下）の場合のみにしてください。すべての鍵操作はノード間で共同計算される ため、それ以外の場合はサイトをまたぐ配置は低速になります。 ネットワーク要件 を参照してください。
- 共有の可観測性基盤は DC 1 に配置します: モニタリング、ロギング、Harbor、GitOps の 各 VM は プライマリ データセンターにのみ配置し、DC 2 と DC 3 はコアスタックのみを 実行します。これらはサイト外にレプリケート／バックアップしてください。
- データベースのレプリケーション: プライマリ ↔ レプリカ間の RTT が 5 ms 以下 の 場合にのみ 同期（RPO ゼロ）とし、それ以外は 非同期 として、小さく文書化された RPO を許容します。
- DKE エンドポイント: GSLB を前段に配置し、サイト間で 同じホスト名と TLS 証明書 を維持します。スプリットホライズン DNS と組み合わせることで、社内および社外のユーザーが最寄りの正常なサイトに到達できます。
- Securosys HSM（オプション）: ハードウェア HSM を追加する場合は、各サイトから 低レイテンシーで到達できるようにしてください。 鍵の保管 を参照してください。
- フェイルオーバーの目標: DuoKey と RTO/RPO を合意し、サイトのフェイルオーバーを 訓練してください。どの層が自動でフェイルオーバーし、どの層が手動かを文書化します。
データセンターごとのサイジング（3 サイト LIGHT プロファイル）
DuoKey の LIGHT リファレンスプロファイルに従った目安の集計で、オプション の DuoKey MPC KMS を含めた構成で示しています。DC 1 は加えて共有の可観測性基盤（モニタリング、 ロギング、Harbor、GitOps）を担い、DC 2 と DC 3 はコアスタックのみを実行します。デフォルトの Software Vault を使用する場合は、これらの数値から MPC ノード分を差し引いてください。 最終的なサイジングは DuoKey と確認してください。
| データセンター | RAM | vCPU | ストレージ | 内容 |
|---|---|---|---|---|
| DC 1（アクティブ + 共有運用基盤） | 約 160 GB | 約 60 | 約 1.7 TB | コアスタック + モニタリング、ロギング、Harbor、GitOps |
| DC 2（パッシブ） | 約 120 GB | 約 48 | 約 580 GB | コアスタック |
| DC 3（パッシブ） | 約 120 GB | 約 48 | 約 580 GB | コアスタック |
| 全体 | 約 400 GB | 約 156 | 約 2.9 TB | 3 サイトの合計 |
ユーザーはロードバランサーに到達し、ロードバランサーは各データセンター内のステートレスな UI と API の VM にトラフィックを分散します。API はサイトの Redis および PostgreSQL クラスターを共有します。
ロードバランシングの詳細
| サービス | LB の種類 | ヘルスチェック | TLS | アフィニティ |
|---|---|---|---|---|
| DKE 鍵エンドポイント（Cockpit API） | L7（または L4 パススルー） | TLS 経由で鍵エンドポイントへの GET | パススルー を推奨（クライアント → API の TLS をそのまま維持） | なし |
| Cockpit UI / API | L7 | HTTP(S) のヘルスチェックパス | 終端またはパススルー | なし（ステートレス） |
| KMIP エンドポイント（オプション） | L4 | TCP 5696 | パススルー | なし |
| PostgreSQL VIP | L4 | プライマリのみのプローブ（フェイルオーバーに追従） | 該当なし | プライマリへのピン留め |
DKE エンドポイント上で TLS を終端する、あるいは SSL インスペクションを行うミドルボックスは、 DKE フローが依拠するクライアント ↔ API 間の信頼を破壊します。この経路では パススルー（L4）を使用し、LB のアイドルタイムアウトは最長の鍵操作よりも 長く 設定してください。
関連項目
- ネットワーク要件 — レイテンシー、NTP、DNS、フローマトリクス
- 前提条件 — コンポーネントのサイジングとプラットフォーム要件
- リファレンスアーキテクチャ — OpenShift + VM のハイブリッド設計
- DNS レコード — スプリットホライズンと DKE エンドポイント
- キックオフ・スコーピング質問票 — サイト、LB、サイジングの情報収集