Categories
Disaster Recovery

**

DevOpsエンジニア、データベース管理者（DBA）、およびITシステムアーキテクトにとって、目標復旧時間（RTO）と目標復旧時点（RPO）は、単なるビジネス継続性のためのバズワードではなく、厳格なエンジニアリング上の制約です。ミッションクリティカルなデータベースを管理する際、これらの指標を正確に計算、設計、検証できなければ、壊滅的なデータ損失や長時間のダウンタイムを招く可能性があります。

現代のエンタープライズ環境において、RTOとRPOを算出するには、データベースの内部構造、ストレージI/O、ネットワークスループット、およびトランザクションログの仕組みに対する深い理解が必要です。本ガイドでは、本番データベースシステムのRTOとRPOを計算、テスト、最適化するための技術的な手法を解説します。

データベースシステムにおけるRPO（目標復旧時点）の解体

RPOは、時間単位で測定される許容可能な最大データ損失量を定義します。RPOが15分の場合、午後12時に障害が発生した際、少なくとも午前11時45分までのすべてのコミット済みトランザクションを復旧できる必要があります。

データベースにおいて、RPOはトランザクションログ管理戦略（PostgreSQLのWAL、OracleのRedoログ、SQL Serverのトランザクションログなど）によって決定されます。

データ損失とログ生成のメカニズム

達成可能なRPOを計算するには、まずデータベースのトランザクションログ生成率を理解する必要があります。15分ごとにバックアップリポジトリへログを転送していても、ネットワークがその時間内に15分分のログを転送できなければ、実際のRPOは継続的に悪化します。

ネイティブのSQLコマンドを使用して、ログ生成率のベースラインを測定できます。例えば、PostgreSQL（バージョン10以降）では、特定の期間におけるWrite-Ahead Log（WAL）の生成率を測定可能です：

-- T=0で実行
SELECT pg_current_wal_lsn() AS start_lsn;

-- 正確に5分（300秒）待機してから実行：
SELECT pg_current_wal_lsn() AS end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
       pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;

このクエリでピーク時に50 MB/sのWALデータが生成されていることが判明した場合、15分のRPOを維持するには45 GBのログデータをバックアップストレージに転送する必要があります。このRPOを維持するためには、ネットワークとストレージターゲットが50 MB/sを超える持続的な書き込み速度をサポートしている必要があります。

同期レプリケーションと非同期レプリケーションの影響

多くのDBAは、RPOを満たすために高可用性（HA）レプリケーションに依存しています。しかし、レプリケーションはバックアップではありません。テーブルの削除（DROP TABLE users;）は即座にレプリケートされます。

災害復旧（DR）にレプリケーションを使用する場合、レプリケーションモードがRPOに直接影響します：
* 同期レプリケーション： RPOゼロ（RPO=0）を保証します。プライマリデータベースは、スタンバイが受信を確認するまでトランザクションをコミットしません。トレードオフとして、プライマリの書き込み操作のレイテンシが増加します。
* 非同期レプリケーション： レプリケーションラグが発生します。RPOは実質的に現在のレプリケーションラグと等しくなります。

PostgreSQLで非同期レプリケーションのラグを監視するには、以下を使用します：

SELECT application_name,
       client_addr,
       state,
       sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

大規模データベースにおけるRTO（目標復旧時間）の解体

RTOは、許容可能な最大ダウンタイム期間です。データベースのRTO計算は、単にファイルをサーバーにコピーする時間ではないため、非常に複雑です。

RTO計算の数学モデル

現実的なデータベースRTOの計算には、4つの異なるフェーズを考慮する必要があります：

RTO = T(インフラ) + T(転送) + T(リストア) + T(リカバリ)

  1. T(インフラ) – インフラストラクチャのプロビジョニング： 代替のコンピューティングおよびストレージを立ち上げる時間。（事前プロビジョニングされたDRサイトやInfrastructure-as-Codeパイプラインを使用すれば、ほぼゼロにできます）。
  2. T(転送) – データ転送： バックアップペイロードをリポジトリからデータベースサーバーへ移動する時間。
  3. T(リストア) – 物理リストア： データファイルをターゲットディスクに書き込む時間。
  4. T(リカバリ) – データベースのクラッシュリカバリ： データベースエンジンがトランザクションログをリプレイし、コミット済みトランザクションをロールフォワードし、未コミットのトランザクションをロールバックする時間。

転送時間とリストア時間の計算

T(転送)とT(リストア)を計算するには、ネットワーク帯域幅とディスクのIOPS/スループットのベースラインを測定する必要があります。理論上の最大値に頼らず、実際のインフラストラクチャをテストしてください。

iperf3を使用して、バックアップリポジトリとデータベースサーバー間のネットワークスループットをテストします：

# バックアップリポジトリ（サーバー）側
iperf3 -s

# データベースサーバー（クライアント）側
iperf3 -c <backup_repo_ip> -t 60 -P 4

fioを使用して、データベースのリストア操作をシミュレートし、データベースストレージボリュームのシーケンシャル書き込みパフォーマンスをテストします：

fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile

データベースが5 TBで、fioテストによる最大持続書き込み速度が500 MB/sの場合、絶対的な最小T(リストア)は約2.8時間となります。ビジネスSLAで1時間のRTOが求められている場合、従来のストリーミングリストアでは不可能です。ストレージレベルのスナップショットやブロックレベルのレプリケーションへアーキテクチャを転換する必要があります。

隠れた罠：T(リカバリ)

最も過小評価されがちな変数はT(リカバリ)です。毎週のフルバックアップをリストアし、RPOに到達するために6日分のトランザクションログを適用する必要がある場合、データベースエンジンはすべてのトランザクションを順次リプレイしなければなりません。

500 GBのトランザクションログのリプレイには数時間かかる可能性があり、シングルスレッドのCPUパフォーマンスとストレージIOPSによって大きくボトルネック化します。T(リカバリ)を最小限に抑えるには、フルバックアップまたは差分バックアップの頻度を上げてください。

ギャップを埋める：RTOとRPOを検証するための実践的なステップ

理論上のRTOとRPOの計算は最初のステップに過ぎません。ミッションクリティカルな環境では継続的な検証が必要です。

ステップ1：継続的アーカイブの実装

同期レプリケーションのパフォーマンス低下を伴わずに1分未満のRPOを達成するには、継続的なログアーカイブを実装します。ログファイルがいっぱいになるのを待つ（トラフィックが少ない期間には数時間かかる場合があります）のではなく、定期的にログスイッチを強制します。

SQL Serverでは、頻繁なトランザクションログバックアップを自動化できます：

BACKUP LOG [MissionCriticalDB] 
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'MissionCriticalDB-Transaction Log Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

ベストプラクティス： RPO要件に応じて、このジョブを1〜5分ごとに実行するようにスケジュールしてください。

ステップ2：リストアテストの自動化

テストされていないバックアップは、単なる理論上の概念に過ぎません。計算されたRTOを保証するには、自動化されたリストアテストを実行する必要があります。

CloudSaveのようなエンタープライズバックアッププラットフォームは、自動化された分離環境でのリカバリテストを提供することで、これを簡素化します。CloudSaveは自動的にサンドボックス環境を立ち上げ、最新のバックアップをマウントし、完全なデータベースリカバリを実行し、カスタム検証スクリプト（SQL Serverの場合はDBCC CHECKDBなど）を実行して正確なRTOを測定し、データの整合性を保証します。これにより、RTOは計算上の推測から、証明可能で報告可能な指標へと変わります。

ステップ3：SLA違反の監視とアラート

監視スタック（Prometheus、Datadog、Zabbix）は、RTO/RPO SLAを脅かす指標を積極的に追跡する必要があります。以下のアラートルールを設定してください：
* バックアップジョブの失敗： RPOに対する直接的な脅威。
* ログ転送のレイテンシ： ログ転送が生成間隔よりも長くかかる場合。
* ストレージIOPSの制限： クラウドプロバイダー（AWS EBSなど）は、バーストクレジットが枯渇するとIOPSを制限します。これは実際の緊急時にRTOを密かに破壊します。

厳格なSLAを満たすためのデータベースバックアップアーキテクチャの最適化

数学的な計算により現在のアーキテクチャではビジネスSLAを満たせないことが判明した場合、バックアップ戦略を最適化する必要があります。

1. ブロックレベルの増分バックアップを活用する

従来のデータベースダンプ（pg_dumpやmysqldumpなどの論理バックアップ）は、ミッションクリティカルなRTOには遅すぎます。物理的なブロックレベルのバックアップを利用してください。ブロックレベルの増分バックアップは、前回のバックアップ以降に変更されたディスクブロックのみをコピーするため、T(転送)とネットワークオーバーヘッドを劇的に削減します。

2. ストレージスナップショットを利用する

15分未満のRTOを必要とするマルチテラバイト規模のデータベースでは、標準的なネットワーク経由の従来のファイルコピーは物理的に不可能です。SANやクラウドネイティブのストレージスナップショット（AWS EBSスナップショット、Pure Storageなど）との統合により、ほぼ瞬時のT(リストア)が可能になります。その後、データベースエンジンはスナップショットに対してクラッシュリカバリを実行するだけで済みます。

3. 並列処理を実装する

バックアップおよびリストアツールがマルチスレッドを活用していることを確認してください。pgbackrestを使用してPostgreSQLデータベースをリストアする場合や、SQL Serverデータベースをリストアする場合、利用可能なネットワークおよびディスク帯域幅を飽和させるために、並列ワーカー数を明示的に定義してください。

# pgBackRestでの並列リストアの例
pgbackrest --stanza=prod_db --process-max=8 restore

結論

ミッションクリティカルなデータベースのRTOとRPOを計算することは、システムエンジニアリングにおける厳格な演習です。DBAはデフォルトのバックアップ設定を超えて、ストレージI/O、ネットワーク容量、データベースリカバリのメカニズムを数学的にモデル化する必要があります。

ログ生成率のベースライン化、データベースリカバリの各フェーズの理解、そしてCloudSaveのような堅牢なプラットフォームを通じた自動テストの実装により、ITチームは自信を持って災害復旧SLAを保証できます。覚えておいてください：データベース管理の世界において、希望は戦略ではなく、テストされていないバックアップは負債です。

DevOpsエンジニアやDBAが、高度なリカバリメカニズム、CLIツール、自動テストを使用して、ミッションクリティカルなデータベースのRTOとRPOを正確に計算、テスト、最適化する方法を学びましょう。

カテゴリー