Serverless Architecture

Serverless Architecture

Serverless Architecture(서버리스 아키텍처) 는 개발자가 서버 인프라를 직접 관리하지 않고, 클라우드 서비스 제공자가 컴퓨팅 리소스의 프로비저닝, 확장, 운영을 자동으로 처리하는 현대적 아키텍처 스타일이다. 대표적으로 Function as a Service(FaaS, 함수형 서비스) 와 Backend as a Service(BaaS, 백엔드 서비스) 가 있으며, 이벤트 기반 트리거, 자동 확장, 사용량 기반 과금, 빠른 배포와 높은 확장성을 특징으로 한다. 이로 인해 개발자는 비즈니스 로직 구현에 집중할 수 있다.

핵심 개념

Serverless Architecture(서버리스 아키텍처) 는 서버 인프라 관리 없이, 클라우드 서비스 제공자가 모든 인프라 운영을 책임지고, 개발자는 코드 (주로 함수 단위) 만 작성하여 배포하는 아키텍처 스타일이다.

기본 개념

서버리스 컴퓨팅 (Serverless Computing)

• 클라우드 제공업체가 서버 인프라를 완전히 관리하는 실행 모델
• 개발자는 서버 프로비저닝, 확장, 유지보수에서 해방됨
• " 서버가 없다 " 는 의미가 아니라 " 서버 관리가 없다 " 는 의미
• 종류:
  • Function as a Service (FaaS): 이벤트 trigger 로 코드를 실행, 클라우드 제공
  • Backend as a Service (BaaS): 인증, DB, 메시징 등 관리형 서비스 활용

이벤트 기반 아키텍처 (Event-Driven Architecture)

• 특정 이벤트나 트리거에 의해 함수가 실행되는 방식
• HTTP 요청, 데이터베이스 변경, 파일 업로드 등이 이벤트 소스가 됨
• 비동기적이고 반응형 시스템 구조

무상태성 (Statelessness)

• 함수 간 상태 정보를 공유하지 않는 설계 원칙
• 각 함수 실행은 독립적이며 이전 실행과 무관
• 외부 저장소를 통해 상태 관리 필요

심화 개념

자동 확장성 (Auto Scaling)

• 요청량에 따라 자동으로 리소스를 확장하거나 축소
• 제로 스케일링 (Zero Scaling) 지원으로 비용 최적화
• 트래픽 급증 시 즉시 대응 가능

사용량 기반 과금 (Pay-per-Use)

• 실제 코드 실행 시간에 대해서만 과금
• 유휴 시간에 대한 비용 부담 없음
• 예측 불가능한 워크로드에 대한 비용 효율성

실무 구현 연관성

아키텍처 설계 측면

• 마이크로서비스 아키텍처와의 자연스러운 결합
• API 우선 설계 (API-First Design) 접근법 활용
• 이벤트 소싱 (Event Sourcing) 패턴 적용

개발 프로세스 측면

• CI/CD 파이프라인과의 긴밀한 통합
• Infrastructure as Code (IaC) 활용 필수
• 모니터링 및 관찰성 (Observability) 강화 필요

운영 관리 측면

• DevOps 문화와의 시너지 효과
• 분산 시스템 관리 복잡성 증가
• 보안 모델의 변화 (제로 트러스트 보안)

배경

서버리스 아키텍처의 등장 배경은 전통적인 서버 관리의 복잡성과 비효율성에서 시작된다. 2014 년 아마존이 AWS Lambda 를 출시하면서 Function as a Service (FaaS) 의 개념이 본격적으로 도입되었다. 이전에는 개발팀이 하드웨어 프로비저닝, 운영체제 관리, 보안 업데이트, 백업 등 인프라 관련 업무에 상당한 시간과 자원을 투입해야 했다.

목적 및 필요성

주요 목적

• 인프라 관리 복잡성 제거를 통한 개발 생산성 향상
• 비용 효율성 증대를 통한 운영비 절감
• 자동 확장성을 통한 안정적인 서비스 제공
• 빠른 출시 시간 (Time-to-Market) 단축

필요성

• 급변하는 비즈니스 요구사항에 대한 민첩한 대응
• 예측 불가능한 트래픽 패턴에 대한 효과적인 대응
• 개발 리소스의 핵심 업무 집중 필요성
• 스타트업과 중소기업의 인프라 비용 부담 해결

주요 기능 및 역할

• 이벤트 처리 (Event Processing)
  • HTTP 요청, 데이터베이스 트리거, 파일 업로드 등 다양한 이벤트 처리
  • 실시간 데이터 스트림 처리
  • 스케줄링된 작업 실행
• API 엔드포인트 제공
  • RESTful API 및 GraphQL API 구현
  • 마이크로서비스 간 통신 지원
  • 써드파티 서비스 통합
• 데이터 처리 및 변환
  • 실시간 데이터 분석 및 변환
  • 이미지/비디오 처리
  • 로그 분석 및 집계

특징

• 동적 확장성 (Dynamic Scalability):
  서버리스 함수는 요청량에 따라 자동으로 확장되며, 트래픽이 없을 때는 제로 스케일링을 통해 리소스를 완전히 해제한다.
• 이벤트 기반 실행 (Event-Driven Execution):
  함수는 특정 이벤트가 발생했을 때만 실행되며, 이벤트가 없으면 비활성 상태를 유지한다.
• 단기 실행 (Short-Lived Execution):
  대부분의 서버리스 플랫폼은 함수 실행 시간에 제한을 두어 (예: AWS Lambda 15 분) 단기 실행에 최적화되어 있다.
• 관리형 인프라 (Managed Infrastructure):
  모든 인프라 관리는 클라우드 제공업체가 담당하며, 개발자는 코드 작성에만 집중할 수 있다.

핵심 원칙

• 단일 책임 원칙 (Single Responsibility Principle):
  각 함수는 하나의 명확한 기능만을 수행해야 하며, 복잡한 로직은 여러 함수로 분리한다.
• 무상태 설계 (Stateless Design):
  함수 간에는 상태를 공유하지 않으며, 필요한 상태는 외부 저장소를 통해 관리한다.
• 멱등성 (Idempotency):
  동일한 입력에 대해 여러 번 실행해도 같은 결과를 보장해야 한다.
• 장애 복원력 (Fault Tolerance):
  개별 함수의 장애가 전체 시스템에 영향을 주지 않도록 설계한다.

주요 원리

이벤트 기반 처리 원리

graph TD
    A[이벤트 발생] --> B[이벤트 라우팅]
    B --> C[함수 트리거]
    C --> D[리소스 할당]
    D --> E[함수 실행]
    E --> F[결과 반환]
    F --> G[리소스 해제]

이벤트가 발생하면 클라우드 플랫폼이 해당 이벤트를 적절한 함수로 라우팅하고, 필요한 컴퓨팅 리소스를 동적으로 할당하여 함수를 실행한 후 결과를 반환하고 리소스를 해제한다.

자동 확장 원리

graph LR
    A[트래픽 증가] --> B[새 인스턴스 생성]
    B --> C[로드 분산]
    C --> D[병렬 처리]
    D --> E[트래픽 감소]
    E --> F[인스턴스 해제]

트래픽이 증가하면 플랫폼이 자동으로 새로운 함수 인스턴스를 생성하여 로드를 분산시키고, 트래픽이 감소하면 불필요한 인스턴스를 해제한다.

작동 원리 및 방식

함수 라이프사이클

sequenceDiagram
    participant C as Client
    participant G as API Gateway
    participant P as Platform
    participant F as Function
    participant S as Storage

    C->>G: HTTP Request
    G->>P: Route Request
    P->>P: Cold/Warm Start Check
    alt Cold Start
        P->>P: Initialize Runtime
        P->>F: Load Function Code
    end
    P->>F: Execute Function
    F->>S: Access External Data
    S->>F: Return Data
    F->>P: Return Result
    P->>G: Response
    G->>C: HTTP Response

클라이언트 요청이 API Gateway 를 통해 들어오면, 플랫폼은 함수가 이미 실행 중인지 (Warm Start) 또는 새로 시작해야 하는지 (Cold Start) 를 확인한다. Cold Start 의 경우 런타임 환경을 초기화하고 함수 코드를 로드한 후 실행한다.

구조 및 아키텍처

서버리스 아키텍처는 여러 핵심 구성 요소들이 유기적으로 결합된 형태이다. 각 요소는 자동 확장, 무상태, 종량 과금이라는 Serverless 핵심 원칙과 연관되며, 이벤트 기반 호출 흐름을 지원한다.

graph TB
    subgraph "Client Layer"
        A[Web Client]
        B[Mobile Client]
        C[IoT Device]
    end
    
    subgraph "API Layer"
        D[API Gateway]
        E[Load Balancer]
    end
    
    subgraph "Function Layer (FaaS)"
        F[Authentication Function]
        G[Business Logic Function]
        H[Data Processing Function]
    end
    
    subgraph "Backend Services (BaaS)"
        I[Database]
        J[Object Storage]
        K[Message Queue]
        L[Third-party APIs]
    end
    
    subgraph "Event Sources"
        M[HTTP Events]
        N[Database Events]
        O[File Events]
        P[Schedule Events]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    D --> G
    D --> H
    F --> I
    G --> I
    G --> J
    H --> K
    H --> L
    M --> F
    N --> G
    O --> H
    P --> H

구성요소

구현 기법

추가 구현 기법 및 고급 패턴

장점

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

분류 기준별 유형

실무 사용 예시

활용 사례

사례 1: 넷플릭스의 동영상 인코딩 시스템

넷플릭스는 서버리스 아키텍처를 활용하여 대용량 동영상 콘텐츠의 인코딩과 배포 시스템을 구축했다.

시스템 구성:

graph TB
    A[콘텐츠 업로드] --> B[S3 저장소]
    B --> C[Lambda 트리거]
    C --> D[동영상 분할]
    D --> E[병렬 인코딩]
    E --> F[품질별 변환]
    F --> G[CDN 배포]
    G --> H[사용자 스트리밍]

워크플로우:

1. 콘텐츠 제작팀이 원본 동영상을 S3 에 업로드
2. S3 이벤트가 Lambda 함수를 트리거
3. Lambda 함수가 동영상을 5 분 단위로 분할
4. 각 세그먼트를 60 개의 병렬 스트림으로 인코딩
5. 다양한 해상도와 품질로 변환
6. CloudFront CDN 을 통해 전 세계 배포

서버리스 아키텍처의 역할:

• 자동 확장: 업로드 volume 에 따라 자동으로 처리 능력 조절
• 비용 최적화: 실제 인코딩 시간에 대해서만 과금
• 병렬 처리: 동시에 수백 개의 인코딩 작업 실행
• 내결함성: 개별 세그먼트 처리 실패가 전체에 미치는 영향 최소화

서버리스 적용 전후 차이점:

• 적용 전 (전통적 서버 기반):
  • 24/7 실행되는 인코딩 서버 클러스터 필요
  • 피크 시간 대비 과도한 리소스 프로비저닝
  • 서버 관리, 패치, 모니터링 등 운영 부담
  • 장애 시 전체 시스템 영향
• 적용 후 (서버리스 기반):
  • 필요 시에만 리소스 사용
  • 자동 확장으로 처리량 최적화
  • 인프라 관리 부담 제거
  • 개별 함수 장애가 전체에 미치는 영향 최소화

사례 2: 이미지 처리 파이프라인

시스템 구성: S3(스토리지), Lambda(함수), DynamoDB(메타데이터 저장)

Workflow: 이미지 업로드 → S3 이벤트 → Lambda 실행 → 이미지 변환/저장 → DynamoDB 기록
다이어그램:

sequenceDiagram
    participant User
    participant S3
    participant Lambda
    participant DynamoDB

    User->>S3: 이미지 업로드
    S3->>Lambda: 이벤트 트리거
    Lambda->>S3: 이미지 처리/저장
    Lambda->>DynamoDB: 메타데이터 기록

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

반드시 학습해야할 내용

용어 정리

참고 및 출처

• AWS Lambda 공식 문서
• Azure Functions 개요
• Google Cloud Functions 문서
• Martin Fowler의 Serverless 아키텍처 분석
• 서버리스 아키텍처 2024년 트렌드 분석
• Datadog 서버리스 모니터링 가이드
• GeeksforGeeks: Serverless Computing의 미래 전망