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

バックアップ戦略：ポイントインタイムリカバリと標準スナップショットの理解

MongoDBのスナップショットとポイントインタイムリカバリを比較し、oplogリプレイ、RPO、RTO、シャーディングクラスターのトレードオフについて解説します。

バックアップ戦略：ポイントインタイムリカバリと標準スナップショットの理解

MongoDBのバックアップ戦略は、1つの難しい質問に帰着します。それは、どれだけのデータ損失を許容できるかということです。標準スナップショットはデータベースを保存時点に復元できますが、ポイントインタイムリカバリは、誤ったデプロイ、誤削除、または破損イベントの直前の正確な秒に近い状態に復元できます。

この記事では、MongoDBのスナップショットとポイントインタイムリカバリ（PITR）を比較し、oplogの役割、シャーディングクラスターでの注意点、およびRecovery Point Objective（RPO）とRecovery Time Objective（RTO）に基づく選択方法について説明します。

データベースバックアップの重要性

具体的な戦略に入る前に、データベースバックアップが必須である理由を再確認することが重要です。

  • ディザスタリカバリ： ハードウェア障害、自然災害、またはデータセンター全体の停止から保護します。
  • データ破損： 論理エラー、誤削除、またはデータを破損するアプリケーションのバグから復旧します。
  • コンプライアンス： 多くの規制要件（例：GDPR、HIPAA、PCI DSS）は、データのバックアップと復旧機能を義務付けています。
  • 監査とフォレンジック： 調査のためにデータを特定の状態に復元できます。

標準スナップショットバックアップ

標準スナップショットバックアップは、特定の時点でのデータベースの状態をキャプチャします。これは、データボリュームの写真を撮るようなものです。一見簡単そうに見えますが、その実装と効果はMongoDBのデプロイ方法によって大きく異なります。

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

標準スナップショットには、通常2つの主要な形式があります。

  1. ファイルシステムスナップショット： これらは、基盤となるストレージシステム（例：LVMスナップショット、AWS EBSスナップショット、Azure Diskスナップショット、Google Persistent Diskスナップショットなどのクラウドプロバイダーのボリュームスナップショット）によって提供されるボリュームレベルのスナップショットです。これらは、データディレクトリ全体のコピーオンライトスナップショットを作成します。この方法は一般的に高速で効率的です。

    • プロセス：
      1. 書き込み操作を一時的に停止する（またはXFS xfs_freeze のようにスナップショット中に一貫性を保証するファイルシステムを使用する）。MongoDBの場合、通常は mongod インスタンスで db.fsyncLock() を実行して、スナップショットの前にすべてのダーティページがディスクにフラッシュされるようにし、スナップショット後にロックを解除します。または、レプリカセットのセカンダリメンバーからスナップショットを取得します。
      2. データボリュームのスナップショットを取得します。
      3. db.fsyncUnlock() でロックを解除するか、書き込みを再開します。
    • 復旧： スナップショットからボリューム全体を復元します。

  2. 論理バックアップ（例：mongodump）： mongodump は、データベースコンテンツのバイナリエクスポートを作成するMongoDBユーティリティです。実行中の mongod インスタンスからデータを読み取り、BSONファイルに書き込みます。

    • プロセス：
      1. MongoDBインスタンスに対して mongodump を実行します。データベースやコレクションを指定できます。

mongodump --host <ホスト名> --port <ポート> --out /path/to/backup/directory 2. レプリカセットの場合、プライマリへの影響を最小限に抑えるために、セカンダリメンバーに対して `mongodump` を実行するのが最適です。 * **復旧：** `mongorestore` を使用して、BSONファイルをMongoDBインスタンスにインポートします。 bash mongorestore --host <ホスト名> --port <ポート> /path/to/backup/directory ```

標準スナップショットの利点

  • シンプルさ： 単一インスタンスや単純なレプリカセットの場合、セットアップと管理が簡単です。
  • 速度（ファイルシステムスナップショットの場合）： ボリュームスナップショットは、特にデータベース全体を最後のスナップショット時点に迅速に復旧する必要があるディザスタリカバリにおいて、作成と復元が非常に高速であることがよくあります。
  • コスト効率： 複雑なPITRソリューションと比較して、ストレージと管理のオーバーヘッドの点で一般的に安価です。

標準スナップショットの欠点

  • 粒度が粗い： スナップショットが取得された正確な時点にしか復元できません。スナップショット間のデータ変更は失われます。
  • 一貫性の課題（シャーディングクラスター）： シャーディングクラスター全体で一貫性のあるファイルシステムスナップショットを取得することは非常に困難です。各シャードとコンフィグサーバーを同時かつ一貫してスナップショットする必要があり、専用ツールなしではほぼ不可能です。各シャードのボリュームの調整されていない単純なスナップショットは、復元時にクラスターの状態が不整合になる可能性が高くなります。
  • パフォーマンスへの影響： mongodump はデータベースに大きな負荷をかける可能性があり、fsyncLock() は書き込みを一時的にブロックするため、高スループットの本番プライマリには適していません。セカンダリで実行することをお勧めします。

標準スナップショットのユースケース

  • 重要度の低いデータ： ある程度のデータ損失（例：数時間または1日分）が許容されるアプリケーション。
  • 開発/テスト環境： データのコピーをすばやく簡単に作成する方法。
  • 単純なデプロイ： スタンドアロンインスタンスまたはレプリカセット。スナップショットのための複数ノード間の一貫性は、レプリカセットプロトコル自体によって管理されます。

ポイントインタイムリカバリ（PITR）

ポイントインタイムリカバリを使用すると、定義されたバックアップウィンドウ内の任意の特定の秒にデータベースを復元できます。これにより、最高レベルのデータ耐久性が提供され、データ損失を最小限に抑える必要があるミッションクリティカルなアプリケーションにとって重要です。

MongoDBにおけるポイントインタイムリカバリの仕組み

MongoDBのPITRは、2つのコアコンポーネントに依存しています。

  1. ベースバックアップ（スナップショット）： これは、標準スナップショットと同様に、特定の時点で取得されたデータの完全なスナップショットです。復旧の開始点として機能します。
  2. Oplog（操作ログ）： MongoDBのoplogは、レプリカセットのプライマリに適用されたすべての書き込み操作（挿入、更新、削除）を記録する特別なキャップ付きコレクションです。これは、すべての変更の継続的な時系列レコードとして機能します。

PITRを実行するには、まずベースバックアップを復元します。次に、ベースバックアップの時点から目的の復旧ポイントまで、アーカイブされたoplogエントリをリプレイします。このプロセスにより、その秒のデータベース状態が正確に再構築されます。

// 例：プライマリのoplogステータスを確認する
rs.printReplicationInfo()

// または、より直接的に
db.getReplicationInfo()

// oplogコレクションの統計を表示するには
db.getSiblingDB("local").oplog.rs.stats()

PITR実装の重要な考慮事項

  • 継続的なOplogアーカイブ： PITRの最も難しい側面は、oplogを確実かつ継続的にアーカイブすることです。これには通常、以下が含まれます。
    • ストリーミングOplog： レプリカセットのセカンダリメンバーからoplogを継続的に追跡します。
    • アーカイブ： これらのoplogエントリを安全で耐久性のある場所（例：S3、Azure Blob Storage）に保存します。
  • シャーディングクラスターとグローバルな一貫性： シャーディングクラスターの場合、PITRは非常に複雑になります。以下を行う必要があります。
    • すべてのシャードとコンフィグサーバーからベースバックアップを取得します。
    • すべてのシャードレプリカセットとコンフィグサーバーレプリカセットのすべてのプライマリメンバーからoplogをアーカイブします。
    • 復旧中は、これらのoplogをグローバルに一貫性のある方法でリプレイする必要があり、すべてのコンポーネント間でタイムスタンプを注意深く調整する必要があります。これは手動で行うのは非常に困難です。
  • ツール： MongoDB Cloud Manager や MongoDB Ops Manager（オンプレミスデプロイメント用）などのエンタープライズグレードのソリューションは、シャーディングクラスターを含む複雑なMongoDBトポロジーのPITRを処理するために特別に設計されています。これらは、ベースバックアップ、oplogアーカイブ、および調整された復旧プロセスを自動化します。

ポイントインタイムリカバリの利点

  • きめ細かい復旧： 任意の秒に復元し、データ損失を最小限に抑えます。
  • 最小限のRPO： 非常に低いRecovery Point Objectiveを達成し、重要なデータに不可欠です。
  • グローバルな一貫性（適切なツールを使用）： 復旧ポイントでシャーディングクラスターのデータがすべてのシャード間で一貫していることを保証します。
  • ビジネス継続性： 厳格な稼働時間とデータ整合性要件を持つアプリケーションに不可欠です。

ポイントインタイムリカバリの欠点

  • 複雑さ： 特に専用ツールなしのシャーディングクラスターの場合、セットアップ、管理、監視が大幅に複雑になります。
  • ストレージ要件： ベースバックアップだけでなく、継続的なoplogアーカイブも保存する必要があり、かなりのストレージ容量を消費する可能性があります。
  • 復旧時間（RTO）： 大量のoplogエントリをリプレイすると、Recovery Time Objectiveが増加する可能性がありますが、データ損失が最小限であるため、これは多くの場合許容されます。
  • コスト： 特に商用ツールを使用する場合、堅牢なPITRソリューションの実装と管理にはコストがかかる可能性があります。

ポイントインタイムリカバリのユースケース

  • ミッションクリティカルなアプリケーション： 金融システム、eコマースプラットフォーム、ヘルスケアアプリケーション、または数秒のデータ損失さえ許容できないシステム。
  • 規制コンプライアンス： 厳格なデータ保持および復旧規制を満たすため。
  • 偶発的なデータ削除/破損： ユーザーエラーやアプリケーションのバグによるデータ損失や破損から迅速に復旧します。

ポイントインタイムリカバリと標準スナップショットの比較

機能 標準スナップショットバックアップ ポイントインタイムリカバリ（PITR）
復旧の粒度 スナップショットが取得された正確な時点 バックアップウィンドウ内の特定のポイント
RPO目標 スナップショット後の変更が失われる可能性があるため高い oplogアーカイブが信頼できる場合は非常に低い
複雑さ スタンドアロンデプロイメントとレプリカセットでは低から中程度 高い、特にシャーディングクラスターの場合
データの一貫性 スナップショットが調整されている場合は良好。調整なしのシャーディングクラスターではリスクあり バックアップツールがスナップショットとoplogリプレイを正しく調整した場合のみ一貫性がある
復旧時間 スナップショットポイントへの復元は多くの場合高速 oplogエントリをリプレイする必要があるため、時間がかかる可能性がある
ストレージ要件 ベーススナップショット ベーススナップショットと継続的なoplogアーカイブ
コスト 一般的に低い ツール、ストレージ、管理のため一般的に高い
最適な用途 重要度の低いデータ、より単純なデプロイメント ミッションクリティカルなアプリケーション、厳格なRPO要件

実用的な考慮事項とベストプラクティス

選択した戦略に関係なく、以下のベストプラクティスを検討してください。

  • RPOとRTOを定義する： ビジネスが許容できるデータ損失（RPO）とダウンタイム（RTO）を明確に定義します。これがバックアップ戦略の主な推進力です。
  • すべてを自動化する： 手動バックアップは人為的エラーが発生しやすいです。スナップショットの作成、oplogのアーカイブ、バックアップの検証を自動化します。
  • 定期的に復元をテストする： バックアップは、復元できて初めて価値があります。定期的に完全な復元テストを実行して、バックアップが有効であり、復旧プロセスが期待どおりに機能することを確認します。異なる環境への復元など、さまざまなシナリオをテストします。
  • バックアップを保護する： 保存中および転送中のバックアップデータを暗号化します。バックアップストレージへのアクセスを制限し、適切な認証を確保します。
  • オフサイトストレージ： 地域的な災害から保護するために、バックアップを別の地理的な場所またはクラウドリージョンに保存します。
  • 監視とアラート： バックアップジョブの成功/失敗、ストレージ使用量、oplogラグを監視します。問題が発生した場合に備えてアラートを設定します。
  • キャパシティプランニング： 保持ポリシーを考慮して、プライマリデータとバックアップの両方に十分なストレージがあることを確認します。
  • クラウドプロバイダーの機能を活用する： クラウドでMongoDBを実行している場合は、多くの場合、適切に統合され効率的なネイティブクラウドプロバイダーのスナップショット機能を利用します。

まとめ

許容できるデータ損失がスナップショット間隔で測定され、トポロジーが自信を持って復元できるほど単純な場合は、スナップショットを選択してください。RPOがより厳しい場合、特に偶発的な削除や不正な書き込みを正確なポイントに復旧する必要がある本番システムでは、PITRを選択してください。どのパスを選択しても、復元テストをスケジュールし、インシデント中に必要になる前に正確な手順を文書化してください。