Assets サイジングガイド

最終更新日: 2023-05-04
  • 作成対象:
  • Developer
    Admin
注意

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

Adobe Experience Manager Assets 実装の環境をサイズ設定する場合は、ディスク、CPU、メモリ、IO、ネットワークスループットなどのリソースに十分な空きがあることを確認することが重要です。 これらのリソースのサイズ設定の多くは、システムに読み込まれるアセットの数を理解しておく必要があります。 より良い指標が使用できない場合は、既存のライブラリのサイズをライブラリの年齢で割って、アセットの作成率を見つけることができます。

ディスク

データストア

Assets 実装に必要なディスク領域のサイズを変更する際によく発生する誤りは、システムに取り込む生の画像のサイズに基づいて計算をおこなうことです。 デフォルトでは、 Experience Manager は、元の画像に加えて 3 つのレンディションを作成し、 Experience Manager UI 要素 以前の実装では、これらのレンディションは、取り込まれるアセットの 2 倍のサイズを想定していました。

ほとんどのユーザーは、標準のレンディションに加えて、カスタムレンディションも定義します。 レンディションに加えて、Assets では、InDesignやIllustratorなどの共通のファイルタイプからサブアセットを抽出できます。

最後に、AEMのバージョン管理機能では、アセットの重複がバージョン履歴に保存されます。 バージョンの消去を頻繁におこなうように設定できます。ただし、多くのユーザーは、長時間システム内にバージョンを保持することを選択し、その結果、追加のストレージ領域を消費します。

これらの要因を考慮すると、ユーザーアセットを保存するために、適切に正確なストレージスペースを計算する方法が必要になります。

  1. システムに読み込まれるアセットのサイズと数を決定します。
  2. AEMにアップロードするアセットの代表的なサンプルを取得します。 例えば、PSD、JPG、AI、PDFの各ファイルをシステムに読み込む予定がある場合、各ファイル形式の複数のサンプルイメージが必要です。 また、これらのサンプルは、様々なファイルサイズや画像の複雑さを表すものにする必要があります。
  3. 使用するレンディションを定義します。
  4. でのレンディションの作成 Experience Manager ImageMagick またはAdobeのCreative Cloudアプリケーション ユーザーが指定したレンディションに加えて、既製のレンディションを作成します。Dynamic Media Classicを実装するユーザーは、IC バイナリを使用してAEMに保存する PTIFF レンディションを生成できます。
  5. サブアセットを使用する場合は、適切なファイルタイプに合わせて生成します。IllustratorレイヤーからInDesignファイルまたは PNG/Asset ファイルからサブPDFページを生成する方法については、オンラインドキュメントを参照してください。
  6. 出力された画像、レンディションおよびサブアセットのサイズを元の画像と比較します。これにより、システムが読み込まれるときに期待される拡張係数を生成できます。例えば、1 GB のアセットを処理した後に合計サイズが 3 GB のレンディションとサブアセットを生成した場合、レンディションの拡張係数は 3 です。
  7. システムでアセットバージョンを維持する最大時間を決定します。
  8. システム内の既存のアセットの変更頻度を指定します。 クリエイティブのワークフローで Experience Manager がコラボレーションハブとして使用されている場合、変更される数は多くなります。完了したアセットのみがシステムにアップロードされる場合、この数ははるかに少なくなります。
  9. 1 ヶ月にシステムに読み込まれるアセットの数を決定します。 不明な場合は、現在使用可能なアセットの数を確認し、その数を最も古いアセットの年齢で割って、おおよその数を計算します。

手順 1 ~ 9 を実行すると、次の項目を判断するのに役立ちます。

  • 読み込むアセットの生のサイズ
  • 読み込むアセットの数
  • レンディションの拡大率
  • 1 か月におこなわれたアセットの変更数
  • アセットのバージョンを管理する月数
  • 毎月読み込まれる新しいアセットの数
  • スペースを割り当てる年数の成長

これらの数を「ネットワークサイジング」スプレッドシートに指定してデータストアに必要な空き容量の合計を決定できます。また、アセットのバージョンを管理することや、ディスクの拡張時に Experience Manager でアセットを変更したときの影響を判断するのにも便利なツールです。

ツールに取り込まれているサンプルデータは、前述の手順を実行することの重要性を示しています。データストアのサイズを読み込まれる 生の画像のみを基準に設定(1 TB)すると、係数が 15 になり、リポジトリサイズが少なく見積もられることがあります。

ファイルを入手

共有データストア

サイズの大きなデータストアでは、ネットワークに接続されたドライブの共有ファイルデータストアまたは S3 データストアを介して、共有データストアを実装できます。この場合、個々のインスタンスでバイナリのコピーを管理する必要がありません。また、共有データストアは、バイナリレスレプリケーションを容易にし、アセットをパブリッシュ環境やオフロードインスタンスにレプリケートする際に使用する帯域幅を削減します。

ユースケース

データストアはプライマリとスタンバイのオーサーインスタンス間で共有し、プライマリインスタンスで加えられた変更をスタンバイインスタンスで更新するのにかかる時間を最小化できます。Adobeは、ワークフローのオフロードでのオーバーヘッドを減らすために、プライマリオーサーインスタンスとオフロードオーサーインスタンスの間でデータストアを共有することをお勧めします。 また、オーサーインスタンスとパブリッシュインスタンスの間でデータストアを共有して、レプリケーション中のトラフィックを最小限に抑えることもできます。

欠点

一部の落とし穴があるので、データストアの共有は、どの場合でも推奨されません。

単一障害点

共有データストアを使用すると、インフラストラクチャに単一の障害点が発生します。 システムに 1 つのオーサーインスタンスと 2 つのパブリッシュインスタンスがあり、それぞれが独自のデータストアを持つシナリオを考えてみましょう。 いずれか 1 つがクラッシュした場合でも、残りの 2 つは引き続き実行を続行できます。 ただし、データストアを共有すると、1 台のディスク障害によってインフラストラクチャ全体が停止する場合があります。 したがって、共有データストアのバックアップを維持し、そこからデータストアを迅速に復元できるようにしてください。

共有データストアにAWS S3 サービスをデプロイすることをお勧めします。これは、通常のディスクアーキテクチャと比べて、障害の確率が大幅に低下するからです。

複雑さの増加

共有データストアを使用すると、ガベージコレクションなどの操作の複雑さも増します。 通常、スタンドアロンデータストアのガベージコレクションは、1 回のクリックで開始できます。 ただし、共有データストアでは、1 つのノードで実際のコレクションを実行するだけでなく、データストアを使用する各メンバに対してマークスイープ操作が必要です。

AWS の操作では、EBS ボリュームの RAID アレイを構築するのではなく、( S3 を介して)1 つの中央ロケーションを実装することで、複雑さやシステム上の操作リスクが大幅に軽減されます。

パフォーマンスに関する問題

共有データストアでは、すべてのインスタンス間で共有されるネットワークにマウントされたドライブにバイナリを保存する必要があります。これらのバイナリはネットワークを通じてアクセスするので、システムのパフォーマンスに悪い影響を及ぼします。ネットワーク接続やディスクアレイを高速化することで、その影響を一部軽減できます。しかし、これにはコストがかかります。AWS の場合、すべてのディスクはリモートであり、ネットワーク接続を必要とします。エフェメラルボリュームは、インスタンスが開始または停止するとデータを失います。

遅延

S3 実装の遅延は、バックグラウンドの書き込みスレッドによって導入されます。 バックアップ手順では、この遅延とオフロード手順を考慮する必要があります。 オフロードジョブの開始時に S3 アセットが S3 に存在しない場合があります。 また、バックアップを作成する際に、Lucene インデックスが不完全なままになる場合があります。 これは、S3 データストアに書き込まれ、別のインスタンスからアクセスされる、時間に影響を受けやすいファイルに適用されます。

ノードストア/ドキュメントストア

以下のリソースが消費するので、NodeStore または DocumentStore の正確なサイズの数値を得るのは困難です。

  • アセットメタデータ
  • アセットのバージョン
  • 監査ログ
  • アーカイブ済みおよびアクティブなワークフロー

バイナリはデータストアに保存されるので、各バイナリが一部の領域を占有します。 ほとんどのリポジトリのサイズは 100GB を下回っています。 ただし、1 TB まで大きなリポジトリが存在する場合があります。 また、オフライン圧縮を実行するには、圧縮済みリポジトリを事前に圧縮したバージョンと一緒に書き換えるのに十分な空き領域がボリュームに必要です。 ディスクのサイズをリポジトリの 1.5 倍にするのがよい経験則です。

リポジトリには、IOPS レベルが 3000 以上の SSD またはディスクを使用します。IOPS がパフォーマンスのボトルネックとなる可能性を排除するために、CPU の入出力待機レベルを監視して問題の兆候を把握してください。

ファイルを入手

ネットワーク

Assets には、他の多くの Experience Manager プロジェクトよりもネットワークのパフォーマンスが重要になる使用例が数多くあります。お客様のサーバーが高速になっていても、システムに対してアセットをアップロードおよびダウンロードする際のユーザーの負荷に対応した十分な大きさのネットワーク接続が備わっていなければ、低速のままに見えます。~へのユーザのネットワーク接続のチョークポイントを決定する良い方法がある Experience Manager 時刻 Experience Manager ユーザーエクスペリエンス、インスタンスのサイズ設定、ワークフローの評価およびネットワークトポロジに関するアセットの考慮事項.

WebDAV

次に Experience Manager WebDAV プロトコルの非効率性により、デスクトップアプリケーションを混在させると、ネットワークの問題がより深刻になります。

非効率性を説明するため、Adobeは OS X で WebDAV を使用してシステムのパフォーマンスをテストしました。3.5MB のInDesignファイルが開かれ、編集され、変更が保存されました。 以下の観察を行った。

  • 操作を完了するために、合計で約 100 個の HTTP リクエストが生成されました
  • ファイルは HTTP 経由で 4 回アップロードされました
  • ファイルは HTTP 経由で 1 回ダウンロードされました
  • 操作全体が完了するまでに 42 秒かかりました
  • 合計 18 MB のデータが転送されました

WebDAV 経由でファイルの平均保存時間を分析する際に、帯域幅が 5~10Mbps のレベルまで増加するにつれて、パフォーマンスが大幅に向上することがわかりました。 したがって、Adobeは、システムに同時にアクセスする各ユーザーに、少なくとも 10 Mbps のアップロード速度と 5~10 Mbps の帯域幅を持たせることをお勧めします。

詳しくは、 トラブルシューティング Experience Manager デスクトップアプリ.

制限事項

実装をサイジングする際は、システムの制限を念頭に置くことが重要です。 提案された実装がこれらの制限を超える場合は、クリエイティブ戦略(複数の Assets 実装間でアセットを分割するなど)を採用します。

メモリ不足 (OOM) の問題を引き起こす要因は、ファイルサイズだけではありません。 また、画像のサイズにも依存します。 AEMの起動時にヒープサイズを大きくすることで、OOM の問題を回避できます。

さらに、Configuration Manager で com.day.cq.dam.commons.handler.StandardImageHandler コンポーネントのしきいサイズプロパティを編集し、0 より大きい中間一時ファイルを使用することもできます。

アセットの最大数

データストアに存在できるファイルの数は、ファイルシステムの制限により、21 億個に制限される場合があります。 データストアの上限に達するまでのノード数が多いため、リポジトリで問題が発生する可能性があります。

レンディションが正しく生成されない場合は、Camera Rawのライブラリを使用します。 ただし、この場合、画像の最も長い辺は65000ピクセル以下にする必要があります。 また、画像に 512 MP (512 *) を超える値を含めることはできません1024 *1024 ピクセル )'です。 アセットのサイズは取るに足らない.

標準搭載の (OOTB) でサポートされているTIFFファイルのサイズを、 Experience Manager ピクセルサイズなどの追加の要因が処理に影響を与えるためです。 可能性がある Experience Manager では 255 MB OOTB のファイルを処理できますが、18 MB のファイルサイズは処理できません。後者のファイルの構成要素は、前者に比べて異常に多い数のピクセルなのでです。

アセットのサイズ

デフォルトでは、 Experience Manager では、最大 2 GB のファイルサイズのアセットをアップロードできます。 AEMで非常に大きなアセットをアップロードするには、 非常に大きなアセットをアップロードするための設定.

このページ