【ITニュース解説】15-Minute RPO to 7-Year Retention: Elasticsearch Backups on S3 with SLM (No Scripts, No Keys)

システムエンジニアを目指す皆さんにとって、データのバックアップは非常に重要なテーマの一つだ。ここでは、大量のデータを扱う際に用いられるElasticsearchというデータベースのバックアップについて、AWSのクラウドサービスを使いながら、どのように効率的かつ安全に実現するかを具体的に解説する。特に、面倒なスクリプトを書かずに自動化し、さらにセキュリティリスクとなりうるアクセスキーを一切使わない方法に焦点を当てる。

私たちが考えるバックアップには、常に三つの重要な問いがある。一つ目は「どれくらいのデータを失うことを許容できるか」、これはRPO（目標復旧時点）と呼ばれるものだ。例えば、15分間隔でバックアップを取っていれば、最大でも15分前までのデータまでしか失わないと見込める。二つ目は「どれくらい昔のデータまで遡って復元できるか」、これはデータの保持期間に関わる。そして三つ目は「そのバックアップ作業は何を使って認証されるのか」というセキュリティの問いだ。この記事で紹介するシステムは、これらの問いに明確に答えることができる。

Elasticsearchは、ログデータやイベントデータのような、時々刻々と発生する大量のデータを高速に検索・分析するのに長けているデータベースだ。このElasticsearchがAmazon EC2という仮想サーバー上で動いている場合、そのバックアップ先として最適なのがAmazon S3（Simple Storage Service）だ。S3はインターネット経由でどんな種類のデータでも保存できる、非常に耐久性が高く安定したクラウドストレージサービスで、ここでは「ただの、堅牢なデータ保存場所」として利用される。S3自身に複雑なルールを設定するのではなく、Elasticsearch側でバックアップの管理をすべて行うのがポイントだ。

このバックアップ戦略の核心は、Elasticsearchに標準搭載されているSLM（Snapshot Lifecycle Management）という機能にある。SLMは、定期的にElasticsearchの「スナップショット」（データベース全体のコピー、つまりバックアップ）を作成し、古くなったスナップショットを自動的に削除してくれる。これにより、バックアップ作業のスケジュール管理やライフサイクル管理といった面倒な作業を、手動のスクリプトなしで自動化できる。これが「No Scripts」を実現する主要な要素だ。

次に、「No Keys」（アクセスキーなし）を実現する方法だ。AWSでは、サービスやリソースにアクセスするために認証情報が必要になる。通常はアクセスキーとシークレットキーという情報を使うが、これらは漏洩すると非常に危険なため、できるだけ使わないのがベストプラクティスとされている。ここでは、EC2インスタンスプロファイルとIAMロールという仕組みを利用する。EC2インスタンスプロファイルは、EC2インスタンス（仮想サーバー）に一時的な認証情報を提供する特別な「身分証明書」のようなものだ。このインスタンスプロファイルに、S3へのアクセスを許可するIAMロールを紐付けることで、Elasticsearchが動作しているEC2インスタンスが、安全かつ自動的にS3へアクセスできるようになる。Elasticsearchのキーストア（秘密情報を保存する場所）に直接アクセスキーを保存する必要がなく、セキュリティが大幅に向上する。IAMロールには、S3のバケット（データを保存する大枠）をリスト表示したり、S3バケット内のオブジェクト（ファイル）を読み書き・削除したりするための具体的な権限が設定される。

このシステムでは、バックアップの頻度と保持期間が異なる四つの階層を設定する。一つ目は「15分間隔」のバックアップで、7日間保持する。これは主に、最も重要で損失が許されない「クリティカルなアプリケーションのインデックス」（特定の種類のデータ群）のみを対象とする。RPOを極限まで短くしたい場合に有効だ。二つ目は「1時間間隔」のバックアップで、35日間保持する。こちらは、すべてのインデックス（データ全体）と、Elasticsearchクラスタの構成情報も含む。日常的なデータ復旧に利用される。三つ目は「1ヶ月に一度」のバックアップで、約13ヶ月間保持する。これもすべてのデータとクラスタ状態を含む。四つ目は「1年に一度」のバックアップで、約7年間という長期にわたって保持する。これもすべてのデータとクラスタ状態を含む。このように、異なる要件に合わせて複数のバックアップポリシーを設定することで、必要な時に必要な粒度でデータを復元できるようになる。これらのバックアップは、S3バケット内に「15min」「daily」「monthly」「yearly」といったフォルダ（パス）に分けて保存される。

具体的な設定手順を見ていこう。まずIAM設定として、EC2インスタンスにS3へのアクセス権限を与えるためのIAMロールとインスタンスプロファイルを作成し、Elasticsearchが動くすべてのEC2ノード（データノード、マスターノード、Kibanaノードなど）に割り当てる。次に、ElasticsearchにS3リポジトリプラグインをインストールし、S3バケット内の各フォルダ（15min, dailyなど）をそれぞれ独立したバックアップリポジトリとして登録する。最後に、SLMポリシーを作成する。各ポリシーには、スナップショットを作成するスケジュール（例: 0 5/15 * * * ? は毎時5分から15分ごとに）、保存先のリポジトリ、バックアップの対象（特定のインデックスか全てか、クラスタ状態を含めるか）、そして保持期間（例: 7日後に期限切れ、最低10個のスナップショットを保持）を設定する。

この運用ではいくつかの注意点がある。S3のライフサイクルルールを使って自動的に古いファイルを削除する機能があるが、これを使わないのが非常に重要だ。Elasticsearchのスナップショットは、増分バックアップとして機能し、複数のスナップショット間で同じファイルを共有することがある。そのため、S3側でファイルの年齢だけで削除してしまうと、他のスナップショットが参照しているファイルを消してしまい、バックアップデータが破損するリスクがある。SLMはどのファイルがまだ必要かを認識しているため、削除はSLMに任せるべきだ。また、SLMはデフォルトで15分未満のスケジュールを拒否する設定になっているため、それよりも短いRPOが必要な場合は、スナップショットではなくレプリケーション（リアルタイム複製）などの別の方法を検討する必要がある。さらに、Elasticsearchノードはすべて同じインスタンスプロファイルを持つ必要がある。どれか一つでも設定が間違っていると、リポジトリの登録が失敗することがあるため、注意が必要だ。複数のSLMポリシーのスケジュールが同じ時間に集中しないよう、開始時間をずらすといった工夫も有効だ。

いざデータ復旧が必要になった際には、まず新しい名前でインデックスを復元し、元のデータと比較して内容を確認するのが安全な方法だ。完全にクラスタ全体を復旧する場合は、復旧先の既存インデックスを閉じるか削除してから、名前の変更なしで復元を行う。

この自動化された、セキュリティの高いバックアップシステムは、日々の運用負荷を減らし、万が一のデータ損失時にも迅速かつ確実に復旧できる安心感を提供する。そして、このバックアップシステムが本当に機能するかを確認するために、定期的にバックアップからのリストア訓練を実施することが何よりも重要だ。バックアップは、実際に復元できて初めて意味があるからだ。