AWS Lambda 기반 서버리스 앱에서 데이터 스토리지 선택하기

AWS Lambda는 서버리스 애플리케이션을 지원하는 온디맨드 컴퓨팅 서비스입니다. Lambda 함수는 임시로 함수가 호출될 때 짧은 시간 동안만 실행 환경이 존재합니다. 그런데, 대부분 컴퓨팅 작업은 다양한 목적을 위해 외부 데이터에 접근해야합니다. 미디어 파일을 읽거나, 임시 파일을 저장하거나 데이터 분석을 위한 로그 파일 등을 접속할 때도 있습니다.

Lambda 함수를 개발할 때, 웹 애플리케이션 개발자의 요구 사항을 충족하는 다양한 스토리지 옵션을 제공합니다. 이 글에서는 다양한 옵션 간의 차이점을 설명하고, 여러분이 선택하는 데 도움이 되는 길잡이가 되고자 합니다. (이 글은 Happy Path 웹 애플리케이션 시리즈를 기반으로 하며, Github 저장소에서 샘플 코드를 다운로드할 수 있습니다.)

1. Amazon S3 – 객체 스토리지 사용하기

Amazon S3는 탄력적으로 확장되는 무제한 객체 스토리지 서비스입니다.  이 서비스는 구조화되지 않은 데이터를 저장하는 데 이상적입니다. 즉, 이미지 또는 미디어, 로그 파일 및 센서 데이터와 같은 이진 데이터가 포함됩니다.

기억해야 할 S3 객체 스토리지의 특성은 S3 객체의 버전 관리는 가능하지만, 파일 시스템에서처럼 데이터를 추가할 수는 없다는 점입니다. 완전히 새로운 버전의 객체를 저장해야 합니다. S3에는 파일 시스템과 다른 스토리지 계층도 있습니다. 디렉터리 대신 사용 를 폴더를 사용 하여, 키 이름에 ‘foldername/‘ 접두사를 통해 개체를 논리적으로 구성합니다.

S3에는  Lambda와의 기본 통합이 있어 S3 이벤트에 대한 응답으로 함수를 호출할 수 있습니다. 즉, S3에서 객체가 생성되거나 삭제될 때 애플리케이션 워크플로를 트리거하는 확장 가능한 방법을 제공할 수 있습니다.  Happy path 샘플 앱에서도 이미지 처리 작업은 파일 업로드 이벤트가 나올 때 동적합니다

S3는  대규모 데이터 분석을 위한 데이터 레이크 저장소입니다. 애플리케이션이 S3 버킷에 데이터를 쓰는 경우, 다운스트림 처리를 위한 유용한 준비 영역이 될 수 있습니다. 분석 워크로드의 경우, AWS Glue를 사용하여 ETL(추출, 변환 및 대출) 작업을 수행할 수 있습니다. Amazon QuickSight는 임시 시각화 및 비즈니스 분석 보고서를 생성하기 위해 S3 버킷에 연결하고 대화형 대시보드를 생성할 수 있습니다. 웹 애플리케이션을 위한 비즈니스 인텔리전스 대시보드를 구축하는 방법은 Innovator Island 워크샵을 살펴보세요.

그리고, S3는 객체 수명 주기 관리를 제공합니다. 이를 통해, 특정 조건이 충족될 때 스토리지 클래스를 자동으로 변경할 수 있습니다. 예를 들어, Happy path 애플리케이션에서도 원본 고해상도 파일 업로드 후, 저장 비용을 줄이기 위해 30일 후에 원본 사진 자산을 자동으로 삭제하도록 구성할 수 있습니다.

2. /tmp 폴더에 임시 저장하기

Lambda 실행 환경에서 /tmp 폴더에 임시 파일 시스템을 제공합니다. 이 공간의 고정 크기는 512MB입니다. 동일한 Lambda 실행 환경을 여러 Lambda 호출에서 재사용할 수 있습니다. /tmp 영역은 실행 환경의 수명 동안 보존되며, 호출 사이의 데이터에 대한 임시 캐시를 제공합니다. 새 실행 환경이 생성될 때마다 이 영역은 삭제됩니다.

즉, 임시 저장 영역으로 사용해야 합니다. 람다 함수는 여기에서 호출 사이에 데이터를 캐시할 수 있지만, 단일 호출에서 코드에 필요한 데이터에만 사용해야 합니다. 데이터를 영구적으로 저장하는 장소가 아니며, 한번 함수를 실행할 때, 필요한 작업을 지원하는 데 사용할 수 있습니다.

/tmp의 파일 작업은 로컬 하드 디스크와 동일하며 빠른 I/O 처리량을 제공합니다. 예를 들어, Python에서 이 공간에 파일의 압축을 풀려면 다음과 같이 할 수 있습니다.

import os, zipfile
os.chdir('/tmp')
with zipfile.ZipFile(myzipfile, 'r') as zip:
    zip.extractall()

3. Lambda Layer 저장소 이용하기

Lambda 함수는 배포 패키지의 일부로 추가 라이브러리를 사용할 수 있습니다. 배포 아카이브에서 이를 번들로 묶거나 Lambda Layer를 사용할 수 있습니다. Lambda 함수는 최대 5개의 계층을 가질 수 있으며, 최대 배포 크기 는 50MB입니다(직접 업로드의 경우 압축 포함). 레이어 패키지는 호출 중에 /opt 디렉토리에서 사용할 수 있습니다. Lambda Layer 공유 기능을 통해 다른 AWS 계정과 공유할 수도 있습니다.

서버리스 애플리케이션 전반에 걸쳐 Lambda Layer를 사용하면 많은 이점이 있습니다. Lambda 서비스와 함께 제공되는 버전에 의존하는 대신 AWS SDK를 사용하는 것이 모범 사례입니다. 이를 통해 SDK 버전을 고정할 수 있습니다. Lambda Layer을 사용하면 각 함수와 패키지를 미리 묶을 필요가 없으므로, 배포 패키지 크기가 커지고 배포 속도가 느려질 수 있습니다. AWS SDK Layer를 생성한 다음, 각 함수에서 Layer에 대한 참조를 포함할 수 있습니다.

Lambda Layer는 의존성을 묶거나 운영 체제에 따라 다른 바이너리와 컴파일된 라이브러리를 공유하는 효과적인 방법이 될 수 있습니다. 예를 들어, Happy Path 애플리케이션에서는 Sharp npm 그래픽 라이브러리를 사용하여 이미지를 처리합니다. 마찬가지로 Innovator Island 워크샵에서는  OpenCV 라이브러리를 사용하여 이미지 조작을 수행하며 이는 공유 레이어를 사용하여 재사용 가능합니다.

일단 Lambda Layer는 정적으로 배포됩니다. 따라서, 새 버전을 배포해야만 레이어의 내용을 변경할 수 있습니다. Lambda Layer을 사용하는 모든 Lambda 함수는 특정 버전에 바인딩되며 계층 버전을 변경하려면 업데이트해야 합니다. 자세한 내용은 Lambda Layer을 사용하여 개발 프로세스 간소화를 참고하세요.

4. Lambda용 Amazon EFS 사용하기

Amazon EFS는 탄력적인 완전 관리형 네트워크 공유 파일 시스템입니다. EBS 볼륨과 같은 내구성이 높은 스토리지이며, 고가용성을 제공하는 옵션도  가능합니다. Lambda 함수에 EFS 볼륨을 탑재할 수 있으므로 함수 호출 간에 데이터를 더 쉽게 공유할 수 있습니다. EFS의 경우, 데이터를 추가하거나 삭제할 때 파일 시스템이 확장 및 축소되므로 스토리지 제한을 관리할 필요가 없습니다.

AWS Lambda 서비스는 람다 함수 실행 환경이 준비되면 EFS 파일 시스템을 연결합니다. 이 때, 다른 초기화 작업과 동시에 발생하므로 일반적으로 콜드 스타트 ​​대기 시간에 큰 영향을 미치지 않습니다. 실행 환경이 이전 호출에서 웜(Warm) 상태이면 마운트가 이미 준비된 것입니다.  VPC를 사용하느 경우, Lambda 함수가 EFS와 동일한 VPC에 있어야 합니다.

EFS는파일 시스템은 라이브러리와 달리 Lambda 함수에 대한 동적 바인딩을 제공합니다. 따라서 항상 최신 버전을 사용하려는 코드 라이브러리를 배포하는 데 유용합니다. 또한, 표준 파일 작업의 속도와 지원을 통해 많은 수의 파일을 지속적으로 수집하거나 쓰는 데에도 유용합니다. 예를 들어, 대용량 아카이브를 압축하거나 압축 해제하는 데 유용할 수 있습니다. 기존 파일에 쓰기를 하기 위해 EFS는 S3를 사용하는 것보다 선호되는 옵션이기도 합니다.

자세한 내용은 AWS Lambda 함수에 Amazon EFS 공유 파일 시스템 제공 기능 출시를 참고하세요.

5. 다양한 서버리스 데이터 저장 옵션 비교

이 표에서는 Lambda 서비스에 대한 다음 네 가지 데이터 스토리지 옵션의 특성을 비교합니다.

마무리

이 글에서는 Lambda 함수에 대한 Aamazon S3 및 EFS 같은 객체 파일 스토리지, 그리고 Lambda Layer 및 임시 스토리지의 기능과 사용 사례를 비교해 보았습니다. 각 유형마다 동작과 특성이 다르기 때문에 각 접근 방식에는 이점이 있습니다. 여러분의 애플리케이션 특성에 따라 선택해서 사용하시면 좋겠습니다.

– James Beswick, AWS Serverless Developer Advocate

이 글은 AWS Compute Blog의 Choosing between AWS Lambda data storage options in web apps 한국어 번역입니다.