DWG 파일을 GLTF로 변환하는 서버리스 컨테이너 Lambda 이야기

서론

회사에서 DWG 파일을 GLTF로 변환하는 기능을 구현해야 하는 과제가 생겼다. 여러 가지 방법을 검토한 끝에, 변환 과정에서 Blender 엔진을 사용하고, 서버리스(Serverless) 환경에서 배포하는 방향으로 결정했다. 이러한 요구 사항을 충족하기 위해 AWS Lambda를 컨테이너 기반으로 실행하는 방법을 선택했다.

이번 글에서는 컨테이너 기반 Lambda의 개념과 이를 도입하는 과정에서 겪은 우여곡절을 공유하려고 한다.

---

Lambda

AWS Lambda는 서버를 관리할 필요 없이 코드 실행을 자동으로 처리하는 서버리스 컴퓨팅 서비스다. 사용자는 트리거 이벤트를 기반으로 코드를 실행할 수 있으며, 인프라를 직접 설정할 필요 없이 AWS가 자동으로 리소스를 할당하고 관리한다.

Lambda를 활용하는 방식은 크게 세 가지로 나눌 수 있다.

Lambda 함수 생성시 볼 수 있는 화면

1. 새로 작성

가장 기본적인 방식으로, AWS Lambda 콘솔 또는 CLI에서 직접 코드를 작성하고 배포하는 방법이다. AWS에서 제공하는 다양한 언어(Python, Node.js, Java 등)를 선택하여 코드를 업로드할 수 있다. 이는 간단한 함수나 빠르게 테스트할 때 유용하지만, 복잡한 애플리케이션을 다루기에는 한계가 있다.

2. 블루프린트

AWS에서 제공하는 미리 정의된 템플릿을 기반으로 Lambda 함수를 생성하는 방식이다. 블루프린트는 특정 AWS 서비스와의 통합을 쉽게 만들도록 설계된 예제 코드와 설정이 포함되어 있어, 처음 Lambda를 사용하는 사용자에게 유용하다.

3. 컨테이너 이미지

Lambda 함수의 실행 환경을 도커 컨테이너로 감싸서 배포하는 방법이다. 이는 특히 복잡한 종속성이 필요한 경우 유용하며, 기존 컨테이너 기반 애플리케이션을 쉽게 서버리스 환경으로 마이그레이션할 수 있다.

이번 프로젝트에서는 Blender 엔진을 포함해야 했기 때문에, 컨테이너 이미지 기반 Lambda를 선택했다.

---

컨테이너 기반 Lambda

그렇다면 어떤 경우에 컨테이너 기반 Lambda를 사용할까?

컨테이너 기반 Lambda는 AWS Lambda를 기존의 도커 컨테이너 실행 방식과 결합한 배포 모델이다. 기본적인 Lambda와는 다르게, 사용자가 직접 도커 이미지를 빌드하고 AWS Elastic Container Registry (ECR)에 업로드한 후 이를 기반으로 Lambda를 실행할 수 있다.

컨테이너 기반 Lambda를 사용하는 이유

1. 대용량 라이브러리 및 종속성 지원
   • Lambda의 일반적인 코드 패키지는 250MB 제한이 있지만, 컨테이너 기반 Lambda는 10GB까지 가능하다.
   • Blender, OpenGL 같은 대형 라이브러리나 바이너리를 포함할 때 유용하다.
2. 로컬 개발 환경과의 일관성 유지
   • 기존 도커 컨테이너 환경에서 개발한 애플리케이션을 동일한 환경에서 Lambda로 배포할 수 있다.
   • 컨테이너 기반 개발을 이미 하고 있다면 Lambda로 쉽게 확장 가능하다.
3. 멀티 언어 및 사용자 정의 런타임 지원
   • AWS Lambda의 기본 런타임(Python, Node.js 등) 외에도, 컨테이너 기반 Lambda를 사용하면 Rust, PHP 등 다른 언어도 실행 가능하다.
4. ECR을 활용한 효율적인 배포
   • 컨테이너 이미지를 한 번 빌드하면, 동일한 이미지를 여러 Lambda 함수에서 재사용할 수 있다.
   • AWS Elastic Container Registry (ECR)를 활용하여 버전 관리 및 배포가 간편하다.

---

컨테이너 기반 Lambda 구축 과정

처음 고려한 아키텍처

빨간색 : 사용자 요청 처리, 파란색 : CI/CD

이 프로젝트에서 우리가 처음 고려한 아키텍처는 크게 두 가지 흐름으로 구성되었다.

1. 사용자 요청 처리: 사용자가 API Gateway를 통해 DWG 파일을 업로드하면, Lambda에서 변환하여 GLTF(GLB) 파일을 반환하는 구조였다. 변환된 파일은 base64로 인코딩되어 전달되었다.
2. CI/CD 프로세스: Github Actions의 Runner가 ECR에 빌드된 이미지를 업로드하고, Lambda의 이미지를 최신 빌드로 업데이트하는 방식이었다.

문제 발생

그러나 문제가 발생했다. Lambda가 DWG 파일을 직접 처리하기에는 한계가 있었다. https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution에 따르면, `6 MB each for request and response (synchronous)` 라고 얘기하고 있었다.

즉, 동기 요청의 경우 요청과 응답 크기 제한이 각각 6MB였다.

이를 해결하기 위해 아키텍처를 수정했다:

1. DWG 파일을 DXF로 변환하는 미들웨어 서버를 추가했다.
2. DXF 파일을 S3에 업로드하여 저장했다.
3. Lambda에서는 CDN을 통해 DXF 파일을 가져와 Blender로 변환하도록 변경했다.

이러한 개선 후의 최종 Workflow는 다음과 같다.

최종 WorkFlow

초록색 : DXF 업로드, 빨간색 : 사용자 요청 처리, 파란색 : CI/CD

또 다른 문제

이제 Lambda에서 DXF를 GLTF(GLB)로 변환하는 과정이 정상적으로 수행되었지만, 또 다른 문제가 발생했다. Blender 엔진이 매우 무겁다는 점이었다.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle

을 참고하면, 아래와 같이 Lambda의 실행 환경 수명 주기 그림을 확인할 수 있다.

Blender 에서 DXF to GLTF(GLB) 하는 것은 1~2초면 끝났지만, Lambda의 초기 실행 단계(INIT)에서 상당한 시간이 소요될 수 있다. 대략 4~5초?
실제로 기본적인 스펙의 메모리로는 아래와 같은 에러를 만날 수 있었다.

INIT_REPORT Init Duration: 9997.70 ms Phase: init Status: timeout

일단 Lambda 스펙을 스케일업 하는 방법으로 해결했다. Lambda의 메모리를 최대한(약 10GB)까지 할당했고, 결과적으로 로직은 정상적으로 수행되었다. 하지만 전체적인 API 응답 시간이 10초 정도 소요되었으며, 이 문제를 UI에서 Graceful하게 처리하는 방식으로 함으로써, 구현을 마무리 하였다.

추가적인 고려사항

컨테이너 이미지를 만들 때 Amazon Linux 2023을 베이스 이미지로 사용했다. 이를 선택한 이유는 다음과 같다:

• AWS Lambda 실행 환경과의 호환성: Amazon Linux는 AWS Lambda의 실행 환경과 동일한 기반을 사용하므로, 최적의 호환성을 제공한다.
• 경량화 및 성능 최적화: 다른 Linux 배포판보다 가벼우면서도 필요한 패키지를 설치하기 용이하다.
• 보안 및 장기 지원: Amazon Linux 2023은 AWS에서 장기 지원(LTS)을 제공하며, Lambda 환경에서의 보안 업데이트가 신속하게 적용된다.

또한, Blender를 서버리스 환경에서 실행할 때 X11을 설치했는데, 이유는 아래와 같다.

• Blender의 GUI 종속성 해결: Blender는 기본적으로 GUI 환경에서 실행되도록 설계되었기 때문에, 헤드리스(Headless) 환경에서도 일부 라이브러리가 필요하다.
• 렌더링 엔진의 실행 안정화: X11이 없으면 일부 렌더링 기능이 제대로 동작하지 않을 수 있어, 최소한의 X 서버 패키지를 설치하여 이를 해결했다.
• Lambda 환경에서의 실행 가능성 확보: X11을 추가하면 Lambda에서 Blender를 실행할 때 DISPLAY 환경 변수가 없어도 정상적으로 작동할 수 있도록 설정할 수 있다.

---

마무리

컨테이너 기반 Lambda를 활용하면 복잡한 라이브러리를 포함한 서버리스 애플리케이션을 손쉽게 배포할 수 있다. 이번 프로젝트에서 Blender를 활용한 DWG → GLTF 변환 기능을 성공적으로 구축할 수 있었으며, 다음과 같은 이점을 얻을 수 있었다.

• 서버리스 아키텍처로 관리 부담 감소
• 컨테이너 환경을 활용하여 개발 및 배포 일관성 유지
• 대형 라이브러리 지원으로 Lambda의 한계를 극복

앞으로 서버리스 환경에서 더 많은 복잡한 애플리케이션을 실행할 수 있도록 컨테이너 기반 Lambda의 활용 방안을 더욱 연구해 볼 예정이다.