ERP のサーバー サイジング: 適切な方法

ERP のサーバーのサイジングは、技術的ではあるもののビジネスに重大な影響を与える決定の 1 つです。サーバーのサイズを小さくすると、初日からパフォーマンスに関する不満が発生します。ページの読み込みが遅くなり、使用量がピークになったときのタイムアウトが発生し、同時負荷がかかるとデータベースのデッドロックが発生します。サイズを大きくしすぎると、ほとんどアイドル状態にあるインフラストラクチャに必要以上に多額の費用がかかることになります。

ほとんどの ERP 実装では、2 つの方向のいずれかでサーバーのサイジングが間違っています。1 つは、ERP のデータベースの強度を考慮せずに「単なる Web アプリだ」という直感に基づいてサイジングを行う自信過剰な IT チーム、または妥当なコストで適切なパフォーマンスではなく、いかなるコストでも最大のパフォーマンスを実現するように調整されたベンダーの推奨事項です。

このガイドでは、ERP 導入のサーバー サイジングに対する構造化されたアプローチ、つまりリソー​​ス要件を決定する主な変数、さまざまなユーザー数における主要な ERP プラットフォームの特定のサイジング ガイドライン、および ECOSIRE の無料のサーバー サイジング カリキュレーターを使用して特定の状況をモデル化する方法を説明します。

重要なポイント

• ERP は一般的な Web アプリケーションよりもデータベースへの負荷が大幅に高くなります。標準の Web サーバーのサイジング ルールは適用されません。
• CPU が制約になることはほとんどありません。 ERP ワークロードでは、ほとんどの場合、RAM とディスク I/O がボトルネックになります。
• Odoo では、同時ワーカー プロセスごとに 2 ～ 4 GB の RAM が必要です。 50 ユーザー以上の本番インスタンスの場合は少なくとも 16 GB
• データベース ストレージの IOPS 要件は、ほとんどのサーバーのサイジング演習で大幅に過小評価されています
• 紙の上では同等に見えるクラウド インスタンス (同じ vCPU、同じ RAM) でも、I/O パフォーマンスが大幅に異なる可能性があります
• 常に 30 ～ 40% のヘッドルームを備えたピーク同時負荷 (平均負荷ではない) に合わせたサイズを設定します。
• ECOSIRE の無料サーバー サイジング カリキュレーターを使用して、特定のユーザー数と ERP プラットフォームの仕様を生成します

---

ERP サーバーのサイジングが異なる理由

具体的な推奨事項に入る前に、ERP サーバーのサイジングには、一般的な Web アプリケーションのサイジングよりも慎重な分析が必要である理由を理解しておく価値があります。

データベースの強度: ERP システムは基本的にトランザクション処理システムです。注文書の作成、請求書の転記、在庫の移動といったユーザーのアクションごとに、アトミックにコミットする必要がある複数のデータベース書き込みが生成されます。データベース層は、多くの場合、複数のテーブル結合や集計計算を伴う、大規模な正規化されたスキーマにわたる複雑なリレーショナル クエリを処理します。これは、ページ ビューごとにいくつかの非正規化テーブルから読み取るコンテンツ管理システムやマーケティング Web サイトとは大きく異なります。

同時ユーザー負荷パターン: ERP ユーザーの動作は、一般的な Web アプリケーションよりも同時的です。消費者向け Web サイトでは、ユーザーは頻繁に対話せずに独立して閲覧します。 ERP システムでは、同じ部門の複数のユーザーがピーク時間 (月末、一日の終わり、シフト終了時) に注文を同時に処理することがあります。この同時書き込みパターンにより、一般的な Web アプリケーションでは決して遭遇しないデータベース ロックの競合が発生します。

レポート生成のワークロード: ERP レポート、特に財務レポート、在庫エージング、需要予測では、30 ～ 120 秒間実行され、実行中に大量の CPU と I/O を消費する複雑な複数テーブルのクエリを実行します。 3 人の財務スタッフ全員が同時に月末決算レポートを実行すると、負荷が大幅に急増する可能性があります。

セッション状態とワーカー プロセス: Odoo は特に、アクティブなユーザー接続ごとにセッション状態を維持する Python ワーカー プロセスを実行します。各ワーカー プロセスは、定常状態で約 200 ～ 400 MB の RAM を消費し、負荷の高いレポートの実行中には最大 1 GB の RAM を消費します。サーバーには、ディスクにスワップせずにすべてのアクティブなワーカーを同時に実行するのに十分な RAM が必要です。ERP データベース サーバーでのスワップは、致命的なパフォーマンスの低下を引き起こします。

---

ERP サーバーのサイジングにおける主要な変数

ERP サーバーのリソース要件は、次の 4 つの変数によって他の変数よりも大きく左右されます。

1.同時ユーザー数 (合計ユーザー数ではありません)

総ユーザー数は、リソース要件の予測には不十分です。適切な指標はピーク同時ユーザー数です。これは、1 日の中で最も混雑する時間帯に、システムに対して同時にアクティブにリクエストを行っているユーザーの数です。

合計ユーザー数からピーク同時ユーザーを推定します。

• 通常営業時間のオフィスベースの ERP: ピーク時に総ユーザー数の 15 ～ 25% が同時接続
• 複数のシフトを伴う製造: 同時ユーザー総数の 25 ～ 35% (シフト変更のピーク)
• タイムゾーンをまたがる分散操作: ピーク同時実行性は低くなりますが、ピーク期間は長くなります。
• 月末の財務負荷の高い使用量: クローズ期間中の同時使用率が一時的に 40 ～ 50% に急増

通常のオフィスベースの使用で 100 ユーザーの Odoo 展開の場合、通常のピーク時に 15 ～ 25 人の同時ユーザーを計画し、月末には 40 ～ 50 人の同時ユーザーを計画します。ユーザーの合計 100 人ではなく、これによってサイジングの計算が行われます。

2.トランザクション量とトランザクションの複雑さ

トランザクション量が多いと、同時ユーザーとは関係なくデータベースの書き込み負荷が増加します。 1 日あたり 2,000 件の発注書を処理する流通会社は、ユーザーが 100 人でもトランザクション量が少ないプロフェッショナル サービス会社よりも、はるかに多くのデータベース書き込み I/O を生成します。同様に、複雑なトランザクション (BOM 消費、在庫、原価計算、品質記録を同時に更新する作業指示書の製造) は、単純なトランザクション (2 つの G/L 勘定を更新する仕訳転記) よりも多くの I/O を生成します。

使用されているモジュールを考慮して、トランザクションの複雑さを見積もります。製造および複数の倉庫の在庫では、最も複雑なトランザクションが生成されます。シンプルな会計モジュールと HR モジュールが最も単純なものを生成します。

3.データベースのサイズと増加率

データベース サイズは、直接的 (テーブルが大きいほどスキャンに時間がかかる) と間接的 (利用可能な RAM を超えるワーキング セットはキャッシュ ミスや I/O の増加につながる) の 2 つの方法でクエリのパフォーマンスに影響します。

ERP データベースは、ほとんどの IT チームが予想するよりも速く成長します。開始時のデータベースは 20 GB ですが、トランザクション履歴、ドキュメントの添付ファイル、監査ログによる通常の増加により、2 ～ 3 年で 100 GB に達する可能性があります。現在のニーズだけでなく、3 年間の予想される成長に合わせてストレージのサイズを設定します。

4.統合と API のワークロード

ERP が API (e コマース プラットフォーム、3PL システム、銀行 API、マーケットプレイス コネクタ) 経由で外部システムに接続している場合、これらの統合により、ユーザー数には反映されない追加のサーバー負荷が発生します。各 API 呼び出しは ERP のアプリケーション層とデータベースを経由します。大規模な統合 (1 時間あたり 1,000 件の注文同期リクエストを処理) は、10 ～ 20 人の同時ユーザーの負荷に匹敵します。

---

プラットフォームとユーザー数別のサイジング ガイドライン

Odoo 19 エンタープライズ

Odoo のアーキテクチャでは、それぞれがユーザーのリクエストを処理するワーカー プロセス (Odoo ワーカー) を使用します。ワーカーの数と必要なサーバー リソースは、同時ユーザー数に応じて増加します。

Odoo ワーカーの計算:

• 推奨されるワーカー数 = (同時ユーザー / 6) + 1、切り上げ
• 各ワーカーには定常状態で約 300 ～ 500 MB の RAM が必要ですが、大量のレポートが発生している場合は最大 1 GB が必要です。
• Cron ワーカー (バックグラウンド プロセス用) は 2 ～ 4 個の追加ワーカーを追加します

ユーザー数別の最小推奨仕様:

Odoo のサイジングに関する重要な注意事項:

• データベース (PostgreSQL) とアプリケーション (Odoo ワーカー プロセス) は、100 ユーザーを超える別々のサーバーで実行するのが理想的です。単一サーバー上で結合すると、データベースとアプリケーションが RAM をめぐって競合します。
• PostgreSQL 共有メモリ (Effective_cache_size) は、データベース サーバー RAM の 50 ～ 75% に設定する必要があります。
• PostgreSQL データ ディレクトリには SSD ストレージが必須です。回転ディスクは ERP データベースで壊滅的なパフォーマンスを引き起こします。
• 50 ユーザーを超える展開には、Odoo セッション ストレージ用に別の Redis サーバーを使用することをお勧めします。

Microsoft Dynamics 365 Business Central

SaaS 導入モデルを使用する場合、Business Central は Microsoft Azure インフラストラクチャ上でクラウドでホストされます。この場合、サーバーのサイジングは Microsoft によって管理されます。オンプレミス展開の場合:

Business Central オンプレミスでは SQL Server をデータベースとして使用し、PostgreSQL とは別のメモリ管理モデルを備えています。専用 RAM を SQL Server のバッファ プール (max server memory 設定経由) に割り当てます (データベース サーバー RAM の約 75%)。

SAP ビジネス ワン

SAP Business One はオンプレミス (Windows または HANA) または SAP Business One Cloud にデプロイされます。

SAP HANA (SAP Business One HANA エディションで使用されるインメモリ データベース) は、ワーキング セットがメモリに収まる必要があるため、従来のディスクベースのデータベースよりもはるかに高い RAM 要件があります。 HANA の RAM 要件は交渉の余地がありません。メモリが不足した HANA は機能低下ではなくクラッシュします。

---

クラウド インスタンスの推奨事項

AWS、Azure、または GCP で ERP をセルフホスティングする場合、適切なインスタンス タイプを選択することが非常に重要です。 vCPU と RAM の数が同じすべてのインスタンスがデータベース ワークロードに対して同等にパフォーマンスを発揮できるわけではありません。

Odoo に対する AWS の推奨事項 (アプリとデータベースの組み合わせ、100 ユーザー未満):

• t3.xlarge (4 vCPU、16 GB): 開発および小規模運用 (25 ユーザー未満)
• r6i.xlarge (4 vCPU、32 GB): 中小規模の運用環境 (25 ～ 50 ユーザー)
• r6i.2xlarge (8 vCPU、64 GB): 中実稼働環境 (50 ～ 100 ユーザー)
• r6i.4xlarge (16 vCPU、128 GB): 大規模な運用環境 (合計 100 ～ 200 ユーザー)

Odoo に対する AWS の推奨事項 (アプリケーション/データベースの分割、100 人以上のユーザー):

• アプリケーション サーバー: c6i.2xlarge (8 vCPU、16 GB) — コンピューティングに最適化
• データベース サーバー: r6i.4xlarge (16 vCPU、128 GB) — メモリ最適化
• データベース ストレージ: io2 EBS ボリューム (プロビジョニングされた IOPS) — 3,000 ～ 6,000 IOPS のプロビジョニング

Azure に相当するもの:

• アプリケーション サーバー: Standard_F8s_v2 (8 vCPU、16 GB)
• データベース サーバー: Standard_E16s_v5 (16 vCPU、128 GB)

GCP に相当するもの:

• アプリケーション サーバー: c2-standard-8 (8 vCPU、32 GB)
• データベース サーバー: n2-highmem-16 (16 vCPU、128 GB)

I/O パフォーマンスの罠: AWS の標準 EBS gp3 ボリュームは、デフォルトで 3,000 IOPS を提供します。同時ユーザー数が 50 人を超える実稼働 ERP データベースの場合、これでは不十分なことがよくあります。特に複数の複雑なレポートが同時に実行される月末締めの際には十分です。データベース ストレージには io2 プロビジョニングされた IOPS ボリュームを使用し、少なくとも 3,000 IOPS がプロビジョニングされます。コストの違いは大きいですが (gp3 の場合は 0.065 ドル/GB/月、io2 の場合は 0.125 ドル/GB/月、さらにプロビジョンド IOPS の場合は 0.065 ドル/IOPS/月)、パフォーマンスの違いも大きくなります。

---

高可用性アーキテクチャ

ダウンタイムがビジネスに大きな影響を与える運用 ERP システムの場合は、単一サーバーの障害に対する回復力を提供する高可用性アーキテクチャを検討してください。

Odoo の最小 HA アーキテクチャ (100 ユーザー以上):

• ロード バランサーの背後にある 2 つのアプリケーション サーバー (ラウンドロビンまたはスティッキー セッション)
• スタンバイ レプリカを備えた PostgreSQL プライマリ データベース (ストリーミング レプリケーションまたは AWS RDS マルチ AZ を使用)
• セッションストレージ用の Redis クラスター (2 ノード)
• Odoo の添付ファイル データ用の共有ファイル ストレージ (AWS EFS または同等のもの)

このアーキテクチャは、手動介入を必要とせずに、単一サーバーの障害に対する回復力を提供します。プライマリ PostgreSQL からスタンバイへのフェイルオーバーは自動 (Patroni または AWS RDS を使用) で、通常は 30 ～ 60 秒で完了します。

一般的な ERP の RPO および RTO 目標:

• 目標復旧時点 (最大データ損失): 5 分 (同期レプリケーションの場合) ～ 30 分 (非同期レプリケーションの場合)
• 目標復旧時間 (最大ダウンタイム): 自動フェイルオーバーの場合は 30 ～ 60 秒、手動復旧の場合は 15 ～ 30 分

---

ECOSIRE サーバーサイジング計算ツールの使用

/tools/server-sizing-calculator にある ECOSIRE の無料のサーバー サイジング カリキュレーターは、上記の計算プロセスを自動化します。入力:

1. ERPプラットフォームの選択
2. 総ユーザー数
3. ピーク時の同時ユーザーの割合 (またはユースケースに基づく自動推定)
4. 取引量 (低、中、高、非常に高)
5. 統合の数と量 (なし、基本、中程度、集中)
6. 可用性要件 (単一サーバー、HA、災害復旧)
7. クラウドプロバイダーの設定 (AWS、Azure、GCP、またはオンプレミス)

出力:

• アプリケーション層とデータベース層の推奨サーバー仕様
• ご希望のプロバイダーに対する具体的なクラウド インスタンスの推奨事項
• 毎月のインフラストラクチャコストの見積もり
• アップグレードが必要になる時期を示す 3 年間の成長予測
• ストレージ IOPS 要件と推奨されるストレージ層

この計算ツールは、数十のクライアント実装にわたる ECOSIRE 独自の実稼働展開データに基づいて調整されており、ベンダーのドキュメントのみよりも推定の信頼性が高くなります。

---

よくある質問

これまで ERP を使用したことがない場合、ピーク時の同時ユーザー数をどのように見積もればよいですか?

履歴データのないグリーンフィールド実装の場合は、通常のオフィスベースの展開の開始推定値として総ユーザー数の 20% を使用します。複数のシフトがある場合、または複数のタイムゾーンにまたがって勤務している場合は、25 ～ 30% を使用します。その後、最初の 2 年間の成長に向けて 50% の余裕を追加します。通常の営業時間で 100 ユーザーの ERP の場合、通常のピーク時に 20 人の同時ユーザーを計画し、30 人をプロビジョニングし、インフラストラクチャを変更せずに 40 人に達するキャパシティを構築します。このヘッドルーム アプローチにより、本番稼働後の数か月で導入が改善されるため、パフォーマンスの問題が回避されます。

Odoo アプリケーションとデータベースは同じサーバー上で実行すべきでしょうか、それとも別のサーバー上で実行すべきでしょうか?

ユーザーが 50 人未満の展開の場合、通常は単一の複合サーバーで問題ありません。通常、その規模のアプリケーションとデータベースのワークロードは競合しません。ユーザーが 50 ～ 100 人の場合、決定は使用パターンによって異なります。ユーザー ベースが 1 日を通して均等に分散されており、顕著なピーク時間帯がない場合は、統合サーバーでも機能する可能性があります。急激なピーク (月末、シフトの終わり) がある場合は、アプリケーション サーバーとデータベース サーバーを別々にすると、より適切に分離できます。ユーザーが 100 人を超える場合は、別のサーバーを使用することを強くお勧めします。

Odoo データベースにはどのようなストレージ タイプを使用する必要がありますか?

PostgreSQL データ ディレクトリには SSD ストレージが必須です。スピニング ディスク (HDD) は、本番の ERP データベースでは許容できないパフォーマンスを生み出します。クラウド プラットフォームでは、同時ユーザー数が 50 人を超える場合は、データベース ストレージとしてプロビジョニングされた IOPS SSD (AWS io2、Azure Premium SSD v2、GCP Extreme Persistent Disk) を使用します。汎用 SSD (AWS gp3、Azure Standard SSD) は、同時ユーザー数 25 人未満の開発および小規模な運用環境で使用できます。

サーバーのサイジングにはどれくらいのヘッドルームを組み込む必要がありますか?

通常の運用では予想されるピーク負荷よりも 30 ～ 40% 高いヘッドルームを構築し、月末締めやピーク販売シーズンなどの例外的な期間では 100% のヘッドルーム (実質的にピーク容量の 2 倍) を構築します。クラウド展開では、自動スケーリングを使用して、その容量を永続的に支払うことなく、例外的な期間に対処できます。これは、固定オンプレミス インフラストラクチャと比較してコスト面で大幅な利点があります。

---

次のステップ

/tools/server-sizing-calculator にある ECOSIRE の無料のサーバー サイジング カリキュレーターを使用して、特定の展開の仕様を生成します。計算ツールは、予算計画に使用できる AWS/Azure/GCP インスタンスの推奨事項と毎月のインフラストラクチャ コストの見積もりを出力します。

Odoo の実装を計画しており、ECOSIRE に実装と同時にインフラストラクチャのサイジングとセットアップを処理してもらいたい場合、インフラストラクチャの計画はすべての ECOSIRE 実装業務に含まれます。