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을 재사용할 수 있음 (스택 위에 스택이 쌓이도록)

CloudEndure

• rehosting 솔루션 (lift & shift)
• Source 서버를 aws 계정에 지속적 복제, 마이그레이션 준비가 되면 서버를 자동으로 변환하고 실행 (전환 시간 단축)
• Agent 기반 솔루션
• 지원 버전

기능

1. 재해 복구
   • CloudEndure Disaster Recovery
     • 스냅샷 기반 솔루션이 아니라 비동기적 복제이므로 초 단위의 RPO(복구 지점 목표)를 실현
     • 자동화된 시스템 변환 및 오케스트레이션을 통해 몇 분 단위의 RTO(복구 시간 목표)를 구현
     • 랜섬웨어로부터의 보호 : 손상되지 않은 서버 버전을 대상 aws 리전에서 시작
     • 온프레미스 to Cloud, 온프레미스 to 온프레미스(Outposts), 리전 간 재해 복구, 클라우드 간 재해 복구를 모두 지원
2. 데이터 무결성 보장
3. 중단없는 workflow
   • 백그라운드 실행을 통해 시스템 성능에 영향을 주지 않고, 데이터의 지속 흐름을 보장
   • 스냅샷, 디스크에 데이터 Write를 하지 않고도 메모리상에서 소스 서버를 복제
4. 보안
   • AES 256 bit를 이용해 전송 중 데이터를 암호화
   • hand-shake, 모니터링을 위해 TCP port 443에 대한 송신 액세스 필요
   • 복제 서버와 통신하기 위해 TCP port 1500에 대한 송신 액세스 필요
   • 에이전트가 복제 서버와 통신하는 것에서 Public 통신이 불가능하도록 하는 요구사항이 필요할 때, Direct Connec나 VPN으로 연결할 수 있는 옵션을 지원. 또한 이 경우에 proxy 서버를 통해서 복제 서버와 통신하도록 하는 옵션 또한 제공.

절차

1. Source 시스템에 CloudEndure Agent 설치
   • CloudEndure Agent는 CloudEndure 콘솔에 연결한 다음, destination이 되는 aws region으로 api를 호출하여, 고객 계정에 staging 영역 생성
   • staging 영역은 경량 EC2 (복제 서버 - default: t3.small)와 저렴한 EBS 볼륨으로 구성
   • 복제 서버는 CloudEndure Agent로부터 데이터를 수신하여 EBS 볼륨에 Write 수행
     • Public IP address가 자동 할당됨
   • 리눅스 machine
     1. agent 설치

         wget -O ./installer_linux.py https://console.cloudendure.com/installer_linux.py

     2. installer 실행 (Token 값은 Machine Actions -> Add Machine에서 확인 가능)

         sudo python ./installer_linux.py -t THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1-THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1 --no-prompt

   • 윈도우 machine
     1. agent 설치

         https://console.cloudendure.com/installer_win.exe

     2. installer 실행

         installer_win.exe -t THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1-THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1 --no-prompt

2. 모든 source 디스크가 staging 영역으로 복제된 후, agent는 source의 변경 사항을 추적하고 복제
   • 1초 미만의 지연시간으로 연속 비동기 블록 수준 데이터 복제(CDP)를 수행
   • 인스턴스 기준으로 마이그레이션이 진행되기 떄문에, 여러 개의 볼륨이 한 인스턴스에 붙어 있어도 마이그레이션이 가능
   • 중간에 볼륨 사이즈가 늘어나면, CloudEndure은 Rescanning을 통해 늘어난 볼륨 사이즈를 인식하는 과정을 수행
     • 이러한 추가된 디스크에 대한 자동 감지는 default 옵션이며, 요구사항에 따라 자동 디스크 감지가 필요없다면 agent를 설치 커맨드 실행시에 --force-volumes 플래그나 -no-auto-disk-detection 플래그를 적용하여 비활성화
3. 고객이 CloudEndure의 [Setup & Info] - [Replication settings] 에서 Source와 Target(destination)을 지정할 수 있음
   • 온프레미스 Source의 경우 Other Infrastructure을 지정
4. test 및 cutover 진행하면 대상 리전으로 마이그레이션 진행됨

CloudEndure 제한사항

• Agent 설치 이후에 복제가 완료되면, 지속적으로 변경 사항을 추적한다. 이 변경 사항이 실제로 서버에 반영되는 것은 Test나 Cutover를 했을 때 반영된다.
• Blueprint에서 EIP 지정을 하지 않으면, 새롭게 test 요청을 했을 때 IP 주소가 바뀐다.
• CloudEndure 복제 속도는 다음과 같은 요소에 의해 영향을 받는다.
  • Source에서 복제 서버까지의 up-link 속도 및 대역폭
    • iperf3로 테스트 가능. 테스팅은 replication 서버가 있는 서브넷에 linux 인스턴스를 추가해서 테스팅한다.
    • sudo apt-get install iperf3 -y로 설치한 뒤, 서버 인스턴스에서 iperf3 -s, 클라이언트 인스턴스에서 iperf3 -c [IP 주소]를 실행하여 확인 가능
  • 전체 디스크 스토리지
  • 복제 중 디스크 변경
    • 쓰기가 많은 서버에서 복제 데이터의 전송을 따라잡지 못할 수 있다.
    • 따라서 DB서버 migration은 SMS나 DMS 권장
  • 원본 서버 I/O 성능
• 네트워크 대역폭 조절(스로틀링) 옵션을 통해 기존 시스템의 트래픽 압박을 줄일 수 있으나, Source 서버의 쓰기 작업량(최소 대역폭) 보다 높게 설정해야 한다. 그렇지 않으면 복제 작업이 완료되지 않음. 이 부분이 사전에 예측이 어렵기 때문에, 사전 test 진행을 통해 어느 정도로 제한할 것인지 결정해야 함.

vs AWS Server Migration Service (SMS)

Reference

• CloudEndure Migration
• CloudEndure Disaster Recovery
• CloudEndure vs AWS SMS

AWS Systems Manager (SSM)

SSM 서비스 내 관리형 인스턴스에 EC2 인스턴스가 포함되면 다음과 같은 작업이 가능 (AmazonSSMManagedInstanceCore 정책을 연결함으로써 쉽게 관리형 인스턴스로 등록 가능 - 기존에 연결하지 않고 나중에 추가되었다면 SSM Agent를 재시작해주어야 함)

1. Session Manager
   • EC2에 pem key 없이 SSH 접속할 수 있도록 해줌
   • Bastion Host를 통하여 AWS VPC의 Private Subnet에 접근하는 방법도 있지만, 이는 Bastion Host 인스턴스 생성 + X.509(RSA) Key Pair 관리 + 22번 (SSH)포트 허용을 위한 보안 그룹 생성을 해야하는 불편함이 있다.
   • SSM는 HTTPS 프로토콜을 사용하며, 인증에 AWS Credentials을 사용
2. Run Commnad
   • 사전 정의된 명령을 작업하도록 시킴
3. Patch Manager
   • 인스턴스의 패치 상태를 일일이 확인하지 않고
   • 주기적으로 패치 상태를 확인하고 패치를 적용해주는 것을 Run Command에 의해 실행됨
   • 패치 매니저를 사용하려면 AmazonSSMPatchAssociation 정책을 추가로 연결해주어야 함

AmazonSSMManagedInstanceCore 정책 연결 이후, 다음 커맨드로 EC2 인스턴스에 연결 가능

aws ssm start-session --target <EC2 인스턴스 ID>

Reference

• AWS 관리형 인스턴스를 사용해야만 하는 이유 - OpsNow Tech Blog
• AWS SSM으로 EC2 인스턴스에 접근하기 (SSH 대체)

엘라스틱서치

• 엘라스틱서치는 검색 엔진인 Apache Lucene으로 구현한 RESTful API 기반의 검색 엔진
• 엘라스틱서치 내에 저장된 데이터를 Index라고 부르며, 각 인덱스는 한 개 이상의 샤드로 구성되어 있음
• 샤드는 Lucene 인덱스를 뜻하며, Lucene 인덱스는 엘라스틱서치 클러스터 내에서 인덱싱 및 데이터 조회를 위한 독립적인 검색엔진이다.

• 데이터를 샤드에 입력할 때, 엘라스틱서치는 주기적으로 디스크에 immuatable한 Lucene segment 형태로 저장하며, 이 작업 이후에 조회가 가능.
  • 이 작업을 리프레쉬(Refresh)라고 부름
  • 샤드는 한 개 이상의 segment로 구성
    
• segment 개수가 많아지면, 주기적으로 더 큰 segment로 병합된다. (Merge)
  • 모든 segment는 immutable하기 때문에, 병합되는 segment가 삭제되기 이전에, 새로운 segment를 생성.
  • 따라서 디스크 사용량에 변화가 생김. 병합 작업은 디스크 I/O 등 리소스에 민감하다.

단점

• 분산처리를 통해 실시간으로 처리하는 것으로 보이지만, 내부적으로 commit, flush 등의 작업을 거치므로 실시간은 아니다.
• 트랜잭션, Rollback을 지원하지 않음 (클러스터의 성능을 위해)
• 데이터의 업데이트를 지원하지 않음. 업데이트 명령이 오면 기존 문서를 삭제하고 새로운 문서 사용
  • 대신에 Immutable하다는 장점이 있다.
  • Segment가 Immutable한 이유는 캐싱 때문이다. Lucene은 읽기 속도를 높이기 위해 OS의 파일시스템 캐싱에 의존하고 있음. 빠른 액세스를 위해 hot segment를 메모리에 상주하게 유지시키는 식으로 작동한다. 참고

Reference

• https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

CDK(Cloud Development Kit)란 terraform, CloudFormation과 같은 Iac(Infrastructure as Code) 서비스로, YAML 문법이 아닌 typescript나 python 등 프로그래밍 언어로 IaC를 가능하게 해주는 도구이다.

AWS CDK 커맨드

1. cdk synth : AWS CDK 애플리케이션을 CloudFormation 템플릿으로 컴파일

2. cdk bootstrap : AWS 환경에 CDK Toolkit을 위한 스택을 배포 (처음 CDK 스택을 deploy한다면 필요한 사전 작업)

   • but no credentials have been configured 에러가 뜬다면, aws configure을 통해 access key ID, Secret access key 및 region을 설정해주는 작업이 필요하다.

   • 구성 확인

     • vi ~/.aws/credential

       [default]
       region = us-east-1
       aws_access_key_id = *****
       aws_secret_access_key = *****
       [project1]
       aws_access_key_id = *****
       aws_secret_access_key = *****

     • vi ~/.aws/config

       [default]
       region = us-east-1
       output=json
       [profile project1]
       region = us-east-1
       output = text

   • 형식 :cdk bootstrap --profile [switched_account]

       Ex> cdk bootstrap --profile project1

3. cdk deploy : CloudFormation을 통해 프로덕션에 AWS CDK 애플리케이션을 배포

   • 형식 : cdk deploy [stack_name] --profile [switched_account]

   • stack_name의 유무에 따라 달라짐. 빈칸이면 해당 디렉토리의 모든 stack을 deploy. 적게 된다면 특정 stack만을 deploy

       Ex> cdk deploy --profile project1

4. cdk destroy : 스택 삭제