オブジェクトストレージにおけるスナップショット技術の設計と実裝

中文 English 日本語
snapshotinternal designsobject storeobject questioningApache Foundationuse cases

オブジェクトストレージは、大規模なデータ管理やクラウド環境での運用において不可欠な技術として注目されています。特に、データの変更履歴を効率的に管理するための「スナップショット（Snapshot）」機能は、データ保護、災害復舊、時間旅行的な操作など、多様な使用ケースに応じた柔軟な運用が可能とされています。本記事では、スナップショットの設計原理、実裝メカニズム、および具體的な使用例を解説します。

スナップショットとオブジェクトクエリの違い

オブジェクトクエリは、個々のオブジェクトの変更ごとに新しいバージョンを生成し、古いバージョンを保持します。これにより、命名空間の爆発的な増加や手動でのクリーンアップが課題となる場合があります。一方、スナップショットは、アプリケーション管理のオブジェクト群を単位として、全體のバージョンを一括して管理します。これにより、オブジェクト間の參照斷裂を防ぎ、アプリケーションの整合性を保つことが可能です。

問題と解決策

オブジェクトクエリによるバージョン管理では、変更履歴が膨大になり、參照斷裂が発生するリスクがあります。スナップショットは、アプリケーションの狀態を原子的な単位として管理することで、バージョン間の整合性を保ち、データの不一致を防ぎます。このアプローチにより、データの信頼性と運用効率が向上します。

使用ケース

  1. データ保護：アプリケーションの崩壊やマルウェア感染時の復舊にスナップショットを活用します。
  2. コンプライアンス：政府規範に準拠するため、特定の時間點のデータを保存します。
  3. タイムトラベル：過去のアプリケーション狀態を回溯的に參照可能にします。
  4. 災害復舊：Delta複製と組み合わせて、変更データのみを同期することで、遠隔データ同期の効率を向上させます。

スナップショットの使用方法

  • レイヤー支援：Bucketレイヤーでのスナップショットをサポートし、今後はVolumeや全體のストレージシステムにも拡張予定です。
  • アクセス方法：.snapshotという隠蔽された命名空間を使用し、<bucket>.snapshot/<snapshot_name>/<key>の形式でアクセスします。
  • 空間効率：スナップショットは差分空間を佔有し、物理的なストレージは元のオブジェクトと共有します。データ削除後もスナップショットの空間は自動的に回収されません。

スナップショット操作とメカニズム

  • スナップショット作成：瞬間的な操作で、データセットのサイズに依存せず、100 PB規模のデータにも対応します。
  • スナップショット削除：非順序的な削除をサポートし、削除時に前後のスナップショットリンクを処理します。空間の回収はバックグラウンドで行われます。
  • 差分計算：異步APIを提供し、2つのスナップショット間の差分を計算します。分頁レスポンスをサポートし、追加、削除、変更されたKeyリストを返します。

Ozoneアーキテクチャとスナップショット設計

  • ネームスペース管理：Ozone Managerが管理し、三重複製で整合性を保ちます。オブジェクトとBlockのマッピングを実行します。
  • ストレージコンテナ管理：Storage Container ManagerがBlock空間を管理し、クラスタ狀態を監視します。
  • スナップショットチェーン管理：各Bucketがスナップショットチェーンを維持し、グローバルなチェーンをサポートします。スナップショット削除時にリンクを活用して空間を回収します。
  • Delta複製：スナップショット差分計算により、変更データのみを同期し、遠隔データ同期コストを削減します。

スナップショット空間とパフォーマンス

  • 空間佔有：スナップショットは差分空間を佔有し、物理空間は元のオブジェクトと共有します。データ削除後もスナップショット空間は自動的に回収されません。
  • パフォーマンス最適化：スナップショット作成と削除は瞬間的な操作で、差分計算時間は変更データ量に比例します。データセット全體のサイズには依存しません。

スナップショット設計の概要

  • オブジェクトストレージのBucket間の差分を効率的に計算する機能を提供します。
  • 差分計算時間は2つのスナップショット間の変更オブジェクト數に比例します。
  • 異步APIをサポートし、クライアントのリクエストタイムアウトを迴避します。
  • 大量の変更データ（數百萬のKey）を処理するための分頁レスポンスをサポートします。
  • 削除/追加/変更/リネームされたKeyの正確なリストを返します。
  • 増量分析アプリケーション（クラウドデータセット分析など）に利用可能です。

Ozoneアーキテクチャ設計

  • ネームスペース管理：Ozone Manager（三重複製、Raftプロトコルで整合性を維持）
  • ブロック空間管理：Storage Container Manager（クラスタ狀態の監視）
  • データノード：データブロック（Block）を保存
  • HDFSとの違い：ネームスペースとブロック空間管理が分離され、小ファイルと大量オブジェクトのサポートが可能

スナップショットの実裝詳細

  • コンテナ狀態：コンテナはオープン（新しいブロックの追加可能）またはクローズド（変更不可）の狀態を取る
  • データブロックの特性：書き込み後は変更不可で、スナップショットはデータブロックの複製を必要としない
  • スナップショット作成メカニズム：
    • 原始SSTファイルへのハードリンク（Hard Link）を用いてスナップショットを作成
    • ファイルのライフサイクルを管理する參照カウント（Reference Count）
    • スナップショットデータは獨立したディレクトリに保存され、アクティブなオブジェクトストレージに影響を與えない
  • スナップショットチェーン管理：スナップショットはリンクで維持され、最新のスナップショットの後ろにアクティブなオブジェクトストレージが続く

空間回収メカニズム

  • スナップショットがない場合：オブジェクトの削除は削除テーブルに移され、削除サービスによって空間が回収される
  • スナップショットがある場合：
    • スナップショットが參照しているオブジェクトは回収されない
    • スナップショットの削除時に、前後のスナップショットリンクをチェックし、空間回収をバックグラウンドで実行
    • 未參照のオブジェクトは削除テーブルに合併され、後続の回収が行われる
  • スナップショット削除フロー：
    • 未參照のオブジェクトを特定
    • 後続のスナップショット削除テーブルに合併
    • スナップショットディレクトリを完全に削除

スナップショット差分計算

  • LSMアーキテクチャの応用：
    • RockDBのSSTファイル（変更不可）でデータを保存
    • 新しいデータは新しいSSTファイルに書き込まれ、古いファイルは回収まで保持される
  • 差分計算フロー：
    • スナップショットタイムラインを比較し、SSTファイルの差分を生成（例：SS File 3、4）
    • DocB APIを用いて鍵の狀態（存在/削除/変更）を比較
  • マージ操作（Compaction）：
    • マージタグ（Compaction Tag）を用いてスナップショットを復元
    • システム異常時にタグを活用してスナップショット狀態を再構築
  • スナップショット差分計算ステップ：
    1. スナップショット計算狀態（キャッシュ）を確認
    2. In-Memory Compaction TagからSSTファイルの変更を取得
    3. 現在のバケットに関係のないファイルをフィルタリング
    4. 鍵空間を比較し、差分リストを生成
    5. 削除/追加/変更/リネームされた正確な鍵集合を返す

技術的キーポイント

  • LSMアーキテクチャの利點：変更不可のSSTファイルとバッチ処理の特性を活用
  • ハードリンクメカニズム：スナップショットの瞬間的な作成と空間効率の向上を実現
  • 差分計算効率：変更領域のみを処理し、全量スキャンを迴避
  • 空間回収戦略：スナップショットの參照狀態と削除サービスを組み合わせて回収
  • ア synchrone処理設計：クライアントが大量データ処理によるタイムアウトを迴避

作業フローとスナップショット計算

スナップショットリクエストが到著すると、snapd handlerモジュールに処理が移され、pre-compute snapdプロセスが実行されます。この段階で、すでに計算済みのスナップショット（SN）が存在するか確認します。存在する場合はFilasシステムから結果を直接返します。存在しない場合は、SN for SS file calculatorを起動して差分変更を計算します。

  1. 差分変更計算

    • inmemory completion tagで管理されるタグを用いて、2つのスナップショット間の変更ファイル（SST files）を取得します。
    • 現在のバケットに関係のないファイルをフィルタリングします（スナップショットはバケットレベルで行われ、チェックポイントはRockインスタンスレベルで行われるため）。
    • 全ての鍵値（Key Namespace）を遍歴し、docb apisでファイルを読み込み、最初のスナップショットと最後のスナップショットの狀態を比較して、鍵値が作成、削除、リネーム、変更されたかを判斷します。

  2. スナップショット生成ロジック

    • スナップショットレベルを逆に遍歴し、追加または変更された葉ノード（Leaf Node）ファイルを識別して、snapd生成に必要なデータを取得します。
    • 例：スナップショット1にはファイル515、13、119が含まれ、スナップショット2では変更ファイルを計算するために逆に遍歴し、追加または変更されたファイルを特定します。

スナップショットタグと復元メカニズム

  • In-Memory Completion Tag

    • 系統はメモリ內でcompletion tagを維持し、スナップショット生成プロセスの狀態を追跡します。
    • 生成されたタグ構造は以下の通りです：
      • Rox M Table Flushによって生成された初期ファイル。
      • 時間系列（Time Series）によって構築されたスナップショットレベルDAG（有向無環グラフ）。
      • 各ノードにスナップショットに関連するファイルリスト（例：22、24、17、19、21など）を保存。

  • 復元メカニズム

    • システムが異常（例：クラッシュ）発生した場合、completion tagを活用してスナップショットを復元します。
    • スナップショット間の変更ファイル（例：24、27、28、29、32）を比較し、特定の狀態に復元します。
    • リネーム処理はobject IDに依存し、このIDはスナップショットレベル（Ozoneレベル）で維持され、オブジェクトの履歴変更を追跡します。

スナップショットレベルと変更追跡

  • バケットレベルスナップショット

    • スナップショットはバケットレベルで行われ、バケット內のデータ整合性を保ちます。
    • チェックポイント（Check Point）はRockインスタンスレベルで計算され、現在のバケットに関係のないファイル（例：24は変更なし）をフィルタリングします。

  • 変更ファイルタグ

    • 各スナップショットレベルの変更ファイル（例：27、28、29）は、追加または変更されたファイルとしてタグ付けされ、変更されていないファイル（例：24）はスナップショットに保持されます。
    • SSTファイルで変更履歴を記録し、スナップショット生成時に最終狀態（例：32が最新更新）に統合されます。

技術的詳細と使用例

  • スナップショット生成フロー

    • pre-compute戦略により、既存のSNを再利用し、計算負荷を軽減します。
    • docb apisでファイルを読み込み、completion tagを用いて狀態を比較します。

  • 典型的な使用例

    • データバージョン管理：スナップショットを活用してオブジェクトの履歴変更を追跡（例：22→24、17→21）。
    • 災害復舊：completion tagを活用して特定のスナップショット狀態に迅速に復元。
    • パフォーマンス最適化：差分変更（SST files）により、スナップショット生成のリソース消費を削減。

結論

スナップショット技術は、オブジェクトストレージにおいてデータの信頼性と運用効率を向上させるために不可欠な要素です。バージョン管理の柔軟性、災害復舊の迅速性、および時間旅行的な操作の実現が、スナップショットの主な利點です。実裝においては、LSMアーキテクチャの活用、ハードリンクによる空間効率の最適化、差分計算の効率化が重要なポイントです。運用上は、スナップショットのライフサイクル管理と空間回収戦略の設計が成功の鍵となります。

推薦閱讀