DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Elasticsearchの日次バックアップとリストア運用のベストプラクティス

この包括的なガイドを使用して、信頼性の高いElasticsearchの日次バックアップ戦略を確立します。永続的なリポジトリの設定方法、スナップショットライフサイクル管理（SLM）を使用した定期的なスナップショットの自動化、長期アーカイブのためのインデックスライフサイクル管理（ILM）の活用方法について学習します。この記事では、セキュリティ、パフォーマンスの調整、および定期的なリストアテストの重要な手順に関するベストプラクティスを詳しく説明し、いかなる状況下でもデータが保護され、復元可能であることを保証します。

Elasticsearchの日次バックアップとリストア運用のベストプラクティス

日次バックアップは、レプリカでは修正できない障害（誤った削除、不正なマッピング、データ破損、アップグレードの失敗、クラスタ全体の損失）からElasticsearchクラスタを保護します。レプリカは可用性を高めますが、スナップショットは既知の正常なコピーに戻ることを可能にします。

Elasticsearchの日次バックアップとリストア運用に関するこれらのベストプラクティスでは、リポジトリのセットアップ、スナップショットライフサイクル管理（SLM）、リストアテスト、およびインデックスライフサイクル管理（ILM）が適切に機能する場所について説明します。

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

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

スナップショットは2つの主要なコンポーネントをキャプチャします：

  1. インデックスデータ： 選択されたインデックスの実際のLuceneセグメント。
  2. クラスタ状態： メタデータ、永続設定、インデックステンプレート、パイプライン、ロール。

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

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

リポジトリタイプ

リポジトリタイプ 説明 最適な用途 要件
fs（共有ファイルシステム） すべてのマスターノードとデータノードからアクセス可能なローカルまたはネットワークマウントドライブ。 小規模クラスタ、迅速なローカルバックアップ。 elasticsearch.yml（path.repo）に登録する必要があります。
s3、azure、gcs クラウドストレージサービス。一部のディストリビューションとバージョンではこれらのリポジトリタイプがバンドルされていますが、それ以外の場合は、すべてのノードに対応するリポジトリプラグインをインストールする必要があります。 本番環境、ディザスタリカバリ。 バージョンに適したリポジトリサポートと適切なIAM/サービスプリンシパル認証情報。

例：S3リポジトリの登録

本番環境では、耐久性とオフサイト復旧のために、通常はクラウドストレージがより良い選択です。Elasticsearchバージョンのリポジトリサポートを確認し、認証情報を安全に設定してから、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による日次自動化の実装

手動スナップショットは1回限りの操作には許容されますが、定期的な日次バックアップはスナップショットライフサイクル管理（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 * * ?は毎日午前1時30分に実行）。使用量が少ない時間帯にスケジュールします。
  • include_global_state: false： 日次データバックアップの場合、リストア時に誤った状態のロールバックを防ぐために、クラスタ状態を除外するのが最善です。
  • retention： クリーンスケジュールを定義します。上記の例では、スナップショットを30日間保持し、少なくとも5つ、最大30つを維持します。

SLMの監視

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

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

3. インデックスライフサイクル管理（ILM）との統合

ログやメトリクスなどの大規模な時系列データの場合、インデックスライフサイクル管理（ILM）は、作成から削除までインデックスを管理します。ILMは日次のSLMスナップショットを置き換えるものではありませんが、完了したスナップショットポリシーと削除を調整するのに役立ちます。

ILMとデータティアリング

ILMが古いインデックスを削除する前に、削除フェーズでSLMポリシーの実行を待機させることができます。これにより、日次または長期スナップショットポリシーが、インデックスがクラスタから削除される前にデータをキャプチャする機会を得られます。

  1. 関連するインデックスパターンをスナップショットするSLMポリシーを作成します。
  2. ILM削除フェーズでwait_for_snapshotを使用してそのSLMポリシーを参照します。
...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

これにより、ILMがインデックスを削除する前に、指定されたSLMポリシーからのスナップショットが成功するのを待機します。データストリームを使用する場合は、ステージング環境でライフサイクルフローをテストして、スナップショットポリシーでカバーされるバッキングインデックスを把握してください。

目標が、古い検索可能データを削除する代わりに、より安価なストレージに保存することである場合は、コールドフェーズまたはフローズンフェーズの検索可能スナップショットアクションを検討してください。これは、単純なディザスタリカバリスナップショットとは異なるパターンです。

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

目標ごとに1つのライフサイクルパターンを使用します。SLMは復元可能なバックアップ、削除前のwait_for_snapshot、低コストの検索アクセスが必要な場合は検索可能スナップショットを使用します。

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 /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

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

セキュリティ

  • リポジトリアクセス： Elasticsearchがリポジトリにアクセスするために使用する認証情報が、リポジトリパスに対して最小権限の原則に従っていることを確認します。実際には、スナップショット管理には、特に保持ポリシーが古いスナップショットを削除する場合、所有するオブジェクトに対する読み取り、書き込み、一覧表示、および削除の権限が必要です。
  • 暗号化： サーバー側の暗号化（SSE-S3またはSSE-KMS）を有効にした安全なリポジトリ（S3など）を利用します。

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

スナップショットはI/O集中型になる可能性があります。スナップショットウィンドウ中にパフォーマンスの低下に気付いた場合は、リポジトリレベルでスナップショットトラフィックをスロットリングします。多くのリポジトリタイプでは、リポジトリを登録または更新する際の関連設定はmax_snapshot_bytes_per_secとmax_restore_bytes_per_secです。

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

indices.recovery.max_bytes_per_secはピアおよびスナップショットリカバリトラフィックを制御するため、シャードリカバリへの影響を理解している場合にのみ調整してください。可能であれば、スナップショットスケジュールをピーク時のインデックス作成および検索時間外に保ちます。

日次バックアップワークフロー

  1. 耐久性のあるリポジトリを設定： 本番環境にはクラウドストレージ（S3/Azure/GCS）を使用します。
  2. SLMポリシーを定義： SLMを使用してスナップショットをスケジュールし（例：毎日午前1時30分）、適切な保持ルールを設定します。
  3. ILMを調整（該当する場合）： 削除前のwait_for_snapshot、または低コストの検索可能な履歴のために検索可能スナップショットを使用します。
  4. ステータスを監視： _slm/policyおよび_slm/statusAPIを介して、SLMポリシーの実行を定期的に確認します。
  5. リカバリをテスト： 四半期または半年ごとに、分離された環境で完全なリストアを実行して、RTOの準備ができていることを検証します。

有用なバックアップとは、復元できるバックアップです。日次のSLMポリシーをシンプルに保ち、障害を監視し、チームがインシデント発生前に正確な手順を把握できるように、十分な頻度でリストアドリルをスケジュールします。