Day 1: AWS Developer Bootcamp for Startup

Singsoong·2024년 6월 18일

AWS

목록 보기

16/18

AWS Summit을 참석한 이후에 AWS 세일즈와 연락이 닿아 startup 개발자를 위한 AWS Developer bootcamp 행사를 초청 받았고, 사내 프론트엔드 AWS 서비스들을 관리하고 있었던 나는, 참석하고 싶다고 응답했다.

6월 13일, 14일 양일간 교육이 진행된다고 했으며 AWS 주요 서비스들을 둘러보고 실습을 경험할 수 있는 환경을 제공해준다고 했다. 제일 관심있었던 CI/CD 주제와 함께 서버리스, Observability, laC, 그리고 AWS의 꿀팁들을 알려준다고 하여 기대를 잔뜩 안고 교육에 임했다.

(교육 받는 환경이 매우 좋았다.....)

아래 내용들은 교육을 듣고 리마인드할 부분을 메모한 내용이다.

10:00 - 11:50: 개발자를 위한 AWS 핵심 서비스 활용하기

AWS에서 워크로드를 운영하기 위해서 필수로 알아야 하는 핵심 서비스의 기본 개념을 살펴봅니다. 그리고 각 서비스를 100% 활용하기 위해 개발자가 반드시 챙겨야하는 여러 가지 팁을 소개합니다.

AWS 개발자를 위한 AWS 핵심 서비스 활용하기

VPC

VPC CIDR는 한번 생성하면 수정 불가능, CIDR 대역의 수정이 불가능하다. (추가는 가능)

Subnet

퍼블릿, 프라이빗 서브넷을 구분짓는건 인터넷 게이트웨이를 통해 트래픽을 주고 받을 수 있는지에 따라 구분짓는다.

NAT Gateway

퍼블릭 서브넷에 배치해서 인터넷으로의 아웃바운드 연결을 가능하게 함
인바운드 연결 하지 못함
외부의 인터넷에서 내부의 워크로드로 들어오진 못하지만, 내부의 워크로드에서 인터넷 리소스를 가져올 순 있음
인터넷 게이트웨이와 같이 라우팅 테이블을 설정해야함
NAT gateway는 직접 구축하는것보다 비싸지만, 완전 관리형으로 잘 만들어져있음

VPC Endpoint

AWS VPC (Virtual Private Cloud) Endpoint는 VPC 내의 리소스가 인터넷을 경유하지 않고 AWS 서비스와 통신할 수 있도록 해주는 네트워크 구성 요소이다. 예를 들어, 내부 리소스가 S3에 데이터를 업로드할 때 인터넷을 거치지 않고 직접 S3에 연결할 수 있어 비용 절감 및 보안 향상에 기여한다.

종류: Gateway Endpoint와 Interface Endpoint
Gateway Endpoint
Gateway Endpoint는 S3와 DynamoDB에 대한 VPC Endpoint로, 다음과 같은 특징을 갖는다.

비용: 무료
지원 서비스: Amazon S3, DynamoDB
리전 접근: 같은 리전에 있는 S3와 DynamoDB에만 접근 가능
온프레미스 접근: 불가능
네트워크: Amazon S3의 공개 IP 주소 사용
사용 사례: VPC 내부 리소스가 S3에 데이터를 업로드할 때, NAT Gateway를 거치지 않고 직접 업로드 가능

기존 방식: 
프라이빗 서브넷의 인스턴스가 S3에 데이터를 업로드하려면 NAT Gateway를 통해야 하고, 
이는 비용이 발생하며 보안 위험이 존재함

Gateway Endpoint 사용 시:
인스턴스가 NAT Gateway 없이 직접 S3와 통신 가능, 비용 절감 및 보안 강화

Interface Endpoint
Interface Endpoint는 PrivateLink 기반으로 AWS 서비스의 API와 통신할 수 있는 VPC Endpoint로, 다음과 같은 특징을 갖는다.

비용: PrivateLink 비용이 발생
지원 서비스: API Gateway, CloudWatch, 기타 AWS 서비스
리전 접근: 다른 리전의 서비스에도 접근 가능
온프레미스 접근: 가능
네트워크: VPC의 프라이빗 IP 주소 사용
사용 사례: VPC 내부 리소스가 CloudWatch 로그에 접근하거나, API Gateway와 통신할 때 사용. 또한, SaaS(Software as a Service) 공급업체에 데이터를 보낼 때도 사용


기존 방식: 
온프레미스에서 AWS API Gateway로 데이터를 보내려면 퍼블릭 인터넷을 통해야 함

Interface Endpoint 사용 시: 
온프레미스에서 PrivateLink를 통해 안전하게 AWS API Gateway로 데이터 전송 가능

SaaS 업체(데이터 독, 몽고디비와 같은)와의 통신에서의 꿀팁

미국 리전에 VPC 생성
VPC 피어링: 데이터를 전송할 AWS 리전에서 생성한 VPC와 피어링 연결
PrivateLink 설정: 피어링된 VPC에서 SaaS 업체의 PrivateLink로 데이터 전송
이 과정에서 인터넷을 경유하지 않기 때문에 데이터 전송의 보안성이 향상되고, 아웃바운드로 데이터를 전송하지 않기 때문에 비용적인 측면에서도 30%정도 절약한다고 한다.

데이터 전송 요금 구조 이해

아웃바운드 요금은 무조건 발생
외부에서 S3 업로드하는것은 무료, S3에서 다운로드 하는것은 비용 부과
Endpoint는 무조건 쓰자

동일 리전 내에서 AZ간 전송 비용

Cross AZ 하는 트래픽이 많으면 비용 증가
보통 ALB를 앞단에 붙히기 때문에 AZ간 트래픽을 주고받는 경우는 거의 없음
EKS, 마이크로 아키텍쳐에서 AZ간 트래픽을 주고 받는 경우들이 생김
ALB는 Cross AZ 비용이 들지 않지만, NLB는 Cross AZ 비용이 들음
(NLB는 기본적으로 Cross AZ 옵션 디폴트가 꺼져있음)

오토스케일링

오토스케일링 시작이 느리다고 생각한다면 warm pool을 사용하자

인스턴스를 절전 모드로 띄워놓는 것으로 생각하면 된다.
초기화가 오래걸리는 인스턴스가 있을 때 사용하면 좋다.

Saving Plans

RI(예약형 인스턴스)보다 유연함을 제공
약정 구조에 계약을 변경해야 하는 경우 -> 약정 중간에 리전, 인스턴스 패밀리, 사이즈 등을 바꿀 수도 있음

Spot Instance

무작정 인스턴스를 회수해가지 않고 2분 전에 알림 줌
컨테이너 같은 것을 사용할 때 스팟 인스턴스를 많이 쓰는 편

S3

S3 Glacier Deep Archive에 옮긴다고 무조건 이득이 아님. 작은 사이즈의 많은 파일을 옮길 때 비용이 많이들음.
(예를 들면, 작은 사이즈의 파일인 128kb는 옮기고 나서 5달이 지났을 때 이득을 볼 수 있다 -> 옮기는 데 각각의 객체마다 비용이 부과)
S3는 prefix 기반으로 오토스케일링 됨 (TPS 수준이 결정)
-> S3 prefix 디자인을 잘 생각해서 하자

RDS

갑자기 쿼리가 늘어날 때 RDS Proxy를 앞단에 붙혀서 커넥션 풀을 만들자.
그래도 안된다면, Aurora를 오토스케일링 할 수 있다.

1단계: 스케일 업
2단계: 커넥션 풀을 조절할 수 있는 RDS Proxy
3단계: Aurora Autoscaling

13:30 - 17:00: Serverless

AWS의 서버리스 서비스를 사용하면 개발 및 운영 생산성을 높일 수 있습니다. 이 시간에는 AWS의 서버리스 서비스들에 알아보고, 어떻게 활용할 수 있는지 운영적인 측면도 포함해서 살펴봅니다. AWS Lambda, API Gateway, SQS, SNS, EventBridge, StepFunctions를 다룹니다. 또한 서버리스 개발 프레임워크인 SAM 에 대해서도 살펴봅니다.

Serverless

서버리스란

인프라를 프로비저닝, 관리할 필요 없음
오토스케일링 자동으로
사용한만큼 과금 -> 트래픽이 항상 많지 않을 경우 서버리스가 유용
고가용성, 보안 컨트롤할 필요 없음

AWS Lambda

서버를 프로비저닝하지않고 항상 실행시킬 수 있음
코드만 올려놓고 실행하면 바로 실행할 수 있음
여러 언어로 함수를 작성할 수 있음
여러 AWS 서비스를 통합하여 활용할 수 있음
람다 함수 실행속도를 높이고 싶으면 메모리 사이즈를 올리면 됨 (메모리 사이즈에 비례하여 CPU 성능이 올라감)
람다 함수 타임아웃을 15분으로 설정했다면, API Gateway 타임아웃을 30초로 설정할 수도 있기 때문에 두 리소스의 타임아웃을 잘 확인해서 타임아웃을 결정
람다 함수 호출을 하면 람다 전용 VPC에서 호출하게 됨 (우리 VPC가 아님)
-> 우리 VPC 안에 있는 RDS를 호출하게 된다면? 람다에 VPC 구성을 해서 사용할 것

콜드 스타트
서비스 요청이 들어옴 -> 람다 실행환경이 있는지 확인
-> COLD Start: 환경이 없으면, 컴퓨팅 리소스 할당 -> 람다 함수 코드 다운 -> 시작 -> INIT 코드 실행 -> 핸들러 코드 실행
-> WARM Start: 환경이 있으면, 핸들러 코드 바로 실행

핸들러 바깥에 초기화 하는 소스 (디비 초기화 등)를 선언하면 더 효율적으로 -> 콜드 스타트를 잘 다룰 수 있음
라이브러리를 사용할 때 라이브러리 전체를 import 하지말고 사용하는 부분만

// const AWS = require('aws-sdk;)
const DynamoDb = require('aws-sdk/dynamoDB)

콜드 스타트를 핸들링 하는 법

INIT 단계에서 필요한 클래스 로딩
패키지 사이즈는 작게
Memory(=CPU) 크기 선택
람다 언어
ProvisionedConcurrency

Lambda Concurrency: 람다 함수에서 동시에 처리하는 리퀘스트 수
Reserved Concurrency: 해당 함수에서 사용할 수 있는 Concurrency 풀 확보 (중요 함수에 대해 이걸 사용하면 됨, 확실하게 실행 보장)
Provisioned Concurrency: 요청이 들어왔을 때 콜드스타트가 발생하지 않음 -> 비용 발생

이렇게 이론 수업을 듣고 실습을 진행했다.
실습을 진행하기 위해 각 교육생마다 실습용 계정을 발급해주었다.
실습용 계정은 몇시간 밖에 사용하지 못하지만, 편하게 사용할 수 있어서 좋았다.

실습은 배달 서비스 만들기 이다. 먼저 브라우저만으로 코드를 작성할 수 있는 Cloud 9 환경을 구축했다.

Cloud 9 환경을 구축하면서 AWS Q Developer 세팅도 같이 해주었다. AWS Q Developer를 사용하면 GPT 처럼 대화는 물론, 코드를 작성하면서 상황에 맞는 코드를 추천해준다.

먼저, 유저가 URL을 호출하면 API Gateway를 통해 정의한 주문 람다 함수를 호출한다.

API Gateway를 구성해주었다.

API Gateway의 통합 연결에서 호출할 람다 함수(주문하기)를 작성했다.

람다 함수를 테스트 하기 위한 코드도 작성하고, 테스트도 해보았다.

람다 함수 배포까지 완료

아까 정의해두었던 post /order에 람다 함수를 등록했다.

/order API를 호출했더니 잘나왔다.

람다 함수에서 CloudWatch에 로깅하는 코드도 적어두었는데, 로깅이 잘되는지도 확인했다.

다음으로 주문을 많이 한다고 가정하고 트래픽을 안정적으로 처리하기 위해 SQS를 중간에 넣었다.

SQS를 먼저 만들고,

post /order를 SQS에 연결하였다.

람다 함수를 SQS에 연결하였다. 람다 함수가 SQS에 접근할 수 있도록 권한을 추가했다.

SQS를 트리거로 추가했다.

주문을 비동기로 처리하게 변경했었는데, 만약 주문을 처리하다가 에러가 발생했을 때 메세지가 유실될 수 있다. 이 때 DLQ(Dead Letter Queue)를 만들어서 에러가 발생한 메시지를 DLQ로 보내어 메시지 유실을 막고 에러가 발생한 주문에 대해 사후 처리를 할 수 있게 구성할 수 있다.

기존 SQS에 DLQ를 등록했다.

최대 수신수를 1로 설정했다. 최대 수신수는 이 큐에서 해당 메시지를 최대 몇번 받을지를 설정한다. 이 값이 1이라면 에러가 발생했을 때 여기서 설정한 DLQ로 메세지를 보내게 된다.
만약 이 값이 2라고 한다면, 다시 한번 주문 처리를 위한 Lambda를 트리거한다. 만약 이번에도 다시 에러가 발생했다면 DLQ로 보낸다.

/order 람다 함수에 에러 코드를 작성했다.