こんにちは、エムスリー 製薬企業向けプラットフォームチームでチームSREをやっている後藤です。
10年ぶりにリメイクが発売されたパワポケRに夢中な日々を過ごしています。
この記事は、 エムスリー Advent Calendar 2021 7 日目の記事です。
クリスマス・お正月と穏やかな年末年始を迎えるためにはしっかりしたバックアップは欠かせませんよね?
最近 AWS の Elastic File System (EFS) のバックアップの仕組みを検討していたので、ここでご紹介したいと思います。
あなたのバックアップ、「自動」でいいの?
ご存知の方も多いかもしれませんが、EFS は AWS Backup と連携した自動バックアップが提供されています。
自動バックアップについては公式ドキュメントをはじめ、各所のブログでも紹介されていますね。
自動バックアップの最大の利点は設定が非常に簡単なことです。
EFSの編集画面で「自動バックアップを有効化」というチェックを入れるだけで設定が完了し、バックアップが取得されるようになります。
AWSをはじめマネージドなクラウドサービスを使っていると、少しの作業でやりたいことが実現できて素晴らしい限りです。
しかし、それゆえに細かい確認を怠ってしまって「自動バックアップにチェック入れたのでバックアップは大丈夫です!!」となってしまいがちではないでしょうか。
自動バックアップの仕組みを詳しく調べてみる
EFSの自動バックアップは実際にどのような仕組みになっているのでしょうか。
バックアップに関連する設定を簡単に図解するとこのようになります。
バックアップの設定はバックアッププランというリソースにまとめられており、その中のバックアップルールに開始時刻や頻度を設定します。
そして、リソースの割り当てという項目でバックアップ対象を指定します。
リソースは直接指定もできますし、タグを使って複数まとめて指定もできます。
バックアップルールにはボールト (Vault) という設定項目が存在し、バックアップされたデータはここで指定されたボールトに暗号化されて保存されます。
この構成を理解した上で、自動バックアップの設定を調べてみます。
バックアッププランは aws/efs/automatic-backup-plan というプランが自動で作成されており、その設定に従ってバックアップが取得されるようになっています。
特に重要なバックアップルールを確認してみると下記のような設定になっています。
| 設定項目 | 設定値 |
|---|---|
| 頻度 | 毎日 |
| バックアップ開始時刻 | 5:00 (UTC)から８時間以内に開始 |
| バックアップ完了期限 | 7日 |
| バックアップ保持期間 | 5週間 (35日) |
上記の設定はあなたの要件にあってるでしょうか?
このように、自動バックアップの設定をきちんと確認した上で、要件に適合しているか判断しなければなりません。
「自動バックアップにチェックを入れた」だけでは、要件にあったバックアップができているとは限らないわけです。
要件にあったバックアップの仕組みを構築する
それでは、今回私が検討したバックアップの内容を実例としてご紹介していきたいと思います。
バックアップ対象の情報は下記の通りです。
- 対象は社内システムで使用されているEFS
- システムの利用時間は平日の業務時間中
- EFSの容量は数百MB程度
- EFSのファイルを操作するバッチ処理がいくつか存在する
上記の情報をベースにバックアップの検討をした結果、このシステムでは自動バックアップは採用しませんでした。
特に要件に合わなかったのはバックアップの開始時刻です。
前述の通り自動バックアップの開始時刻は UTC 5:00 (JST 14:00)から８時間以内となっており、日中にバックアップが開始される可能性が高いです。
しかし、このシステムは業務時間外は使用されないので、データの変更もなく区切りとしてもわかりやすい夜間の方がバックアップに適していると言えます。
また、バックアップの開始時間が8時間以内とかなり幅がある点も気になります。
EFSを操作するバッチ処理の時間を避けるため、開始時間はなるべく限定的にしたいです。
このような理由から、バックアップは夜間かつバッチの時間を避けて「JST 22:00から1時間以内に開始、3時間以内に完了」という設定にしました。
自動バックアップの設定に比べて時間の制約を厳しくした形になりますが、そもそもデータ量が多くないため時間内に問題なくバックアップが完了します。
リストアのことも考えよう
ここまでバックアップのことをお話ししてきましたが、リストアのことも考えなければいけません。
AWS Backupではリストアも非常に簡単でコンソールからリストアするポイントを選択してジョブを実行するだけです。
しかし、リストアにおいてもこの手順だけ調べてOKだと思い込んでいてはダメで、まだ注意すべきポイントがあります。
リストアするための権限に注意
例えば自動で取得したバックアップのリストアを実際にやってみましょう。
するとこのようなエラーになるはずです。
緊急事態でリストアしている時にエラーに遭うなんて考えたくもないですね。
原因はバックアップボールトのポリシーにあります。
自動バックアップで使用される aws/efs/automatic-backup-vault というボールトでは下記のアクションが明示的に拒否されているのです。
backup:DeleteBackupVaultbackup:DeleteBackupVaultAccessPolicybackup:DeleteRecoveryPointbackup:StartCopyJobbackup:StartRestoreJobbackup:UpdateRecoveryPointLifecycle
このうち、 backup:StartRestoreJob というアクションがリストアには必要ですが、明示的に拒否されているので AdministratorAccess のポリシーが付与されていても実行できません。
このポリシーを削除しないとリストアはできないので、事前に削除しておく、もしくはリストア手順に明記しておくのがおすすめです。
ここまで設定すれば AdministratorAccess ポリシー相当の権限があるユーザではリストアができるようになります。
ただし、例えば PowerUserAccess ポリシーを付与しているユーザでリストアしようとすると、まだエラーが発生してしまいます。
この原因はまた別にあり、iam:PassRole というアクションへの権限が不足しているためにエラーとなってしまいます。
こちらについては、そもそも我々のチームでは管理者のみリストアできるようにしたかったのでこのままの権限設定としておきました。
それぞれチームでの IAM の運用ポリシーに従い、例えばリストアをする作業者のポリシーを別に定義している場合などは必要に応じて設定してください。
リストアされたファイルの配置に注意
権限エラーをクリアしてジョブを実行して無事完了、といきたいところですがまだ終わりではありません。
AWS Backupのリストアでは、aws-backup-restore_{timestamp} というディレクトリが作られてその配下にリストアしたファイルが配置されます。
既存のファイルが置き換えられるわけではないので、手動でファイルを移動する必要があります。
EFSを操作できる環境があれば、そこで手動なりスクリプトなりでファイル移動をすればいいのですが、今回の我々のシステムは ECS (Fargate) + EFSの構成だったのでなかなかそうもいきませんでした。
そこで、今回は Lambda から EFS を操作してファイルを移動する方法をとりました。
リストアは滅多にやる操作ではないので、EFS をマウントしたマシンを常時用意しておくより Lambda でやる方がコスト面でも優れていると判断しました。
ただし、Lambda は最大タイムアウトが900秒なので、それ以上に処理がかかるような大量データの場合は別の方法を考えなければいけません。
今回のケースでは1分かからずファイルの移動は完了しました。
まとめ
バックアップを検討する時、そこには必ず要件が存在するはずです。
自動バックアップは非常に簡単ですし、これだけで十分というケースも多いと思いますが、盲目的に利用するのではなく本当に要件にあっているのか確認することが重要です。
また、バックアップにおいてリストアは検討が不足しているケースも稀にみられます。
特にリストアは緊急時にやることになる作業ですので、手順を事前に準備してリハーサルをしておきましょう。
We are Hiring!
エムスリーではSREも大募集中です。
クラウド移行やシステムモニタリング、デプロイパイプラインの改善などなど一緒に取り組んでいける方のご応募お待ちしています。
