【AWS】今日からできるAWSでのBCP対策【BCP対策】

BCP対策で検討すべきこと

1. BCPとは

・BCPとは、Business Continuity Planの略で、業務継続計画のことです。
・災害や自己など、不測の事態による業務中断が発生しないよう、また、発生した場合でも速やかに復旧・再開できるよう、優先順位や手順などの行動を、あらかじめ策定し準備しておく行動計画です。

2. BCPで対応すべき主な要因

・BCPというと地震などの自然災害により事業拠点にダメージが発生することで事業がすすめられないことの対策がイメージしやすいですが、他には人為的なミスやサイバー攻撃で業務を進めるために重要なデータが失われることの対策も必要になります。

＜主な要因＞

・人的ミス、サイバー攻撃、システム障害、自然災害 など

3. 復旧目標 (RTO と RPO)

・何らかの要因でデータやシステムに問題が発生した際に、復旧までにどれくらいの停止時間が許されるか、障害が発生した時点からどこまで前までの状態に戻せればよいのかということはその業務やシステムの要件によって異なります。
・BCPの戦略はこれらの要件(PRO,RPO)に合わせて決定することが必要になります。

①RTO ( 目標復旧時間：Recovery Time Objective )

サービスの中断からサービスの復元までの最大許容遅延です。これにより、サービスが利用できないときに許容可能と見なされる時間枠が決まります。

②RPO ( 目標復旧時点：Recovery Point Objective )

最後のデータ復旧ポイントからの最大許容時間です。これにより、最後の復旧ポイントからサービスの中断までの間に許容可能と見なされるデータ損失が決まります。

今日からできるAWSでのBCP対策

1. S3ファイルのバックアップ

①S3のバージョン管理とライフサイクル管理

・S3ファイルを取り込み、日次バッチ処理や月次バッチ処理を行うシステムの場合、S3ファイルを意図せず消してしまった場合のリストアや何かしらの要因で誤った内容で集計した際に正しい状態での再集計が必要です。
・バージョニングとライフサイクル管理の設定方法は過去の記事に投稿していますので以下のURLを参照してください

(S3のバックアップの保持期間とバージョン数の設定画面)

S3バックアップの保持日数とバージョン数の最小値を設定する時の考え方 ※個人的見解

＜ 日次更新ファイルの場合 ＞

・日次更新ファイルの場合、毎日更新されるわけなのでバックアップしたい日数分だけのバージョン数が必要になります
・さらに、日次で更新されたファイルを処理した結果が間違いなく処理されたことを確認する間隔と長期で休業日がある場合はその期間もこの設定の考慮事項になります
・例えば以下のような設定ができると思います

例1：日次バッチが動いていてその結果は毎回確認している。長期休暇が10日あり、翌営業日に確認したときに結果の誤りに気が付いたら最終確認時点にファイルで再実行する

→保持日数：11、非現行バージョン数：11　※休業期間 + 1日

例2：日次バッチが動いていて週1回内容を確認している。確認時に誤りに気が付いたら最終確認時にファイルで再実行する

→保持日数：7、非現行バージョン数：7　※確認の間隔

＜ 月次更新ファイルの場合 >

・月次更新されるファイルの場合も日次処理と同じく、確認が行われる間隔をもとに最小値を検討することができます。

例1：月次バッチが動いており、その結果を毎回確認している。誤った結果になったときは前回のファイルで再実行する

→保持日数：32、非現行バージョン数：1　※確認間隔の日数 + 1日、バージョン数はファイルが月1回更新なら1

例2：月次バッチが動いており、その結果を毎回確認している。誤った結果になったときは前回のファイルで再実行する。ただし顧客との取り決めで処理したファイルを1年間は保持する。

→保持日数：365、非現行バージョン数：12　※確認間隔の日数(顧客との取り決め)。バージョン数はファイルが月1回更新なら12(1年間に更新が発生する回数)

2. RedshiftDBのバックアップ

①スナップショットの自動取得

・RedshiftDBを使用している場合、スナップショットと呼ばれるバックアップを取得することが可能です。
・スナップショットは自動と手動の2種類がありますが、自動の方はバックアップの取得間隔と保持期間を設定することができます。

Redshiftバックアップの取得間隔と保持期間を設定する時の考え方 ※個人的見解

・これもデータの更新頻度によりますが、基本的に日次で業務開始前に取得しておくことが良いと思います。
・日次バッチが動く場合や開発で毎日更新がかかる場合などでも関係者がわかりやすいタイミング(日次バッチ処理が完了した後で、業務での手動更新が入っていない状態)を設定しておくことはDBの運用のしやすさやリストア後の再更新をかけるのもどこから実施するかがわかりやすくなります。そのため、保持期間については特に要件がなければ料金がかからない35日としておいて良いと思います。

※Redhiftスナップショットのコスト

・バックアップを取得するときに気になるコストですが、以下のAWS公式サイトにはこのような記載があります

Amazon Redshift のスナップショットスケジューリング機能を使用して作成される Redshift 自動スナップショットに料金は発生せず、最大 35 日間保持することができます。

3. システム構成のバックアップ

①CloudFormationによる構成のコード化

・上記1，2ではデータに関するバックアップについて説明しましたが、AWSではシステムの構成や作成したスクリプトの定義をCloudFormationを使ってコード化することができます。
・例えばGlueのジョブの定義を誤って消してしまった場合やLambdaに紐づくロール設定を誤って変更した場合に、正常に動いていた状態に戻すためにもCloudFormationは役立ちます
・CloudFormationの定義の仕方とCloudFormaion外で変更が行われたことを検知する(ドリフト検出)については過去の以下の記事で紹介していますので、参考にしておいてください

4. プログラムコードのバックアップ

①CodeCommitでバージョン管理

・IT業界で活躍されている方に対しては言わずもがなですが、プログラムコードやCloudFormatnionなどの定義ファイルはCodeCommit、Gitなどのバージョン管理ツールで管理したほうが良いです。
・LambdaやGlueのスクリプトを直接更新しても良いですが、そのコードはきちんとCodeCommit上でpythonファイルやCloudFormationの中に記載してバージョン管理しましょう。
・これも言わずもがなですが、編集が完了したらなるべく早くプッシュしてリポジトリに上げましょう。ローカルにあるファイルを上げ忘れたまま風になって自分がしばらく業務が出来なくなって全体の業務が停止するなんてことももしかしたらあるかも
・BCPの内容とは少しずれますが、CodeCommit系の記事も過去に書いていますのでその内容もリンクを張っておきます

BCPのシナリオ

・BCP対策はRTOとRPOの要件を考慮して決定することが必要ですが、その対策のシナリオは以下の参考サイトの画像のように大きくは4段階に分けられます
・BCP対策を考えるときはこの4つのシナリオを基本にざっくりと方針を決め、その後より具体的にどのサービスでそのシナリオを実現するかを決めるのが良いと思います
参考：AWSブラックベルト「AWS Backup で実現するVMware Cloud on AWS 環境の簡易的なバックアップと災害対策」

各シナリオの特徴

①バックアップと復元

・データとアプリケーションのバックアップは行うが、実際に稼働するシステムは稼働系1つだけ
・コストが最も低く抑えられる
・待機系のシステムもないため、稼働系が停止したらバックアップから新たに稼働系を構築するなどの手順が必要になり、復旧までの時間が長くなる

②パイロットライト

・稼働系で発生するデータを待機系に常に同期を行い、待機系はシステムの構成(インフラストラクチャ)の定義は構築されているが起動していない状態にした構成(EC2であればインスタンスは停止している状態)。
・稼働系に異常が発生した際に待機系を起動して障害発生時まで同期されていたデータで処理を引き継ぐ
・データが同期されているためRPOは少ないが、システムを停止している状態から起動するためRTOは少し発生する

③ウォームスタンバイ

・稼働系と、稼働系のスペックを落とした状態で起動している待機系を用意しておき、稼働系に障害が発生した際は待機系に処理を移譲して待機系を稼働系として処理を継続させる構成
・待機系は常に稼働しているため、RTOが短縮されている
・ただし待機系も常に起動した状態になるためコストは高くなる

④マルチリージョンのアクティブ/アクティブ

・複数のリージョンで同じシステムを稼働させる構成
・同じスペックのシステムが起動してデータを同期しながら処理を行っているのであるリージョンに異常が発生してもRPO、RTOともに他のシナリオで最も小さい値で他のリージョンで異常が発生したリージョンと同じ処理を行える
・複数のリージョンで同スペックのシステムが常に動くためコストは最も高くなる

さいごに

BCP対策はとても大切な対策です。どんなシステムにおいても避けては通れない検討事項です。
ただし、どこまでの対策が必要なのか、もっともよい対策なのかはそのシステムの特性によって異なります。
1秒のロスが多額の損失を招くようなシステムであれば「マルチリージョンアクティブ/アクティブ」のようなシナリオが必要ですが、例えば月に一度の何らかの報告のためにレポートを出力するようなシステムの場合は次回のレポート作成までに復旧できれば良いのでそこまでのRPO/RTOは求められないと思います。さらにもしコストを徹底的に削減したいような要件があれば、S3のバージョンの数もより削った構成になるかも。
どんな対応もそうですが、その要件に対してまずどんな選択肢があるか、一般的なシナリオや事例を学びそれに対してどんなソリューションが実施されてそれはどんなメリットデメリットが発生するかAWSブログやブラックベルト、その他のサイトやニュースなどで事前に情報収集して自分なりの解釈を持っておくことが大切だと思います。

参考