サイジング
サイジング（サーバー要件の見積もり）は、「最大同時接続数 × 品質（HD/SD）× 冗長化」の3要素で決まります。過剰なスペックで無駄なコストをかけるのも、スペック不足で品質トラブルを起こすのも避けたいところです。
私たちメディアプラスが推奨しているのは、最小構成でPoCを実施し、実測データをもとに段階的に拡張するアプローチです。このページでは、見積もりの前提と考え方を、稟議やPoC設計に使える形で整理します。
サイジングの3要素
サーバー要件は、以下の3つの掛け合わせで決まります。
1. 最大同時接続数
ピーク時に何拠点・何端末が同時に会議するかが出発点です。全社の会議室数ではなく、同時に接続する最大数で考えてください。帯域の算出にあたっては、週次の定例会議が集中する月曜午前の時間帯を基準として参照するのが適切です。現時点では概算値で問題ありませんので、まずはその数値をベースにPoC（概念実証）を実施し、実測データに基づいて正確な値へと補正していく方針で進めます。
2. 品質（HD/SD）
映像品質によって、1接続あたりのサーバー負荷が大きく変わります。映像品質の選定については、会議室の大画面や役員会議にはHD（720p以上）、帯域の限られる拠点やPCからの参加にはSD（480p以下）を推奨しており、どちらを優先するかによって同一サーバー内での収容数が2〜3倍変動するため、用途に応じた設計が重要となります。
3. 冗長化の要否
冗長化とは、サーバーが1台停止しても会議を継続できる構成です。システム構成については、本番環境では最低2台のカンファレンスノードを用いる「冗長化あり」の構成を推奨しますが、PoCや検証段階であれば最小1台の「冗長化なし」で開始することも可能です。ただし、冗長化を組む場合はサーバー台数が最低2倍必要となる点に留意してください。
見積もりの入力項目
サイジングの見積もりに必要な情報です。
- 最大同時接続数（おおよそでOK）
- 拠点数と代表端末の種類
- 解像度の要件（HD中心 or SD中心）
- 冗長化の要否（PoC段階では不要）
- 配置形態（オンプレ / クラウド / ハイブリッド）
推奨サーバースペック
Pexip Infinityのカンファレンスノード（会議処理を行うサーバー）の推奨スペックです。
| 項目 | 推奨スペック | 備考 |
|---|---|---|
| CPU | Intel Xeon Scalable Series Gold 第三世代（Ice Lake以降） | 24コア以上推奨 |
| メモリ | 192GB（16GB×12 DIMM） | 最小96GB |
| ストレージ | SSD 500GB以上 | OS＋ログ用 |
| ネットワーク | 1Gbps NIC（デュアルNIC推奨） | 冗長化対応 |
| 仮想化基盤 | VMware vSphere ESXi 6.7/7.0/8.0、Hyper-V、KVM | 既存の仮想化基盤を利用可能 |
| クラウド | Azure、AWS、GCP | オンプレミスとのハイブリッドも可 |
実務のポイント
推奨スペックはあくまで目安です。実際の同時接続数・解像度・利用パターンによって最適なスペックは変わるため、PoCでの実測が重要です。クラウド環境であれば、PoC後にインスタンスサイズを変更して最適化できます。
同時接続数の目安
（サーバースペック別）
同じサーバーでも、HD接続とSD接続では収容できる数が大きく異なります。
| サーバースペック | HD接続数（720p以上） | SD接続数（480p以下） |
|---|---|---|
| 2×24コア（Cascade Lake） | 160〜185 | 390〜425 |
| 2×20コア（Cascade Lake） | 135〜180 | 156〜192 |
| 2×20コア（Skylake） | 110〜132 | 240〜290 |
※注意：この数値はPexip社の公開ベンチマークに基づく参考値です。コーデックの種類、画面共有の有無、会議のレイアウト（分割数）によって変動します。実環境での接続数は、PoCで確認してください。
規模別の構成イメージ
小規模（同時接続〜30）
- カンファレンスノード：1台
- 管理ノード：1台（兼用可）
- 冗長化：PoC段階では不要
- まずはこの構成でPoCを開始し、実測データを取るのが最短ルートです
中規模（同時接続30〜100）
- カンファレンスノード：2〜3台（冗長化込み）
- 管理ノード：1台（専用）
- 分散配置：主要拠点にノードを配置し、WAN帯域を削減
- 拠点間の帯域が細い場合は、分散配置の効果が大きくなります
大規模（同時接続100〜）
- カンファレンスノード：3台以上（冗長化＋負荷分散）
- 管理ノード：冗長化推奨
- マルチサイト：国内外の拠点にノードを分散
- クラウド（Azure/AWS/GCP）とのハイブリッド構成で、柔軟にスケール
クラウド構成の場合
- Azure/AWS/GCPの仮想マシンを利用
- インスタンスサイズの変更で、段階的にスケールアップ
- PoC→本番で同じ環境を使い回せるのがメリット
- オンプレとのハイブリッドも対応可能
よくある失敗と対策
失敗1：過剰スペックでコスト増
- 症状：高額なサーバーを導入したが、実際の利用率は見積もりの30%程度
- 原因：「最大同時接続数」を過大に見積もった。全会議室×全時間帯で同時利用を想定してしまった
- 対策：最小構成で開始し、3〜6か月の実績データをもとに追加する。クラウド版であれば柔軟にスケール可能
失敗2：ネットワーク不足でサーバーが
活きない
- 症状：サーバースペックは十分なのに、映像が途切れる
- 原因：帯域やQoSの設計をせずにサーバーだけ導入した。ボトルネックはサーバーではなくネットワークだった
- 対策：サイジングとネットワーク設計はセットで行う。帯域の目安（0.5〜3Mbps/参加者）とQoS設定を先に整えてからサーバーを確定する
失敗3：冗長化の考慮漏れ
- 症状：サーバー障害で全会議が停止した
- 原因：PoC構成（1台）のまま本番に移行してしまった
- 対策：本番環境では最低2台のカンファレンスノードで冗長化する。クラウド構成であれば、別リージョンへの分散も選択肢
失敗4：仮想化基盤の制約を見落とし
- 症状：既存のVMware環境にデプロイしたが、パフォーマンスが出ない
- 原因：仮想マシンにCPUやメモリを十分割り当てていなかった。他のVMとリソースを共有してオーバーコミットが発生
- 対策：カンファレンスノード用のVMはリソース予約（Reservation）を設定する。CPUの物理コアを専有で割り当てると安定します
よくあるご質問
- 「おおよそ」で十分です。たとえば「会議室が20室あり、ピーク時は半分が使われている」なら、同時接続10程度が目安になります。正確な値はPoCで実測して補正するので、初期段階では概算で問題ありません。
- 同時接続数と利用頻度によります。同時接続数が少ない（〜30程度）場合や、利用が不定期な場合はクラウドの方が初期コストを抑えられます。常時稼働で同時接続が多い場合は、オンプレの方がランニングコストが低くなる傾向があります。
流用できますか?
- VMware/Hyper-V/KVMの環境があれば、既存の仮想化基盤にPexip Infinityをデプロイ可能です。ただし、カンファレンスノードには十分なCPU/メモリのリソース予約が必要です。既存環境のリソース余剰を確認した上で、PoC用のVMを作成するのが一般的な進め方です。
その他の技術・要件ページ
適切な規模感、一緒に見積もりませんか？
同時接続数・品質・冗長化の前提を整理するところからご支援します。PoCを通じて段階的に確認する進め方も提案します。
