서버리스 시스템 (Serverless System)

개요

서버리스 컴퓨팅은 클라우드 제공자가 하드웨어 및 소프트웨어 리소스의 프로비저닝, 배포, 관리를 고객이 수행하지 않도록 하는 클라우드 서비스 카테고리입니다. ISO/IEC 22123-2에 따르면, 서버리스 컴퓨팅은 가상화된 컴퓨팅의 한 형태로, 고객이 애플리케이션 코드나 데이터만 제공하면 됩니다. "서버리스"라는 용어는 서버가 존재하지 않는다는 의미가 아니라, 개발자가 서버 인프라를 직접 관리할 필요가 없음을 의미합니다.

서버리스 컴퓨팅은 단순한 기술이 아닌 아키텍처 패러다임으로, 기능 모듈화, 이벤트 기반 실행, 자동 스케일링을 통해 인프라 운영 부담을 클라우드 제공자에게 이전합니다. 이를 통해 개발자는 비즈니스 로직에만 집중할 수 있으며, 사용한 리소스만큼만 비용을 지불하는 과금 모델을 활용할 수 있습니다. 그러나 서버리스는 복잡성을 완전히 제거하는 것이 아니라, 운영 팀에서 개발 팀으로 이전하는 것이며, IAM, 네트워킹, 보안 정책, 비용 최적화 측면에서 여전히 관리가 필요합니다.

핵심 개념

FaaS (Function as a Service)

FaaS는 서버리스 컴퓨팅의 핵심 컴퓨팅 모델로, 개발자가 함수 단위로 코드를 배포하고 실행할 수 있는 플랫폼을 제공합니다. 대표적인 서비스로 AWS Lambda, Azure Functions, Google Cloud Functions, OpenFaaS 등이 있습니다.

FaaS의 주요 특징:
- 이벤트 기반 실행: HTTP 요청, 데이터베이스 변경, 메시지 큐 이벤트 등 다양한 트리거에 의해 함수가 실행됩니다.
- 자동 스케일링: 트래픽에 따라 자동으로 인스턴스 수를 조정하며, 트래픽이 없을 때는 스케일 다운됩니다.
- 과금 모델: 실행 시간과 리소스 사용량에 따라 과금되므로, 유휴 상태에서는 비용이 발생하지 않습니다.
- 무상태(Stateless): 각 함수 호출은 독립적으로 실행되며, 상태를 유지하지 않습니다.

FaaS 플랫폼 비교:

BaaS (Backend as a Service)

BaaS는 서버리스 아키텍처에서 백엔드 인프라를 관리하는 서비스로, 인증, 데이터베이스, 스토리지, 푸시 알림 등 공통 백엔드 기능을 Managed Service로 제공합니다.

주요 BaaS 서비스:
- 인증: AWS Cognito, Firebase Authentication, Auth0
- 데이터베이스: AWS DynamoDB, Firestore, Azure Cosmos DB
- 스토리지: AWS S3, Azure Blob Storage, Google Cloud Storage
- 메시징: AWS SNS/SQS, Azure Service Bus, Google Pub/Sub

상태 외부화와 관리형 통합

서버리스 함수는 기본적으로 무상태 실행을 전제로 하므로, 세션 상태, 워크플로우 진행 상태, 캐시, 장기 저장 데이터는 외부 서비스에 둬야 한다. 이때 상태 저장소를 어떻게 선택하느냐가 서버리스의 확장성과 복원력을 좌우한다.

• 짧은 상태: Redis, DynamoDB TTL, Firestore 같은 저지연 키-값 저장소에 보관
• 워크플로우 상태: Step Functions, Durable Functions처럼 상태 머신을 제공하는 오케스트레이터 사용
• 대용량 객체: S3, Blob Storage, GCS처럼 객체 스토리지에 저장
• 비동기 버퍼링: SQS, Service Bus, Pub/Sub로 급격한 트래픽 증가를 흡수

이벤트 기반 아키텍처

서버리스 시스템은 이벤트 기반 아키텍처를 기반으로 동작합니다. 이벤트는 시스템 상태의 변화를 나타내며, 이를 트리거로 함수가 실행됩니다.

이벤트 유형:
- 동기 이벤트: HTTP API 요청, 직접 함수 호출
- 비동기 이벤트: 메시지 큐, 이벤트 스트림, 파일 업로드
- 스케줄 이벤트: Cron 표현식 기반 정기 실행

자동 스케일링 및 스케일 to/from Zero

서버리스 시스템의 핵심 장점 중 하나는 자동 스케일링입니다. 트래픽이 증가하면 자동으로 인스턴스를 추가하고, 트래픽이 줄면 인스턴스를 제거합니다. 특히 스케일 to zero는 트래픽이 없을 때 모든 인스턴스를 제거하여 비용을 절감할 수 있습니다.

스케일링 동작:
- Cold Start: 첫 번째 요청 시 함수 인스턴스를 초기화하는 과정으로, 지연 시간이 발생할 수 있습니다.
- Warm Start: 기존 인스턴스를 재사용하여 빠른 응답을 보장합니다.
- Concurrency Limit: 계정/리전별 동시 실행 제한이 있으며, 이를 초과하면 요청이 대기됩니다.
- 예약/사전 준비 인스턴스: AWS Provisioned Concurrency, Azure Premium/Flex Consumption의 always-ready 인스턴스처럼 미리 준비된 실행 환경으로 지연 시간을 줄일 수 있습니다.

비교/분석

기존 인프라 모델과의 비교

서버리스 아키텍처 패턴

1. 마이크로서비스 패턴
- 각 기능을 독립적인 함수로 구현
- 서비스 간 통신은 API Gateway, 이벤트 스트림 등으로 수행
- 각 서비스를 독립적으로 배포 및 스케일링

2. 이벤트 드리븐 패턴
- 시스템 간 비동기 통신을 이벤트로 수행
- 느슨한 결합을 통한 유연한 아키텍처
- 장애 격리 및 복원력 향상

3. API Gateway 패턴
- 클라이언트 요청을 함수로 라우팅
- 인증, 인가, 레이트 리미팅 관리
- REST API, WebSocket API 지원

4. 파이프라인/워크플로우 패턴
- 여러 함수를 순차적으로 연결하여 복잡한 처리 수행
- AWS Step Functions, Azure Durable Functions 등으로 구현
- 상태 관리 및 에러 핸들링 제공

워크로드 적합성 비교

동작 원리

함수 실행 흐름

1. 트리거 이벤트 수신: 클라이언트 요청, 메시지 큐, 스케줄 등에서 이벤트가 발생합니다.
2. 함수 라우팅: 이벤트 소스에 해당하는 함수가 선택됩니다.
3. 인스턴스 할당: 기존 Warm 인스턴스가 있으면 재사용하고, 없으면 Cold Start를 통해 새 인스턴스를 생성합니다.
4. 함수 실행: 함수 코드가 실행되고, 필요시 외부 서비스와 통신합니다.
5. 응답 반환: 함수 실행 결과가 이벤트 소스로 반환됩니다.
6. 인스턴스 정리: 유휴 상태가 되면 인스턴스가 종료됩니다 (스케일 to zero).

Cold Start 최적화

Cold Start는 서버리스 시스템의 주요 과제로, 이를 최적화하는 방법들이 있습니다:

• 런타임 최적화: 경량 런타임 사용 (Node.js, Python 등)
• 의존성 최소화: 불필요한 라이브러리 제거
• 사전 준비 인스턴스(Provisioned Concurrency): 미리 인스턴스를 준비하여 Cold Start를 줄임
• Lambda SnapStart: JVM 기반 함수의 시작 시간 최적화

Cold Start는 단순히 함수 코드만의 문제가 아니라 네트워크 연결, VPC ENI 준비, 런타임 부팅, 비밀 정보 로딩, 대형 SDK 초기화가 합쳐진 결과다. 따라서 실제 튜닝은 패키지 크기 축소, 연결 재사용, 초기화 코드 분리, 워크로드별 메모리 조정, 항상 준비된 인스턴스 사용 여부를 함께 검토해야 한다.

메모리 및 리소스 관리

서버리스 함수는 메모리 할당에 따라 CPU 리소스가 자동으로 조정됩니다. 메모리를 더 많이 할당하면 더 많은 CPU를 사용할 수 있습니다.

메모리-CPU 관계 (AWS Lambda 기준):
- 128MB ~ 3008MB: 1 vCPU의 비례적 할당
- 3008MB 초과: 전체 vCPU 할당

비용 최적화 전략:
- 함수별 적정 메모리 크기 결정 (벤치마킹 필요)
- 메모리 사용량 모니터링 및 조정
- 비동기 처리를 통한 실행 시간 최적화

실패 처리와 관측성

서버리스 시스템에서는 인스턴스 내부에 상태를 오래 유지할 수 없으므로, 실패 처리와 관측성을 플랫폼 수준에서 설계해야 한다. 동기 호출은 빠른 오류 반환과 타임아웃 제어가 중요하고, 비동기 호출은 재시도 정책, dead-letter queue, idempotency key가 중요하다.

1. 재시도 정책: 일시적 실패는 지수 백오프로 재시도하되, 무한 재시도로 중복 비용이 커지지 않도록 제한한다.
2. 멱등성 보장: 같은 이벤트가 두 번 도착해도 결과가 한 번만 반영되도록 키나 버전 검사를 둔다.
3. 분산 추적: API Gateway, 함수, 데이터베이스, 큐를 trace ID로 연결해 병목 구간을 찾는다.
4. 로그 구조화: 함수별 로그 형식을 통일해 검색성과 알림 정확도를 높인다.
5. 지표 수집: 호출 수, 오류율, p95 지연시간, 동시성, DLQ 적재량을 함께 본다.

장단점

장점

1. 운영 부담 감소: 서버 인프라 관리가 불필요하여 개발에 더 집중할 수 있습니다.
2. 비용 효율성: 사용한 리소스만큼만 비용을 지불하므로, 트래픽이 적을 때 비용을 절감할 수 있습니다.
3. 자동 스케일링: 트래픽 변화에 자동으로 대응하여 안정적인 서비스 제공이 가능합니다.
4. 개발 생산성: 함수 단위로 코드를 작성하고 배포할 수 있어 개발 속도가 향상됩니다.
5. 복원력: 분산 환경에서 장애가 격리되고, 자동 복구 메커니즘이 제공됩니다.

단점

1. Cold Start 지연: 첫 번째 요청 시 인스턴스 초기화로 인한 지연이 발생할 수 있습니다.
2. 벤더 종속성: 특정 클라우드 제공자에 종속될 수 있으며, 마이그레이션이 어려울 수 있습니다.
3. 실행 시간 제한: 함수 실행 시간에 제한이 있어, 장시간 실행되는 작업에는 적합하지 않습니다.
4. 디버깅 및 모니터링 어려움: 분산 환경에서 문제를 추적하고 디버깅하는 것이 복잡할 수 있습니다.
5. 상태 관리 어려움: 무상태 설계가 권장되므로, 상태를 유지해야 하는 작업은 별도의 처리가 필요합니다.
6. 보안 고려사항: 함수별 IAM 권한 관리, 의존성 보안, 데이터 암호화 등 보안 관리가 필요합니다.
7. 네트워크 제약: VPC 연결, 외부 API 호출, NAT 비용, 연결 재사용 실패가 성능과 비용에 직접 영향을 줄 수 있습니다.

관련 기술

참고 문헌 및 표준

• ISO/IEC 22123-2:2023: 클라우드 컴퓨팅 개념 정의 표준
• AWS Lambda Developer Guide: 실행 제한, 동시성, 메모리-CPU 비례 할당 문서
• Azure Functions Scale and Hosting: Flex Consumption, Premium, Always Ready 인스턴스 설명
• CNCF Serverless Landscape: 클라우드 네이티브 서버리스 기술 생태계
• OWASP Serverless Top 10: 서버리스 보안 위험 목록
• OpenFaaS: 셀프 호스팅 가능한 오픈소스 FaaS 플랫폼
• Serverless Framework: 서버리스 애플리케이션 배포 프레임워크

관련 기술

• 컨테이너 오케스트레이션: Kubernetes, Docker Swarm
• API Gateway: AWS API Gateway, Kong, NGINX
• 메시징/이벤트: Apache Kafka, RabbitMQ, AWS EventBridge
• 서버리스 데이터베이스: DynamoDB, Firestore, PlanetScale
• 서버리스 AI/ML: AWS SageMaker Serverless, Azure ML Serverless

관련 문서

• 메모리 디스에이거게이션 고도화
• 캐시 일관성 MESI/MOESI
• LLM 서빙 메모리 중심 조사

핵심 정리

서버리스 컴퓨팅은 클라우드 네이티브 애플리케이션 개발의 중요한 패러다임으로, 인프라 관리 부담을 줄이고 개발 생산성을 높이는 장점이 있습니다. FaaS와 BaaS를 통해 이벤트 기반, 자동 스케일링되는 유연한 아키텍처를 구현할 수 있으나, Cold Start, 벤더 종속성, 상태 외부화, 네트워크 비용 같은 과제도 함께 따라옵니다. 적합한 워크로드를 선별하고, 오케스트레이션, 재시도, 관측성, 사전 준비 인스턴스 같은 운영 기법을 함께 적용해야 비용 효율적이고 안정적인 시스템을 구축할 수 있습니다. 서버리스는 만능이 아닌 특정 시나리오에서 최적의 솔루션이므로, 애플리케이션 요구사항에 따라 기존 인프라, 컨테이너, 서버리스를 적절히 조합하는 것이 중요합니다.