アセットを一括で移行する方法 assets-migration-guide

アセットを Adobe Experience Manager に移行する際には、いくつかの手順を考慮する必要があります。現在のホームからアセットやメタデータを抽出する方法は、実装環境により方法が大きく異なるのでこのドキュメントでは説明しません。本書では、抽出したアセットを Experience Manager に移行してメタデータを適用し、レンディションを生成してそれらをパブリッシュインスタンスでアクティベートする方法について説明します。

前提条件 prerequisites

この方法に従って実際に手順を実行する前に、Assets パフォーマンスチューニングに関するヒントのガイダンスを確認して実践してください。ここで紹介する手順の多くは、同時に実行可能なジョブの最大数の設定など、負荷時のサーバーの安定性とパフォーマンスを大幅に改善します。システムにアセットが読み込まれた後になると、その他の手順（ファイルデータストアの設定など）を実行するのがより困難になります。

Experience Manager への移行 migrating-to-aem

Experience Manager にアセットを移行するにはいくつかの手順を経る必要があるので、フェーズ別に処理することをお勧めします。移行のフェーズは次の通りです。

ワークフローの無効化 disabling-workflows

移行を開始する前に、DAM アセットの更新ワークフローのランチャーを無効化します。すべてのアセットを取り込んでからワークフローをバッチで実行する方法が最適です。移行が実行されるときに既にライブである場合は、これらのアクティビティを営業時間外に実行するようにスケジュールを設定できます。

タグの読み込み loading-tags

画像に適用するタグ分類は既に用意されていることがあります。CSV Asset Importer などのツールや Experience Manager のメタデータプロファイルのサポートにより、タグをアセットに適用する処理は自動化できますが、タグをシステムに読み込む必要があります。ACS AEM ツールの Tag Maker 機能を使用すると、システムに読み込まれた Microsoft Excel のスプレッドシートを使用してタグを入力できます。

アセットの取り込み ingesting-assets

アセットをシステムに取り込む際に重要なのは、パフォーマンスと安定性です。システムに大量のデータを読み込むので、特に既に実稼動環境にあるシステムでは、システムがパフォーマンスを可能な限り発揮できるようにして処理に必要な時間を短縮する一方で、システムのオーバーロードによりシステムがクラッシュしないように注意する必要があります。

システムにアセットを読み込むには、HTTP を使用したプッシュベースのアプローチと、JCR の API を使用したプルベースのアプローチがあります。

HTTP 経由で送信 pushing-through-http

アドビの Managed Services チームは Glutton というツールを使用して、お客様の環境にデータを読み込みます。Glutton は小さな Java アプリケーションであり、Experience Manager のデプロイメントでディレクトリから別のディレクトリにすべてのアセットを読み込みます。Glutton の代わりに、Perl スクリプトなどのツールを使用してアセットをリポジトリに投稿することもできます。

HTTPS を通じたプッシュのアプローチには、主に次の 2 つの欠点があります。

アセットを取り込むもう一方のアプローチでは、ローカルファイルシステムからアセットを引っ張ってきます。ただし、プルベースのアプローチを実行する外部ドライブやネットワーク共有がサーバーにマウントされていない場合は、HTTP を介したアセットの投稿が最適なオプションです。

ローカルファイルシステムからの取得 pulling-from-the-local-filesystem

ACS AEM ツールの CSV Asset Importer は、アセットをファイルシステムから、アセットメタデータをアセット読み込み用の CSV ファイルから、それぞれ取り込みます。Experience Manager の Asset Manager API を使用して、アセットをシステムに取り込み、設定したメタデータプロパティを適用します。アセットはネットワークファイルマウントまたは外部ドライブを介してサーバーにマウントされているのが理想です。

アセットをネットワーク経由で送信する必要がないので、全体的なパフォーマンスが劇的に向上します。このため、一般的にはこの方法がアセットをリポジトリに読み込む最も効率的な方法と見なされています。さらに、ツールがメタデータの取り込みをサポートし、すべてのアセットとメタデータを 1 つの手順で取り込むことができるので、別のツールを使用してメタデータを適用する 2 つ目の手順が不要になります。

レンディションの処理 processing-renditions

アセットをシステムに読み込んだ後、メタデータを抽出してレンディションを生成するには、DAM アセットの更新ワークフローを通じてアセットを処理する必要があります。この手順を実行する前に、DAM アセットの更新ワークフローをニーズに合わせて複製および変更する必要があります。既製のワークフローには、Dynamic Media PTIFF の生成や InDesign Server の統合など、ユーザーによっては必要でない手順が多く含まれています。

ニーズに合わせてワークフローを設定したら、次の 2 つの方法のいずれかで実行できます。

アセットのアクティベート activating-assets

パブリッシュ層のあるデプロイメントでは、アセットをパブリッシュファームにアクティベートする必要があります。アドビは 1 つ以上のパブリッシュインスタンスを実行することを推奨していますが、すべてのアセットを 1 つのパブリッシュインスタンスにレプリケートして、そのインスタンスをクローンする方法が最も効率的です。多数のアセットをアクティベートするときは、ツリーのアクティベートを実行した後に、介入が必要になる場合があります。理由は、アクティベートをトリガーするときに、Sling のジョブやイベントキューに項目が追加されるからです。このキューのサイズがだいたい 40,000 項目を超えると、処理速度が劇的に低下します。このキューのサイズが 100,000 項目を超えると、システムの安定性に影響を及ぼします。

この問題を回避するには、Fast Action Manager を使用してアセットのレプリケートを管理します。これは Sling キューを使用することなく動作し、オーバーヘッドを減らすほか、ワークロードをスロットルしてサーバーのオーバーロードを防ぎます。レプリケーションの管理に FAM を使用する例は、この機能のドキュメントページに記載しています。

アセットをパブリッシュファームに移行するその他のオプションは、vlt-rcp または oak-run を使用する方法です。これらは Jackrabbit の一部のツールとして提供されます。Experience Manager インフラストラクチャにオープンソースツール Grabbit を使用する方法もあります。vlt よりも高いパフォーマンスを発揮すると言われています。

これらのアプローチで注意すべき点は、オーサーインスタンス上でアセットがアクティベートされていると表示されないことです。アセットのアクティベート状態を正しくフラグ設定するには、アセットをアクティベート済みとマークする別のスクリプトも実行する必要があります。

パブリッシュをクローン化する cloning-publish

アセットがアクティベートされたら、パブリッシュインスタンスをクローンしてデプロイメントに必要なコピーを必要な分だけ作成できます。サーバーのクローンは比較的簡単ですが、いくつか重要な手順があります。パブリッシュをクローンするには、次の手順を実行します。

ワークフローを有効化する enabling-workflows

移行が完了したら、レンディションの生成とメタデータの抽出をサポートするために DAM の更新アセットワークフローのランチャーを再度有効化し、稼働中のシステムが日常的に使用できるようにします。

Experience Manager デプロイメントを超えた移行 migrating-between-aem-instances

それほど一般的ではないものの、ある Experience Manager デプロイメントから別のデプロイメントに大量のデータを移行する必要があります。例えば、Experience Manager のアップグレードを実行したり、ハードウェアをアップグレードをしたり、新しいデータセンターへの移行（AMS の移行）を実行する場合です。

このケースでは、移行するアセットには既にメタデータが入力されており、レンディションは既に生成されています。インスタンス間の移動に集中することができます。Experience Manager デプロイメント間で移行を行うには、次の手順を実行します。