[AWS]복원성 아키텍쳐

가용성 계산하기

가용성이란 애플리케이션이 기대한 성능을 발휘하는 시간의 비율이다.

 

연간 가용성 비율 비가용 시간

99%	3일, 15시간, 30분
99.9%	8시간, 45분
99.95%	4시간, 22분
99.99%	52분
99.999%	5분

가용성은 9의 개수로 표현하기도 한다. 예를들어 두 개의 9는 99%를 의미한다.

전통적인 애플리케이션과 클라우드 네이티브 애플리케이션의 가용성 차이

전통적인 애플리케이션의 가용성

이는 기존의 Linux, Windows에서 실행되는 애플리케이션을 의미하며, 이를 AWS에 배포하려면 하나 이상의 EC2 인스턴스를 실행해야한다.

예를들어 멀티 AZ 기반 RDS 배포 환경에서 EC2 인스턴스 하나에 의존해서 실행 중인 전통적인 애플리케이션의 경우를 생각해보자 이 애플리케이션의 가용성은 EC2 인스턴스 및 RDS 인스턴스의 가용성에 의존하며, 이를 강한 의존성 관계라 부른다.

강한 의존성 관계에 속해있는 애플리케이션의 가용성은 가용성의 곱으로 계산할 수 있다.

총 가용성을 높이기 위해서는 중복구현 요소를 사용할 수 있다. 기존 하나의 EC2 인스턴스 대신 서로 다른 AZ에 있는 세 개의 EC2 인스턴스를 사용하고, 각 인스턴스에서 애플리케이션을 실행하며, ALB를 추가해 타겟 그룹에서 이들 인스턴스를 연결한다.

하나의 애플리케이션 또는 하나의 인스턴스가 실패해도 ALB가 즉시 헬스 체크 결과가 우수한 인스턴스에 연결할 수 있으며 이를 통해 중복구현을 완성했다. 중복구현 요소의 가용성은 100%에서 해당 인스턴스 실패 확률을 차감하는 방식이므로 가용성이 올라간다. 가용성을 더 높이기 위해서는 EC2 인스턴스를 추가하거나 데이터베이스를 중복구현할 수 있다.

클라우드 네이티브 애플리케이션의 가용성

클라우드 네이티브 애플리케이션은 AWS와 같은 특정 클라우드 플랫폼의 리소스를 활용하기 위해 만들어진 애플리케이션으로 Lambda 함수를 활용한 서버리스 애플리케이션도 이에 해당한다.

예를들어 단일 EC2 인스턴스에서 Linux 애플리케이션을 실행하며 데이터베이스로 DynamoDB를 사용하는 경우로 생각해보면 단일 리전에서 DynamoDB의 가용성은 99.99%이고 중복구현된 세 개 EC2 인스턴스의 가용성은 99.9%, ALB의 가용성은 99.99%이므로 이들 요소의 가용성은 곱인 99.79%가 된다. 만약 서로 다른 6개의 AZ에서 EC2 인스턴스를 실행하고 ALB를 이용해 트래픽을 분산시키는 경우 가용성은 더 높아지게 된다.

리소스 용량 제한의 파악

AWS는 개별 사용자가 우연히, 혹은 의도적으로라도 모든 클라우드 리소스를 고갈시키지 못하도록 하는 용량 제한을 적용하고 있다.

용량 제한은 서비스에 따라 다르며, 네트워크 처리용량, 초당 S3 PUT 요청 횟수, 리전당 인스턴스 수, 리전당 일래스틱 IP 주소 수 등으로 다양하고 일부는 AWS에 상향 요청이 가능하다.

AWS Trusted Advisor를 이용해 서비스 용량 제한을 확인할 수 있으며 CloudWatch Alarms 설정에서 용량 제한선에 이르기 전에 경고 메시지를 보내도록 할 수 있다.

가용성 높이기

실제 애플리케이션의 가용성 수준은 버그, 메모리 누수, 데이터베이스 오류 등 계산보다 더욱 낮아질 수 있다.

가용성 최대화를 위한 최선의 방법은 실패 방지이다. 하나의 대규모 인스턴스에서 웹 어플리케이션을 호스팅하는 대신 서로 다른 AZ에 다수의 중소규모 인스턴스를 분산 배치하는 것이 중요하다.

또한 인스턴스가 실패 시 다른 인스턴스가 부담을 지게 되므로 적절한 시기에 실패 인스턴스를 대체하는 새 인스턴스를 배포해야한다.

또 다른 주의사항은 처리 요구량이 증가하면 인스턴스 성능이 저하되거나 중단될 수 있다는 것이다. 분산 애플리케이션을 통해 처리 용량을 증가시켜 이런 문제를 해결할 수 있다. 좀 더 높은 성능의 인스턴스로 업그레이드보다는 인스턴스의 수를 증가시키는 편이 좋다. 분산 시스템은 언제든 수평적으로 리소스 확장이 가능해 편하다.

EC2 Auto Scaling

EC2 Auto Scaling은 애플리케이션 실패 상황에 대한 대응 및 신속한 복원을 위한 서비스로서, 사용자가 지정한 수의 EC2 인스턴스를 자동으로 프로비저닝 및 시작 가능하며 수요 증가세에 맞춰 동적 인스턴스 추가도 가능하다.

인스턴스 자동 시작을 위해 시작 환경설정 및 시작 템플릿을 사용하며 기본적으로 설정된 파라미터에 따라 인스턴스를 구성하고 관련 스크립트를 실행한다.

시작 환경설정

인스턴스를 수동으로 생성하려면 AMI, 인스턴스 타입, SSH 키페어, 보안 그룹, 인스턴스 프로파일, 블록 디바이스 맵핑, EBS 최적화 여부, 플레이스먼트 테넌시, 커스텀 스크립트 등 유저 데이터 등 다양한 환경설정 파라미터 작성이 필요하다.

사용자는 기존 EC2 기반으로 시작 환경설정 생성이 가능하다. 시작 환경설정은 EC2 auto scaling에서만 사용할 수 있으며 설정 내용 중 변경이 필요한 경우 새 시작 환경설정을 생성해야한다.

시작 템플릿

시작 템플릿은 버전 속성을 지니기에 생성 후 변경이 가능하다. 변경이 필요할 때 수정한 후 새 버전을 생성하면 된다. AWS가 버전을 관리하기에 사용자는 필요에 따라 버전 앞, 뒤로 이동하며 인스턴스를 생성할 수 있다.

Auto Scaling 그룹

Auto Scaling 그룹은 Auto Scaling이 관리하는 EC2 인스턴스 그룹이다. 시작 설정들을 이들을 이용해 Auto Scaling이 생성, 유지할 인스턴스 수를 지정한다. 이 떄 중요한 것은 최소 및 최대 그룹 크기를 지정하는 것이며, Auto Scaling이 생성 및 유지하기 위한 희망 인스턴스 수 지정이 가능하다

.

최소 용량

Auto Scaling이 성능을 유지하기 위해 지켜야 할 최소 인스턴스 수를 의미한다. 이를 0으로 설정하면 Auto Scaling은 새 인스턴스를 추가하지 않으며, 그룹 내 실행중인 인스턴스는 폐기된다.

 

최대 용량

Auto Scaling이 성능을 유지하기 위해 지켜야 할 최대 인스턴스 수이다. AWS가 계정당 부여하는 용량 제한과 관계가 있으며, 동시에 실행할 수 있는 인스턴스 수가 무한히 증가하는 이슈를 막는다.

 

희망 용량

희망 용량은 최소 및 최대 용량 사이로 설정해야하며 Auto Scaling에서 인스턴스가 중지된 경우 자동으로 해당 인스턴스를 제거하고 인스턴스 개수를 희망용량에 맞춘다.

Application Load Balancer 타겟 그룹 설정하기

Auto Scaling 그룹에서 인스턴스로 전달되는 트래픽을 ALB로 분산시키려는 경우 Auto Scaling 그룹 생성 시 ALB 타겟 그룹에 추가하면 된다. 이후 Auto Scaling이 새 인스턴스를 생성하면 해당 인스턴스는 자동으로 ALB 타겟 그룹에 추가된다.

애플리케이션 인스턴스의 헬스 체크

Auto Scaling은 기본적으로 EC2 헬스 체크 정보에 따라 인스턴스 상태를 결정한다.

애플리케이션 로드 밸런서를 이용해 인스턴스 트래픽을 분산시킬 경우 로드 밸런서의 타겟 그룹에 대한 헬스 체크를 하도록 설정이 가능하다. 타겟 그룹의 헬스 체크는 200에서 499번까지의 HTTP 응답 코드가 포함되며 Auto Scaling 그룹이 이 정보를 반영해 인스턴스 작동 여부를 결정한다.

Auto Scaling 옵션

수동 스케일링

최소, 최대, 희망 용량을 변경할 경우 Auto Scaling은 이를 바로 반영한다. 이를 통해 수동으로 스케일링이 가능하다.

동적 스케일링 정책

S3, ELB, Internet gateways, NAT gateways등 대부분 AWS 관리형 리소스는 탄력성을 지닌다. Auto Scaling은 그룹에 속한 모든 인스턴스와 관련된 다음과 같은 성능 지표를 생성한다.

• CPU 누적 활성화율
• 타겟별 평균 요청 횟수
• 네트워크 평균 유입량
• 네트워크 평균 유출량

이들 외에도 CloudWatch logs에서 성능 지표를 추출할 수 있는 매트릭스 필터를 사용 가능하다.

동적 스케일링 정책은 CloudWatch alarm이 울링 경우 희망 용량을 증가시키는 방법으로 스케일 아웃이 가능하다. 동적 스케일링 정책으로는 아래 항목들이 있다.

 

심플 스케일링 정책

지표가 기준치를 초과하면 Auto Scaling이 희망 용량을 증가시킨다. 얼마나 증가시킬지는 조정 타입 선택에 달려있다.

• ChangeInCapacity: 지정된 수량만큼 용량 증가
• ExactCapacity: 현재 용량에 상관 없이 지정된 수량에 맞춤
• PercentChangeInCapacity: 현재 용량에 대한 비율로 수량 증가

스텝 스케일링 정책

성능 요구 수준이 빠르게 증가하는 상황에서 성능 지표에 맞춰 신속하게 인스턴스 추가가 가능하다.

예를들어 CPU 활성화율이 50%에 도착했을 떄 2개를 추가하고 60%일 때 4개를 추가하는 설정이 가능하다.

각 단계별 조정은 다음과 같은 내용으로 이루어져있다.

• 경계 하한선: 단계 조정 작업이 실행되는 지표의 범위
• 경계 상한선: 단계 조정 작업이 실행되는 지표의 범위
• 조정 타입: 심플 스케일링 정책의 조정 타입
• 희망 용량 증가분: 증가시킬 희망 용량

타겟 추적 정책

스텝 스케일링 정책보다 간단하게 조정이 가능하다.

사용자가 지표와 목표 값을 선택하면 Auto Scaling이 CloudWatch Alarm 및 스케일링 정책을 생성하고 해당 지표의 목표 값에 맞춰 인스턴스 수를 조정한다.

이 때 지표는 그룹의 평균 CPU 활성화율, SQS 메시지 수, 타겟별 요청 수 등 인스턴스의 워크로드에 비례해 변경 될 수 있는 것을 선택해야 한다. ALB의 총 요청 수 등 누적지표는 개별 워크로드에 비례해 변경되지 않으므로 타겟 추적 정책 지표로는 부적절하다.

타겟 추적 정책의 특징은 스케일 아웃은 물론 지표 수준에 맞춰 인스턴스 수를 줄이는 스케일 인 기능 사용이 가능하다는 것이다. 원치 않으면 해당 기능을 종료해도 된다. 또한 스텝 스케일링 정책처럼 웜업 타임을 정할 수 있다.

• 예약작업: 워크로드 패턴이 예측 가능하고 용량을 선제적으로 조정해 요구 수요 한계에 다다르기 전에 인스턴스를 증가시키고자 할 떄 유용하다. 아래 내용 설정이 가능하다.
  • 최소 및 최대 용량, 희망 용량
  • 시작 날짜 및 시간

데이터 백업과 복원

S3

One Zone IA를 제외한 S3의 모든 스토리지 클래스가 멀티 AZ에 객체를 분산 저장한다.

데이터 삭제, 데이터 손상을 방지하려면 S3 버저닝 기능을 활성화한다.

멀티AZ의 실패, 리전의 실패로부터 데이터를 보호하기 위해 크로스 리전 복제 기능을 활성화해 하나의 리전은 소스 버킷으로 또 다른 리전은 데스티네이션 버킷으로 설정한다.

크로스 리전 복제 기능이 활성화되면 S3는 모든 저장 객체를 동기적으로 소스 버킷에서 데스티네이션 버킷으로 복제한다. 단 두 버킷 모두 버저닝 기능을 사용해야한다.

Elastic File System

EC2 인스턴스와 온프레미스 서버 간의 파일공유를 가능케하는 관리형 Network File System이다.

데이터 손실, 변조 방지를 위해 개별 파일을 동일 리전 내 S3 버킷 또는 다른 EFS에 백업할 수 있고, AWS Backup Service를 이용해 정해진 스케쥴에 따라 EFS에 백업을 생성할 수 있다.

Elastic Block Storage

EBS는 리전 내 멀티 AZ환경에 볼륨을 자동으로 복제해 개별 AZ 실패 상황에 대비 하지만 변조 위험성이 있다.

볼륨 백업의 가장 쉬운 방법은 스냅샷 생성이며 AWS는 S3에 EBS스냅샷을 저장한다. Amazon Data Lifecycle Manager를 이용해 일정 주기마다 자동 스냅샷 생성이 가능하다.

CloudWatch Logs는 인스턴스의 애플리케이션 로그 파일을 실시간으로 수집, 저장하며, 해당 인스턴스가 폐기된 뒤에도 관련 로그 파일을 검색 및 분석할 수 있도록 한다.

데이터베이스의 복원성

자체 관계형 데이터베이스 서버를 실행하는 경우 해당 데이터베이스 엔진에 내장된 백업 기능을 이용해 데이터베이스를 파일로 저장할 수 있다. 그 다음 백업 파일을 S3 또는 Glacier에 저장해 데이터를 보호할 수 있다.

AWS RDS의 경우 데이터 베이스 스냅샷을 생성해 데이터 복원이 가능하다.

멀티 AZ 환경에 데이터 베이스를 배포할 수 있으며 하나의 AZ에는 기본 인스턴스, 다른 AZ에는 대기 인스턴스를 둘 수 있다. RDS는 기본 인스턴스의 데이터를 대기 인스턴스에 동기적으로 복제할 수 있다.

Amazon Aurora를 사용해 복원성을 극대화 할 수 있다. Aurora 는 세 개 AZ에 데이터베이스를 저장하며, 기본 인스턴스 실패 시 다른 AZ의 Aurora 복제본이 기능을 대체하게한다.

DynamoDB는 멀티 AZ 환경에 테이블을 저장하며 실패 상황에서도 저지연성, 고성능의 NoSQL 서비스 사용이 가능하다. 또한 자동으로 백업 생성도 가능하다.

복원성 네트워크 생성

모든 AWS 리소스는 네트워크에 의존하기때문에 네트워크를 적절히 설계하는 일은 중요하다.

VCP 설계 시 고려사항

VPC 생성 시 리소스에 충분한 IP 주소를 할당할 수 있도록 충분한 크기의 CIDR 블록을 생성해야한다.

서브넷 생성 시 CIDR 블록에 충분한 미사용 공간을 둬 미래에 대비하는 것도 중요하다.

복원성을 지닌 외부 연결

애플리케이션의 가용성은 네트워크 가용성에 의존한다. 퍼블릭 인터넷을 대체할 수 있는 기업 전용 연결이 필요하거나 중요한 어플리케이션의 경우 Direct Connect를 이용해 AWS 리소스를 연결하거나 백업을 전송할 수 있다. Direct Connect는 1~10 Gbps의 전송 속도 및 일관된 저지연성을 제공한다. 또한 AWS 리소스에 퍼블릭 인터넷으로 접속이 불가능한경우 보조 연결 수단으로 Direct Connect를 이용할 수 있다.

SQS, Simple Queue Service

루스 커플링이라는 설계 원칙을 이용해 애플리케이션의 확장성, 신뢰성을 높인다. 불필요한 요소를 최소화해 하나의 서버에서 실행하는 단일 애플리케이션을 구현하되, 각 컴포넌트를 마이크로서비스라 부르는 요소로 세분화한다.

SQS는 애플리케이션을 구성하는 다양한 컴포넌트가 서로에게 메시지를 보낼 수 있도록 돕는 관리형 메시지 서비스이다. SQS는 고가용성, 고탄력성을 제공한다.

Queues

SQS는 처리해야 할 메시지를 담는 큐를 생성하며, 큐에 메시지를 넣는 프로듀서 컴포넌트와 메시지를 읽는 컨슈머 컴포넌트로 구성된다. 메시지의 최대 크기는 256KB이다.

API 호출 횟수를 줄이기 위해 최대 10개의 메시지를 묶어 처리할 수 있다.

가시성 중지기간

컨슈머 객체가 큐에서 메시지를 확인해도 메시지는 큐에 유지된다. 읽은 메시지 삭제 여부는 컨슈머가 결정한다. 특정 컨슈머가 메시지를 확인하면 SQS는 일정시간 다른 컨슈머가 해당 메시지를 확인할 수 없게하며 이를 가시성 중지기간이라 부른다. 이를 통해 동일 메시지를 중복 처리하는 일을 막는다.

보유기간

기본 메시지 보유기간은 4일이며 최소 1분 최대 14일까지 설정 가능하다.

딜레이 큐와 메시지 타이머

큐에 메시지를 넣을 때 큐마다 지연시간 설정이 가능하다. 기본 딜레이 시간은 0초고 최대 15분까지 가능하다.

큐 타입

다양한 처리 요구에 의해 스탠다드 큐, FIFO 큐 두 가지 타입의 큐를 제공한다.

스탠다드 큐

스탠다드 큐는 무제한의 처리 성능을 제공한다. 메시지는 순서와 무관하게 전달되고 때론 동일 메시지가 중복 전달되기도 한다. 최대 12만개의 인플라이트 메시지 처리가 가능하다.

FIFO 큐

초당 3천개의 메시지를 큐에 전달할 수 있다. 도착 순서대로 큐에 전달된다. 각 메시지는 단 한번만 기록되어 중복메시지 문제를 피할 수 있다. 약 2만개의 인플라이트 메시지 처리가 가능하다.

FIFO 큐는 메시지 단위로 큐를 분할해 입력 메시지의 하위 그룹 생성이 가능하다. 메시지 전송 다수 프로듀서가 있는 경우 프로듀서별로 메시지 관리가 가능하다.

폴링

큐에서 메시지를 확인할 때 숏폴링, 롱폴링중 하나를 선택할 수 있다. 숏폴링은 일부 메시지 누락이 있더라도 즉시 메시지를 확인해야 할 때 사용하고 롱폴링은 약간의 지연이 있는대신 정확하다.

숏폴링에서 SQS는 대기중인 메시지 내역만 확인하며 도착 즉시 확인하거나 큐에 메시지가 없는것을 확인할 수 있다. 하지만 지연 시간이 짧아 메시지가 있는데도 없다고 판단할 수 있다.

롱폴링은 SQS 큐에서 대기중인 모든 메시지를 반환하며, 모든 큐 서버를 확인하므로 응답시간이 20초가량 걸릴 수 있다.

데드레터 큐

때로는 컨슈머가 제대로 처리하지 못한 메시지가 큐에 남기도 하는데 이런 메시지는 데드레터라고 부른다. 이를 처리하기 위해 SQS를 통해 자동으로 메시지를 꺼내 데드레터 큐에 보관할 수 있다. 큐의 maxReceiveCount 속성으로 메시지의 최대 인출 횟수 시도를 설정 가능하며 데드레터 큐는 소스 큐와 동일 리전에 있어야한다.

가용성을 고려한 설계

가용성은 이를 구현하기 위한 복잡성과 소요되는 비용의 비례관계에 있다.

99% 가용성을 위한 설계

연간 3.5일의 다운타임을 목표로 한다. 이 다운타임은 많은 불편을 초래하는 수준이다. 이 시나리오에서는 애플리케이션 및 셀프 호스팅 SQL 데이터베이스를 실행하기 위해 단일 EC2 인스턴스를 사용하며 데이터 백업을 위해 버저닝 기능이 활성화된 S3 버켓에 데이터베이스가 백업되도록 스크립트를 자동으로 실행하고, S3 Lifecycle 정책을 설정해 구 버전 데이터는 Glacier로 이동, 저장되도록 한다. 리소스 상태 모니터링을 위해 Route 53의 헬스 체크 기능으로 HTTP 상태 코드를 확인하며 페일오버 레코드 세트를 생성해 헬스 체크를 통과하지 못한 경우 사용자에게 접속 실패를 알리는 정적 페이지를 제공한다. 이 때 정적 페이지는 S3 버킷을 사용하거나 CloudFront 배포 호스팅을 이용해 제공한다.

복원 절차

복원 절차는 정기적으로 확인해 정상 작동 여부, 복원 소요 시간 파악이 필요하다.

단순히 SQL 모조 데이터를 생성해 S3 버킷에 전송하는 실험은 부족하기에 정기적으로 새 인스턴스를 생성하고, 백업을 이용해 정상적으로 데이터베이스를 복원할 수 있는지 확인한다.

애플리케이션 및 데이터베이스 인스턴스 조합을 신속하게 생성, 재생성해야 하는 경우 CloudFormation을 이용하면 편하다. CloudFormation 템플릿을 생성해 새 인스턴스의 생성, 웹 및 데이터베이스 서버 설치 설정, 저장소로부터 애플리케이션 파일 복사, 보안 그룹 설정 작업을 일관 처리가 가능하다. CloudFormation 템플릿은 인스턴스 실패 상황에서 인스턴스의 신속한 재생성, 데이터베이스 복원 연습을 위한 임시 인스턴스 생성, 애플리케이션 업데이트 테스트를 위한 목적으로 주로 활용된다.

가용성 계산

가용성 예측을 위해 몇 가지 가정을 한다. 먼저 실패 상황 발생 시 30분의 분석 결정 시간을 가진 뒤 복원 프로세스를 실행한다. 복원 결정 시 CloudFormation 템플릿을 이용해 새 인스턴스를 생성하는데 10분이 소요되고, 데이터베이스 복원에 30분이 소요된다. 즉 각 실패상황의 복원 목표 시간은 70분이다.

복원 목표 시점은 데이터베이스 백업 빈도에 따라 달라진다.

애플리케이션과 운영체제 업데이트와 관련해 연간 6회, 4시간동안 업데이트를 진행한다고 가정했을 때 24시간의 다운타임이 추가된다.

99.9%의 가용성을 위한 설계

연간 9시간의 다운타임을 목표로 한다. 이는 큰 위협 요인으로 인식될 수 있는 수준이다. 이를 위해 분산 애플리케이션 설계 기법을 활용해야 한다.

애플리케이션은 단일 리전 내 멀티 AZ 환경에서 멀티 인스턴스 기반으로 실행된다. ALB를 이용해 트래픽을 다수의 인스턴스에 분산하고 해당 인스턴스에 대한 헬스 체크를 지속적으로 실시한다. 시작 템플릿을 이용해 애플리케이션 웹 서버를 설치하고 중앙화 저장소에서 애플리케이션 파일을 복사한다. Auto Scaling 그룹을 생성 해 3개 AZ마다 2개 인스턴스 즉 최소 6개의 인스턴스가 항상 실행되도록 한다.

복원 절차

대부분의 실패 상황 복원은 자동으로 이루어진다. 실패 시 ALB는 해당 인스턴스에 트래픽을 전송하지 않으며 Auto Scaling은 해당 인스턴스를 폐기하고 새 인스턴스를 추가한다.

데이터베이스의 경우 멀티 AZ 기반 RDS 인스턴스를 사용할 수 있다. 특정 AZ의 실패로 인해 그에 속한 기본 데이터베이스 인스턴스가 실패하면 RDS는 또 다른 AZ에서 보조 데이터베이스 인스턴스를 실행한다. 또한 변조 위험 대비로 자동 스냅샷 기능을 활성화 시켜 복원 기능도 활성화한다.

가용성 계산

실패 상황은 연간 2회, 각각 60분 지속되고 애플리케이션과 운영체제 업데이트는 연간 10회, 각각 15분이 소요된다 이를 모두 합해 연간 다운타임은 4.5시간이다.

99.99% 의 가용성을 위한 설계

중요 애플리케이션이나 사람의 목숨과 연관된 경우 추가 리소스 할당 없이도 복합 실패 상황에 문제 없이 대응할 수 있어야 한다.

두 개의 리전에 인스턴스를 추가하고 하나는 액티브, 하나는 패시브 리전으로 운영한다. Auto Scaling을 이용해 각 리전마다 멀티 AZ 환경을 구성하고, 멀티 인스턴스를 생성하고 피크타임에 각 각각 AZ가 50%의 트래픽을 처리할 수 있도록 한다.

멀티 AZ RDS 사용 시 기본 데이터베이스 인스턴스와 보조 인스턴스가 반드시 동일한 리전에서 실행되어야하는데 이는 현재 별도의 리전에서 운영이 불가능하다.

이를 위해 MySQL 또는 MariaDB 엔진의 멀티 AZ 읽기 사본을 생성해 다수의 리전에 배포해놓고 비동기적으로 하나의 리전에서 다른 리전으로 데이터 사본을 전달할 수 있게 한다. 물론 사본과 데이터 차이는 발생할 수 있어 사본 복제 지연 시간을 적절히 설정해야한다.

복원 절차

리전 실패 전 사용자는 액티브 리전에서만 애플리케이션 인스턴스에 접속하며, CloudWatch Alarm을 생성해 ALB 헬스 체크 모니터링 기능으로 액티브 리전 내 인스턴스 상태를 확인할 수 있다. 이후 액티브 ALB가 실패하면 패시브 리전 기반으로 실패 대응에 나설 지 결정한다.

패시브 리전에서 실패 대응을 하게되었다면 먼저 Route 53의 리소스 레코드를 수정해 패시브 리전의 ALB로 사용자 트래픽 흐름을 변경한다. 그 다음 패시브 리전의 읽기 사본을 기본 데이터베이스 인스턴스로 승격시킨다.

가용성 계산

연간 2회의 실패가 발생하고 실패 복원에 각각 20분이 소요된다고 했을 때 연간 다운타임은 40분이며 이는 99.99%의 가용성이다. 이 시나리오에서는 애플리케이션, 운영체제로 업데이트로 인한 다운타임이 발생하지 않도록 한다. 업데이트 과정중엔 새 인스턴스를 생성해 업데이트를 진행한 뒤 기존 인스턴스를 점진적으로 대체한다.

정리

가용성을 최대한 높이려면 멀티 AZ 환경에서 멀티 EC2 인스턴스 기반으로 ABL을 이용해 워크로드를 멀티 인스턴스에 최대한 균등히 분산시켜야 한다. 하나의 인스턴스, 또는 AZ가 실패하더라도 ALB가 사용자 트래픽을 다른 AZ로 전달할 수 있다.

실패를 막는 또 다른 방법은 개별 인스턴스에 가해지는 부담을 관리하는 것이며 EC2 Auto Scaling이 바로 이런 일을 도와준다.

실패의 주요 원인 중 하나는 데이터 손실, 변조이며 S3 버저닝, 크로스 리전 복제, EBS 스냅샷 등 다양한 기법을 이용해 데이터를 안전히 백업, 복원할 수 있다. 데이터베이스의 경우 멀티 AZ 기반 RDS를 이용해 데이터베이스 인스턴스 스냅샷 생성을 자동화해 데이터베이스의 최손 복제본을 만들고 멀티 AZ 환경에 안전히 저장할 수 있다.