Show Menu
トピック×

Assets sizing guide

Adobe Experience Manager Assets実装の環境サイズを決定する際は、ディスク、CPU、メモリ、IO、およびネットワークのスループットに関して十分なリソースを確保することが重要です。 これらのリソースのサイジングには、システムに読み込まれたアセットの数を理解しておく必要があります。わかりやすい指標がない場合は、ライブラリの有効期間から既存のライブラリのサイズを分割し、アセットが作成されたときの割合を見つけることができます。

ディスク

データストア

Assets の実装に必要なディスク領域をサイジングするときによくある間違いは、システムに取り込まれる Raw 画像のサイズに基づいて計算することです。デフォルトでは、Experience Managerは、Experience Manager UI要素のレンダリングに使用する元の画像に加えて3つのレンディションを作成します。 以前の実装では、これらのレンディションは取り込まれるアセットのサイズの倍と想定されていました。
ほとんどのユーザーは、既製のレンディションに加えてカスタムレンディションを定義します。In addition to the renditions, Assets lets you extract sub-assets from common file types, such as Adobe InDesign and Adobe Illustrator.
最後に、Experience Managerのバージョン管理機能では、バージョン履歴にアセットの重複が保存されます。 頻繁に削除するバージョンを構成できます。 ただし、多くのユーザーはバージョンをシステムに長い間保持するので、ストレージ領域をさらに消費します。
これらの要素を考慮して、ユーザーのアセットを保存するための正確なストレージ領域を計算する手法が必要です。
  1. システムに読み込まれるアセットのサイズと数を決定します。
  2. Experience Managerにアップロードするアセットの代表的なサンプルを参照できます。 例えば、システムに PSD、JPG、AI および PDF ファイルを読み込む場合、各ファイル形式の複数のサンプル画像が必要です。また、これらのサンプルは異なるファイルサイズや画像が混在する中で代表的なものである必要があります。
  3. 使用するレンディションを定義します。
  4. ImageMagickまたはアドビのCreative Cloudアプリケーションを使用して、Experience Managerでレンディションを作成します。 ユーザーが指定したレンディションに加えて、既製のレンディションを作成します。Scene7を実装しているユーザーは、ICバイナリを使用してPTIFFレンディションを生成し、Experience Managerに保存することができます。
  5. サブアセットを使用する場合は、適切なファイルタイプに合わせて生成します。
  6. 出力された画像、レンディションおよびサブアセットのサイズを元の画像と比較します。これにより、システムが読み込まれたときに、期待される成長率を生成できます。 例えば、1 GB のアセットを処理した後に合計サイズが 3 GB のレンディションとサブアセットを生成した場合、レンディションの拡張係数は 3 です。
  7. アセットのバージョンがシステムで管理される最大時間を決定します。
  8. 既存のアセットがシステムで変更される頻度を決定します。Experience Managerをクリエイティブワークフローのコラボレーションのハブとして使用する場合は、変更の量が多くなります。 完了したアセットのみがシステムにアップロードされる場合、この数はかなり少なくなります。
  9. 毎月システムに読み込まれるアセットの数を決定します。正しい数字がわからない場合は、現在使用できるアセットの数を確認し、その数を最も古いアセットの年齢で除算して、おおよその数を計算します。
上記の手順を実行すると、次の項目を決定できます。
  • 読み込まれるアセットの Raw サイズ.
  • 読み込まれるアセットの数.
  • レンディションの拡張係数.
  • 月ごとのアセットの変更回数.
  • アセットのバージョンを管理する月数.
  • 月ごとに読み込まれる新しいアセットの数.
  • ストレージ領域の割り当ての増加年数。
これらの数を「ネットワークサイジング」スプレッドシートに指定してデータストアに必要な空き容量の合計を決定できます。また、アセットのバージョンの管理やアセットの変更がディスクの増加に与える影響を判断するのに役立つツールです。
ツールに取り込まれているサンプルデータは、前述のステップを実行することの重要性を示しています。データストアのサイズを読み込まれる Raw 画像のみを基準に設定(1 TB)すると、係数が 15 になり、リポジトリサイズが少なく見積もられることがあります。

Shared datastores

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

ユースケース

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

ドローバック

データストアの共有が常に推奨されるとは限りません。いくつかの落とし穴が存在します。

Single point of failure

共有データストアは、インフラストラクチャに単一障害点をもたらすことがあります。次のシナリオを検討してみましょう。システムにオーサーインスタンスが 1 つ、パブリッシュインスタンスが 2 つあり、それぞれ独自のデータストアがあるとします。いずれか 1 つがクラッシュしても、残りの 2 つは引き続き稼動します。ただし、データストアが共有されている場合、1 つのディスクに障害が発生すると、インフラストラクチャ全体がダウンします。このため、データストアを簡単に復元できる場所に共有データストアのバックアップが必要です。
共有データストアには AWS S3 サービスをデプロイすることをお勧めします。これにより、通常のディスクアーキテクチャと比較して、障害が発生する確率を大幅に減らします。

Increased complexity

共有データストアは、ガベージコレクションなどの操作を複雑にします。通常、スタンドアロンのデータストアのガベージコレクションは、1 つのクリックで開始できます。しかし、共有データストアの場合は、単一のノードで実際のコレクションを実行することに加えて、そのデータストアを使用する各メンバーでマークスイープ操作が必要になります。
AWSの運用では、EBSボリュームのRAIDアレイを構築する代わりに(Amazon S3を介して)1か所の中央サイトを実装することで、システムの複雑さと運用上のリスクを大幅に軽減できます。

Performance concerns

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

待ち時間

S3 の実装では、バックグラウンドの書き込みスレッドにより待ち時間が発生します。バックアップ手順では、この遅延を考慮する必要があります。 また、バックアップを作成するときに Lucene のインデックスが未完成のままになることがあります。これには、S3 データストアに書き込まれ、別のインスタンスからアクセスされる、時間に左右されるすべてのファイルが該当します。

Node store or document store

次の要素によってリソースが消費されるので、ノードストアやドキュメントストアの正確なサイジングを特定するのは困難です。
  • アセットのメタデータ
  • アセットのバージョン
  • 監査ログ
  • アーカイブされたワークフローとアクティブなワークフロー
バイナリはデータストアに保存されるので、各バイナリが空き容量を一部占有します。大部分のリポジトリのサイズは 100 GB を下回ります。ただし、1 TBまで大きなリポジトリが存在する場合もあります。 また、オフラインコンパクションを実行するには、コンパクション済みのリポジトリをコンパクション前のバージョンの横に書き直すための十分な空き容量がボリュームに必要です。経験則としては、ディスクのサイズをリポジトリの予想サイズの 1.5 倍にすることです。
リポジトリには、IOPSレベルが3000を超えるSSDまたはディスクを使用します。 IOPS がパフォーマンスのボトルネックとなる可能性を排除するために、CPU の入出力待機レベルを監視して問題の兆候を早めに把握するようにしてください。

ネットワーク

アセットには、多くのExperience Managerプロジェクトよりもネットワークのパフォーマンスを重要にする多くの使用例があります。 お客様は高速なサーバーを使用できますが、ネットワーク接続の大きさが、システムからアセットをアップロードおよびダウンロードするユーザの負荷をサポートするのに十分でない場合、動作は遅くなります。 There is a good methodology for determining the choke point in a user's network connection to Experience Manager at Assets considerations for user experience, instance sizing, workflow evaluation, and network topology .

制限事項

実装をサイジングするときは、システムの制限事項を頭に入れておくことが重要です。提案された実装がこれらの制限を超える場合は、クリエイティブの戦略(例:アセットを複数の Assets の実装全体で分割する)を採用してください。
メモリ不足(OOM)の問題を起こす要因はファイルのサイズだけではありません。画像のサイズにも依存します。開始のExperience Managerでより高いヒープサイズを指定すると、OOMの問題を回避できます。
In addition, you can edit the threshold size property of the com.day.cq.dam.commons.handler.StandardImageHandler component in Configuration Manager to use intermediate temporary file greater than zero.

アセットの最大数

データストア内のファイル数は、ファイルシステムの制限により 21 億に制限されています。おそらくリポジトリについては、データストアの制限に到達するかなり前に、ノードが多すぎることによる問題に直面します。
レンディションが誤って生成される場合は、Camera Raw ライブラリを使用します。ただしこの場合、画像の長いほうのサイズが 65000 ピクセルを超えてはいけません。また、画像に含めるメモリのサイズは512 MP(512 x 1024 x 1024ピクセル)以下にする必要があります。 アセットのサイズは問題になりません。
ピクセルサイズの影響処理など、追加の要因による影響を受けるので、Experience Manager用の特定のヒープを使用して、すぐに使用できるTIFFファイルのサイズを正確に見積もるのは困難です。 Experience Managerでは、初期設定の状態で255 MBのファイルを処理できますが、18 MBのファイルサイズは処理できません。これは、18 MBのファイルサイズが1つのファイルに比べてピクセル数が非常に多いためです。

Size of assets

デフォルトでは、Experience Managerでは、最大2 GBのファイルサイズのアセットをアップロードできます。 非常に大きいアセットをExperience Managerにアップロードするには、非常に大きいアセットをアップロードする ための設定を参照してください