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 대체)

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 : 스택 삭제

Amazon SNS

• Pub Sub(출판-구독) 모델 : 게시자가 SNS로 메시지를 보낼 때 구독자에게 Push됨 (Push 방식)
• 개별 메시지를 보내거나 대량의 메시지를 다수의 수신자에게 보낼 때 사용
• 이메일, SMS, HTTP 엔드포인트 및 SQS와 같은 엔드포인트를 지원함
• 메시지를 가져오는 동시에 메시지 삭제. 사용 가능한 수신자가 없을 경우 메시지 손실 (메시지 전달이 보장되지 않음)
• 수신자마다 다른 방식으로 메시지 처리 가능

Amazon SQS

• 분산 큐잉 시스템 : 메시지가 수신자에게 푸시되지 않고, 수신자가 메세지를 수신하기 위해 SQS를 Polling 해야함 (Pull 방식)
• 동시에 여러 수신자가 메시지를 받는 것이 아님. SNS와는 달리 폴링 방식으로, SQS에서의 메시지 전달에는 약간의 latency 존재
• 애플리케이션 분리 및 병렬 비동기 처리에 사용됨
  • 트래픽이 많이 몰리는 상황에서, 누락되는 요청을 안정적으로 받아내기 위해 특정 서비스 앞에 붙여 사용
• 수신자가 available하지 않을 경우 메시지가 최대 14일(기본값 : 4일) 동안 SQS내에 저장 (메시지 전달이 보장)
• 모든 수신자가 동일한 방식으로 메시지를 처리해야 함
• 표준 대기열
  • API 작업별 초당 무제한 호출 수 지원
  • 각 메시지 최소 1회 전달 보장
    • 2회 이상 동일한 메시지가 전달될 수도 있음.
    • 가용성을 위해 메시지를 여러 서버에 저장하고, 서버가 사용될 수 없는 경우 메시지가 삭제되지 않고, 다시 메시지를 수신할 수 있도록 설계되어 있기 때문
  • 정확한 순서 보장 X
• FIFO 대기열
  • API 작업별 초당 최대 3000개 트랜잭션 지원(초당 300번의 처리 * Batch 10회 처리)
  • 모든 메시지를 정확히 1회 처리 보장
  • 정확한 순서 보장
• DLQ (데드레터큐) : 메시지 전송 실패를 처리할 때 사용. 해당 대기열을 따로 생성해야 사용 가능

SNS with SQS

SNS 단일 사용 시 문제점

1. 메시지를 받는 수신자가 연결을 막았을 수 있음
2. 대량의 메시지로 엔드포인트가 죽을 수도 있음
3. http 엔드포인트 혹은 SMS로 보낼 때 메시지 전송 실패로 메시지가 도착하지 못하고 모두 삭제될 수 있음

• SNS와 SQS를 결합하면 원하는 속도로 메시지를 받을 수 있음!
• 클라이언트가 오프라인 상태가 되거나, 네트워크 및 호스트 장애에도 메시징에 문제가 없음 (메시지 전송을 보장)

Amazon MQ

• 온프레미스 환경에서 사용하던 코드를 클라우드로 그대로 옮기고 싶거나, MQTT, STOMP 등 다양한 프로토콜 지원이 필요한 경우

Route 53

DNS 서비스에서 더 발전된 형태의 GSLB 형태의 서비스이다.
GSLB는 Global Server Load Balancing의 약자로서, 지역에 상관없이 부하를 줄여주는 기능을 제공한다.
주기적으로 연결된 서버들에 헬스 체크가 이루어지기 때문에, 기존 DNS 방식과는 달리 다운된 서버로 사용자가 연결되지 않게 한다.

DNS

• naver.com과 같은 문자열 주소를 192.168.0.1과 같은 IPv4로의 주소 변환이 필요하고, 이를 DNS 서비스라 부름
• DNS서버에는 도메인 주소와 IP주소가 서로 맵핑된다.
• 하나의 행을 레코드라고 부르며, 저장되는 타입에 따라, A 레코드와 CNAME으로 구분

Record

• A 레코드 : 도메인 주소와 서버의 IP 주소를직접 맵핑 (naver.com - 192.168.0.1)
  • 한 번의 요청으로 바로 IP 주소를 알 수 있음
  • IP 주소가 자주 바뀌는 경우 번거로움
• CNAME : 도메인 주소를 또 다른 도메인 주소로 맵핑 (post.blog.co.kr - postapi.blog.co.kr)
  • IP 주소가 자주 바뀌어도 유연하게 대응 가능
  • 실제 IP 주소를 얻을 때까지 여러 번 DNS 정보를 요청하며, 성능 저하의 가능성 존재

라우팅 정책

아래와 같은 정책 등을 통해 SLA 100%의 서비스를 제공하는 것이 Route 53이다.

1. 지연시간 기반 : 각 리전에 대한 latency 정보를 가지고 있어서, 고객 기준으로 가장 latency가 작은 서버와 연결
2. 가중치 기반 : 각 서버로 가는 트래픽의 비율을 조정하여, 특정 서버로 연결될 확률을 조정
3. 지역 기반 : 유저의 지역 정보를 기반으로 가까운 지역의 서버로 연결

Route 53 이 정상적인 레코드를 선택하는 방식

1. 라우팅 정책과 레코드에 대해 지정한 값을 기반으로 선택
2. Route 53이 레코드가 정상이라 확인한 경우
   • 상태 확인이 연결된 비별칭 레코드
   • Evaluate Target Health (대상 상태 평가)가 예로 설정된 별칭 레코드
3. 레코드가 정상인 경우 IP주소와 같이 해당되는 값으로 쿼리에 응답 / 레코드가 비정상인 경우 다른 레코드 선택하고 정상 레코드를 찾을 때까지 반복