AWS Certified Solutions Architect Associate - C03을 준비하며 작성한 글입니다.

01. 서버리스 소개

서버리스란?

• Serverless ≠ 서버가 없다.
• 관리자가 서버를 관리할 필요가 없는 새로운 체계
• “코드(함수)를 배치(deploy)한다.”
• 최초의 서버리스 == FaaS (Function as a Service)
• 서버리스는 AWS Lambda를 시작으로, 현재는 원격 관리되는 모든 것을 포함합니다. (데이터베이스, 메시지, 스토리지 등)
• 서버리스는 서버가 보이지 않거나 서버를 프로비저닝하지 않는 것

AWS에서의 서버리스

• AWS Lambda
• DynamoDB
• AWS Cognito
• AWS API Gateway
• Amazon S3
• AWS SNS & SQS
• AWS Kinesis Data Firehose
• Aurora Serverless
• Step Functions
• Fargate

02. Lambda 개요

AWS Lambda를 사용하는 이유

• EC2
  • 클라우드의 가상 서버
  • 프로비저닝 필요 → 메모리와 CPU 크기가 제한됩니다.
  • 지속적인 실행(Continuously Running)
    • 최적화를 하려면 효율적으로 시작하고 중단해야 합니다.
  • 스케일링: 서버를 추가하고 제거하는 작업
• Lambda
  • 가상의 함수 → 관리할 서버가 없습니다.
  • 제한 시간이 있어 실행 시간이 짧습니다. (최대 15분)
  • 온디맨드 실행(Run on-demand)
    • 호출을 받아야 실행되며 함수가 실행되는 동안만 비용이 청구됩니다.
  • 스케일링 자동화

AWS Lambda의 장점

• 쉬운 가격 책정
  • Lambda가 수신하는 요청의 횟수에 따른 과금 (호출 횟수와 컴퓨팅 시간)
• 다양한 AWS 서비스와 연동
• 여러가지 프로그래밍 언어 지원
• 쉬운 모니터링 with AWS CloudWatch
• 함수당 추가 자원 프로비저닝 (함수당 최대 10GB 램)
  • 함수의 RAM을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상됩니다.

AWS Lambda 지원 언어

• Node.js (JavaScript)
• Python
• Java (Java 8 Compatible)
• C# (.NET Core)
• Golang
• C# / Powershell
• Ruby
• 커뮤니티에서 지원하는 사용자 지정 런타임 API (Rust 등)
• Lambda 컨테이너 이미지
  • 컨테이너 이미지를 만들 때 전제 조건이 필요합니다. → 모든 컨테이너 이미지가 Lambda에서 실행되는 것은 아닙니다.
    • 컨테이너 이미지 자체의 Lambda 런타임 API를 구현해야 합니다.
  • 임의의 도커 이미지를 실행할 때는 ECS / Fargate를 주로 사용합니다.

AWS Lambda 가격 정책

• https://aws.amazon.com/ko/lambda/pricing/
• 요청당 가격
  • 월별 첫 1,000,000 요청 무료
  • 이후 1,000,000 요청당 0.20$ (요청당 0.0000002$)
• 시간당 가격
  • 월별 첫 400,000GB-초 컴퓨팅 시간 무료
  • == 1GB RAM일 때 400,000초 무료
  • == 128MB RAM일 때 3,200,000초 무료
  • 이후 600,000GB-초당 1.00$
• Lambda로 코드를 실행하면 정말 저렴합니다!

03. Lambda 한도

• Lambda의 한도는 리전별로 존재합니다.
• 실행 한도
  • 메모리 할당량: 128MB ~ 10GB (1MB씩 증가)
    • 메모리가 증가하면 더 많은 vCPU가 필요
  • 최대 실행 시간: 900초 (15분)
  • 환경변수: 4KB
  • 임시 공간(/tmp): 512MB ~ 10GB
  • 동시 실행: 최대 1000개
    • 요청하면 증가시킬 수 있지만, 동시성은 미리 예약해 두는 것이 좋습니다.
• 배포 한도
  • 압축 시 최대 크기: 50MB (compressed .zip)
  • 압축하지 않을 시 최대 크기: 250MB (code + dependencies)
  • 시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 활용할 수 있습니다.
  • 환경변수: 4KB

04. Lambda@Edge & CloudFront Functions

Edge에서의 사용자 지정

• 보통의 경우, 함수와 애플리케이션을 특정 리전에서 배포
• CloudFront의 경우, Edge Location을 통해 콘텐츠를 배포
  • 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 Edge에서 로직을 실행하도록 요구하기도 합니다.
• Edge 함수
  • CloudFront 배포에 연결하는 코드
  • 사용자 근처에서 실행하여 지연시간을 최소화 하는 것이 목적
• CloudFront: CloudFront 함수 & Lambda@Edge
• Edge 함수를 사용하면 전역으로 배포되기 때문에 서버를 관리할 필요가 없습니다.
• Use case: CloudFront의 CDN 콘텐츠 사용자 지정
• 사용한 만큼 비용 지불
• Fully Serverless

CloudFront 함수 + Lambda@Edge: Use Cases

• 웹사이트 보안과 프라이버시
• Edge의 동적 웹 애플리케이션
• 검색 엔진 최적화(SEO)
• 오리진 및 데이터 센터 간 지능형 경로
• Edge에서의 봇 활동 완화
• 실시간 이미지 변환
• A/B 테스트
• 사용자 인증 및 권한 부여
• 사용자 우선순위 지정
• 사용자 추적 및 분석

CloudFront 함수

• JavaScript로 작성된 경량 함수
• 확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용됩니다.
• 시작 시간은 1ms 미만이며, 초당 백만 개의 요청을 처리합니다.
• 뷰어 요청과 응답을 수정합니다.
  • 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 수정 가능
  • 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전 수정 가능
• 모든 코드가 CloudFront에서 직접 관리됩니다.
• 고성능, 고확장성이 필요할 때, 뷰어 요청과 뷰어 응답에만 사용됩니다.

Lambda@Edge

• Node.js 또는 Python으로 작성합니다.
• 초당 수천 개의 요청을 처리할 수 있습니다.
• 모든 CloudFront 요청 및 응답을 변경할 수 있습니다.
  • 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 수정 가능
  • 오리진 요청: CloudFront가 오리진에 요청을 보내기 전 수정 가능
  • 오리진 응답: CloudFront가 오리진으로부터 응답을 받은 다음 수정 가능
  • 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전 수정 가능
• us-east-1 리전에서만 Lambda@Edge 함수 작성이 가능합니다.
  • 함수를 작성하면 CloudFront가 모든 로케이션에 해당 함수를 복제합니다.

CloudFront 함수 vs. Lambda@Edge

CloudFront 함수 vs. Lambda@Edge: Use Cases

• CloudFront 함수
  • 캐시 키 정규화: 요청 속성을 변환하여 최적의 캐시 키를 생성
  • 헤더 조작: 요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제
  • URL 다시 쓰기 또는 리디렉션
  • 요청 인증 및 권한 부여: 요청을 허용 또는 거부하기 위한 JWT 생성 및 검증
• Lambda@Edge
  • 긴 실행 시간
  • CPU와 메모리 증가
  • 써드파티 라이브러리에 의존하는 코드 작성
  • 네트워크 액세스를 통해 외부 서비스에서 데이터를 처리
  • 파일 시스템이나 HTTP 요청 본문에 바로 액세스

05. Lambda in VPC

Lambda 네트워킹 기초

• 기본적으로 Lambda 함수는 VPC 외부에서 시작됩니다.
• 따라서 Lambda 함수는 VPC 내부 리소스에 액세스 할 권한이 없습니다. (RDS, ElastiCache, 내부 ELB 등)
  • 인터넷의 퍼블릭 API에 액세스하는 것은 가능합니다. → DynamoDB 등 퍼블릭 리소스

Lambda in VPC

• VPC ID와 Lambda 함수를 실행하려는 서브넷을 지정하고, Lambda 함수에 보안 그룹을 추가해야 합니다.
• Lambda가 서브넷에 ENI(Elastic Network Interface)를 생성해 VPC에서 실행되는 리소스에 액세스할 수 있게 됩니다.
  • VPC 내 모든 항목에 비공개로 연결할 수 있습니다.

Lambda + RDS 프록시

• 만약 Lambda 함수가 RDS 데이터베이스에 직접 액세스하면, Lambda 함수가 너무 많이 생성되었다 사라지길 반복하면서 문제가 발생합니다.
  • 개방된 연결이 너무 많아서 RDS 데이터베이스의 로드가 상승해 시간 초과 등의 문제로 이어집니다.
• 프록시를 생성하면 이 연결들을 한곳으로 모으고, RDS 데이터베이스 인스턴스 연결의 수를 줄입니다.
• RDS 프록시의 장점
  • 데이터베이스 연결의 풀링과 공유를 통한 확장성 향상
  • 장애 발생 시 장애 조치 시간을 66%까지 줄여 가용성 향상 및 연결 보존
  • RDS 프록시 수준에서 IAM 인증을 강제하여 보안 향상, 자격 증명은 Secrets Manager에 저장
• Lambda 함수가 RDS 프록시에 연결할 수 있으려면, VPC 내부에서 Lambda 함수를 시작해야 합니다.
  • RDS 프록시는 퍼블릭 액세스가 불가능하기 때문입니다.

06. Amazon DynamoDB 개요

Amazon DynamoDB

• 완전 관리형 데이터베이스
• 데이터가 다중 AZ 간에 복제되므로 가용성이 높습니다.
• NoSQL 데이터베이스 ↔ RDS, Aurora 등 관계형 데이터베이스
  • 관계형 데이터베이스는 아니지만 트랜잭션을 지원합니다.
• 데이터베이스가 내부에서 분산되기 때문에 방대한 워크로드로 확장 가능
• 초당 수백만 개의 요청을 처리
• 수조 개의 행, 수백 TB의 스토리지 지원
• 한 자릿수 ms의 속도와 높은 일관성
• 보안, 권한 부여, 관리 기능 → IAM 연동
• 적은 비용과 오토 스케일링
• 유지 관리나 패치 없이 항상 사용 가능
• 두가지 테이블 종류
  • Standard: 액세스가 빈번한 데이터
  • IA(Infrequent Access): 액세스가 빈번하지 않는 데이터

DynamoDB 기초

• 테이블로 구성되며 데이터베이스를 생성할 필요가 없습니다. (데이터베이스가 이미 존재하는 서비스)
• 테이블을 생성하면 각 테이블에 기본 키가 결정 및 부여됩니다.
• 각 테이블은 항목, 즉 행을 무한히 추가할 수 있습니다.
• 각 항목은 속성을 가지며 속성은 열에 표시됩니다.
  • 속성은 나중에도 추가할 수 있으며, null도 가능합니다.
• 항목의 최대 크기는 400KB로 큰 객체를 저장할 때는 적합하지 않습니다.
• 지원하는 데이터 타입
  • 스칼라: 문자열, 숫자, 바이너리, 불리언, null
  • 문서: 목록, 지도
  • 세트: 문자열 Set, 숫자 Set, 바이너리 Set
• 데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때 DynamoDB를 사용합니다.
  • Better than Aurora, RDS

DynamoDB 테이블 예시

• 기본 키: 파티션 키 + 정렬 키(선택 사항)
  • Primary Key: User_ID(Partition Key) + Game_ID(Sort Key)
  • Attributes: Score, Result …
• 속성은 null로 설정하거나 나중에 추가 가능

DynamoDB - 읽기/쓰기 용량 모드

• 테이블 용량 관리 방식 제어
• 프로비저닝된 모드(기본 설정)
  • 초당 읽기/쓰기 요청 수를 예측하여 지정하면 용량을 미리 프로비저닝
  • 용량을 사전에 계획
  • 프로비저닝된 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)만큼의 비용을 지불
  • 오토 스케일링 기능 → 테이블 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있습니다.
  • 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원할 때 적합합니다.
• 온디맨드 모드
  • 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장됩니다.
  • 용량을 사전에 계획하지 않기 때문에 RCU나 WCU의 개념이 없습니다.
  • 정확히 사용한 만큼(모든 읽기와 쓰기)의 비용을 지불, 높은 비용
  • 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용합니다.

07. Amazon DynamoDB 심화 기능

DynamoDB Accelerator (DAX)

• 고가용성의 완전 관리형 무결절 인메모리 캐시
• 읽기 혼잡 해결
  • 테이블에 읽기 작업이 많을 때, DAX 클러스터를 생성하고 데이터를 캐싱
• 캐시 데이터에 마이크로초 수준의 지연 시간 제공
• 기존 DynamoDB API와 호환 → 애플리케이션 로직 변경 불필요
• 캐시의 기본 TTL: 5분 (변경 가능)

DynamoDB Acclerator (DAX) vs. ElastiCache

• DAX는 DynamoDB 앞에 있고 개별 객체 캐시, 쿼리와 스캔 캐시를 처리하는데 유용합니다.
• 집계 결과를 저장한다면 Amazon ElastiCache가 좋습니다.
• DynamoDB는 대용량의 연산을 저장할 때 좋습니다.
• Elasticache와 DynamoDB는 상호 보완적인 성격
• Amazon DynamoDB에 캐싱 솔루션을 추가할 때는 보통 DAX를 사용

DynamoDB - 스트림 처리

• 테이블의 모든 수정 사항(Create, Update, Delete)을 포함한 스트림 생성
• Use Cases
  • 테이블 변경 사항 실시간 반응 (사용자 환영 이메일 등)
  • 실시간 사용 분석
  • 파생 테이블 삽입
  • 리전 간 복제 실행
  • DynamoDB 테이블 변경 사항에 대한 Lambda 함수 실행
• DynamoDB Streams
  • 24시간 보존
  • 소비자 수 제한
  • Lambda 트리거 또는 DynamoDB Stream Kinesis 어댑터와 함께 사용
• Kinesis Data Streams
  • 1년 보존
  • 더 많은 수의 소비자 수
  • AWS Lambda 함수, Kinesis Data Analytics, Kinesis Data Firehose, Glue 스트리밍 ETL 등을 활용한 데이터 처리

DynamoDB 글로벌 테이블

• 여러 리전 간에 복제가 가능한 테이블
• 복수의 리전에서 짧은 지연 시간으로 액세스 가능
• 다중 활성 복제 가능
  • 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있습니다.
• DynamoDB 스트림을 활성화해야 리전 간 테이블을 복제할 수 있는 기본 인프라가 구축됩니다.

DynamoDB TTL(Time To Live)

• 만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능
• Use Cases
  • 최근 항목만 저장
  • 규정에 따라 데이터를 삭제(개인정보 처리방침 등)
  • 웹 세션 핸들링

DynamoDB - 재해 복구

• **지정 시간 복구(PITR, Point-In-Time Recovery)**를 사용한 지속적인 백업
  • 선택적 활성화, 35일 지속
  • 백업 기간 내에는 언제든 지정 시간 복구 실행 가능
  • 복구 진행 시 새로운 테이블 생성
• 온디맨드 백업
  • 직접 삭제할 때까지 보존
  • DynamoDB의 성능이나 지연 시간에 영향을 주지 않습니다.
  • AWS Backup 서비스 사용 가능 → 수명 주기 정책 활성화, 리전 간 백업 복사 등
  • 복구 진행 시 새로운 테이블 생성

DynamoDB - Amazon S3 연동

• S3로 테이블 export → 지정 시간 복구 기능 활성화 선행
  • 지속적인 백업을 활성화한 상태로, 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있습니다.
  • 테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않습니다.
  • DynamoDB를 S3로 export하여 데이터 분석 수행 (query using Athena)
  • 감사 목적 스냅샷 확보
  • 데이터를 DynamoDB로 다시 import하기 전에 데이터 ETL 등 대규모 변경 실행 가능
  • 파일 형식: DynamoDB JSON 또는 ION
• S3에서 테이블 import
  • 파일 형식: CSV, DynamoDB JSON, ION
  • 쓰기 용량을 소비하지 않고, 새로운 테이블 생성
  • import하면서 발생하는 오류는 CloudWatch Logs에 기록

08. API Gateway 개요

Serverless API

• Lambda 함수에서 API의 데이터베이스로 DynamoDB를 사용할 수 있으며, 테이블을 CRUD할 수 있습니다.
• 클라이언트에서 Lambda 함수를 직접 지연 호출(invoke)하려면 IAM 권한이 필요합니다.
• 클라이언트와 Lambda 함수 사이에 애플리케이션 로드밸런서를 배치하면 HTTP 엔드포인트에 Lambda 함수가 노출됩니다. → API Gateway
  • AWS의 서버리스 서비스로 REST API를 생성할 수 있습니다. → 클라이언트가 퍼블릭 액세스할 수 있게 됩니다.
  • API Gateway에 클라이언트가 직접 소통하면서 다양한 작업을 할 수 있으며, Lambda 함수에 요청을 proxy

AWS API Gateway

• AWS Lambda + API Gateway: 인프라 관리가 불필요 (full serverless)
• WebSocket 프로토콜 지원
• API 버전 핸들링
• dev, test, prod 등 여러 환경 핸들링
• 보안 → 인증, 권한 부여 등 활성화
• API 키 생성, 요청 스로틀링 처리
• Swagger, Open API 3.0 등 지원
• API Gateway 수준에서 요청과 응답 변형, 유효성 검사 가능
• SDK 또는 API 스펙(specifications) 생성
• API 응답 캐시

API Gateway 연동

• Lambda 함수
  • Lambda 함수 지연 호출
  • Lambda 함수를 사용하는 REST API를 애플리케이션에 노출시키는 가장 일반적인 방법
• HTTP
  • 백엔드의 HTTP 엔드포인트 노출
• AWS 서비스
  • AWS API 노출

API Gateway - 엔드포인트 유형

• 엣지 최적화(기본 유형): 글로벌 클라이언트용
  • 모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅 → 지연 시간 개선
  • API Gateway는 여전히 생성된 리전에 위치하지만 모든 CloudFront 엣지 로케이션에서 액세스될 수 있습니다.
• 리전 배포: CloudFront 엣지 로케이션을 원하지 않을 때 사용
  • 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 합니다.
  • 자체 CloudFront 배포 생성 가능
    • 엣지 최적화 배포와 동일 결과
    • 캐싱 전략과 CloudFront 설정에 더 많은 권한을 가질 수 있습니다.
• 프라이빗
  • VPC 내에서만 액세스 가능(인터페이스 VPC 엔드포인트)
  • 액세스를 정의할 때 리소스 정책 사용

API Gateway - 보안

• 사용자 식별
  • IAM 역할: 내부 애플리케이션에서 유용
  • Cognito: 외부 사용자(웹, 모바일 어플리케이션)에 대한 보안 조치
  • 사용자 지정 권한 부여자: 자체 로직 실행(Lambda 함수)
• HTTPS 보안
  • 사용자 지정 도메인 이름을 AWS Certificate Manager(ACM)와 연동
    • 엣지 최적화 엔드포인트 사용 시 인증서는 us-east-1에 있어야 합니다.
    • 리전 엔드포인트 사용 시 API Gateway 단계와 동일한 리전에 있어야 합니다.
    • Route 53에 CNAME 또는 A-별칭 레코드를 설정하여 도메인 및 API Gateway를 가리키도록 해야 합니다.

09. Step Functions

AWS Step Functions

• 서버리스 워크플로우를 시각적으로 구성
  • 람다 함수를 오케스트레이션 하는데 사용
  • 각 그래프 단계별로 해당 단계의 결과에 따라 다음으로 수행하는 작업이 무엇인지 정의
  • 복잡한 워크플로우를 만들어 AWS에서 실행시킬 수 있는 편리한 도구
• 기능: 시퀀싱, 병행 실행, 조건 설정, 타임 아웃, 오류 제어
• EC2, ECS, 온프레미스 서버, API Gateway, SQS 큐 등 다양한 AWS 서비스와 연동 가능
• 워크플로우에 사람이 개입해서 승인해야만 진행되는 단계 설정 가능
• Use Cases
  • 주문 이행
  • 데이터 처리
  • 웹 애플리케이션