🌏

レンティオのディザスタリカバリ(災害復旧)への取り組み

2023/09/15に公開

はじめに

こんにちは、レンティオの坂元です。

レンティオでは、AWS CopilotAWS CDKを使ってAWSでインフラ環境を構築しています。

これまでマルチAZ対応はできていましたが、東京リージョンが何らかの理由でダウンした場合に備え、他リージョン(ここでは大阪リージョン)でサービスを復旧できるようにディザスタリカバリの対応しました。

この記事では、ディザスタリカバリについてどのような対応をしたのか、AWS Copilotを使った他リージョンへのサービスのデプロイについて共有できればと思います。

レンティオのインフラ構成

レンティオのサービスは大まかに図のような構成になっています。
ECS、NATゲートウェイ、ALB、VPCやサブネットなどはAWS Copilotで構築しています。
それ以外のリソース(Auroraや、ElastiCache、CloudFrontなど)はAWS CDKで構築しています。

ディザスタリカバリについて

ディザスタリカバリは、組織がテクノロジー関連の災害を予測して対処するプロセスです。どの企業の IT システムも、停電、自然災害、セキュリティに関する問題などの予測できない状況が原因となって予期せずダウンする可能性があります。ディザスタリカバリには、そのようなイベントから迅速に復旧するための企業の手順とポリシーが含まれます。 ディザスタリカバリとは何ですか?

ディザスタリカバリの戦略には

  1. バックアップと復元
  2. パイロットライト
  3. ウォームスタンバイ
  4. マルチサイトアクティブ/アクティブ

の4つがあります。
レンティオでは、

  • RTO(目標復旧時間)は、最大で24時間までとしたい
  • RPO(目標復旧時点)は、ECサイトのため注文データはほぼリアルタイムのものを保持しデータの損失はできるだけ避けたい

上記の理由から、バックアップと復元で対応を検討しました。
データベース、商品画像データがあるAuroraとS3については大阪リージョンに短い間隔でレプリケートしておき、障害時の復旧については手動実行する方針で調査と検証をしました。
また、環境変数として使っているパラメータストアについてもレプリケートをすることとしました。

調査と検証

Aurora

レンティオでは、Aurora PostgreSQLを使っています。
データ損失はできるだけ避けたいのでGlobalDatabaseを検討しました。

Amazon Aurora Global Database は複数の AWS リージョン にまたがり配置されます。これにより、低レイテンシーのグローバル読み取りを実現し、AWS リージョン 全体に影響が及ぶ可能性のある停止がまれに起きても、すばやい復旧を可能にします。

セカンダリクラスターを使用すると、従来のレプリケーションソリューションと比較して迅速 (低い RTO) かつ少ないデータ損失 (低い RPO) で、Aurora Global Database を新しいプライマリ AWS リージョン で使用できるようになります。 Amazon Aurora Global Database の使用

また、Global Databaseではヘッドレスのクラスターを作成も可能です。
ヘッドレスとはDBインスタンスがない構成のことで、データを同期しつつ料金を抑えることができます。
ヘッドレスにすることで、復旧は遅くなりますが許容範囲だったためヘッドレスを採用しました。

S3

S3には商品画像やアセットを保存しています。
クロスリージョンレプリケーションを使うことにしました。
レプリケーションの設定

また、既存のオブジェクトについては自動的にレプリケートされないため、バッチレプリケーションを使ってレプケートしました。
S3 バッチレプリケーションを使用した既存のオブジェクトのレプリケーション

パラメータストア

レンティオでは、Copilot Secretsを使ってパラメータストアで環境変数を管理しています。
パラメータストアもリージョンごとのサービスなので大阪リージョンにレプリケーションしておきます。

EventBride + Lambda で、パラメータストアの作成、更新、削除のイベントを受け取ってLambdaで大阪リージョンのパラメータストアを更新します。
こちらのコードを参考にさせていただきました。
https://github.com/alessandrobologna/parameter-store-replicator

また、AWS Copilotで外部から読み込んだパラメータストアを使うには、

  • copilot-application
  • copilot-environment

の2つのタグを設定しておく必要があります。
Copilot の外部で作成したシークレットの取り込み

AWS Copilotを使って別リージョンにサービスをデプロイする

ここからは、事前にレプリケートしておいたデータを使って、大阪リージョンでサービスを動かすための検証です。

大阪リージョンにApplicationを追加

AWS Copilotで別リージョンに環境を構築する場合、AWS_PROFILE環境変数で別プロファイルの指定が必要です。
Credentials - AWS Copilot CLI

今回はすでに作成済みのcopilot/ディレクトリを使いますが、Application名は別リージョンに使っている名前をそのまま使うことはできません。

$ copilot init

Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with a containerized application on AWS. An application is a collection of
containerized services that operate together.

If you want to create a new workspace reusing the existing application XXXXX, please switch to the region where you created the application, and run `copilot app init`.
If you'd like to recreate the application and all of its resources, please switch to the region where you created the application, and run `copilot app delete`.
✘ application named "XXXXX" already exists in another region

そのため、大阪リージョンでは別Applicationを新たに作成しました。
copilot/ディレクトリがある状態でcopilot initを実行すると、copilot/.workspaceが変更され、新しいApplicationにデプロイできます。

copilot/.workspace
-  application: tokyo-app
+  application: osaka-app

Environmentの追加

Environmentの追加によって、VPC、セキュリティグループなどのリソースが作られます。

$ copilot env init --name production
$ copilot env deploy --name production 

Service作成とデプロイ

先ほど作成したEnvironmentにServiceをデプロイします。
また、デプロイ前にS3バケット、Auroraのエンドポイントや、リージョンを指定しているコードがあれば書き換えておく必要があります。

$ copilot svc init -n frontend
$ copilot deploy --name frontend --env production

普段はmainブランチにpushすることで自動的にCodePipelineでデプロイしていますが、大阪リージョンでは現在CodePipelineは対応していません。
そのため、今回はローカル環境からデプロイしています。

そのほかのリソース

AWS Copilot以外で作成されているリソースはほとんどがAWS CDKで管理されているため、リソースのARNを書き換えるだけで動くようになりました。
CloudFrontのオリジンや、ECSとAuroraのVPCピアリング設定などを変更します。

ここまでの検証で、大阪リージョンでサービスが動いていることを確認できました。

マニュアル作成

上記の調査・検証を元にマニュアルを作成しました。
大まかな復旧手順は以下の通りになりました。

  • AWS CDKで大阪リージョンに必要なリソースを作成
    • GlobalDatabaseのセカンダリクラスタにインスタンスを追加
    • ElastiCacheなどのリソースを大阪リージョンに作成
  • AWS Copilotでサービスデプロイ
  • AWS CDKでVPCピアリングなどの設定
  • CloudFrontのオリジンを大阪リージョンに変更

ちなみに、レンティオではこの手順で復旧まで3時間ほどかかります。
特にAuroraインスタンスの起動とServiceのデプロイに時間がかかり、それぞれ

  • Auroraのインスタンス起動 10分
  • Serviceのデプロイ Serviceごとに8~15分

ほどかかります。

おわりに

自動化などもっとできることはあるかと思いますが、ディザスタリカバリの最初の取り組みとして、データのレプリケーションや別リージョンでサービスを動かすことができました。
AWS CopilotやAWS CDKを使うことで、少ない手順で他リージョンにも同じリソースを作ることができて便利ですね。

何かの参考になれば幸いです。

採用情報

レンティオではエンジニアを募集しています。もし興味をお持ちいただけたらこちらもお目通しいただけると幸いです。

https://recruit.rentio.co.jp/engineer

https://www.rentio.jp/

Discussion