Architecting on AWS - 03

ELB, CloudWatch, Auto Scaling

이 삼총사는 같이 움직인다.

하나의 예로

ELB

는 연결된 4개의 인스턴스들을 로드 밸런싱 및 모니터링(Health Check)하며 관리하고,

CloudWatch

는 ELB로부터 노티피케이션 받은 인스턴스 정보를 Auto Scaling에게 트리거링 해준다.

또한 전반적인 AWS 컴포넌트들에 대한 모니터링을 수행하며, Amazon S3 등 저장 공간에 연결하여 각종 모니터링에 대한 데이터를(주로 감사 용도로) 저장한다.

Auto Scaling

은 CPU 사용률(지표=Metric)이 5분(지정기간) 동안 50%(임계치)를 초과하는 경우 인스턴스를 하나 추가하는(Scale Out) 등의 정책에 따라 인스턴스 집합(Fleet)을 스케일링한다. 그러면 다시 ELB는 추가된 인스턴스까지 포함해 5개의 인스턴스를 로드 밸런싱하며 관리한다.

 

3가지 유형의 탄력성

시간 기반(예약) : 특정 시간대에 고정적으로 스케일링

볼륨 기반(동적) : CPU, I/O 등의 모니터링을 통한 스케일링

예측 기반 : ML을 통해 일일 및 주간 추세를 기반으로 향후 트래픽 예측을 통한 스케일링

 

Auto Scaling - 구매 옵션

오토 스케일링이 인스턴스를 생성할 때 그 인스턴스의 사양과 최소, 최대값을 지정해야 한다.

인스턴스의 사양은 Launch Configuration에서 지정한다.

Min, Max, Desired 값은 Auto Scaling Group에서 지정한다.

---

RDS Read Replica

관계형 데이터베이스의 읽기 전용 복제본이다.

읽기 작업이 매우 자주 일어나는 상황에서 트래픽의 경합을 막기 위해 여러 복제본으로 트래픽을 분산시킨다.

Amazon Aurora의 경우 최대 15개,

Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL은 최대 5개까지 생성할 수 있다.

 

Scale Up/Down

RDS 인스턴스의 리소스 성능을 변경하는 작업이다.

micro부터 24xlarge에 이르는 모든 크기의 인스턴스 타입을 지원한다.

스토리지(EBS) 추가를 제외하면 변경 시에 발생하는 다운 타임은 감안해야 한다.

 

Amazon Aurora Serverless

Amazon Aurora 위에 MySQL이나 PostgreSQL을 얹어서 사용할 수 있다.

다운 타임 없이 RDS에 대한 수직적 확장 및 축소가 가능하며, 서버 인프라를 관리할 필요없이 애플리케이션의 필요에 따라 자동으로 시작 및 종료하고 용량을 축소 또는 확장하는 DB 클러스터이다.

---

Infra Automation with CloudFormation (인프라 자동화)

수동 프로세스는 확장, 버전 제어, 감사 내역, 일관성이 없기에 인프라 자동화가 필요하다. 

JSON/YAML로 작성한 템플릿을 CloudFormation 엔진에서 돌려 아키텍처 스택을 만든다.

 

IaC (Infra as a Code)

반복성, 재사용성 등의 장점이 있고, 템플릿의 내용만 고쳐 쉽게 인프라를 수정할 수 있다. 원래 스택에 대한 변경 집합을 검사한 후 CloudFormation으로 실행한다.

스택은 주로 위와 같이 계층별로 구분지어 따로 만든다. 각 스택을 알아보기 편하고 관리하기 쉽기 때문이다.

 

AWS Quick Start

AWS Solutions Architect가 구축한 모범 표준 AWS CloudFormation 템플릿.

보안 및 고가용성 모범 사례에 기초하여 만들어졌으며, 클릭 한 번으로 1시간 이내에 전체 아키텍처 생성이 가능하다.

템플릿이 적용할 환경에 정확히 부합하진 않을 것이기 때문에 스크립트로 커스터마이징하여 부트스트랩으로 배포해 사용할 수 있다.

 

Deployment Automation (배포 자동화)

보안 패치 등을 수많은 인스턴스(Fleet)에 적용하기 위해 Systems Manager를 이용한다.

일괄적으로 명령 실행, 패치 관리, 상태 관리, 세션 관리, 인벤토리 관리가 가능하다.

 

S/W Inventory : 설치될 제품 목록

 

AWS OpsWorks

개별 인스턴스 내부의 S/W 설정에 특화되어 있다. 스택에서 인스턴스 외부의 부분은 CloudFormation으로 구축하고, 인스턴스 내부의 상세한 설정은 OpsWorks로 구축하면 된다.

온프레미스에서 사용하던 Chef, Puppet를 사용하여 애플리케이션을 구성 관리할 수 있다.

 

AWS Elastic Beanstalk

AWS Elastic Beanstalk의 목표는 개발자가 기본 인프라에 대해 걱정할 필요없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포하고 유지 관리하도록 돕는 것이다. Elastic Beanstalk은 선택된 플랫폼에서 애플리케이션을 실행하는데 필요한 요소로 구성한다. 애플리케이션 스택을 설치 및 구성하기 위해 인스턴스에 로깅하는 것에 대해 걱정할 필요가 없다.

 

 

상황에 맞는 알맞은 솔루션을 선택하여 시스템을 구축한다.

---

AWS CloudFront

CDN(Contents Delivery Network)서비스란 말 그대로 콘텐츠 전송 네트워크로, 기본적인 멀티 티어 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화되어 있다. 이 세션에선 AWS Edge Location의 CloudFront를 살펴본다.

 

무엇을 캐싱해야 하는가?

• 수집하려면 느리고 비싼 쿼리가 필요한 데이터
• 비교적 정적이고 자주 액세스하는 데이터(WORM : Amazon S3)
• 공개 거래되는 주식 가격처럼 일정 기간 동안 변화가 없을 수 있는 정보

캐싱 유형

• 클라이언트 - 웹 브라우저
• 서버 - 웹 서버
• 서버 - 역방향 프록시 캐시

원래 동적인 데이터는 캐싱의 대상이 아니지만 AWS CloudFront는 매우 빠른 속도의 AWS Backbone Network를 사용하기 때문에 동적인 부분도 캐싱이 가능은 하다.

 

콘텐츠 만료 방법

• TTL(Time To Live)
• 객체 이름 변경
• 객체 무효화

 

Amazon DynamoDB Acclerator (DAX)

DynamoDB와 마찬가지로 완전관리형 서비스이다. DynamoDB는 10밀리초 미만의 일관된 지연 시간을 제공하지만 DAX는 읽기 중심의 워크로드에 대한 초당 수백만 건의 요청에 대해서 마이크로초 단위의 응답 시간을 제공한다.

또한 DynamoDB와 API 호환이 되기 때문에 작동 중인 애플리케이션 코드를 변경할 필요가 없다. DAX 클러스터를 프로비저닝하고 DAX 클라이언트 SDK를 사용하여 DAX 클러스터에서 기존 DynamoDB API 호출을 가리키면, DAX가 나머지 모든 작업을 처리한다.

위와 같이 응답 시간이 중요한 게임 서버 등의 캐시로써 잘 사용된다.

 

Amazon ElastiCache

Amazon ElastiCache는 클라우드에서 인 메모리 캐시를 배포, 운영, 조정하는 데 사용되는 완전관리형 웹 서비스이다.

여러 개의 캐시 노드(EC2 Instance)들을 묶어 하나의 ElastiCache 클러스터로 관리한다.

ElastiCache는 Memcached와 Redis 두 가지의 유형이 있다.

기준	Memcached	Redis
DB 부하를 오프로드하는 단순 캐시	O	O
쓰기/스토리지를 위한 수평적 확장	O	X
멀티 스레드	O	X
고급 데이터 유형	X	O
데이터 세트 정렬 / 순위 지정	X	O
Pub/Sub 기능	X	O
자동 장애 조치가 있는 Multi-AZ	X	O
지속성	X	O
클러스터당 최대 캐시 노드 갯수	20개	90개

아래의 다이어그램은 애플리케이션 서버, 캐시, 데이터베이스의 흐름도를 나타낸다.

 

Write Through (연속 쓰기)

애플리케이션으로부터 쓰기 작업을 요청받으면 Cache와 오리진 DB에 모두 데이터를 입력한다. 

 

Lazy Loading

애플리케이션으로부터 읽기 작업을 요청받았을 때 캐시에서 요청한 데이터가 Hit되면 그대로 받아오기만 하고, 만약 Miss되어 데이터베이스로부터 읽어왔다면 캐시에 그 값을 저장한다.

 

CloudFront, 캐시, ELB를 포함한 3-Tier 웹 애플리케이션 아키텍처 예시