はじめに

こんにちは、ENKです。
 

今回のテーマは「楽にかつ安全にシステムを運用する」方法について、AWSクラウドのバックアップ／リストア・リカバリーに焦点を当ててお話ししたいと思います。
バックアップはシステム運用に欠かせないデータ保護手段の一つであり、データの物理的・論理的な喪失や不整合からの復元に使用されます。その復元の際は、データが正確な状態を保持していた時点への迅速な回復が求められます。
情報システムでは、データがビジネス活動の源泉であるため、確実にバックアップを取得し、リストア・リカバリーも確実に実施できることが必要になります。

目次

  1. 本記事の対象範囲
  2. バックアップ／リストア・リカバリーとは
  3. AWSにおける基本的なバックアップ方法
  4. バックアップを取得するタイミング
  5. まとめ

1.本記事の対象範囲

本記事で取り扱うバックアップは、主に業務データが配置されるサービスに焦点を当てています。システム全体の復元には設定値等も含めたバックアップが必要になりますが、IaC（Infrastructure as Code）の利用を前提とし、設定値等は設計書やコードリポジトリで適切に管理されていると仮定し、本記事ではこれらに関する説明は省略させていただきます。

なお、AWSのコードリポジトリはCodeCommitというサービスを利用します。このサービスはリージョンサービスの一つであり、リポジトリのデータは各リージョンのS3上に配置され、安全に利用することが可能です。しかしながら、リージョンサービスはリージョン障害に対応することが難しいため、現時点でも個別のバックアップ戦略が必要となると考えられます。

AWS CodeCommit での耐障害性
AWS グローバルインフラストラクチャは AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。AWS リージョン には、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている物理的に独立・隔離された複数のアベイラビリティーゾーンがあります。アベイラビリティーゾーンを使用すると、中断することなくゾーン間で自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用できます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性が高く、フォールトトレラントで、スケーラブルです。https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/disaster-recovery-resiliency.html
 

Q: どうすればリポジトリをバックアップできますか？
git clone を完全に実行してローカルコピーを作成している場合、そのコピーを使用してデータを復元できます。追加のバックアップを作成する場合は、複数の方法があります。1 つは Git をバックアップサーバーにインストールし、 git clone コマンドを使用したスケジュールジョブを実行して定期的にリポジトリのスナップショットを作成することです。増分変更のみをコピーする場合は git clone ではなく git pull を使用します。バックアップサーバーおよびポーリング頻度の設定によっては、これらの操作によって追加のユーザーまたはリクエスト料金、またはその両方が発生する可能性があることに注意してください。
https://aws.amazon.com/jp/codecommit/faqs/

2.バックアップ／リストア・リカバリーとは

AWSクラウドの活用により便利さが増しても、バックアップやリストア・リカバリーの考え方自体は変わりません。従来の理念に基づく便利な機能がAWSクラウド上で利用可能となっているのが現状です。

以下の表に示す機能例は一部のものですが、AWSでは各種データ保存領域に対し、適宜バックアップ／リカバリー・リストアの方法が用意されています。これらをうまく活用していくためには、RPO（目標復旧時点）/ RTO（目標復旧時間）やDR戦略の有無を考慮した上で、バックアップの周期や世代管理から復旧作業、さらにはDR時の待機環境の復旧運用といった要素を全体的に把握しつつ、どのサービスをどのように使い分けるかを設計していく必要があります。

方式

説明

AWS機能例

バックアップ

データを別の場所に複製して安全に保管しておくこと。また複数世代取得して同様に保管することで、データの消失や破損に備えることができる。
  • AMI作成
  • EBSスナップショット
  • RDSスナップショット

リストア

データをバックアップから元の状態に復元すること。
  • AMIからインスタンス作成
  • EBSスナップショットからのボリューム作成
  • RDSスナップショットからの復元

リカバリ

データに必要な情報を加えて戻すこと。リストアと合わせて、サーバー上のデータを最新状態にするために用いる。
  • RDSポイントインタイムリカバリ
  • AMIからインスタンス作成時の最新アプリデプロイ（CodeDeploy利用）

3.AWSにおける基本的なバックアップ方法

先程も少し触れましたが、AWSではデータが配置される各サービスに対するバックアップの仕組みが用意されています。これらサービスごとのバックアップ体制がシステム運用の煩雑さを引き起こす要因になりえるため、複数の機能が一体化された「AWS Backup」の利用を推奨します。

サポートしているサービスは以下のとおりであり、頻繁に利用するサービスの殆どはカバーしているのではないでしょうか。

  • Amazon Elastic Compute Cloud (Amazon EC2)
  • Amazon Simple Storage Service (Amazon S3)
  • Amazon Elastic Block Store (Amazon EBS)
  • Amazon DynamoDB
  • Amazon Relational Database Service (Amazon RDS)
  • Amazon Aurora
  • Amazon Elastic File System (Amazon EFS)
  • FSx for Lustre
  • FSx for Windows File Server
  • Amazon FSx for NetApp ONTAP
  • Amazon FSx for OpenZFS
  • AWS Storage Gateway (ボリュームゲートウェイ)
  • Amazon DocumentDB
  • Amazon Neptune
  • Amazon Redshift
  • Amazon Timestream
  • VMware Cloud on AWS
  • VMware Cloud on AWS Outposts
  • AWS CloudFormation
  • SAP HANA データベース

 

サポート対象の AWS リソースとサードパーティーアプリケーション
https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/whatisbackup.html#supported-resources

AWS Backupの主な機能は以下の通りです。この機能を利用しない場合、Lambdaを用いてバックアップ機能を開発するか、専用のバックアップ製品を導入する必要があります。しかし、AWS Backupの利用により、そのような手間を省きつつ、より簡単にシステム運用を行うことが可能となります。
 

AWS Backup機能概要

  • 一元管理されたバックアップ管理
  • ポリシーベースのバックアップ
  • タグベースのバックアップポリシー
  • ライフスタイル管理ポリシー
  • リージョン間バックアップ
  • アカウント間管理およびアカウント間バックアップ
  • AWS Backup Audit Managerでの監査とレポート作成
  • 増分バックアップ
  • フルAWS Backup管理
  • バックアップアクティビティモニタリング
  • バックアップ保管庫のデータ保護

4.バックアップを取得するタイミング

有効なバックアップサービスを利用しても、緊急事態に対応できるバックアップが確保できていなければ意味がありません。この点はRPO／RTOの要件やデータ更新の頻度により、選択肢が変わってきます。様々な手段と組み合わせが可能ですが、基本的には以下の観点からの検討が適切だと考えられます。ある程度検討方針が定まったら、AWS Backup機能で実現できることを確認し、システム運用を楽にしていくことができます。
 

コンピュートサービス
OSやミドルウェアの更新は運用段階では比較的低頻度で行われることが多いため、変更が行われるタイミングにバックアップを取ることで基本的に問題はありません。それに加えて、稼働するアプリケーションについては、CodeDeploy等を利用して初回起動時に最新情報を反映するようにすると、当サービスの最新状態が常に維持することが可能になります。

時間

RPO（目標復旧時点）

RTO（目標復旧時間）

長い
  •  設定変更時にバックアップ
  • 用意された復旧手順を用いて対応

短い
  •  設定変更時にバックアップ
  • 障害イベントが生じた際、自動的に復旧できるように、IaCやLambdaを利用して、最新のバックアップからの自動復旧を検討

ストレージ（EBS）サービス
最近の傾向として、EBSに直接データを保管するのは推奨される手法ではないと言えます。データ配置もなるべく分離することが望ましいと考えられます。しかし、何らかの理由でデータをEBSに配置しなければならない場合もありますので、そのような時は以下に示す方法が参考になるかと思います。

時間

RPO（目標復旧時点）

RTO（目標復旧時間）

長い
  • 日次バックアップを検討
  • 用意された復旧手順を用いて対応

短い
  • サードベンダーのツールを利用したレプリケーションを検討
  • レプリケーションされたボリュームの再アタッチを自動化して対応を検討

ストレージ（S3）サービス
S3には大量のデータが保存されていることが多く、日次バックアップなどは現実的な手法ではありませんので、レプリケーション機能を検討ください。またレプリケーション先のコストについては、ライフサイクル機能でRTOを鑑みGlacierに移すなどを巧く利用することが可能です。

時間

RPO（目標復旧時点）

RTO（目標復旧時間）

長い
  • コストを考慮し、同期／非同期レプリケーションを用いたバックアップを検討
  • コストを意識しデータをGlacierから復旧
  • バージョニングからの元ファイル復旧を検討

短い
  • コストを考慮し、同期／非同期レプリケーションを用いたバックアップを検討
  • バージョニングからの元ファイル復旧を自動化含め検討

DBサービス関連
DBサービスのほとんどは、スナップショットによるバックアップやポイント・イン・タイム・リカバリー、さらにはレプリケーションやグローバルDBといった多様な方式を提供しています。そのため、要件に応じて幅広く選択して利用することが可能です。

時間

RPO（目標復旧時点）

RTO（目標復旧時間）

長い
  • 日次バックアップを検討
  • 用意された復旧手順を用いて対応

短い
  • 一日に数回バックアップを取得
  • ポイントインリカバリの利用を検討
  • コストを考慮し、同期／非同期レプリケーションを用いたバックアップを検討
  • 障害イベントが生じた際、自動的に復旧できるように、IaCやLambdaを利用して、最新のバックアップからの自動復旧を検討
  • コストを考慮し、同期／非同期レプリケーションを用いたバックアップを検討

5.まとめ

情報システムの運用ではバックアップが不可欠ですが、データを安全に、また常に利用可能な状態に保つのは簡単なことではありません。この問題をAWSのマネージドサービスで運用することで、多くの人が利便性を享受できるのではないでしょうか。