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

해당 글은 AWS Korea의 천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 강연를 토대로 정리한 글입니다.

AWS 리전과 가용영역

리전은 클러스터링된 큰 규모의 하나의 물리적 서비스 공간이며, 적어도 2개 이상의 가용영역으로 구성.

가용 영역은 하나 이상의 개별 데이터 센터로 구성되며 각 데이터 센터에는 이중화된 전원, 네트워킹 및 연결 구성이 되어 있으며 분리된 시설에 위치.

서울 리전의 경우 현재 4개의 가용영역이 있음.

100명 이하의 사용자

주요 고려사항

• 기본 아키텍처
  • 적절한 인스턴스 선택 및 스케일업
  • 데이터베이스 분리
  • 기본 보안 및 모니터링
• 비용 효율적 구성

아키텍처

사용자는 Route53이라고 하는 DNS 서비스를 통해서 Public IP를 찾아서 AWS VPC 안에 구성된 인스턴스와 연결하여 서비스를 시작.

인스턴스에서 Web과 WAS 역할을 하고 데이터는 별도 구성된 DB 인스턴스에 접근해서 가져오게 됨.

용도에 맞는 EC2 서버 선택

• 업무에 적합한 서버 선정
  • CPU, 메모리, I/O 별 인스턴스 타입
  • 필요 성능에 따른 스토리지 선택

기본 보안 구성

• 서브넷을 Public과 Private으로 분리함으로써 외부 사용자가 접근하는 네트웍과 데이터가 저장된 네트웍을 분리

• 각 인스턴스는 Security Group이라고 하는 Stateful 방식의 접근제어 서비스를 통해 필요한 Port와 IP만 접근할 수 있도록 구성

• AWS Shield 솔루션을 통해 DDos 방어 수행 - Standard 서비스는 AWS 사용시 기본 제공

기본 모니터링

• CloudWatch를 통한 리소스 메트릭 및 로그 모니터링
• 자동 대시보드 생성, 임계치 초과 알람 (SNS 연동)

1000명 이상의 사용자

주요 고려사항

• 이중화 구성을 통한 안정성 개선
  • 다중 가용영역 활용
  • 로드 밸런서를 통한 서버 이중화
  • 데이터베이스 이중화
• Managed DB 사용
  • RDS, Aurora DB 활용

아키텍처

기존에는 단일 인스턴스, 단일 데이터베이스였기 때문에 고려하지 않았지만, 서비스 안정성을 높이기 위해서 다중 가용 영역을 활용.

인스턴스를 하나 이상으로 늘린다는 것은 곧 스케일아웃, 수평적 확장을 의미한다. 이 때 인스턴스 앞 단에서 사용자 트래픽을 받아서 각 인스턴스에게 분배해주는 서비스가 필요.

그 서비스가 곧 Elastic Load Balancer, ELB라고 하는 서비스이다. ELB는 여러 개의 가용영역에 걸쳐 서비스할 수 있다.

ELB를 이용한 수평적 확장

• 여러 대상으로 트래픽을 분산
• 다중 가용 영역 지원
  • 가용영역은 1개 이상의 물리적 데이터센터를 연결한 독립적 전력, 네트워킹, 연결이 제공되는 기본 서비스 단위
• 자동으로 용량 확장
• 오토 스케일 그룹 지원
  • 자동으로 인스턴스를 ELB에 등록하고 제외

ALB vs NLB

• Application Load Balancer
  • HTTP와 HTTPS를 지원하는 L7 기반 로드 밸런서
  • 고가용성, 자동확장
  • 컨텐츠 기반 라우팅
  • HTTP/2
  • 헬스 체크
  • 세션 유지
  • 모니터링/로깅
  • WebSockets 지원
• Network Load Balancer
  • L4 레벨의 분기를 지원하므로 상대적으로 Throughput이 더 높음
  • 고가용성, 자동확장
  • 고정 IP
  • TCP, UDP, TLS 지원
  • 소스 IP 주소 유지
  • 헬스 체크
  • 세션 유지
  • 모니터링/로깅
  • WebSockets 지원

Amazon RDS - 관리형 데이터베이스

6개 데이터베이스 엔진 기반의 관계형 데이터베이스 관리형 서비스

• Amazon Aurora
  • MySQL, PostgreSQL과 호환
  • 3개의 가용 영역에 6벌 복제
  • 최대 15개 읽기 복제본
  • 최대 64TB 자동 스토리지 확장
  • Amazon S3 지속 증분 백업
• MySQL
• PostgreSQL
• MariaDB
• SQLServer
• Oracle

장점

• 간편한 관리
  • 데이터베이스 설치, 수동 패치 필요 없음
• 뛰어난 확장성
  • 손쉽게 컴퓨팅 및 스토리지 확장
• 가용성 및 내구성
  • Multi-AZ 구성시 자동 동기식 복제, 자동화 백업
• 성능과 낮은 비용

데이터베이스 이중화

다중 가용 영역에 읽기, 쓰기 인스턴스로 이중화 구성

10,000명 이상의 사용자

주요 고려사항

• 오토 스케일링 그룹
• 웹 성능 개선
  • 정적 컨텐츠 분리 및 캐싱
  • 동적 컨텐츠 가속화
• 운영 자동화
• 보안 고도화
• 비용 최적화

아키텍처

트래픽 변화에 대한 대응

온프렘 환경이라면 인스턴스 사이즈는 3번에 맞춰야만 한다.

클라우드 환경에서는 오토 스케일링을 통해 최적의 인프라 리소스를 자동으로 활용할 수 있도록 해준다.

오토 스케일링 그룹

EC2 인스턴스에 오토스케일링 그룹을 설정해서 내가 지정한 기준에 따라 인스턴스가 자동으로 늘어나거나 줄어들 수 있도록 구성할 수 있음.

일반 RDS의 경우는 DB의 스토리지에 대해서만 오토스케일링이 가능했지만, AuroraDB의 경우 인스턴스에 대해서도 오토스케일링이 가능함.

• 컴퓨팅 클러스터의 자동 수량 조절
• Pool 사이즈의 최소/최대 값을 지정
• 서버 장애 시 최소 수량만큼 자동 복구
• Amazon CloudWatch 지표 기반 스케일링

웹 성능 개선 - CloudFront

EC2나 DB와 같은 일반적 서비스를 하는 물리적 가용영역이 아니라 별도의 공간, 고객에 가까운 위치에 POP이라고 하는 전용선으로 연결된 에어리어를 두고 캐싱.

정적 컨텐츠는 캐싱을 하고 동적 컨텐츠는 인터넷이 아닌 전용구간 가속화를 통해 성능 향상.

사용자는 Route53에서 IP를 받고 CloudFront에 설정된 엔드포인트를 통해 접근, HTML, CSS, JS 뿐만 아니라 이미지와 동영상 같은 정적 컨텐츠는 S3를 오리진으로 해서 CloudFront에 캐싱하고 사용자에게 보다 빠르게 전달 됨.

Dynamic한 요청에 대해서는 CloudFront와 VPC 간의 내부 전용선을 통해 보다 빠르게 전송하고 앞서 구성한 ELB를 통해 각 인스턴스 및 DB로 접근해서 필요한 내용을 가져오는 구조.

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

운영 자동화 - Systems Manager

• 클라우드, 온프레미스 및 엣지에서 가시성 및 제어를 개선
• 운영 문제의 탐지 및 해결에 소요되는 시간을 단축
• 패치, 구성 및 사용자 지정 정책에 대한 인스턴스 규정 준수
• 애플리케이션 및 리소스의 구성 및 지속적인 관리 자동화

100,000명 이상의 사용자

주요 고려사항

• 컨테이너 기반 서비스 전환 컨테이너는 코드, 의존성, 런타임을 묶어서 만든 하나의 Immutable 단일 객체. Immutable 이라는 것은 형상을 운영 중 변경하는 것이 아니라 새로운 것으로 교체해 버린다는 의미. 커널 혹은 애플리케이션 레벨의 설정이 변경 되거나 코드가 바뀌는 경우에는 새로운 컨테이너로 교체를 해서 서비스.

  • 표준화, 경량화, 이식성, 쉬운 배포

• 데이터베이스 성능

  • 캐시 기반 읽기 성능 개선

아키텍처

마이크로 서비스를 위한 컨테이너 솔루션

컨테이너 기반 아키텍처 - EKS

기존 비즈니스 로직을 처리하는 EC2 인스턴스가 EKS로 변경되고 Worker Node들 안에 컨테이너 존재

EKS의 경우 별도 분리된 VPC에 EKS의 컨트롤 플레인을 다중 가용 영역에서 서비스, 내부적으로 ENI라고 하는 인터페이스를 통해 상호 연결.

AuroraDB의 경우 Read Replica를 여러 개 두어서 부하 분산 처리.

데이터베이스 읽기 캐시 - Amazon ElastiCache

• 관리형 Memcached 또는 Redis
• 한 개에서 여러 개의 노드로 확장
• 자가 복구 (문제 인스턴스 교체)
• 한 자리수 ms 속도
• 캐시, 세션 저장소, 채팅, 게임리더보드 등 다양한 케이스로 활용 가능

1,000,000명 이상의 사용자

주요 고려사항

• 데이터베이스 분산
  • 목적에 맞는 데이터베이스 분리
  • 샤딩을 통한 데이터셋 분리
• 재해복구 및 멀티리전 서비스
  • CFN, CDK를 통한 laC 구현
  • S3, RDS, DynamoDB 교차리전 복제

아키텍처

용도에 맞는 DB 서비스 적용

NoSQL 데이터베이스 - Amazon DynamoDB

장바구니나 위시리스트 같은 서비스를 별도로 DynamoDB로 구성.

관계형 DB의 경우에도 하나의 효율적 분산처리를 원하는 경우 샤딩을 구성해서 부하 분산 가능.

• 완전 관리형 NoSQL 데이터베이스
• 대규모 요청에도 한 자릿수 ms 응답 시간
• 페타바이트 규모 스토리지
• 프로비저닝된 스루풋
• 다중 리전 글로벌 테이블 복제
• DAX를 통한 읽기 및 쓰기 캐시

멀티리전 재해 복구

Infra as a code 서비스인 CDK를 이용할 수 있음.

파이썬이나 노드 JS, 타입스크립트, 자바와 같은 일반 프로그래밍 언어를 이용해서 인프라 및 서비스 구성에 대한 자동화 구현 가능.

이를 기반으로 재활용 가능한 템플릿을 구성하여 다른 리전에 빠르고 정확하게 서비스를 복구할 수 있음.

리전 1번으로 평상시에 서비스를 구축하고 운영하다가 문제가 발생한 경우 리전 2번에 CDK를 통해 빠르게 리소스를 복구시키고, S3와 데이터베이스 스냅샷 등을 통해 서비스 복구

10,000,000명 이상의 사용자

주요 고려사항

• 다중 리전 서비스
  • 다중 리전별 서비스 활성화
  • 데이터베이스의 글로벌 서비스

아키텍처

Aurora 글로벌 데이터베이스

• 데이터를 마스터링하는 하나의 기본 AWS 리전 및 최대 5개의 읽기 전용 리전 가능
• 짧은 복제 지연시간
  • 1초 미만의 짧은 복제 지연시간으로 리전 간 데이터 복제
• 빠른 복구
  • 기본 리전 장애 시 1분 이내에 타 리전에서 read-write 승격 가능

DynamoDB 글로벌 테이블

• 글로벌 테이블에 대해 각 리전 별 Local 읽기-쓰기 지원
• 짧은 지연시간으로 데이터 동기화

ElastiCache 글로벌 데이터스토어 for Redis

• 하나의 리전에서 Active Master의 역할을 하면서 읽기와 쓰기를 할 수 있고, 다른 리전에서는 해당 내용을 Cross Region Link를 통해 복제하고 읽기 전용으로 활용 가능
• 짧은 복제 지연시간
  • 1초 미만의 짧은 복제 지연시간으로 리전 간 데이터 복제
• 빠른 복구
  • 기본 리전 장애 시 1분 이내에 타 리전에서 read-write 승격 가능

여러 개의 리전을 Active하게 Route53을 통해 보다 가까운 지역에서 접근할 수 있도록 하고, 데이터에 대해서도 글로벌 데이터베이스 활용.

요약

• Single Point Of Failure를 없애는 구성
  • 이중화 및 Failover 구성을 항상 고려
  • 다중 가용역역 또는 다중 리전을 통한 서비스
• 오토 스케일링을 이용한 유연성 확보
• 성능 및 부하 분산을 위해 데이터를 캐시
• 확장성이 뛰어난 관리형 서비스 활용
• CloudFormation 및 CDKS를 이용한 프로비저닝
• 용도에 적합한 데이터베이스 사용
• 느슨한 결함/분산 아키텍처 적용
• 적절한 지표/모니터링/로깅을 하고 있는지 확인