1. 개요

AWS에 구축한 프로젝트에서 서울 리전 → 도쿄 리전으로 DR을 구성해야 되는 요건이 있었습니다.
주요 AWS Resource로는 ECS, Aurora RDS, S3 등을 사용하고 있었고, 최대한 AWS의 기능을 활용하여 구축을 진행을 했었습니다.
DR을 구축하기 위해 어떤 고민이 있었고, 사용한 방법은 어떤 것이 있었는지 알아보겠습니다.

2. 관련된 서비스

● ALB
● ECS – Fargate
● ECR
● Aurora RDS for MySQL
● S3
● Route53

3. 프로젝트 개요

이 프로젝트는 AWS에서 SaaS 서비스를 구축 중이었습니다.
Public 서비스는 없고, Direct Connect를 이용하여 사내망과 연결되어 있었습니다.
계열사의 임직원을 대상으로 서비스를 계획하고 있었기 때문에 Private 네트워크망을 이용하고, 인터넷으로의 outbound 트래픽은 보안장비를 거쳐서 허용되었습니다.
프로젝트에서 사용 중인 주요 AWS Resource로는 ALB, ECS, Aurora RDS, S3, AWS Batch, CloudWatch Event, Transfer Family(SFTP) 등을 사용하고 있었습니다.

4. DR 구성 요건

DR 조건으로는 RTO 4시간, RPO 5분이고, warm site로 구축하는 것이 목표였습니다.
현재 사용 중인 리전은 서울이고, DR 환경은 도쿄 리전에 구성하게 됩니다.
대부분의 자원은 Terraform v1.1.2으로 정의하였고, Jenkins CI/CD Pipeline을 통해서 생성하였습니다.
도쿄 리전에 생성되는 자원들은 비용을 고려해서, 평소에는 자원 생성을 하지 않거나 최소로 유지하는 방안으로 정했습니다.
데이터나 로그, container image 등은 replication을 위한 설정들이 필요하고, 도쿄 리전에 자원 생성이 필요했습니다.
ALB, ECS, SFTP 자원들처럼 데이터를 포함하지 않는 자원들은 DR 전개 시 생성하는 것으로 했습니다.

5. 구성 방안

5.1 DR 아키텍처

아키텍처 구성도를 단순하게 도식화했는데요.
서울 리전을 primary 리전으로 구성했고, 도쿄 리전을 secondary 리전으로 구성했습니다.
도쿄 리전의 아이콘들 중에 그라데이션 효과를 넣은 것들은 DR 상황 발생 시 생성할 자원들입니다.
평시에는 비용을 줄이기 위한 목적으로 자원을 생성하지 않았습니다.
해당 자원들은 Terraform 코드로 구성이 되었기 때문에 언제든지 빠르게 생성을 할 수 있습니다.
Aurora RDS, S3, ECR, Secrets Manager 들은 replication 기능을 제공하고 있습니다.
해당 기능을 통해서 더 쉽게 구현이 가능했습니다.

5.2 Aurora RDS DR 구성
Aurora RDS는 AWS Managed로 제공되는 Database 서비스입니다.
Aurora RDS는 Global Database 기능을 제공하며, 다른 리전으로 확장 가능한 클러스터를 추가할 수 있습니다.
Primary 리전의 클러스터에는 Writer 인스턴스가 존재하고, Secondary 리전에는 Reader 인스턴스가 추가되어 부하를 분산시킬 수 있습니다.
재해 복구가 필요한 상황이 발생한다면, Secondary 리전을 승격(Promote) 시켜서 Primary 리전으로 동작하게 할 수 있습니다.
데이터에 대한 복제는 1초 미만의 지연시간으로 가능하고, 재해복구는 1분 이내에 가능합니다.

Terraform으로 Aurora RDS for MySQL 을 구성을 위한 코드입니다.
Security Group 과 Subnet, IAM, RDS parameter 등을 생성하기 위한 추가적인 코드가 더 필요합니다.

5.3 ECR의 DR 구성
ECS 또는 EKS를 사용 중인 프로젝트라면, ECR을 대부분 사용하고 있을 것입니다.
ECR에는 Private Image Replication 기능을 제공하므로, ECR에 Image를 push 하면 자동으로 다른 리전으로 Image replication 을 할 수 있습니다.
ECR Replication 기능은 Repository 단위로 지정하는 것이 아니라, 리전을 지정하면 리전에 있는 모든 Repository가 대상이 됩니다.
Filter 조건을 추가하여 일부 Repository만 복제하는 것도 가능합니다.

Replication 기능을 사용하기 위해서 destination을 지정해야 하는데요. 같은 account의 서울 리전에서 도쿄 리전으로 복제를 실행할 계획입니다.
configuration 은 terraform으로 구성하였습니다.

repository_filter를 추가하지 않았기 때문에 서울 리전의 모든 Repository가 복제가 됩니다.
Repository의 Prefix name을 기준으로 filtering 하여 복제 대상을 제한할 수도 있습니다.

설정을 하기 전에 서울 리전에 존재하는 Repository의 Image 들은 복제가 되지 않습니다.
설정을 완료하고 난 후 Push 되는 이미지에 대해서만 복제가 됩니다.
복제가 될 때 destination 리전에 Repository가 없으면, Repository가 생성되고 Image가 replication 됩니다.
삭제에 대해서는 replication을 해주지 않기 때문에 수동으로 제거해야 합니다.

6. 마무리

이번 편에서는 DR 구성을 위한 아키텍처를 소개하고,
AWS 서비스 중에 Replication 기능을 제공하는 서비스를 중심으로 DR 구성 방법을 설명했습니다.
2편에는 재해복구 상황 시 추가적으로 필요한 작업들과 적용 방법을 알아보겠습니다.