Amazon OpenSearch Service クラスターで Deleted Documents メトリクスが非常に高いのはなぜですか?

所要時間2分

Amazon OpenSearch Service クラスターでドキュメントを削除しましたが、ディスク領域が解放されません。

簡単な説明

OpenSearch Service では、DeletedDocuments メトリクスは、削除対象としてマークされたドキュメントの数を示すカウンターです。DeletedDocuments メトリクスは、削除リクエストが処理された後に増加し、クラスター内でインデックスセグメントがマージされた後に減少します。

OpenSearch Service は、マージポリシー設定を使用して merge API オペレーションを自動的に実行します。マージの際、インデックスサイズを維持するために、小さいセグメントは大きなセグメントにマージされます。削除のマークが付けられたドキュメントも消去され、追加のディスク領域が解放されます。

ディスク容量を直ちに解放するために、個々のドキュメントを削除する代わりにインデックスを削除することができます。または、force merge API と only_expunge_deletes パラメータを使用して、インデックス内の削除されたドキュメントをクリアすることもできます。

クラスターのディスク容量を解放しつつ、インデックスメタデータを維持するには、次のアプローチを検討してください。

削除されたドキュメントの数を確認します。
ドキュメントのサイズを確認します。
削除されたドキュメントを消去します。
OpenSearch Service ドメインにストレージ領域を追加します。

解決方法

削除されたドキュメントの数を確認する

OpenSearch Service クラスターで削除されたドキュメントの数を確認するには、cluster stats API を実行します。cluster stats API コールから取得した値は、クラスターの DeletedDocuments メトリクスに表示されます。出力は、クラスターに存在するすべてのインデックスについて、削除されたドキュメントの合計を返します。この数は、レスポンス出力の [docs.deleted フィールドを使用して確認できます。

例えば、クラスターに 3 つのインデックス (index1、index2、index3) がある場合、index stats API コールを実行します。

GET index1/_stats
...
"docs": {
     "count": 100,
     "deleted": 1
}
... 
GET index2/_stats
...
"docs": {
     "count": 100,
     "deleted": 5
}
...
GET index3/_stats
...
"docs": {
     "count": 100,
     "deleted": 8
}
...

cluster stats API コールは、クラスターに存在するすべてのインデックスの [docs.deleted] フィールドを追加します。

...
"docs": {
     "count": 1227677521,
     "deleted": 14
}
...

index2 を削除すると、cluster stats API コールは index1 と index3 の値のみを計算します。

GET _cluster/stats
...
"docs": {
     "count": 1227677521,
     "deleted": 9
}

セグメントがマージされ、index2 のインデックスメタデータが消去されます。その結果、DeletedDocuments メトリクス値は 9 に減少しました。

ドキュメントのサイズを確認する

インデックスのドキュメントサイズと数を確認するには、cat indices API を使用します。新しいドキュメントが OpenSearch Service クラスターの既存のドキュメントと同じサイズであることを確認します。同じドキュメントサイズを使用すると、削除されたドキュメントが余計なディスク容量を占有しないようにできます。

削除されたドキュメントを消去する

手動でディスク容量を解放するには、only_expunge_deletes パラメータを [true] に設定して force merge API を実行します。

POST /<index-name>/_forcemerge?only_expunge_deletes=true

注: このオペレーションは、削除対象としてマークされたドキュメントを含むセグメントのみを削除します。

その結果、force merge によって使用されているディスク容量が減少します。新しいセグメントが作成されると、古いセグメントが削除され、新しいセグメントには削除対象としてマークされたドキュメントは含まれなくなります。削除されたドキュメントの詳細については、Elasticsearch ウェブサイトの Lucene's handling of deleted documents を参照してください。

ただし、強制マージオペレーションを実行するときは、以下の点に注意してください。

十分な空きストレージ容量がある場合にのみ、クラスターで強制マージを実行します。このアクションは、リソースを大量に使用するオペレーションです。
強制マージ操作は、I/O 集約型のプロセスをトリガーし、マージが完了するまでクラスターへのすべての新しいリクエストをブロックします。
強制マージオペレーションは、インデックスに追加データが書き込まれていない場合にのみ、読み取り専用インデックスに対して呼び出す必要があります。読み取り/書き込みインデックスに対して強制マージを呼び出すと、非常に大きなセグメントが生成される場合があります (セグメントあたり 5 GB 超)。このような場合、自動結合ポリシーは、ほとんど削除されたドキュメントがセグメントに含まれるまで、これらの非常に大きなセグメントを将来のマージの対象とはみなしません。その結果、ディスク使用量が増加し、検索パフォーマンスが低下します。

また、delete by query API または delete API を使用して、クラスター内のドキュメントを手動で削除することもできます。

ディスク容量を直ちに解放する

直ちにディスク容量を解放するには、delete index API を使用します。インデックスを削除しても、削除マーカーは作成されません。代わりに、delete index API はインデックスメタデータをクリアし、ディスク領域はすぐに再利用されます。解放されたディスク領域は、DeletedDocuments メトリクスに反映されます。

注: 使用されていない古いインデックスを削除するのがベストプラクティスです。アクティブなインデックスを削除する場合は、インデックスの自動作成をブロックしてください。詳細については、Elasticsearch ウェブサイトの「Automatically create data streams and indices」(データストリームとインデックスの自動作成) を参照してください。