ジョブのオフロード offloading-jobs
はじめに introduction
オフロードによって、トポロジ内の Experience Manager インスタンス間で処理タスクが配布されます。オフロードでは、特定の Experience Manager インスタンスを使用して、特定のタイプの処理を実行できます。処理を特化することによって、利用可能なサーバーリソースを最大限に使用できます。
オフロードは、Apache Sling Discovery および Sling JobManager の機能に基づきます。オフロードを使用するには、Experience Manager クラスターをトポロジに追加し、クラスターで処理するジョブトピックを特定します。クラスターは 1 つ以上の Experience Manager インスタンスで構成され、単一のインスタンスがクラスターと見なされます。
トポロジへのインスタンスの追加について詳しくは、トポロジの管理を参照してください。
ジョブ配布 job-distribution
Sling JobManager と JobConsumer を使用して、トポロジ内で処理されるジョブを作成できます。
- JobManager:特定のトピックのジョブを作成するサービス。
- JobConsumer:1 つ以上のトピックのジョブを実行するサービス。 同じトピックに対して複数の JobConsumer サービスを登録できます。
JobManager がジョブを作成すると、オフロードフレームワークは、トポロジ内のExperience Managerクラスターを選択してジョブを実行します。
- クラスターには、ジョブトピックに登録された JobConsumer を実行している 1 つ以上のインスタンスを含める必要があります。
- このトピックは、クラスター内の 1 つ以上のインスタンスに対して有効にする必要があります。
ジョブ配布の調整について詳しくは、トピック使用の設定を参照してください。
オフロードフレームワークで、ジョブを実行するクラスターを選択し、クラスターが複数のインスタンスで構成される場合、Sling Distribution は、クラスター内のどのインスタンスでジョブを実行するかを決定します。
ジョブペイロード job-payloads
オフロードフレームワークは、ジョブをリポジトリ内のリソースに関連付けるジョブペイロードをサポートします。 ジョブペイロードは、ジョブがリソースを処理するために作成され、ジョブが別のコンピュータにオフロードされる場合に役立ちます。
ジョブの作成時に、ペイロードはジョブを作成するインスタンス上にのみ配置されることが保証されます。 ジョブのオフロード時に、レプリケーションエージェントは、最終的にジョブを使用するインスタンス上にペイロードが作成されることを確認します。 ジョブの実行が完了すると、リバースレプリケーションによって、ペイロードがジョブを作成したインスタンスにコピーされ直されます。
トポロジの管理 administering-topologies
トポロジは、オフロードに参加している疎結合Experience Managerクラスタです。 クラスタは、1 つ以上のExperience Managerサーバーインスタンスで構成されます(1 つのインスタンスがクラスターと見なされます)。
各Experience Managerインスタンスは、次のオフロード関連サービスを実行します。
- Discovery Service:トポロジに参加するためのリクエストを Topology Connector に送信します。
- トポロジコネクタ:結合リクエストを受け取り、各リクエストを受け入れるか拒否します。
トポロジのすべてのメンバーの Discovery Service は、いずれかのメンバーの Topology Connector を指します。 以降のセクションでは、このメンバーをルートメンバーと呼びます。
トポロジ内の各クラスターには、リーダーとして認識されるインスタンスが含まれています。 クラスターリーダーは、クラスターの他のメンバーの代わりに、トポロジとやり取りします。 引出線がクラスタから離れると、クラスタの新しい引出線が自動的に選択されます。
トポロジの表示 viewing-the-topology
トポロジブラウザーを使用して、Experience Managerインスタンスが参加しているトポロジの状態を調べます。 トポロジブラウザーには、トポロジのクラスターとインスタンスが表示されます。
各クラスタには、各メンバがクラスタに参加した順序と、どのメンバがリーダーかを示すクラスタメンバの一覧が表示されます。 現在プロパティによって、現在管理しているインスタンスが示されます。
クラスターの各インスタンスについて、複数のトポロジ関連プロパティを確認できます。
- インスタンスのジョブコンシューマーが担当するトピックの許可リスト。
- トポロジとの接続用に公開されるエンドポイント。
- インスタンスがオフロード用に登録されているジョブトピック。
- インスタンスが処理するジョブトピック。
-
タッチ UI を使用して、「ツール」タブをクリックします。 (http://localhost:4502/tools.html)
-
Granite の操作領域で、「ブラウザーのオフロード」をクリックします。
-
ナビゲーションパネルで、[ トポロジブラウザ ] をクリックします。
トポロジに参加しているクラスターが表示されます。
-
クラスターをクリックすると、クラスター内のインスタンスと、その ID、現在のステータス、リーダーのステータスのリストが表示されます。
-
インスタンス ID をクリックすると、詳細なプロパティが表示されます。
また、Web コンソールを使用してトポロジ情報を表示することもできます。 コンソールには、トポロジクラスターに関する詳細情報が表示されます。
- ローカルインスタンスを表すインスタンス。
- このインスタンスがトポロジへの接続に使用する Topology Connector サービス(送信)と、このインスタンスに接続するサービス(受信)です。
- トポロジおよびインスタンスプロパティの履歴を変更します。
次の手順を実行して、Web コンソールのトポロジ管理ページを開きます。
-
ブラウザーで Web コンソールを開きます。 (http://localhost:4502/system/console)
-
[Main] > [Topology Management] の順にクリックします。
トポロジメンバーシップの設定 configuring-topology-membership
Apache Sling Resource-Based Discovery Service は各インスタンスで実行され、Experience Managerインスタンスとトポロジとのやり取りを制御します。
Discovery Service は、トポロジとの接続を確立し、維持するために、定期的なPOST要求(ハートビート)を Topology Connector サービスに送信します。 Topology Connector サービスでは、トポロジへの参加が許可される IP アドレスまたはホスト名の許可リストを維持管理します。
- インスタンスをトポロジに参加させるには、ルートメンバーの Topology Connector サービスの URL を指定します。
- インスタンスがトポロジに参加できるようにするには、インスタンスをルートメンバーの Topology Connector サービスの許可リストに追加します。
Web コンソールまたは sling:OsgiConfig ノードを使用して、 org.apache.sling.discovery.impt.Config サービスの次のプロパティを設定します。
CQ インスタンスをトポロジのルートメンバーに接続するには、次の手順を実行します。 この手順では、インスタンスがルートトポロジメンバーの Topology Connector URL を指し示します。 トポロジのすべてのメンバーで、この手順を実行します。
- ブラウザーで Web コンソールを開きます。 (http://localhost:4502/system/console)
- [Main] > [Topology Management] の順にクリックします。
- [Configure Discovery Service] をクリックします。
- Topology Connector URLs プロパティに項目を追加し、ルートトポロジメンバーの Topology Connector サービスの URL を指定します。 URL の形式は、https://rootservername:4502/libs/sling/topology/connector です。
トポロジのルートメンバーで以下の手順を実行します。この手順では、他のトポロジメンバの名前が Discovery Service許可リストに追加されます。
- ブラウザーで Web コンソールを開きます。 (http://localhost:4502/system/console)
- [Main] > [Topology Management] の順にクリックします。
- [Configure Discovery Service] をクリックします。
- トポロジの各メンバーについて、Topology Connector の許可リストプロパティに項目を追加し、トポロジメンバーのホスト名または IP アドレスを指定します。
トピック消費の設定 configuring-topic-consumption
オフロードブラウザを使用して、トポロジ内のトピックインスタンスのExperience Manager消費を設定します。 各インスタンスについて、使用するトピックを指定できます。 例えば、1 つのインスタンスが特定のタイプのトピックを使用するようにトポロジを設定するには、1 つを除くすべてのインスタンスでトピックを無効にします。
ジョブは、関連するトピックが有効になっているインスタンス間で、ラウンドロビンロジックを使用して分散されます。
-
タッチ UI を使用して、「ツール」タブをクリックします。 (http://localhost:4502/tools.html)
-
Granite の操作領域で、「ブラウザーのオフロード」をクリックします。
-
ナビゲーションパネルで、[ オフロードするブラウザ ] をクリックします。
オフロードするトピックと、そのトピックを使用できるサーバーインスタンスが表示されます。
-
インスタンスのトピックの使用を無効にするには、トピック名の下で、インスタンスの横にある「無効にする」をクリックします。
-
あるインスタンスのすべてのトピック使用を設定するには、トピックの下にあるインスタンス識別子をクリックします。
-
トピックの横にある次のボタンの 1 つをクリックして、インスタンスの消費動作を設定し、「保存」をクリックします。
- 有効:このインスタンスは、このトピックのジョブを使用します。
- 無効:このインスタンスはこのトピックのジョブを使用しません。
- 排他:このインスタンスはこのトピックのみのジョブを使用します。
注意: トピックに対して [ 除外 ] を選択すると、その他のトピックはすべて自動的に [ 無効 ] に設定されます。
インストール済みのジョブコンシューマー installed-job-consumers
複数の JobConsumer 実装が、インストールと共にExperience Managerされます。 これらの JobConsumer が登録されているトピックは、オフロードブラウザに表示されます。 表示される追加のトピックは、カスタム JobConsumer が登録したトピックです。 次の表に、デフォルトの JobConsumer を示します。
インスタンスのトピックの無効化と有効化 disabling-and-enabling-topics-for-an-instance
Apache Sling Job Consumer Manager サービスは、トピックの許可リストとブロックリストのプロパティを提供します。 これらのプロパティを設定して、Experience Managerインスタンスでの特定のトピックの処理を有効または無効にします。
注意: インスタンスがトポロジに属している場合は、トポロジ内の任意のコンピューターでオフロードするブラウザーを使用して、トピックを有効または無効にすることもできます。
有効なブロックリストのリストを作成するロジックは、まず許可リスト内のすべてのトピックを許可し、次にそのトピック上のトピックを削除します。デフォルトでは、すべてのトピックが有効になっています (許可リスト値は *
) や、無効なトピックはありません (ブロックリストに値がありません )。
Web コンソールまたは sling:OsgiConfig
ノードを使用して、以下のプロパティを設定します。sling:OsgiConfig
ノードの場合、JobConsumer Manager サービスの PID は、org.apache.sling.event.impl.jobs.JobConsumerManager です。
オフロード用のレプリケーションエージェントの作成 creating-replication-agents-for-offloading
オフロードフレームワークは、レプリケーションを使用して、オーサーとワーカーの間でリソースを転送します。 オフロードフレームワークは、インスタンスがトポロジに参加すると、レプリケーションエージェントを自動的に作成します。 エージェントはデフォルト値で作成されます。 エージェントが認証に使用するパスワードは手動で変更する必要があります。
オフロード用にインスタンス間でジョブペイロードを転送するレプリケーションエージェントを作成します。 次の図に、オーサーインスタンスからワーカーインスタンスにオフロードするために必要なエージェントを示します。 オーサーの Sling ID は 1、ワーカーインスタンスの Sling ID は 2 です。
この設定には、次の 3 つのエージェントが必要です。
- ワーカーインスタンスにレプリケートする、オーサーインスタンス上の送信エージェントです。
- ワーカーインスタンス上のアウトボックスから取り込む、オーサーインスタンス上のリバースエージェント。
- ワーカーインスタンス上のアウトボックスエージェント。
このレプリケーションスキームは、オーサーインスタンスとパブリッシュインスタンスの間で使用されるスキームと似ています。 ただし、オフロード状況では、関係するすべてのインスタンスがオーサリングインスタンスです。
オフロードのレプリケーションエージェントの命名 naming-the-replication-agents-for-offloading
オフロードフレームワークによって特定のワーカーインスタンスに対して適切なエージェントが自動的に使用されるように、レプリケーションエージェントの「名前」プロパティに特定のフォーマットを使用します。
オーサーインスタンスの送信エージェントの命名:
offloading_<slingid>
、ここで <slingid>
は、ワーカーインスタンスの Sling ID です。
例:offloading_f5c8494a-4220-49b8-b079-360a72f71559
オーサーインスタンスのリバースエージェントの命名:
offloading_reverse_<slingid>
、ここで <slingid>
は、ワーカーインスタンスの Sling ID です。
例:offloading_reverse_f5c8494a-4220-49b8-b079-360a72f71559
ワーカーインスタンスのアウトボックスの命名:
offloading_outbox
送信エージェントの作成 creating-the-outgoing-agent
-
作成者で レプリケーションエージェント を作成します( レプリケーションエージェントのドキュメント) をクリックします。 任意の タイトル を指定します。名前 は命名規則に従う必要があります。
-
以下のプロパティを使用してエージェントを作成します。
table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 プロパティ 値 「設定」>「シリアル化の種類」 デフォルト トランスポート/トランスポート URI https:// <ip of target instance>
:<port>
/bin/receive?sling:authRequestLogin=1
トランスポート/トランスポートユーザー ターゲットインスタンス上のレプリケーションユーザー トランスポート/トランスポートパスワード ターゲットインスタンスのレプリケーションユーザーのパスワード 拡張/HTTP メソッド POST トリガー/デフォルトを無視 True
リバースエージェントの作成 creating-the-reverse-agent
-
作成者に リバースレプリケーションエージェント を作成します。( レプリケーションエージェントのドキュメント.) 任意の タイトル を指定します。名前 は命名規則に従う必要があります。
-
以下のプロパティを使用してエージェントを作成します。
table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 プロパティ 値 「設定」>「シリアル化の種類」 デフォルト トランスポート/トランスポート URI https:// <ip of target instance>
:<port>
/bin/receive?sling:authRequestLogin=1
トランスポート/トランスポートユーザー ターゲットインスタンス上のレプリケーションユーザー トランスポート/トランスポートパスワード ターゲットインスタンスのレプリケーションユーザーのパスワード 拡張/HTTP メソッド GET
アウトボックスエージェントの作成 creating-the-outbox-agent
-
ワーカーインスタンス上に レプリケーションエージェント を作成します。( レプリケーションエージェントのドキュメント.) 任意の タイトル を指定します。名前 は
offloading_outbox
にする必要があります。 -
次のプロパティを使用してエージェントを作成します。
table 0-row-2 1-row-2 2-row-2 3-row-2 プロパティ 値 「設定」>「シリアル化の種類」 デフォルト トランスポート/トランスポート URI repo://var/replication/outbox トリガー/デフォルトを無視 True
Sling ID の検索 finding-the-sling-id
次のいずれかの方法を使用して、Experience Managerインスタンスの Sling ID を取得します。
- Web コンソールを開き、Sling 設定で、Sling ID プロパティの値を検索します(http://localhost:4502/system/console/status-slingsettings)。このメソッドは、インスタンスがまだトポロジに含まれていない場合に役立ちます。
- インスタンスが既にトポロジの一部である場合は、トポロジブラウザーを使用します。
DAM アセットの処理のオフロード offloading-the-processing-of-dam-assets
DAM で追加または更新されたアセットのバックグラウンド処理を特定のインスタンスが実行するように、トポロジのインスタンスを設定します。
デフォルトでは、Experience Managerは、DAM アセットが変更された、または DAM に追加されたときに、DAM アセットの更新ワークフローを実行します。 デフォルトの動作を変更して、Experience Managerが代わりに DAM Update Asset Offloader ワークフローを実行するようにします。 このワークフローは、次のトピックを持つ JobManager ジョブを生成します: com/adobe/granite/workflow/offloading
. 次に、ジョブが専用のワーカーにオフロードされるようにトポロジを設定します。
次の手順では、オフロードトポロジの次の特性を想定しています。
- 1 つ以上のExperience Managerインスタンスが、DAM アセットの追加または更新のためにユーザーがやり取りするオーサリングインスタンスです。
- DAM アセットを処理する 1 つ以上のExperience Managerインスタンスを直接操作しない。 これらのインスタンスは、DAM アセットのバックグラウンド処理専用です。
-
各Experience Managerインスタンスで、ルート Topography Connector を指すように Discovery Service を設定します。 ( トポロジメンバーシップの設定.)
-
接続インスタンスが許可リスト上にあるように、ルート Topography Connector を設定します。
-
オフロードブラウザーを開き、
com/adobe/granite/workflow/offloading
DAM アセットをアップロードまたは変更するためにユーザーがやり取りするインスタンスに関するトピック。 -
ユーザーがやり取りする各インスタンスで、DAM アセットをアップロードまたは変更する際に、 DAM アセットの更新オフロードワークフローを使用するようにワークフローランチャーを設定します。
- ワークフローコンソールを開きます。
- 「ランチャー」タブをクリックします。
- DAM アセットの更新ワークフローを実行する 2 つのランチャー設定を見つけます。 1 つのランチャー設定イベントタイプは「Node Created」で、もう 1 つのタイプは「Node Modified」です。
- 両方のイベントタイプを変更して、DAM アセットの更新のオフロードワークフローを実行します。 ( ランチャーの設定について詳しくは、 ノードが変更されたときのワークフローの開始.)
-
DAM アセットのバックグラウンド処理を実行するインスタンスで、 DAM アセットの更新ワークフローを実行するワークフローランチャーを無効にします。
参考情報 further-reading
このページで説明する詳細に加えて、次の情報もお読みください。
- Java API を使用したジョブおよびジョブコンシューマーの作成について詳しくは、オフロードのためのジョブの作成と使用を参照してください。
- アセットのオフロードに関する一般的なガイドラインおよびベストプラクティスについては、 アセットのオフロードの一般的なガイドラインとベストプラクティス.
- オフロードエージェントの自動作成を無効にする方法については、 自動エージェント管理の無効化.