ハードウェアのサイジングのガイドライン hardware-sizing-guidelines

このサイジングのガイドラインでは、AEM プロジェクトのデプロイに必要なハードウェアリソースの概算値を示します。サイズの見積もりは、プロジェクトのアーキテクチャ、ソリューションの複雑さ、予想されるトラフィック、プロジェクトの要件に応じて異なります。このガイドを使用すると、具体的なソリューションに必要なハードウェアを特定したり、ハードウェア要件の上限と下限を見積もることができます。

基本的な考慮事項を以下に示します(以下の順序で考慮します)。

  • ネットワーク速度

    • ネットワーク遅延
    • 利用可能な帯域幅
  • 計算速度

    • キャッシュ効率
    • 予想されるトラフィック
    • テンプレート、アプリケーション、コンポーネントの複雑さ
    • 同時に作業する作成者の数
    • 作成操作(簡易コンテンツ編集、MSM ロールアウトなど)の複雑度
  • I/O パフォーマンス

    • ファイルまたはデータベースストレージのパフォーマンスと効率
  • ハードドライブ

    • リポジトリサイズの 2 倍または 3 倍
  • メモリ

    • Web サイトのサイズ(コンテンツオブジェクト、ページ、ユーザーの数)
    • 同時にアクティブなユーザー/セッションの数

アーキテクチャ architecture

通常の AEM 設定は、オーサー環境とパブリッシュ環境で構成されます。これらの環境は、基盤となるハードウェアのサイズおよびシステム設定に関して、それぞれ要件が異なります。両方の環境での詳細な考慮事項については、オーサー環境パブリッシュ環境の各節で説明します。

通常のプロジェクト設定では、次のようないくつかの環境でプロジェクトのフェーズを分類します。

  • 開発環境
    新しい機能の開発や重要な変更を行うために使用します。開発者ごとに開発環境(個人のシステム上でのローカルインストール)を使用して作業することをお勧めします。

  • オーサーテスト環境
    変更を検証するために使用します。テスト環境の数は、プロジェクトの要件によって異なります(個別の QA 用、統合テスト用、ユーザー受け入れテスト用など)。

  • パブリッシュテスト環境
    主にソーシャルコラボレーションのユースケースをテストしたり、オーサーインスタンスと複数のパブリッシュインスタンス間のインタラクションをテストしたりするために使用します。

  • オーサー実稼動環境
    作成者がコンテンツを編集するために使用します。

  • パブリッシュ実稼動環境
    公開済みコンテンツを提供するために使用します。

また、環境は、AEM とアプリケーションサーバーを実行する単一サーバーシステムから、複数のサーバー、複数の CPU で構成される拡張性の高いクラスターインスタンスに至るまで、多岐にわたります。実稼動システムごとに個別のコンピューターを使用し、これらのコンピューターではその他のアプリケーションを実行しないことをお勧めします。

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

この節では、様々な点を考慮しながら、ハードウェア要件を計算する方法について説明します。大規模なシステムの場合、参照構成でシンプルな一連の社内ベンチマークテストを実行することをお勧めします。

特定のプロジェクトに対してベンチマークテストを行う場合は、基本的な作業として、まずパフォーマンスの最適化を実行します。パフォーマンスの最適化に関するドキュメントに記載されている内容を適用してから、ベンチマークテストを実行して、ハードウェアサイジングの計算結果を使用してください。

高度なユースケースの場合、ハードウェアサイジングの要件は、プロジェクトのパフォーマンスを詳細に評価したうえで計算する必要があります。膨大なハードウェアリソースを必要とする高度なユースケースの特徴を次に示します。

  • コンテンツのペイロードが大きく、スループットが高い
  • カスタマイズされたコード、カスタムワークフロー、サードパーティのソフトウェアライブラリの広範な使用
  • サポートされていない外部システムとの統合

ディスク容量/ハードドライブ disk-space-hard-drive

必要なディスク容量は、主に web アプリケーションのボリュームとタイプによって決まります。計算では次の項目を考慮する必要があります。

  • ページ、アセットおよびリポジトリに保存されているその他のエンティティ(ワークフロー、プロファイルなど)のサイズと量
  • 推定されるコンテンツの変更頻度、つまりコンテンツバージョンが作成される頻度
  • 生成される DAM アセットレンディションのボリューム
  • コンテンツ全体の経時的増大

オンライン、オフラインおよびリビジョンのクリーンアップ中は、ディスク容量が継続的に監視されます。使用可能なディスク容量が臨界値を下回った場合、プロセスはキャンセルされます。臨界値とは、リポジトリのその時点でのディスクフットプリントの 25%であり、変更はできません。ディスクのサイズは、予想されるリポジトリの増加分を含めたリポジトリサイズの 2 倍または 3 倍にすることをお勧めします。

データの冗長性を確保するために、独立したディスク(RAID、例えば RAID10)の冗長配列を設定することを検討してください。

NOTE
実稼動用インスタンスの一時ディレクトリでは、利用可能な容量を 6 GB 以上確保する必要があります。

仮想化 virtualization

AEM は仮想環境でも動作しますが、CPU や I/O などの要素については、物理ハードウェアと純粋に同等と見なすことはできません。通常、I/O 速度を高くする(一般的に)ことが重要な要因です。必要なリソースを正確に把握するには、環境のベンチマークテストを行う必要があります。

AEM インスタンスの並列化 parallelization-of-aem-instances

フェイルセーフ

フェールセーフ web サイトは、少なくとも 2 つの別々のシステムにデプロイします。1 つのシステムが故障しても、別のシステムが引き継ぐため、システム障害を補うことができます。

システムリソースのスケーラビリティ

すべてのシステムを実行しながらでも、コンピューターのパフォーマンスを向上することができます。このパフォーマンスは、必ずしもクラスターノード数に比例して直線的に向上するわけではなく、技術環境に大きく依存します。詳しくは、クラスタードキュメントを参照してください。

必要なクラスターノードの推定数は、特定の web プロジェクトの基本要件および特定のユースケースによって決まります。

  • フェイルセーフの観点では、すべての環境において、障害の重大度を特定し、クラスターノードのリカバリー所要時間に基づいて障害補償時間を決定する必要があります。
  • スケーラビリティの面から考えると、基本的には書き込み操作数が最も重要です。オーサー環境の場合は同時に操作している作成者を、パブリッシュ環境の場合はソーシャルコラボレーションを参照してください。読み取り操作のみを行うためにシステムにアクセスする場合は、操作を負荷分散することができます。詳しくは、Dispatcher を参照してください。

オーサー環境固有の計算 author-environment-specific-calculations

ベンチマーキングを目的として、アドビはスタンドアロンのオーサーインスタンス用にいくつかのベンチマークテストを開発しました。

  • ベンチマークテスト 1
    同じような性質を持つ既存の 300 ページを負荷のベースにして、ユーザーが単純なページ作成を行った場合の負荷プロファイルの最大スループットを計算します。実行した手順は、サイトへのログイン、SWF と画像/テキストを使用したページの作成、タグクラウドの追加、ページのアクティベーションです。

    • 結果
      1 つのトランザクションと見なされる、上記のような単純なページ作成の演習での最大スループットは、1 時間あたり 1730 件のトランザクションとなります。
  • ベンチマークテスト 2
    新規ページの作成(10 %)、既存ページの変更(80 %)、およびページの作成と変更の連続操作(10 %)の混合を負荷プロファイルとして、その最大スループットを計算します。ページの複雑度はベンチマークテスト 1 のプロファイルの場合と同じです。ページの基本的な変更として、画像を追加し、テキストコンテンツを変更します。この場合も、ベンチマークテスト 1 に定義されたものと同じ複雑度を持つ 300 個のページを基本負荷として、作業を行いました。

    • 結果
      このような混合操作シナリオの最大スループット(1 時間あたりのトランザクション数)は 3252 となりました。
NOTE
スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。

前述の 2 つのテストから、操作のタイプに応じてスループットが変化することは明らかです。システムのサイジングを行う際には、環境におけるアクティビティを基準として使用します。変更などの集中的なアクションの量が少ないと、スループットが向上します(より一般的)。

キャッシュ caching

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

同時操作している作成者 authors-working-in-parallel

オーサー環境で主な制限要因となっているのは、同時操作している作成者の数と、システムに対する作成者の操作の負荷です。したがって、データの共有スループットに基づいてシステムのスケーリングを行うことをお勧めします。

このような状況では、Adobeは、オーサーインスタンスの 2 ノードの共有なしクラスターで、ベンチマークテストを実行しました。

  • ベンチマークテスト 1a
    2 つのオーサーインスタンスからなるアクティブ-アクティブ構成のシェアードナッシングクラスターで、すべて類似の性質を持つ 300 個の既存ページを基本負荷として、ユーザーが単純なページ作成作業を行うという負荷プロファイルの最大スループットを計算します。

    • 結果
      1 つのトランザクションと見なされる、上記のような単純なページ作成の演習での最大スループットは、1 時間あたり 2016 件のトランザクションとなります。 スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 16 %増加しています。
  • ベンチマークテスト 2b
    2 つのオーサーインスタンスからなるアクティブ-アクティブ構成のシェアードナッシングクラスターで、負荷プロファイルに新規ページの作成(10 %)、既存ページの変更(80 %)、およびページの作成と変更の連続操作(10 %)が混在する際の最大スループットを計算します。ページの複雑度はベンチマークテスト 1 のプロファイルの場合と同じです。ページの基本的な変更として、画像を追加し、テキストコンテンツを変更します。この場合も、ベンチマークテスト 1 に定義されたものと同じ複雑度を持つ 300 個のページを基本負荷として、作業を行いました。

    • 結果
      このような混合操作シナリオの最大スループット(1 時間あたりのトランザクション数)は 6288 となりました。スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 93 %増加しています。
NOTE
スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。

前述の 2 つのテストから、AEM で基本的な編集操作を行う作成者にとってスケーリングが適切に機能していることは明らかです。一般に、AEM は読み取り操作のスケーリングを行うのに最も効果的です。

標準的な web サイトでは、ほとんどの作成操作がプロジェクトフェーズで行われます。Web サイトを実稼動に移行した後は、同時操作している作成者の数は、通常、(運用モードの)平均値に下がります。

オーサー環境に必要なコンピューター(CPU)の台数は次のように計算できます。

n = numberOfParallelAuthors / 30

この式は、作成者が AEM で基本的な操作を実行する場合の CPU スケーリングのガイドラインとして使用できます。システムおよびアプリケーションが最適化されていることが前提となります。ただし、この式は、MSM やアセットなどの高度な機能には当てはまりません(下記の節を参照)。

並列化およびパフォーマンスの最適化も参照してください。

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

通常、オーサー環境では、パブリッシュ環境に推奨されているものと同じハードウェアを使用できます。通常、オーサリングシステムでは Web サイトのトラフィックは少なくなりますが、キャッシュの効率も低くなります。 ただし、ここで基本的な要因となるのは、同時操作している作成者の数と、システムに対するアクションの種類です。一般に、(オーサー環境の)AEM クラスタリングは読み取り操作のスケーリングを行うのに最も効果的です。言い換えると、AEM クラスターのスケーリングは、基本的な編集操作を行う作成者にとって適切に機能します。

アドビでのベンチマークテストは、以下で構成される Hewlett-Packard ProLiant DL380 G5 ハードウェアプラットフォームで実行されている Red Hat® 5.5 オペレーティングシステムを使用して行われました。

  • 2 基のクアッドコア Intel Xeon® X5450 CPU、3.00 GHz
  • 8 GB RAM
  • Broadcom NetXtreme II BCM5708 ギガビットイーサネット
  • HP Smart Array RAID Controller、256 MB キャッシュ
  • 2 個の 146 GB 10,000 RPM SAS ディスク(RAID0 ストライプセットとして構成)
  • SPEC CINT2006 Rate ベンチマークスコア 110

AEM インスタンス実行時の最小ヒープサイズおよび最大ヒープサイズはそれぞれ 256M および 1024M です。

パブリッシュ環境用の計算 publish-environment-specific-calculations

キャッシュ効率とトラフィック caching-efficiency-and-traffic

キャッシュ効率は web サイトの速度を検討するにあたって欠かせない要素です。最適化された AEM システムで、Dispatcher などのリバースプロキシを使用して処理できる 1 秒間あたりのページ数について、次の表に示します。

キャッシュ率
ページ/秒(ピーク)
1 日あたり 100 万ページ(平均)
100%
1000 ~ 2000
35 ~ 70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
CAUTION
免責事項:この数値はデフォルトのハードウェア構成に基づいており、使用される個々のハードウェアによって異なる可能性があります。

キャッシュ率とは、Dispatcher が AEM にアクセスしなくても返すことができるページの割合です。100 %は、Dispatcher がすべてのリクエストに回答することを示し、0 %は AEM がすべてのページを計算することを意味します。

テンプレートとアプリケーションの複雑度 complexity-of-templates-and-applications

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

数式 formula

次の式を使用して、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
Dispatcher キャッシュから取得されるページの割合。すべてのページがキャッシュから取得される場合は 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
NOTE
* JVM に必要なメモリ量に加え、オペレーティングシステムを稼動させるために十分な RAM を確保してください。

その他のユースケース用の計算 additional-use-case-specific-calculations

デフォルトの Web アプリケーションの計算に加えて、次の使用例の具体的な要因を考慮します。 計算された値は、デフォルトの計算結果に加算されます。

アセットに固有な考慮事項 assets-specific-considerations

デジタルアセットを大規模に処理するには、最適化されたハードウェアリソースが必要になります。最も関連する要因は、画像サイズと、処理された画像のピーク時のスループットです。

16 GB 以上のヒープを割り当て、Camera Raw パッケージを使用して Raw 画像を取り込むように、DAM アセット更新ワークフローを設定します。

NOTE
イメージのスループットが高いと、コンピューティングリソースがシステム I/O や逆に対応できる必要があります。 例えば、画像のインポートによってワークフローが開始された場合、多数の画像を WebDAV 経由でアップロードすると、ワークフローのバックログが発生する可能性があります。
TarPM、データストアおよび検索インデックスに個別のディスクを使用することで、システム I/O 動作を最適化できます(ただし、検索インデックスは、通常、ローカルに保持することが合理的です)。
NOTE
詳しくは、アセットパフォーマンスガイドも参照してください。

マルチサイトマネージャー multi-site-manager

オーサリング環境で AEM MSM を使用する場合のリソースの消費量は、ユースケースによって大きく異なります。基本的な要因は次のとおりです。

  • ライブコピーの数
  • ロールアウトの頻度
  • ロールアウトするコンテンツツリーのサイズ
  • ロールアウトアクションの連携機能

計画されたユースケースをテストする際に代表的なコンテンツを引用すると、リソース消費量をより的確に把握できます。スループット計画から結果を推定することで、AEM MSM で別途必要になるリソースを評価できます。

また、同時に並行して作成者が作業していることも考慮します。AEM MSM のユースケースで予定よりも多くのリソースが消費されると、作成者はパフォーマンスの低下に気付くことになります。

AEM Communities のサイジングの考慮事項 aem-communities-sizing-considerations

AEM Communities の機能を含む AEM Sites (コミュニティサイト)には、パブリッシュ環境のサイト訪問者(メンバー)から高レベルのインタラクションがあります。

コミュニティサイトのサイジングに関する考慮事項は、コミュニティメンバーによる予測されるインタラクションとページコンテンツの最適なパフォーマンスの重要度が高いかどうかによって異なります。

メンバーによって送信されたユーザー生成コンテンツ(UGC)は、ページコンテンツとは分けて保存されます。AEM プラットフォームではオーサー環境からパブリッシュ環境にサイトコンテンツをレプリケートするノードストアを使用し、AEM Communities では UGC のために単一の共通ストアを使用します。UGC はレプリケートされません。

UGC ストアの場合は、選択したデプロイメントに影響を及ぼすストレージリソースプロバイダー(SRP)を選択する必要があります。
参照先

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2