천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기

AWS는 전세계에 약 20개의 리전, 즉 거점을 제공함.

리전하나에는 최소 두 개이상의 AZ(가용영역)이라고 하는 논리적인 데이터 센터들의 클러스터가 존재한다.

전세계의 유저들에게 빠르게 컨텐츠를 제공하려면 CDN서비스가 필요하며 AWS는 CloudFront라고하는 CDN서비스를 제공하고 있다. CloudFront는 전세계에 166개 이상의 엣지 로케이션에서 서비스되고 있다.

실 사용자 1명

페일오버, 이중화 필요없음.

아주 단순한 구조. VM에 고정 IP(Elastic Ip)를 부여하고, 고정 IP를 통해서 접근할 수 있지만, IP는 외우기 힘드므로 AWS Route 53을 이용해서 도메인 주소로 접근할 수 있게한다.

더 큰 시스템 필요 시

가장 단순한 접근으로는 수직적 확장을 하는것인데 언젠가는 결국 한계에 봉착한다.

실 사용자 1명 이상

하나의 인스턴스에 있던 DB를 따로 분리해준다.

DB

EC2에 직접 DB를 설치하고 관리할 수 있다.

하지만 서비스가 커질수록 공수가 많이 들어간다.

따라서 AWS에서는 관리형 DB를 제공한다.

RDS : 관계형 데이터베이스
DynamoDB : NoSQL
Neptune : Graph DB
DocumentDB : MongoDB 호환

RDS

총 6개의 DB엔진을 지원함.

Amazon Aurora

MySQL 또는 Postgres와 호환
자동으로 스토리지 확장
최대 15개의 읽기 전용 복제본
S3로 지속적인 백업
3개의 AZ(가용영역)에 6개의 데이터 복제
Serverless
실제 사용 데이터베이스 용량(ACU) 초단위로 과금

등록, 로그인

AWS Cognito사용

보안 체크리스트

AWS IAM : 팀원 별 권한을 다르게 설정 가능

AWS CloudTrail : AWS는 모든 리소스 활용이 API로 이루어 진다. Api의 활동내역을 기록하고, 관리하는 것.

AWS GuardDuty : 불법적인 침입, 침투를 탐지할 수 있다.

AWS Shield : DDOS방어 솔루션.

AWS Certificate Manager : SSL, TSL 인증서관리를 위한 서비스.

AWS Config : AWS리소스 전체를 변경, 관리해주는 서비스.

실 사용자 100명 이상

EC2 인스턴스에 직접 DB를 올리는 것이 아닌 RDS로 전환해서 관리에 대한 공수를 줄여나감.

실 사용자 1000명 이상

가용성이 중요해진다. 서비스에 문제가 생겼을 시 불만이 굉장히 많을 것.

가용성

위의 그림을 보면 VPC내부에 2개의 AZ(가용영역)이 표현되어 있다. 각 가용영역에는 EC2 instance와 RDS instance가 위치해있다.

가운데에 위치해있는 ELB(Elastic Load Balancing)는 사용자로 부터 온 요청을 로드밸런서가 받아서 가용영역에 있는 EC2로 골고루 분산시켜 주는것.

ELB

Application Load Balancer : L7쪽 담당
Network Load Balancer : L4쪽 담당
Classic Load Balancer : Application, Network Load Balancer가 나오기 이전의 Load Balancer, 권장하지 않음.

ALB(Application Load Balancer)

고 가용성
1 ~ 65535 포트 사용 가능
상태 검사(helth check)
세션 유지
모니터링 / 로깅
컨텐츠 기반 라우팅
WebSockets
HTTP/2

컨텐츠 기반 라우팅 가능, 따라서 A 컨텐츠를 제공하는 EC2 그룹과 B 컨텐츠를 제공하는 EC2 그룹이 있을 때 A 컨텐츠 요청이 온다면 A 컨텐츠를 제공하는 그룹으로 요청을 보내준다.

ELB 사용 및 확장

수직적 확장은 한계가 존재하고, 수평적 확장은 사실상 한계가 없다.

ELB를 사용하지 않는다면 수평적 확장 시 굉장히 공수가 많이 들겠지만, ELB를 사용한다면 간편하게 수평적 확장을 할 수 있다.

실 사용자 10000명 이상

사용자의 요청을 최대한 분산하고, 그것을 수용할 수 있는 많은 인스턴스들을 관리해야 함.

각 가용영역에 4개씩 EC2 instance가 생겼고, 그 사이에는 ALB가 위치해있다.

또한 Web Server 이외에도 DB도 확장성을 가져야 한다. Master DB를 놓고 각 각의 AZ에 여러개의 읽기전용 복제본을 두어서 읽기에 대한 노드들을 분산시킨다.

정적 컨텐츠 부하 분산

AWS S3와 CloudFront를 사용해서 정적 컨텐츠에 대한 부하를 나눠가질 수 있다.

S3(Simple Storage Service)

오브젝트 기반 스토리지
높은 내구성 (eleven nine)
정적 자산에 최적화
무한 확장 가능
오브젝트 당 5TB까지 지원
전송 중 / 저장 시 암호화

CloudFront

AWS의 CDN 서비스

빠른 컨텐츠 전달을 위해 캐싱
오리진 측의 부담을 덜어줌
동적 / 정적 컨텐츠 / 스트리밍 비디오
사용자 SSL 인증서
낮은 TTL
최적화

Data Layer 부하 분산

데이터 레이어에 대한 부하 분산은 Cache를 이용하는 방법이다.

AWS ElasticCache

관리형 Memcached 또는 Redis
한 개에서 여러 개의 노드로 확장
자가 복구
한 자리수 ms 속도
Memcached로 하나의 AZ에서 서비스
Redis에서 여러 AZ에서 서비스

AWS DynamoDB

완전 관리형 NoSQL DB
프로비저닝된 스루풋
빠르고 예상 가능한 성능
완전 분산, 내결함성
한 자리수 ms 속도
아이템 당 최대 400KB, JSON 지원
TTL
스트림 / 트리거 역할
AWS 어플리케이션 오토스케일링
글로벌 테이블

더 높은 확장성

오토 스케일링

아마존 닷컴을 예시로 블랙 프라이데이 이전에 미리 준비하는 컴퓨터의 용량은 블랙 프라이데이 전, 11월 초에는 필요없음에도 미리 준비해서 그만큼의 비용 낭비가 발생함.

오토 스케일링을 적용하면 트래픽에 맞춰서 리소스를 할당하므로 비용 최적화를 이룰 수 있다.

실 사용자 500000 이상

오토스케일링을 적극적으로 활용해야함.

오토스케일링 그룹을 AZ간에 걸치도록 만드는 것을 권장하고, 오토스케일링 그룹 내 유지되어야할 인스턴스의 수를 지정하면 한쪽의 AZ가 작동 불능상태가 되었을 시 다른 AZ가 작동 불능된 AZ의 트래픽까지 받아야하므로 해당 AZ에 추가적인 instance가 필요하게 되는데 위처럼 설정을 한다면 오토스케일링이 알아서 해준다.

자동화

AWS System Manager

AWS 클라우드 뿐만 아니라 온프레미스도 지원
관리자의 작업을 자동화
쉘 접근(베스천 서버 없이)
저렴한 가격

VPC 내에 존재하는 EC2를 접근할 때 기존에는 보안상 이유로 베스천 서버를 둬서 한 단계 경유해서 접근해야 했는데, 위 서비스를 이용하면 베스천 서버 없이 콘솔에서 EC2의 쉘 접근이 가능하게된다.

제어권을 많이 가진다면 컨트롤 할 수 있는 영역이 많아지지만 자동화는 포기해야하고, 자동화를 중시한다면 편해지지만, 컨트롤 할 수 있는 영역이 적어지므로 관리자의 편의에 맞게 골라야한다.

AWS Code 서비스

Cloud9 : 웹 브라우저 상에서 개발 IDE 환경을 제공하는
CodeCommit : 형상관리 서비스
CodeBuild : 빌드를 지원
CodeDeploy : 배포를 지원
CodePipeline : 위의 파이프라인을 관리해주는 서비스.

AWS CodeStar

AWS 상에서 어플리케이션을 빠르게 개발, 빌드, 배포

AWS에서 개발을 수 분 내 시작
보안을 지키며 팀 간 협업
소프트웨어 배포 관리가 쉬워짐
여러 프로젝트 템플릿 선택 가능

사용자 수가 500000이상이라면..

성능 모니터링에 힘을 써야한다. 그래야 사용자의 경험이 좋아진다.

AWS CloudWatch

모니터링을 위한 서비스

수집 : 지표와 로그들
모니터링 : 알람과 대시보드
액션 : 오토 스케일링과 이벤트
분석 : 추이와 지표 계산
컴플라이언스와 보안

MicroService

기존 모놀리식 아키텍쳐 : 사용자 인터페이스, 비즈니스 로직, 데이터 접근이 의존도를 가지고있으므로 업그레이드 시 굉장히 많은 준비와 시간이 필요하게된다.

SOA(Service Oriented Architecture)

티어별로 구조를 쪼게게 된다(Presentition Tier, Logic Tier, Data Tier), 로직 티어에서는 Feature단위로 쪼게게 된다.

MSA(Micro Service Architecture)

Feature를 최소단위로 쪼갠 것.

AWS SQS & SNS

Loose coupling(느슨한 결합)을 구현하기 편리하다.

A서비스와 B서비스가 있을 때 A서비스의 요청을 B서비스가 반드시 받아야할 때 B는 꺼지면 안된다. 즉 업그레이드 시 다운타임이 있으면 안된다.

SQS를 둬서 큐를 써서 메시지를 받는다면 업그레이드 시 큐가 A서비스의 요청을 받아놓고, B서비스가 올라왔을 때 SQS에서 받아서 소비할 수 있으므로 다운타임이 없다.

AWS Lambda

이벤트가 발생하면 함수가 실행된다.
내부적으로 스케일링
Serverless

ALB, EC2, DB를 API Gateway, Lambda, DynamoDB로 대체가능.

AWS X-Ray

성능의 병목 원인과 에러 파악
어플리케이션의 특정 서비스 이슈 파악
어플리케이션의 사용자에 대한 영향도 파악
어플리케이션의 서비스 호출 그래프 시각화

실 사용자 1000000 이상

사용자가 백만이 넘어가면 앞에서 이야기했었던 기능들이 더욱 필요해진다.

다중 AZ
계층(Tier) 사이에 ELB
오토 스케일링
SOA
컨텐츠 전송의 최적화(CloudFront + S3)
DB 캐싱

Multi AZ는 Default로 깔고 가는것이므로 이제부터 그림의 VPC 내부에 AZ는 없다.

기존에는 ELB를 외부에서 오는 요청만 분산시켰다면, 이제는 내부에서의 요청도 분산시켜줘야한다.

가장 오른쪽에 Serverless 웹 어플리케이션 스택이 있는데, VPC안에서 운영하던 서비스를 건드리지않고, 실험적으로 웹 서비스를 빠르게 제공하고싶을 때 쉽게 할 수 있음.

워커노드에서 SQS를 바라보고있는데 대량의 요청이 들어왔을 때 SQS에 큐잉 해놓고 필요할 때 꺼내쓰는 형식으로 구축해서 많은 데이터 또는 많은 요청이 들어와도 문제없이 서비스가 이루어 질 수 있도록 한다.

실 사용자 5 백만 ~ 1천만

데이터 베이스 이슈

해결책

역할 별로 여러 DB로 쪼개기
샤딩 - 여러 DB인스턴스로 하나의 데이터 세트를 쪼개기
어떤 기능은 다른 타입의 DB로 이관 (NoSQL, Graph 등)

리뷰

다중 AZ 적극적으로 활용
확장성이 뛰어난 서비스들을 활용 - ELB, S3, Lambda, SNS, SQS, Step Functions 등
모든 계층에 이중화 적용
SQL부터 시작
인프라의 안쪽(Data layer)과 바깥쪽(Static data)에서 데이터를 캐시
인프라에 자동화 툴들을 이용
적절한 지표/모니터링/로깅
각 계층을 개별 서비스로 분리(SOA)
오토 스케일링 이용
바퀴를 다시 발명하지 마세요
적절한 때가 되면 NoSQL로 이행

실 사용자 1천만 이상

어플리케이션을 더 정교하게 튜닝
더 많은 영역에서 마이크로서비스 적용
멀티 AZ에서 멀티 리전으로 진화
멀티 리전을 가장 쉽게 적용할 수 있는 서비스는 DynamoDB 글로벌 테이블이다.
전체 스택에 대해서 깊은 분석 진행
가능하다면 언제나 서버리스 적용

클라우드 아키텍처 진화하기