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

このサイジングのガイドラインでは、AEM プロジェクトのデプロイに必要なハードウェアリソースの概算値を示します。サイズの予測は、プロジェクトのアーキテクチャ、ソリューションの複雑さ、予想されるトラフィック、およびプロジェクトの要件によって異なります。 このガイドは、特定のソリューションに必要なハードウェアや、ハードウェア要件の上限、下限の概算値を把握する際に役立ちます。

考慮すべき基本的な要因は次のとおりです。

  • ネットワーク速度

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

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

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

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

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

アーキテクチャ

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

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

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

  • テスト
    環境の作成変更を検証するにはテスト環境の数は、プロジェクト要件に応じて異なる場合があります(例えば、QA、統合テスト、ユーザー受け入れテスト用に分けてください)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メモ

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

仮想化

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

AEM インスタンスの並列化

フェイルセーフ

フェールセーフWebサイトは、少なくとも2つの異なるシステムに展開されます。 一方のシステムが故障した場合は、他方のシステムがそのシステムを引き継ぎ、システム障害を補うことができます。

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

すべてのシステムが実行されているときのコンピューターのパフォーマンスが向上しました。この関係は技術的な環境に大きく左右されるので、追加のパフォーマンスは必ずしもクラスタノードの数と一致するとは限りません。詳しくは、クラスターのドキュメントを参照してください。

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

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

オーサー環境用の計算

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

  • ベンチマークテスト1

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

    • 結果

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

  • ベンチマークテスト2

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

    • 結果

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

メモ

スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。

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

キャッシュ

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

同時操作している作成者

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

このようなシナリオを対象として、Adobe は、オーサーインスタンスからなる 2 つのノードのシェアードナッシングクラスターでベンチマークテストを実行しました。

  • ベンチマークテスト1a

    2つのオーサーインスタンスのアクティブ — アクティブ — アクティブ — 非共有クラスターを使用して、読み込みプロファイルで最大スループットを計算します。基本読み込みの300個の既存ページに対する単純なページ作成の演習を行います。

    • 結果

      上記のような単純なページ作成の演習での最大スループット(1つのトランザクションと見なされる)は、2016年のトランザクション/時間です。 スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 16 %増えています。

  • ベンチマークテスト2b

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

    • 結果

      このような混合操作シナリオの最大スループットは、6288トランザクション/時であることが判明しました。 スタンドアロンのオーサーインスタンスに対して同じベンチマークテストを実行した場合と比較して、約 93 %増えています。

メモ

スループット率から、負荷プロファイル内のトランザクションタイプを区別することはできません。スループットの測定に使用されたアプローチでは、各タイプのトランザクションが固定の比率でワークロードに組み込まれています。

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

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

作成者環境に必要なコンピューター(またはCPU)の数は、次のように計算できます。

n = numberOfParallelAuthors / 30

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

並列処理パフォーマンスの最適化に関する追加のコメントもご覧ください。

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

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

Adobeでのベンチマークテストは、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 平均アクティベーション数(作成者から発行層への平均サイズのページとアセットの複製)を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 アプリケーション用の計算に加え、次のユースケースに固有の要因を検討する必要がある場合があります。計算後の値は、デフォルトの計算結果に加算されます。

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

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

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

メモ

画像のスループットが高くなった場合、システム I/O に遅れずに対応するための計算リソースが必要になります(その逆も言えます)。例えば、画像のインポートによってワークフローが開始された場合、多数の画像を WebDAV 経由でアップロードすると、ワークフローのバックログが発生する可能性があります。

TarPM、データストアおよび検索インデックスに対して別個のディスクを使用すると、システム I/O 動作を最適化できます(ただし、検索インデックスは、通常、ローカルに格納しておくことで意味をなします)。

メモ

アセットパフォーマンスガイドも参照してください。

Multi Site Manager

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

  • ライブコピーの数
  • ロールアウトの周期性
  • ロールアウトするコンテンツツリーのサイズ
  • ロールアウト操作の接続機能

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

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

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

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

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

メンバーによって送信されたユーザー生成コンテンツ(UGC)は、ページコンテンツとは分けて保存されます。AEMプラットフォームは、作成者から発行にサイトのコンテンツを複製するノードストアを使用しますが、AEM Communitiesは、複製されないUGC用の単一の共通ストアを使用します。

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

このページ

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now