🖥️ System

서버리스 메모리 (Serverless Memory)

개요

서버리스 컴퓨팅 환경에서 메모리 관리는 기존 인프라와 근본적으로 다른 특성을 가집니다. 전통적인 서버 환경에서는 OS 수준에서 메모리를 직접 관리하지만, 서버리스 환경에서는 클라우드 제공자가 함수별 메모리 할당, 리소스 격리, 동적 스케일링을 관리합니다. AWS Lambda의 경우 128MB에서 10,240MB까지 메모리를 설정할 수 있으며, CPU 전력은 메모리에 비례하여 자동으로 할당됩니다.

서버리스 메모리 관리의 핵심은 제한된 리소스 내에서 최적의 성능을 달성하는 것입니다. 함수 실행 시간, 메모리 사용량, 임시 저장소 요구사항을 고려한 적절한 설정이 필요하며, 잘못된 설정은 성능 저하나 비용 증가로 이어질 수 있습니다. 또한 Lambda 실행 환경은 warm start 시 이전 초기화 결과와 /tmp 데이터를 일부 재사용할 수 있으므로, 단순 용량뿐 아니라 초기화 비용과 캐시 전략까지 함께 설계해야 합니다. 본 문서에서는 서버리스 환경의 메모리 아키텍처, 할당 메커니즘, 최적화 기법을 분석합니다.

그림 1. 서버리스 환경의 메모리 할당 및 관리 아키텍처

핵심 개념

함수 메모리 할당

AWS Lambda 함수는 실행 시 메모리를 할당받으며, 이 메모리는 함수의 CPU, 네트워크, I/O 성능에 직접적인 영향을 미칩니다.

메모리 할당 특징:
- 범위: 128MB ~ 10,240MB (1MB 단위 조정 가능)
- CPU 비례 할당: 1,769MB당 1 vCPU 할당
- 리소스 격리: 각 함수 실행 환경은 독립된 메모리 공간 사용
- 동적 조정: 함수 배포 시 메모리 설정 변경 가능

메모리와 CPU 관계:

메모리 설정	CPU 할당	vCPU 등가
128MB	0.072 vCPU	경량 처리
512MB	0.289 vCPU	일반적인 워크로드
1,769MB	1.0 vCPU	CPU 집약적 처리
3,538MB	2.0 vCPU	고성능 처리
10,240MB	5.79 vCPU	최대 리소스

임시 저장소 (Ephemeral Storage)

Lambda 함수는 /tmp 디렉토리에 임시 저장소를 제공하며, 각 실행 환경마다 독립적으로 할당됩니다.

임시 저장소 특징:
- 기본 용량: 512MB (무료)
- 최대 용량: 10,240MB (추가 과금)
- 데이터 암호화: AWS 관리 키로 암호화
- 실행 환경별 격리: 각 함수 인스턴스마다 독립된 저장소

사용 사례:
- ETL 작업: 중간 처리 데이터 저장
- ML 추론: 모델 파일 및 참조 데이터 로드
- 데이터 처리: 대용량 파일 처리 시 임시 버퍼
- 이미지 처리: 대형 이미지 파일 조작

콜드 스타트와 메모리

서버리스 함수의 콜드 스타트는 메모리 할당과 밀접한 관련이 있습니다.

콜드 스타트 영향 요인:
- 함수 패키지 크기: 런타임, 라이브러리, 의존성 포함
- 메모리 할당량: 더 많은 메모리는 더 빠른 초기화 가능
- VPC 연결: VPC 내 함수는 추가 초기화 시간 발생
- 초기 설정: 외부 서비스 연결, 데이터베이스 연결 풀

콜드 스타트 최적화:
- 함수 패키지 크기 최소화
- Provisioned Concurrency 활용
- SnapStart 적용 (Java 런타임)
- 의존성 캐싱 및 재사용

실행 환경 재사용과 캐시

Lambda는 호출이 끝난 실행 환경을 즉시 폐기하지 않고 일정 시간 유지할 수 있습니다. 같은 함수가 다시 호출되면 초기화가 끝난 런타임, 핸들러 바깥에서 생성한 객체, /tmp의 임시 파일을 재사용하는 warm start가 발생할 수 있습니다.

다만 이 재사용은 보장되지 않으며, 동시성 증가나 런타임 업데이트, 오류에 따른 환경 재생성 시에는 새 실행 환경이 만들어집니다. 따라서 캐시는 성능 최적화 수단으로만 사용하고, 정합성이 필요한 상태는 S3, DynamoDB, ElastiCache 같은 외부 저장소에 둬야 합니다.

비교/분석

서버리스 vs 전통적 메모리 관리

특성	전통적 인프라	서버리스 (Lambda)
메모리 관리	OS 수준 직접 관리	클라우드 제공자 관리
할당 단위	프로세스/컨테이너	함수 단위
스케일링	수동 또는 자동 설정	완전 자동 스케일링
과금 모델	시간/월 과금	실행 시간 + 메모리 과금
메모리 제한	하드웨어 제한	함수당 최대 10GB
상태 관리	가능	무상태 권장
리소스 격리	컨테이너/VM 격리	함수 실행 환경 격리

서버리스 저장 위치 비교

위치	용도	장점	주의점
메모리(heap)	요청 처리 중 활성 데이터	가장 빠른 접근	메모리 부족 시 OOM, 호출 종료 시 유지 불가
`/tmp`	모델, 중간 파일, 압축 해제 결과	warm start에서 재사용 가능, 메모리보다 저렴	실행 환경 종료 시 사라지며 인스턴스 간 공유 불가
Amazon EFS	공유 파일, 대형 모델, 공통 데이터	여러 인스턴스 간 공유 가능	네트워크 지연, 마운트 비용 고려 필요
S3/DynamoDB	영속 상태, 결과 저장	내구성, 확장성 우수	직접 메모리처럼 접근할 수 없어 지연 증가

메모리 할당 전략 비교

전략	설명	장점	단점
최소 메모리 (128MB)	기본 설정 유지	최저 비용	성능 제한적
워크로드 기반	사용 패턴 분석 후 설정	최적 비용/성능	초기 분석 필요
프로비저닝	미리 리소스 할당	일관된 성능	높은 비용
동적 조정	모니터링 기반 실시간 조정	최적화된 성능	구현 복잡도

비용 최적화 기법

1. 메모리 사용량 모니터링
- CloudWatch 메트릭스 활용
- 메모리 사용률 기반 알림 설정
- 사용 패턴 분석을 통한 적정 용량 결정

2. Lambda Power Tuning
- open source 도구 활용
- 다양한 메모리 레벨에서 성능 측정
- 비용 대비 최적점 결정

3. Provisioned Concurrency 활용
- 일정한 트래픽 패턴에서 콜드 스타트 제거
- 높은 트래픽 애플리케이션에 적합
- 비용/성능 트레이드오프 필요

동작 원리

메모리 할당 메커니즘

Lambda 함수가 호출되면 다음 과정을 통해 메모리가 할당됩니다:

함수 호출: 이벤트 트리거에 의해 함수 실행 시작
Init 단계: 확장(extensions) 시작, 런타임 부트스트랩, 정적 초기화 수행
실행 환경 생성: 격리된 실행 환경에 메모리와 임시 저장소 연결
메모리 할당: 설정된 메모리 양만큼 런타임에 할당
CPU 비례 할당: 메모리 양에 따라 CPU 리소스 자동 배분
함수 실행: 할당된 리소스 내에서 코드 실행
Freeze 또는 종료: 후속 호출이 있으면 환경을 얼려 재사용하고, 아니면 리소스를 회수

임시 저장소 동작

함수 실행 중 임시 저장소는 다음과 같이 동작합니다:

저장소 마운트: 함수 시작 시 /tmp 디렉토리 마운트
데이터 쓰기: 함수 실행 중 임시 데이터 저장
데이터 읽기: 저장된 데이터 참조 및 처리
환경 재사용 시 유지: warm start에서는 이전 /tmp 데이터가 남아 캐시로 활용 가능
환경 종료 시 삭제: 실행 환경이 폐기되면 /tmp 데이터도 함께 사라짐

메모리 회수 및 가비지 컬렉션

서버리스 환경에서는 자동으로 메모리가 회수됩니다:

함수 실행 종료: 실행이 끝나면 즉시 재사용 가능한 상태로 freeze 되거나 회수됨
타임아웃: 설정된 시간 초과 시 강제 종료 및 메모리 해제
오류 처리: 함수 오류 시에도 리소스 자동 해제
스케일 다운: 트래픽 감소 시 인스턴스 수 줄이기

장단점

장점

인프라 운영 부담 해소: 메모리 관리, 패치, 업데이트를 클라우드 제공자가 담당
자동 스케일링: 트래픽 변화에 따라 자동으로 리소스 조정
비용 효율성: 사용한 만큼만 비용 지불, 유휴 리소스 비용 없음
간단한 배포: 코드 업로드만으로 배포 완료
높은 가용성: 클라우드 제공자의 인프라를 활용한 높은 가용성

단점

콜드 스타트 지연: 첫 번째 요청 시 초기화 시간 발생
실행 시간 제한: AWS Lambda의 경우 최대 15분
메모리 제한: 함수당 최대 10GB로 제한
상태 관리 어려움: 무상태 설계가 권장되므로 상태 유지가 복잡
벤더 종속: 특정 클라우드 제공자 기능에 구조가 묶일 수 있음