Elasticsearch:検索可能スナップショット

制限

アーカイブデータノードの有効化

検索可能スナップショットを使用するには、Alibaba Cloud Elasticsearch インスタンスでアーカイブデータノードを有効にする必要があります。アーカイブデータノードは、検索可能スナップショットのコンピューティングレイヤーであり、インデックスのメタデータを維持し、ローカルキャッシュを管理し、Alibaba Cloud OSS からデータブロックをオンデマンドで取得します。

1. Alibaba Cloud Elasticsearch コンソールにログインします。

2. インスタンスに応じて、以下の手順に従ってください。

   • 新しい 8.17.0 インスタンスの場合：インスタンス作成ページで、バージョン 8.17.0 を選択します。インスタンス仕様セクションで、アーカイブデータノード を選択し、ノード数と仕様を設定します。

3. ノード仕様を選択します。

   データは Alibaba Cloud OSS に保存されるため、アーカイブデータノードには大きなローカルディスクは必要ありません。キャッシュヒット率を向上させるために、十分なメモリを設定することを推奨します。推奨構成：4 コア、16 GB メモリ以上、500 GB 以上のディスク (効率的なクラウドディスクまたは ESSD)。

4. 購入を確定し、変更が完了するのを待ちます。アーカイブデータノードの準備が完了すると、検索可能スナップショット機能はデフォルトで有効になり、追加の操作は不要です。

OSS スナップショットリポジトリの構成

Alibaba Cloud Elasticsearch には repository-oss プラグインがプリインストールされています。プラグインをインストールすることなく、Alibaba Cloud OSS をスナップショットリポジトリとして使用できます。

Kibana の Dev Tools で、次のコマンドを実行して OSS スナップショットリポジトリを登録します。

PUT _snapshot/my_oss_repo
{
  "type": "oss",
  "settings": {
    "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
    "access_key_id": "<your_access_key_id>",
    "secret_access_key": "<your_secret_access_key>",
    "bucket": "<your_bucket_name>",
    "base_path": "es_snapshots",
    "compress": true,
    "chunk_size": "500mb"
  }
}

リポジトリの接続を確認します。

POST _snapshot/my_oss_repo/_verify

成功したレスポンスにはクラスターノードがリストされ、必要な読み取りおよび書き込み権限で Alibaba Cloud OSS に接続されたことが確認されます。OSS プラグインのパラメーターの完全なリストについては、「elasticsearch-repository-oss」をご参照ください。

スナップショットの作成とマウント

PUT _snapshot/my_oss_repo/snapshot_20260227
{
  "indices": "logs-2025-*",
  "ignore_unavailable": true,
  "include_global_state": false
}

GET _snapshot/my_oss_repo/snapshot_20260227/_status

POST logs-2025-01-01/_doc
{ "message": "test log data 01", "level": "info", "timestamp": "2025-01-01T10:00:00" }

POST logs-2025-01-02/_doc
{ "message": "test log data 02", "level": "warn", "timestamp": "2025-01-02T10:00:00" }

POST logs-2025-01-03/_doc
{ "message": "test log data 03", "level": "error", "timestamp": "2025-01-03T10:00:00" }

POST logs-2025-01-04/_doc
{ "message": "test log data 04", "level": "info", "timestamp": "2025-01-04T10:00:00" }

POST logs-2025-01-05/_doc
{ "message": "test log data 05", "level": "debug", "timestamp": "2025-01-05T10:00:00" }

POST _snapshot/my_oss_repo/snapshot_20260227/_mount?storage=shared_cache&wait_for_completion=true
{
  "index": ".ds-logs-2025-01-01-2026.03.03-000001",
  "renamed_index": "frozen-logs-2025-01-01",
  "index_settings": {
    "index.number_of_replicas": 0
  },
  "ignore_index_settings": ["index.refresh_interval"]
}

GET frozen-logs-2025-01-01/_search
{
  "query": {
    "match": {
      "message": "error"
    }
  }
}

GET logs-2025-*,frozen-logs-2025-*/_search
{
  "query": {
    "range": {
      "timestamp": {
        "gte": "2025-01-01",
        "lt": "2025-02-01"
      }
    }
  }
}

DELETE frozen-logs-2025-01-01

POST _snapshot/my_oss_repo/snapshot_20260227/_restore
{
  "indices": ".ds-logs-2025-01-01-2026.03.03-000001",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1"
}

ILM によるデータライフサイクルの自動化

インデックスライフサイクル管理 (ILM) ポリシーを使用して、インデックスを Frozen 階層に自動的に移行します。次のポリシーは、完全な Hot → Warm → Frozen → Delete のライフサイクルを実装します。インデックスが Frozen フェーズに入ると、ILM は自動的に Alibaba Cloud OSS にスナップショットを作成し、それを部分マウントモードでマウントします。これらはすべて手動介入なしで行われます。

PUT _ilm/policy/logs_lifecycle_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "frozen": {
        "min_age": "90d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_oss_repo"
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

ライフサイクルフェーズの概要：

仕組み

検索可能スナップショットは、アーカイブデータノード (コンピューティングレイヤー) と Alibaba Cloud OSS (ストレージレイヤー) が連携する、ストレージとコンピューティングの分離アーキテクチャを使用しています。

• Alibaba Cloud OSS は、永続的なストレージレイヤーとして機能し、スナップショットリポジトリとして動作します。すべてのスナップショットデータは Alibaba Cloud OSS に保存され、独自の冗長性を利用してデータの信頼性を確保します。これにより、Elasticsearch でのレプリカシャードが不要になります。

• アーカイブデータノードはコンピューティングレイヤーであり、クエリリクエストの受信とデータアクセスの調整を担当します。各ノードには、3 つの主要なコンポーネントが含まれています。

  • メタデータ：インデックス構造とシャードマッピング情報を保存し、検索可能スナップショットインデックスの論理ビューを維持します。

  • 共有キャッシュ：頻繁にアクセスされるデータブロックをキャッシュします。このキャッシュは、同じノード上の検索可能スナップショットインデックスのすべてのシャードで共有されます。

  • クエリエンジン：クエリリクエストを受信し、キャッシュヒットを確認し、ミスが発生した場合はオンデマンドで Alibaba Cloud OSS からデータブロックを取得します。

データフローは、書き込みパスとクエリパスに分かれています。

• 書き込みパス: 手動アクションまたは ILM ポリシーにより、インデックスは Alibaba Cloud OSS にスナップショット化されます。storage=shared_cache パラメーターでマウントされると、インデックスは部分マウントモードになり、データは Alibaba Cloud OSS に残ったまま、アーカイブデータノードはメタデータのみをロードします。

• クエリパス：アーカイブデータノードは、まずローカルの共有キャッシュで必要なデータブロックを確認します。キャッシュヒットの場合、結果を直接返し、パフォーマンスはローカルデータと同等です。キャッシュミスの場合、必要なデータブロックを Alibaba Cloud OSS から取得し、結果を返し、将来のクエリのためにデータをキャッシュします。

共有キャッシュは、デフォルトでノードの総ディスク容量の 90% (または総容量から 100 GB を引いた値のいずれか小さい方) に設定されます。Least Recently Used (LRU) ポリシーを使用して、コールドデータブロックを追い出します。

Elasticsearch は、アクセス頻度に基づいてデータを複数の階層に分類します。検索可能スナップショットは、これらのうち最もコスト効率の高い Frozen 階層を提供します。

検索可能スナップショットは、次のメカニズムを通じてコストを削減します。

• レプリカシャードの排除：データの信頼性は Alibaba Cloud OSS のマルチレプリカメカニズムによって保証されるため、レプリカシャードは不要になります。これにより、ストレージ要件が 50% 削減され、アベイラビリティゾーン間のトラフィックコストがなくなります。

• ストレージとコンピューティングの分離：すべてのデータは Alibaba Cloud OSS に保存されます。OSS の単価はクラウドディスクストレージよりもはるかに低く (多くの場合 10 倍以上)、アーカイブデータノードはメタデータとホットデータキャッシュのみを保存します。

• 非常に高いデータ密度比：アーカイブデータノードは、1:1500 のメモリ対データ比を達成できます。64 GB のメモリを持つノードは、約 100 TB のアーカイブデータを管理できますが、Warm 階層の同じリソースでは約 10 TB しかサポートできません。

ユースケース

• ログのアーカイブ：古いログを Frozen 階層に移行して、検索機能を維持しながらストレージコストを削減します。

• コンプライアンスと監査：コンプライアンス目的でデータを低コストで長期保存し、オンデマンドで取得します。

• 履歴データ分析：高価な高性能ストレージを占有することなく、アクセス頻度の低い履歴データを分析します。

関連ドキュメント

• Elasticsearch 検索可能スナップショット公式ドキュメント

• Mount Snapshot API

• ILM Searchable Snapshot Action

• Alibaba Cloud OSS Snapshot Repository Plugin

• Alibaba Cloud Elasticsearch インスタンスのノード構成