1. 개요
AWS 서비스 DR 환경 구축하기 1편에서는 DR 아키텍처에 대해서 알아보았고, AWS 서비스 중에 Replication 기능을 제공하는 서비스를 중심으로 설명을 진행했습니다.
실제 프로젝트에서 적용했던 사례를 중심으로 설명을 하다보니, 모든 서비스를 다루지는 않았습니다.
2편에서는 S3 및 소스 관리와 도쿄 리전의 AWS 자원 생성 방법 등에 대해서 알아보겠습니다.
2. 구성 방안
2.1 S3의 DR 구성
S3 Bucket에도 replication 기능이 있습니다.
ECR의 Replication 기능과 다른 점은 S3 Bucket 개별로 설정을 해야 한다는 점입니다.
Source Bucket에서 Destination Bucket으로 Replication을 할 수 있는 Role을 추가합니다.
이 Role은 Source Bucket을 읽고 Destination Buket으로 Replication or Delete 가 가능한 Action 들이 포함됩니다.
상세한 Policy는 아래의 코드를 참고해 주세요.
terraform의 코드를 통해 s3 replication config 를 추가하여 생성했습니다.
replication config 설정 시점 이후로 생성된 object만 replication이 진행이 되기 때문에,
설정 이전에 저장된 object들은 aws s3 cp 명령으로 버켓별로 복사 작업을 진행했습니다.
source bucket에서 object 삭제시 destination bucket에서도 삭제가 되므로 주의가 필요합니다.
glacier에 저장된 object는 replication 되지 않습니다.
2.2 Git Repository DR 구성
사내에서 구축해서 사용중인 소스관리 플랫폼이 있습니다. 이 서비스는 AWS 환경에 구축되어 있습니다.
다른 조직에서 관리하는 서비스이기 때문에 해당 서비스에 대한 DR도 별도로 진행이 될 것입니다.
현재 진행중인 프로젝트의 소스는 이 소스관리 플랫폼에서 관리가 되고 있습니다.
소스관리 플랫폼의 재해복구가 늦어지는 상황이 발생할수도 있고, 나의 시스템도 빠르게 복구를 진행해야 되는 상황이라면 난감해질 것입니다.
재해 상황에서도 나의 프로젝트 소스에 대해 빠르게 접근하기 위해서 별도의 Git Repository로 복제가 필요하다고 생각했습니다.
Terraform 으로 도쿄 리전에 codecommit repository를 구성하고, git clone 과 git push를 수행하도록 했습니다.
복제 실행은 jenkins를 이용했고, 스케줄을 지정하여 주기적으로 실행했습니다.
2.3 Application의 DR 구성 방안
RTO 4시간, RPO 5분이고 warm site 구축하는 것이 목표였기 때문에
도쿄 리전에 Application 자원들을 미리 만들어 둘 필요는 없었습니다.
재해복구 상황이 발생했을 때 자원 생성을 진행하는 것으로 결정하였습니다.
주요 Application 자원들로는 ALB, ECS-fargate, Route53 Recordset 등이 있습니다.
모든 자원은 terraform 코드로 작성을 했고, Jenkiins Pipeline을 통해서 생성을 합니다.
도쿄 리전에 생성할 자원들은 서울 리전에 생성할 자원과 동일하고, 약간의 Configuration만 다르기 때문에 쉽게 구성할 수 있었습니다.
IaC가 빛을 발하는 순간이기도 합니다.
Application Image는 ECR에서 관리하고 있었기 때문에 ECR Replication 기능으로 도쿄 리전에 이미 복제가 되어 있는 상태입니다. 자원 생성시 도쿄 리전의 ECR 이미지로 생성이 가능했습니다.
2.4 Infra 자원들에 대한 DR 구성 방안
VPC 및 Subnet, Security Group, NACL, Routing Table 등 네트워크 관련 자원들은
도쿄 리전에 기본적으로 구축을 해서 유지를 했습니다.
이 부분도 Terraform으로 구성을 했기 때문에 서울 리전과 거의 동일하게 구성이 가능했습니다.
IP대역이나 자원의 이름, 리전 이름 등 변경이 필요한 부분은 Terraform variable로 구성하여 configuration을 통해서 생성하였습니다.
IAM Role/Policy는 리전에 상관없이 사용할 수 있는 자원들이기 때문에
동일한 Terraform 코드로 생성할 경우 중복된 이름으로 인해 에러가 발생할 수 있습니다.
IAM Role/Policy 이름이나 S3 버켓명 등을 지정할 때는 리전명 또는 환경에 대한 이름을 postfix로 붙여서 생성을 했습니다.
Infra 자원들도 대부분은 terraform 코드로 작성을 했습니다.
2.5 route53을 이용한 라우팅 방안
사용자가 접속시 사용하는 도메인을 DR 상황에서 도쿄 리전에서도 사용을 해야 합니다.
Route53에서 관리되고 있는 Recordset에 대한 관리가 필요한데요.
Route53 Failover Routing Policy 도 고민을 해 볼 수 있는데요.
저희는 warm site 구축이 목표이기 때문에 실제로 라우팅 할 수 있는 자원이 평소에는 존재하지 않는 문제가 있었습니다.
다른 방안으로 Terraform 으로 Route53 Recordset 을 변경하는 방법으로 해결했습니다.
Terraform 으로 서울리전과 도쿄 리전의 환경을 구성할 때, State 파일을 분리했습니다.
Route53 Recordset 자원을 Terraform으로 생성을 하면, 같은 이름의 Recordset을 Overwrite 하면서 생성을 합니다.
예를 들면 아래와 같이 동작을 합니다.
(1) 서울 리전 Backend Infra CI/CD Pipeline 빌드 실행
(2) Terraform Apply 실행되며, Route53 Recordset 생성(service-be.example.com → 서울 리전 ALB)
(3) DR 전환 요건 발생
(4) 도쿄 리전 Backend Infra CI/CD Pipeline 빌드 실행
(5) Terraform Apply 실행되며, Route53 Recordset 생성(service-be.example.com → 도쿄 리전 ALB)
Application CI/CD Pipeline 에서는 Application 에서 사용할 Recordset을 생성하고 관련된 컴퓨팅 자원들을 생성하고 있습니다.
Route53 Hostedzone과 ACM 자원들은 별도의 인프라 CI/CD Pipeline을 통해서 생성을 했습니다.
3. 마무리
이번편에서는 S3와 Git Repository 의 복제 방법에 대해서 살펴보고, Application과 Infra DR 생성 방안에 대해서 알아보았습니다.
DR을 구성하기 위한 방법은 여러가지가 있겠지만, AWS 에서 제공하는 기능들을 찾아보고 적용을 한다면 좀 더 쉽고 빠르게 구현을 할 수 있습니다.
