AWS 클라우드 따라잡기 9장

이번 장은 서버리스(Serverless)를 다룬다.

서버리스는 "서버가 없다"는 뜻이 아니다.

서버를 내가 관리하지 않는다는 뜻이다.

인스턴스를 켜고 끄고 패치하는 일 없이, 코드만 올리면 AWS가 알아서 실행한다.

이 장의 목표는 다음과 같다.

• Lambda의 동작 방식과 과금 모델을 이해한다.
• API Gateway로 HTTP API를 만든다.
• 서버리스 아키텍처를 그린다.

1. Lambda — 함수 단위 실행

Lambda는 코드를 "함수" 단위로 실행하는 서비스다.

특징은 다음과 같다.

• 서버를 프로비저닝하지 않는다. 코드만 올린다.
• 이벤트가 발생하면 실행되고, 끝나면 사라진다.
• 실행된 시간(밀리초)과 횟수만큼만 요금을 낸다. 대기 중에는 0원.

이벤트는 다양하다.

• API Gateway로 들어온 HTTP 요청
• S3에 파일이 올라온 순간
• DynamoDB 데이터가 바뀐 순간
• EventBridge의 스케줄(예: 매일 새벽 3시)

간단한 파이썬 Lambda 예시:

def handler(event, context):
    name = event.get("name", "World")
    return {
        "statusCode": 200,
        "body": f"Hello, {name}!"
    }

2. Lambda의 특징과 한계

Lambda를 잘 쓰려면 성격을 알아야 한다.

• 상태를 저장하지 않는다(stateless). 데이터는 DynamoDB나 S3에 둔다.
• 실행 시간 제한이 있다. 기본 최대 15분.
• 콜드 스타트: 한동안 안 쓰이다 처음 호출되면 준비 시간이 조금 걸린다.
• 메모리를 올리면 CPU도 비례해 올라간다.

짧고, 이벤트 기반이며, 자주 붙었다 떨어지는 작업에 잘 맞는다.

무겁고 오래 도는 작업은 EC2나 컨테이너가 낫다.

3. API Gateway — HTTP 관문

API Gateway는 클라이언트의 HTTP 요청을 받아 Lambda 등으로 전달하는 관문이다.

• REST API 또는 HTTP API를 만든다.
• 인증, 요청 제한(throttling), 캐싱을 처리한다.
• 경로와 메서드별로 다른 Lambda에 연결한다.

예를 들어:

• GET /users → 사용자 목록 Lambda
• POST /users → 사용자 생성 Lambda

4. 서버리스 아키텍처

Lambda + API Gateway + DynamoDB를 모으면 서버 한 대 없이 API 서비스가 완성된다.

클라이언트
  │  HTTPS
[API Gateway]
  │
[Lambda 함수]
  │
[DynamoDB]

이 구조의 장점은 다음과 같다.

• 트래픽이 0이면 비용도 0에 가깝다.
• 트래픽이 폭증해도 자동으로 확장된다. 서버 증설이 필요 없다.
• 운영 부담이 거의 없다.

5. 그 밖의 서버리스 서비스

서버리스 생태계에는 조합해 쓰는 서비스가 많다.

• EventBridge: 이벤트 버스, 스케줄러. 서비스 간 이벤트를 연결한다.
• Step Functions: 여러 Lambda를 순서·조건에 따라 엮는 워크플로.
• SQS/SNS: 큐와 알림. 서비스를 느슨하게 연결(비동기)한다.
• SAM/Serverless Framework: 서버리스 앱을 코드로 정의하고 배포한다.

6. 언제 서버리스가 좋은가

• 트래픽이 들쭉날쭉하거나 예측이 어려울 때
• 이벤트에 반응하는 작업(파일 업로드 처리, 알림 등)
• 빠르게 프로토타입을 만들 때
• 운영 인력을 최소화하고 싶을 때

반대로 항상 높은 트래픽이 꾸준하거나, 매우 긴 작업이라면 EC2/컨테이너가 비용·성능에서 유리할 수 있다.

정리

• 서버리스는 서버 관리 없이 코드만 올려 실행하는 방식이다.
• Lambda는 이벤트로 실행되고 쓴 만큼만 과금된다.
• API Gateway + Lambda + DynamoDB가 서버리스 API의 정석이다.
• 들쭉날쭉한 트래픽과 이벤트 기반 작업에 특히 강하다.

다음 장에서는 또 다른 배포 방식인 컨테이너를 다룬다.