고가용성 및 탄력성

부분적 문제가 생기더라도 서비스가 문제 없이 돌아가야 한다.

 

 

고가용성의 요소
내결함성 : APP 구성 요소의 내장된 중복성

확장성 및 탄력성 : 설계 변경 없이 성장을 수용

복구성 : 재해 발생 후 서비스 복구

 

탄력성이란?

탄력적인 인프라는 용량 욕구사항이 변화함에 따라 지능적으로 확장 및 축소 될 수있다.

 

탄력성 유형

시간 기반 : 사용되지 않는 리소스 끄기

볼륨 기반 : 수요 강도에 맞게 규모 조정

 

모니터링 이유

1.운영 상태

2.리소스 활용

3.애플리케이션 성능

4.보안 감사

 

CloudWatch를 사용하여 모니터링

1)Metric

	EC2 - 비관리	RDS - 관리형
AWS	CPU, Disk, N/W
사용자 지정 데이터	Mem (5min -> 1min ($) -> 1sec

2) Alarm

CPU >= 60% -> Action (Msg, EC2+1)

 

상태

1.OK
2.Alarm
3.Insufficient Data

 

3) logs

log 저장(단순 저장용이면 s3가 더 싸다)

(수집 -> 활용)

Filter 제공 -> (metric)으로 만들 수 있다.

 

4)Event

1. EC2 - stop -> Action -> 알림

2. scheduled ( 시간으로 자동화)

 

 

특징

지표 - 15개월동안 보관

로그

경보 (Rule)

이벤트

규칙

대상

 

CloudTrail
api 호출기록 후 s3에 저장

 

VPC Flow Logs

네트워크 모니터링

 

 

탄력성

 

Auto Scaling

- scale out 하는 서비스

- 지정된 조건에 따라 인스턴스를 시작 또는 종료

- 새 인스턴스를 LB에 자동 등록

- 여러 AZ에 걸쳐 시작 가능

 

ELB,CW, Auto Scaling Group 을 활용하여 탄력성 확보

 

자동확장 방법

1. 예약 : 특정 시간대 or 이벤트시 사용량 예측

2. 동적 : 트래픽에 따라

3. 예측 : 기계학습기반 조정

 

Auto Scaling 구매 옵션

1. 온디맨드 인스턴스

2. 예약 인스턴스

3. 스팟 인스턴스

 

Auto Scaling 용량

- 원하는 용량

- 최소 용량 ( 배치성 워크로드 시 0개)

- 최대 용량

1:1:1 로 설정하면 self healing ( 회복시에 ip가 바뀐다, 안바뀌려면 EIP) -> NAT Instance에서 사용하기 좋다

 

Auto Scaling 고려사항

- 여러가지 고려

- 단계 조정

- 둘 이상의 지표 사용

- 조기에 빠르게 확장하고 천천히 축소

- 수명 주기 후크 사용

 

Auto Scaling에서 사용할 AMI 베이크 전략

1. EC2+ userdata 100줄 => 시간오래걸림, AMI 주기 길어짐

2. AMI 통채로 굽는다 => AMI 주기 짧아짐

3. Hybrid

- 잘 바뀌지 않는 Data => AMI

- 자주 바뀌는 Data => user data

 

DB 규모 조정

RDS

- 읽기 중심의 워크로드 처리를 위해 수평적으로 확장

- 주의 : 비동기식, 중간에 data가 다를 수 있다. APP 로직 변경이 필요 할 수 있다.

 

RDS 스토리지 Auto Scaling

- 수요에 따라 자동 확장

- 신규 및 기존 데이터 베이스 인스턴스와 연동

- storage는 정지 없이 확장가능

- 중간에 정지할 수 있음

- etc : RDS proxy(https://aws.amazon.com/ko/blogs/korea/amazon-rds-proxy-now-generally-available/)

 

RDS Sharding

- 운영이 어렵다....

- 저장시 특정 기준으로 나눠서 저장한다.

 

Aurora DB 클러스터

- 각 Aurora DB 클러스터는 최대 15개의 Aurora 복제본을 가질 수 있다.

- 클러스터 볼륨 간 DB 복제가 일어난다

Aurora Serverless

- 사용한 ACU 수에 따라 비용 지불

 

DynamoDB

1. Auto Scaling : WCU, RCU 지정

2. 온디맨드 : 제한 없이 사용량에 따라 비용 지불

 

Dynamo Auto Scaling

CloudWatch가 트래픽을 보고 Auto Scaling을 한다.

 

파티션 키를 잘 설정하지 않으면 로드가 한쪽으로 쏠려 핫 파티션 발생 가능.( DDB 내부적으로 분산되어 저장되는데 트래픽이 한쪽으로 쏠린다)

userId를 파티션키로 잡으면 핫 파티션 문제가 발생 할 수 있다.

ex) 유저의 게임 사용량이 다른경우, 사용자 많은 유저가 핫 파티션 발생 시킬 수 있음