10/03AWS2024年10月3日AWSを用いたシステム開発においてDBのバックアップ設計について検討しました。その際に参照したAWSホワイトペーパーを自分なりに解読したのでアウトプットのために記事にしました。筆者と同じくデータのバックアップ設計を考えられる方に参考にしていただければ幸甚です。今回解説するホワイトペーパーは米国の金融機関のデータバックアップの設計についてです。Council)の要件に準拠したデータ保護やバックアップの設計を行う方法を詳しく解説しています。データバックアップや復元の戦略に焦点を当て、万が一の障害やサイバー攻撃からデータを守るための仕組みが紹介されています。本章からホワイトペーパーの各章に記載されていることを要約して解説していきます。本ホワイトペーパーには専門用語が頻繁に出てくるため、適宜補足を入れていきます。概要(Overview)金融機関は、非常に厳格な規制のもとで運営されており、そのシステムやデータが常に安全かつ利用可能であることが求められています。アメリカのFFIECによる「ビジネス継続性管理(BCM)」のガイドラインに従う必要があります。このホワイトペーパーは、金融機関がAWSのリレーショナルデータベースサービス(RDSやAurora)を利用して、この規制に対応する方法が説明されています。補足:FFIECのガイドラインは、金融機関がシステムのダウンやデータ損失があった場合でも、迅速に復旧できるようにするためのルールです。考慮事項(Considerations)このセクションでは、AWSでのバックアップ設計に必要な前提知識が紹介されています。Backup、Glueに関する基本知識があることを前提に記載されている旨の説明があります。バックアップ計画を実行するには、AWSアカウントを設定し、必要な権限やサービスを使える状態にしておく必要があります。補足:AWSでは、複数のサービスを連携して動作できます。ここで説明されているEC2は仮想サーバー、S3はデータの保存場所、RDSはデータベースサービスと理解してください。architecture)RDSやAuroraのエアギャップバックアップのアーキテクチャエアギャップバックアップとは、データが他のシステムやネットワークから物理的かつ論理的に隔離されているバックアップのことです。AWSでは、RDSやAuroraが提供する機能を活用することで、バックアップを自動的に別の場所に保存し、災害時やサイバー攻撃によるデータ損失に備えることができる旨の説明がありました。バックアップの復元時間(RTO)や、データをどれくらい前まで戻せるか(RPO)についても設計段階で考慮する必要が説明されています。補足:エアギャップとは、データを外部からアクセスできないように隔離することです。RTOは「どれだけ早くシステムを復旧できるか」、RPOは「どれだけ最近のデータまで戻せるか」を示す指標です。backups)イミュータブルバックアップとは、バックアップデータが一定期間変更や削除できない状態に保つことを指します。Lockという機能を使い、バックアップデータを特定の期間中、絶対に変更できないように保護することができます。これにより、サイバー攻撃や内部からの不正な操作によるデータ破損を防ぎます。補足:イミュータブル(immutable)とは、「変更できない」という意味です。データを一度保存したら、特定の期間は誰も変更や削除できないようにする仕組みです。Backupは、複数のAWSサービスのバックアップを一元的に管理できるサービスです。金融機関などの規制対象企業にとっては、コンプライアンスに対応するためのバックアップ管理が必要です。Backupを使うことで、AWSの複数アカウントやリージョンにまたがるバックアップを一括して管理でき、データの安全な保存や復元が簡単に行える旨の解説がありました。データの変更や削除を防ぐために、イミュータブルなバックアップを作成することもできます。補足:クロスアカウントやクロスリージョンバックアップとは、複数のアカウント間や、異なる地理的なリージョンにバックアップをコピーすることです。これにより、災害などの大規模な障害に備えられます。S3に保存する方法が説明されていました。Glueは、データを処理して別の場所に移動したり、データを変換するためのサービスです。Lockを使って、変更不可能な状態に保つことができます。この方法は、データベースのフルバックアップを安全に保管し、必要に応じて復元するために役立ちます。Glueはデータを自動的に変換したり移動したりするためのツールで、S3はデータを保存するための場所です。結論(Conclusion)本ホワイトペーパーの結論として、金融機関がAWSを使ってFFIECの規制要件を満たすためのデータバックアップと保護方法を効果的に設計するための手法を説明したことが書かれています。データの破壊や改ざんを防ぐためのエアギャップバックアップや、イミュータブルバックアップの重要性が強調されていました。補足:結論では、金融機関が直面するリスク(データ破壊やサイバー攻撃)に対処するために、AWSがどのように役立つかがまとめられていました。Recovery)の設定を候補とする場合があると思います。BackupとPITRの用途の違いを追加調査しました。補足:PITRは、データベースのトランザクションログを保存し、特定の時点にデータベースを復元するための機能です。AWSではRDSやDynamoなどのあらゆるデータベースサービスにオプションとして設定が可能です。Backupは障害への備えなどの大規模長期間のバックアップが得意なのでそれぞれ補完しあって使うのが良いことがわかりました。PITRは、短期間のデータ回復が必要な場合に適しており、運用中のデータベースの特定の時点に戻すために使用されます。日々の操作ミスや小規模な障害に対処できます。Backupは、長期間にわたるバックアップ保持や、コンプライアンス要件に対応するためのバックアップ管理に適しており、大規模な障害や災害時のデータ復旧に使用されます。クロスアカウントやクロスリージョンでのバックアップや、変更不可能なイミュータブルバックアップを実現できるため、信頼性の高いデータ保持が可能です。Recovery)の向き不向き小規模障害や誤操作によるデータの復旧に適しています。短期間のデータ損失の防止:数分前のデータまで復元可能であり、細かい復元ポイントが必要なシナリオに適しています。小規模障害や誤操作:小規模な障害や、誤操作によるデータ損失に対応する場合に有効です。短いRPO/RTO:RPOは数分、RTOは数分から数時間とされ、短い時間での復元に適しています。補足:RPOは「どれだけ最近のデータまで戻せるか」、RTOは「どれだけ早くシステムを復旧できるか」を示す指標です。逆にPITRは以下のユースケースでは不向きです。大規模障害やログの破損に弱い:PITRはデータベースのログに基づく復旧ため、もしログが破損したり削除された場合、完全な復旧ができない可能性があります。Backupなど)が向いています。35日以上保持できない:PITRのトランザクションログはデフォルトで35日間しか保持できません。それ以上の長期バックアップや、コンプライアンス要件に応じた特定の保持期間を設定したい場合には、PITRは不向きです。クロスリージョンやクロスアカウントのバックアップができない:PITRのバックアップデータは通常、同一リージョン内で管理されます。そのため、異なるリージョンやアカウントにデータをコピーして保管したい場合には、PITRだけでは不十分です。Backupは、バックアップの一元管理や長期間の保存、イミュータブル(変更不可)バックアップ、大規模障害などに向いています。逆に、PITRが得意な細かな巻き戻しには不向きです。長期的なバックアップ管理:複数アカウントやリージョンを跨いでバックアップを管理し、コンプライアンス要件に応じた長期保存が可能です。Lock機能を使うことで、バックアップデータの変更や削除を防ぎ、セキュリティ強化に役立ちます。大規模障害や長期間保存:大規模な障害や災害時のデータ復旧、コンプライアンスに必要な長期間のデータ保持に適しています。クロスリージョンやクロスアカウントでの保管が可能です。中程度のRPO/RTO:RPOは数分から数時間、RTOは数時間に及ぶ場合があり、全データベースの大規模な復元が必要なシナリオに適しています。Backupの弱みとなります。(PITRと補完できる弱みもあります。)任意時点への復旧は不可:PITRのように頻繁なログ保存を行わないため、数分単位の任意の時点にデータを復元するようなケースには不向きです。Backupは、主にフルバックアップや全体を復元するために使用されるため、「特定のテーブルの特定のレコードの復元」といったデータベースの一部だけを選んでの復元には向いていません。Backupを使用してデータを復元する際、特に大規模なデータセットや複雑なシステムの復旧には時間がかかることがあります。これに対して、PITRや読み取りレプリカを使用する方が、迅速な復旧(短いRTO)を実現できる場合があります。最後に(筆者の感想)このホワイトペーパーは英語で書かれており、専門用語が多く使われていたため、解読に苦労しました。原文では、さらに具体的な設計方法が詳しく述べられています。具体的な手順や設計に興味がある方は、ぜひ原文にも目を通してみてください。今回のケースはアメリカの銀行システムに関するもので、非常に厳密なバックアップ要件を満たす設計が紹介されていました。他のシステム構築においては、ここまでの設計は過剰かもしれませんが、AWSを活用した最も厳格なバックアップ設計として参考になる考え方だと感じました。この設計の考え方を基に、各システム開発の設計に役立てていければと思います。関連記事AWSとAzureの主要サービ...[AWSコード生成AI]Cod...EC2をApacheでSSL(...[初心者向け]NginxでEC...【AWS】SNSでスマホにSM...【AWS】former2をCl...[AWS]ACMがドメインのW...【完全版】AWSでWordPr...syoシステムエンジニアAWSを中心としたクラウド案件に携わっています。IoTシステムのバックエンド開発、Datadogを用いた監視開発など経験があります。IT資格マニアでいろいろ取得しています。理系の大学院を卒業IT企業に就職AWSのシステム導入のプロジェクトを担当ランキングランキングに参加しています。クリックして応援いただけると嬉しいです。Practitionerとは?勉強方法と教材紹介AWSにおけるDBバックアップの設計に関するホワイトペーパーの要約と解説ランキングランキングに参加しています。クリックして応援いただけると嬉しいです。