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

最終更新日: 2023-05-04
  • トピック:
  • Deploying
    このトピックの詳細を表示
  • 作成対象:
  • User
注意

AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

これらのサイジングガイドラインは、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 速度を(一般的に)高くすることをお勧めします。これは、ほとんどの場合、重要な要因です。 必要なリソースを正確に把握するには、環境のベンチマークを行う必要があります。

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の規模が適切に拡大されることが明らかになっています。 一般に、AEMは、読み取り操作のスケーリングに最も効果的です。

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

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

n = numberOfParallelAuthors / 30

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

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

ハードウェアRecommendations

通常は、パブリッシュ環境に推奨されるハードウェアと同じハードウェアをオーサー環境で使用できます。 通常、オーサリングシステムでは 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 Controller、256 MB キャッシュ
  • 146 GB 10,000 RPM SAS ディスク 2 台(RAID0 ストライプセットとして構成)
  • SPEC CINT2006 Rate ベンチマークスコアは 110 です。

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

パブリッシュ環境固有の計算

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

キャッシュの効率は、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
注意

免責事項:数値はデフォルトのハードウェア構成に基づいており、使用するハードウェアによって異なる場合があります。

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

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

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

数式

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

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

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

n = (traffic * complexity / 1000 ) * activations

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

トラフィック 予想される 1 秒あたりのピークトラフィック。これは、1 日あたりのページヒット数を 35,000 で割った値と見積もることができます。
applicationComplexity

単純なアプリケーションには 1、複雑なアプリケーションには 2、またはその間の値を使用します。

  • 1 - 完全に匿名のコンテンツ指向のサイト
  • 1.1 - 完全に匿名のコンテンツ指向のサイト。クライアントサイド/ターゲットのパーソナライズゼーションに対応。
  • 1.5 - 匿名セクションとログインセクションの両方で構成される、コンテンツ指向のサイト。クライアントサイド/ターゲットのパーソナライゼーションに対応。
  • 1.7 - 匿名セクションとログインセクションの両方で構成される、コンテンツ指向のサイト。クライアントサイド/ターゲットのパーソナライゼーションに対応。一部でユーザー生成コンテンツを使用。
  • 2 - サイト全体でログインが必要。ユーザー生成コンテンツを幅広く使用。多様なパーソナライゼーション手法を採用。
cacheRatio Dispatcher キャッシュから取得されるページの割合。すべてのページがキャッシュから取得される場合は 1 を使用し、すべてのページがAEMで計算される場合は 0 を使用します。
templateComplexity 1 ~ 10 の値を使用して、テンプレートの複雑さを指定します。 数値が大きいほど、より複雑なテンプレートが示されます。ページあたりのコンポーネントの平均数が 10 のサイトの場合は値 1 を使用し、ページの平均数が 40 のコンポーネントの場合は値 5 を使用し、10 を超えるコンポーネントの平均数を使用します。
有効化 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 アプリケーションの計算に加えて、次の使用例に対して特定の要因を考慮する必要が生じる場合があります。 計算された値がデフォルトの計算に追加されます。

アセット固有の考慮事項

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

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

メモ

イメージのスループットが高いと、コンピューティングリソースがシステム I/O に遅れを取らず、またその逆に遅れを取らなくてはならなくなります。 例えば、画像のインポートによってワークフローが開始された場合、WebDAV を介して多数の画像をアップロードすると、ワークフローのバックログが発生する可能性があります。

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

メモ

マルチサイトマネージャ

オーサリング環境でAEM MSM を使用する場合のリソース消費は、特定の使用例に大きく依存します。 基本的な要因は次のとおりです。

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

計画済みの使用例を代表的なコンテンツの抜粋と共にテストすると、リソース消費に関する理解を深めるのに役立ちます。 スループット計画から結果を推定することで、AEM MSM で別途必要になるリソースを評価できます。

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

AEM Communitiesのサイズ設定に関する考慮事項

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

コミュニティサイトのサイズ設定に関する考慮事項は、コミュニティメンバーが予想するやり取りと、ページコンテンツの最適なパフォーマンスがより重要かどうかによって異なります。

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

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

参照先

このページ