카테고리 없음

[26WKRD2] API Gateway와 Lambda, 그리고 MySQL

CloudBackend 2026. 4. 3. 17:34

Image by Amazon Web Services

개요

API Gateway, Lambda, MySQL 조합은 AWS 환경에서 가볍고 유연한 API 백엔드를 구성할 때 자주 언급되는 아키텍처입니다. 클라이언트의 요청은 API Gateway가 받아 엔드포인트 역할을 수행하고, Lambda가 비즈니스 로직을 처리하며, MySQL은 필요한 데이터를 저장하고 조회하는 데이터베이스 역할을 맡습니다. 이 구조를 사용하면 서버를 직접 운영하지 않으면서도 비교적 빠르게 API를 구축할 수 있습니다.

이 글에서는 API Gateway -> Lambda -> MySQL 흐름을 기준으로, 각 서비스가 어떤 역할을 담당하는지부터 실제 요청이 데이터베이스까지 전달되고 응답으로 돌아오는 과정까지 차근차근 정리합니다. 또한 구성 시 고려해야 할 연결 방식, 보안 설정, 그리고 실무에서 자주 마주치는 주의사항도 함께 살펴볼 예정입니다.

0. 사전 준비

실습 시 <이 레포>를 사용하니 클론받아 준비해두기 바랍니다.

 

사전 준비 단계에서는 이후 사용할 VPC와 SG 등을 생성합니다.

먼저, VPC를 구성해봅시다. 필자는 아래와 같이 구성하였습니다.

 

이후, 보안 그룹을 구성합니다. 필자는 아래와 같이 구성하였습니다.

1. lambda-sg; Deny inbound, Allow outbound to 0.0.0.0/0 from any.

2. db-sg; Allow inbound from lambda-sg to port 3306, Allow outbound to 0.0.0.0/0 from any.

 

마지막으로, Lambda에서 사용할 Role을 생성하도록 하겠습니다.

 

그리고, 권한 추가 -> 인라인 정책 추가를 선택합니다. 아래 접은글 내의 정책을 참고합니다.

더보기
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Allow",
			"Action": "rds-db:connect",
			"Resource": "arn:aws:rds-db:ap-northeast-2:156041424727:*"
		}
	]
}

 

위와 같은 정책을 가진 람다 역할을 생성합니다.

1. Database 구성

먼저, RDS가 배치될 서브넷의 집합인 서브넷 그룹과 DB 옵션의 집합인 파라미터 그룹을 생성합니다.

필자는 아래와 같이 Private subnet only 서브넷 그룹과 파라미터 그룹을 생성하였습니다.

 

이제, RDS를 생성해봅시다. 필자는 MySQL과 다중 AZ DB 인스턴스 배포 기법을 선택하였습니다.

 

엔진 버전은 Parameter Group의 버전인 8.4 시리즈의 Latest를 선택하였습니다.

이후, 인스턴스 이름, 사용자 이름을 선택하고, Secrets Manager 기반의 암호 관리 기법을 선택합니다.

 

이후, 인스턴스는 필자의 경우 db.t3.medium을 선택하였습니다.

 

스토리지는 20GiB를 할당하였고, 앞서 생성한 VPC와 SubnetGroup을 선택하였으며, 외부에서의 접속을 차단하고자 퍼블릭 액세스를 차단하였습니다.

 

보안 그룹은 DB SG, RDS 프록시도 생성하도록 합니다.

 

모니터링의 경우, 적당히 입맛에 따라 설정합니다.

 

여기서부터는 본인의 입맛에 맞게 싹 설정합니다.

 

이제, 생성합니다.

생성까지 시간이 걸리므로 이후 단계를 밟다가 다시 돌아오는 것을 권장합니다.

조금 기다렸다 돌아오면 위와 같이 잘 생성된 것을 알 수 있습니다.

2. Lambda Setup

이제, 서비스를 구동하기 위한 Lambda를 셋업해봅시다.

먼저, PyMySQL를 설치하여야 하는데, Lambda 특성 상 Layer로 올려야 하므로 참고 문서 1을 참고하여 생성하도록 합시다.

생성을 완료했다면, Lambda 함수를 생성해봅시다.

 

새로 작성을 선택하고, 함수의 이름을 작성하고, Python 3.14를 선택합니다. 아키텍처는 x86_64를 선택하도록 합니다.

그리고 기본 실행 역할은 0번에서 생성한 Lambda Role을 선택합니다.

 

API Gateway를 사용할 예정이므로 함수 URL 옵션은 비활성화하고, VPC 옵션은 활성화하여 Private subnet에 배치할 수 있도록 합니다.

 

자, 이제 생성합니다.

그 후, 참고 문서 1의 절차를 따라 레이어를 함수와 연결합니다.

 

이제, 람다의 기본 lambda_handler.py를 삭제하고 앞서 클론받은 레포의 app/{db, lambda_function}.py를 업로드, 배포합니다.

 

다음으로 람다의 구성 -> 환경 변수 탭으로 들어가 아래와 같이 환경 변수를 세팅합니다.

단, Key 값 조합들은 반드시 여러분들의 App 구성에 맞게 구성하시기 바랍니다.

 

이제 마지막입니다. Lambda -> 함수 선택 -> 구성 -> RDS 데이터베이스로 들어가 아래와 같이 뜨는지 확인합니다.

 

만약 뜨지 않는다면 아래와 같이 선택해서 생성합니다. 그리고 생성했는지 여부와 무관하게 Add proxy로 프록시도 다시 한번 추가합니다.

만약 Proxy 추가 시 오류가 발생한다면, 다시 시도합니다.

 

이제, 테스트해봅시다.

클론받은 Repo의 post_user.json을 테스트 json으로 하는 테스트를 아래와 같이 생성합니다.

 

그리고 테스트합니다.

잘 되네요 Yarr~

3. API Gateway 연결하기

우리의 인프라에서 API Gateway는 2개 타입을 사용할 수 있습니다. 이번 챕터에서는 2개 타입 모두를 실습해보도록 하겠습니다.

3-1. HTTP API

API 이름을 지정하고, API가 통신할 백엔드를 앞서 생성한 Lambda로 지정합니다.

 

이후, 쭉 진행하여 생성합니다.

생성이 잘 되었습니다.

이제 GET 요청을 보내보면

출력이 잘 됩니다.

3-2. REST API

이제 두 번째 타입인 REST API를 선택하고, 아래처럼 값을 잘 지정합니다.

그리고 생성합니다.

 

그 후, 리소스 생성에서 아래 2개를 생성합니다.

1) /products

2) /products/{id}

 

이제, 메서드를 생성해봅시다.

이 때 반드시 Lambda 프록시 통합을 켜주어야 API Gateway가 event를 정상적으로 람다에 쏴줄 수 있습니다.

위와 같은 방식으로 API Method 5개를 모두 생성해줍니다.

 

이제 API 배포를 선택하고, 아래와 같이 입력한 후 배포합니다.

 

잘 배포되었습니다.

 

배포된 URL로 요청을 보내보겠습니다.

 

요청이 잘 가는 모습을 확인할 수 있습니다.

트러블슈팅

- {"message":"Missing Authentication Token"}

API Gateway 리소스 파트에 오타가 없는지 확인할 것.

마치며

지금까지 API Gateway, Lambda, MySQL을 활용해 서버를 직접 운영하지 않으면서도 API 백엔드를 구성하는 흐름을 살펴보았습니다. API Gateway가 요청을 받고, Lambda가 비즈니스 로직을 처리하며, MySQL이 데이터를 저장하는 구조는 비교적 단순하면서도 빠르게 구축할 수 있어 실습용은 물론 실제 서비스의 초기 아키텍처로도 충분히 활용할 수 있습니다.

 

다만 실제 운영에서는 Lambda와 DB 간 연결 방식, VPC 및 보안 그룹 설정, 권한 관리, 커넥션 수 제어 같은 요소를 반드시 함께 고려해야 합니다. 이번 글이 API Gateway -> Lambda -> MySQL 구조를 이해하고 직접 구성해보는 데 도움이 되었기를 바랍니다.

참고 문서

[1] Lambda에 패키지 추가하는 법 - Lambda Layer - https://ninejuan.tistory.com/entry/26WKRD2-Lambda%EC%97%90-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%B6%94%EA%B0%80%ED%95%98%EB%8A%94-%EB%B2%95-Lambda-Layer