はじめに
Dr.ワーナーはこのように言っています。
”Everything fails, all at the time."
障害は発⽣するものであり、最終的にはすべてが時間の経過とともにフェイルオーバーします。つまり、ルーターからハードディスクまで、TCPパケットを破壊するオペレーティングシステムからメモリユニットまで、そして⼀時的なエラーから永続的な障害まで、どれもが対象となるのです。
これは、最⾼品質のハードウェアを使⽤しているか、最低料⾦のコンポーネントを使⽤しているかにかかわらず、当たり前のことです。
クラウド設計の原則である「Design by Failure」に基づき、「障害は必ず発生するものとしてコントロールする」ことが重要です。具体的には以下の点を考慮する必要があります。
- データのバックアップ
- 障害部分の切り離し
- 障害に耐えうるワークロードの設計
- 信頼性のテスト
- 災害対策の計画と実施
これらの観点について、ビジネスニーズに応じてコストとのトレードオフを考え、「あえてコントロールしない」という判断も可能です（もちろん、リスクを許容した上での話です）。ビジネスニーズに適した可用性を実現することで、コストを最適化し、ビジネスに投資を集中させることができます。
障害対応において、可用性（High Availability）と災害対策（Disaster Recovery）は異なる目的を持っています（関連性はあります）。
可用性が重視するのはワークロードのコンポーネントの稼働時間であり、ハードウェアやソフトウェア障害によるダウンタイムを最小限に抑えることが目的です。
一方、災害対策（DR）はワークロード全体のコピーをどれだけ確保するか（RPO）と、いかに迅速に復旧するか（RTO）に焦点を当て、災害によるリージョン障害に対応することが目的となります。
一般的なユースケースでは、単一リージョン構成で要件的には十分な場合が多く、リージョン障害に対応するDR構成が必要となるかはお客様の要件次第です。ミッションクリティカルなシステムを除き、コスト面からDR構成は不要で、バックアップだけ別リージョンに保存するケースがよく見られます。
本記事では、リージョン障害を考慮したDR構成を実現するために、ユースケースごとにどのようなサービスを利用するか、具体的な操作や注意事項について自分の知識整理のためにまとめました。
操作方法や機能実装については実際と異なる場合がありますので注意してください。
ユースケース別マルチリージョン対応
バックアップ＆リストア
- データだけ別リージョンにレプリケーションする構成。おそらく一番よく利用するユースケース(個人の感想です)
- スナップショットの最終取得時点がRPOとなり、障害が発生した場合は、CloudFormationなどのIaCサービスを使ってDRサイトを構築＋データのリストアまでがRTOとなる構成。比較的、RTOの要件が低い場合に利用します
S3
クロスリージョンレプリケーション
S3に保存されているログ、ユーザデータ、スナップショットデータなどを別リージョンにレプリケーションすることで、DR構成の実現だけではなく、スケーラビリティ・パフォーマンス・高可用性のメリットが生じます
- S3バケットの管理タブから「レプリケーションルール」を設定します。レプリケーションの前提条件として、バケットのバージョニングを有効にしておきます
- レプリケーションルールで指定するオプションとしては、送信先バケット(別アカウントでもOK)、IAMロール、暗号化の有無(暗号化する際には暗号化キー)、送信先バケットのストレージクラス(Glacierも可)が指定可能です
- 送信先バケットにおいてレプリケーション設定を送信元のバケットにすることで、双方向レプリケーションが実現可能です
- 単一のバケットから複数の送信先バケットにレプリケーションすることも可能です
- レプリケーションルールによって作成されたオブジェクトは、別のレプリケーションルールによる複製の対象外となります(循環レプリケーションとかはされないことに)
- 「追加のレプリケーションオプション」は以下のとおり
- レプリケーション時間をコントロールしたい場合(新しいオブジェクトの99.9%が15分以内にレプリケートされることを保証する)にはRTCを有効にします(有償)
- レプリケーションが失敗したときに通知を行いたい場合には、「レプリケーションメトリクス」を有効にします
- 削除を反映したいときには、「削除マーカーのレプリケーション」を有効にします
EC2
AMI
本番環境と同様の構成のEC2をDRサイトで起動したい場合に利用します。AMI(OSイメージ)を取得する際に、EBSのスナップショットもあわせて取得することが可能です。
EBS
EBSのみスナップショットを取るユースケースは少ないかもしれませんが、スナップショットのデータを別リージョンにコピーすることが可能です。
AMIとスナップショットについて
- 元のEC2インスタンスを再現するには、インスタンスの構成情報を含むAMIとEBS内のデータ(OS実データやミドルウェアなど)を含むスナップショットの両方が必要です
- AMIを取得する際には同時にEBSのスナップショットを含めることができるため、AMIとスナップショットを個別にバックアップする必要性はあまりありません
- ライフサイクル的に、更新頻度の高いEBSのみスナップショットを高頻度にし、更新頻度の高くないAMIは低頻度に取得するなどして、容量を抑えることも実現可能です
- AMI、スナップショットいずれもインスタンスタイプやネットワークなどの情報は保持していないため、起動テンプレートと組み合わせて実行する必要があります(起動テンプレートはクロスリージョンコピーには未対応)
- 起動テンプレートについては以下を参照してください
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/create-launch-template.html
RDS
バックアップ
自動バックアップを有効にすると、DBインスタンスのバックアップ(すべてのスナップショットとトランザクションログ)のクロスリージョンコピーを取ることができます。
スナップショット
手動で取得したスナップショットをクロスリージョンコピーすることが可能です。
ECR
クロスリージョンレプリケーション
プライベートECRレジストリは、クロスリージョンレプリケーションおよびクロスアカウントレプリケーションの両方をサポートしています。
クロスリージョンレプリケーションの場合は、送信元リポジトリの設定を行います。
参考までに、クロスアカウントレプリケーションの場合は、送信元と送信先でそれぞれ送信先のアカウントを指定、送信先では送信元のアカウントを指定します。
レジストリ内のすべてのプライベート ECR リポジトリが、異なるアカウントやリージョンにある複数の他のリポジトリにイメージを自動的にコピーします。リージョン内でイメージをプルできるようになるため、プルにかかるレイテンシが削減され、コンテナの起動が速くなります。また異なるリージョンのイメージは、アーティファクトが地理的に分散しているため、ディザスタリカバリの要件を満たすのに役立ちます。