---
title: サイジング
description: サイトに関するいくつかの数値から、OpenLM Platform のインストールに必要なワーカー容量と、SQL Server、Kafka、MongoDB、Redis のサイズを見積もります。
product: OpenLM Platform
---

クラスターとデータサービスを発注する前に、このページを使ってサイズを決めてください。ここに示す数値は、約 300 台のライセンスサーバーを持つ参照インストールに基づく見積もりです。サイトの利用状況によって異なる場合があるため、1～3 か月後に実際の使用量を確認して調整してください。[確認と調整](#確認と調整) を参照してください。

## 収集する情報

まず、サイトに関する次の数値を収集してください。

| 入力 | 確認先 | 影響 |
|---|---|---|
| **S**: 監視するライセンスサーバーの数 | ライセンス管理者。ベンダーデーモンまたはポートごとに 1 つとして数えます。 | 使用状況データ、Kafka のトラフィック、データベースの増加量を左右します |
| **U + W**: ユーザーとワークステーションの数 | ディレクトリ同期の対象範囲 | MongoDB のサイズを左右します |
| **Y**: 保持する履歴の年数 | レポートの要件 | SQL Server のサイズを左右します |
| **R**: Kafka メッセージの保持期間（日数） | **14 を推奨します**（Kafka の既定値は 7）。このリリースでは、OpenLM Platform がデータパイプラインのトピックに 3 日を自ら設定するため、14 日は独自の設定を持たないトピックに適用されます。 | Kafka のディスクを左右します |
| 製品 | [ステップ 4](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-4-values) でオンにするコンポーネント (標準セットと、追加するコンポーネント) | CPU とメモリを左右します |
| データサービス | お客様自身のサーバーまたはマネージドサービス、あるいはクラスター内 | クラスター内で実行する場合はクラスター容量が増えます |

ユーザー数よりもライセンスサーバーの数のほうが重要です。ユーザー 1,200 人とライセンスサーバー 40 台のサイトは、ユーザー 5,000 人とライセンスサーバー 10 台のサイトよりも多くの容量を必要とします。

## クラスター容量

2 つのルールでワーカーのサイズを求め、**大きいほう**の結果を採用してください。どちらのルールも、データサービスがクラスターの外部で実行されることを前提としています。

### ライセンスサーバー数による見積もり

レポートデータを準備するデータ処理ジョブは使用状況データに比例して増えるため、ライセンスサーバーの数によってワーカーのサイズが決まります。次の表で該当する数を確認してください。

| ライセンスサーバー数 (S) | ワーカー |
|---|---|
| 100 未満 | 3 × 8 vCPU / 32 GiB |
| 100～199 | 3 × 12 vCPU / 48 GiB |
| 200 以上 | 3～4 × 16 vCPU / 64 GiB |

### オンにするコンポーネントによる見積もり

このルールは、どのサイトにも適用される下限を定めます。

| 項目 | 見積もり |
|---|---|
| vCPU | **Pod が要求する CPU の 2 倍。** 標準セットは約 10 vCPU を要求するため、少なくとも **24 vCPU** を見込んでください。標準セットに加えてデータ処理ジョブを 1 つオンにするごとに、4 vCPU を追加します。 |
| メモリ | **Pod が使用できるメモリの上限（リミット）の 1.25 倍**を、ノード単位に切り上げた値。標準セットのリミットは合計で約 55 GiB のため、少なくとも **96 GiB** を見込んでください。 |
| ワーカー | メンテナンスのために 1 台をドレインできるよう、少なくとも **3 台のワーカー**を用意し、それぞれ 8 vCPU / 32 GiB 以上にします。 |

ピークの原因はデータ処理ジョブです。複数のジョブが同時に実行され、それぞれが 2～5 vCPU を使用します。ほとんどの時間、OpenLM Platform の使用量ははるかに少なく、約 85 個の Pod を持つテストシステムでは約 1 vCPU と 16 GiB でした。

### クラスター内のデータサービス

データサービスをクラスター内で実行する場合は、**32 GiB のメモリと 6～8 vCPU** を追加してください。これには次のサービスが含まれます。

- **MongoDB**: 8 GiB 以上。
- **Kafka**: 4～6 GiB。
- **Redis**: 1 GiB。
- **SQL Server**（これもクラスター内で実行する場合）: 約 16 GiB と 4 vCPU。

これらのボリュームには高速な `ReadWriteOnce` ストレージが必要です。サイズは [データサービス](#データサービス) に従ってください。

すべてのノードで `fs.inotify.max_user_instances` を 8192 以上にする必要があります。[要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/requirements) を参照してください。

## データサービス

次の計算式で各データサービスのサイズを見積もってください。

| サービス | 見積もり | 備考 |
|---|---|---|
| **SQL Server**（4 つのデータベースすべて） | **max(50 GB, 2 × (2 GB + 0.072 GB × S × Y))** | ライセンスサーバー 1 台あたり月に約 0.006 GB 増加します。レポートには 2 vCore が必要です。負荷の高いダッシュボードには 4 vCore を見込んでください。 |
| **Kafka** のディスク | **max(20 GB, 1.25 × (0.048 GB × S × R + 3 GB))** | 保持期間によってディスクがいっぱいにならないよう、各トピックにサイズの上限を設定してください。 |
| **MongoDB** | **max(20 GB, 2 × (1 GB + ユーザーとワークステーション 1,000 あたり 0.22 GB))** | |
| **Redis** | 1～2 GB のメモリ | キャッシュのみで、永続データはありません |

Power BI から DirectQuery モードでレポートを作成する場合は、SQL Server のサイズにかかわらず、使用状況テーブルが約 1 億行を超えた時点で増分更新を使用してください。

## 例

次の表は、3 つのサイトに計算式を適用した例です。

| サイト | S | U + W | Y | R | SQL Server | Kafka | MongoDB | ワーカー（データサービスは外部） |
|---|---|---|---|---|---|---|---|---|
| 小規模、ユーザー約 1,200 人 | 30 | 3,000 | 5 | 14 | 50 GB | 30 GB | 20 GB | 3 × 8 vCPU / 32 GiB |
| 中規模 | 100 | 20,000 | 5 | 14 | 80 GB | 90 GB | 20 GB | 3 × 12 vCPU / 48 GiB |
| 大規模 | 300 | 90,000 | 5 | 14 | 220 GB | 250 GB | 42 GB | 3～4 × 16 vCPU / 64 GiB |

データサービスをクラスター内で実行する場合は、各例に 32 GiB のメモリと 6～8 vCPU を追加してください。

## 確認と調整

これらの係数は 1 つの大規模なインストールに基づくもので、ライセンスサーバー 1 台あたりの利用状況はサイトによって異なります。CAD や EDA の利用が多いサイトでは、セッションが多く発生します。1～3 か月後に実際の数値を見積もりと比較し、サイズを調整してください。次の数値を確認します。

- **データベースの増加量**: 4 つのデータベースのサイズの月ごとの推移。
- **Kafka のディスク**: ブローカーが使用している容量と、その上限との比較。
- **クラスター**: 負荷の高い時間帯の `kubectl top nodes` の結果と、メモリ不足で Pod が保留中になったり再起動されたりしていないか。