Indexing Assets in Jira Service Management
Jira Service Management のアセットは、オブジェクト (資産と構成アイテム) のデータベースを管理するのに役立ち、リクエストを通じて簡単に操作できるようにします。ただし、これらのオブジェクトに対するクエリは、詳細な情報モデルが作成されるため、リソースを大量に消費する可能性があります。これらの課題に対処し、パフォーマンスを向上させるには、インデックスを使用できます。インデックスは、データベースのディスクに保存されているデータとは別の、アセット オブジェクト データのインメモリ コピーです。インデックスを使用すると、データへのアクセスがはるかに速くなり、パフォーマンスが向上し、アセット クエリ言語 (AQL) の結果が速くなります。
アセットとメモリの要件
インスタンスが大きくなるにつれて、インメモリ インデックスには時間の経過とともにより多くの Java 仮想マシン (JVM) メモリが必要になる可能性があります。アセットで使用する予定のデータ量を Jira が処理できるように設定されていることをご確認ください。アセットのメモリに関する推奨事項をご確認ください。
アセットのインデックス化の仕組み
アセットでは、インデックス化はインメモリ キャッシュ システムである Google の Guava Cache によって管理されます。このシステムでは、アセット データの種類が異なれば使用するインデックスも異なり、それぞれが特定のデータ カテゴリ向けに最適化されています。このアプローチでは、データが複雑になっても、システムは応答性と効果を維持します。Google の Guava Cache について詳細をご確認ください。
インデックス | 保存対象 |
|---|---|
オブジェクト |
|
オブジェクト タイプ属性 |
|
objectType |
|
objectSchema | 以下のような基本的なオブジェクト スキーマ:
|
オブジェクト チケット | Jira チケットとの関係 |
ファイル | アセットで参照されているファイル |
アイコン | アイコン データ |
カスタム フィールド、参照カスタム フィールド、既定のカスタム フィールド | アセットのカスタム フィールド設定 |
フリー テキスト インデックス | 検索に必要な ID、キー、ラベル、属性用語。フリー テキスト インデックスは、文字列全体を保存するのではなく、文字列をキーワードに減らします。フリー テキスト インデックスについて詳細をご確認ください。 これは Lucene に保存される唯一のインデックスです。 |
インデックス化されたフラグ
インデックス化されたフラグは、資産の特定の属性を検索および取得する目的でインデックスに含めるかどうかを決定する設定です。アセットでは、テキスト領域を除くすべての属性が既定でインデックス化されます。
特定の属性をインデックスから削除するには、その属性のインデックス化されたフラグを無効にします。これはメモリ消費量の削減に役立ちますが、属性をデータベースから直接取得する必要があるため、検索やインポートが遅くなる可能性があります。属性の設定について詳細をご確認ください。
属性のインデックス化を無効にしても、インデックス再作成のパフォーマンスに大きな影響はありません。ただし、インデックス化されていない属性のインポートのパフォーマンスは 2 倍を超える可能性があります。
ディスク ストレージ
Jira とは異なり、アセットのインデックスは Lucene には保存されません（フリー テキスト インデックスを除く）。つまり、アセットのインデックスは通常、ディスク上に残りません。管理者はインデックスを手動でディスクに転送できます。または、アセットの設定で [シャットダウン時にキャッシュを保存] を有効にすることで、シャットダウン時に自動的に転送することもできます。
システムがシャット ダウンする際に、[シャットダウン時にキャッシュを保存] が有効になっている場合、または [アセット インデックスをファイルに永続化] が手動でトリガーされると、次のインデックスが JiraLocalHome/caches/insight_indexes ディレクトリのファイルに書き込まれます。
オブジェクト
オブジェクト スキーマ
オブジェクト タイプ
オブジェクト タイプ属性
オブジェクト チケットの接続
このプロセスでは、インデックスを一時ファイルに書き込み、既存のインデックス ファイルを削除し、一時ファイルを insight_indexes ディレクトリに移動します。
起動時のディスク ストレージ
起動時に、[アセット インデックスをファイルから復元] が有効になっていると、インデックスはディスク上のインデックス ファイルから再作成されます。この設定が有効になっていない場合、インデックスはデータベースから再作成されます。
オブジェクトの数が多い場合は、データベースからインデックスを再作成するよりも、起動時にファイルからインデックスを復元する方が効率的です。ただし、データベースからインデックスを再作成することで、データの不整合の原因となり得るインデックス ファイルの破損というリスクを軽減できる可能性があります。構成の設定について詳細をご確認ください。
フリー テキスト インデックス
フリー テキスト インデックスは Lucene に保存され、テキスト領域、テキスト、URI、メール、選択属性などのアセットのテキスト属性でテキストを検索するために使用されます。
アセットのフリー テキスト インデックスは JiraLocalHome/caches/insight_indexes/freetext/directory に保存され、スキーマごとに 1 つのインデックスが保持されます。アセットでは毎晩深夜に、フリー テキスト インデックスを再作成する定期ジョブが自動的に実行されます。現在、このジョブを無効にするオプションはありません。さらに、手動でインデックス再作成が実行されるたびに、フリー テキストのインデックス再作成がトリガーされます。この設定により、インデックス化は最新の状態に保たれますが、インデックス再作成のスケジュールを管理する際の柔軟性が制限される可能性があります。
クラスタリングとレプリケーション
クラスター環境では、各ノードが独自のインデックスを保持しているため、すべてのノードが現在のデータの状態を認識できるように、変更をノード間でレプリケートする必要があります。このレプリケーション プロセスは、ネットワークの中断、高負荷 (インポート中など)、および一般的なパフォーマンス上の課題に対処する必要があるため、複雑です。レプリケーションは、オブジェクトが変更されるたびに行われます。
Jira Service Management 5.8.0 以降では、アセットの無効化通知には、オブジェクト インデックスのクラスター メッセージの代わりに Atlassian Cache のノード間無効化が使用されます。アセットのパフォーマンス改善について詳細をご確認ください。
レプリケーション フロー
レプリケーションには、作成、更新、削除というオブジェクト操作が含まれます。CacheMessage には次のものが含まれます。
インデックス タイプ
追加、削除、更新などの操作の種類
インデックスで更新するエンティティの ID
更新時刻
作業キュー サイズの既定容量は 10,000 です。容量は、アセット設定ページの送信者キューのサイズ プロパティ (com.atlassian.assets.replication.work.queue.size) を更新することで設定できます。アセット設定の詳細
バッチ レプリケーション メッセージには、追加および削除されるオブジェクトの ID と、更新されたオブジェクトの ID およびその更新時間が含まれます。たとえば、jiradctest3 ノードに ID 21229075 のオブジェクトが作成された場合、ログに次のメッセージが表示されます。
2024-09-19 16:55:59,747+0200 assets-replicator-3 TRACE [i.r.i.i.replication.poller.CacheMessageWorkQueuePoller] Batch message: AssetsBatchReplicationMessage(id=026ef180-78d5-487e-a8fb-35507714336f, sourceNode=jiradctest3, cacheType=OBJECT, addIds=[21229075, 21229057 ], updateIds={}, deleteIds=[], messageTimestamp=1726757759747, retryAttempts=0, lastRetryTimestamp=1726757759747)他のノードでは、メッセージは次のようになるかもしれません。
2024-09-19 16:56:00,729+0200 RMI TCP Connection(4298)-10.150.208.4 DEBUG [i.r.i.index.replication.AssetsReplicationTransportManager] onRemove for event: 026ef180-78d5-487e-a8fb-35507714336f
2024-09-19 16:56:00,724+0200 RMI TCP Connection(5457)-10.150.208.4 DEBUG [i.r.i.index.replication.AssetsReplicationTransportManager] Received event from node jiradctest3 from object cache with ID 026ef180-78d5-487e-a8fb-35507714336f
2024-09-19 16:56:00,724+0200 RMI TCP Connection(5457)-10.150.208.4 DEBUG [i.r.i.index.replication.AssetsBatchReplicationMessageReceiver] Received message with ID 026ef180-78d5-487e-a8fb-35507714336f
2024-09-19 16:56:00,725+0200 assets-replication-receiver-0 TRACE [i.r.i.i.replication.poller.AssetsBatchReplicationMessageWorkQueuePoller] Processing replication message with ID 026ef180-78d5-487e-a8fb-35507714336f複製は無効化によって行われます。各ノードは削除メッセージを受け取り、データベースから更新を個別にロードします。アセット インデックス検証プロパティの既定値の詳細
デッドレター キュー
デッドレター キュー (DLQ) は、正常に処理できないメッセージを保持する領域です。既定では、再試行キューにある項目は、合計 10 分間、1 分ごとに再試行されます。必要に応じて、アセット設定でこれを設定できます。
すべての再試行が失敗すると、失敗した更新メッセージは DLQ に移動されます。必要に応じて、失敗の根本原因を解決したら DLQ 内のアイテムを再生 (再試行) できます。また、問題を解決できない場合やインデックスの再作成がすでに完了している場合は、アイテムをクリアできます。
これらのエンドポイントでは、DLQ を再生またはクリアできます。
GET
rest/insight/1.0/deadletterqueue/replayは、DLQ を非クラスター モードで再生し、クラスター モードですべてのノードの DLQ を再生するブロードキャスト リクエストを送信します。GET
rest/insight/1.0/deadletterqueue/replay/{nodeId}は、特定のノードの DLQ をクラスター モードで再生するユニキャスト リクエストを送信します。nodeIdは、リクエストを受信してその DLQ を再生するノードです。
アセットのインデックス再作成
インデックスの再作成を行うには、Jira システム管理者である必要があります。
時々、アセット データがデータベースと同期しなくなることがあります。これは、データベースが直接変更されたり、インデックスの複製プロセスが失敗した場合に発生する可能性があります。すべてを復元するには、アセットのインデックスを再作成する必要があります。インデックスの再作成には、メモリ内のデータをすべて削除し、データベースから新しいデータを引き出すことが含まれます。次の再インデックス アクションを実行できます。
クリーンな再インデックス化では、すべてのノードですべてのオブジェクトがインデックスから削除されて、その後再びインデックス化されます。これは、最新の状態のインデックスが必要な場合に推奨されます。インデックス化の進行中は、その処理を取り消したり、オブジェクトを検索またはフィルタリングしたりすることはできません。この再インデックス化により、キャッシュに保存されているすべての ID が削除されます。
再インデックス化 (標準的な再インデックス化) では、すべてのオブジェクトをインデックスに残した上で、Assets が再度インデックスを作成します。処理中もオブジェクトを検索できます。この再インデックス化では ID が保持され、すでにキャッシュにある ID のデータのみが取得されます。
標準的な再インデックス化では、ID が削除または追加された場合に障害が発生する可能性があります。このような場合は、クリーンな再インデックス化をお勧めします。Jira 設定でのクリーンな再インデックス化の詳細
アセット インデックスをファイルに永続化では、ディスク上にインデックスを手動で永続化 (コピー) できます。多数のオブジェクトを含む大規模なアセット環境があり、Jira の再インストールを計画している場合に役立ちます。インデックスをディスク上に保存しておけば、Assets でゼロから作り直す必要はありません。
クリーンな再インデックス化の間に、各タイプのローカル インデックスがクリアされ、インデックスのコピーを削除するように求めるメッセージがすべてのノードに送信されます。このメッセージには、削除するインデックスの種類 (オブジェクトなど) と REMOVE_ALL 操作が含まれています。ディスクに保存されているすべてのローカル インデックス ファイルは削除されます。再インデックス化を処理しているノードは、インデックスの再構築を開始します。このプロセスで使用されるスレッドの数は、アセット設定ページのアセットの並列処理プロパティを調整することで設定できます。次に、すべてのノードがインデックスのローカル コピーを削除し、レプリケーション プロセスを使用してインデックスを再構築します。
ロックの適用
再インデックス化の間は、再インデックス化を実行しているノードで Assets を使用できません。クリーンな再インデックス化の場合、クラスター全体で Assets を使用できません。これを管理するために、アセット データが変更されないようにロックをかけています。再インデックス化が完了すると、アセットのロックが解除されます。
スタートアップ
アセット インデックスをファイルから復元を有効にした場合、起動時にインデックスが、ディスク上のインデックス ファイルから再作成されます。この設定を有効にしないと、インデックスはデータベースから再作成されます。アセット インデックス ファイルの整合性チェックはデータベースに対して行われます。データベースは信頼できる情報源となり、データに一貫性があるかどうかが検証されます。データに一貫性がない場合は、アセットの再インデックス化が開始されます。
次の例のようなログに再インデックス化の詳細が表示されます。
2024-11-11 10:15:27,870 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Control corrupted data done
2024-11-11 10:15:27,872 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] property: 'assets.version' set to: 20.2.0-SNAPSHOT
2024-11-11 10:15:27,873 InsightLauncherThread WARN anonymous [i.r.i.i.m.InsightPersistedIndexManager] Assets Object Cache file not found <localhome>/caches/insight_indexes/objectschema
2024-11-11 10:15:27,876 InsightLauncherThread WARN anonymous [i.r.i.i.m.InsightPersistedIndexManager] Assets Object Cache file not found <localhome>/caches/insight_indexes/objecttype
2024-11-11 10:15:27,877 InsightLauncherThread WARN anonymous [i.r.i.i.m.InsightPersistedIndexManager] Assets Object Cache file not found <localhome>/caches/insight_indexes/objecttypeattribute
2024-11-11 10:15:27,877 InsightLauncherThread WARN anonymous [i.r.i.i.m.InsightPersistedIndexManager] Assets Object Cache file not found <localhome>/caches/insight_indexes/objects
2024-11-11 10:15:27,877 InsightLauncherThread WARN anonymous [i.r.i.i.m.InsightPersistedIndexManager] Assets Object Cache file not found <localhome>/caches/insight_indexes/objectConnection
2024-11-11 10:15:27,881 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Restore Assets cache done
2024-11-11 10:15:27,882 InsightLauncherThread WARN anonymous [c.r.j.p.i.s.c.i.i.IndexIntegrityCheckerImpl] Integrity check failed, number of objects mismatched, database: 1, index: 0
2024-11-11 10:15:27,884 InsightLauncherThread WARN anonymous [c.r.j.p.i.s.c.i.i.IndexIntegrityCheckerImpl] Integrity check failed, number of objects schemas mismatched, database: 1, index: 0
2024-11-11 10:15:27,885 InsightLauncherThread WARN anonymous [c.r.j.p.i.s.c.i.i.IndexIntegrityCheckerImpl] Integrity check failed, number of objects types mismatched, database: 21, index: 0
2024-11-11 10:15:27,885 InsightLauncherThread WARN anonymous [c.r.j.p.i.s.c.i.i.IndexIntegrityCheckerImpl] Integrity check failed, number of objects type attribute mismatched, database: 138, index: 0
2024-11-11 10:15:27,888 InsightLauncherThread WARN anonymous [c.r.j.p.i.s.l.InsightLauncher] Cache integrity check failed: IndexIntegrity{objectJiraIssueIndexOk=true, objectSchemaIndexOk=false, objectTypeAttributeIndexOk=false, objectTypeIndexOk=false, objectIndexOk=false}
2024-11-11 10:15:27,893 InsightLauncherThread INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexServiceImpl] Numbers of objects in database 1
2024-11-11 10:15:27,895 InsightLauncherThread INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexServiceImpl] Starting Assets Reindex with a total work units of 161
2024-11-11 10:15:27,930 InsightLauncherThread INFO Anonymous user [c.r.j.p.i.s.c.m.AsyncTaskHandlerImpl] Starting InsightMultiThreadedEnabled service AsyncTaskHandlerImpl with parallelism set to 10
2024-11-11 10:15:27,934 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Check Assets cache integrity done
2024-11-11 10:15:27,934 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Start scheduling object attributes
2024-11-11 10:15:27,934 insight-InsightThreadGroup-worker-thread-0 WARN Anonymous user [c.r.j.p.i.s.c.i.ReindexServiceImpl] Starting Assets reindex in 10 threads
2024-11-11 10:15:27,934 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.InsightLockServiceImpl] Locking Assets insight_locked
2024-11-11 10:15:27,935 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Scheduling object attributes done.
2024-11-11 10:15:27,936 InsightLauncherThread INFO anonymous [c.r.j.p.i.s.l.InsightLauncher] Scheduling import done.
2024-11-11 10:15:27,936 insight-InsightThreadGroup-worker-thread-0 WARN Anonymous user [c.r.j.p.i.s.c.i.ClusterAwareReindexServiceImpl] Assets is locked for reindex
2024-11-11 10:15:27,943 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.c.i.ObjectTypeReindexStrategy] Getting object type IDs to index
2024-11-11 10:15:27,945 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.c.i.ObjectTypeReindexStrategy] Found 21 object type IDs to index
2024-11-11 10:15:27,946 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.c.i.ObjectTypeReindexStrategy] Started Assets reindex of object types
2024-11-11 10:15:27,974 insight-InsightThreadGroup-worker-thread-3 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:27,974 insight-InsightThreadGroup-worker-thread-3 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:27,974 insight-InsightThreadGroup-worker-thread-1 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,073 insight-InsightThreadGroup-worker-thread-8 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,074 insight-InsightThreadGroup-worker-thread-9 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,074 insight-InsightThreadGroup-worker-thread-5 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,075 insight-InsightThreadGroup-worker-thread-7 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,077 insight-InsightThreadGroup-worker-thread-6 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,078 insight-InsightThreadGroup-worker-thread-4 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,078 insight-InsightThreadGroup-worker-thread-2 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexObjectTypesJob] Object type index complete for thread
2024-11-11 10:15:28,078 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.c.i.ObjectTypeReindexStrategy] Reindex of object types completed in 135ms
2024-11-11 10:15:28,362 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.c.i.ReindexServiceImpl] Finishing progress OK ProgressId: resourceId: reindex, category: assets-reindex
2024-11-11 10:15:28,362 insight-InsightThreadGroup-worker-thread-0 INFO Anonymous user [c.r.j.p.i.s.InsightLockServiceImpl] Unlocking Assets insight_locked
2024-11-11 10:15:28,364 insight-InsightThreadGroup-worker-thread-0 WARN Anonymous user [c.r.j.p.i.s.c.i.ClusterAwareReindexServiceImpl] Assets is unlocked after reindex構成
アセットのグローバル Jira 設定にアクセスするには、次の手順に従います。
[管理] > [アプリの管理] の順に移動します。
[アセット] セクションで、[アセット設定] に移動します。
3. アセット設定ページの下部で、[設定を編集] を選択します。
4. [一般アセット設定] セクションに移動し、必要な設定を変更します。
構成 | 説明 | Why you might change this |
|---|---|---|
アセット インデックスをファイルから復元 | アセット インデックスをファイルから復元すると、起動時間が短縮されます。これをオフにすると起動時間が遅くなりますただし、インデックス ファイルが破損している場合に発生するデータ不整合のリスクは排除できます 既定では、ファイルからキャッシュが復元されます。 | これを無効にすると、起動時に常にインデックスが再作成されます。 |
キャッシュをシャットダウン時に保存 | プラグインのシャットダウン時にファイルにアセット キャッシュを保存します。 | 処理するオブジェクトの数が非常に多い場合、シャットダウン時にキャッシュを保存するとパフォーマンスが低下する可能性があります。そのような場合は、Tomcat のシャットダウン タイムアウト (既定では 60 秒) を増やすことを検討してください。パフォーマンス チューニングの設定を確認してください |
アセット キャッシュを制限 | アセット キャッシュに格納されるオブジェクトの量を制限します。 | これは、必要なメモリ フットプリントを減らすためです。 |
キャッシュに許されるオブジェクトの数 | アセット オブジェクト キャッシュに置かれるオブジェクトの最大数を指定します。この量を超えた場合、オブジェクトは LRU の原則によって除去されます。 | キャッシュ内のオブジェクトの最大数を変更するには。 |
インデックス サイズの制限
アセット インデックスのオブジェクト数を制限して、メモリ消費量を減らすことができます。ただし、インデックスにないオブジェクトはデータベースから直接クエリされるため、パフォーマンスに影響します。
トラブルシューティング
インデックス作成の問題が発生した場合は、以下の情報を参照してください。
不整合な状態のインデックス再作成
場合によっては、データベース内のデータが不整合な状態になってしまうことがあります。この場合、データをインデックスで参照できなくなり、Assets アプリケーションで表示しようとすると問題が発生する可能性があります。
Jira Service Management 10.1 以降では、これらのエラーはアセット インデックス UI とログに表示されます。アセット インデックスのトラブルシューティングの詳細
アトラシアンのプロファイリングとメトリック
Assets は、アセットのレプリケーション統計を監視するために使用できるいくつかの Java Management Extensions (JMX) メトリックを収集して公開します。JMX インターフェイスを使用したライブ モニタリングの詳細
ログ
以下に、Assets でレプリケーションと再インデックス化のプロセスを監視およびトラブルシューティングするために使用されるロガー (ログ作成メカニズム) の概要を示します。
logger | レベル | 説明 |
|---|---|---|
| DEBUG | 既定では、DLQ の内容を 5 分ごとに記録しますが、DLQ が空でない場合に限ります。デッドレター キューの記録間隔 (ミリ秒) を更新することで、記録頻度を変更できます。 |
| DEBUG | 既定では、アセット インデックス レプリケーション統計を 5 分ごとに記録します。デッドレター キューの記録間隔 (ミリ秒) を更新することで、記録頻度を変更できます。 |
| DEBUG | すべてのレプリケーション ログを含みます。Assets のパフォーマンスの詳細 |
| DEBUG | 再インデックス化をログに記録します。 |