Bering Note – formerly 流沙河鎮

情報技術系のこと書きます。

OpenSearchCon North America 2025「OpenSearchのSnapshotをマスターする：基本から応用まで」- Ashish Singh & Chaitanya KSR, AWS

OpenSearchCon North America 2025のセッション「Mastering OpenSearch Snapshots: From Basics To Advanced Strategies - Ashish Singh & Chaitanya KSR」をまとめます。

www.youtube.com

スピーカー

Ashish Singh - OpenSearchCon North America 2025
Ashish Singh氏はAmazon Web ServicesのSenior Software Development Engineerで、OpenSearch Serviceチームに所属しています。9年以上にわたるソフトウェア開発の経験を持ち、特に分散システムに注力してきました。OpenSearchにおいては、remote store機能の開発に貢献し、データの耐久性とストレージ機能の改善に取り組んでいます。KafkaやRedisといった分散プラットフォームでの経験も、OpenSearchの発展に活かされています。
Chaitanya KSR - OpenSearchCon North America 2025
Chaitanya KSR氏はAmazon Web ServicesのSenior Software Engineerで、10年以上にわたってスケーラブルなクラウドネイティブシステムの構築に携わってきました。分散コンピューティング、AWSインフラストラクチャ、そしてゼロからのサービス開発を専門としています。エンジニアリングリーダーシップにも情熱を注いでおり、システム設計とDevOpsのベストプラクティスについてチームのメンタリングを積極的に行っています。

なぜスナップショットが必要なのか


OpenSearchを運用していると、避けられない現実に直面します。それはハードウェアの故障です。どんなに信頼性の高いハードウェアを購入しても、インスタンスやディスクはいつか必ず故障します。この避けられない障害によってデータが失われる可能性があるため、データの保護が不可欠になります。
さらに深刻な問題として、サイレントデータ破損があります。ディスクの劣化やメモリ上でのビットフリップによって、気づかないうちにデータが破損することがあります。これらは検出が困難で、発見した時にはすでに手遅れになっているケースも少なくありません。
そして人的ミスも無視できません。SREやエンジニアが誤ってデータを削除してしまうことは、実際の運用現場では珍しいことではありません。どれだけ注意深く作業していても、ヒューマンエラーは完全には防げません。これらすべての障害シナリオから保護するために、スナップショットという仕組みが必要不可欠なのです。

スナップショットの重要性は障害対策だけではありません。クラスター間でのデータ移行においても重要な役割を果たします。あるクラスターから別のクラスターへデータを移行する際、スナップショットは最も信頼性の高い方法の一つです。特にバージョンアップグレードを行う際には、新しいバージョンで既存のデータが正しく動作するかを事前にテストできるため、本番環境のアップグレードのリスクを大幅に軽減できます。
コンプライアンスとガバナンスの観点からも、スナップショットは欠かせません。多くの組織では規制要件により、データを数日、数ヶ月、時には数年間保持する必要があります。スナップショットはこうした長期データ保持の要件を効率的に満たす手段となっています。
そして最も重要な活用方法の一つが、災害復旧アーキテクチャの構築です。スナップショットとリストアを組み合わせることで、比較的シンプルに災害復旧の仕組みを実装できます。これについては後ほど詳しく説明していきます。つまりスナップショットは単なるバックアップツールではなく、データのレジリエンシー戦略全体を支える重要な基盤なのです。

従って、スナップショットは単なるバックアップツールではありません。データの耐障害性、破損やヒューマンエラーからの復旧、クラスター移行とアップグレード、コンプライアンス要件の充足、そして災害復旧の実現まで、OpenSearchクラスターの運用において包括的なデータレジリエンシー戦略を提供しています。これらすべての要素が組み合わさることで、スナップショットは現代のデータインフラストラクチャにおいて欠かせない基盤技術となっているのです。

スナップショットの仕組み

概要


なぜスナップショットが必要かを理解したところで、次はその仕組みについて見ていきましょう。
スナップショットは、クラスターの状態とデータをリモートストレージにバックアップする仕組みです。クラスターの状態には、クラスター設定、ノード情報、インデックス設定、シャードアロケーションなどが含まれます。これらのデータは、S3、Google Cloud Storage、Azure Blob Storage、HDFSなどのリモートストレージに保存されます。
OpenSearchはリポジトリという概念を持っており、リポジトリプラグインを通じて様々な標準的なBlobストレージサービスと連携できます。この柔軟性により、組織が既に利用しているクラウドプロバイダーのストレージサービスをそのまま活用できます。
特に重要なのは、スナップショットがインクリメンタルな性質を持つことです。つまり、前回のスナップショット以降に変更されたデータのみを保存します。新しいデータがインデックスされていない場合、データの再アップロードは発生しません。この仕組みにより、冗長なアップロードを避け、ストレージコストを大幅に削減できます。
また、頻繁にアクセスしないデータをスナップショットとして保存することで、さらなるコスト削減が可能です。実際には使用していないけれどもコンプライアンス要件で保持が必要なデータなどは、スナップショットとして保存するのが理想的です。

リポジトリ構造の詳細


リポジトリはBlobストレージ上に構築され、階層的な構造でデータを管理しています。
最上位にはindex-Nファイルがあります。これはリポジトリデータファイルとも呼ばれ、いわばメタデータの親玉のような存在です。このファイルには、クラスターのスナップショットに関するあらゆる情報が含まれています。取得したすべてのスナップショット、各スナップショットでバックアップされたインデックスの情報などが、直接的に、あるいは間接参照の形で格納されています。index.latestファイルは最新世代のスナップショット情報を保持する特別なファイルです。
クラスターレベルのデータも重要な要素です。スナップショットを取得するたびに、クラスターレベルで作成されるファイル群があります。これにはクラスターステート、つまり動的設定やカスタムメタデータなど、クラスター全体に関わる情報が含まれています。
indicesフォルダの中には、個々のインデックスが格納されています。各インデックスには固有のUUIDが割り当てられ、その中にはインデックスメタデータが保存されています。リフレッシュ間隔などの各種設定がここに記録されます。さらにインデックスUUIDの下には、0や1といった番号で表現されるシャードフォルダがあり、シャードレベルのファイルが格納されています。各スナップショットごとにsnap-UUID.datのようなファイルが作成される仕組みです。
この階層構造の優れた点は、柔軟性にあります。クラスター全体のスナップショットを取ることも、特定のインデックスセットだけを対象にすることも可能です。リストア時も同様に、必要なインデックスだけを選択的に復元したり、クラスターステートを含めるかどうかを選択したりできます。この構造により、きめ細かなバックアップとリストア戦略を実現できるのです。

スナップショットの基本的な使い方


スナップショットの使い方はシンプルです。最初にリポジトリを登録します。S3バケットやAzure Blob Storageなどのリモートストレージを指定し、認証情報と共にOpenSearchに登録します。
リポジトリの登録後、スナップショットの作成が可能になります。作成時には対象となるインデックスを指定でき、特定のインデックスだけを選択することも、クラスター全体を対象にすることもできます。クラスターステートを含めるかどうかや、メタデータとして作成者や環境情報を付与することも可能です。
スナップショット情報の取得APIでは、リポジトリ内のスナップショット一覧を確認したり、特定のスナップショットの詳細を取得したりできます。進行中のスナップショット操作のステータスを確認するAPIも用意されており、大規模なバックアップの進捗状況を把握できます。
リストアは柔軟性があり、クラスターレベルで取得したスナップショットから、必要なインデックスだけを選択的に復元できます。パラメータを調整することで、一つまたは複数のインデックスを選んでリストアすることが可能です。
不要になったスナップショットの削除もAPIコールで実行できます。これらの基本的なAPIに加えて、高度な操作のためのAPIも用意されています。

スナップショット運用の考慮事項


スナップショットを運用する際には、いくつかの重要な考慮事項があります。まずスナップショット処理はノードのIO、CPU、メモリといったリソースを消費します。適切に設定しないと、検索やインデックス作成のパフォーマンスに影響を与える可能性があります。
ストレージロケーションの選択も重要です。データをバックアップする以上、耐久性、可用性、スケーラビリティという基準を満たす必要があります。リモートストア関連のAPIレスポンスタイムも確保する必要があります。
バージョン互換性にも注意が必要です。スナップショットは1つのメジャーバージョンまでしか前方互換性がありません。頻繁にメジャーバージョンアップグレードを行う場合は、データの再インデックスとスナップショットの再取得が必要になることがあります。
パフォーマンスを最適化するためのベストプラクティスとして、専用のクラスターマネージャーノードの使用を推奨します。これによりスナップショットの作成と削除を大幅に高速化できます。また、max_snapshot_bytes_per_secやmax_restore_bytes_per_secといった設定でリソース使用量を制限し、ライブトラフィックへの影響を最小限に抑えることができます。
運用上の注意点として、スタックしたスナップショットの監視が不可欠です。進行中のスナップショットがある間はインデックスの削除ができないという制約があり、スタックしたスナップショット削除はJVMメモリプレッシャーを引き起こす可能性があります。
S3を使用している場合は、最大同時接続数などの設定を動的に変更できるリロード可能な設定も活用できます。これらの設定により、スナップショットをニーズに合わせて調整できます。

スナップショットを活用した災害復旧


災害復旧（DR）は、どんなアプリケーション構築においても重要な要件です。スナップショットはドメイン全体の状態を保存します。これにはインデックス、マッピング、設定などすべてが含まれており、クラスターの特定時点のバージョンを復元できるようになっています。
災害復旧を考える上で、2つの主要な指標を理解する必要があります。1つ目はRTO（Recovery Time Objective）で、サービス中断から復旧までの最大許容遅延時間を示します。つまり、システムがダウンした場合、どれだけの時間ダウンタイムを許容できるかという指標です。
2つ目はRPO（Recovery Point Objective）で、最後のデータ復旧ポイントからの最大許容時間を示します。これは本質的に、どれだけのデータ損失を許容できるかという指標です。スナップショットを取得していれば、そのスナップショット以降にインデックスされたデータのみが失われることになります。
これらのパラメータは、要件に基づいて調整する必要があります。スナップショットはこれらの目標を達成するための手段となります。

災害復旧セットアップの実装


ここではシンプルな災害復旧セットアップを紹介します。プライマリリージョンのOpenSearchクラスターにアクティブトラフィックが流れ、セカンダリリージョンにスナップショットを保存します。プライマリクラスターが災害でダウンした場合、セカンダリリージョンでスナップショットをリストアし、トラフィックを切り替えます。
これはアクティブ・パッシブ型のDRセットアップです。リアルタイムのクロスクラスターレプリケーションのような高度なソリューションと比較すると、コストを抑えられるのが利点です。
RTOを改善したい場合は、セカンダリクラスターを常時稼働させ、定期的にスナップショットをリストアしておくことで、ダウンタイムを最小限に抑えられます。RPOを改善したい場合は、スナップショットの取得頻度を上げます。例えば5分や10分ごとにスナップショットを取得すれば、データ損失を最小限に抑えられます。
このようなシンプルなセットアップで、プライマリクラスターの災害時に対応できる仕組みを構築できます。

スナップショットの課題と解決策


スナップショットは重要な機能ですが、実運用では4つの主要な課題に直面します。
1つ目の課題は、頻繁にアクセスしないデータのコストです。スナップショットに保存したデータにアクセスするには、まずリストアが必要です。再度インデックスする場合も同様にリストアが必要になります。この課題に対してはSearchable Snapshotsという解決策があります。
2つ目は運用のオーバーヘッドです。スナップショットは定期的に取得する必要がありますが、その管理作業に圧倒されたくはありません。この課題にはSnapshot Managementが対応します。
3つ目はリモートストレージのスケーリングです。大規模なクラスターで多数のノードとシャードがある場合、リモートストアがボトルネックになる可能性があります。Hash Prefix Shard Path Typeという手法でこの問題を解決します。
4つ目は大規模デプロイメントでのスナップショットのスケーリングです。Lightweight Snapshotsがこの課題に対応します。
それぞれの課題と解決策について、これから詳しく説明していきます。

課題1：頻繁にアクセスしないデータのコスト


クラスターには異なるデータティアが存在します。頻繁に書き込みやアクセスを行うホットティアと、アクセス頻度の低いウォームティアです。例えば、過去7日間のデータは頻繁にアクセスされますが、1年前のデータへのアクセスはまれです。ホットティアには良好なレイテンシが求められますが、ウォームティアではそこまでのレイテンシは不要です。
クラスターのストレージはデータノードのディスク容量に制約されます。100GBのディスクでは、それ以上のデータは保存できません。1TBのデータを保持したければ、ノードやディスクを追加する必要があります。つまり、ストレージとコンピュートが結合されている状態です。
解決策として、アクセスしないウォームデータをスナップショットにオフロードできます。しかし問題は、スナップショット内のデータへのアクセス方法です。従来の方法では、スナップショットをリストアする必要があり、これはホットティアのリソース要件を増加させます。より多くのディスクやコンピュートリソースが必要になりますが、これは避けたい状況です。

Searchable Snapshots


解決策となるのがSearchable Snapshotsです。この機能により、リストア作業なしでスナップショットデータに直接アクセスできます。ホットティアのリソースを追加で消費することなく、データにアクセスできるようになります。
オンデマンドでリアルタイム検索が可能で、リストアの完了を待つ必要がありません。すぐにデータへのアクセスを開始できます。さらにキャッシング機能により、同じクエリを繰り返し実行する際のパフォーマンスが向上します。初回はコールドスタートの問題がありますが、2回目以降は高速化されます。
Searchable Snapshotsは専用のノードロールも提供しています。これによりホットティアとウォームティアを分離でき、ホットティアへの影響を防げます。アーキテクチャはシンプルで、検索ノードとデータノードがあり、必要に応じてスナップショットリポジトリからデータをダウンロードします。
この仕組みにより、リモートストアやスナップショットリポジトリに保存できるデータ量に実質的な制限がなくなります。数TBのデータも保持可能です。ただし、検索クエリで使用するデータ量に応じて、キャッシュ用のディスクは必要になります。

Searchable Snapshotsの利点


Searchable Snapshotsは4つの主要な利点を提供します。まず、データアクセスとストレージの効率化です。必要なデータのみをオンデマンドで取得できるため、リソースの無駄がありません。
次にストレージとコンピュートのデカップリングが実現されます。これまで結合していた2つの要素を分離することで、それぞれを独立してスケールできるようになりました。
コスト削減も大きなメリットです。頻繁にアクセスしないデータのために追加のディスクやノードを用意する必要がなくなりました。
運用効率も改善されます。従来はデータをリストアし、完了を待ってからアクセスしていましたが、その待ち時間が不要になりました。

Searchable Snapshotsの使い方


Searchable Snapshotsの使い方は通常のリストアとほぼ同じです。リストアAPIを実行する際に、storage_typeパラメータをremote_snapshotに指定するだけです。リネームパターンやリネーム置換も通常通り指定できます。
リストア後は通常のインデックスと同じように検索できます。ホットティアのインデックスと同様の操作が可能です。
使用後はインデックスを削除できます。インデックスはクラスターマネージャーに追加のリソース負荷をかけるため、使用しないものは削除することを推奨します。

Searchable Snapshotsのベストプラクティス


Searchable Snapshotsは検索のたびにリモートストアを呼び出すため、コスト管理が重要です。ベンダーによって価格モデルが異なるため、リモートストアの呼び出し回数を監視し、追加コストを把握する必要があります。
ホットワークロードへの影響を避けるため、検索ロールを持つ専用ノードを使用します。これによりホットティアとウォームティアを効果的に分離できます。
スナップショット取得前にforce mergeを実行してセグメント数を最小化することで、検索パフォーマンスとレイテンシが改善されます。
リモートデータとローカルディスクキャッシュサイズの最大比率を設定することも重要です。ホットティアとウォームティアの混在環境でも、両方から最良のパフォーマンスを引き出せるようになります。

課題2：運用のオーバーヘッド


2つ目の課題は運用面のオーバーヘッドです。多くの組織では法的要件やコンプライアンスのためにスナップショットが必須となっています。そのため追加のチームやコードでスナップショットの作成と削除を管理している場合があります。
手動でのスケジューリングと実行は、チームにとって大きな負担となります。外部監視とアラート設定も必要です。例えば、法的にN日間以上データを保持できない場合、X日以内にスナップショットが削除されていないことを検知する外部監視が必要になります。
スナップショットのライフサイクル管理全体が運用負担を増加させ、結果として管理における大きなオペレーショナルオーバーヘッドにつながっています。

Snapshot Management


この課題に対する解決策がSnapshot Managementです。OpenSearchを使用したことがある方は、ISM（Index State Management）をご存じかもしれません。Snapshot ManagementはIndex Managementプラグインを使用してスケジュールジョブを作成します。
Snapshot Managementのポリシーとメタデータはシステムインデックスに保存されます。つまり、スナップショットのライフサイクルを管理するために別のデータベースは不要で、OpenSearchクラスター自体がデータベースとして機能します。
この機能により、スナップショットの作成と削除プロセスが自動化されます。ビルトインのリトライ機能もあり、クラスターが過負荷状態でスナップショット取得に失敗した場合でも、自動的に再試行します。
通知チャネルとの統合も可能です。スナップショットの作成や削除が失敗した場合、SlackやPagerDutyなどに通知できます。Webhookを介して標準的な通知チャネルと連携できるため、既存の監視システムに容易に組み込めます。

Snapshot Managementの利点


Snapshot Managementは運用効率を大幅に改善します。先ほど説明した手動管理の負担がすべて自動化されるためです。
リモートストアのコスト増加も防げます。定期的な削除により、手動管理で起こりがちな削除忘れや、プログラムによる管理で障害処理が不十分な場合に発生するコストの積み上がりを防止できます。
通知フックを使った障害処理の自動化も可能です。PagerDutyやSlackへの通知を受けて、その上に自動化の仕組みを構築することで、障害への対応も自動化できます。

Snapshot Managementの使い方


Snapshot ManagementはISM（Index State Management）と同様にポリシーベースで動作します。SMポリシーを作成し、そのポリシーに基づいてスナップショットのライフサイクルが管理されます。
作成cronでは、スナップショットの取得頻度を定義します。削除cronでは、削除タイミングを設定できます。削除条件では、経過時間（age）やスナップショット数（count）を基準に削除を実行できます。例えば、特定数以上のスナップショットを保持しないような設定が可能です。
スナップショット設定では、対象となるインデックスを指定できます。重要なインデックスのみをバックアップ対象にすることで、効率的な運用が実現できます。
通知チャネルとしてSlackやPagerDutyなどを設定でき、通知条件も細かく制御できます。作成や削除の失敗時だけでなく、処理時間が制限を超えた場合にも通知を受け取れます。タイムリミットフィールドを設定することで、スナップショット処理が予想以上に長時間かかっている場合の検知も可能です。

Snapshot Managementのベストプラクティス


Snapshot Managementは多くの利点を提供しますが、障害が発生する可能性もあります。SM Explain APIを使用して、スナップショット操作の監視を軽量に実施する必要があります。
削除スケジュールはオプションですが、設定することを推奨します。APIは削除設定がなくてもポリシー作成をブロックしませんが、コスト管理の観点から削除スケジュールを設定すべきです。
並行スナップショット操作は避ける必要があります。複数のスナップショットを同時に実行すると、クラスターの不安定化につながる可能性があります。

課題3：リモートストレージのスケーリング


3つ目の課題は、リモートストアのスロットリングで、これは大規模なOpenSearchクラスターを運用する際の大きな問題です。100ノード以上、場合によっては10〜30ノード程度でも発生します。
組織のデータは最初は少量から始まります。しかし時間とともに、OpenSearchの活用が進むににつれて、様々なユースケースが追加されていきます。スケールのためにシャードとノードを追加し、1ノードクラスターから始まって、5、10、100ノードと拡張していきます。
OpenSearchは制限なくノードを追加でき、200〜1000ノードまで安全に拡張できます。クラスターはインデックスや検索において適切にスケールしますが、リモートストアがボトルネックになり始めます。多数のシャードからの同時アクセスにより、リモートストアでスロットリングが発生するのです。

Hash Prefix Shard Path Type


この課題に対する解決策として、キーをランダム化し、ホットキーをランダムなプレフィックスに分散させる新しいアプローチを開発しました。
従来のスナップショットリポジトリの構造では、ルートの下にindicesフォルダ、その下にindex UUID、さらにshard IDという固定パスになっています。シャード数やインデックス数が増えると、固定パーティションにアクセスが集中します。インデックスUUIDによる一定のランダム化はありますが、固定文字列部分が長く、負荷が適切に分散されません。
あるインデックスがホットになるとリモートストアはそのインデックス用にスケールしますが、別のインデックスがホットになると、作成済みのパーティションが無駄になり、再びスロットリング問題が発生します。リモートストアプロバイダーはスロットリング時にパーティションを追加しますが、この制約により常に安定したスナップショット成功を保証できません。
そこでHash Prefix Shard Path Typeでは、決定論的なランダムプレフィックスを導入しました。各シャードが異なるパーティションを使用し、異なるインデックスのシャードが同じパーティションを共有できるようになります。あるインデックスが非アクティブになっても、全体のパーティションプールから均等に分散されます。この方法により、スロットリングが発生しづらくなります。

課題4：スケーラビリティとパフォーマンスの問題


ペタバイトスケールでのスケーラビリティとパフォーマンスの問題について説明します。
ペタバイト規模のデータでスナップショットを取得すると、処理の遅延が発生します。データをスナップショットバケットにアップロードする必要があり、スナップショットタスクは低優先度のため、長時間スターブ状態になることがあります。結果として、スナップショット操作全体のレイテンシが増加します。
スナップショットの状態管理も課題です。開始状態からスナップショット中、そして最終化状態まで、クラスターマネージャーとデータノード間で多数のトランスポートコールが発生します。ペタバイトスケールでは数百のノードと10万規模のシャードが存在し、これらのコールがクラスターマネージャーレベルでボトルネックを生み出します。スケールに応じて指数関数的に増加するのです。
スナップショット取得には、既存のスナップショットと最新データの差分を特定するためのネットワークI/OとディスクI/Oも必要です。さらに、最近更新されていない非アクティブなインデックスについても、変更の有無を確認する必要があり、固定的なストレージコストが発生します。

スナップショット処理の流れ


基本的なスナップショット処理の流れを見てみましょう。
スナップショット操作が開始されると、まずリクエストがデータノードの1つに到達し、そこからクラスターマネージャーへのリクエストが作成されます。クラスターマネージャーは新しいクラスターレベルのスナップショットを開始し、プライマリシャードを持つ各データノードにシャードレベルのスナップショットをリクエストします。
各ノードレベルでは差分が特定され、必要なデータがスナップショットバケットにアップロードされます。このアーキテクチャは通常のスケールでは問題なく動作しますが、ペタバイトスケールになると、シャード数が膨大になるため、これらの操作がクラスターマネージャーを圧迫することになります。

スナップショットの進化：Remote Storeの活用


これらの問題を緩和するために、まず注目すべきは毎回のスナップショット時のデータアップロード負荷です。スナップショットを取得するたびに、各シャードから差分データをスナップショットバケットにアップロードする必要があります。この負荷を削減するため、OpenSearchのRemote Store機能、特にRemote Segment Store機能を活用できます。
OpenSearch 2.10から導入されたRemote Store機能は、定期的な頻度で新しく作成されたセグメントを各ノードからリモートストアに継続的にアップロードします。スナップショットリクエストが開始されると、従来通りシャードレベルのスナップショットがリクエストされますが、必要なデータは既にリモートストアに存在しています。これは信頼性の向上だけでなく、スナップショット操作レベルでの全体的なアップロード量の削減にも貢献します。
Remote Storeの一部として、保存される正確なセグメント情報を含むメタデータファイルがアップロードされます。このメタデータにはセグメントアップロードが発生した時刻を示すタイムスタンプも含まれています。スナップショット操作の一環として、さらにロックファイルが追加されます。このロックファイルは、複数のメタデータファイルの中から、必要なデータが存在する対応ファイルを示します。後で古いデータを参照したい場合、このロックファイルから必要なセグメントファイルを持つメタデータを特定し、以前の状態に戻すことができます。
しかし課題があります。小規模なセットアップでは簡単ですが、ペタバイトスケールのクラスターになると、データノード全体でロックファイルやメタデータファイルが作成され、その数は各スナップショットで10万ファイルに達する可能性があります。データアップロード操作の観点から削減を試みていますが、作成されるファイル数の問題は依然として存在します。ファイル数はシャード数と同じになり、ガベージコレクション時の古い不要なメタデータファイルの削除、スナップショット削除時のすべてのロックファイル削除など、S3やGCPなどの基盤データストアへの操作が増加します。ペタバイトスケールでは、データではなくロックファイルのアップロードでさえ影響を受け、スロットリングエラーが発生する可能性があります。

スナップショットへの新たなアプローチ


解決策を考える前に、一歩下がってユースケースの観点からどの操作がより重要かを特定し、理想的なアプローチを導き出しました。
スナップショットの方法論を見てみると、シャードレベルでスナップショットを取る際には、保持すべきセグメントを正確に含むチェックポイントを作成する必要があります。ガベージコレクションでは、このチェックポイントによって参照されているデータのガベージコレクションをスキップし、後のリストアポイントで有用となるようにします。リストア時には、チェックポイントによって参照されているデータをダウンロードし、特定のクラスターにダウンロードしてシャードを開始できるようにします。
操作の複雑さを考慮すると、スナップショットははるかに複雑な操作です。各シャードレベルで個別に操作する必要があり、リストアと比較してもスナップショットの方がはるかに集約的な操作となります。
使用頻度の観点からも、スナップショットの取得はリストアより重要と言えます。災害復旧時に最新のデータに戻れるよう、定期的により多くのスナップショットを取得したいというニーズがあります。そのため、頻繁な間隔でのスナップショット取得は、リストアよりも重要な操作となります。リストアは障害発生時にのみ実行され、その操作が少し複雑になっても問題ありません。
このユースケースの観点を考慮し、スナップショット処理を高速化し、リストアはより複雑になってもよいというロジックの変更を決定しました。

Snapshot v2でのスナップショット取得


このアプローチを実現するため、リモートストアを活用することにしました。メタデータファイルがアップロードされる際、セグメントがリモートストアにアップロードされた正確な時刻を表す逆順タイムスタンプ形式でメタデータファイルを作成します。このタイムスタンプをメタデータファイルに保持することで、新しいアプローチが可能になります。 このアプローチでは、特定の時点でスナップショットが開始されると、クラスターマネージャーにスナップショット作成リクエストが送られます。しかし、ロックファイルを作成する代わりに、スナップショットがリクエストされた時刻のタイムスタンプを単純に識別します。このタイムスタンプがスナップショットによって参照されます。
各シャードレベルでファイルをアップロードする代わりに、初期リクエスト時のスナップショット時刻という単一のタイムスタンプを識別するだけです。これにより、クラスターレベルのスナップショット操作が1つ実行されるだけで、すべてのノードへの多数のシャードレベル操作は不要になります。スナップショット作成時のシャードレベルの処理をすべて省略し、高速な操作を実現しています。結果として、スナップショット処理は大幅に高速化されます。
ガベージコレクションの処理も変更されています。Remote Store操作の一環として、クラスターからリモートストアへのデータアップロードが継続的に行われます。新しいセグメントが作成される間隔ごとに、新しいチェックポイントファイルが作成され、そのメタデータがリモートストアに保存されます。
これらのメタデータをガベージコレクションする必要があります。そうしないと、不要なメタデータが蓄積され続けます。最新のメタデータは検索クエリが依存するものですが、古いメタデータは通常不要です。ただし、スナップショットを取得した場合、そのメタデータは後で古いデータにリストアするために重要になります。
ガベージコレクションでは、すべてのメタデータファイルをリストアップする必要があります。各ファイルには既にタイムスタンプが含まれているという利点があります。重要なメタデータファイルを特定するため、すべてのファイルを反復処理し、最新のものだけを保持します。その時点以降はデータが更新され、新しいメタデータが存在するため、古いメタデータを維持する必要はありません。この処理は反復処理と保持すべきファイルの特定が必要なため、少し複雑になりますが、効果的にメタデータを管理できます。

Snapshot v2でのリストア処理


リストア時には、特定のスナップショットを古いタイムスタンプにリストアするリクエストを受け取ります。スナップショットIDに基づいて古いタイムスタンプを取得し、それに基づいてRemote Restoreリクエストが作成されます。
次に、存在するすべてのメタデータファイルを確認し、現在のタイムスタンプ値より前の最も古いタイムスタンプを持つファイルを特定する必要があります。具体例を見てみましょう。2025-02-04 23:00:00Zにリストアしたいというリクエストがあったとします。
メタデータファイルのリストには以下が含まれています。

  • MD_2025-02-05-00:50:00Z
  • MD_2025-02-04-23:40:00Z
  • MD_2025-02-04-22:50:00Z
  • MD_2025-02-04-21:50:00Z

最初のファイル（00:50:00Z）は最新のものですが、その下にさらにメタデータが存在するため、次に進みます。23:40:00Zのファイルも23:00:00のリクエスト時刻より新しいため、スキップします。22:50:00Zのファイルを確認すると、これは23:00:00より前のタイムスタンプです。これを最新のチェックポイントとして選択し、そのメタデータに含まれるすべてのセグメントをリストアします。
リクエストは23:00:00Zでしたが、実際には22:50:00Zのメタデータが使用されます。22:50から23:00の間に中間のメタデータが存在しないということは、その期間に実際の更新が発生していないことを意味するからです。
このようにすべてのメタデータファイルをループすることで、古い状態に素早く戻ることができます。リストア処理は従来の方法と比較すると時間がかかり複雑になりますが、それでも効率的な処理が可能です。

Snapshot v2の全体的な利点


Snapshot v2の全体的な利点を見てみましょう。このアプローチではデータのコピーが一切発生しません。タイムスタンプを特定し、そのタイムスタンプに基づいて保持すべき適切なセグメントを参照するだけです。それ以前のものはガベージコレクションされます。
このゼロコピー、コーディネーションフリーのアプローチにより、クラスターマネージャーと個々のノード間での調整が不要になります。クラスターレベルのスナップショット操作のみが関与し、シャードレベルの操作は一切必要ありません。これが大きな利点の一つです。
タイムスタンプベースの参照により、ロックファイルは不要になります。ロックファイルの代わりにタイムスタンプを直接参照するため、アップロードコストが完全に回避されます。明示的なロックファイルが存在しないことで、リモートストアへの呼び出しも削減されます。
このプロセス全体がSnapshot v2と呼ばれ、タイムスタンプに依存した新しいアプローチとなっています。

Snapshot v2の利点とパフォーマンス


Snapshot v2の利点は4つの領域で現れています。パフォーマンス面では、スナップショットの作成と削除時間が短縮され、システムリソース使用率が低下しました。複雑なアップロード処理が不要になったため、数秒でスナップショット操作が完了します。リソース消費がなくなったことで、インデックスや検索トラフィックへの影響も排除されました。
スケーラビリティでは、多数のノードとシャードがある環境でもスナップショット作成時間が短く保たれます。大規模OpenSearchクラスターに適した設計となっています。
ストレージ効率では、既存データへのスマートな参照を維持し、多数のノードとシャードがあってもリモートストアとのやり取りコストが低く抑えられます。アーキテクチャも簡素化されています。

実際のパフォーマンス結果を見ると、100ノード・10万シャードの環境で、従来のスナップショットは1時間以上かかりました。Shallow Snapshot v1（Remote Store使用）では約1時間でした。Shallow Snapshot v2では10秒未満で完了しています。10ノード・1万シャードの環境では、従来30〜40分だったものが5秒未満に短縮されました。

Snapshot v2の使い方


Snapshot v2を使用するには前提条件があります。まずRemote Storeでバックアップされたクラスターが必要で、既存のクラスターの場合はRemote Storeクラスターへの移行が必要です。
設定は2つ必要です。まず静的クラスター設定として、opensearch.ymlファイルにcluster.remote_store.pinned_timestamps.enabled=trueを追加します。
次にリポジトリ設定で、リポジトリ作成時にshallow_snapshot_v2パラメータをtrueに設定します。これによりSnapshot v2の動作が有効になります。これらのリポジトリレベル設定を行うことで、先ほど示したパフォーマンス改善が実現されます。