6. 서버리스와 연결 — 요청·이벤트·메시지
이 장에서 처음 나오는 말4개
LambdaAWS Lambda- 이벤트를 입력받아 함수를 실행하는 서비스.
API GatewayAmazon API Gateway- 클라이언트의 API 요청을 받아 인증·라우팅·백엔드 연결을 담당하는 입구.
이벤트Event- 사진 업로드 완료처럼 발생한 일을 알리는 데이터.
큐Queue- 생산자가 보낸 작업을 소비자가 처리할 때까지 보관하는 대기열.
사진 목록은 사용자가 화면에서 바로 받아야 한다. 반면 썸네일 생성은 업로드를 접수한 뒤 처리할 수 있다. 같은 앱에서도 바로 결과가 필요한 요청과 완료를 나중에 확인할 작업은 연결 방식이 다르다. 이 장에서는 저장소 앞뒤의 호출 경로와 실패 처리 책임을 찾는다.
먼저 동기 요청과 나중에 처리할 작업을 나누기
섹션 제목: “먼저 동기 요청과 나중에 처리할 작업을 나누기”| 상황 | 호출자가 기다리는 것 | 설계할 것 |
|---|---|---|
| 사진 목록 조회 | 조회 결과 응답 | timeout·오류 응답·클라이언트 재시도 |
| 업로드 후 썸네일 생성 | 작업 접수 또는 이벤트 전달 | 작업 상태·재시도·실패 보관·중복 처리 |
비동기 접수 성공은 썸네일 생성 성공과 다르다. 화면에서 PROCESSING 상태를 보여 주고 나중에
READY 또는 FAILED를 조회할 수 있어야 한다. 서비스 사이를 나누면 그 사이의 실패도 앱이 표현해야 한다.
Lambda의 들어오는 권한과 나가는 권한
섹션 제목: “Lambda의 들어오는 권한과 나가는 권한”
그림의 두 화살표는 서로 다른 요청이다. API Gateway 같은 서비스가 함수를 호출하도록 허용하는 것은 함수의 자원 기반 정책에서 확인한다. 같은 계정 IAM 주체의 직접 호출 등은 호출자 정책과 함께 평가하므로 모든 호출에 같은 형태의 함수 정책이 필요한 것은 아니다. (Lambda 자원 기반 정책)
**Execution role(실행 역할)**은 함수 코드가 S3·DynamoDB·CloudWatch Logs 등에 접근할 때 쓰는 권한이다. 역할의 신뢰 정책은 Lambda 서비스가 맡을 수 있게 하고, 권한 정책에는 필요한 작업과 대상만 넣는다. 로그를 남길 권한도 여기에 속한다. (Lambda 실행 역할)
따라서 함수가 호출되지 않으면 호출 경로와 호출 권한부터, 실행됐는데 S3 접근이 거부되면 실행 역할과 S3 정책부터 본다. 상세 평가 원리는 IAM 장을 따른다.
함수 설정은 코드의 실행 계약이다
섹션 제목: “함수 설정은 코드의 실행 계약이다”| 설정·입력 | 읽을 의미 | 사진 처리에서 확인할 것 |
|---|---|---|
| Handler | 런타임이 호출할 코드 진입점 | 설정한 모듈·함수 이름과 배포 파일 일치 |
event | 이번 호출의 입력 | API 요청인지 S3 알림인지 SQS batch인지 |
context | 실행 관련 정보 | 요청 식별자·남은 실행 시간 등 |
| Runtime | 코드 실행 환경 | 지원 언어·버전·패키지 호환성 |
| Memory·Timeout | 할당 메모리와 실행 시간 한도 | 큰 이미지 처리 시간·메모리 부족 |
| Execution role | 실행 중 AWS API 권한 | 원본 읽기·썸네일 쓰기·로그 기록 |
입력 형태는 호출 경로마다 다르다. 콘솔의 임의 테스트 JSON이 통과해도 실제 S3 알림이나 SQS batch를 처리할 수 있다는 증거는 아니다. 런타임별 handler 계약은 Lambda 프로그래밍 모델을 확인한다.
Lambda 호출은 세 갈래로 구분한다
섹션 제목: “Lambda 호출은 세 갈래로 구분한다”| 방식 | 대표 경로 | 실패를 다시 다루는 곳 |
|---|---|---|
| 동기 호출 | API Gateway → Lambda | 호출자·앞단 서비스의 정책 |
| 비동기 호출 | S3 알림·SNS → Lambda 내부 큐 → 함수 | Lambda 비동기 이벤트 처리 설정 |
| Event source mapping | Lambda poller가 SQS·스트림을 읽음 → 함수 | 소스별 queue·stream 설정과 매핑 설정 |
동기 호출: 결과를 호출자에게 돌려준다
섹션 제목: “동기 호출: 결과를 호출자에게 돌려준다”Lambda의 직접 동기 호출은 함수 코드 오류를 자동 재시도하지 않는다. API Gateway도 함수 오류를 호출자에게 전달한다. 재시도가 필요하면 호출자 측에서 오류 종류와 중복 실행 가능성을 판단한다. (호출 방식별 재시도)
비동기 호출: Lambda가 이벤트를 접수하고 실행한다
섹션 제목: “비동기 호출: Lambda가 이벤트를 접수하고 실행한다”S3가 함수에 이벤트를 비동기로 보내면 Lambda가 내부 큐에서 실행을 관리한다. 함수 오류는 기본적으로 추가 두 번 재시도하지만 설정으로 바꿀 수 있다. throttling·서비스 오류의 처리는 함수 오류와 다르며, 이벤트 최대 수명과 실패 목적지도 확인한다. (비동기 오류 처리)
이벤트 소스 매핑: Lambda가 큐·스트림을 읽는다
섹션 제목: “이벤트 소스 매핑: Lambda가 큐·스트림을 읽는다”SQS나 DynamoDB Streams에서는 Lambda의 event source mapping이 레코드를 읽어 batch로 함수를 호출한다. SQS가 위의 비동기 내부 큐로 메시지를 밀어 넣는 그림과 구별한다. (이벤트 소스 매핑)
SQS의 재처리는 visibility timeout과 redrive policy 등을 확인한다. 스트림은 shard와 batch의 실패 처리·보존 시간·재시도 설정을 본다. 이 경로에 “최대 두 번 재시도”를 그대로 적용하지 않는다.
API Gateway는 클라이언트와 백엔드의 경계다
섹션 제목: “API Gateway는 클라이언트와 백엔드의 경계다”REST API의 네 단계로 요청 변환 읽기
섹션 제목: “REST API의 네 단계로 요청 변환 읽기”강의의 요청·응답 그림은 REST API의 non-proxy 통합을 이해하는 데 유용하다.
| 순서 | 설정 영역 | 답할 질문 |
|---|---|---|
| 요청 1 | Method request | 어떤 메서드·파라미터·인증 조건으로 받을까? |
| 요청 2 | Integration request | 어느 백엔드로 어떤 형식으로 전달할까? |
| 응답 1 | Integration response | 백엔드 결과·오류를 어떻게 변환할까? |
| 응답 2 | Method response | 클라이언트에게 어떤 상태·헤더를 돌려줄까? |
Lambda proxy integration은 요청 정보를 정해진 event 형식으로 전달하고 함수가 약속된 응답 형식을 반환한다. 위 네 영역을 모두 수동 매핑하는 방식과 설정이 다르다. (API 통합 유형)
REST API와 HTTP API를 혼동하지 않기
섹션 제목: “REST API와 HTTP API를 혼동하지 않기”API Gateway의 REST API와 HTTP API는 별도 제품 유형이다. HTTP API에서도 REST 방식의 API를 만들 수 있다. JWT authorizer·요청 검증·캐시·WAF 연동 같은 필요한 기능을 공식 비교표에서 확인한다.
REST API endpoint 유형은 edge-optimized·Regional·private로 구분한다. Private API와
“공개 API가 VPC 안의 비공개 백엔드에 연결한다”는 private integration은 다른 경계다.
Stage는 배포를 노출할 환경 이름이다. dev·prod라는 이름만으로 계정·데이터·권한이 격리되지는 않는다.
(REST API endpoint 유형,
Stage)
SQS·SNS·EventBridge를 역할로 고르기
섹션 제목: “SQS·SNS·EventBridge를 역할로 고르기”| 필요한 동작 | 서비스 | 사진 앱 예시 |
|---|---|---|
| 작업을 쌓고 소비 속도에 맞춰 처리 | SQS (Simple Queue Service) | 썸네일 작업을 큐에서 가져가 처리 |
| 한 알림을 여러 구독자에게 전달 | SNS (Simple Notification Service) | 처리 완료를 여러 구독 큐로 전달 |
| 이벤트 내용과 규칙으로 목적지 선택 | EventBridge | 업로드 이벤트를 이미지·동영상 처리 대상으로 분기 |
큐는 보관과 소비 속도 조절, topic은 구독자에게 배포, event bus는 규칙 기반 라우팅에 초점을 둔다. 서로 대체만 하는 서비스가 아니라 SNS → SQS처럼 조합할 수 있다. (AWS 메시징 선택 가이드)
서비스를 하나 더 넣을 때마다 전달 성공·처리 성공·실패 보관 위치를 나눠 기록한다. API·함수·큐가 모두 정상이어도 앱이 완료 상태를 저장하지 않으면 사용자에게는 계속 처리 중으로 보인다.