キャパシティ計画
キャパシティ計画は、本番移行前に顧客管理の FactVerse 環境で必要となるリソースを定義します。このページは Kubernetes、OpenShift、顧客 VM、制限ネットワークでのプライベートコンテナデプロイ向けです。
以下の数値は、顧客側デプロイの初期計画レンジです。最終値は、配送パッケージ、有効化モジュール、ユーザー同時実行、アセット規模、コネクタースケジュール、保持ポリシー、顧客インフラ標準に基づいて検証します。
前提条件
先にデプロイモデルとコンテナランタイムを決定します。対象製品モジュール、環境数、ID 方式、ソースシステム、想定ユーザー、クライアントデバイス、データ保持ポリシー、バックアップ先、監視基盤、変更承認プロセスを確認します。
キャパシティ計画フロー
製品デプロイ単位
イメージ名と chart 名は、プロジェクト配送パッケージで提供されます。以下の表で、通常は個別にキャパシティ計画が必要になるデプロイ単位を確認します。
| 製品範囲 | 典型的なデプロイ単位 | キャパシティ要因 |
|---|---|---|
| FactVerse Platform ベースライン | Web コンソール、API gateway、テナントと ID サービス、アセット metadata サービス、データベース、キャッシュまたはキュー、オブジェクトストレージ、入口。 | 同時ユーザー、アセット metadata 量、API call、認証トラフィック、オブジェクトストレージ増加。 |
| DataMesh Inspector | Inspector API、作業指示と点検サービス、証跡アップロードサービス、通知ジョブ、任意の DFS コネクター worker、ECM 証跡ストレージ。 | 現場ユーザー、点検記録、写真または動画証跡、作業指示同期、モバイルアップロードのピーク。 |
| Data Fusion Services | DFS API、コネクターコントローラー、コネクター worker、マッピングと品質ジョブ、スケジューラー、キュー、コネクターログ。 | コネクター数、同期頻度、バッチサイズ、ソースシステム制限、リトライ率、品質ルール数。 |
| FactVerse AI Agent | Agent API、ワークフローオーケストレーター、ツール実行 worker、検索または index サービス、承認キュー、監査記録。 | ワークフロー同時実行、tool call 量、文書検索、定期自動化、人による承認滞留。 |
| エンタープライズコンテンツ管理 | ECM API、文書サービス、検索または index サービス、オブジェクトストレージ、承認ワークフロージョブ。 | 文書数、ファイルサイズ、保持期間、承認活動、検索頻度。 |
| Designer、アセット準備、Physical AI | アセットサービス、モデル変換 worker、シミュレーションまたはレンダリング worker、worker scratch ストレージ、任意の GPU worker。 | 最大モデルサイズ、変換頻度、シミュレーションジョブ、SimReady asset 準備、レンダリングまたは物理ワークロード。 |
| クライアントアプリ | Web アクセス、デスクトップクライアント、モバイルクライアント、MR デバイス、現場キャッシュ。 | ダウンロードサイズ、サイト帯域、デバイスキャッシュ挙動、更新頻度、オフラインパッケージ要件。 |
初期コンテナ sizing
以下の数値は、特に記載がない限り replica または worker 単位です。requests はスケジューリング計画に使い、limits はノード保護に使います。limits は検証ワークロードを測定してから調整します。
| デプロイ単位 | 初期 request | 初期 limit | replica または worker | I/O とストレージの補足 |
|---|---|---|---|---|
| Web コンソールまたは静的 frontend | 0.1-0.25 vCPU、256-512 MiB | 0.5 vCPU、1 GiB | 本番は 2 replicas。 | ディスク I/O は小さい。許可される場合は入口または顧客 CDN で静的アセットをキャッシュします。 |
| API gateway と軽量 API | 0.5-1 vCPU、1-2 GiB | 2 vCPU、4 GiB | 本番は 2 replicas。 | p95 latency、error rate、connection pool 使用状況を確認します。 |
| 製品 API サービス | 1 vCPU、2-4 GiB | 4 vCPU、8 GiB | 本番は 2 replicas。高同時実行では追加します。 | データベース latency とオブジェクトストレージアクセスに影響されます。 |
| テナント、ID、管理サービス | 0.5 vCPU、1-2 GiB | 2 vCPU、4 GiB | 本番は 2 replicas。 | フェイルオーバーテスト時に SSO callback と session 挙動を確認します。 |
| DFS コネクター worker | 0.5-2 vCPU、1-4 GiB | 4 vCPU、8 GiB | コネクターグループまたは同期時間帯ごとに 1 worker から開始します。 | バッチサイズとソースシステム latency が主な制約になりやすいです。大型同期ジョブの重なりを避けます。 |
| AI Agent ワークフロー worker | 1-2 vCPU、4-8 GiB | 4 vCPU、16 GiB | 定期ワークフロー有効時は 2 workers から開始します。 | queue depth、tool call latency、retrieval latency、承認滞留でスケールします。 |
| ECM 文書と検索サービス | 1-2 vCPU、2-8 GiB | 4 vCPU、16 GiB | API は 2 replicas。index サービスは別に sizing します。 | 検索 index には高速な永続ストレージとメモリ余力が必要です。 |
| モデル変換またはアセット処理 worker | 2-4 vCPU、8-16 GiB | 8 vCPU、24-32 GiB | 1-2 workers から開始します。重いアセットでは API ノードから分離します。 | 高速なローカル scratch ストレージを使います。大きなモデルはメモリと一時ディスクを急増させます。 |
| シミュレーション、レンダリング、Physical AI worker | 4-8 vCPU、16-32 GiB | 16 vCPU、64 GiB | プロジェクトワークロードごとに sizing します。配送パッケージで要求される場合は GPU ノードを追加します。 | 専用 scratch ストレージと長めの検証実行が必要です。 |
| キャッシュまたはキュー | 1-2 vCPU、2-4 GiB | 4 vCPU、8 GiB | 本番は顧客承認済みの HA パターンを使います。 | queue depth、memory eviction、永続化モードを監視します。 |
| Ingress controller | 0.5-1 vCPU、512 MiB-2 GiB | 2 vCPU、4 GiB | クラスター方針が許す場合は 2 replicas 以上。 | TLS 終端、アップロードサイズ、クライアントダウンロードピークで sizing します。 |
環境 sizing プロファイル
以下のプロファイルは顧客側の初期計画用です。クラスターまたは環境レベルの参考値であり、リリース固有の values ファイルと検証結果で調整します。
| プロファイル | 典型用途 | コンピュート基線 | データサービス | ストレージと I/O 基線 |
|---|---|---|---|---|
| 単一ノード検証 | ラボ検証、トレーニング、設定レビュー、問題再現。 | 1 VM または 1 ノードで 8-12 vCPU、32-48 GiB RAM。 | ローカルまたは顧客提供のデータベースとキャッシュ。 | 300-500 GiB SSD。検証用途です。 |
| 小規模本番 | 1 サイト、中程度のユーザー、限定的なコネクター、標準的な Inspector または ECM ワークロード。 | 3 worker nodes、各 8 vCPU、32 GiB RAM。control-plane は顧客標準に従います。 | PostgreSQL 4 vCPU、16 GiB RAM。キャッシュまたはキュー 2 vCPU、4 GiB RAM。 | データベース SSD は 3,000 IOPS 以上。オブジェクトストレージ 1-2 TiB。worker scratch 100-200 GiB。 |
| 標準本番 | 複数サイトまたは複数部門、定期 DFS 同期、AI Agent ワークフロー、文書と証跡保持。 | 3-5 worker nodes、各 16 vCPU、64 GiB RAM。 | PostgreSQL 8 vCPU、32 GiB RAM。キャッシュまたはキュー 4 vCPU、8 GiB RAM。検索有効時は検索サービス 4 vCPU、16 GiB RAM。 | データベース SSD 6,000-10,000 IOPS。オブジェクトストレージ 2-5 TiB。worker scratch 300-500 GiB。 |
| アセット重視または Physical AI | 大型モデル、頻繁な変換、シミュレーション、レンダリング、SimReady asset 準備、ロボティクストレーニング。 | 標準本番に加え、16-32 vCPU、64-128 GiB RAM の専用 worker nodes を追加します。必要な場合だけ GPU ノードを追加します。 | PostgreSQL 8-16 vCPU、32-64 GiB RAM。retrieval 有効時は検索または index 容量を分けます。 | データベース SSD 10,000+ IOPS。オブジェクトストレージ 5 TiB 以上。scratch storage 500 GiB 以上、高い sequential throughput。 |
| 高統制環境 | 制限ネットワーク、オフラインパッケージ import、厳格な保持、検証と本番経路の分離。 | 本番と検証を別々に sizing します。オフラインアップグレード検証用の余力を確保します。 | 顧客管理の HA データベース、キャッシュまたはキュー、内部レジストリ、バックアップ基盤。 | イメージアーカイブ、復旧サンプル、ログ、release bundle 用の容量を追加します。 |
ストレージと I/O 推奨
| ストレージ領域 | 推奨タイプ | 計画ガイド | 監視項目 |
|---|---|---|---|
| データベース volume | SSD または高性能 block storage。 | sizing プロファイルの IOPS レンジから開始します。index、migration、backup staging、restore test 用の空き容量を確保します。 | IOPS saturation、latency、slow query、lock wait、connection pressure。 |
| オブジェクトストレージ | 顧客 object storage または S3 互換サービス。 | source files、converted assets、documents、evidence、generated reports、retained versions、lifecycle buffer を含めます。 | growth rate、large-object latency、failed uploads、lifecycle cleanup、restore samples。 |
| Worker scratch | 高速 local SSD または高 throughput ephemeral volume。 | モデル変換とシミュレーション worker には独立した一時領域が必要です。最大モデルと派生ファイルから scratch を見積もります。 | temporary disk pressure、conversion duration、worker eviction、failed jobs。 |
| 検索または index volume | SSD persistent volume。 | メモリとディスクを一緒に計画します。rebuild time は保守ウィンドウ内に収めます。 | query latency、index size、rebuild time、memory pressure。 |
| ログと監査記録 | 顧客 log platform または retained persistent storage。 | 保持ポリシーと export volume で sizing します。高統制プロジェクトでは監査保持を分離します。 | log growth、dropped logs、retention pressure、query time。 |
| バックアップ先 | 顧客 backup platform または object storage tier。 | backup throughput は保守ウィンドウに収めます。データベース、object storage、configuration、release evidence を含めます。 | backup duration、failed backup、restore duration、不完全な protected asset list。 |
I/O 計画ルール
- データベース volume は latency が安定した SSD クラスのストレージを使います。
- オブジェクトストレージは大きなファイルの順次 upload/download に合わせます。
- モデル変換とシミュレーション worker には専用 scratch を与え、一時ファイルがデータベース I/O と競合しないようにします。
- 小規模環境では、大型 DFS 同期、モデル変換、バックアップ、検索 reindexing の時間帯を分けます。
- モデル、変換済みアセット、文書、点検証跡、ログ、データベース、バックアップを分けてストレージ成長を追跡します。
- キャパシティベースライン承認前に、検証計画へ少なくとも 1 件の復旧サンプルを含めます。
入力
| 入力 | 確認内容 | キャパシティへの影響 |
|---|---|---|
| 環境 | 本番、検証、トレーニング、災害復旧、ラボ環境。 | クラスター、VM、ストレージ、バックアップ、監視の総量を決める。 |
| ユーザーワークロード | 指名ユーザー、アクティブユーザー、ピーク同時セッション、ユーザーグループ、サイトのタイムゾーン、クライアント種別。 | Web/API replica、セッション負荷、ネットワーク throughput、サポート時間帯に影響する。 |
| シーンとアセットワークロード | シーン数、最大モデルサイズ、モデル変換頻度、メディアファイル、ダウンロード、現場デバイスのキャッシュ挙動。 | オブジェクトストレージ、モデル処理 worker、キャッシュ、バックアップ容量に影響する。 |
| DFS と連携ワークロード | ソースシステム、コネクター数、同期周期、バッチサイズ、リトライポリシー、書き戻し要件。 | コネクター worker、queue depth、データベース I/O、ネットワーク経路、ソースシステム制限に影響する。 |
| AI Agent ワークロード | ワークフロー同時実行、tool call 量、文書検索、定期自動化、承認キュー。 | worker 同時実行、キュー容量、データベース負荷、任意のプライベート推論容量に影響する。 |
| シミュレーションまたは Physical AI ワークロード | 対象範囲に含まれるシミュレーションジョブ、アセット準備、レンダリング、物理検証、ロボティクスまたはトレーニングシナリオ。 | 専用 worker ノード、GPU ノード、大きなストレージ、長い検証時間帯が必要になる場合がある。 |
| ECM と証跡ワークロード | 文書、SOP、画像、点検証跡、監査記録、保持期間。 | オブジェクトストレージ、データベースレコード、index サイズ、バックアップ時間帯、復旧テスト範囲に影響する。 |
| 運用ポリシー | 可用性目標、保守ウィンドウ、ログ保持、バックアップ頻度、復旧目標。 | 冗長性、監視、ログストレージ、バックアップ基盤、復旧プロセスに影響する。 |
計画手順
- 製品範囲と想定ワークロードに合う sizing プロファイルを選びます。
- 有効化する製品をデプロイ単位へ対応付け、専用 worker が必要な単位を特定します。
- ユーザー、シーン、アセット、連携、AI Agent ワークフロー、ECM 文書、保持要件の sizing worksheet を埋めます。
- CPU requests、memory requests、limits、replica 数、storage class、persistent volume、namespace quota を定義します。
- データベース IOPS、object storage 容量、worker scratch サイズ、検索 index サイズ、ログ保持、backup target throughput を定義します。
- モデル変換、定期同期、バッチインポート、検索 indexing、シミュレーションジョブなどのバーストワークロードを定常ワークロードから分けます。
- replica、worker 数、ストレージ拡張、データベースチューニング、コネクタースケジュール、バックアップウィンドウのスケール条件を定義します。
- 代表的なユーザー、ソースレコード、シーン、文書、クライアントデバイスで検証ワークロードを実行します。
- キャパシティベースライン、既知の前提、余力、レビュー周期、各リソース領域の所有者を記録します。
サイジングワークシート
| ワークシート項目 | 記録内容 |
|---|---|
| ピーク同時ユーザー | 業務ピーク、サイトピーク、クライアント種別、想定成長、検証サンプル。 |
| 最大運用シーン | シーンサイズ、アセット数、メディア数、対象デバイス、ダウンロード挙動。 |
| 連携スケジュール | ソースシステム、同期頻度、バッチサイズ、許可ウィンドウ、リトライポリシー。 |
| AI Agent 同時実行 | ワークフロー種別、定期実行、手動実行、tool call 量、承認キュー。 |
| ストレージ成長 | オブジェクトストレージ成長、データベース成長、ログ成長、保持期間。 |
| バックアップと復旧 | バックアップ頻度、バックアップ時間帯、復旧目標、復旧サンプルセット。 |
| 高可用性 | replica ポリシー、ノード分散、データベース可用性パターン、保守ウィンドウ。 |
| 任意の GPU ワークロード | シミュレーション、レンダリング、モデル処理、プライベート推論、検証実行時間。 |
検証チェックリスト
- 代表的なユーザーが想定ピーク時間帯に対象ワークフローを完了できる。
- コネクタージョブが承認済み同期ウィンドウ内に完了する。
- モデル変換、アセット読み込み、文書アクセスが受け入れ期待を満たす。
- AI Agent ワークフローと承認キューが制御不能な滞留を作らない。
- データベース、キュー、キャッシュ、オブジェクトストレージのメトリクスが合意した運用範囲に収まる。
- バックアップが承認済み時間帯に完了し、復旧サンプリングが成功する。
- CPU、メモリ、pod restart、queue backlog、database connection pressure、storage growth、backup failure のアラートがある。
- 顧客所有者がベースラインとレビュー周期を承認している。
期待結果
期待される成果は、製品デプロイ単位、ワークロード前提、初期 resource requests と limits、データベースとストレージ I/O 前提、バックアップ見積もり、スケール条件、検証証跡、将来のキャパシティレビュー所有者を含むキャパシティベースラインです。
キャパシティ課題のトラブルシューティング
| 症状 | 確認項目 |
|---|---|
| ピーク時にページが遅い | 同時セッション、入口容量、API replica、データベースレイテンシ、cache hit rate。 |
| コネクタージョブが同期ウィンドウを超える | ソースシステム制限、バッチサイズ、worker 数、queue depth、リトライポリシー、ネットワーク経路。 |
| モデルまたはアセットタスクが長い | worker リソース、アセットサイズ、ストレージ throughput、変換キュー、任意の GPU worker の必要性。 |
| ストレージが想定より速く増える | 保持ポリシー、重複アップロード、ログ保持、インポートファイルのライフサイクル、バックアップコピー。 |
| バックアップが保守ウィンドウを超える | 保護対象アセット一覧、オブジェクトストレージ容量、データベースサイズ、バックアップ先 throughput、スケジュール。 |
| resource requests がデプロイを止める | namespace quota、node capacity、storage class availability、OpenShift project limits、cluster policy。 |