コンテンツの検索とインデックス作成

AEM as a Cloud Service の変更点

AEM as a Cloud Service によって、アドビは AEM インスタンス中心モデルから、Cloud Manager の CI/CD パイプラインによって駆動される、n-x AEM コンテナを持つサービスベースの表示に移行します。単一の AEM インスタンスでインデックスを設定および保守する代わりに、デプロイメントの前にインデックス設定を指定する必要があります。本番環境での設定変更は、CI/CD のポリシーを明らかに破るものです。インデックスの変更についても同じことが言えます。実稼働環境に移行する前にテストおよび再インデックスを指定しない場合、システムの安定性とパフォーマンスに影響を及ぼす可能性があるからです。

AEM 6.5 以前のバージョンと比較した主な変更点のリストを以下に示します。

1. 単一の AEM インスタンスのインデックスマネージャーにアクセスできなくなり、インデックスのデバッグ、設定、または維持ができなくなります。ローカルデプロイメントおよびオンプレミスデプロイメントにのみ使用されます。

2. 単一の AEM インスタンスのインデックスを変更したり、整合性チェックや再インデックスについて心配する必要はありません。

3. 一般に、Cloud Manager の CI/CD パイプラインの品質の高いゲートウェイを迂回せず、実稼働環境のビジネス KPI に影響を与えないように、インデックスの変更は実稼働環境に移行する前に開始されます。

4. 実稼働環境での検索パフォーマンスを含むすべての関連指標は、検索とインデックスのトピックの全体的な表示を提供するために、実行時に顧客が利用できます。

5. 顧客は、必要に応じてアラートを設定できます。

6. SRE はシステムの正常性を 24 時間 365 日監視しており、必要に応じて可能な限り早急に対処します。

7. インデックスの設定は、デプロイメントを介して変更されます。インデックス定義の変更は、他のコンテンツの変更と同様に設定されます。

8. AEM as a Cloud Service の高レベルでは、Blue-Green デプロイメントモデルが導入され、1 つは古いバージョン用のセット（青）、もう 1 つは新しいバージョン用のセット（緑）の 2 組のインデックスが存在します。

9. Cloud Manager のビルドページで、顧客はインデックス作成ジョブが完了したかどうかを確認できます。新しいバージョンでトラフィックを引き受ける準備ができたら、通知を受け取ります。

10. 制限事項：

• 現在、AEM as a Cloud Service のインデックス管理は、lucene 型のインデックスに対してのみサポートされています。
• 標準のアナライザー（製品に付属しているアナライザー）のみサポートされています。カスタムアナライザーはサポートされていません。

使用方法

インデックスの定義は、次の 3 つのユースケースで構成できます。

1. 新しい顧客インデックス定義の追加
2. 既存のインデックス定義の更新。これは、既存のインデックス定義の新しいバージョンを追加することを意味します
3. 冗長または古い既存のインデックスの削除。

上記のポイント 1 と 2 の両方について、それぞれの Cloud Manager リリーススケジュールで、カスタムコードベースの一部として新しいインデックス定義を作成する必要があります。詳しくは、AEM as a Cloud Service へのデプロイドキュメントを参照してください。

新しいインデックス定義の準備

次の命名パターンに従って、実際のインデックス定義を含む新しいインデックス定義パッケージを準備する必要があります。

<indexName>[-<productVersion>]-custom-<customVersion>

それらは ui.apps/src/main/content/jcr_root の下に置く必要があります。現在、サブルートフォルダーはサポートされていません。

上記のサンプルのパッケージは、com.adobe.granite:new-index-content:zip:1.0.0-SNAPSHOT としてビルドされます。

索引定義のデプロイ

インデックス定義は、カスタムおよびバージョン付きとしてマークされるようになりました。

• インデックス定義自体（例 /oak:index/ntBaseLucene-custom-1）

したがって、インデックスをデプロイするには、インデックス定義（/oak:index/definitionname）を Git および Cloud Manager のデプロイメントプロセスを使用して ui.apps 経由で配信する必要があります。

新しいインデックス定義を追加したら、Cloud Manager を使用して新しいアプリケーションをデプロイする必要があります。デプロイメントを開始すると、2 つのジョブが開始され、それぞれ MongoDB と Azure Segment Store にオーサー用とパブリッシュ用のインデックス定義を追加（また必要に応じて結合）します。Blue-Green スイッチが起こる前に、基になるリポジトリーのインデックスが新しいインデックス定義で再作成されています。

Blue-Green デプロイメントを使用したインデックス管理

インデックス管理とは

インデックス管理とは、インデックスの追加、削除、変更を行うことです。インデックスの​定義​変更はすぐにできますが、変更を適用する（「インデックスの構築」、または既存インデックスの場合は「インデックスの再構築」と呼ばれる）には時間が必要です。これは即時には実行されません。インデックスを作成するデータをリポジトリーでスキャンする必要があります。

Blue-Green デプロイメントとは

Blue-Green デプロイメントは、ダウンタイムを短縮できます。また、ダウンタイムをゼロにするアップグレードも可能で、高速なロールバックが可能です。アプリケーションの古いバージョン（青）は、アプリケーションの新しいバージョン（緑）と同時に実行されます。

読み取り専用領域と読み取り／書き込み可能領域

リポジトリーの特定の領域（リポジトリーの読み取り専用の部分）は、古い（青い）バージョンと新しい（緑の）バージョンで異なる場合があります。リポジトリーの読み取り専用領域は、通常、「/app」と「/libs」です。次の例では、読み取り専用領域に斜体を使用し、読み取り／書き込み可能領域に太字を使用します。

• /
• /apps（読み取り専用）
• /content
• /libs（読み取り専用）
• /oak:index
• /oak:index/acme.
• /jcr:system
• /system
• /var

リポジトリーの読み取り／書き込み領域は、アプリケーションのすべてのバージョン間で共有されますが、アプリケーションの各バージョンには、/apps と /libs の固有のセットがあります。

Blue-Green デプロイメントを使用しないインデックス管理

開発中、またはオンプレミスインストールを使用する場合は、インデックスを実行時に追加、削除または変更できます。インデックスは、利用可能になるとすぐに使用されます。まだ古いバージョンのアプリケーションでインデックスを使用することを想定していない場合は、通常、予定されたダウンタイム中にインデックスが構築されます。インデックスの削除時や、既存のインデックスの変更時にも同じことが起こります。インデックスを削除すると、ただちに使用できなくなります。

Blue-Green デプロイメントによるインデックス管理

Blue-Green デプロイメントでは、ダウンタイムは発生しません。ただし、インデックス管理の場合は、インデックスが特定のバージョンのアプリケーションでのみ使用される必要があります。例えば、アプリケーションのバージョン 2 でインデックスを追加する場合に、アプリケーションのバージョン 1 ではまだインデックスを使用したくないことがあります。逆に、インデックスを削除する場合に、バージョン 2 で削除したインデックスがバージョン 1 ではまだ必要なことがあります。インデックス定義を変更する場合、古いバージョンのインデックスをバージョン 1 でのみ使用し、新しいバージョンのインデックスをバージョン 2 でのみ使用します。

次の表に、5 つのインデックス定義を示します。インデックス cqPageLucene は両方のバージョンで使用され、インデックス damAssetLucene-custom-1 はバージョン 2 でのみ使用されます。

バージョン番号は、インデックスが変更されるたびに増加します。製品自体のインデックス名と衝突するカスタムインデックス名を回避するには、カスタムインデックスと、標準提供のインデックスの変更を -custom-<number> で終える必要があります。

標準提供のインデックスの変更

アドビが「damAssetLucene」や「cqPageLucene」のような標準提供のインデックスを変更すると、damAssetLucene-2 または cqPageLucene-2 という名前の新しいインデックスが作成されます。また、インデックスが既にカスタマイズされている場合は、次のように、カスタマイズされたインデックス定義が標準提供のインデックス変更と結合されます。変更のマージは自動的に行われます。つまり、標準提供のインデックスが変更された場合、何もする必要はありません。ただし、後でインデックスを再びカスタマイズすることは可能です。

現在の制限事項

インデックス管理は、現在、lucene 型のインデックスに対してのみサポートされています。

インデックスの追加

新しいバージョン以降のアプリケーションで使用する /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

変更の取り消し

インデックス定義の変更を元に戻す必要が生じる場合があります。誤って変更が加えられたり、変更が不要になったなどの理由によります。例えば、インデックス定義 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 では、柔軟なインデックス設定により検索クエリを効率的に処理できます。大規模なリポジトリーでは、インデックスは特に重要です。すべてのクエリに適切なインデックスを付与するようにしてください。適切なインデックスのないクエリを実行すると、何千ものノードが読み取られる可能性があり、その場合は警告として記録されます。このようなクエリは、インデックス定義を最適化できるように、ログファイルを分析して特定する必要があります。詳しくは、このページを参照してください。

AEM as a Cloud Service での Lucene フルテキストインデックス

フルテキストインデックス /oak:index/lucene-2 は、デフォルトで AEM リポジトリー内のすべてのノードに対してインデックスを作成するので、非常に大きくなる可能性があります。アドビではこのインデックスを廃止する予定であり、AEM as a Cloud Service 製品ではこのインデックスは使用されなくなるので、カスタマーコードを実行する必要はなくなります。共通の Lucene インデックスを使用する AEM as a Cloud Service 環境の場合、アドビでは、ユーザーと個別に協力して、このインデックスを補完したり、最適化されたより優れたインデックスを使用できるように協調的アプローチを進めています。アドビから別途通知がない限り、ユーザーは何もする必要はありません。AEM as a Cloud Service ユーザーは、この最適化に関して対処が必要な場合に、アドビから通知を受けます。このインデックスがカスタムクエリに必要な場合は、一時的な解決策として、このインデックスのコピーを別の名前（例：/oak:index/acme.lucene-1-custom-1）で作成してください（詳しくはこちらを参照）。
この最適化は、オンプレミスでホストされる、または Adobe Managed Services で管理される他の AEM 環境には、デフォルトでは適用されません。

クエリの最適化

クエリパフォーマンス​ツールを使用すると、一般的なクエリと低速な JCR クエリの両方を監視できます。さらに、クエリを分析し、特に、このクエリにインデックスが使用されているかどうかについての様々な情報を表示することができます。

オンプレミスの AEM とは異なり、AEM as a Cloud Service では​クエリパフォーマンス​ツールが UI に表示されなくなりました。代わりに、（Cloud Manager の）開発者コンソールの「クエリ」タブで使用できるようになりました。