Show Menu
トピック×

ハードウェアのサイジングのガイドライン

このサイジングのガイドラインでは、AEM プロジェクトのデプロイに必要なハードウェアリソースの概算値を示します。サイズの予測は、プロジェクトのアーキテクチャ、ソリューションの複雑さ、予想されるトラフィック、およびプロジェクトの要件によって異なります。 このガイドは、特定のソリューションに必要なハードウェアや、ハードウェア要件の上限、下限の概算値を把握する際に役立ちます。
考慮すべき基本的な要因は次のとおりです。
  • ネットワーク速度
    • ネットワーク遅延
    • 利用可能な帯域幅
  • 計算速度
    • キャッシュの効率
    • 予想トラフィック
    • テンプレート、アプリケーション、コンポーネントの複雑さ
    • 同時に作業する作成者の数
    • 作成操作(簡易コンテンツ編集、MSM ロールアウトなど)の複雑度
  • I/Oパフォーマンス
    • ファイルまたはデータベースのパフォーマンスと効率ストレージ
  • ハードドライブ
    • リポジトリサイズの 2 倍または 3 倍以上
  • メモリ
    • Webサイトのサイズ(コンテンツオブジェクト、ページ、ユーザーの数)
    • 同時にアクティブなユーザー/セッションの数

アーキテクチャ

通常の AEM 設定は、オーサー環境とパブリッシュ環境で構成されます。これらの環境は、基盤となるハードウェアのサイズおよびシステム設定に関して、それぞれ要件が異なります。Detailed considerations for both environments are described in the author environment and publish environment sections.
通常のプロジェクト設定では、次のようないくつかの環境でプロジェクトのフェーズを分類します。
  • 開発環境 新しい機能の開発や重要な変更をおこなうために使用します。ベストプラクティスは、開発者ごとの開発環境(通常は個人用システムにローカルでインストール)を使用することです。
  • 作成者テスト環境 ​変更を検証します。 テスト環境の数は、プロジェクトの要件に応じて異なります(例えば、QA、統合テスト、ユーザー受け入れテスト用に別々に)。
  • パブリッシュテスト環境 主にソーシャルコラボレーションのユースケースをテストしたり、オーサーインスタンスと複数のパブリッシュインスタンス間のインタラクションをテストしたりするために使用します。
  • オーサー実稼動環境 作成者がコンテンツを編集するために使用します。
  • パブリッシュ実稼動環境 公開済みコンテンツを提供するために使用します。
また、環境は、AEM とアプリケーションサーバーを実行する単一サーバーシステムから、複数のサーバー、複数の CPU で構成される拡張性の高いクラスターインスタンスに至るまで、多岐にわたります。実稼動システムごとに個別のコンピューターを使用し、これらのコンピューターではその他のアプリケーションを実行しないことをお勧めします。

ハードウェアサイジングに関する一般的なガイドライン

この節では、様々な点を考慮しながら、ハードウェア要件を計算する方法について説明します。大規模なシステムの場合、基準設定で一連の単純な社内ベンチマークテストを実行することをお勧めします。
特定のプロジェクトに対してベンチマークテストをおこなう場合は、基本的な作業として、まずパフォーマンスの最適化を実行します。ベンチマークテストを実行し、ハードウェアサイジングの計算結果を使用する前に、 パフォーマンスの最適化に関するドキュメント に記載されている内容に従ってください。
高度なユースケースの場合、ハードウェアサイジングの要件は、プロジェクトのパフォーマンスを詳細に評価したうえで計算する必要があります。膨大なハードウェアリソースを必要とする高度なユースケースの特徴を次に示します。
  • コンテンツのペイロードが大きく、スループットが高い
  • カスタマイズされたコード、カスタムワークフロー、またはサードパーティソフトウェアライブラリの広範な使用
  • サポートされていない外部システムとの統合

ディスク容量/ハードドライブ

必要なディスク容量は、主に Web アプリケーションのボリュームとタイプによって決まります。計算では次の項目を考慮する必要があります。
  • ページ、アセットおよびリポジトリに保存されているその他のエンティティ(ワークフロー、プロファイルなど)のサイズと量
  • 推定されるコンテンツの変更頻度、つまりコンテンツバージョンが作成される頻度
  • 生成される DAM アセットレンディションのボリューム
  • コンテンツ全体の経時的増大
オンライン、オフラインおよびリビジョンのクリーンアップ中は、ディスク容量が継続的に監視されます。使用可能なディスク容量が臨界値を下回ると、プロセスがキャンセルされます。臨界値はリポジトリの現在のディスクフットプリントの 25 %で、設定はできません。推定増加量を含め、リポジトリ・サイズの2倍または3倍以上のサイズでディスクをサイズ設定することをお勧めします。
データの冗長性を確保するために、独立したディスク(RAID、例えば RAID10)の冗長配列を設定することを検討してください。
実稼働用インスタンスの一時ディレクトリでは、利用可能な容量を 6 GB 以上確保する必要があります。

仮想化

AEM は仮想環境でも動作しますが、CPU や I/O などの要素については、物理ハードウェアと純粋に同等と見なすことはできません。ほとんどの場合、I/O 速度は非常に重要です。したがって、通常は、より高速な I/O を選択することをお勧めします。必要なリソースを正確に把握するには、環境のベンチマークテストをおこなう必要があります。

AEM インスタンスの並列化

フェイルセーフ
フェールセーフWebサイトは、2つ以上の別々のシステムに展開されます。 一方のシステムが故障した場合、他方のシステムが引き継ぎ、システム障害を補うことができます。
システムリソースのスケーラビリティ
すべてのシステムが実行されているときのコンピューターのパフォーマンスが向上しました。That additional performance is not necessarily linear with the number of cluster nodes as the relationship is highly dependent on the technical environment; please see the Cluster documentation for more information.
必要なクラスターノードの推定数は、特定の Web プロジェクトの基本要件および特定のユースケースによって決まります。
  • フェイルセーフの観点では、すべての環境において、障害の重大度を特定し、クラスターノードのリカバリー所要時間に基づいて障害補償時間を決定する必要があります。
  • スケーラビリティの面から考えると、基本的には書き込み操作数が最も重要です。オーサー環境の場合は 同時操作している作成者 を、パブリッシュ環境の場合は ソーシャルコラボレーション を参照してください。Load balancing can be established for operations that access the system solely to process read operations; see Dispatcher for details.

オーサー環境用の計算

ベンチマーキングを目的として、Adobe はスタンドアロンのオーサーインスタンス用にいくつかのベンチマークテストを開発しました。
  • ベンチマークテスト 1 すべて類似の性質を持つ 300 個の既存ページを基本負荷として、ユーザーが単純なページ作成作業をおこなう際の負荷プロファイルの最大スループットを計算します。実行した手順は、サイトへのログイン、SWF と画像/テキストを使用したページの作成、タグクラウドの追加、ページのアクティベーションです。
    • 結果 前述のような単純なページ作成作業を 1 個のトランザクションと見なした場合、最大スループット(1 時間あたりのトランザクション数)は 1730 となりました。
  • ベンチマークテスト 2 新規ページの作成(10 %)、既存ページの変更(80 %)、およびページの作成と変更の連続操作(10 %)の混合を負荷プロファイルとして、その最大スループットを計算します。ページの複雑度はベンチマークテスト 1 のプロファイルの場合と同じです。ページの基本的な変更として、画像を追加し、テキストコンテンツを変更します。この場合も、ベンチマークテスト 1 に定義されたものと同じ複雑度を持つ 300 個のページを基本負荷として、作業をおこないました。
    • 結果 このような混合操作シナリオの最大スループット(1 時間あたりのトランザクション数)は 3252 となりました。
スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。
前述の 2 つのテストから、操作のタイプに応じてスループットが変化することは明らかです。システムのサイジングをおこなう際には、環境におけるアクティビティを基準として使用します。(よく見られる)変更などの集中的な操作が減るほど、スループットが向上します。

キャッシュ

オーサー環境では、通常、キャッシングの効率が大幅に低下します。これは、Web サイトでは変更が頻繁に行われるうえに、コンテンツがインタラクティブで、個人用にカスタマイズされているからです。ディスパッチャーを使用すると、AEMライブラリ、JavaScript、CSSファイルおよびレイアウトイメージをキャッシュできます。 これにより、作成プロセスの一部の側面が高速化されます。こうしたリソースのブラウザーキャッシングのヘッダーを追加で設定するように Web サーバーを設定すると、HTTP 要求数が減り、作成操作の際のシステムの応答性が向上します。

同時操作している作成者

オーサー環境で主な制限要因となっているのは、同時操作している作成者の数と、システムに対する作成者の操作の負荷です。したがって、データの共有スループットに基づいてシステムのスケーリングをおこなうことをお勧めします。
このようなシナリオを対象として、Adobe は、オーサーインスタンスからなる 2 つのノードのシェアードナッシングクラスターでベンチマークテストを実行しました。
  • ベンチマークテスト 1a 2 つのオーサーインスタンスからなるアクティブ-アクティブ構成のシェアードナッシングクラスターで、すべて類似の性質を持つ 300 個の既存ページを基本負荷として、ユーザーが単純なページ作成作業をおこなうという負荷プロファイルの最大スループットを計算します。
    • 結果 前述のような単純なページ作成作業を 1 個のトランザクションと見なした場合、最大スループット(1 時間あたりのトランザクション数)は 2016 となりました。スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 16 %増えています。
  • ベンチマークテスト2b 2つのオーサーインスタンスのアクティブ — アクティブな共有 — なしクラスターを使用して、読み込みプロファイルに新規ページ作成(10%)、既存ページの修正(80%)、ページの作成と変更(10%)が混在する場合の最大スループットを計算します。 ページの複雑度はベンチマークテスト 1 のプロファイルの場合と同じです。ページの基本的な変更として、画像を追加し、テキストコンテンツを変更します。この場合も、ベンチマークテスト 1 に定義されたものと同じ複雑度を持つ 300 個のページを基本負荷として、作業をおこないました。
    • 結果 このような混合操作シナリオの最大スループット(1 時間あたりのトランザクション数)は 6288 となりました。スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 93 %増えています。
スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。
前述の 2 つのテストから、AEM で基本的な編集操作をおこなう作成者にとってスケーリングが適切に機能していることは明らかです。一般に、AEM は読み取り操作のスケーリングをおこなうのに最も効果的です。
標準的な Web サイトでは、ほとんどの作成操作がプロジェクトフェーズで行われます。Web サイトを実稼動に移行した後は、同時操作している作成者の数は、通常、(運用モードの)平均値に下がります。
作成者のコンピューターに必要なコンピューター(またはCPU)の数は、次のように環境できます。
n = numberOfParallelAuthors / 30
この式は、作成者が AEM で基本的な操作を実行する場合の CPU スケーリングのガイドラインとして使用できます。システムおよびアプリケーションが最適化されていることが前提となります。ただし、この式は、MSM やアセットなどの高度な機能には当てはまりません(下記の節を参照)。
Please also see the additional comments on Parallelization and Performance Optimization .

ハードウェアに関する推奨事項

通常、オーサー環境では、パブリッシュ環境に推奨されているものと同じハードウェアを使用できます。一般的に、Web サイトのトラフィックは作成システムでは大幅に少なくなっていますが、キャッシュの効率も低下します。ただし、ここで基本的な要因となるのは、同時操作している作成者の数と、システムに対するアクションの種類です。一般に、(オーサー環境の)AEM クラスタリングは読み取り操作のスケーリングをおこなうのに最も効果的です。言い換えると、AEM クラスターのスケーリングは、基本的な編集操作をおこなう作成者にとって適切に機能します。
アドビのベンチマークテストは、Hewlett-Packard ProLiant DL380 G5ハードウェアプラットフォーム上で実行され、次の設定でRedHat 5.5オペレーティングシステムを使用して行われました。
  • 2 個のクアドコア Intel Xeon X5450 CPU、3.00 GHz
  • 8 GB RAM
  • Broadcom NetXtreme II BCM5708 ギガビットイーサネット
  • HP Smart Array RAID コントローラー、256 MB キャッシュ
  • 2 個の 146 GB 10,000 RPM SAS ディスク(RAID0 ストライプセットとして構成)
  • SPEC CINT2006 Rate ベンチマークスコア 110
AEM インスタンス実行時の最小ヒープサイズおよび最大ヒープサイズはそれぞれ 256M および 1024M です。

パブリッシュ環境用の計算

キャッシュ効率とトラフィック

キャッシュ効率は Web サイトの速度を検討するにあたって欠かせない要素です。最適化された AEM システムで、ディスパッチャーなどのリバースプロキシを使用して処理できる 1 秒間あたりのページ数について、次の表に示します。
キャッシュ率
ページ/秒(ピーク時)
1日あたり100万ページ(平均)
100%
1000-2000
35-70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
免責事項:この数値はデフォルトのハードウェア構成に基づいており、使用される個々のハードウェアによって異なる可能性があります。
キャッシュ率とは、ディスパッチャーが AEM にアクセスしなくても返すことができるページの割合です。100 %は、ディスパッチャーがすべての要求に応答することを表します。0 %は、AEM がすべてのページの処理をおこなうことを示します。

テンプレートとアプリケーションの複雑度

複雑なテンプレートを使用している場合、AEM でページのレンダリングにかかる時間が増加します。キャッシュから取得されたページでは、このような影響はありません。ただし、全体の応答時間を考慮した場合、ページサイズはパフォーマンスに関係します。複雑なページのレンダリングでは、単純なページのレンダリングと比較して 10 倍の時間がかかることもあります。

数式

次の式を使用して、AEMソリューションの全体的な複雑さの予測を計算できます。
complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)
複雑さに基づいて、次のようにパブリッシュサーバーに必要なサーバー(またはCPUコア)の数を環境できます。
n = (traffic * complexity / 1000 ) * activations
この方程式の変数について次に示します。
交通 1秒あたりの予想ピークトラフィック。 この数値は、1 日あたりのページヒット数を 35,000 で除算することで推定できます。
applicationComplexity
単純なアプリケーションを 1、複雑なアプリケーションを 2 として、1 ~ 2 の値を使用します。
  • 1 — 完全に匿名で、コンテンツ指向のサイト
  • 1.1 — 完全に匿名の、コンテンツ指向のサイトで、クライアント側/ターゲットのパーソナライゼーション
  • 1.5 — 匿名セクションとログインセクション、クライアント側/ターゲットのパーソナライゼーションを持つコンテンツ指向サイト
  • 1.7 — 匿名セクションとログインセクションの両方を持つコンテンツ指向サイト、クライアント側/ターゲットのパーソナライゼーション、および一部のユーザー生成コンテンツ
  • 2 — サイト全体でログインが必要な場所で、ユーザ生成コンテンツを広範に使用し、さまざまなパーソナライゼーションテクニックを使用します。
cacheRatio ディスパッチャーキャッシュから出てくるページの割合。 すべてのページがキャッシュから取得される場合は 1 を、すべてのページが常に AEM で処理される場合は 0 を使用します。
templateComplexity 1 ~ 10 の値でテンプレートの複雑度を指定します。数値が大きいほど、テンプレートが複雑になります。1 ページあたりの平均コンポーネント数が 10 個のサイトには値 1 を使用し、平均コンポーネント数が 40 個のサイトには値 5 を使用し、平均コンポーネント数が 100 個を超えるサイトには値 10 を使用します。
activations 1時間当たりの平均アクティベーション数(作成者から発行層への平均サイズのページとアセットの複製)をxで割った値。xは、システムで行われたアクティベーションの数で、システムで処理された他のタスクへのパフォーマンスの影響はありません。 x = 100 のように、悲観的な初期値をあらかじめ定義しておくこともできます。
複雑な Web サイトの場合は、AEM が受け入れ可能な時間内で要求に応答できるように、より性能の高い Web サーバーが必要となります。
  • 4未満の複雑さ:・ 1024 MB JVM RAM*・低パフォーマンスから中パフォーマンスのCPU
  • 4 ~ 8の複雑さ:・ 2048 MB JVM RAM*・中間から高パフォーマンスのCPU
  • 8を超える複雑さ:・ 4096 MB JVM RAM*・ハイエンドからハイエンドのパフォーマンスCPU
  • JVM に必要なメモリ量に加え、オペレーティングシステムを稼働させるために十分な RAM を確保してください。

その他のユースケース用の計算

デフォルト Web アプリケーション用の計算に加え、次のユースケースに固有の要因を検討する必要がある場合があります。計算後の値は、デフォルトの計算結果に加算されます。

アセットに関する考慮事項

デジタルアセットを大規模に処理するには、最適化されたハードウェアリソースが必要になります。最も関連する要因は、画像サイズと、処理された画像のピーク時のスループットです。
Allocate at least 16GB of heap and configure the DAM Update Asset workflow to use the Camera Raw package for the ingestion of raw images.
画像のスループットが高くなった場合、システム I/O に遅れずに対応するための計算リソースが必要になります(その逆も言えます)。例えば、画像のインポートによってワークフローが開始された場合、多数の画像を WebDAV 経由でアップロードすると、ワークフローのバックログが発生する可能性があります。 TarPM、データストアおよび検索インデックスに対して別個のディスクを使用すると、システム I/O 動作を最適化できます(ただし、検索インデックスは、通常、ローカルに格納しておくことで意味をなします)。
アセットパフォーマンスガイド も参照してください。

Multi Site Manager

作成環境で AEM MSM を使用する場合のリソースの消費量は、ユースケースによって大きく異なります。基本的な要因は次のとおりです。
  • ライブコピーの数
  • ロールアウトの周期性
  • ロールアウトするコンテンツツリーのサイズ
  • ロールアウトアクションの接続機能
計画したユースケースをテストする際に代表的なコンテンツを引用すると、リソース消費量をより的確に把握できます。スループット計画から結果を推定することで、AEM MSM で別途必要になるリソースを評価できます。
さらに考慮すべき点として、AEM MSM のユースケースで予定よりも多くのリソースが消費されると、同時に作業する作成者がパフォーマンスの低下に気付くことになります。

AEM Communities のサイジングの考慮事項

AEM Communities の機能を含む AEM サイト(コミュニティサイト)には、パブリッシュ環境のサイト訪問者(メンバー)から高レベルのインタラクションがあります。
コミュニティサイトのサイジングで何を考慮するかは、コミュニティメンバーによる予測されるインタラクションと、ページコンテンツの最適なパフォーマンスの重要度が高いかどうかによって異なります。
メンバーによって送信されたユーザー生成コンテンツ(UGC)は、ページコンテンツとは分けて保存されます。AEMプラットフォームは、作成者から発行にサイトのコンテンツを複製するノードストアを使用しますが、AEM Communitiesは、複製されない単一の共通のUGCストアを使用します。
UGC ストアの場合は、選択したデプロイメントに影響を及ぼすストレージリソースプロバイダー(SRP)を選択する必要があります。参照先