AWS Backup へのバックアップシステムの移行

f:id:apt-k-ueno:20211217142235j:plain

aptpod Advent Calendar 2021 の21日目を担当します、SREチームの金澤です。

私が所属する SRE チームでは、担当業務の一つに、弊社の製品である intdash のインフラストラクチャをメインとしたクラウドシステムのインフラ設計・構築、監視・バックアップなどの運用業務があります。

バックアップについては、約1年半前、Amazon Web Service(AWS) のマネージドサービスである AWS Backup への移行を開始し、設定のチューニングを行いながら、現在ではバックアップ要件がある AWS リソースほぼすべてを AWS Backup にてバックアップ管理しています。

本記事では、バックアップマネージドサービスである AWS Backup への移行について、現在検討中の内容も交えてご紹介いたします。

AWS Backup とは

公式ドキュメントの言葉を借りますと、一元管理型クラウドバックアップサービスです。

AWS Backup は AWS クラウド内の AWS のサービス間でアプリケーションデータを簡単かつ低コストでバックアップできる一元管理型クラウドバックアップサービスです。

スナップショットとしてバックアップするケースが多い EBS を始め、RDS や EFS など現在11種類のリソースのバックアップが可能*1です。さらに、今年オンライン上で開催されました re:Invent 2021 では、Amazon S3 のバックアップがサポート予定であることが発表*2となり、計12種類となりました。

設定においては、複雑になりがちなバックアップウインドウ*3や、保持しておきたいバックアップファイルの世代管理が容易に設定できます。また、マネージドサービス自体の初期費用はゼロで、使用したい場合は手軽に始めることができます。

バックアップの動作

AWS Backup の動作について簡単に説明します。

AWS Backup では、Backup Plan リソースの内容にしたがってバックアップの動作を決定し、バックアップリソースは Backup Vault というリソースに整理・保管されます。

f:id:aptpod_tech-writer:20211217125427p:plain
AWS Backup で行われるバックアップ動作

Backup Plan では、バックアップの頻度やバックアップウインドウ、保持期間を定めます。また、バックアップ対象を指定する方法を設定します。

f:id:aptpod_tech-writer:20211217125526p:plain
Backup Plan の設定内容

バックアップの設定検討

バックアップを行うにあたり、設定検討した内容です。

環境毎の Backup Vault の作成

通常、開発環境は本番やステージングなど複数の環境があるものと思います。それぞれの環境におけるバックアップの要件も当然異なるため、複数の Backup Vault を作成し運用しています。これにより、それぞれの環境におけるバックアップリソース個数の規模感が明確になり、現状どのくらいのバックアップリソースが存在するか把握できるようになりました。

Backup Vault の作成には個数制限*4があるものの費用自体は発生しないため、管理したい形で構成することができます。

f:id:aptpod_tech-writer:20211217130050p:plain
環境毎の Backup Vault の作成

IaC による管理が可能

弊社のインフラは基本的に IaC*5 を行っており、Terraform にて構築・管理しています。

現在では、IaCによる管理も珍しくないものとなりもはや当たり前と言われそうですが、AWS Backup も Terraform によるコード化が可能で、弊社のインフラストラクチャ管理と親和性が高く難なく組み込むことができました。

バックアップリソースの選択

バックアップするリソースを選択する方法としては、上述の通り以下が存在します。

  • サービス全体(EC2, EBS, ...)
  • リソースID
  • リソースに付与されるタグ

今後変更が見込まれない環境やバックアップ対象が明確に決められている場合は、サービス全体やリソース ID によるバックアップの方が都合が良い場合が存在しますが、変更が見込まれる環境においてはスケールしやすい(バックアップ対象の増減が容易な)リソースタグによる管理が多いと思われます。弊社もリソースタグによる対象管理を行っています。

タグとは別に、AWS Backup ではサービスのオプトインというバックアップ対象を有効または無効化出来る機能があり、併用することでタグ付与における効率化が可能か、と検討していましたが、現状ではそこまで効率化が見込めず、検討時点ではhashicorp/terraform-provider-awsが対応していなかったため、採用していません*6

RDSの継続的バックアップ

AWS RDS は自身でバックアップウインドウを設定し自動バックアップを行うことが出来ます。この自動バックアップが AWS Backup によって管理できるようになりました。バックアップ管理を統合し易くなり、管理性の向上が見込めるようになりました。弊社で稼働している RDS は稼働当初より自動バックアップが設定していますが、そのような目的のもとに AWS Backup への移行を行っています。

f:id:aptpod_tech-writer:20211217004102p:plain
統合後、自動バックアップは AWS Backup 管理である旨が記載される

バックアップのスケールが容易になった

AWS Backup への移行のモチベーションとして一番大きかったのは、それまで稼働していたバックアップシステムのスケーラビリティを改善したいというものでした。

以前は AWS SDK を使用してバックアップを行っていました。当初は問題ありませんでしたが、弊社製品を利用していただく機会が増えることにより、バックアップリソースの数も増加し、次第にスケールの限界が見えるようになりました。その影響を被る前にマネージドサービスへの移行を検討・開始し、現在に至ります。

約1年半前の移行検討を開始した時点と比較して、現在もバックアップリソースの数は増加していますが、バックアップ失敗といったアラートはほとんど見られず、バックアップのスケールに対して特別な意識を持たなくてもよくなりました。

監視

AWS Backup の設定を行いバックアップを開始することができました。次に、バックアップが正常に実行されているかどうかの監視はどのように行えばよいでしょうか。

いくつか方法はあるかと思いますが、弊社では AWS SNS で作成した SNS topic に Backup Vault からバックアップのレスポンスを Slack に通知することで行っています。

f:id:aptpod_tech-writer:20211216233114p:plain
Slack に自動投稿されたバックアップ失敗アラート

バックアップするリソースの数が多い場合は、フィルターをかけた方が視認性的にも費用的にも利点が多いです。現在はレスポンスに含まれる MessageAttributes の Key-Value の値でフィルターし、通知に使用しています。

監査

現在検討中の内容もご紹介します。

先日開催された AWS のイベントである re:Inforce 2021 では AWS Backup Audit Manager が発表されました。*7

これは、現在動作しているバックアップの結果を既定のポリシーに従って評価する、またその評価結果をレポートする機能となります。Audit という名称から想像できるとおり、バックアップにおける監査・コンプライアンスの対応に役立つ機能です。

既定のポリシーとは、

  • バックアップリソースがバックアッププランによって保護されているかどうか
  • バックアッププランの最小頻度と最小保持期間が想定通りとなっているか

など計5種類が設定されていて、バックアップしているリソースに対してポリシーを満たしているかどうか評価され、レポートを指定の S3 バケットにCSVまたはJSONの形式で配信することができます。このレポートをデータソースとして、Amazon QuickSight を利用したダッシュボードを作成し監査対応者などの第三者がリソースバックアップの状況を閲覧するようなこともできると考えています。

f:id:aptpod_tech-writer:20211217130557p:plain
レポートを元に作成したバックアップステータスダッシュボード(のようなもの)

また、リソースバックアップの成功を確認出来るという意味では、上述の監視にも利用出来るものと考えており検討を進めています。

一点、このAWS Backup Audit ManagerAWS Configを用いて実現しています。AWS Configは AWS リソースの設定状況を記録するサービスとなり、AWS Backup Audit Managerにおいては、

  • AWS リソースの設定状況の記録
  • 既定のポリシーによる評価

の2点をAWS Configが担当しています。対象となるリソース数が多い場合は意図せず費用が膨らむ場合があります。そのため、導入には費用算出を考慮した上で検討したほうがよいです。今回は影響が微小となるように、別途用意されている個人アカウントでの検証を行いました。

さいごに

本記事では、AWS Backup への移行として、その際に検討した内容や現在検討中の内容を交えて紹介いたしました。バックアップという比較的地味な領域ではありますが、システム運用の面では重要で不可欠な領域だと考えます。引き続き、有用なサービスや機能の利用を検討しながら、効率的な基盤構築・運用に貢献できるよう努めていきたいと思います。