サイジング

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

収集する情報

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

入力	確認先	影響
S: 監視するライセンスサーバーの数	ライセンス管理者。ベンダーデーモンまたはポートごとに 1 つとして数えます。	使用状況データ、Kafka のトラフィック、データベースの増加量を左右します
U + W: ユーザーとワークステーションの数	ディレクトリ同期の対象範囲	MongoDB のサイズを左右します
Y: 保持する履歴の年数	レポートの要件	SQL Server のサイズを左右します
R: Kafka メッセージの保持期間（日数）	14 を推奨します（Kafka の既定値は 7）。このリリースでは、OpenLM Platform がデータパイプラインのトピックに 3 日を自ら設定するため、14 日は独自の設定を持たないトピックに適用されます。	Kafka のディスクを左右します
製品	ステップ 4 でオンにするコンポーネント (標準セットと、追加するコンポーネント)	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 以上にする必要があります。要件 を参照してください。

データサービス

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

サービス	見積もり	備考
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 が保留中になったり再起動されたりしていないか。