AEM as a Cloud Service によって、アドビは AEM インスタンス中心モデルから、Cloud Manager の CI/CD パイプラインによって駆動される、n-x AEM コンテナを持つサービスベースの表示に移行します。単一の AEM インスタンスでインデックスを設定および保守する代わりに、デプロイメントの前にインデックス設定を指定する必要があります。本番環境での設定変更は、CI/CD のポリシーを明らかに破るものです。インデックスの変更についても同じことが言えます。実稼働環境に移行する前にテストおよび再インデックスを指定しない場合、システムの安定性とパフォーマンスに影響を及ぼす可能性があるからです。
AEM 6.5 以前のバージョンと比較した主な変更点のリストを以下に示します。
単一の AEM インスタンスのインデックスマネージャーにアクセスできなくなり、インデックスのデバッグ、設定、または維持ができなくなります。ローカルデプロイメントおよびオンプレミスデプロイメントにのみ使用されます。
単一の AEM インスタンスのインデックスを変更したり、整合性チェックや再インデックスについて心配する必要はありません。
一般に、Cloud Manager の CI/CD パイプラインの品質の高いゲートウェイを迂回せず、実稼働環境のビジネス KPI に影響を与えないように、インデックスの変更は実稼働環境に移行する前に開始されます。
実稼働環境での検索パフォーマンスを含むすべての関連指標は、検索とインデックスのトピックの全体的な表示を提供するために、実行時に顧客が利用できます。
顧客は、必要に応じてアラートを設定できます。
SRE はシステムの正常性を 24 時間 365 日監視しており、必要に応じて可能な限り早急に対処します。
インデックスの設定は、デプロイメントを介して変更されます。インデックス定義の変更は、他のコンテンツの変更と同様に設定されます。
AEM as a Cloud Service の高レベルでは、Blue-Green デプロイメントモデルが導入され、1 つは古いバージョン用のセット(青)、もう 1 つは新しいバージョン用のセット(緑)の 2 組のインデックスが存在します。
Cloud Manager のビルドページで、顧客はインデックス作成ジョブが完了したかどうかを確認できます。新しいバージョンでトラフィックを引き受ける準備ができたら、通知を受け取ります。
制限事項:
lucene
型のインデックスに対してのみサポートされています。damAssetLucene
インデックスに対して記述されたクエリは、Skyline 上では実際には、このインデックスの Elasticsearch バージョンに対して実行される可能性があります。この違いは、通常、アプリケーションとユーザーには見えませんが、explain
機能などの特定のツールでは異なるインデックスが報告されます。Lucene インデックスと Elasticsearch インデックスの違いについては、Apache Jackrabbit Oak の Elastic 関連ドキュメントを参照してください。ユーザーは、Elasticsearch インデックスを直接設定する必要はなく、また設定できません。インデックスの定義は、以下の 3 つのユースケースで構成されます。
上記のポイント 1 と 2 の両方について、それぞれの Cloud Manager リリーススケジュールで、カスタムコードベースの一部として新しいインデックス定義を作成する必要があります。詳しくは、 AEM as a Cloud Service へのデプロイ ドキュメントを参照してください。
インデックスの定義は、以下のいずれかになります。
/oak:index/cqPageLucene-2
があります。/oak:index/cqPageLucene-2-custom-1
があります。/oak:index/acme.product-1-custom-2
があります。名前の競合を避けるために、完全なカスタムインデックスには acme.
のようなプレフィックスを付ける必要があります。標準提供のインデックスのカスタマイズと完全なカスタムインデックスの両方に、-custom-
を含める必要があることに注意してください。完全なカスタムインデックスのみ、プレフィックスで始める必要があります。
標準提供のインデックスをカスタマイズする場合(例:damAssetLucene-6
)、CRX DE パッケージマネージャー(/crx/packmgr/
)を使用して、最新の標準のインデックス定義を Cloud Service 環境にコピーしてください。次に、設定の名前を damAssetLucene-6-custom-1
などに変更し、その上にカスタマイズを追加します。これにより、必要な設定が誤って削除されるのを防ぐことができます。例えば、/oak:index/damAssetLucene-6/tika
下のノード tika
は、Cloud Service のカスタマイズ済みインデックスに必要です。Cloud SDK には存在しません。
次の命名パターンに従って、実際のインデックス定義を含む新しいインデックス定義パッケージを準備する必要があります。
<indexName>[-<productVersion>]-custom-<customVersion>
それらは ui.apps/src/main/content/jcr_root
の下に置く必要があります。カスタマイズされたカスタムインデックス定義は、すべて /oak:index
下に保存する必要があります。
パッケージのフィルターは、既存(標準提供のインデックス)が保持されるように設定する必要があります。ui.apps/src/main/content/META-INF/vault/filter.xml
ファイルで、各カスタム(またはカスタマイズ済み)インデックスを、例えば <filter root="/oak:index/damAssetLucene-6-custom-1"/>
のようにリストする必要があります。インデックスのバージョンを後で変更する場合は、フィルターを調整する必要があります。
上記のサンプルのパッケージは、com.adobe.granite:new-index-content:zip:1.0.0-SNAPSHOT
としてビルドされます。
インデックス定義を含んだコンテンツパッケージには、コンテンツパッケージのプロパティファイル(/META-INF/vault/properties.xml
)で次のプロパティを設定する必要があります。
noIntermediateSaves=true
インデックス定義は、カスタムおよびバージョン付きとしてマークされます。
/oak:index/ntBaseLucene-custom-1
)カスタムインデックスまたはカスタマイズ済みインデックスをデプロイするには、インデックス定義(/oak:index/definitionname
)は、Git と Cloud Manager のデプロイメントプロセスを使用して ui.apps
を介して配信される必要があります。FileVault フィルター、例えば ui.apps/src/main/content/META-INF/vault/filter.xml
では、カスタムおよびカスタマイズ済み各インデックスを、<filter root="/oak:index/damAssetLucene-7-custom-1"/>
のように個別にリストします。カスタムまたはカスタマイズ済みインデックス定義自体が、次のように ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/.content.xml
ファイルに保存されます。
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:oak="http://jackrabbit.apache.org/oak/ns/1.0" xmlns:dam="http://www.day.com/dam/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
jcr:primaryType="oak:QueryIndexDefinition"
async="[async,nrt]"
compatVersion="{Long}2"
...
</indexRules>
<tika jcr:primaryType="nt:unstructured">
<config.xml jcr:primaryType="nt:file"/>
</tika>
</jcr:root>
上記の例には、Apache Tika の設定が含まれています。Tika 設定ファイルは、ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/tika/config.xml
に保存されます。
Jackrabbit Filevault Maven パッケージプラグインを使用するバージョンに応じて、プロジェクトでさらに設定が必要になります。Jackrabbit Filevault Maven パッケージプラグインバージョン 1.1.6 以降を使用する場合は、pom.xml
ファイルに filevault-package-maven-plugin
のプラグイン設定の configuration/validatorsSettings
(jackrabbit-nodetypes
の直前)に、次のセクションを記述する必要があります。
<jackrabbit-packagetype>
<options>
<immutableRootNodeNames>apps,libs,oak:index</immutableRootNodeNames>
</options>
</jackrabbit-packagetype>
また、この場合、vault-validation
バージョンは、新しいバージョンにアップグレードする必要があります。
<dependency>
<groupId>org.apache.jackrabbit.vault</groupId>
<artifactId>vault-validation</artifactId>
<version>3.5.6</version>
</dependency>
そして、ui.apps.structure/pom.xml
と ui.apps/pom.xml
の filevault-package-maven-plugin
の設定で、 allowIndexDefinitions
と noIntermediateSaves
を有効にする必要があります。オプション noIntermediateSaves
は、インデックス設定が自動的に追加されることを保証します。
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<configuration>
<allowIndexDefinitions>true</allowIndexDefinitions>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
<noIntermediateSaves>true</noIntermediateSaves>
</properties>
...
ui.apps.structure/pom.xml
で、このプラグインの filters
セクションには、次のようにフィルタールートを含める必要があります。
<filter><root>/oak:index</root></filter>
新しいインデックス定義を追加したら、Cloud Manager を使用して新しいアプリケーションをデプロイする必要があります。デプロイメントを開始すると、2 つのジョブが開始され、それぞれ MongoDB と Azure Segment Store にオーサー用とパブリッシュ用のインデックス定義を追加(また必要に応じて結合)します。Blue-Green スイッチが起こる前に、基になるリポジトリーのインデックスが新しいインデックス定義で再作成されています。
AEM as a Cloud Service を使用する場合に必要なパッケージ構造の詳細については、 AEM プロジェクト構造 ドキュメントを参照してください。
インデックス管理とは、インデックスの追加、削除、変更を行うことです。インデックスの定義変更はすぐにできますが、変更を適用する(「インデックスの構築」、または既存インデックスの場合は「インデックスの再構築」と呼ばれる)には時間が必要です。これは即時には実行されません。インデックスを作成するデータをリポジトリーでスキャンする必要があります。
Blue-Green デプロイメントは、ダウンタイムを短縮できます。また、ダウンタイムをゼロにするアップグレードも可能で、高速なロールバックが可能です。アプリケーションの古いバージョン(青)は、アプリケーションの新しいバージョン(緑)と同時に実行されます。
リポジトリーの特定の領域(リポジトリーの読み取り専用の部分)は、古い(青い)バージョンと新しい(緑の)バージョンで異なる場合があります。リポジトリーの読み取り専用領域は、通常、「/app
」と「/libs
」です。次の例では、読み取り専用領域に斜体を使用し、読み取り/書き込み可能領域に太字を使用します。
リポジトリーの読み取り/書き込み領域は、アプリケーションのすべてのバージョン間で共有されますが、アプリケーションの各バージョンには、/apps
と /libs
の固有のセットがあります。
開発中、またはオンプレミスインストールを使用する場合は、インデックスを実行時に追加、削除または変更できます。インデックスは、利用可能になるとすぐに使用されます。まだ古いバージョンのアプリケーションでインデックスを使用することを想定していない場合は、通常、予定されたダウンタイム中にインデックスが構築されます。インデックスの削除時や、既存のインデックスの変更時にも同じことが起こります。インデックスを削除すると、ただちに使用できなくなります。
Blue-Green デプロイメントでは、ダウンタイムは発生しません。アップグレード中は、しばらくの間、アプリケーションの古いバージョン(例:バージョン 1)と新しいバージョン(バージョン 2)の両方が同じリポジトリーに対して同時に実行されています。バージョン 1 で特定のインデックスを使用できる必要がある場合は、バージョン 2 でこのインデックスを削除しないでください。このインデックスは、後で(例えばバージョン 3 で)削除してください。その時点では、アプリケーションのバージョン 1 は実行されなくなっています。また、バージョン 2 が実行中で、バージョン 2 のインデックスが使用可能でも、バージョン 1 が正常に動作するようにアプリケーションを作成してください。
新しいバージョンへのアップグレードが完了した後、システムが古いインデックスをガベージコレクションできます。(ロールバックが必要な場合は)ロールバックを高速化するために、古いインデックスがしばらくの間保持される可能性があります。
次の表に、5 つのインデックス定義を示します。インデックス cqPageLucene
は両方のバージョンで使用され、インデックス damAssetLucene-custom-1
はバージョン 2 でのみ使用されます。
<indexName>-custom-<customerVersionNumber>
は、既存のインデックスの代わりとしてマークするために、AEM as a Cloud Service で必要です。
索引 | 標準提供インデックス | バージョン 1 で使用 | バージョン 2 で使用 |
---|---|---|---|
/oak:index/damAssetLucene | はい | はい | いいえ |
/oak:index/damAssetLucene-custom-1 | 可(カスタマイズ) | いいえ | はい |
/oak:index/acme.product-custom-1 | いいえ | はい | いいえ |
/oak:index/acme.product-custom-2 | いいえ | いいえ | はい |
/oak:index/cqPageLucene | はい | はい | はい |
バージョン番号は、インデックスが変更されるたびに増加します。製品自体のインデックス名と衝突するカスタムインデックス名を回避するには、カスタムインデックスと、標準提供のインデックスの変更を -custom-<number>
で終える必要があります。
アドビが「damAssetLucene」や「cqPageLucene」のような標準提供のインデックスを変更すると、damAssetLucene-2
または cqPageLucene-2
という名前の新しいインデックスが作成されます。また、インデックスが既にカスタマイズされている場合は、次のように、カスタマイズされたインデックス定義が標準提供のインデックス変更と結合されます。変更のマージは自動的に行われます。つまり、標準提供のインデックスが変更された場合、何もする必要はありません。ただし、後でインデックスを再びカスタマイズすることは可能です。
索引 | 標準提供インデックス | バージョン 2 で使用 | バージョン 3 で使用 |
---|---|---|---|
/oak:index/damAssetLucene-custom-1 | 可(カスタマイズ) | はい | いいえ |
/oak:index/damAssetLucene-2-custom-1 | 可(damAssetLucene-custom-1 および damAssetLucene-2 から自動的に結合) | いいえ | はい |
/oak:index/cqPageLucene | はい | はい | いいえ |
/oak:index/cqPageLucene-2 | はい | いいえ | はい |
インデックス管理は、現在、lucene
型のインデックスに対してのみサポートされています。内部的には、他のインデックスがクエリに設定され使用される可能性があります(例えば Elasticsearch インデックスなど)。
新しいバージョン以降のアプリケーションで使用する /oak:index/acme.product-custom-1
という名前の完全カスタムインデックスを追加するには、インデックスを以下のように設定する必要があります。
acme.product-1-custom-1
これは、インデックス名の前にカスタム識別子を付け、その後にドット(.
)を付けることで機能します。識別子の長さは 2~5 文字です。
これにより、新しいバージョンのアプリケーションでのみインデックスが使用されます。
既存のインデックスを変更する場合は、変更したインデックス定義を使用して新しいインデックスを追加する必要があります。例えば、既存のインデックス /oak:index/acme.product-custom-1
が変更されるとします。古いインデックスは /oak:index/acme.product-custom-1
下に、新しいインデックスは /oak:index/acme.product-custom-2
下に格納されます。
アプリケーションの古いバージョンでは、次の設定を使用します。
/oak:index/acme.product-custom-1
新しいバージョンのアプリケーションでは、次の(変更された)設定が使用されます。
/oak:index/acme.product-custom-2
AEM as a Cloud Service のインデックス定義が、ローカル開発インスタンスのインデックス定義と完全には一致しない場合があります。開発インスタンスには Tika 設定がありませんが、AEM as a Cloud Service インスタンスには Tika 設定があります。Tika 設定でインデックスをカスタマイズする場合は、その Tika 設定を保持してください。
インデックス定義の変更を元に戻す必要が生じる場合があります。誤って変更が加えられたり、変更が不要になったなどの理由によります。例えば、インデックス定義 damAssetLucene-8-custom-3
は誤って作成され、既にデプロイされているとします。そのため、以前のインデックス定義 damAssetLucene-8-custom-2
に戻す必要があります。それには、前のインデックス damAssetLucene-8-custom-2
の定義を含んだ damAssetLucene-8-custom-4
という新しいインデックスを追加する必要があります。
次の操作は、カスタムインデックスにのみ適用されます。製品インデックスは AEM で使用されるので、削除できません。
新しいバージョンのアプリケーションでインデックスを削除する場合は、新しい名前で空のインデックス(使用されることがなく、データを含まない空のインデックス)を定義できます。この例では、/oak:index/acme.product-custom-3
という名前を付けることができます。これにより、/oak:index/acme.product-custom-2
インデックスが置き換えられます。システムによって /oak:index/acme.product-custom-2
が削除された後は、空のインデックス /oak:index/acme.product-custom-3
も削除できます。このような空のインデックスの例を次に示します。
<acme.product-custom-3
jcr:primaryType="oak:QueryIndexDefinition"
async="async"
compatVersion="2"
includedPaths="/dummy"
queryPaths="/dummy"
type="lucene">
<indexRules jcr:primaryType="nt:unstructured">
<rep:root jcr:primaryType="nt:unstructured">
<properties jcr:primaryType="nt:unstructured">
<dummy
jcr:primaryType="nt:unstructured"
name="dummy"
propertyIndex="{Boolean}true"/>
</properties>
</rep:root>
</indexRules>
</acme.product-custom-3>
標準提供のインデックスをカスタマイズする必要がなくなった場合は、標準提供のインデックス定義をコピーする必要があります。例えば、既に damAssetLucene-8-custom-3
をデプロイしていて、カスタマイズが不要になり、デフォルトの damAssetLucene-8
インデックスに戻す場合は、damAssetLucene-8
のインデックス定義を含んだインデックス damAssetLucene-8-custom-4
を追加する必要があります。
Apache Jackrabbit Oak では、柔軟なインデックス設定により検索クエリを効率的に処理できます。大規模なリポジトリーでは、インデックスは特に重要です。すべてのクエリに適切なインデックスを付与するようにしてください。適切なインデックスのないクエリを実行すると、何千ものノードが読み取られる可能性があり、その場合は警告として記録されます。
詳しくは、 このドキュメント クエリとインデックスを最適化する方法について詳しくは、を参照してください。