Elasticsearchデイリーバックアップとリストア運用のベストプラクティス

デイリーバックアップは、Elasticsearchのようなミッションクリティカルな分散システムにおいて、信頼性の高いデータ管理の基礎となります。Elasticsearchはレプリケーションを通じて高可用性を提供しますが、運用上のエラー、データ破損、壊滅的なシステム障害から保護するためには、信頼性の高いスナップショット戦略が不可欠です。

このガイドでは、ElasticsearchのSnapshot and Restore APIを使用した堅牢な自動デイリースナップショットバックアップを実装するためのベストプラクティスを詳述します。特に、Snapshot Lifecycle Management (SLM)による自動化、Index Lifecycle Management (ILM)との統合、および定期的なリストアテストという重要な要件に焦点を当てています。

Elasticsearchのスナップショットメカニズムを理解する

Elasticsearchのスナップショットは単なるファイルのコピーではなく、Luceneインデックスの内部構造を活用したインクリメンタルなものです。これは、最初のフルスナップショットの後、以降のスナップショットでは最後の成功したスナップショット以降に変更されたデータセグメントのみが保存されるため、時間とストレージの面で非常に効率的であることを意味します。

スナップショットは主に以下の2つのコンポーネントを捕捉します。
1. インデックスデータ: 選択されたインデックスの実際のLuceneセグメント。
2. クラスターステート: メタデータ、永続設定、インデックステンプレート、パイプライン、ロール。

1. スナップショットリポジトリの確立

スナップショットを取得する前に、スナップショットファイルが保存される安全な場所であるリポジトリを登録する必要があります。リポジトリの選択は、耐久性と回復速度にとって非常に重要です。

リポジトリの種類

リポジトリタイプ	説明	最適な用途	要件
`fs` (共有ファイルシステム)	すべてのマスターノードとデータノードからアクセス可能なローカルまたはネットワークマウントされたドライブ。	小規模クラスター、迅速なローカルバックアップ。	`elasticsearch.yml` (`path.repo`)に登録する必要がある。
`s3`、`azure`、`gcs`	クラウドストレージサービス (すべてのノードにそれぞれのプラグインのインストールが必要)。	本番環境、災害復旧。	プラグインのインストールと適切なIAM/サービスプリンシパル認証情報。

例: S3リポジトリの登録

本番環境では、耐久性とオフサイトリカバリのためにクラウドストレージが強く推奨されます。リポジトリプラグイン (例: repository-s3) をインストールし、その後API経由でリポジトリを登録する必要があります。

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

ヒント: 設定されたバケットまたはファイルシステムパスが安全であり、不変性（プロバイダーがサポートしている場合）を持ち、バックアップ専用に使用されていることを確認してください。

2. SLMによる日次自動化の実装

手動スナップショットは一度限りの操作には許容されますが、ルーチンなデイリーバックアップはSnapshot Lifecycle Management (SLM)を使用して自動化する必要があります。SLMは、スケジュールの定義、保持ポリシー、スナップショットの管理のために特別に設計されたElasticsearch内のネイティブなメカニズムです。

SLMポリシーの定義

標準的なデイリーポリシーでは、スケジュール、含める（または除外する）インデックス、およびスナップショットを保持する期間を定義します。

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?", 
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false 
  },
  "retention": {
    "expire_after": "30d", 
    "min_count": 5, 
    "max_count": 30 
  }
}

SLM設定の主なポイント:

schedule: Quartz cron構文を使用します（例: 0 30 1 * * ? は毎日午前01:30に実行）。使用量の少ない時間帯にスケジュールしてください。
include_global_state: false: 日次データバックアップの場合、リストア時の偶発的な状態ロールバックを防ぐために、クラスターステートを含めないことが最善であることが多いです。
retention: クリーニングスケジュールを定義します。上記の例では、スナップショットを30日間保持し、最低5個、最大30個が維持されるようにします。

SLMの監視

ポリシーが正常に実行されていることを確認するために、定期的にステータスをチェックしてください。

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. Index Lifecycle Management (ILM)との統合

大量の時系列データ（ログなど）の場合、Index Lifecycle Management (ILM)はインデックスの作成から削除までを管理します。長期的なアーカイブのために、デイリースナップショットはILMと統合する必要があります。

ILMとデータ階層化

永続的に削除される前、またはリソース集約型のコールド/フローズンティアに移動される直前にインデックスのスナップショットを取るのがベストプラクティスです。スナップショット操作をILMポリシーの削除フェーズに直接組み込むことができます。

ポリシーフェーズの定義: ILMポリシーにフェーズ (例: delete) を作成します。
スナップショットアクションの追加: リポジトリとスナップショット名のパターンを指定します。

...
"delete": {
  "min_age": "90d",
  "actions": {
    "forcemerge": {},
    "shrink": {},
    "rollover": {},
    "delete": {
      "snapshot": {
        "repository": "my_longterm_archive_repo",
        "name": "ilm-archive-{{index}}"
      }
    }
  }
}
...

これにより、90日以上前のデータがクラスターからインデックスが削除される前にアーカイブされ、高価なプライマリストレージに大量の古いデータを保持することなく、コンプライアンス要件を満たします。

4. リストアテストのベストプラクティス

バックアップルーチンは、実績のあるリカバリ戦略なしには不完全です。データ整合性を検証し、リカバリ時間目標 (RTO) を達成するために、リストアプロセスを定期的にテストする必要があります。

リストアテスト環境

本番クラスターに直接リストアしないでください。 本番環境のセットアップ（同じElasticsearchバージョン、ネットワークトポロジ）を模倣した専用のステージング環境またはテスト環境を使用してください。
頻度: 少なくとも四半期ごと、または主要なアップグレード/設定変更後にリストアテストを実施してください。

リストアの実行

リストアは特定のインデックス、またはクラスターステート全体を対象とすることができます。

ステップ1: スナップショットの詳細を取得

リストアする必要があるスナップショット名を特定します。

GET /_snapshot/my_s3_daily_repo/_all

ステップ2: リストア操作を実行

特定のインデックスをリストアするには、indicesパラメータを使用します。アクティブなインデックスとの競合を避けるために（特にテスト環境では）、リストア中にインデックスの名前を変更する必要があることがよくあります。

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

リストアの成功の検証

リストア後、インデックスがグリーン状態であり、ドキュメント数が元のデータソースと一致することを確認してください。

GET /restored-logstash-2024-05-01/_count

5. セキュリティとパフォーマンスに関する考慮事項

セキュリティ

リポジトリアクセス: Elasticsearchがリポジトリにアクセスするために使用する認証情報（例: S3認証情報）が最小権限の原則に準拠していることを確認してください。つまり、スナップショットプロセス中は書き込みアクセスのみ、リストア中は読み取りアクセスのみを持つべきです。
暗号化: サーバーサイド暗号化（SSE-S3またはSSE-KMS）が有効になっている安全なリポジトリ（S3など）を利用してください。

パフォーマンススロットリング

スナップショットはI/O負荷が高い場合があります。デフォルトでは、Elasticsearchは同時セグメントアップロードを制限します。スケジュールされたスナップショット期間中にパフォーマンスの低下に気づいた場合、スロットリング設定を調整できます（ただし、あまりにも寛容に設定しないようにしてください）。

PUT /_cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "100mb", 
    "snapshot.max_bytes_per_sec": "100mb"
  }
}

警告: max_bytes_per_sec を高すぎると、クライアントクエリやインデックス作成操作に対するクラスターの応答性に悪影響を与える可能性があります。

日次バックアップワークフローの概要

耐久性のあるリポジトリの構成: 本番環境ではクラウドストレージ（S3/Azure/GCS）を使用してください。
SLMポリシーの定義: SLMを使用してスナップショットをスケジュールし（例: 毎日午前1時30分）、適切な保持ルールが設定されていることを確認してください。
ILMとの統合（該当する場合）: 削除前にILMを使用して古いインデックスを長期リポジトリにアーカイブしてください。
ステータスの監視: _slm/policy および _slm/status APIを介してSLMポリシーの実行を定期的に確認してください。
リカバリテスト: 四半期ごとまたは半年に一度、隔離された環境に完全なリストアを実行し、RTOの準備ができていることを検証してください。