1. 文書の目的
本書は、プライベート展開シナリオにおけるサーバーおよびミドルウェアリソースの計画をガイドするために使用され、実装エンジニア、運用エンジニア、プリセールス技術支援担当者の参考用です。
文書の内容は、過去のプロジェクトの容量計画、サンプル構成、ミドルウェアのベースラインに基づいており、プリセールス見積もり、リソース申請、実装展開、およびその後の拡張評価に使用できます。
2. 範囲と指示
2.1 範囲
本書は、プライベート展開シナリオにおける異なるユーザー規模のアプリケーションノードおよびミドルウェアリソースの事前計画に適用されます。
2.2 指示
-
このドキュメントの構成はすべて推奨構成であり、初期段階のプロジェクト容量評価およびリソース計画に使用されます。
-
アプリケーションノードのリソースとミドルウェアのリソースは別々に計算すべきであり、混合計画は推奨されません。
-
大規模なユーザーシナリオでは、ミドルウェアのリソースはピーク時のビジネス負荷、同時実行モデル、容量ストレステスト結果、および本番環境の監視データに基づいてさらに補正する必要があります。
-
正式な本番環境では、拡張容量を確保し、高可用性構築を優先することが推奨されます。
-
国内の CPU アーキテクチャサーバーを使用する場合、標準仕様の2倍の総リソースを見積もることを推奨します。
3. 計画の原則
3.1 アプリケーションおよびミドルウェアの展開原則
-
ユーザー数が10,000未満のシナリオでは、実際のプロジェクト状況に応じて、クラスタ内に一部のミドルウェアを展開するかどうかを評価することが可能です。 K8s
-
ユーザー数が10,000以上のシナリオでは、アプリケーションノードとミドルウェアを完全に分離して展開することを推奨します。
-
データベース、キャッシュ、メッセージキュー、検索サービスなどのコアミドルウェアは、高可用性アーキテクチャでの展開を優先することが推奨されます。
-
条件が許す場合、安定性と保守性を向上させるために、成熟したパブリッククラウドのマネージドミドルウェアサービスの使用を優先することが推奨されます。
3.2 オブジェクトストレージ計画原則
-
可能であれば、Alibaba Cloud OSS、Huawei Cloud OBS、Tencent Cloud COS, AWS S3.
-
などのパブリッククラウドのオブジェクトストレージサービスを使用してください。プライベート展開のオブジェクトストレージを使用する場合は、 SSD ディスクを使用する必要があり、容量増加後の性能、安定性、操作性を慎重に評価する必要があります。
-
業務で大量の大きなファイルのアップロード、ダウンロード、プレビュー、またはマルチユーザーによる大規模なスプレッドシート編集シナリオが含まれる場合は、独立したオブジェクトストレージサービスの使用を優先することを推奨します。
4. アプリケーションノード計画
4.1 アプリケーションノード仕様分類
仕様 A
-
推奨仕様:
24C / 48G / >=500G SSD * N -
適用範囲: 10,000 ユーザー未満
-
適用機能:
-
中小規模のビジネスシナリオをサポート可能
-
ミドルウェアはプロジェクトに応じて K8s 環境にデプロイ可能
-
単一ノードは高負荷を担う; ノードが障害を起こした場合、影響範囲は比較的広い
-
仕様 B
-
推奨仕様:
16C / 32G / >=300G SSD * N -
適用範囲: 10,000 ユーザー以上
-
適用機能:
-
大規模で高可用性の展開シナリオに適する
-
独立したミドルウェアを使用する必要があります
-
小規模スペックのマルチノード方式を使用し、よりバランスの取れたスケジューリングと柔軟なスケーリングを提供する
-
ノードがメンテナンス中または問題に遭遇した場合、全体のビジネス影響は小さい
-
4.2 アプリケーションノード計算基準
既存プロジェクトの例と容量計算ルールに基づき、アプリケーションノードは以下の式を用いて推定することを推奨します:
Number of nodes = Number of users × 0.03 ÷ 160
簡単に理解すると次の通りです:
Number of nodes ≈ Number of users ÷ 5300
ここで:
-
同時接続ユーザー係数は次のように推定されます
0.03. -
単一ノードの容量はおおよそ
16C / 32G約です150 ~ 180 QPS. -
次を計算基準として使用することを推奨します
160 QPS/node -
計算結果は切り上げることが推奨され、拡張のための追加容量を確保することが望ましいです。
4.3 アプリケーションノードの推奨構成表
| ユーザ規模（人） | ノード仕様 | 推奨数量 | 展開の提案 |
|---|---|---|---|
| 500 | 24C / 48G / 500G SSD | 1台 | 単一マシンに展開可能。高可用性の場合は、少なくとも3台のサーバーを展開することが推奨されます。 |
| 3000 | 24C / 48G / 500G SSD | 3台 | クラスタモード、高可用性展開（クラスタ展開の最小仕様基準） |
| 10,000 | 24C / 48G / 500G SSD | 3台 | クラスタモード、高可用性展開；外部ミドルウェアの使用はプロジェクトのニーズに応じて評価可能 |
| 30,000 | 16C / 32G / 300G SSD | 5台 | クラスタモード、高可用性展開、独立ミドルウェアを使用 |
| 50,000 | 16C / 32G / 300G SSD | 10 ユニット | クラスタモード、高可用性展開、独立ミドルウェアを使用 |
| 100,000 | 16C / 32G / 300G SSD | 18 ~ 20 ユニット | 18 ユニットから始め、拡張のための容量を確保し、独立したミドルウェアを使用することを推奨します |
| 200,000 | 16C / 32G / 300G SSD | 38 ~ 40 ユニット | 段階的に構築・デプロイすることを推奨します |
| 300,000 | 16C / 32G / 300G SSD | 56 ~ 60 ユニット | 段階的に構築・デプロイすることを推奨します |
| 500,000 | 16C / 32G / 300G SSD | 94 ~ 100 ユニット | 独立したリソースプールを計画し、段階的に構築・デプロイすることを推奨します |
| 700,000 | 16C / 32G / 300G SSD | 132 ~ 140 ユニット | 独立したリソースプールを計画し、段階的に構築・デプロイすることを推奨します |
4.4 アプリケーションノード計画の結論
-
ユーザー数が10,000未満の場合は、仕様Aの使用を推奨します。
-
ユーザー数が10,000以上の場合は、仕様Bの使用を推奨します。
-
ユーザー規模が100,000の場合は、サンプルアンカーに従い18ユニットから開始でき、他の規模は統一された計算式に従って推定し、切り上げます。
-
継続的に成長するプロジェクトの場合は、過剰な一括投資を避けるため、段階的な拡張戦略を進めることを推奨します。
5. ミドルウェア計画
5.1 ミドルウェア分類の原則
現在のミドルウェアリソース計画は、二つの基準層に従って実行されます：
-
Users below 3,000: 小規模なベースライン構成を使用してください。 -
3000 users and above: 大規模ベースライン構成を使用します。
10,000、30,000、50,000、100,000、200,000、300,000、500,000、700,000ユーザーなどの大規模シナリオでは、'3000ユーザー以上’のベースライン構成から統一して開始し、ビジネスの成長に応じて動的にスケールすることを推奨します。
5.2 ミドルウェア仕様ベースライン表
| ミドルウェア | 推奨バージョン | 3000ユーザー未満 | 3000ユーザー以上 | 高可用性要件 |
|---|---|---|---|---|
| MySQL | MySQL 8.0 | 4C / 8G / 200G SSD | 8C / 16G / 200G SSD | マスタースレーブフェイルオーバー高可用性<br>文字セット: utf8mb4<br>タイムゾーン: Asia/Shanghai または UTC<br>接続: 最大_接続数 ≥ 1000 |
| MongoDB | MongoDB 4.4 | 2C / 8G / 100G SSD | 4C / 16G / 100G SSD | レプリカセット高可用性クラスタ |
| Redis | Redis 6.2.21 | 2C / 4G / 100G SSD | 2C / 8G / 100G SSD | マスター・スレーブ/センチネル高可用性、データ永続性； クラスターモード非対応； DB数 ≥ 64 |
| Kafka | Kafka 3.5 | 2C / 4G / 300G SSD | 4C / 8G / 300G SSD | ブローカー >= 3、デフォルトのレプリケーション係数 3<br>メッセージ保持期間：72時間（ビジネスニーズに応じて調整可能）<br>トピックごとの最大単一メッセージサイズ：10 MB<br>認証：対応 SASL 暗号化アクセス（PLAIN, SCRAM-SHA-256, SCRAM-SHA-512) |
| Elasticsearch | ES 8.18.5 | 2C / 4G / 200G SSD | 4C / 8G / 200G SSD | ノード数 >= 3<br>必要なインストール:<br>analysis-ik（中国語分かち書き）、<br>analysis-pinyin（ピンイン分かち書き） |
| オブジェクトストレージ | S3 プロトコル互換 | 互換性あり S3 | 互換性あり S3 プロトコル | パブリッククラウドを推奨、外部アクセス必須 HTTPS 外部アクセス |
注意：
- 上記のミドルウェア仕様は、実際の負荷に応じてスケールする必要があります
6. 実装および運用・保守の提案
6.1 展開実装の提案
-
MySQL, MongoDB, Redis, Kafka, Elasticsearch 高可用性クラスターモードでの展開を推奨します。
-
条件が許せば、安定性と保守性を向上させるために、パブリッククラウドのマネージドデータベースおよびミドルウェアサービスの優先利用を推奨します。
-
1万人以上のユーザーがいるユーザーシナリオでは、アプリケーションノードとミドルウェアを別々に配置することを推奨します。
-
以下のために Kafkaは、他の業務とリソースを共有しないように、別インスタンスを使用することを推奨します。
6.2 オブジェクトストレージ実装の提案
-
パブリッククラウドのオブジェクトストレージ製品の優先使用を推奨します。
-
プライベートオブジェクトストレージを使用する場合は、 SSD ディスクを使用する必要があります。
-
チームスペースで大容量ファイルのアップロード、ダウンロード、プレビューが多いシナリオがある場合、オブジェクトストレージの容量、スループット、および帯域幅が重要な評価要素となります。
6.3 スケーリングの考慮事項
以下のビジネスシナリオでは、ミドルウェアリソースの評価および追加を優先することが推奨されます:
-
大量の添付ファイルのアップロード、ダウンロード、プレビュー
-
高頻度の全文検索
-
メッセージ蓄積または集中的な非同期タスク
-
ピーク時のバッチ書き込みおよび統計分析
-
ログ量の継続的な増加
注目すべき主要指標には以下が含まれます:
-
データベース: CPUメモリ、ディスクIO
-
Redis接続数、ヒット率、帯域幅使用量
-
Kafkaブローカー数、メッセージ蓄積、ディスク容量
-
Elasticsearch: ノード数、インデックスサイズ、ストレージ容量
-
オブジェクトストレージ: 読み取り/書き込み性能、リクエストスループット、容量、帯域幅
7. 結論
-
小規模シナリオ（ユーザー数10,000未満）の場合は、仕様Aのアプリケーションノード構成を推奨し、プロジェクトの状況に応じてクラスタ内に一部のミドルウェアを展開するかどうかを評価してください。
-
中規模および大規模シナリオ（ユーザー数10,000以上）の場合は、仕様Bのアプリケーションノード構成を推奨し、独立したミドルウェアおよび高可用性アーキテクチャと組み合わせて使用してください。
-
ミドルウェアは、「3,000ユーザー未満」と「3,000ユーザー以上」の2つの基準に基づいて構成することを推奨します。大規模プロジェクトでは、継続的な拡張は負荷テストおよび監視データに基づいて行います。
-
公式実装前に、リソース計画の確認、互換性検証、および容量負荷テストを同時に完了させ、展開仕様と実際のサポート範囲の不一致を避ける必要があります。
-
国内の CPU アーキテクチャサーバーを使用する場合は、標準仕様の2倍のリソースを見積もることを推奨します。
-
本マニュアルは事前インストールの選定用であり、現場での負荷テストや最終的な実装の代替にはなりません。