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

https://medium.com/@nuatmochoi

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

SAM template은 CloudFormation 위에서 작동됨

SAM Commands

1. sam build : Lambda 코드를 build하고 Deployment artifact를 만듦. dependancy 설치.
   • sam build --use-container : 도커 컨테이너 안에서 패키지 인스톨 및 빌드
2. sam package : 코드와 dependency가 포함된 코드를 zip 압축하여 S3에 업로드. SAM template에서 local을 s3 버킷(CodeUri)으로 바꿈으로써 최종 SAM template 생성
3. sam deploy : SAM template으로 스택을 만들고, AWS resource들이 프로비저닝됨

sam local (로컬 환경에서 테스트)

1. sam local generate-event
2. sam local invoke
3. sam local start-api
4. sam local lambda

CloudFormation

1. Parameters : 동적인 파라미터 및 AWS SSM parameter store에 저장한 값을 가져올 수 있음
2. Mappings: key값에 따라 미리 value를 정해놓고 사용 가능
3. Conditions : 조건을 만족할 때만 resource 생성하도록
4. Nested stacks : 공통 리소스를 정의한 template을 재사용할 수 있음 (스택 위에 스택이 쌓이도록)