AWS-2-1. 삼성 계정 글로벌 DR-2024-08
AWS 서밋
삼성 계정 서비스가 글로벌 DR을 어떻게 진행하였는지 설명되는 내용.
DNS서비스 리전 이중화 방법, 디비 동기화, 동적 콘텐츠 동기화, 정적 컨턴츠 동기화가 설명된다.
<1> 복구시간 및 복구 시점 목표, 재해 복구(DR) 전략
<2> 삼성 글로벌 계정 서비스
<3> 트래픽 전환 제어- 글로벌 로드밸런서, 글로벌 엑셀러레이터 검토
<4> 트래픽 전환 제어- 글로벌 로드밸런서, DNS 기반 사용
<5> 웹콘텐츠 S3장애 복구 대응
<6> 운영 환경에서 모의 장애 훈련 진행함.
<7> 개인 요약
<1> 복구시간 및 복구 시점 목표, 재해 복구(DR) 전략
1
복구 시간 목표 (RTO) = 4시간? 4시간 안에 복구
복구 시점 목표(RPO) = 데이터 손실이전 , 1일 전 데이터가지 복구?
2
재해복구 전략
<2> 삼성 글로벌 계정 서비스
1
17억 사용자.
삼성 페이등에서 사용함.
온라인 오프라인 서비스 모두 1개의 계정으로 제공하고 있다.
2
270만 대용량 트래픽 처리 중
70여 개 이상의 마이크로 서비스로 운영 중임.
EKS기반으로 운영 중이다.
오로라 DB를 주요 데이터베이스로 사용 중이다.
3개의 리전을 사용
자체 설루션을 통해 동기화.
MSK로 동기화 개선 중.
CDN을 AWS Cloudfront로 이전하여 사용 중.
3
3개 리전에서 서비스 중이다.
글로벌 장애 복구 아키텍처 필요함.
US, EU 사용 중. 트래픽 분산 필요.
신규 AP리전 구축하여 분산 진행함.
70여 개 마이크로 서비스
A 기능이 US만 존재하는 문제.
AP 리전 구축 시 A 기능 제공하도록 개선함.
데이터 동기화 필요.
Postgre 동기화 =자체 기반 설루션 + MSK 기반의 동기화에 확산 중 (최근 msk로)
다이나모 디비 = 다이나모 디비 자체 기능인 글로벌 테이블 사용함.
<3> 트래픽 전환 제어- 글로벌 로드밸런서, 글로벌 엑셀러레이터 검토
적은 비용으로 효율적인 방법 고려
글로벌 로드밸런서 사용?
web , api를 다른 리전으로 전환하는 방식.
글로벌 엑셀러레이터 검토?
삼성은 큰 비용, 시스템 복잡도 사용 중 - 많은 엔드포인트가 있었다. = 사용 힘듦.
복구작업의 단순화를 위해 DNS 기반으로 고려함.
<4> 트래픽 전환 제어- 글로벌 로드밸런서, DNS 기반 사용
1
DNS기반
Route53을 사용.
2
단점?
isp의 DNS캐시로 인해 시간 지연.
삼성 계정은 DNS기반으로 선택함.
3
US리전에 Route53 구축되어 있음.
AWS US 리전 장애 시 Rotue53 사용불가.
장애 트래픽 전환 불가능해짐.
4
Route53 ARC 서비스 출시.
Route53 장애 시 복구할 수 있도록 해준다.
Route53 ARC를 기반으로 US리전 장애 시 복구법 확인해 보자.
평소에는 프라이머리인 US리전으로 서비스 중.
US리전 장애 발생 시 - 제어계층에 장애 복구 요청을 함
EU리전의 DNS인 세컨더리가 동작하도록 함.
Route53의 고가용성 기능을 통해 EU로 전환되도록 함.
리전 단위 장애 복구 아키텍처를 확보함.
Route53 ARC
AWS Route53 장애 시 한 리전에 있는 Route53을 다른 리전에서 서비스 가능하도록 변경하도록 해줄 수 있는 기능을 제공한다.
한 리전 장애 시 AWS Route53을 계속 사용할 수 있게 해 줄 수 있다.
https://docs.aws.amazon.com/ko_kr/r53recovery/latest/dg/what-is-route53-recovery.html
5
리전 장애 시 다른 리전에서 서비스 가능하도록 용량을 확보함.
트래픽 제어가 필요해짐.
트래픽 분산은 어떻게?
지연시간 기반 라우팅과 지리적 라우팅을 고려함.
6
지연시간은 라우팅 사용?
route53에서 정의하여 트래픽 조정함 - 삼성에는 미리 예측 힘들 다는 단점 발생
7
지리적 라우팅 방식?
삼성 계정에서 사용하는 방식으로 결정함.
국가 단위로 트래픽 미리 예측가능함
트래픽 예측 가능.
256개국 가능함. = 운영 관점에 복잡도 증가함 = 국가를 그룹으로 묶을 필요성 발생.
클라우드 프런트의 에지 라우팅으로 해결함.
8
US리전 장애 시?
클라우드 프런트의 에지 라우팅으로 해결함.
한국 트래픽은 EU리전으로 분산 가능
US트래픽은 AP리전으로 분산가능
9
지리적 라우팅 라우팅 동작 방식 = 삼성 계정 동작 방식?
삼성 계정 사용자가 계정으로 접속 시도
지리적 라우팅으로 (클라우드 프런트 에지 캐시) 해당 지역 계정으로 접속한다.
브라질 어카운트로 접속
페일오버 br 어카운트로 연결 - us에서 처리됨.
us 리전의 장애 시 브라질 리전 도메인은 ap 리전으로 라우팅 되어 트래픽 처리가 된다.
에지로케이션으로 들어오지 않는 예외도 고려함 - 디폴트
<5> 웹콘텐츠 S3장애 복구 대응
1
삼성 정적 웹콘텐츠는 S3 기반으로 운영되고 있다.
S3는 지역 기반 서비스이다.
동적 컨텐츠는 지리적 라우팅 방식? 삼성 계정에서 사용하는 방식으로 결정함.
2
정적 컨텐츠인 S3는 지역 기반이라 이중화 필요함. = S3를 2개 리전에 프라이머리, 세컨더리 구축함. 오리진 그룹으로 묵음
<6> 운영 환경에서 모의 장애 훈련 진행함.
1
운영 환경에 적용
철저한 사전 검증을 통해 준비.
2% 트래픽을 검증.
2
부하는 10% , 50% 부하 검증은 2번 진행함.
3
1개 리전을 100% 전환 진행함.
<7> 개인 요약
1
기업에 따라 복구 시간은 다르다. = 2개 지역에 모두 활성화되어 서비스하면 좋지만 고비용 발생한다.
2
지리적 라우팅 방식?
삼성 계정에서 사용하는 방식으로 결정함.
3
데이터 동기화 필요.
Postgre 동기화 =자체 기반 솔루션 + MSK 기반의 동기화에 확산 중 (최근msk로)
다이나모 디비 = 다이나모 디비 자체 기능인 글로벌 테이블 사용함.
4
글로벌 로드밸런서인 route53을 이용해 리전장애에 대응하자.
정적 콘텐츠도 cloudfront와 s3로 대응하자.
동적 컨텐츠는 geo로 해결 가능함.
정적 컨텐츠인 S3는 지역 기반이라 이중화 필요함. = S3를 2개 리전에 프라이머리, 세컨더리 구축함. 오리진 그룹으로 묵음
5
실제 운영 환경에서 모의 장애 훈련을 진행한 부분은 매우 좋은 사례인 거 같다.
감사합니다.
