24.07 - AWS Region 이전

현재 우리 회사 제품은 AWS cloud service 를 이용하여

KR, ID, US, VN 국가 별 독립적인 리전에서 운영하고 있다

 

근데 그런 서비스 중 한 국가의 Region 을 바꿔야 하는 일이 생길까?

 

굳이?

 

그런데 생겼다

 

아니 왜죠?

 

환자의 의료정보를 저장하고 있기 때문에, 데이터의 저장 위치가 해당 국가여야만 하기 때문

 

그럼 처음부터 해당 국가가 속하는 지역의 region 을 선택하면 되는 문제 아니었을까?

 

그럼 되는 문제였다

 

있었다면 말이지...

 

그 국가에 진출하여 최초로 환경을 구성할 때까지만 해도

 

Jakarta region 은 존재하지 않았다

 

그래서 가장 가까운 region 을 선택하여 서비스하던 와중, Jakarta region 이 추가되었고

 

그 시점부터 해당 국가의 의료법상 자국의 의료 데이터는 자국의 데이터 센터에 저장되어야만 했다

 

그래서 환자의 의료정보를 저장하는 우리 팀의 인도네시아 서비스는 리전 이사를 가게 되었다

 

마크(사수)는 늘 그랬듯, 나에게 먼저 물어봤다

 

해 보실래요?

 

내 대답이야 뻔했다

 

이런 재밌는좋은 기회를 놓칠 수야 있나

 

안 그래도 실제 프로덕트의 대규모 인프라 구성을 바닥부터 직접 만들어보고 싶었다

 

이미 만들어져 있는 걸 적당히 다뤄서 알고 있는 것과

 

직접 삽질해 가며 만들어 보는 것은 차원이 다른 이해도일 테니까

 

그래서 덥석 시작했다

 

어떻게 할지부터 구상한다

 

1. AWS Jakarta Region 활성화

 

 

2. S3 영상 이전

수백 TB의 영상을 이전해야 하고, 아래와 같은 조건이 있다

 

- 하나의 손실도 발생해선 안 되며

 

- 서비스가 중단되어서도 안 된다

 

- 이전 후 검증이 필요하다

 

- 버킷 이름이 동일해야 한다

 

당연히? 다행히 AWS S3 는 버킷 복제 기능을 제공한다!

 

버킷 복제는 아래와 같이 두 가지 방식이 있는데

 

SRR(Single-Region-Replication)

 

- 동일 리전 내 복제

 

- 데이터 전송 비용 무료

 

- 데이터 PUT 비용 부과 (1,000건당 약 $0.005)

 

CRR(Cross-Region-Replication)

 

- 타 리전 복제

 

- 데이터 전용 비용 부과 (예: 서울 → 도쿄: $0.02/GB)

 

- 데이터 PUT 비용 부과 (1,000건당 약 $0.005)

 

두 방식 모두 단방향 동기화만 가능하며, 조건은 아래와 같다

 

원본 버킷에 새로운 데이터 저장 시 → 대상 버킷으로 동일하게 복제

(99.99%의 경우 15분 이내에 복제)

 

대상 버킷에 새로운 데이터 저장 시 원본 버킷으로 데이터 복제 불가

 

원본 버킷에 존재하는 객체의 메타데이터 변경만 동기화 설정 가능

 

 

위 조건과 함께, 버킷 이름을 동일하게 사용해야 한다

 

AWS resource naming rule 을 만들어 Terraform, Github workflow, Dockerfile 등에 사용 중인데

 

하나만 다르면 일단 기분이 나쁘고

 

리전 구분에 사용하는 환경변수, 배포 자동화에 사용하는 환경변수 등을 맞춰놨기 때문!

 

 

그래서 나온 최선의 방법이 전혀 최선 같지 않은데 정말 최선인...

 

1. 원본 버킷 이름-tmep 로 SRR 을 통해 이전

 

2. 이전된 데이터 검증 (도중에 쌓이는 영상은 S3 동기화 기능으로 싱크)

 

3. temp 버킷으로 엔드포인트 수정

 

3. 원본 버킷 삭제 (TB 단위라 삭제만 한세월)

 

4. 원본 버킷과 동일한 이름으로 이전 대상 리전에 버킷 생성

 

5. temp 버킷에서 재생성 한 원본 이름의 버킷으로 CRR 사용하여 데이터 이전

 

6. 이전 된 데이터 검증 (도중에 쌓이는 영상은 S3 동기화 기능으로 싱크)

 

7. 재생성 한 원본 이름 버킷으로 엔드포인트 수정

 

8. tmep 버킷 삭제

 

총 사용 비용은 월에 청구되는 비용의 *2 수준으로 나쁘지? 않았다

 

 

3. RDS 이전

이전 자체는 쉽다. 역시 AWS 가 제공하는 복제 기능을 사용하면 되니까.

 

그 사이에 새로 쓰일 데이터들을 어떻게 처리하냐가 문제인데

 

이럴 때를 대비해서 큐를 사용하지 않았겠어?

 

딱히 이런 상황까지 고려한 건 아니지만 그렇다고 친다

 

1. 업로더 서버가 바라보는 DB 엔드포인트를 삭-제

 

2. 이전하려는 리전에 DB 복제 약 20분 내외 소요

 

3. 복제된 디비 검증

 

4. DB 엔드포인트를 다시 업로더 서버 큐에 연결 (디비 엔드포인트도 도메인으로 만들어 두면 참 편했을 텐데 항상 지나고 나서 후회한다)

 

5. 정체되어 있던 데이터들이 잘 쓰이는 것을 확인한다

 

6. 참 쉽죠?

4. ECS 이전

https://firstquarter.tistory.com/entry/2407-github-actions-caching

24.07 - 배포 시 캐싱 문제

 

이런 사소하게 허탈한 문제가 있었으나

 

CI/CD 는 평소에 배포할 때도 좋고 리전을 이전할 때도 좋다?

 

그런 의도는 아니었겠지만...?

 

동일하게 리소스들 생성하고

 

리전 변경해서 배포하면 끝

 

이것이 진정한 딸-깍

 

5. VPC 구성

이것이 참 거대한 삽질이었는데... 따로 작성

 

6. 서버 동작 검증

하필? IoT 장비가 오랜 기간 운영하며 여러 버전이 존재하고

 

극소수지만 초기 버전이 다른 엔드포인트를 사용하는 걸 모른 채로 수 시간이 지났고

 

마침 해당 버전을 사용하는 장비가 그날따라 촬영이 많아서 140개가량의 영상이 올라오지 않는다는 문제를 인지

 

혹시 몰라 남겨둔 원본 디비에 쓰인 데이터와 영상을 수동으로 옮겨서 최종 마무리

 

 

7. 결과

뭐든 할 수 있다는 자신감이 가득 차 있는 시기였지만

 

내심 후달리는? 마음 또한 공존했는데

 

오히려 인프라 전체를 씹고 뜯고 맛보고 즐기며 더 잘 알게 되어

 

건방져졌다는 그런 결과