AWSにおけるDBバックアップの設計に関するホワイトペーパーの要約と解説

AWSを用いたシステム開発においてDBのバックアップ設計について検討しました。その際に参照したAWSホワイトペーパーを自分なりに解読したのでアウトプットのために記事にしました。筆者と同じくデータのバックアップ設計を考えられる方に参考にしていただければ幸甚です。

はじめに　今回解説するホワイトペーパーの紹介

今回解説するホワイトペーパーは米国の金融機関のデータバックアップの設計についてです。金融機関は厳密なデータ保護を要求されるため、他のシステム設計でも参考に出来る部分は大いにあると思います。

↓今回要約・解説するホワイトペーパー

このホワイトペーパーでは、AWSのクラウドサービスを活用して、金融機関がFFIEC（Federal Financial Institutions Examination Council）の要件に準拠したデータ保護やバックアップの設計を行う方法を詳しく解説しています。特に、データバックアップや復元の戦略に焦点を当て、万が一の障害やサイバー攻撃からデータを守るための仕組みが紹介されています。

要約と解説

本章からホワイトペーパーの各章に記載されていることを要約して解説していきます。なお、本ホワイトペーパーには専門用語が頻繁に出てくるため、適宜補足を入れていきます。

概要（Overview）

金融機関は、非常に厳格な規制のもとで運営されており、そのシステムやデータが常に安全かつ利用可能であることが求められています。特に、アメリカのFFIECによる「ビジネス継続性管理（BCM）」のガイドラインに従う必要があります。このホワイトペーパーは、金融機関がAWSのリレーショナルデータベースサービス（RDSやAurora）を利用して、この規制に対応する方法が説明されています。

• 補足：FFIECのガイドラインは、金融機関がシステムのダウンやデータ損失があった場合でも、迅速に復旧できるようにするためのルールです。

考慮事項（Considerations）

このセクションでは、AWSでのバックアップ設計に必要な前提知識が紹介されています。本ガイドを読み進めるにはEC2、RDS、Aurora、Amazon S3、IAM、Organizations、KMS、AWS Backup、Glueに関する基本知識があることを前提に記載されている旨の説明があります。バックアップ計画を実行するには、AWSアカウントを設定し、必要な権限やサービスを使える状態にしておく必要があります。

• 補足：AWSでは、複数のサービスを連携して動作できます。ここで説明されているEC2は仮想サーバー、S3はデータの保存場所、RDSはデータベースサービスと理解してください。

エアギャップバックアップアーキテクチャの構築（Provisioning an “air-gapped” data backup architecture）

エアギャップバックアップとは、データが他のシステムやネットワークから物理的かつ論理的に隔離されているバックアップのことです。AWSでは、RDSやAuroraが提供する機能を活用することで、バックアップを自動的に別の場所に保存し、災害時やサイバー攻撃によるデータ損失に備えることができる旨の説明がありました。また、バックアップの復元時間（RTO）や、データをどれくらい前まで戻せるか（RPO）についても設計段階で考慮する必要が説明されています。

• 補足：エアギャップとは、データを外部からアクセスできないように隔離することです。RTOは「どれだけ早くシステムを復旧できるか」、RPOは「どれだけ最近のデータまで戻せるか」を示す指標です。

変更不可能な（イミュータブル）データベースバックアップ（Design for immutable database backups）

イミュータブルバックアップとは、バックアップデータが一定期間変更や削除できない状態に保つことを指します。AWSでは、S3のObject Lockという機能を使い、バックアップデータを特定の期間中、絶対に変更できないように保護することができます。これにより、サイバー攻撃や内部からの不正な操作によるデータ破損を防ぎます。

• 補足：イミュータブル（immutable）とは、「変更できない」という意味です。データを一度保存したら、特定の期間は誰も変更や削除できないようにする仕組みです。

AWS Backupを利用したイミュータブルバックアップの集中管理（Design for centralized immutable database backup management using AWS Backup）

AWS Backupは、複数のAWSサービスのバックアップを一元的に管理できるサービスです。特に、金融機関などの規制対象企業にとっては、コンプライアンスに対応するためのバックアップ管理が必要です。AWS Backupを使うことで、AWSの複数アカウントやリージョンにまたがるバックアップを一括して管理でき、データの安全な保存や復元が簡単に行える旨の解説がありました。また、データの変更や削除を防ぐために、イミュータブルなバックアップを作成することもできます。

• 補足：クロスアカウントやクロスリージョンバックアップとは、複数のアカウント間や、異なる地理的なリージョンにバックアップをコピーすることです。これにより、災害などの大規模な障害に備えられます。

AWS GlueとAmazon S3 Object Lockを使った完全なデータベースコピーの作成（Design for immutable full database copies using AWS Glue and Amazon S3 Object Lock）

このセクションでは、AWS Glueを使ってデータベース全体のコピーを作成し、Amazon S3に保存する方法が説明されていました。AWS Glueは、データを処理して別の場所に移動したり、データを変換するためのサービスです。作成したデータベースコピーは、S3のObject Lockを使って、変更不可能な状態に保つことができます。この方法は、データベースのフルバックアップを安全に保管し、必要に応じて復元するために役立ちます。

• 補足：AWS Glueはデータを自動的に変換したり移動したりするためのツールで、S3はデータを保存するための場所です。

結論（Conclusion）

本ホワイトペーパーの結論として、金融機関がAWSを使ってFFIECの規制要件を満たすためのデータバックアップと保護方法を効果的に設計するための手法を説明したことが書かれています。データの破壊や改ざんを防ぐためのエアギャップバックアップや、イミュータブルバックアップの重要性が強調されていました。

• 補足：結論では、金融機関が直面するリスク（データ破壊やサイバー攻撃）に対処するために、AWSがどのように役立つかがまとめられていました。

追加調査 PITRでは十分ではないケース

クラウドのデータベースのバックアップを考える際、一番気軽に設定できるPITR（Point-In-Time Recovery）の設定を候補とする場合があると思います。本ホワイトペーパーで述べられていたAWS BackupとPITRの用途の違いを追加調査しました。

補足：PITRは、データベースのトランザクションログを保存し、特定の時点にデータベースを復元するための機能です。AWSではRDSやDynamoなどのあらゆるデータベースサービスにオプションとして設定が可能です。

結論としてはPITRは細かな誤操作による復旧が得意で、AWS Backupは障害への備えなどの大規模長期間のバックアップが得意なのでそれぞれ補完しあって使うのが良いことがわかりました。

• PITRは、短期間のデータ回復が必要な場合に適しており、運用中のデータベースの特定の時点に戻すために使用されます。日々の操作ミスや小規模な障害に対処できます。
• AWS Backupは、長期間にわたるバックアップ保持や、コンプライアンス要件に対応するためのバックアップ管理に適しており、大規模な障害や災害時のデータ復旧に使用されます。また、クロスアカウントやクロスリージョンでのバックアップや、変更不可能なイミュータブルバックアップを実現できるため、信頼性の高いデータ保持が可能です。

PITR（Point-In-Time Recovery）の向き不向き

小規模障害や誤操作によるデータの復旧に適しています。

• 短期間のデータ損失の防止：数分前のデータまで復元可能であり、細かい復元ポイントが必要なシナリオに適しています。
• 小規模障害や誤操作：小規模な障害や、誤操作によるデータ損失に対応する場合に有効です。
• 短いRPO/RTO：RPOは数分、RTOは数分から数時間とされ、短い時間での復元に適しています。

補足：RPOは「どれだけ最近のデータまで戻せるか」、RTOは「どれだけ早くシステムを復旧できるか」を示す指標です。

逆にPITRは以下のユースケースでは不向きです。

• 大規模障害やログの破損に弱い：PITRはデータベースのログに基づく復旧ため、もしログが破損したり削除された場合、完全な復旧ができない可能性があります。データ破損やサイバー攻撃からの完全な保護には、ログに依存しない方法（例：AWS Backupなど）が向いています。
• 35日以上保持できない：PITRのトランザクションログはデフォルトで35日間しか保持できません。それ以上の長期バックアップや、コンプライアンス要件に応じた特定の保持期間を設定したい場合には、PITRは不向きです。
• クロスリージョンやクロスアカウントのバックアップができない：PITRのバックアップデータは通常、同一リージョン内で管理されます。そのため、異なるリージョンやアカウントにデータをコピーして保管したい場合には、PITRだけでは不十分です。

PITRの不向きをAWS Backupで補完する

対してAWS Backupは、バックアップの一元管理や長期間の保存、イミュータブル（変更不可）バックアップ、大規模障害などに向いています。逆に、PITRが得意な細かな巻き戻しには不向きです。

• 長期的なバックアップ管理：複数アカウントやリージョンを跨いでバックアップを管理し、コンプライアンス要件に応じた長期保存が可能です。
• イミュータブル（変更不可能）バックアップ：AWS BackupとS3 Object Lock機能を使うことで、バックアップデータの変更や削除を防ぎ、セキュリティ強化に役立ちます。
• 大規模障害や長期間保存：大規模な障害や災害時のデータ復旧、コンプライアンスに必要な長期間のデータ保持に適しています。クロスリージョンやクロスアカウントでの保管が可能です。
• 中程度のRPO/RTO：RPOは数分から数時間、RTOは数時間に及ぶ場合があり、全データベースの大規模な復元が必要なシナリオに適しています。

一方、以下のケースはAWS Backupの弱みとなります。（PITRと補完できる弱みもあります。）

• 任意時点への復旧は不可：PITRのように頻繁なログ保存を行わないため、数分単位の任意の時点にデータを復元するようなケースには不向きです。
• 部分的な復旧には不向き：AWS Backupは、主にフルバックアップや全体を復元するために使用されるため、「特定のテーブルの特定のレコードの復元」といったデータベースの一部だけを選んでの復元には向いていません。
• 大規模なデータベースの復元にはRTOが長くなる：AWS Backupを使用してデータを復元する際、特に大規模なデータセットや複雑なシステムの復旧には時間がかかることがあります。これに対して、PITRや読み取りレプリカを使用する方が、迅速な復旧（短いRTO）を実現できる場合があります。

最後に（筆者の感想）

このホワイトペーパーは英語で書かれており、専門用語が多く使われていたため、解読に苦労しました。原文では、さらに具体的な設計方法が詳しく述べられています。具体的な手順や設計に興味がある方は、ぜひ原文にも目を通してみてください。

今回のケースはアメリカの銀行システムに関するもので、非常に厳密なバックアップ要件を満たす設計が紹介されていました。他のシステム構築においては、ここまでの設計は過剰かもしれませんが、AWSを活用した最も厳格なバックアップ設計として参考になる考え方だと感じました。この設計の考え方を基に、各システム開発の設計に役立てていければと思います。