サーバーリソース仕様の目安
qOntology のデプロイでは、利用場面、データ規模、予算に応じて、1 台への集約配置またはコンポーネントごとの分離配置を選択できます。以下は、サーバー選定と容量計画の参考となる、テスト環境向け最小推奨構成と一般的な本番環境向け推奨リソース一覧です。
最小構成の要件
機能テスト、デモ、少量データでの試用向けです。標準の Docker Compose 構成を使用し、Nginx、qOntology API、MySQL、Redis、Neo4j、kkFileView の 6 サービスを 1 台に配置します。
本節はテスト環境の最小推奨出発点であり、負荷試験で認定された最低動作要件ではありません。 ローカルでの大規模モデル推論と独立したベクトルサービスは含みません。AI 機能には、別途設定した外部モデルのエンドポイントを使用します。
| 番号 | サーバー名 | 用途 | OS | CPU | メモリ | ディスク | 台数 |
|---|---|---|---|---|---|---|---|
| 1 | qOntology 統合サーバー | Nginx、qOntology API、MySQL、Redis、Neo4j、kkFileView を配置 | Ubuntu | 4 vCPU | 16GB | 200GB SSD | 1 |
集約配置では、各サービスがホストのリソースを共有します。バッチ抽出、グラフ検索、ファイル変換の同時実行で必要量が増えるため、テストではタスクの同時実行数を制御し、ホスト全体のメモリとディスク使用量を監視してください。Docker Desktop では、ホストの仕様だけでなく Docker に割り当てたリソースも確認します。
推奨構成の要件
チームの日常的なモデリング、グラフ検索、適量の抽出タスクを想定した、一般的な本番環境の計画向けです。以下はコンポーネントを分離する場合の調達例です。AI 機能には外部モデルのエンドポイントを使用し、ローカル GPU や大規模モデル推論サーバーは含みません。
表の CPU、メモリ、ディスクは各サーバー 1 台あたりの推奨仕様です。 実際のコンポーネントのバージョンとイメージのアーキテクチャに対応する Ubuntu 環境を選択してください。
| 番号 | サーバー名 | 用途 | OS | CPU | メモリ | ディスク | 台数 |
|---|---|---|---|---|---|---|---|
| 1 | アプリケーションサーバー | Nginx、フロントエンド、qOntology API を配置 | Ubuntu | 8 vCPU | 16GB | 200GB SSD | 1 |
| 2 | リレーショナルデータベースサーバー | MySQL による業務データの保存 | Ubuntu | 4 vCPU | 16GB | 500GB SSD | 1 |
| 3 | グラフデータベースサーバー | Neo4j によるグラフデータの保存と検索 | Ubuntu | 8 vCPU | 32GB | 500GB SSD | 1 |
| 4 | キャッシュサーバー | Redis によるキャッシュ | Ubuntu | 2 vCPU | 4GB | 100GB SSD | 1 |
| 5 | ファイルプレビューサーバー | kkFileView によるファイル変換とプレビュー | Ubuntu | 4 vCPU | 8GB | 200GB SSD | 1 |
| 6 | ベクトルサーバー（任意） | Weaviate によるベクトルの保存と検索 | Ubuntu | 4 vCPU | 16GB | 300GB SSD | 必要に応じて 1 台追加 |
基本構成の合計は 5 台、26 vCPU、メモリ 76GB、SSD 1.5TB です（ディスクは 1000GB = 1TB で集計）。任意のベクトルサーバーは別計上です。利用可能な Weaviate がある場合は既存サービスへの接続を計画でき、重複調達は不要です。ベクトルの件数、次元数、インデックス設定に基づいて実際の必要量を評価してください。
コンポーネントの分離配置
標準の Compose は 1 台で実行するものであり、複数ホストにサービスを自動配分しません。上記の分離構成では、API のデータベース、キャッシュ、グラフデータベースの接続先と、Nginx の転送先を変更します。サービス間通信、認証、ファイルのアクセス経路も確認してください。
上記の各役割はいずれも単一ノードです。分離配置はリソースを分けるためのもので、それだけで高可用性を実現するものではありません。高可用性が必要な場合は、冗長ノード、フェイルオーバー、バックアップと復旧を別途設計し、リソースを再計算してください。
補足事項
- ディスクとバックアップ：SSD を優先します。表の容量には OS、アプリケーション、ローカルデータを含み、独立したバックアップ領域は別途計画します。業務データに加え、グラフデータとインデックス、アップロードファイル、プレビューキャッシュ、ログを計上し、増加量と保存期間に応じて余裕を確保してください。
- メモリ配分：現在のバックエンドイメージの API 最大 JVM ヒープは 2GB、Compose の kkFileView 最大ヒープは 1GB です。ヒープ上限はプロセス全体の使用量やホスト全体の必要メモリとは異なります。データベース、グラフキャッシュ、ファイル変換プロセス、OS の領域を確保し、設定値の合計でメモリを使い切らないようにしてください。
- 計算資源と拡張：クエリの複雑さ、抽出タスクの同時実行数、ファイル変換量に応じて CPU とメモリを調整します。本番公開前に日常操作とバッチ処理を検証し、CPU、メモリ、ディスク容量、I/O を継続監視して、増強やサービス分離の要否を判断してください。
- AI とベクトルサービス：外部モデルの呼び出しにローカル GPU は不要ですが、利用可能なネットワーク、エンドポイント、認証情報が必要です。ローカルの大規模モデル推論は、モデル規模、量子化方式、同時実行目標に応じて別途評価します。Weaviate は標準の Compose 構成に含まれず、必要に応じて個別に用意します。
- OS とアーキテクチャ：各コンポーネントとイメージのバージョン、CPU アーキテクチャ、動作条件を確認します。ARM や麒麟（Kylin）などの中国国産環境は、対象のハードウェアとソフトウェアの組み合わせで適合性を検証してください。
- ネットワークと永続化：アプリケーションとデータサービスは、可能な限り管理された内部ネットワークで通信させ、必要なポートのみ公開します。データベース、グラフデータ、アップロードファイルの永続化先を確認し、バックアップから復元できることを検証してください。