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

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

ディスク disk

データストア datastore

Assets の実装に必要なディスク領域をサイジングするときによくある間違いは、システムに取り込まれる 生画像のサイズに基づいて計算することです。 デフォルトでは、Experience Manager は Experience Manager UI 要素のレンダリングに使用するために、元の画像に加えて 3 つのレンディションを作成します。 以前の実装では、これらのレンディションは取り込まれるアセットのサイズの倍と想定していました。

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

最後に、Experience Manager のバージョン管理機能により、アセットの複製がバージョン履歴に保存されます。 バージョンの消去を頻繁におこなうように設定できます。 ただし、多くのユーザーはバージョンをシステムに長い間保持するので、ストレージ領域をさらに消費します。

これらの要素を考慮して、ユーザーのアセットを保存するための正確なストレージ領域を計算する手法が必要です。

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

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

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

ファイルを入手

共有データストア shared-datastores

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

使用例 use-cases

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

デメリット drawbacks

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

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

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

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

複雑さの増加 increased-complexity

共有データストアは、ガベージコレクションなどの運用を複雑にします。 通常、スタンドアロンのデータストアのガベージコレクションは、ワンクリックで開始できます。 しかし、共有データストアの場合は、単一のノードで実際のコレクションを実行することに加えて、そのデータストアを使用する各メンバーでマークアンドスイープ操作が必要になります。

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

パフォーマンス上の懸念 performance-concerns

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

待ち時間 latency

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

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

次の要素によってリソースが消費されるので、ノードストアやドキュメントストアの正確なサイジングを特定するのは困難です。

バイナリはデータストアに保存されるので、各バイナリが容量を一部占有します。 大部分のリポジトリのサイズは 100 GB を下回ります。 ただし、最大で 1 TB のサイズの大きなリポジトリが存在することもあります。 また、オフライン圧縮を実行するには、圧縮済みのリポジトリを圧縮前のバージョンと共に書き直すための十分な空き容量がボリュームに必要です。 経験則としては、ディスクのサイズをリポジトリの予想サイズの 1.5 倍にすることです。

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

ファイルを入手

ネットワーク network

Assets には、他の多くの Experience Manager プロジェクトよりもネットワークのパフォーマンスが重要になる使用例が複数あります。 お客様のサーバーが高速になっていても、システムに対してアセットをアップロードおよびダウンロードする際のユーザーの負荷に対応した十分な大きさのネットワーク接続が備わっていなければ、低速のままに見えます。 Experience Manager へのユーザーのネットワーク接続の渋滞地点を判別するための便利な手法については、Assets のユーザーエクスペリエンス、インスタンスのサイジング、ワークフローの評価およびネットワークトポロジに関する考慮事項を参照してください。

制限事項 limitations

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

メモリ不足（OOM）の問題を起こす要因はファイルのサイズだけではありません。 画像のサイズにも依存します。 Experience Manager を開始する際にヒープサイズを高く指定することで、OOM の問題を回避できます。

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

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

データストア内のファイル数は、ファイルシステムの制限により 21 億に制限されています。 データストアの上限に達するよりもかなり前に、ノード数が多いことにより、リポジトリで問題が発生する可能性があります。

レンディションが正しく生成されない場合は、Camera Raw ライブラリを使用します。 ただし、この場合、画像の最も長い辺を 65000 ピクセル以下にする必要があります。 また、画像は 512 MP（512 x 1024 x 1024 ピクセル）を超えてはいけません。 アセットのサイズは関係ありません。

Experience Manager では、ピクセルサイズなど他の要因が処理に影響を与えるので、デフォルトで特定のヒープでサポートされる TIFF ファイルのサイズを正確に予測することは困難です。 Experience Manager がデフォルトで 250 MB のサイズのファイルを処理できても、そのファイルに比べて非常に多数のピクセルで構成されている場合は、18 MB のサイズのファイルでも処理できないことがあります。

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

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