아래 Medium 블로그로 이전합니다.

https://medium.com/@nuatmochoi

Amazon MemoryDB for Redis

• 다중 AZ의 내구성을 갖춘 Redis 호환 인메모리 DB 서비스
• DMS 통해서 ElastiCache에서 Migration 가능

ElastiCache for Redis 가 있는데 왜?

• MSA로 오면서, Hot Data를 지원하기 위한 데이터베이스가 필요했다
  • Fast
  • Flexible
  • Friendly
• DB를 관리하기 어려워질 수 있다 (항상 가동)
• Robust 하게 만들기가 어렵다. (내구성 및 데이터 손실 zero)
• Scaling 어려울 수도
• 비싸거나
• ElastiCache는 기본 DB및 다른 저장소의 Data를 캐싱 or 내구성이 필요하지 않은 일시적 데이터를 위함
  • memcached와 비슷하게 이슈가 있어서 노드가 다운되면 데이터가 날아감
  • 직접 구성하는 Redis의 경우 HDD에 저장되겠지만, ElastiCache는 날아감
    • 단일 노드의 경우 AOF 기능을 통해 노드 재부팅 시 데이터 지속, but 노드 손상 시 데이터 손실
    • multi-AZ(replica) 구성 시에도 노드 승격이 비동기 작업이기 때문에 down-time은 발생할 수 있음
  • 따라서 Multi AZ가 필요함
• MemoryDB는 멀티 AZ 내구성 / 애플리케이션의 기본 DB(Primary DB)로 지정 가능 (캐싱과는 별개) / 그러면서 Redis API와 호환
  • 영구 저장
  • 쓰기 속도는 ElastiCache보다 좀 느림 (ElastiCache는 쓰기 읽기 모두 microsecond 단위)

기능

• microsecond read / 한자리 ms write
• cluster scale out 시 초당 수백만 건의 트랜잭션까지 가능
  • 처리량이 높고 대기 시간이 짧은 까다로운 애플리케이션 지원 가능
• 관리작업 (스냅샷 등) 자동화
• Redis API 100% 호환하는 Primary DB
• multi-AZ 기본 지원 (cluster mode를 통함)
• DB의 key set 별로 샤드당 최대 5개의 복제본 생성하여
  • 해당 key space에 대한 고가용성 및 읽기 성능 확장
• 최대 500개의 노드를 가질 수 있음
  • 250개의 Primary + 250개의 Replica (multi-AZ에 따라)
  • 클러스터 당 128TB의 저장소까지 지원

사용 사례

• 리테일 : 고객 프로파일, 계정 정보 저장 / 재고 트래킹 및 이행 (추적 및 제공)
• 게임 : 리더보드, 플레이어 데이터 스토어, 세션 히스토리
• 은행 및 금융 : 유저 트랜잭션, 사기 탐지(실시간 - 빠르게 레코드를 수집하고 Redis를 활용하여 실시간 분석)
• 미디어 : 유저 데이터 및 실시간 스트리밍
• IoT : 들어오는 데이터에 대한 실시간 분석 / redis의 기능인 공간 조회(spatial lookup --> 공간 반경 등)

벤치마크

• R6g.16xlarge 에서
• 초당 390,000개의 reads / 1.3GB/s read
• 초당 100,000개의 write / 100MB/s write

스케일링 매우 쉽다

• aws memorydb update-cluster --cluster-name my-cluster --shard-configuration ShardCount=5

오픈소스 Redis 라면..

• 데이터 전송 시 기본 시스템이 다운되면, 해당 Replica와 해당 데이터는 사라질 것 (Primary가 act, but not deliver)
• MemoryDB는 이를 내부적으로 multi-AZ transaction log에 저장하여 모든 노드에 저장되고 원하는 곳으로 전달될 것.
• 모든 것은 Primary DB로 Redis를 제공하기 위한 설계

AWS 서비스간 비교 (내구성 측면 )

ElastiCache for Memcached

• 내구성 측면 지속성 없다.

ElastiCache for Redis

• 내구성 없으며, 실제로 다른 데이터 베이스를 캐싱하거나
• 임시 데이터의 Primary DB 역할을 할뿐임
• 스냅샷을 사용하거나(연속 스냅샷은 불가)
• 다른 노드에 대한 비동기식 복제 --> 문제는 비동기이므로 데이터 손실 생길 수 있음

MemoryDB for Redis

• Multi AZ transaction log -> 모든 쓰기 작업은 내구성을 가짐

Reference

• https://youtu.be/RvBbaKl9k6w?t=1795

AWS EFS

• 관리형 파일 스토리지
• 온프레미스의 NFS, NAS와 동일한 서비스
• 수천대의 EC2 인스턴스간 파일 시스템 공유 가능. 병렬 접근이 가능하도록 설계되어 IOPS가 파일시스템이 커짐에 따라 탄력적으로 설정됨
  • 따라서 두 개 이상의 EC2로부터 하나의 공유된 스토리지 공간이 필요할 때 EFS 채택

• EFS 생성 시 VPC 내 가용영역의 서브넷에 Mount Target 생성
• Linux만 지원하며 Windows는 지원하지 않음 (필요하다면 Linux와 SAMBA 연동 필요)
• Direct Connect와 VPN 연결을 통해 온프레미스 NFS, NAS와 연결이 용이하다.

Vs EBS

• EFS는 EBS와 다르게 Multi-AZ 가능
• 단일 EBS 볼륨의 최대 크기는 최대 16TB까지 될 수 있지만 EFS 볼륨 크기는 사실상 무제한이다. EFS에서 파일의 최대 크기는 47.9TB이다. EBS는 파일 크기 제한 없음.
• EBS, EFS 모두 높은 내구성을 제공하지만, 확장성에서 차이가 있음. EFS 볼륨은 워크로드 수요의 급격한 증가를 수용하기 위해 빠르며 자동으로 수행되는 Scale-up/down이 가능함.
• EFS는 S3와 비슷하게 lifecycle 관리를 통해 스토리지 클래스를 전환하여 비용을 절감할 수 있음
• EBS는 디스크 지연 시간을 최소로 할 수 있음(프로비저닝된 IOPS). EFS는 충분히 빠르지만 EBS만큼의 낮은 디스크 지연시간은 확보할 수 없음. 반면에 분산 파일 저장 시스템이기 때문에, EFS는 EBS에 비해 초당 처리량은 높을 수 있다.
• EFS 볼륨은 전사적 파일 서버, 백업 시스템, 빅 데이터 클러스터, 대규모 병렬 처리(MPP) 시스템, CDN 및 기타 대규모 사용 사례에 적합
• EBS 볼륨은 관계형 및 NoSQL 데이터베이스, ERP 시스템, 메일 서버, 쉐어포인트, 웹 서버, 디렉터리 서버, DNS 서버 또는 미들웨어에 적합 (큰 클러스터에서 실행되지 않는 워크로드로 마운트되는 볼륨이 필요 없음)

EFS Backup 옵션

1. DataSync
   • DataSync는 온프레미스 스토리지와 Amazon EFS 파일 시스템 간의 상시 연결을 유지하여 둘 사이에서 데이터를 쉽게 이동하도록 도움.
   • DataSync는 대량의 데이터를 정기적으로 가져오기 및 내보내기, 일회성 데이터 마이그레이션 또는 데이터 복제 및 복구에 사용할 수 있음.
   • 리전간 전송에도 AWS DataSync를 사용할 수 있음
2. AWS Tranfer Family
   • SFTP, FTPS, FTP를 지원하는 완전관리형 파일 전송 서비스.
   • Amazon EFS 내부 및 외부 파일 전송을 가능하게 함.
   • AWS Transfer Family 엔드포인트는 EFS 파일 시스템과 동일한 리전에 있어야 함 (리전 간 전송 불가)
3. AWS Backup
   • Amazon EFS의 백업 정책 및 예약을 자동화하고 추적함
4. EFS-to-EFS backup
   • EFS 파일의 증분 백업을 자동으로 생성

Reference

• AWS EFS Mount

DynamoDB

특징

• 자동 이중화 : 서버 장애 또는 가용 영역 중단시 내결함성을 제공하기 위해 AWS 리전의 3개 시설에 자동으로 데이터 복제
• SSD기반 NoSQL 서비스
• 테이블 데이터는 json 형식으로 저장됨
• 완전 관리형 NoSQL 데이터베이스 서비스
  • 클러스터링, 백업정책, 성능 상향, 다중리전 지원
• 트랜잭션, JOIN과 같은 작업이 필요하다면 DBMS 사용이 더 적합 (DDB의 단점)
• 규모가 커지더라도 PUT/GET이 항상 10ms 이내, 무제한으로 Scaling 가능.
• Table + Item + Attribute
  • Table : item들의 집합. 리전당 생성할 수 있는 최대 개수 256개
    • 기본키 지정 필수
      • 단순 기본키 : Partition Key (Hash Key) (=, != 연산만 가능)
      • 복합 기본키 : Sort Key (Range Key) (범위연산 및 ~ 연산 가능)
• 테이블 내 항목의 데이터 크기는 400KB를 초과할 수 없다.

인덱스

• 단순 보조 인덱스 기본키 : Hash Key (기본키 이용하여 자동 생성)
• 복합 보조 인덱스 기본키 : Hash Key + Range Key
• Global 보조 인덱스(GSI) : 파티션키와 정렬키가 모두 다름 (모든 파티션에 접근 가능)
  • 생성, 삭제가 자유롭고 쿼리 용량에 제한 없음
• Local 보조 인덱스 (LSI) : 파티션키는 같지만 정렬키가 다름 (특정 파티션에만 접근 가능)
  • 테이블 생성 시에만 생성 가능. 삭제 불가.
  • Hot Key 이슈를 막기 위하여 사용됨
  • 10GB 제한

Scaling

• 전체 데이터를 골고루 분산시키기 위해 Partition Key 사용 (Scaling의 핵심이 Partition Key)
  • DynamoDB는 DB 트래픽이 늘어나면 자동으로 instance를 늘리는데, 그 기준은 파티션키를 hash 값.
  • 한 파티션 키에 해당하는 데이터는 10GB가 넘을 수 없다.
• 로드가 적은 DDB의 테이블 사용시 한 서버로 처리
• 로드가 많아지면 파티션 키의 hash 값으로 두 개의 서버로 쪼개지고, 그래도 부하가 크다면, 계속 쪼개지는 과정 반복.

Partition Key

• Key-Value 저장소 용도일 때는 파티션키를 고려하지 않아도 크게 문제 없음.
• Query 를 사용할 때 Partition Key + Sort Key 조합으로 Key를 설정해야 함
  • DDB의 Query 기능은 Partition Key에 속한 Sort Key에 조건을 걸어 데이터 조회하기 때문
  • Query를 사용하고 싶어도, 특정 Partition Key에만 데이터가 몰려서는 안되기 때문에, 파티션키 정하는 것이 어려운 것임 (Hot Key 이슈)

추가 기능

1. DAX (DynamoDB Accelerator)
   • DDB와 동일한 인터페이스의 in-memory cache 서버.
   • 읽기 볼륨이 많거나 1ms 미만의 읽기 지연시간이 필요할 때 필요
2. Stream + Lambda
   • DDB에 POST/PUT/DELETE 되는 데이터가 생길 때마다 Lambda를 실행할 수 있음
3. Global Table
   • AWS가 지원하는 리전에 자동으로 동기화되는 데이터를 구성할 수 있음
   • 전세게에 DB 분산

백업

1. 온디맨드 백업
   • 온디맨드 백업 생성 시 전체 테이블 데이터가 백업됨
2. 특점 시점으로 복구(PITR)
   • 활성화 시 테이블 삭제하면 백업이 자동으로 생성되며 35일 동안 유지 (무료)

요금 계산

• 모든 아이템을 KB 단위로 환산한 뒤에 소수점 이하를 올림하고 용량단위의 배수로 맞춰서 다시 올림 (1Byte만 사용해도 용량단위로 올림해서 계산)
• 용량 단위
  • WCUs : 1KB
  • RCUs : 4KB, Strictly Consistent Read (Real Time)
  • RCus : 8KB, Eventually Consistent Read (Near Time)
• 온디맨드 프로비저닝에 비해, 읽기 및 쓰기용량을 미리 예약하면 비용을 절감할 수 있다.

Reference

• DynamoDB 사용하기

Amazon Aurora

• MySQL PostgreSQL 오픈소스와 호환
  • MySQL의 5배, PostgreSQL의 3배 쓰루풋
  • 고가용성 보장 (단일 데이터 베이스가 여러 리전에 걸쳐있음)
    • RDS MySQL은 Multi-AZ 활성화 시 Active-Standby 모델
    • RDS Aurora는 Active-Active 모델로 단일 장애점(SPOF) 제거
  • 지역 전체 중단에도 RPO 1초, RTO 1분 미만
• 1/10 비용으로 상용 데이터베이스 수준의 성능 & 가용성 제공
  • 하지만 RDS MySQL에 비해서는 20%~30% 정도 비쌈
• Aurora Serverless
  
  • 데이터베이스를 shutdown 시켜놓았을 때 EC2에 대한 과금 X
  • 자동으로 용량 조절
  • 초당 지불 (최소 1분)
  • 자주 사용하지 않거나, 주기적인 워크로드에 적합
  • HTTP 기반 API 제공

Aurora 장애조치

자동으로 장애조치를 하며, 관리자의 개입없이도 장애조치가 작용된다.

• Aurora는 DB 인스턴스의 CNAME이 정상적인 복제본을 가리키도록 변경하며, 해당 복제본은 승격되어 새로운 기본 복제본으로 지정된다. 이는 30초 이내에 수행됨.
• 현재 AZ를 사용할 수 없는 경우, Aurora는 다른 AZ에서 DB 인스턴스를 자동으로 다시 생성함.
• 복제본이 없는 경우, 원래 인스턴스와 동일한 AZ에 새 DB 인스턴스를 생성 시도함.
• 여러 리전에 걸친 장애 복구는 수동 프로세스이며, 보조 리전을 승격시키는 조치가 필요함

Aurora Multi-Masters

기존 aurora는 클러스터 내 읽기/쓰기가 가능한 마스터 노드는 1개만 구성하였고, 최대 15개의 읽기 복제본만 구성(읽기 성능만 확장)할 수 있었다.

Multi-Masters의 출시로 이제는 읽기/쓰기가 모두 가능한 마스터 노드를 2개 이상 구성할 수 있게 되어, 읽기/쓰기 성능 모두 확장 가능하게 되었다. (2019년에 정식버전으로 병합)

• 마스터 노드 1개가 장애가 발생하더라도 다른 마스터노드가 쓰기 작업을 할 수 있게 되었다.
• 샤딩 없이 쓰기 성능을 확장 가능
  • 샤딩 : 최대 성능의 데이터베이스 타입을 사용 중인데 성능이 부족하게 된다면, 같은 스키마를 가진 데이터를 다수의 db에 분산하여 저장하는 방법

따라서 고가용성과 성능을 보장할 수 있게됨

Amazon Pinpoint

• 이메일, 앱 푸시알림, SMS 문자 및 음성 메시지를 보낼 수 있는 서비스
• 마케팅 라이프사이클 관리
  • 홍보 및 거래 메시지(구매 영수증) 전달
• 고객 참여 및 활동(구매 등) 활동, 선호도 등 사용자 행동을 확인할 수 있는 분석 제공
  • 외부에서 분석 및 저장하려면 Pinpoint 데이터를 Amazon Kinesis로 스트리밍 필요
    • 콘솔에서 [설정]-[이벤트스트림]에서 Kinesis Data Streams 및 Firehose로 스트리밍 활성화 가능하며 cli 및 sdk도 지원 중
• 콘텐츠 및 채널, 참여 시기에 관한 예측을 생성해줌
• 서울 리전에는 아직 SMS 기능은 추가되지 않음 (이메일, 앱 푸시알림만 가능)
  • 국내 발신 번호를 사용하고 싶다면 커스텀 채널을 통해 서드 파티 솔루션을 도입하는 방향 고려

Email

• 보내기 전에 송신자 및 수신자 이메일의 자격 증명 과정이 필수적
  • email verification 과정 이후 활성화 가능
  • 24시간 동안 최대 200개의 메시지, 초당 최대 1개의 메시지를 보낼 수 있으며 할당량 증가 요청으로 제한 풀 수 있음
• 와일드 카드 로컬 부분 표기법 지원 (ex> fred@domainfred+foo@domain)
• Pinpoint 수신자가 열었거나 클릭한 이메일을 자동으로 추적
  • AWS Server에서 호스팅되는 이미지를 이메일 끝에 추가
  • 이메일의 모든 링크를 AWS에서 호스팅하는 도메인을 참조하는 링크로 구성함
    • AWS 호스팅 도메인 전송 이후 목적 위치로 리디렉션됨
• SMS 문자는 SNS와 거의 동일

푸시알림

• 자격 증명 필요 (APN, FCM 등)
• 기본적으로 초당 25,000개의 메시지 발송 가능하면 할당량 증가 요청 가능

세그먼트

• 운영체제 및 모바일 유형과 같은 데이터 기반으로 동적 세그먼트 정의 가능
• 아래와 같은 csv 및 json 파일을 가져와서 세그먼트 생성 가능 (정적) 
• ChannelType,Address,User.UserId,User.UserAttributes.FirstName,User.UserAttributes.LastName,User.UserAttributes.age,User.UserAttributes.isActive EMAIL,Raymond+pinpoint1@emaildomain.com,userid1,Raymond,Phillips,35,TRUE EMAIL,Sue+pinpoint2@emaildomain.com,userid2,Sue,Sherman,31,FALSE EMAIL,Mark+pinpoint3@emaildomain.com,userid3,Mark,Price,28,
• 세그먼트 가져오기 외에 위 csv 예시(이전에 업로드한 사용자의 열 참조)의 isActive 속성을 활용하여 활성/비활성 사용자에 대해 세그먼트 분류 가능

메시징 캠페인

• 세그먼트 단위별로 지정해서 메시지를 보낼 수 있음
• 시점 선택 가능
  • 특정 시간
    • 즉시, 한번, 매시간, 매일, 매주, 매월
  • 이벤트 발생 시
  • 고객이 불편한 시간에 메시지 보낼 수 없도록 전송 중단 시간 설정 가능
• 메시지 템플릿 사용 가능
  • 개인화된 콘텐츠 명시 가능 (ex> Hi {{User.UserAttributes.FirstName}}, congratulations on your new {{User.UserAttributes.Activity}} record of {{User.UserAttributes.PersonalRecord}}!)
  • 개인화된 콘텐츠 추가
  • 버저닝 가능

여정(Journey)

• 특정 고객 세그먼트로부터 시작해서 메시지를 보내거나 행동에 따라 그룹핑을하는 activity를 추가하는 여정을 생성할 수 있음
• 여정의 시작 및 종료 시간을 지정할 수 있음
• multivalidate split 분기로 이메일 클릭/ 이메일 오픈 / 수신 거부 등의 분기 처리 가능
• 비활성화 유저 독촉 : Yes/no split을 통해 특정 로직이 지나간 후에 기존 세그먼트의 유저가 그대로 남아 있는지 확인 가능 (동일 세그먼트로 조건 평가를 추가하면 됨)
• 시작 이후 각 분기별 지표 확인 가능

Pinpoint vs SES

• 많은 수의 트랜잭션 이메일을 보내는 경우 SES가 유리

Reference

• Pinpoint Workshop