복원성 아키텍처
- 복원성이란
- 실패를 회피하거나 실패 발생시 신속하게 회복할 수 잇는 능력
- 애플리케이션이 기대한 성능을 발휘하는 시간의 비유을 나타내는 가용성의 또 다른 표현
가용성 계산하기
- 가용성이란 애플리케이션이 기대한 성능을 발휘하는 시간의 비율 의미
| 연간 가용성 비율 | 비가용시간 |
|---|---|
| 99% | 3일 15시간 39분 |
| 99.9% | 8시간 45분 |
| 99.95% | 4시간 22분 |
| 99.99% | 52분 |
| 99.999% | 5분 |
전통적인 애플리케이션 가용성
- 기존 Linux 또는 Windows 에서 실행되는 애플리케이션 의미
- AWS 배포시 하나 이상의 EC2 인스턴스 실행
- 데이터베이스 사용시 EC2인스턴스 에 데이터베이스 설치하던가 AWS 관리형 데이터베이스 사용하면 됨
- 관계형 데이터베이스 필요시 RDS를 사용
- REDIS 필요시 ElasticCache 사용
멀티 AZ 기반 RDS 배포 환경에서 EC2 인스턴스 하나에 의존해서 실행중인 전통적인 애플리케이션 경우
-
EC2인스턴스및 RDS 인스턴스 가용성에 의존
- 강한 의존성관계
-
총가용성
- 강한 의존성 관계에 속한 가용성의 곱으로 계산
-
EC2인스턴스 90% 멀티 AZ 기반 RDS 인스턴스 가용성 99.5%
- 이 두개의 곱은 89.955%
- 즉 연간 36일 다운타임 발생
총 가용성을 높이기 위해 중복 구현 요소 사용시
- 하나의 EC2 인스턴스 대신 서로 다른 AZ에 있는 세개의 EC2인스턴스를 사용하고 각 인스턴스에서 애플리케이션을 실행하며, 애플리케이션 로드 밸런서를 추가해 타겟 그룹에서 이들 인스턴스를 연결
- 하나의 애플리케이션 혹은 하나의 인스턴스가 실패해도 ALB 가 헬스 체크 결과가 우수한 인스턴스에 연결
- 가용성 100%에서 실패 비율을 차감하는 방식으로 계산
- 100% - (10%10%10%) = 99.9%;
- 연간 다운타임 9시간
- 데이터베이스와 ALB 가용성 계산시
- 데이터 베이스 99.95% ALB 99.99% 중복구현 EC2 99.9%
- 99.84%
- 연간 14시간 다운타임 발생
클라우드 네이티브 애플리케이션 가용성
- AWS 와 같은 특정 클라우드 플랫폼의 리소스를 활용하기 위해 만들어진 애플리케이션
- Lambda 함수를 활용한 서버리스 애플리케이션도 이에 해당
- 관계형 db 대신 DynamoDB 사용
- JSON과 같은 비관계형 데이터 포맷으로 작성된 데이터에 저지연성으로 접근하는 것이 기본 ㅓ
단일 EC2 인스턴스에서 Linux 애플리케이션을 실행하되 DynamoDB를 사용하는 경우
-
DynamoDB 가용성은 99.99%
-
중복 구현 EC2 가용성 99.9
-
ALB 가용성 99.99%
- 총 99.79%
- 연간 18시간 다운타임
-
서로 다른 6개 AZ 에 EC2 실행시
- 100% - (10%10%10%10%10%*10%) =99.999%
- 이럼 총 99.979%
- 연간 2시간 다운타임 의미
-
이들을 두개의 리전으로 나눠 배치하면 가용성을 더 높일수 있음
-
Route 53으로 트래픽 분산시
- 100%-99.979% = .021
- 100%-(.021%*.021%) = 99.999%
- 연간 5분 다운타임
-
교차 리전에서 애플리케이션을 실행하는 경우 크로스 리전 복제를 지원하는 DynamoDB 글로벌 테이블을 활용하는 것이 좋으며
-
이 서비스의 가용성은 99.999%
-
즉 99.999% * 99.999% = 99.998%
- 연간 10분 다운타임
Lambda 서버리스 개발
- Lambda 함수는 일시적으로 실행되는 임무에 적합
- 사용자는 함수 실행 시간에 따른 비용만 부담하면 된다
- Lambda는 고가용성의 분산 컴퓨팅 플랫폼에서 함수를 실행하며 경우에 따라 중지 폐기 될수 있는 ec2 인스턴스와 달리 언제든 접근해서 사용
리소스 용량 제한 파악
-
AWS 는 개별 사용자가 우연히 혹은 의도적으로라도 모든 클라우드 리소스를 고갈시키지 못하도록 하는 용량 제한이 있다.
-
용량제한은
- 네트워크 처리용량, 초당 3S PUT 요청횟수, 리전당 인스턴스 수 , 리전당 EIP 주소 수 등으로 다양하다
-
AWS Trusted Advisor를 이용해 계정에 적용된 서비스 용량제한을 확인 할 수 있으며
-
CloudWatch Alarms 설정에서 용량 제한선에 이르기 전 경고 메시지를 보낼 수 있다.
-
용량 제한 회피 전략
- AWS 지원팀에게 용량 수준 높일것을 요청
- 새로운 AZ 리소스 배포
- 다른 리전에 워크로드 이전 작업
가용성 높이기
- 가용성을 최대화 하기 위한 최선의 방법은 실패를 방지
- 하나의 대규모 인스턴스에서 웹 애플리케이션 호스팅 하는 대신
- 서로 다른 AZ에 다수 중소규모 인스턴스 분산 배치 노력
- 하나의 인스턴스 또는 하나의 AZ가 실패하더라도 애플리케이션 정상 작동
- 허나 하나의 인스턴스가 실패시 다른 인스턴스가 그 부담을 지게 되어 다수 인스턴스가 실패하고 일부 인스턴스가 남은 성능 떨어지다 나머지 인스턴스도 실패
- 적절한 시기에 실패한 인스턴스 대체하는 새로운 인스턴스 배포 필요
EC2 Auto Scaling
- 애플리케이션 실패 상황에 대한 대응 및 신속한 복원을 위한 서비스
- 사용자가 지정한 수의 EC2 인스턴스를 자동으로 프로비저닝 및 시작 할 수 있도록 도움
- 수요 증가세에 맞춰 동적으로 인스턴스 추가
- 실패시 폐기ㅏ 또는 Auto Scaling이 자동으로 인스턴스 대체
Auto Scaling 그룹
-
Auto Scaling 이 관리하는 EC2 인스턴스 그룹
-
최소용량
- Auto Scaling이 성능을 유지하기 위해 지켜야할 최소 인스턴스 수
- 0 으로 설정시 Auto Scaling은 새 인스턴스를 추가하지 않으며 그룹내 실행중인 인스턴스 폐기
-
최대 용량
- Auto Scaling 이 성능을 유지하기 위해 지켜야할 최대 인스턴스 수
- 계정당 부여하는 용량제한과 관계가 있으며, 동시에 실행할 수 있는 인스턴스 수가 무한대로 증가하는 것을 막는 의미도 있음
-
희망 용량
- 최소 및 최대 용량 사이 값으로 설정
- 설정하지 않음 AutoScaling이 최소 용량에 맞춰 인스턴스 생성
- 설정시 자동으로 인스턴스 추가하거나 폐기하며 희망 용량 유지
ALB 타겟 그룹 설정하기
- Auto Scaling 그룹에서 인스턴스로 전달되는 트래픽을 ALB 로 분산 시키려는 경우 Auto Scaling 그룹 생성시 ALB 타겟 그룹에 추가하면 된다
- AutoScaling이 새 인스턴스 생성시 해당 인스턴스는 자동으로 ALB 타겟 그룹에 생성된다
애플리케이션 인스턴스 헬스 체크
- Auto Scaling 그룹 생성 후 자동으로 최소 용량 또는 희망 요량에 맞춰 인스턴스 수 조정
- 인스턴스 상태 나빠질 경우 Auto Scaling 은 해당 요소를 폐기하고 새 인스턴스를 추가
- 특정 인스턴스에 대한 ALB 헬스 체크가 실패한 경우 해당 인스턴스로 가는 트래픽을 다른 곳으로 향하게 해 문제 발생을 차단
- AutoScaling은 해당 인스턴스를 삭제하고 이를 대체할 새 인스턴스를 생성해 alb 타겟 그룹에 추가 그러면 ALB 는 새 인스턴스에 트래픽 전달
Auto Scaling 옵션
-
Auto Scaling은 요구 수준에 따라 인스턴스를 스케일 아웃 할수 있는 다양한 방법 제공
-
수동 스케일링
- 그룹 생성 후 최소 용량 희망 용량 최대용량을 변경하며 Auto Scaling은 즉시 이를 반영
- 기존 2였던 희망 용량을 4로 변경하면 Auto Scaling은 즉시 2개 인스턴스 추가
-
동적 스케일링 정책
- 동적 스케일링 정책을 통해 리소스 고갈 전 인스턴스를 자동으로 추가해야한다.
- CPU 누적 활성화율
- 타겟별 평균 요청 횟수
- 네트워크 평균 유입량
- 네트워크 평균 유출량
-
이들 네이트브 성능 지표 외에도 CloudWatch logs 성능 지표를 추출할수 있는 매트릭스 필터를 사용할 수 있다.
-
CloudWathch alarm이 올릴 경우 희망 용량을 증가시키는 방법으로 스케일아웃 할 수 있다.
-
동적 스케일링 정책으로 심플 스케일링, 스텝 스케일링, 타겟 추적 스케일링 등 세가지가 있다.
심플 스케일링 정책
-
지표가 기준치를 초과하면 AutoScaling이 희망 용량을 증가 시킨다.
-
ChangeInCapacity
- 지정된 수만큼 용량을 증가 시킨다.
-
ExactCapacity
- 현재 용량에 상관없이 지정된 수량에 맞춘다
-
PerecntChageInCapacity
- 현재 용량에 대한 비율로 증가 시킨다.
-
AutoScaling이 조정 작업을 마치면 다음 정책 실행 전 쿨 다운 기간을 보내게 되고 이 시간 동안 알람이 울려도 무시한다
-
기본 쿨 다운 기간은 300초 0으로 설정해 쿨다운 기능을 끌수 있다.
-
단 인스턴스 상태가 좋지 못하면 Auto Scaling 쿨다운 기간을 무시하고 해당 인스턴스를 대체한다
스텝 스케일링 정책
-
CloudWatch Alarm 을 생성해 평균 CPU 활성화율을 모니터링하고 희망 용량 증가 시작점이자 알람의 기준치를 50%로 설정
-
최소 1단계의 조정 설정
- 경계하향선
- 경계 상향선
- 조정 타입
- 희망 용량 증가분
-
스텝 스케일링 정책에서는 웜업 타임을 설정할 수 있다.
-
Auto Scaling이 새로운 인스턴스를 추가하기 위해 지표를 확인하기 위한 대기 시간 기본 값은 300초
-
쿨다운 기간은 적용되지 않는다
타겟 추척 정책
-
사용자가 지표와 목표 값을 선택하면 AutoScaling이 CloudWatch Alarm 및 스케일링 정책을 생성하고 해당 지표의 목표 값에 맞춰 인스턴스 수를 조정
-
지표는 그룹의 평균 cpu 활성화율 , sqs 메시지 수 , 타겟별 요청 수 등 인스턴스의 워크로드에 비례해서 변경될 수 있는 것을 선택
-
스케일 아웃은 물론 지표 수준에 맞춰 인스턴스 수를 줄이는 스케일 인 기능을 사용
-
웜업타임 지정 가능
예약 작업
- 애플리케이션의 워크로드 패턴이 예측 가능하고 용량을 선제적으로 조정해 요구 수요 한계에 다다르기 전 인스턴스를 증가시키려고 할때 유용
- 최소 및 최대용량, 희망용량
- 시작 시간 및 날짜
데이터 백업과 복원
S3
-
One Zone IA를 제외한 S3 의 모든 스토리지 클래스가 멀티 AZ에 객체를 분산 저장
-
데이터 삭제 및 데이터 손상을 방지하려면 S3 비저닝 기능 활성화
- 저장 객체는 임의 덮어쓰기나 실수에 의한 삭제로 부터 안전해 지며, 원본 객체 수정시 새 번진이 만들어지고 사용자는 언제든지 수정 이전 버전으로 복원할 수 있게 된다.
- 원본 객체 삭제시 실제 S3 버킷에서 삭제되지 않고 삭제 마커만 부여돼 화면에 노출되지 않게 되며, 해당 객체와 모든 버전은 항상 유지
-
멀티 AZ의 실패 또는 리전의 실패로부터 데이터를 보호하기 위해 크로스 리전 복제 기능을 활성화해 하나의 리전은 소스 버킷으로 또 다른 리전은 데스티네이션 버킷으로 설정
-
크로스 리전 복제 기능이 활성화 되면 S3는 모든 저장 객체를 동기적으로 소스 버킷에서 데이티네이션 버킷으로 복제
Elastic File System
-
EC2 인스턴스와 온프레미스 서버간의 파일 공유를 가능케 하는 관리형 Network File System EFS는 리전 내 멀티 AZ 환경에 데이터를 저장해 개별 AZ 실패 상황에 대비
-
데이터 손실 변조를 방지하기 위해 개별 파일을 동일 리전 내 S3 버킷 도는 다른 EFS에 백업 할 수 있고 , AWS Backup Service를 이요해 정해진 스케줄에 따라 efs에 백업을 생성할수 있다.
EBS
- 리전내 멀티 AZ 환경에 볼륨을 자동으로 복제해 개별 AZ 실패 상황에 대비 하지만 데이터 변조 위험은 여전히 존재
- 백업 가장 간단한 방법은 스냅샷 생성
- S3에 EBS 스냅샷 저장
- EBS 스냅샷을 직접 생성하거나 Amazon Data Lifecycle Manager를 이용해 일정 주기마다 자동으로 스냅샷 생성
데이터베이스 복원성
-
자체 관계형 데이터베이스 서버를 실행하는 경우 해당 데이터베이스 엔진에 내장된 백업 기능을 이용해 데이터베이스 파일로 저장할수 있다.
-
s3 또는 Glacier에 저장해 데이터를 보호할 수 있다.
-
백업 파일을 목표 인스턴스로 전송하고 임포트 등의 절차를 거쳐 데이터베이스를 복원
-
RDS 의 경우 간단하게 데이터베이스 스냅샷만 생성하면 된다
-
데이터베이스 스냅샷으로 데이터베이스 복원하는 작업에느 ㄴ몇 분이 소요되며, 복원 후 새로우 ㄴ데이터베이스 인스턴스가 생성
-
복원성을 높이기 위해 멀티 AZ 환경에 데이터베이스를 배포 할 수 있으며, 하나의 AZ 에는 기본 인스턴스를 다른 AZ에는 대기 인스턴스를 둘수 있다.
-
RDS는 기본 인스턴스의 데이터를 대기 인스턴스에 동기적으로 복제할 수 있다.
- 기본 인스턴스 실패시 RDS는 대기 인스턴스를 가동해 실패 상황에 대응한다.
-
복원성을 극대화하려면 Amazon Aurora 의 멀티 Aurora 복제본을 활용한다.
-
Aurora는 세개 AZ 데이터베이스를 저장하며, 기본 인스턴스 실패시 다른 AZ의 Aurora 복제본이 기능을 대체하게 된다
-
DynamoDB 는 멀티 AZ환경에서 테이블을 저장하며, 개발 AZ 실패 상황에서도 저지연성 고성능의 NoSQL 데이터베이스 서비스를 제공할 수 있다.
-
DynamoDB 글로벌 테이블을 사용해 멀티 리전에 테이블을 복제하면 복원성을 더욱 높일수 있다.
-
테이블의 기준시점 복구를 설정해 자동으로 백업을 생성하도록 할 수 있다.
복원성 네트워크 생성하기
VPC 설계시 고려사항
- VPC 생성시 리소스에 충분한 IP 주소를 할당할 수 있도록 충분한 크기의 CIDR 블록을 생성하는 것이 중요
SQS
- 애플리케이션 개발자는 종종 루스 커플링 이라는 설계 원칙을 이용해 애플리케이션의 확장성 및 신뢰성을 높인다.
- 불필요한 요소를 최소화해 하나의 서버에서 실행되는 단일 애플리케이션 구현
- 각 컴포넌트를 마이크로 서비스라 부르는 요소로 세분화
- 마이크로 서비스는 서로 다른 서버에서 실행되지만 서로에게 메시지를 전송하며 긴밀하게 소통
Queues
SQS는 처리해야할 메시지를 담는 큐를 생성하며, 큐에 메시지를 넣는 프로듀서 컴포넌트와 큐에 있는 메시지를 읽는 컨슈머 컴포넌트로 구성
- 메시지 최대 크기 256KB
- 프로듀서가 sENDmESSAGE 액션을 통해 큐에 하나 이상 메시지를 넣는다. 큐에 입력된 메시지는 이동중 메시지 또는 인플라이트 메시지라 부른다.
- 컨슈머가 큐에 담긴 새 메시지를 처리할지 확인한다. ReceiveMessage 액션을 통해 큐에 하나이상의 메시지를 소비한다.
- 컨슈머는 메시지를 처리한뒤 DeleteMessage 액션을 통해 큐에서 삭제한다.
- sqs 전송되는 api 호출 횟수를 줄이기 위해 최대 10개 메시지를 묶어 일관적으로 처리할 수 있다.
가시성 중지 기간
-
컨슈머 객체가 큐에서 메시지를 확인하더라도 메시지는 큐에 그대로 유지된다.
- 읽은 메시지의 삭제 여부는 컨슈머가 결정할 수 잇다.
- 특정 컨슈머 객체가 메시지르르 확인하면, SQS는 이후 일정시간 동안 해당 메시지를 다른 컨슈머가 확인할 수 없게 한다.
- 이를 가시성 중지 기간이라 한다.
- 동일 메시지를 다른 컨슈머가 중복 처리하는 일을 막기 위한 조치
-
보유기간
- 기본 보유기간은 4일 최소 1분에서 최대 14일까지 설정 가능
-
딜레이큐 메시지 타이머
- 큐에 메시지를 넣을때 큐마다 지연시간을 설정 할 수 있다.
- 기본 큐 딜레이 시간은 0초 최대 15분 까지 설정할 수 있다.
-
큐타입
- 스탠다드큐, FIFO 두가지 타입의 큐를 제공한다.
스탠다드 큐
- 스탠다는 큐는 거의 무제한의 처리 성능을 제공
- 메시지는 순서와 무관하게 전달되고
- 때로는 동일 메시지가 중복해서 전달
FIFO 큐
-
초당 3천개의 메시지를 큐에 전달
-
메시지는 도착 순서대로 큐에 전달
-
각 메시지는 단 한번만 기록되므로 중복 메시지 문제를 피할수 있다.
-
FIFO큐는 메시지 단위로 큐를 분할해 큐에 입력된 메시지의 하위 그룹을 만들수 있다.
- 다수 프로듀서 객체가 있는 경우 메시지 그룹을 이용해 프로듀서 별 메시지 순서를 관리 할 수 있다.
폴링
-
큐에서 메시지 확인 할때 도착 여부 조회 옵션인 숏폴링 또는 롱폴링 중 하나를 선택할 수 있다.
-
숏 폴링은 일부 메시지 누락이 있더라도 즉시 메시지를 확인 할 때 사용한다.
-
롱폴링은 약간의 지연이 있더라도 큐에 있는 모든 메시지를 정확하게 확인해야 할 때 사용한다.
-
숏폴링을 선택하면 SQS는 대기중인 메시지 내역만 확인하며, 큐에 들어온 메시지를 즉시 확인하거나 큐에 메시지 없을 을 즉시 확인할 수 있다.
-
하지만 메시지 도착후 지연시간이 짧은 관계로 큐에 메시지가 있는 상황에서 메시지가 없다는 응답을 받을 수 있다.
- 즉 메시지 를 착오 없이 확인하려면 여러번 조회해야한다.
-
롱폴링을 선택하면 SQS는 큐에 대기중 모든 메시지 반환한다.
- 응답시간이 20초 가량 걸릴 수 있다.
데드레터 큐
- 컨슈머가 제대로 처리하지 못한 메시지가 큐에 남을시 , 이러한 메시지는 큐에 벗어날 수 없으며 이를 데드레터라 함
- SQS를 통해 자동으로 이와 같은 메시지를 소스 큐에 꺼내 데드레터 큐에 보관한다.
- 데드레터 큐도 다른 모든 큐와 같이 보유기간의 영향을 받는다
- 하나의 메시지가 데드레터 큐로 옯겨지면 원본 생성 일자 기준으로 삭제된다.
