AWS Lambda → EC2 트리거

한 줄 요약

S3에 파일이 업로드되면 Lambda가 이를 감지하여 EC2 인스턴스를 시작하고, EC2에서 텍스처 변환(JPEG → KTX2)을 수행한 뒤 자동 종료하는 이벤트 드리븐 아키텍처. Lambda는 트리거 역할만 하고, 실제 연산은 고사양 EC2에서 처리한다.

왜 Lambda에서 직접 변환하지 않는가

AWS Lambda는 서버리스 함수로, 이벤트에 반응하여 코드를 실행하기에 적합하다. 그러나 텍스처 변환 작업에는 두 가지 근본적 제약이 있다:

시간 제한: Lambda의 최대 실행 시간은 15분이다. 3,561개의 b3dm 파일(2.6GB)을 변환하는 데는 이 시간으로 부족하다.

메모리 제한: Lambda의 최대 메모리는 10GB다. 대용량 3D 모델 파일을 메모리에 올려서 변환하기에는 제약이 크다.

이 제약 때문에 Lambda에서 직접 변환하는 것은 불가능했다.

대안 검토: 왜 EC2인가

AWS에서 장시간 배치 작업을 처리하는 서비스는 여러 가지가 있다:

• AWS Batch: 배치 작업 관리 서비스. 설정이 복잡하고 관리 오버헤드가 있다.
• ECS Fargate: 서버리스 컨테이너. 편리하지만 비용이 EC2보다 높다.
• EC2: 직접 인스턴스를 관리해야 하지만, 비용이 가장 저렴하다.

최종적으로 EC2가 가장 비용 효율적이었다. 핵심 전략은 높은 사양의 인스턴스를 선택하여 실행 시간을 최소화하는 것이다. 저사양 인스턴스를 오래 돌리는 것보다, 고사양 인스턴스를 짧게 돌리는 것이 총 비용이 더 적었다. 32 vCPU 인스턴스를 사용하면 CPU 코어 수만큼 병렬 처리가 가능하여 변환 시간이 크게 단축된다.

아키텍처 구조

업로드 담당자: zip 파일을 S3에 업로드 (기존 워크플로우 변경 없음)
        ↓
S3: 업로드 이벤트 발생
        ↓
Lambda: S3 이벤트 감지 → EC2 인스턴스 시작 (트리거 역할만)
        ↓
EC2 (32 vCPU):
  1. S3에서 zip 다운로드
  2. 압축 해제
  3. JPEG → KTX2 변환 (CPU 코어 수만큼 병렬)
  4. 변환 결과를 S3에 업로드
  5. 자동 종료

이 구조의 핵심 설계 원칙 세 가지:

Lambda는 트리거만 한다: Lambda의 코드는 EC2 인스턴스를 시작하는 API 호출 한 줄이다. 실제 변환 로직은 EC2에서 실행된다. Lambda의 실행 시간은 수 초에 불과하므로 비용이 거의 발생하지 않는다.

업로드 담당자의 워크플로우는 변경되지 않는다: 담당자는 이전과 동일하게 zip 파일을 S3에 업로드하기만 하면 된다. 이후의 변환 과정은 자동으로 진행된다.

EC2는 작업 완료 후 자동 종료된다: 변환이 끝나면 EC2가 스스로 종료되므로, 유휴 상태에서 비용이 발생하지 않는다. 사실상 "사용한 만큼만 비용을 지불하는" 서버리스에 가까운 비용 구조가 된다.

비용과 성능

32 vCPU EC2 인스턴스 기준으로, 3,561개 b3dm 파일(2.6GB) 변환에 약 10분이 소요된다.

비용 구조를 분해하면:

• Lambda: 월 수백 회 트리거 수준이면 프리 티어 범위 내이거나 극히 소액
• EC2: 변환 1회당 고사양 인스턴스 10분 사용 비용만 발생
• S3: 저장 및 전송 비용 (모델 데이터 크기에 비례)

24시간 서버를 운영하는 것이 아니라, 변환이 필요한 순간에만 고사양 인스턴스를 켜고 끄는 방식이므로 비용 효율이 높다.

이 경험에서 추출한 원칙

1. "서버리스의 한계"가 곧 "서버가 필요한 이유"다. Lambda의 시간·메모리 제한은 설계상 의도된 것이다. 이 제한을 우회하려고 Lambda를 억지로 쓰는 것보다, Lambda는 트리거로만 쓰고 실제 작업은 적합한 도구(EC2)에 맡기는 것이 올바른 아키텍처다.

2. 고사양 × 짧은 시간이 저사양 × 긴 시간보다 싸다. 클라우드 비용은 (인스턴스 단가 × 실행 시간)이다. 단가가 높더라도 실행 시간이 충분히 줄어들면 총 비용이 낮아진다. 특히 CPU 병렬 처리가 가능한 작업에서는 코어 수를 늘리는 것이 거의 선형적으로 시간을 줄여준다.