Zenn
Happy ElementsPublicationへの投稿
😽

AWS環境でのディザスタリカバリの導入

sakura
2023/12/09に公開
AWS
ディザスタリカバリ
tech

「Happy Elements Advent Calendar 2023」 12月9日の記事です。

はじめに

Happy Elements 株式会社 カカリアスタジオ インフラエンジニア の T.J. です。
弊社ではAWSを利用しており、各タイトルや公式サイトのほとんどがAWS上で動いていますので、AWS上での環境構築・運用が主な仕事です。

この記事では、昨年より進めていた 「AWS環境でのディザスタリカバリ[1]（以下 DR）の導入」 について紹介させていただこうと思います。

DR導入について

経緯

2020年9月末〜2020年10月末にかけてユーザー影響のあるAWSでの障害が発生しました。

  • CloudFront（2020-09-26）
  • CloudFront, Route53（2020-10-02）
  • AZ（APNE1-AZ2：ap-northeast-1d）ネットワーク通信（2020-10-22）

また、2022年4月にも CloudFront の障害が発生したことにより、万が一に備えてDR導入を進めることになりました。

検討したこと

1. リージョンの選択

候補としては次の3つありました。

  • 大阪
  • ソウル
  • シンガポール

弊社の各タイトルのユーザは、ほとんどが日本からアクセスされていますので、リージョンが変わっても現状と近い環境でプレイできるのが望ましいと考え、大阪リージョンにDR環境を導入することになりました。

2. 構成

検討した構成としては、4つありましたが、最終的に 2. データの日時バックアップ + スタンバイ構成 で導入しました。

[主な要因]

  • 導入するにあたり既存環境の設定変更やバージョンアップが不要
  • 導入コストが比較的低い
  • データの日時バックアップのみより復旧時間が短い
1. データの日時バックアップのみ

■ 構成

  • 必要なデータのみ日時で大阪リージョンに コピー or レプリケート

    [対象]
  • Aurora（AWS Backup）
  • ElastiCache for Redis（CRR）
  • S3（CRR）
  • Git LFSで利用中のS3バケット
2. データの日時バックアップ + スタンバイ構成

■ 構成

  • データの日時バックアップに加え VPC や ECS、CloudFront 等を構築
  • 各インスタンスやノードはコストが発生するため、リージョンを切り替えるまでは起動しない
  • リージョンを切り替える時に各インスタンスを起動、またはバックアップから復元

    [対象]
  • Aurora（AWS Backup）
  • ElastiCache for Redis（CRR）
  • S3（CRR）
  • CloudFront
  • ALB
  • ECS（ASG）
  • ACM
3. データのレプリケーション

■ 構成

  • 必要なデータのみ非同期で別リージョンにレプリケート

    [対象]
  • Aurora（Global Database）
  • ElastiCache for Redis（Global Datastore）
  • S3（CRR）
4. データのレプリケーション + スタンバイ構成

■ 構成

  • データのレプリケートに加え VPC や ECS、CloudFront 等を構築
  • リージョンを切り替える時にレプリケートしないインスタンス（EC2やMemcached等）を起動

    [対象]
  • Aurora （Global Database）
  • ElastiCache for Redis （Global Datastore）
  • S3（CRR）
  • CloudFront
  • ALB
  • ECS（ASG）
  • ACM

比較

No. 復旧速度 データの保全性 導入の容易さ コスト
1 × △ ◎ ◎
2 ○ △ ○ ○
3 △ ◎ △ △
4 ◎ ◎ △ ×

大阪リージョンにDR環境を構築してみて

実際に大阪リージョンにDR環境を構築していくと、考慮できていないことがありました。

リソース名

AWSのほとんどのサービスは リージョンベース のサービスですが、 IAM や S3 バケットは グローバル/アカウントベース のサービスのため、同じ名前を使用できません。
対応方法として、次のように各リソース名の prefix に リージョンコード を含めることにしました。

prefix

リージョン 大文字 小文字
東京リージョン ProjectEnvAPN1 project-env-apn1
大阪リージョン ProjectEnvAPN3 project-env-apn3

AWSサービス

大阪リージョンは、正式に開設してから2年半程度と、東京リージョンと比較すると利用できないサービスがあります。

大阪リージョンを利用する際には、AWS サービス (リージョン別) で確認しておくことをお勧めします。

CodePipeline

弊社では、CodePipelineを使ってCI/CDプロセスを実装することが多いのですが、つい最近（2023/11/14）まで CodePipeline は大阪リージョンでは利用できず CodeBuild で代用していました。

インスタンスタイプ / ノードタイプ

東京リージョンで使用できる インスタンスタイプ/ノードタイプ が、大阪リージョンではまだ使用できないものがあります。

ElastiCache for Redis のデータ階層化

2023/12/9 時点では、r6gd ファミリーのノードタイプは大阪リージョンでは使用できません。
そのため、ElastiCache for Redis のデータ階層化 は大阪リージョンでは使用できませんので、ご注意ください。

データ階層化 - 制限事項

使用するノードタイプは、us-east-2、us-east-1、us-west-2、us-west-1、eu-west-1、eu-central-1、eu-north-1、eu-west-3、ap-northeast-1、ap-southeast-1、ap-southeast-2、ap-south-1、ca-central-1、sa-east-1 のリージョンで使用できる r6gd ファミリーのものである必要があります。

今後の課題

Auroraの強制アップデートやインスタンスタイプの変更など、AWSや運用に合わせて本番環境の各リソースや設定などを変更しています。
そういった場合に、東京リージョンと大阪リージョンの設定や構成にズレが生じないための仕組みが必要と感じています。

弊社の場合、terraform で環境を構築することが主流となっており、DR環境についても例外ではありません。
手動で変更を加えた場合には terraform のコードも更新し、大阪リージョンにも反映する等、コードの運用についても考えないといけないですね...。

脚注

  1. 地震や津波などの災害によってシステムの継続利用が不可能になった際の復旧および修復、あるいはそのためのシステムなどを指します。日本語では災害復旧と訳されます。 ↩︎

Happy Elements
Happy ElementsPublication

京都でスマートフォン向けゲームを開発・運営している Happy Elements カカリアスタジオの Publication です

Discussion