Assets のオフロードのベストプラクティス assets-offloading-best-practices

Adobe Experience Manager Assets で大きなファイルや実行中のワークフローを処理すると、CPU、メモリおよび I/O リソースを大量に消費する可能性があります。 特に、アセットのサイズ、ワークフロー、ユーザー数、アセットの取り込み頻度は、システム全体のパフォーマンスに影響を与える可能性があります。 リソースを最も多く消費する操作には、アセットの取り込みとレプリケーションワークフローが含まれます。 単一のオーサーインスタンスでこれらのワークフローを集中的に使用すると、オーサリングの効率に悪影響を与える可能性があります。

これらのタスクを専用のワーカーインスタンスにオフロードすると、CPU、メモリ、および IO のオーバーヘッドを削減できます。 一般的に、オフロードの背後にある考え方は、CPU/メモリ/IO リソースを大量に消費するタスクを、専用のワーカーインスタンスに配分することです。 以下の節では、Assets のオフロードの推奨使用例を示します。

Experience Manager Assets オフロード aem-assets-offloading

Experience Manager Assets は、オフロード用のネイティブなアセット固有のワークフロー拡張機能を実装します。 オフロードフレームワークが提供する汎用ワークフロー拡張に基づいて構築されますが、実装に追加のアセット固有の機能が含まれます。 アセットのオフロードの目的は、アップロードしたアセットに対して DAM アセットの更新ワークフローを効率的に実行することです。 アセットのオフロードを使用すると、取り込みワークフローをより詳細に制御できます。

Experience Manager アセットのオフロードコンポーネント aem-assets-offloading-components

次の図は、アセットのオフロードプロセスの主なコンポーネントを示しています。

DAM アセットの更新のオフロードワークフロー dam-update-asset-offloading-workflow

DAM アセットの更新のオフロードワークフローは、ユーザーがアセットをアップロードするプライマリ（オーサー）サーバーで実行されます。 このワークフローは、通常のワークフローランチャーによってトリガーされます。 このオフロードワークフローは、アップロードされたアセットを処理する代わりに、トピックを使用して新しいジョブを作成します com/adobe/granite/workflow/offloading. オフロードワークフローは、ターゲットワークフローの名前（この場合は DAM アセットの更新ワークフロー）と、アセットのパスをジョブのペイロードに追加します。 オフロードジョブを作成した後、プライマリインスタンスのオフロードワークフローは、オフロードジョブが実行されるまで待機します。

ジョブマネージャー job-manager

ジョブマネージャーは、新しいジョブをワーカーインスタンスに配信します。 配布メカニズムを設計する際は、トピックの有効化を考慮に入れることが重要です。 ジョブは、ジョブのトピックが有効になっているインスタンスにのみ割り当てることができます。 トピックを無効にする com/adobe/granite/workflow/offloading プライマリで、ワーカーで有効にして、ジョブがワーカーに割り当てられていることを確認します。

Experience Manager オフロード aem-offloading

オフロードフレームワークは、ワーカーインスタンスに割り当てられたワークフローのオフロードジョブを識別し、レプリケーションを使用して、ペイロード（取り込む画像など）を含むジョブをワーカーに物理的に転送します。

ジョブコンシューマーをオフロードするワークフロー workflow-offloading-job-consumer

ジョブがワーカーに書き込まれると、ジョブマネージャーは、 com/adobe/granite/workflow/offloading トピック。 次に、ジョブコンシューマーがアセットに対して DAM アセットの更新ワークフローを実行します。

Sling トポロジ sling-topology

Sling トポロジグループ Experience Manager インスタンスを作成し、基礎となる永続性とは関係なく、相互に認識できるようにします。 Sling トポロジのこの特性により、非クラスター化、クラスター化、混在シナリオ用のトポロジを作成できます。 インスタンスは、トポロジ全体にプロパティを公開できます。 フレームワークには、トポロジの変更（インスタンスとプロパティ）をリッスンするためのコールバックが用意されています。 Sling トポロジは、Sling 分散ジョブの基盤を提供します。

Sling 分散ジョブ sling-distributed-jobs

Sling の分散ジョブを使用すると、トポロジのメンバーである一連のインスタンス間でジョブを容易に分散できます。 Sling ジョブは、機能の概念に基づいています。 ジョブは、ジョブトピックによって定義されます。 ジョブを実行するには、インスタンスが特定のジョブトピックのジョブコンシューマーを提供する必要があります。 ジョブトピックは、配信メカニズムの主要なドライバです。

ジョブは、トピックのジョブコンシューマーを提供するインスタンスにのみ配布されます。 インスタンスのジョブコンシューマーを有効または無効にすることで、インスタンスの機能を定義し、配布メカニズムに影響を与えることができます。 インスタンスの使用可能なジョブコンシューマーは、トポロジ全体にブロードキャストされます。

このコンテキストでは、「配分」とは、ジョブコンシューマーを提供する特定のインスタンスにジョブを割り当てることを表します。 インスタンスへの割り当ては、リポジトリに保存されます。 つまり、Sling 分散ジョブは、デフォルトで、トポロジ内の任意のインスタンスに割り当てることができます。 ただし、同じリポジトリを共有するインスタンスでのみ、他のジョブを実行できます。 つまり、これらのジョブは、同じクラスターの一部であるインスタンスによってのみ実行できます。 異なるクラスターのインスタンスに割り当てられたジョブは実行されません。

Granite オフロードフレームワーク granite-offloading-framework

Granite オフロードフレームワークは、非クラスターインスタンスに割り当てられたジョブを実行する Sling ジョブ配布を補完します。 配布（インスタンスの割り当て）は実行されません。 ただし、非クラスターインスタンスに配布された Sling ジョブを識別し、実行のためにターゲットインスタンスに転送します。 現在、オフロードでは、レプリケーションを使用してこのジョブの転送を実行しています。 ジョブを実行するには、オフロードで入力と出力を定義します。オフロードは、ジョブと組み合わせて、ジョブペイロードを作成します。

Sling 分散ジョブは、ジョブと配布フレームワークを提供します。 Granite のオフロードは、ジョブが非クラスターインスタンスに配布される特殊なケースのトランスポートのみを処理します。

トランスポートに加えて、オフロードフレームワークはワークフローエンジンの拡張機能を提供します。 これにより、フレームワークは、ワークフローの一部として分散ジョブを作成し、ワークフローが進む前にジョブの完了を待つことができます。 これは、ワークフローエンジンのワークフロー外部ステップ API を使用して実装されます。 拡張機能の 1 つは、ワークフローの一般的な配布を容易にします。 単一のワークフローステップの配布はサポートされていません。

オフロードフレームワークには、トポロジ全体でのジョブトピックのイネーブルメントを視覚化および制御するユーザーインターフェイス (UI) も付属しています。 UI を使用すると、Sling の分散ジョブのトピックの有効化を便利に設定できます。 UI を使用せずにオフロードを設定することもできます。

アセットのオフロードに関する一般的なガイダンスとベストプラクティス general-guidance-and-best-practices-for-asset-offloading

すべての実装は一意であり、そのため、1 サイズにすべて適合するオフロード設定はありません。 以下の節では、アセットの取り込みのオフロードに関するガイダンスとベストプラクティスを示します。

アセットのオフロードでは、操作のオーバーヘッドを含め、システムにオーバーヘッドも課せられます。 アセットの取り込みの読み込みで問題が発生した場合、Adobeでは、まずオフロードをおこなわずに設定を改善することをお勧めします。 アセットのオフロードに移行する前に、次のオプションを検討してください。

Assets のオフロードが適切なアプローチであると結論付けた場合、Adobeは次のガイダンスを提供します。

推奨アセットのオフロードのデプロイメント recommended-assets-offloading-deployment

を使用 Experience Manager と Oak では、いくつかのデプロイメントシナリオが考えられます。 Assets のオフロードの場合は、共有データストアを使用した TarMK ベースのデプロイメントをお勧めします。 次の図に、推奨されるデプロイメントの概要を示します。

データストアの設定について詳しくは、 AEMでのノードストアとデータストアの設定.

自動エージェント管理をオフにする turning-off-automatic-agent-management

Adobeでは、自動エージェント管理をオフにすることをお勧めします。これは、バイナリレスレプリケーションをサポートしておらず、新しいオフロードトポロジを設定する際に混乱を招く可能性があるからです。 また、バイナリレスレプリケーションで必要なフォワードレプリケーションフローも自動的にはサポートされません。

フォワードレプリケーションの使用 using-forward-replication

デフォルトでは、オフロードトランスポートはリバースレプリケーションを使用して、オフロードされたアセットをワーカーからプライマリにプルバックします。 リバースレプリケーションエージェントは、バイナリレスレプリケーションをサポートしていません。 オフロードされたアセットをワーカーからプライマリにプッシュするためにフォワードレプリケーションを使用するようにオフロードを設定する必要があります。

オーサーとワーカー間での共有データストアとバイナリレスレプリケーションの使用 using-shared-datastore-and-binary-less-replication-between-author-and-workers

アセットのオフロードでの転送オーバーヘッドを削減するには、バイナリレスレプリケーションの使用をお勧めします。 共有データストアにバイナリレスレプリケーションを設定する方法については、 AEMでのノードストアとデータストアの設定. Assets のオフロードの手順は、他のレプリケーションエージェントを伴う点を除いて異なりません。 バイナリレスレプリケーションはフォワードレプリケーションエージェントでのみ機能するので、すべてのオフロードエージェントでフォワードレプリケーションを使用する必要があります。

トランスポートパッケージのオフ turning-off-transport-packages

デフォルトでは、オフロードは、オフロードジョブとジョブペイロード（元のアセット）を含むコンテンツパッケージを作成し、単一のレプリケーションリクエストを使用してこの単一のオフロードパッケージをトランスポートします。 バイナリレスレプリケーションを使用する場合は、パッケージを作成する際にバイナリが再びパッケージ内にシリアル化されるので、これらのオフロードパッケージを作成すると非生産的になります。 これらのトランスポートパッケージの使用をオフにすると、オフロードジョブとペイロードが、ペイロードエントリごとに 1 つずつ、複数のレプリケーションリクエストでトランスポートされます。 これにより、バイナリレスレプリケーションのメリットを活用できます。

ワークフローモデルのトランスポートの無効化 disabling-the-transport-of-workflow-model

デフォルトでは、 DAM アセットの更新のオフロード オフロードワークフローは、ワーカーで呼び出すワークフローモデルをジョブペイロードに追加します。 このワークフローは標準搭載のに従うので DAM アセットの更新 モデルのデフォルトでは、この追加のペイロードは削除できます。

ワークフローモデルがジョブペイロードで無効になっている場合は、パッケージマネージャーなどの他のツールを使用して、参照されているワークフローモデルに変更を配布します。

ワークフローモデルのトランスポートを無効にするには、「 DAM アセットの更新のオフロード」ワークフローを変更します。

ポーリング間隔の最適化 optimizing-the-polling-interval

ワークフローのオフロードは、プライマリの外部ワークフローを使用して実装されます。このワークフローは、ワーカーのオフロードされたワークフローの完了をポーリングします。 外部ワークフロープロセスのデフォルトのポーリング間隔は 5 秒です。 Adobeでは、 Assets のオフロード手順のポーリング間隔を少なくとも 15 秒に増やして、プライマリのオフロードのオーバーヘッドを減らすことをお勧めします。

追加のリソース more-resources

このドキュメントでは、アセットのオフロードに焦点を当てています。 オフロードに関する追加のドキュメントを次に示します。