アセットとメモリの要件

インスタンスが大きくなるにつれて、インメモリ インデックスには時間の経過とともにより多くの Java 仮想マシン (JVM) メモリが必要になる可能性があります。アセットで使用する予定のデータ量を Jira が処理できるように設定されていることをご確認ください。アセットのメモリに関する推奨事項をご確認ください。

アセットのインデックス化の仕組み

アセットでは、インデックス化はインメモリ キャッシュ システムである Google の Guava Cache によって管理されます。このシステムでは、アセット データの種類が異なれば使用するインデックスも異なり、それぞれが特定のデータ カテゴリ向けに最適化されています。このアプローチでは、データが複雑になっても、システムは応答性と効果を維持します。Google の Guava Cache について詳細をご確認ください。

インデックス化されたフラグ

インデックス化されたフラグは、資産の特定の属性を検索および取得する目的でインデックスに含めるかどうかを決定する設定です。アセットでは、テキスト領域を除くすべての属性が既定でインデックス化されます。

特定の属性をインデックスから削除するには、その属性のインデックス化されたフラグを無効にします。これはメモリ消費量の削減に役立ちますが、属性をデータベースから直接取得する必要があるため、検索やインポートが遅くなる可能性があります。属性の設定について詳細をご確認ください。

フリー テキスト インデックス

アセットのフリー テキスト インデックスは JiraLocalHome/caches/insight_indexes/freetext/directory に保存され、スキーマごとに 1 つのインデックスが保持されます。アセットでは毎晩深夜に、フリー テキスト インデックスを再作成する定期ジョブが自動的に実行されます。現在、このジョブを無効にするオプションはありません。さらに、手動でインデックス再作成が実行されるたびに、フリー テキストのインデックス再作成がトリガーされます。この設定により、インデックス化は最新の状態に保たれますが、インデックス再作成のスケジュールを管理する際の柔軟性が制限される可能性があります。

クラスタリングとレプリケーション

クラスター環境では、各ノードが独自のインデックスを保持しているため、すべてのノードが現在のデータの状態を認識できるように、変更をノード間でレプリケートする必要があります。このレプリケーション プロセスは、ネットワークの中断、高負荷 (インポート中など)、および一般的なパフォーマンス上の課題に対処する必要があるため、複雑です。レプリケーションは、オブジェクトが変更されるたびに行われます。

Jira Service Management 5.8.0 以降では、アセットでの ADD、UPDATE、REMOVE オブジェク操作の無効化通知には、オブジェクト インデックスのクラスター メッセージの代わりに Atlassian Cache のノード間無効化が使用されます。その他すべての操作には、引き続きクラスター メッセージ アプローチが使用されます。 アセットのパフォーマンス改善について詳細をご確認ください。

レプリケーション フロー

Replication includes the following object operations: ADD, UPDATE, and REMOVE. The CacheMessage includes:

• インデックス タイプ

• 操作のタイプ (ADD、UPDATE、REMOVE など)

• インデックスで更新するエンティティの 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 を再生するノードです。

アセットのインデックス再作成

時々、アセット データがデータベースと同期しなくなることがあります。これは、データベースが直接変更されたり、インデックスの複製プロセスが失敗した場合に発生する可能性があります。すべてを復元するには、アセットのインデックスを再作成する必要があります。インデックスの再作成には、メモリ内のデータをすべて削除し、データベースから新しいデータを引き出すことが含まれます。次の再インデックス アクションを実行できます。

• クリーンな再インデックス化では、すべてのノードですべてのオブジェクトがインデックスから削除されて、その後再びインデックス化されます。これは、最新の状態のインデックスが必要な場合に推奨されます。インデックス化の進行中は、その処理を取り消したり、オブジェクトを検索またはフィルタリングしたりすることはできません。この再インデックス化により、キャッシュに保存されているすべての ID が削除されます。

• 再インデックス化 (標準的な再インデックス化) では、すべてのオブジェクトをインデックスに残した上で、Assets が再度インデックスを作成します。処理中もオブジェクトを検索できます。この再インデックス化では ID が保持され、すでにキャッシュにある ID のデータのみが取得されます。

クリーンなインデックス再作成の実行中に、各タイプのローカル インデックスがクリアされ、インデックスのコピーを削除するように求めるメッセージがすべてのノードに送信されます。このメッセージには、削除するインデックスのタイプ (オブジェクトなど) と REMOVE_ALL 操作が含まれています。インデックス再作成を処理しているノードは、インデックスの再構築を開始します。このプロセスで使用されるスレッドの数は、アセット設定ページのアセットの並列処理プロパティを調整することで設定できます。次に、すべてのノードがインデックスのローカル コピーを削除して、レプリケーション プロセスによってインデックスを再構築します。

ロックの適用

再インデックス化の間は、再インデックス化を実行しているノードで Assets を使用できません。クリーンな再インデックス化の場合、クラスター全体で Assets を使用できません。これを管理するために、アセット データが変更されないようにロックをかけています。再インデックス化が完了すると、アセットのロックが解除されます。

スタートアップ

起動時に、アセットのインデックス再作成が開始され、インデックスが復元されます。

構成

アセットのグローバル Jira 設定にアクセスするには、次の手順に従います。

1. [管理] > [アプリの管理] の順に移動します。

2. [アセット] セクションで、[アセット設定] に移動します。

3. アセット設定ページの下部で、[設定を編集] を選択します。
4. [一般アセット設定] セクションに移動し、必要な設定を変更します。

インデックス サイズの制限

アセット インデックスのオブジェクト数を制限して、メモリ消費量を減らすことができます。ただし、インデックスにないオブジェクトはデータベースから直接クエリされるため、パフォーマンスに影響します。

トラブルシューティング

インデックス作成の問題が発生した場合は、以下の情報を参照してください。

不整合な状態のインデックス再作成

場合によっては、データベース内のデータが不整合な状態になってしまうことがあります。この場合、データをインデックスで参照できなくなり、Assets アプリケーションで表示しようとすると問題が発生する可能性があります。

Jira Service Management 10.1 以降では、これらのエラーはアセット インデックス UI とログに表示されます。アセット インデックスのトラブルシューティングの詳細

アトラシアンのプロファイリングとメトリック

Assets は、アセットのレプリケーション統計を監視するために使用できるいくつかの Java Management Extensions (JMX) メトリックを収集して公開します。JMX インターフェイスを使用したライブ モニタリングの詳細

ログ

以下に、Assets でレプリケーションと再インデックス化のプロセスを監視およびトラブルシューティングするために使用されるロガー (ログ作成メカニズム) の概要を示します。