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

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

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

アーキテクチャ architecture

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

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

さらに、AEMとアプリケーションサーバーを実行するシングルサーバーシステムから、マルチサーバーのマルチ CPU クラスターインスタンスの高度な拡張セットまで、環境は様々です。 実稼動システムごとに別のコンピュータを使用し、これらのコンピュータで他のアプリケーションを実行しないことをお勧めします。

一般的なハードウェアのサイズ設定に関する考慮事項 generic-hardware-sizing-considerations

以下の節では、様々な考慮事項を考慮して、ハードウェア要件の計算方法に関するガイダンスを提供します。 大規模なシステムの場合、参照構成でシンプルな一連の社内ベンチマークテストを実行することをお勧めします。

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

高度な使用例のハードウェアのサイジング要件は、プロジェクトの詳細なパフォーマンス評価に基づく必要があります。 例外的なハードウェアリソースを必要とする高度なユースケースの特徴は、次の組み合わせです。

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

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

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

データの冗長性を確保するために、独立したディスク（RAID、RAID10 など）の冗長アレイのセットアップを検討します。

仮想化 virtualization

AEMは仮想化環境で適切に動作しますが、物理ハードウェアとは直接同等にはならない要因が CPU や I/O など存在する場合があります。 I/O 速度を（一般的に）高くすることをお勧めします。これは、ほとんどの場合、重要な要因です。 必要なリソースを正確に把握するには、環境のベンチマークを行う必要があります。

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

フェイルセーフ fail-safeness

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

システムリソースのスケーラビリティ system-resources-scalability

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

必要なクラスターノード数の概算は、特定の Web プロジェクトの基本要件と具体的な使用例に基づいて決定されます。

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

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

上記の 2 つのテストでは、操作のタイプに応じてスループットが変化することを明確に示しています。 環境上のアクティビティを、システムのサイズ設定の基礎として使用します。 変更などの集中的なアクションの数が少ないと、スループットが向上します（これはより一般的です）。

キャッシュ caching

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

並行して作業する作成者 authors-working-in-parallel

オーサー環境では、並行して作業するオーサーの数と、そのインタラクションがシステムに追加する負荷が、主な制限要因となります。 したがって、データの共有スループットに基づいてシステムを拡張することをお勧めします。

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

上記の 2 つのテストでは、AEMで基本的な編集操作を実行する作成者に対してAEMの規模が適切に拡大されることが明らかになっています。 一般に、AEMは、読み取り操作のスケーリングに最も効果的です。

一般的な Web サイトでは、ほとんどのオーサリングはプロジェクトフェーズでおこなわれます。 Web サイトが公開されると、並行して作業している作成者の数は通常、低い（運用モード）平均に減少します。

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

n = numberOfParallelAuthors / 30

この式は、作成者がAEMで基本操作を実行する際の CPU のスケーリングに関する一般的なガイドラインとして役立ちます。 システムとアプリケーションが最適化されていることを前提としています。 ただし、MSM や Assets などの高度な機能では、数式は正しく機能しません（以下の節を参照）。

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

ハードウェアRecommendations hardware-recommendations

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

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

AEMインスタンスが実行されていた際の最小ヒープサイズは 256M、最大ヒープサイズは 1024M でした。

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

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

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

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

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

複雑なテンプレートを使用する場合、AEMはページのレンダリングにより多くの時間が必要になります。 キャッシュから取得したページはこの影響を受けませんが、全体的な応答時間を考慮する場合、ページサイズは依然として重要です。 複雑なページのレンダリングは、単純なページのレンダリングよりも 10 倍も簡単に時間がかかる場合があります。

数式 formula

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

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

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

n = (traffic * complexity / 1000 ) * activations

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

より複雑な Web サイトがある場合は、AEMが許容可能な時間内にリクエストに応答できるように、より強力な Web サーバーも必要になります。

その他の使用例固有の計算 additional-use-case-specific-calculations

デフォルトの Web アプリケーションの計算に加えて、次の使用例に対して特定の要因を考慮する必要が生じる場合があります。 計算された値がデフォルトの計算に追加されます。

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

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

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

マルチサイトマネージャ 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）を選択する必要があります。

参照先