現在表示中:

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

ディスク

データストア

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

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

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

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

  1. システムに読み込まれるアセットのサイズと数を決定します。

  2. AEM にアップロードされるアセットの代表的なサンプルを取得します。例えば、システムに PSD、JPG、AI および PDF ファイルを読み込む場合、各ファイル形式の複数のサンプル画像が必要です。また、これらのサンプルは異なるファイルサイズや画像が混在する中で代表的なものである必要があります。

  3. 使用するレンディションを定義します。

  4. ImageMagick やアドビの Creative Cloud アプリケーションを使用して AEM にレンディションを作成します。ユーザーが指定したレンディションに加えて、既製のレンディションを作成します。Scene7 を実装するユーザーの場合は、IC バイナリを使用して AEM に保存される PTIFF のレンディションを生成できます。

  5. サブアセットを使用する場合は、適切なファイルタイプに合わせて生成します。InDesign のファイルからサブアセットのページを生成する、または Illustrator のレイヤーから PNG ファイルや PDF ファイルを生成する方法については、オンラインドキュメントを参照してください。

  6. 出力された画像、レンディションおよびサブアセットのサイズを元の画像と比較します。 これにより、システムが読み込まれるときに期待される拡張係数を生成できます。例えば、1 GB のアセットを処理した後に合計サイズが 3 GB のレンディションとサブアセットを生成した場合、レンディションの拡張係数は 3 です。

  7. アセットのバージョンがシステムで管理される最大時間を決定します。

  8. 既存のアセットがシステムで変更される頻度を決定します。クリエイティブのワークフローで AEM がコラボレーションハブとして使用されている場合、変更される数は多くなります。完了したアセットのみがシステムにアップロードされる場合、この数はかなり少なくなります。

  9. 毎月システムに読み込まれるアセットの数を決定します。正しい数字がわからない場合は、現在使用できるアセットの数を確認し、その数を最も古いアセットの年齢で除算して、おおよその数を計算します。

ステップ 1 から 9 を実行することで、次の数を決定できます。

  • 読み込まれるアセットの Raw サイズ
  • 読み込まれるアセットの数
  • レンディションの拡張係数
  • 月ごとのアセットの変更回数
  • アセットのバージョンを管理する月数
  • 月ごとに読み込まれる新しいアセットの数
  • 空き容量を割り当てる対象の成長年数

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

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

ダウンロード

共有データストア

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

ユースケース

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

ドローバック

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

単一障害点

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

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

複雑さの増加

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

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

パフォーマンス上の懸念

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

待ち時間

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

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

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

  • アセットのメタデータ
  • アセットのバージョン
  • 監査ログ
  • アーカイブされたワークフローとアクティブなワークフロー

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

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

ダウンロード

ネットワーク

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

WebDAV

AEM Desktop App をミックスに追加した場合、非効率な WebDAV プロトコルにより、ネットワークの問題はより深刻になります。

この非効率性を説明するために、アドビは OS X 上で WebDAV を使用してシステムのパフォーマンスをテストしました。3.5 MB の InDesign ファイルが開かれて編集され、変更が保存されました。 監視結果は次の通りです。

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

WebDAV を介したファイルの平均保存時間を分析したところ、帯域幅が 5 ~ 10 Mbps のレベルにまで上昇するに連れて、パフォーマンスが劇的に上昇することがわかりました。このため、システムに同時にアクセスする各ユーザーのアップロード速度は 10 Mbps 以上、帯域幅は 5 ~ 10 Mbps 以上にすることをお勧めします。

詳しくは、AEM Desktop App のトラブルシューティングを参照してください。

制限事項

実装をサイジングするときは、システムの制限事項を頭に入れておくことが重要です。提案された実装がこれらの制限を超える場合は、クリエイティブの戦略(例:アセットを複数の Assets の実装全体で分割する)を採用してください。

アセットの最大数

アドビは現在まで、120 万以上のアセットをシステムに読み込むテストを実施していません。Oak リポジトリ内のドキュメント数とデータストア内のファイル数には制限が設けられています。

リポジトリ内のノード数の制限は決められていませんが、各アセットは約 150 ページを生成するので、アセットだけでも 120 万のアセットが 1 億 9200 万のドキュメントでテストされます。これには監査ログ、アーカイブ済みのワークフローまたはバージョンは含まれません。

データストア内のファイル数は、ファイルシステムの制限により 21 億に制限されています。おそらくリポジトリについては、データストアの制限に到達するかなり前に、ノードが多すぎることによる問題に直面します。

アセットのサイズ

AEM では現在、一度に 2 GB のアセットをアップロードできます。アップロードするファイルの最大サイズを設定する方法について詳しくは、https://docs.adobe.com/docs/ja/aem/6-2/author/assets/managing-assets-touch-ui.html を参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー