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

천만 사용자를 위한 최종 Checklist

• 적절한 모니터링 (Cloud Watch 활용)
• ELB을 활용한 트래픽 분산 관리
• 가용영역을 분리하여 WEB/WAS를 분산.
• 오토 스케일링 그룹을 통해 서버 과부하, 장애방지.
• CloudFront 캐싱을 통해 빠른 속도로 데이터 전달.
• 컨테이너를 활용한 EKS를 통해 높은 확장성 확보.
• Elasticache를 통해 읽기 중심 서비스에 특화된 캐싱 제공.
• 샤딩을 통한 데이터셋 분리 처리.
• 데이터 형태에 따라 알맞은 DB활용.
• Aurora 글로벌 인터페이스를 활용하여 다중 리전에 복제하여 빠른 복구
• Dynamo DB 글로벌 테이블을 통한 빠른 데이터 동기화.
• DB 종류에 따라 로컬에 쓸 수 있는것과 아닌것을 구분.
• 멀티리전 DB를 통한 안정성 높은 서비스 고려.

---

AWS 서비스 기본 지식

• AWS 글로벌 인프라 스트럭처
  • 전세계 25개 지역(리전)에 81개의 가용영역(AZ)이 있다.
  • 한국에는 서울에 4개 영역이 가용 가능하다.
• AWS 리전 디자인
  • 고가용성, 높은 확장성, 높은 내결함성을 위해 여러 가용 영역(AZ, Availability Zones)으로 구성.
  • 애플리케이션과 데이터는 실시간 복제. 서로 다른 가용 영역에서 일관성 유지.
• AWS 서비스
  
• EC2(Elastic Compute Cloud) : 아마존 데이터 센터에 있는 가상화 서버.
  • 크기 조정 가능한 컴퓨팅 파워
  • 컴퓨터 리소스 완전 제어 제공
  • 새로운 서버 인스턴스 확보 및 부팅 시간 단축
  • 개발자가 쉽게 웹 규모 컴퓨팅 작업 가능
• EBS(Elastic Block Storage)
  

• EC2와 같은 가용영역 내에 있는 스토리지.
• 네트워크로 연결된 영구 블록 스토어.
• EC2가 정지 및 종료되어도 데이터 유지.
• io1은 54000 IOPS로 적은 데이터 빠르게 처리 용이 - st1은 처리량에서 우위. 용량이 큰 파일일때 유리.
• EBS의 최대 IOPS는 아무리 늘려도 프로비저닝(사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포 해 두었다가 필요시 시스템을 즉시 사용할 수 있는 상태로 미리 준비하는 것) 된 SSD 기준 64000IOPS. 더 빠른걸 쓰려면 인스턴스 스토어 사용해야 함.
  • 인스턴스 스토어 : 임시 블록 스토어. 인스턴스 종료나 정지 시 데이터 손실, 스냅샷 불가.
  • 버퍼, 캐시, 테스트용 초기 데이터 및 분산 파일 시스템에 사용.
• 요금 책정 방식
  • 프로비저닝 된 용량만큼 과금. 1TB볼륨을 사용하면 전체 용량을 다 사용하지 않아도 그 용량에 맞게 과금. (볼륨 크기는 생성 이후에 늘리기는 되나 줄이기는 되지 않으니 실제보다 용량을 적게 잡고 가는게 더 효율적.)
• AWS에서는 기본적으로 2진수 표현 단위로 사용(ex. GiB,PiB)

사용자 규모별 아키텍처

100명 이하의 사용자

• 주요 고려사항

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

• 용도에 맞는 EC2(Amazon Clastic Compute Cloud, 아마존 클라우드 컴퓨팅 플랫폼 아마존 웹 서비스의 중앙부. 가상 컴퓨터를 사용자가 임대 받아 위에서 애플리케이션 실행 가능.) 서버 선택

  • 업무에 적합한 서버를 선정할 수 있음. CPU, 메모리, I/O 별 인스턴스 타입
  • 필요성능(IOPS)에 따른 스토리지 선택
  • 용량 산정 고민 없이 필요할때 서버 타입 변경이 가능하다.
    • c5.9xlarge (컴퓨팅 최적화)
      • vCPU : 36 (호스트 컴퓨터 코어에 있는 하나의 스레드를 말함)
      • 메모리 : 72GiB
      • 인스턴스 스토리지 : EBS 전용
      • 네트워크 대역폭 : 10Gbps
      • EBS 대역폭 : 9,500Mbps
    • m5.2xlarge (범용)
      • vCPU : 8
      • 메모리 : 32GiB
      • 인스턴스 스토리지 : EBS 전용
      • 네트워크 대역폭 : 최대 10Gbps
      • EBS 대역폭 : 최대 4,750Mbps
    • t3.nano (범용)
      • vCPU : 2
      • 시간당 CPU 크레딧 : 6 (1분동안 CPU Boost를 해줄 수 있는 갯수)
      • 메모리 : 0.5GiB
      • 인스턴스 스토리지 : EBS 전용
      • 네트워크 대역폭 : 최대 5Gbps

• 데이터베이스 분리 및 기본 보안 구성

  

  • VPC(Veritual Private Cloud) : 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있다.
  • Amazon Route 53 : 아마존 DNS(도메인 이름 시스템) 서비스
  • Route53에서 public IP를 찾아서 AWS VPC안에 구성된 인스턴스와 연결하여 서비스.
  • 각 인스턴스는 Security group이라고 하는 stateful(server side에 client와 sever의 동작, 상태정보를 저장하는 형태)방식의 접근제어 서비스를 통해 필요한 port와 IP만 접근할 수 있도록 구성.
  • DDos 방어는 기본으로 수행.

• CloudWatch 를 통해 리소스 메트릭 및 로그 모니터링 가능. 자동으로 대시보드 생성해서 임계치 초과 알람.

1,000명 이상의 사용자

• 주요 고려사항
  

• 이중화 구성을 통한 안정성 개선
  - 다중 가용영역을 활용
  - 로드 밸런서(서버에 가해지는 부하를 분산해주는 장치 및 기술)를 통한 서버 이중화
  - 데이터베이스 이중화

• Managed DB 사용
  - RDS, Aurora DB (둘 다 아마존 관계형 DB)

• 다중 가용 영역 활용

  

  • 100명과 동일한 구조를 가지고 가용영역을 추가하는 방식
  • 가용영역 : 1개 이상의 물리적 데이터센터를 연결한 독립적 전력 네트워킹, 연결이 제공되는 기본 서비스 단위.

• ELB(Elastic Load Balancing)를 이용한 수평적 확장 (보통 아마존에서 쓰는 로드 밸런싱을 통칭하는 용어임)
  

  • 여러 대상으로 트래픽을 분산
    • EC2 인스턴스, 컨테이너, IP주소
  • 다중 가용 영역 지원
  • 자동으로 용량 확장
  • 오토 스케일(EC2 인스턴스 모음) 그룹 지원
    • 자동으로 인스턴스를 ELB에 등록하고 제외함.

• ALB vs NLB

  • ALB
    • L7단의 로드 밸런서 지원.
    • HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송
    • IP, Port 이외에도 URL, Payload, Http Header, Cookie등(패킷 내용)의 내용을 기준으로 부하를 분산.
    • 콘텐츠 기반 스위칭이라고도 한다.
    • IP 주소가 변동되기 때문에 클라이언트에서 access 할 ELB의 DNS name을 이용해야 한다.
  • NLB
    • L4단의 로드 밸런서를 지원
    • TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송
    • IP, Port를 기준으로 스케줄링 알고리즘을 통해 부하를 분산
    • IP 주소가 고정이기 때문에 DNS name과 IP주소 모두 사용 가능.
    • 요청하는 서비스의 종류와는 상관없이 여러개의 공장을 돌리는 방식.
    • 네트워크 계층까지만 확인하기 때문에 7계층인 ALB보다 빠름.
    • 단순한 라우팅이 필요하고 트래픽이 많은 경우에는 NLB가 적합함.

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

  • 6개의 데이터 베이스 엔진 기반의 관계형 데이터베이스 관리형 서비스
    • 아마존 오로라, MySQL, PostgreSQL, MariaDB, Microsoft SQL server, Oracle

• 데이터베이스 관리자의 역할 변화.

  • 이제 어플리케이션 단에서만 신경쓰면 된다.

• Amazon Aurora
  

  • MySQL, PostgreSQL 호환
  • 3개의 가용 영역에 6벌 복제
  • 최대 15개 복제본.
  • 최대 64TB 자동 스토리지 확장
  • Amazon S3(아마존 웹 서비스에서 제공하는 온라인 스토리지 웹 서비스) 지속 증분 백업

• 결국 최종 DB 이중화
  

  • web/was로 가용영역을 나눠 씀.
  • 들어오는 트래픽은 ELB로 적절히 나눠 분산처리.

10,000명 이상의 사용자

• 주요 고려사항
  

• 오토 스케일링 그룹

  • 웹 성능 개선
    • 정적 컨텐츠 분리 및 캐싱
    • 동적 컨텐츠 가속화
  • 운영 자동화
  • 보안 고도화
  • 비용 최적화

• 트래픽 변화에 대한 대응이 주요한 사항임

• 오토 스케일링 그룹

  

  • 풀을 만들어서 최소, 최대값을 지정하고 어떤 기준으로 확장할지 선택해주면 CloudWatch 지표 기반으로 자동 스케일링.
  • 서버의 과부하, 장애등과 같은 서비스 불능 상황 발생시 자동으로 서버를 복제하여 서버 대수를 늘려주는 작업을 해줌.
  • CloudWatch 지표를 기반으로 스케일링한다.
  • 온디맨드(이용한 만큼 비용 지불) 혹은 스팟(AWS내에 남아있는 서버 공간을 빌려서 사용하는 방식)으로 이용 가능하다.

• 웹 성능 개선 - CloudFront

  

  • CloudFront
    • 아마존에서 운영하는 CDN(콘텐츠 전송 네트워크) 서비스
    • 캐싱을 통해서 사용자에게 좀 더 빠른 속도를 제공함.
    • 물리적 공간이 아니라 고객에 가까운 위치에 POP(48개국 90개 넘는 도시에 410개 넘는 pop로 구성된 네트워크를 사용)라고 하는 전용선으로 연결된 에어리어를 두고 여기에 캐싱을 함.
    • 전 세계에 Edge server를 두고 가장 가까운 Edge server에서 데이터를 제공해 레이턴시를 최소화 함.
    • HTML, CSS, JS뿐 아니라 이미지와 동영상 같은 static contents는 S3를 오리진으로 해서 Amazon CloudFront에 캐싱하여 사용자에 빠르게 전달.
    • Dynamic한 요청에 대해서는 CloudFront와 VPC간의 내부 전용선을 통해 빠르게 전송.

• 운영 자동화 - Systems Manager

  • 클라우드, 온 프레미스(기업 자체 시설에서 보유하고 직접 유지 관리하는 프라이빗 데이터 센터)및 엣지에서 가시성 및 제어 개선
  • 운영 문제 탐지 및 해결 소요 시간 단축
  • 사용자 지정 정책에 대한 인스턴스 규정 준수
  • 시스템 패치와 인벤토리 관리에 대한 자동화

• 보안 고도화

  • AWS WAF(Web Application Firewall) : 웹의 비정상 트래픽을 탐지하고 차단하는 방화벽. 단순 방화벽과는 다르게 TCP/IP 레벨이 아니라 HTTP 정보를 바탕으로 차단 룰을 설정.
  • AWS Shield : DDoS 공격에 대해 보호 (앞에서 나온 것보다 더 향상됨)
  • Amazon GuardDuty : 지능형 위협 탐지. 잠재적 위협을 식별하고 우선순위 지정.

• 비용 최적화

  • 온디맨드 : 장기 약정 없이 사용한 만큼
  • 세이빙스 플랜 : 1년 또는 3년 시간당 사용 약정
  • 스팟 : 온디맨드 대비 최대 90%할인. (남는 서버 공간 사용)

100,000명 이상의 사용자

• 주요 고려사항
  

• 컨테이너 기반 서비스 전환

  • 데이터베이스 성능
    • 캐시 기반 읽기 성능 개선

• 컨테이너를 쓰는 이유?

  • 컨테이너 : 애플리케이션의 코드, 구성 및 종속성을 하나의 객체로 패키징하는 표준화된 방식을 제공. (코드, 의존성, 런타임을 묶어서 만든 하나의 불변단일 객체 →운영중 만약 코드가 바뀌거나 애플리케이션 레벨의 설정이 변경되면 새로운 컨테이너로 교체해줌)
  • 가볍고 쉽게 실행하고 확장할 수 있는 애플리케이션을 위한 일관적인 이동식 소프트웨어 환경 제공.
  • 마이크로 서비스 운영에 있어서 필수적이다.

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

  • 컨테이너 관리
    • ECS(Elastic Container Service) : 컨테이너화된 애플리케이션 실행 또는 마이크로 서비스 구축할때 ECS는 완전 관리형 컨테이너 오케스트레이션 서비스로 안전하고 신뢰성과 확장성이 뛰어난 솔루션 제공.
    • EKS(Elastic Container Service for Kubernetes) : Kubernetes(구글에 의해 설계되고 현재 리눅스 재단에서 운영하는 컨테이너화된 애플리케이션 관리 시스템)로 컨테이너화된 애플리케이션을 실행하는 가장 안전하고 신뢰성, 확정성이 뛰어난 솔루션 제공
  • 호스팅
    • EC2 : 서버 수준 제어를 통해 컨테이너 실행.
    • Fargate : 서버를 관리하지 않고 컨테이너를 실행. 서버리스 컴퓨팅 엔진으로 ECS, EKS와 연동된다. 애플리케이션별로 리소스를 지정하고 관련 내용을 지불할 수 있음. 애플리케이션을 격리하도록 설계되어있기 때문에 보안 성능향상.
  • 이미지 저장소
    • ECR(Elastic Container Registry) : 컨테이너에 이미지를 압축하고 암호화하여 어디서든 빠르게 시작하고 사용할 수 있음.

• 데이터 베이스 읽기 캐시 (Amazon ElastiCache)

  • 분산 인 메모리 캐시를 손쉽게 생성하고 확장할 수 있는 서비스
  • 읽기 중심의 서비스(소셜 네트워크, 게임, 추천 엔진 등)을 제공해야 하는 환경, 고속으로 데이터를 분석해야 하는 환경에 적합.
  • 관리형 Memcached(분산 메모리 캐시 시스템), Redis(다양한 데이터 형식을 제공하는 키값 데이터 저장소)

• 결국 최종 EKS

  

  • EC2 인스턴스가 EKS로 변경. worker node 안에 컨테이너가 띄워져있음.
  • EKS는 별도로 분리된 아마존 VPC에 EKS 컨트롤 플레인을 다중 가용 영역에서 서비스 하고 있으며 내부적으로 ENI(Elastic Network Interface)라는 인터페이스를 통해 상호 연결됨.
  • Aurora DB도 read replica 여러개 두어서 부하를 분산처리
  • read, write 엔드포인트를 따로 두어서 read 엔드포인트를 변경하게 되면 DNS 기반으로 엔드포인트에 반영
  • 데이터베이스 읽기 캐시를 쓰기 위해서 ElasticCache를 활용.
  • 애플리케이션에서 SDK를 이용해 캐시를 먼저 읽고 miss 되면 DB에서 가져오는 방식.
  • 로그도 통합 구성

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

• 주요 고려사항
  

  • 데이터 베이스 분산
    • 목적에 맞는 데이터베이스 분리 (기존에는 관계형DB만 있었다면 이제 용도에 따라 다르게 써야함)
    • 샤딩(데이터를 여러 조각으로 나누어 저장하는 기술)을 통한 데이터셋 분리
  • 재해복구(DR) 및 멀티리전 서비스
    • CFN,CDK를 통한 IaC구현
    • S3, RDS, DynamoDB 교차리전 복제

• 용도에 맞는 DB 서비스 적용

  • Relational : 기존 어플리케이션 ( RDS(아마존 관계형 DB서비스), Aurora, RedShift(아마존 대형 클라우드 컴퓨팅 플랫폼) )
  • In-memory : 캐싱, 세션관리, 지리 공간 애플리케이션 (ElastiCache, MemoryDB)
  • Key-Value : 높은 트래픽의 웹 앱, 전자 상거래 시스템, 게임 (Dynamo DB)
  • Document : 콘텐츠 관리, 사용자 프로필, 카탈로그, MongoDB호환 (DocumentDB)
  • Wide Column : 장비 관리, 차량 관리 및 경로 최적화에 사용하는 대규모 산업용 앱 (Keyspaces)
  • Graph : 부정 탐지, 소셜 네트워킹, 추천 엔진 (Neptune)
  • Time Series : IoT 애플리케이션, DevOps (Timestream)
  • Ledger : 블록체인 기반. 레코드 시스템, 은행거래 (QLDB)

• NoSQL DB (Amazon DynamoDB)

  • 완전 관리형 NoSQL DB
  • 대규모 요청에서 한자릿수 ms 응답 시간
  • 장바구니나 위시리스트 같이 쓰기 작업이 많이 필요한 경우 또는 스키마의 유연성이 필요한 경우에 활용 가능.
  • 프로비저닝된 스루풋을 보장해주는 구조기 때문에 적절히 활용하면 서비스 성능을 일관성 있게 유지할 수 있다.
  • DAX라 하는 자체 읽기 및 쓰기 캐시 서비스를 통해 보다 빠른 응답시간 보장받을 수 있다.

• 용도에 맞는 DB 서비스

  

  • 장바구니나 위시리스트같은 특정 서비스를 별도로 DynamoDB로 구성해서 데이터 페더레이션(여러 DB가 하나로 기능하도록 하는 sw)으로 구축
  • 관계형 DB인 Aurora가 하나의 클러스터로 표현되어 있으나 샤딩을 구성해서 부하를 분산할 수 있다.

• 멀티리전 재해 복구

  • infra as as code 서비스인 CDK(Cloud Development Kit)를 이용할 수 있다. 기존 CloudFormation과는 다르게 파이썬, node.js, typescript, java와 같은 일반 프로그래밍언어를 통해서 인프라 및 서비스 구성에 대한 자동화를 구현할 수 있음.
  • 이를 통해 재활용 가능한 템플릿을 만든다던가, DR 상황에서 다른 리전에 빠르게 서비스를 복구할 수 있음.

• S3 교차 리전 복제

  • 다른 리전에 데이터를 백업
  • 한 리전의 S3에 업로드 되는 file이 다른 리전에 자동 복제 sync 가능.
  • tag 기반 선택적 복제 가능
  • 재하복구, 컴플라이언스(법규준수/내부통제) 준수, 낮은 지연시간 서비스에서 활용

• RDS snapshot 교차 리전 복사 (RDS는 개별 DB가 아니라 전체 DB 인스턴스를 백업하여 DB 인스턴스의 스토리지 볼륨 스냅샷을 생성. 이떄 백업이 예비 복제본으로부터 수행되기 때문에 기본 AZ에서의 I/O가 중단되지 않는다.)

  • 한 리전의 DB를 데이터와 엔진까지 전체 snapshot 복사
  • 다른 리전에서 snapshot으로 DB 인스턴스 생성 가능
  • 증분복사(이전에 복사된 내용 빼고 복사) 기능으로 변경된 데이터만 복사 가능
  • 빠른 시간에 재해복구을 위한 DB 생성 가능

• 멀티리전 DR(Disaster Recovery) 아키텍쳐

  

  • 리전 1번에서 평상시에 서비스 운영 하다가 문제가 발생하면 2번에 CDK를 통해 빠르게 리소스를 복구
  • S3와 DB 스냅샷 등을 통해 서비스를 복구하는 구성을 생각해 볼 수 있다.

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

• 주요 고려사항

  

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

• Aurora 글로벌 데이터베이스

  • 짧은 복제 지연시간
  • 빠른 복구
  • 여러개의 리전에 읽기 전용 인스턴스를 두고 서비스를 구현할 수 있다.
    • 데이터를 마스터링 하는 하나의 기본 리전과 최대 5개의 읽기전용 리전을 둘 수 있다.

• DynamoDB 글로벌 테이블

  • 글로벌 서비스에 더 적합함. 각 리전별로 읽기 및 쓰기까지 가능.
  • 짧은 시간 안에 데이터 동기화 가능.
  • 로컬에서 읽기 및 쓰기를 수행하면 변경 사항들은 자동으로 글로벌 리전으로 전파됨으로써 일관성 유지 가능.

• ElastiCache글로벌 데이터스토어 for Redis(다양한 데이터 형식을 제공하는 키값 데이터 저장소)

  • 하나의 리전에서 Active Master의 역할을 하면서 읽기와 쓰기를 할 수 있음. 다른 리전에서는 해당 내용을 cross-regin link를 통해 복제하고 읽기 전용으로 쓸 수 있음.

• 최종 아키텍처

  

  • 여러개의 리전을 Active하게 Route53을 통해 보다 가까운 지역(리전)에서 접근 가능.
  • 데이터에 대해서도 AWS 글로벌 DB를 활용
  • DB 종류에 따라 로컬에 쓸 수 있는것과 아닌것을 구분해야함.
  • 멀티리전 DB를 통해 높은 성능과 안정성을 가지고 서비스 할 수 있음.

Summary

• 정해진 답은 없음. 단순히 Best Practice일뿐.
• 상황에 맞춰 유연하게 적용해야함. 순서가 바뀔 수 있고 없는 내용이 추가될 수 있음.
• 중요한 것은 Single Point of Failure을 없애는 구성.
  • 이중화 및 Failover 구성을 항상 고려
  • 다중 가용영역 또는 다중 리전을 통한 서비스.
• 성능을 위한 캐시의 활용 필요.
• Infra as a code(CloudFormation ,CDK)를 통해 자동화되고 일관성 있는 서비스 구현할 수 있음.
• 관계형 DB가 기본이긴 하나 꼭 그것만 고집할 필요 없이 적절히 활용해야 한다.
  • 서비스에 맞게 분리하여 구성함으로 부하를 줄이고 사용자 경험을 높일 수 있음.
• 느슨한 결합과 분산 아키텍처 적용. 이때 컨테이너가 효율적임
• 모니터링, 로깅은 매우 중요.
  • 사용자의 행동 데이터를 이용한 개인화 추천과 같은 높은 수준의 서비스를 제공할 수 있음.