Lambda 요청 본문 한계를 CPU EC2 게이트웨이로 해결하기

문제: 서버를 깨우는 것과 원래 요청을 전달하는 것은 다른 문제였습니다

Request-on-Wake 구조를 설계하면서 처음에는 Lambda가 GPU EC2를 시작하는 동시에 원래 요청까지 이어서 처리하는 방식을 검토했습니다.

하지만 RenameDP의 요청은 문서나 이미지처럼 본문 크기가 커질 수 있었습니다. Lambda를 요청 중계 지점으로 사용하면 요청 본문 크기와 실행 방식의 제약 때문에 대용량 데이터를 안정적으로 보관하고 전달하기 어려웠습니다.

해결: 제어 경로와 데이터 경로를 분리했습니다

Lambda에는 GPU EC2를 시작하거나 상태를 변경하는 제어 역할만 맡겼습니다. 실제 사용자 요청의 수신·보관·재전송은 항상 실행 중인 CPU EC2 게이트웨이가 담당하도록 구조를 변경했습니다.

CPU EC2는 다음 흐름을 처리합니다.

1. 클라이언트의 원래 요청을 수신합니다.
2. GPU EC2와 vLLM 서버의 상태를 확인합니다.
3. 서버가 중지되어 있으면 Lambda에 기동을 요청합니다.
4. 추론 서버가 준비되면 보관 중인 원래 요청을 전달합니다.
5. 모델 응답을 클라이언트에 반환합니다.

이 구조에서는 대용량 요청 본문이 Lambda를 통과하지 않습니다. Lambda는 짧고 명확한 인프라 제어 작업에 집중하고, CPU EC2는 일반적인 HTTP 요청 처리와 재시도 흐름을 담당합니다.

설계 의도

• Control Plane: Lambda를 통한 GPU EC2 상태 제어
• Data Plane: CPU EC2를 통한 실제 요청과 응답 전달
• Inference Plane: GPU EC2와 vLLM을 통한 모델 추론

기능별 책임을 분리하면서 각 컴포넌트가 잘하는 일에 집중할 수 있었고, Lambda의 제약이 서비스 요청 크기의 제약으로 이어지는 문제를 피했습니다.

배운 점

서버리스 컴포넌트가 편리하더라도 모든 요청을 그 안으로 통과시키는 것이 항상 좋은 설계는 아니었습니다.

이번 경험을 통해 인프라 제어 이벤트와 실제 비즈니스 데이터를 분리하고, 제약이 있는 컴포넌트는 좁고 명확한 책임으로 사용하는 것이 중요하다는 점을 배웠습니다.