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

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

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

• ネットワーク速度

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

• 計算速度

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

• I/O パフォーマンス

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

• ハードドライブ

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

• メモリ

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

アーキテクチャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

仮想化

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

AEM インスタンスの並列化

フェイルセーフ

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

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

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

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

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

オーサー環境用の計算

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

• ベンチマークテスト 1

  ユーザーが、類似した特性を持つ 300 の基本的な読み込みに加えて、単純なページ作成の演習を実行する読み込みプロファイルの最大スループットを計算します。 実行した手順は、サイトへのログイン、SWF と画像／テキストを使用したページの作成、タグクラウドの追加、ページのアクティベーションです。

  • 結果

    上記のような単純なページ作成の演習（1 つのトランザクションと見なされる）の最大スループットは、1 時間あたり 1730 件のトランザクションであることが判明しました。

• ベンチマークテスト 2

  読み込みプロファイルに新しいページの作成 (10%)、既存のページの変更 (80%)、ページの作成と変更 (10%) が混在している場合、最大スループットを計算します。 ページの複雑度はベンチマークテスト 1 のプロファイルの場合と同じです。ページの基本的な変更として、画像を追加し、テキストコンテンツを変更します。この場合も、ベンチマークテスト 1 に定義されたものと同じ複雑度を持つ 300 個のページを基本負荷として、作業をおこないました。

  • 結果

    このような混合操作シナリオの最大スループットは、1 時間あたり 3252 トランザクションであることがわかりました。

前述の 2 つのテストから、操作のタイプに応じてスループットが変化することは明らかです。システムのサイジングをおこなう際には、環境におけるアクティビティを基準として使用します。（よく見られる）変更などの集中的な操作が減るほど、スループットが向上します。

キャッシュ

オーサー環境では、通常、キャッシングの効率が大幅に低下します。これは、web サイトでは変更が頻繁に行われ、またコンテンツが高度にインタラクティブでパーソナライズされているからです。Dispatcher を使用すると、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 やアセットなどの高度な機能には当てはまりません（下記の節を参照）。

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

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

通常、オーサー環境では、パブリッシュ環境に推奨されているものと同じハードウェアを使用できます。一般的に、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 秒間あたりのページ数について、次の表に示します。

キャッシュ率とは、ディスパッチャーが AEM にアクセスしなくても返すことができるページの割合です。100 ％は、ディスパッチャーがすべての要求に応答することを表します。0 ％は、AEM がすべてのページの処理をおこなうことを示します。

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

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

数式

次の式を使用して、AEM ソリューションの全体的な複雑さを計算で推定できます。

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

この複雑さに基づいて、パブリッシュ環境で必要となるサーバー数（または CPU コア数）を次のように求めることができます。

n = (traffic * complexity / 1000 ) * activations

この方程式の変数は、次のとおりです。

複雑な Web サイトの場合は、AEM が受け入れ可能な時間内で要求に応答できるように、より性能の高い Web サーバーが必要となります。

• 4 未満の複雑さ：

  • 1024 MB JVM RAM*
  • 低～中程度のパフォーマンスの CPU

• 複雑度 4 ～ 8:

  • 2048 MB JVM RAM*
  • ミッドからハイパフォーマンスの CPU

• 複雑さが 8 を超える：

  • 4096 MB JVM RAM*
  • ハイエンドからハイエンドの CPU

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

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

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

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

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

Multi Site Manager

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

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

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

さらに考慮すべき点として、AEM MSM のユースケースで予定よりも多くのリソースが消費されると、同時に作業する作成者はパフォーマンスの低下を感じるようになります。

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

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

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

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

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

参照先

• コミュニティコンテンツのストレージ
• Communities 用の推奨トポロジ

Business.Adobe.com リソース

Content Insights Content Intelligence Embedded Charts Content Management Headless Cms Digital Asset Management