Assets サイジングガイド assets-sizing-guide

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

ディスク disk

データストア datastore

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

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

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

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

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

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

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

ファイルを入手

共有データストア shared-datastores

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

ユースケース use-cases

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

欠点 drawbacks

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

単一障害点 single-point-of-failure

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

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

複雑さの増加 increased-complexity

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

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

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

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

遅延 latency

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

ノードストア/ドキュメントストア node-store-document-store

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

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

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

ファイルを入手

ネットワーク network

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

WebDAV webdav

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

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

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

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

制限事項 limitations

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

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

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

アセットの最大数 maximum-number-of-assets

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

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

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

アセットのサイズ size-of-assets

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