Searchable snapshots

検索可能なスナップショット

検索可能なスナップショットを使用すると、スナップショットを利用して、あまりアクセスされない読み取り専用データを非常にコスト効率よく検索できます。コールドおよびフローズンデータ層は、ストレージおよび運用コストを削減するために検索可能なスナップショットを使用します。

検索可能なスナップショットは、ホット層からロールオーバーした後にレプリカシャードの必要性を排除し、データを検索するために必要なローカルストレージを半分に削減する可能性があります。検索可能なスナップショットは、バックアップに使用するのと同じスナップショットメカニズムに依存しており、スナップショットリポジトリのストレージコストに対する影響は最小限です。

検索可能なスナップショットの使用

検索可能なスナップショットインデックスの検索は、他のインデックスの検索と同じです。

デフォルトでは、検索可能なスナップショットインデックスにはレプリカがありません。基盤となるスナップショットは耐障害性を提供し、クエリボリュームは低いため、単一のシャードコピーで十分と見込まれています。ただし、より高いクエリボリュームをサポートする必要がある場合は、index.number_of_replicasインデックス設定を調整してレプリカを追加できます。

ノードが失敗し、検索可能なスナップショットシャードを他の場所で回復する必要がある場合、Elasticsearchがシャードを他のノードに割り当てる間、クラスタの健康状態がgreenでない短い時間のウィンドウがあります。これらのシャードにヒットする検索は、シャードが健康なノードに再割り当てされるまで失敗するか部分的な結果を返す可能性があります。

通常、検索可能なスナップショットはILMを通じて管理されます。検索可能なスナップショットアクションは、coldまたはfrozenフェーズに達したときに、通常のインデックスを検索可能なスナップショットインデックスに自動的に変換します。また、マウントスナップショットAPIを使用して、既存のスナップショット内のインデックスを手動で検索可能にすることもできます。

複数のインデックスを含むスナップショットからインデックスをマウントするには、検索したいインデックスのみを含むスナップショットのクローンを作成し、そのクローンをマウントすることをお勧めします。マウントされたインデックスがある場合、スナップショットを削除しないでください。クローンを作成することで、バックアップスナップショットのライフサイクルを検索可能なスナップショットとは独立して管理できます。ILMを使用して検索可能なスナップショットを管理する場合、必要に応じてスナップショットのクローン作成を自動的に行います。

検索可能なスナップショットインデックスのシャードの割り当ては、通常のインデックスと同じメカニズムを使用して制御できます。たとえば、インデックスレベルのシャード割り当てフィルタリングを使用して、検索可能なスナップショットシャードをノードのサブセットに制限できます。

検索可能なスナップショットインデックスの回復速度は、リポジトリ設定max_restore_bytes_per_secおよびノード設定indices.recovery.max_bytes_per_secによって制限され、通常の復元操作と同様です。デフォルトではmax_restore_bytes_per_secは無制限ですが、indices.recovery.max_bytes_per_secのデフォルトはノードの構成に依存します。回復設定を参照してください。

検索可能なスナップショットインデックスとしてマウントされるスナップショットを取得する前に、インデックスをシャードごとに単一のセグメントに強制マージすることをお勧めします。スナップショットリポジトリからの各読み取りには時間がかかり、コストがかかります。セグメントが少ないほど、スナップショットを復元するために必要な読み取りが少なくなります。

検索可能なスナップショットは、大規模な履歴データのアーカイブを管理するのに理想的です。履歴情報は通常、最近のデータよりも頻繁には検索されないため、そのパフォーマンス上の利点のためにレプリカが必要ない場合があります。

より複雑または時間のかかる検索には、検索可能なスナップショットとともに非同期検索を使用できます。

検索可能なスナップショットで使用できるリポジトリタイプは次のとおりです：

• AWS S3
• Google Cloud Storage
• Azure Blob Storage
• Hadoop Distributed File Store (HDFS)
• 共有ファイルシステム（NFSなど）
• 読み取り専用HTTPおよびHTTPSリポジトリ

これらのリポジトリタイプの代替実装（たとえば、MinIO）を使用することもできますが、完全に互換性がある必要があります。リポジトリアナリシスAPIを使用して、検索可能なスナップショットとの使用に対するリポジトリの適合性を分析します。

検索可能なスナップショットの動作

インデックスがスナップショットからマウントされると、Elasticsearchはそのシャードをクラスタ内のデータノードに割り当てます。データノードは、指定されたマウントオプションに基づいて、リポジトリから関連するシャードデータをローカルストレージに自動的に取得します。可能な場合、検索はローカルストレージのデータを使用します。データがローカルに利用できない場合、Elasticsearchはスナップショットリポジトリから必要なデータをダウンロードします。

これらのシャードのいずれかを保持しているノードが失敗した場合、Elasticsearchは影響を受けたシャードを別のノードに自動的に割り当て、そのノードがリポジトリから関連するシャードデータを復元します。レプリカは必要なく、失われたシャードを復元するために複雑な監視やオーケストレーションは必要ありません。検索可能なスナップショットインデックスにはデフォルトでレプリカがありませんが、index.number_of_replicasを調整することでこれらのインデックスにレプリカを追加できます。検索可能なスナップショットシャードのレプリカは、検索可能なスナップショットシャードのプライマリと同様に、スナップショットリポジトリからデータをコピーすることによって回復されます。対照的に、通常のインデックスのレプリカはプライマリからデータをコピーすることによって復元されます。

マウントオプション

スナップショットを検索するには、最初にそれをローカルにインデックスとしてマウントする必要があります。通常、ILMがこれを自動的に行いますが、マウントスナップショットAPIを自分で呼び出すこともできます。スナップショットからインデックスをマウントするには、パフォーマンス特性とローカルストレージのフットプリントが異なる2つのオプションがあります：

• 完全にマウントされたインデックス

• Elasticsearchクラスタ内のスナップショットインデックスのシャードを完全にキャッシュします。ILMはhotおよびcoldフェーズでこのオプションを使用します。
  完全にマウントされたインデックスの検索パフォーマンスは通常、通常のインデックスと同等であり、スナップショットリポジトリにアクセスする必要が最小限であるためです。回復が進行中の場合、検索パフォーマンスは通常のインデックスよりも遅くなる可能性があります。なぜなら、検索にはまだローカルキャッシュに取得されていないデータが必要な場合があるからです。その場合、Elasticsearchは、進行中の回復と並行して、検索を完了するために必要なデータを積極的に取得します。ディスク上のデータは再起動を通じて保持され、ノードは再起動後にすでにノードに保存されているデータを再ダウンロードする必要はありません。ILMによって管理されるインデックスは、完全にマウントされるとrestored-でプレフィックスされます。

• 部分的にマウントされたインデックス
• スナップショットインデックスのデータの最近検索された部分のみを含むローカルキャッシュを使用します。このキャッシュは固定サイズであり、同じデータノードに割り当てられた部分的にマウントされたインデックスのシャード間で共有されます。ILMはfrozenフェーズでこのオプションを使用します。
  検索がキャッシュにないデータを必要とする場合、Elasticsearchはスナップショットリポジトリから不足しているデータを取得します。これらの取得を必要とする検索は遅くなりますが、取得されたデータはキャッシュに保存されるため、将来の類似の検索に対してより迅速に提供できます。Elasticsearchは、キャッシュからあまり使用されないデータを追い出してスペースを空けます。ノードが再起動されるとキャッシュはクリアされます。
  完全にマウントされたインデックスや通常のインデックスよりは遅いですが、部分的にマウントされたインデックスは、リポジトリ内のデータのレイアウトが検索のために大幅に最適化されているため、大規模なデータセットでも迅速に検索結果を返します。多くの検索は、結果を返す前に全体のシャードデータの小さなサブセットのみを取得する必要があります。ILMによって管理されるインデックスは、部分的にマウントされるとpartial-でプレフィックスされます。

インデックスを部分的にマウントするには、共有キャッシュが利用可能な1つ以上のノードが必要です。デフォルトでは、専用のフローズンデータ層ノード（data_frozenロールを持ち、他のデータロールを持たないノード）は、合計ディスクスペースの90％と100GBのヘッドルームを差し引いた合計ディスクスペースの大きい方を使用して共有キャッシュを構成しています。

専用のフローズン層を使用することは、運用使用に強く推奨されます。専用のフローズン層がない場合、1つ以上のノードでキャッシュのためのスペースを予約するxpack.searchable.snapshot.shared_cache.size設定を構成する必要があります。部分的にマウントされたインデックスは、共有キャッシュを持つノードにのみ割り当てられます。

• xpack.searchable.snapshot.shared_cache.size
• (静的) 部分的にマウントされたインデックスの共有キャッシュのために予約されたディスクスペース。合計ディスクスペースのパーセンテージまたは絶対バイト値を受け入れます。専用のフローズンデータ層ノードのデフォルトは、合計ディスクスペースの90%です。それ以外の場合は0bのデフォルトです。
• xpack.searchable.snapshot.shared_cache.size.max_headroom
• (静的、バイト値) 専用のフローズン層ノードの最大ヘッドルーム。xpack.searchable.snapshot.shared_cache.sizeが明示的に設定されていない場合、この設定のデフォルトは100GBです。それ以外の場合は-1（未設定）のデフォルトです。この設定は、xpack.searchable.snapshot.shared_cache.sizeがパーセンテージとして設定されている場合にのみ構成できます。

これらの設定がどのように連携して機能するかを示すために、専用のフローズンノードでの設定のデフォルト値を使用した2つの例を見てみましょう：

• 4000 GBのディスクは、3900 GBのサイズの共有キャッシュを生成します。4000 GBの90％は3600 GBで、400 GBのヘッドルームが残ります。デフォルトのmax_headroomである100 GBが適用され、その結果3900 GBになります。
• 400 GBのディスクは、360 GBのサイズの共有キャッシュを生成します。

#### Yaml
``````yaml
xpack.searchable.snapshot.shared_cache.size: 4TB
`

これらの設定は、data_frozenロールを持つノードでのみ構成できます。さらに、共有キャッシュを持つノードは、単一のdata pathしか持てません。

Elasticsearchは、検索可能なスナップショットシャードの回復を迅速化するために、.snapshot-blob-cacheという専用のシステムインデックスも使用します。このインデックスは、部分的または完全にマウントされたデータの上に追加のキャッシングレイヤーとして使用され、検索可能なスナップショットシャードを開始するために必要な最小限のデータを含みます。Elasticsearchは、このインデックスでもはや使用されないドキュメントを自動的に削除します。この定期的なクリーンアップは、次の設定を使用して調整できます：

• searchable_snapshots.blob_cache.periodic_cleanup.interval
• (動的) 定期的な.snapshot-blob-cacheインデックスのクリーンアップがスケジュールされる間隔。デフォルトは毎時(1h)。
• searchable_snapshots.blob_cache.periodic_cleanup.retention_period
• (動的) .snapshot-blob-cacheインデックスにおける古いドキュメントを保持するための保持期間。デフォルトは毎時(1h)。
• searchable_snapshots.blob_cache.periodic_cleanup.batch_size
• (動的) 定期的な.snapshot-blob-cacheインデックスのクリーンアップ中に一度に検索されてバルク削除されるドキュメントの数。デフォルトは100。
• searchable_snapshots.blob_cache.periodic_cleanup.pit_keep_alive
• (動的) 定期的な.snapshot-blob-cacheインデックスのクリーンアップ中に実行されるポイントインタイム保持リクエストに使用される値。デフォルトは10m。

検索可能なスナップショットでコストを削減

ほとんどの場合、検索可能なスナップショットは、レプリカシャードの必要性を排除し、ノード間でシャードデータをコピーする必要がなくなることで、クラスターの運用コストを削減します。ただし、環境内でスナップショットリポジトリからデータを取得するのが特に高価な場合、検索可能なスナップショットは通常のインデックスよりもコストがかかる可能性があります。使用する前に、運用環境のコスト構造が検索可能なスナップショットと互換性があることを確認してください。

レプリカコスト

耐障害性のために、通常のインデックスは複数のノードにわたって各シャードの冗長コピーを必要とします。ノードが失敗した場合、Elasticsearchは冗長性を使用して失われたシャードコピーを再構築します。検索可能なスナップショットインデックスはレプリカを必要としません。検索可能なスナップショットインデックスを含むノードが失敗した場合、Elasticsearchはスナップショットリポジトリから失われたシャードキャッシュを再構築できます。

レプリカがないため、あまりアクセスされない検索可能なスナップショットインデックスは、はるかに少ないリソースを必要とします。レプリカなしの完全にマウントされた検索可能なスナップショットインデックスを含むコールドデータ層は、通常のインデックスに同じデータを含む層の半分のノードとディスクスペースを必要とします。部分的にマウントされた検索可能なスナップショットインデックスのみを含むフローズン層は、さらに少ないリソースを必要とします。

データ転送コスト

通常のインデックスのシャードがノード間で移動されると、その内容はクラスタ内の別のノードからコピーされます。多くの環境では、ノード間でデータを移動するコストは重要であり、特に異なるゾーンにノードがあるクラウド環境で実行している場合は顕著です。対照的に、検索可能なスナップショットインデックスをマウントしたり、そのシャードの1つを移動したりする場合、データは常にスナップショットリポジトリからコピーされます。これは通常、はるかに安価です。

ほとんどのクラウドプロバイダーは、リージョン間で転送されるデータやプラットフォームから転送されるデータに対して高額な料金を請求します。スナップショットを、スナップショットリポジトリと同じリージョンにあるクラスターにのみマウントする必要があります。複数のリージョンでデータを検索したい場合は、複数のクラスターを構成し、検索可能なスナップショットの代わりにクロスクラスター検索またはクロスクラスター複製を使用してください。

検索可能なスナップショットのバックアップと復元

通常のスナップショットを使用して、検索可能なスナップショットインデックスを含むクラスターをバックアップできます。検索可能なスナップショットインデックスを含むスナップショットを復元すると、これらのインデックスは再び検索可能なスナップショットインデックスとして復元されます。

検索可能なスナップショットインデックスを含むスナップショットを復元する前に、元のインデックススナップショットを含むリポジトリを登録する必要があります。復元されると、検索可能なスナップショットインデックスは元のリポジトリから元のインデックススナップショットをマウントします。必要に応じて、通常のスナップショットと検索可能なスナップショットに別々のリポジトリを使用できます。

検索可能なスナップショットインデックスのスナップショットには、元のインデックススナップショットを識別するための少量のメタデータのみが含まれています。元のインデックスからのデータは含まれていません。バックアップの復元は、元のインデックススナップショットが利用できない検索可能なスナップショットインデックスを復元することに失敗します。

検索可能なスナップショットインデックスは通常のインデックスではないため、検索可能なスナップショットインデックスのスナップショットを取得するためにソース専用リポジトリを使用することはできません。

検索可能なスナップショットの信頼性

検索可能なスナップショットインデックス内のデータの唯一のコピーは、リポジトリに保存された基盤となるスナップショットです。このスナップショットを削除すると、データは永久に失われます。Elasticsearchが検索を高速化するために一部のデータをローカルストレージにキャッシュしている場合でも、このキャッシュされたデータは不完全であり、基盤となるスナップショットを削除すると回復に使用することはできません。たとえば：

• 検索可能なスナップショットがマウントされている間にリポジトリの登録を解除してはいけません。
• インデックスのいずれかが検索可能なスナップショットインデックスとしてマウントされている場合、スナップショットを削除してはいけません。このスナップショットには、データの唯一の完全なコピーが含まれています。これを削除すると、データは他の場所から回復できなくなります。
• 異なるクラスターが書き込みアクセスを持つリポジトリ内のスナップショットからインデックスをマウントする場合、他のクラスターがこれらのスナップショットを削除しないことを確認する必要があります。このスナップショットには、データの唯一の完全なコピーが含まれています。これを削除すると、データは他の場所から回復できなくなります。
• リポジトリが失敗したり、スナップショットの内容が破損したりし、以前の正常な状態に復元できない場合、データは永久に失われます。
  すべての主要なパブリッククラウドプロバイダーが提供するブロブストレージは、通常、障害や破損に対して非常に良い保護を提供します。独自のリポジトリストレージを管理する場合、その信頼性に対して責任を負う必要があります。