cd

Serverless Architecture

7 min read

1️. 모바일 애플리케이션 시나리오 – MyTodoList

요구사항

  • REST API + HTTPS
  • Serverless 아키텍처
  • 사용자가 자신의 S3 폴더에 직접 접근
  • 관리형 Serverless 인증 서비스 사용
  • To-do 읽기 위주, 쓰기는 상대적으로 적음
  • 확장 가능한 DB, 높은 읽기 처리량

2️. 모바일 앱 – REST API 레이어

구성

Mobile Client
 └─ API Gateway (HTTPS)
     ├─ Cognito (Authenticate)
     └─ Lambda
         └─ DynamoDB
  • API Gateway: HTTPS 엔드포인트
  • Cognito: 사용자 인증
  • Lambda: 비즈니스 로직
  • DynamoDB: To-do 데이터 저장

3️. 모바일 앱 – S3 직접 접근 권한 부여

구조

MobileClient
 ├─ API Gateway
 ├─Cognito (인증)
 └─ Amazon S3
     └─ 사용자 전용 폴더
  • Cognito를 통해 제한된 권한의 임시 자격증명 발급
  • 앱 사용자가 S3에 직접 파일 업로드/다운로드
  • 서버를 경유하지 않아 성능·비용 최적화

4️. 모바일 앱 – 높은 읽기 처리량 대응

DynamoDB + DAX

Lambda
 └─ DynamoDB
     └─ DAX (캐싱 레이어)
  • 읽기 위주 워크로드 최적화
  • 마이크로초 단위 응답
  • DB 부하 감소

5️. 모바일 앱 – API Gateway 캐싱

API 레벨 캐시

Client
 └─ APIGateway(Response Cache)
     └─ Lambda
         └─ DynamoDB / DAX
  • 동일 요청에 대한 응답 캐싱
  • Lambda 호출 감소
  • 전체 API 비용 절감

6️. 모바일 앱 아키텍처 핵심

이 아키텍처에서 다루는 핵심 패턴

  • Serverless REST API (API Gateway + Lambda + DynamoDB)
  • Cognito 기반 인증 & 임시 자격증명
  • S3 직접 접근 패턴
  • DynamoDB DAX 캐싱
  • API Gateway 응답 캐싱
  • 인증·인가 보안 구조

7️. Serverless 호스팅 웹사이트 시나리오 – MyBlog.com

요구사항

  • 글로벌 확장
  • 게시글은 쓰기 적음 / 읽기 많음
  • 정적 콘텐츠 + 동적 REST API
  • 가능한 곳은 모두 캐싱
  • 신규 구독자 웰컴 이메일
  • 이미지 업로드 시 썸네일 자동 생성

8️. 정적 콘텐츠 글로벌 배포

구조

Client
 └─ CloudFront (Global)
     └─ Amazon S3 (Static Files)
  • CloudFront 엣지 로케이션에서 콘텐츠 제공
  • 전 세계 사용자에게 낮은 지연 시간

9️. 정적 콘텐츠 보안 – OAC

Origin Access Control

CloudFront
 └─ S3 Bucket
     └─ BucketPolicy(CloudFront만 허용)
  • S3 직접 접근 차단
  • CloudFront를 통해서만 접근 허용

10. 공개 Serverless REST API 추가

구조

Client
 └─ CloudFront
     └─ API Gateway
         └─ Lambda
             └─ DynamoDB
                 └─ DAX
  • REST API는 Serverless
  • 인증 필요 없는 공개 API
  • 읽기 성능을 위해 DAX 사용

1️1. DynamoDB Global Tables 활용

글로벌 데이터 접근

Multiple Regions
 └─ DynamoDBGlobalTables
     └─ Active-ActiveReplication
  • 전 세계에서 낮은 지연 시간
  • 양방향 읽기/쓰기
  • CloudFront + API Gateway와 궁합 좋음

1️2. 사용자 웰컴 이메일 흐름

이벤트 기반 이메일 발송

DynamoDB
 └─ Streams
     └─ Lambda
         └─ Amazon SES
  • 사용자 생성 이벤트 감지
  • Lambda가 자동으로 이메일 발송
  • IAM Role로 SES 사용 권한 제어

1️3. 썸네일 생성 플로우

이미지 업로드 후 처리

Client
 └─S3(Upload)
     └─EventTrigger
         ├─Lambda(Thumbnail)
         ├─SQS/SNS(Optional)
         └─S3(Thumbnail 저장)
  • S3 이벤트 기반 처리
  • 비동기 확장 가능 (SQS / SNS)

1️4. AWS 호스티드 웹사이트 요약

  • CloudFront + S3로 정적 콘텐츠 글로벌 배포
  • Serverless REST API
  • DynamoDB Global Tables
  • DynamoDB Streams + Lambda
  • SES로 이메일 발송
  • S3 이벤트 트리거 활용

1️5. 마이크로서비스 아키텍처 전환 배경

목표

  • 서비스 단위 독립 개발
  • 빠른 배포 주기
  • 각 서비스의 유연한 아키텍처 선택

1️6. 마이크로서비스 환경 예시

구성

Users
 └─ Route 53
     ├─ service1.example.com
     ├─ service2.example.com
     └─ service3.example.com

각 서비스 내부는 다음 중 선택 가능:

  • API Gateway + Lambda
  • ALB + EC2
  • ECS
  • DynamoDB / RDS
  • ElastiCache

1️7. 마이크로서비스 통신 패턴

동기식

  • API Gateway
  • Load Balancer

비동기식

  • SQS
  • SNS
  • Kinesis
  • S3 이벤트
  • Lambda 트리거

1️8. 마이크로서비스의 도전 과제

  • 서비스 수 증가에 따른 오버헤드
  • 서버 밀도 / 자원 활용 최적화 어려움
  • 다중 버전 공존의 복잡성
  • 클라이언트 코드 복잡도 증가

1️9. Serverless가 해결하는 부분

  • 자동 확장
  • 사용량 기반 과금
  • API 복제 및 환경 분리 용이
  • Swagger 기반 SDK 자동 생성

2️0. 소프트웨어 업데이트 오프로딩 문제

기존 상황

  • EC2 기반 애플리케이션
  • 업데이트 시 트래픽 폭증
  • CPU / 네트워크 비용 증가
  • 구조 변경은 원하지 않음

2️1. 기존 아키텍처

EC2 Auto ScalingGroup
 └─ EFS
     └─ SoftwareUpdate Files
  • 모든 요청이 EC2로 집중

2️2. 해결책 – CloudFront 추가

개선 구조

Client
 └─ CloudFront
     └─ EFS / EC2 Origin

CloudFront를 사용하는 이유

  • 아키텍처 변경 최소
  • 정적 파일을 엣지에 캐싱
  • EC2 스케일링 감소
  • 네트워크 비용 절감
  • 가용성 향상

기존 애플리케이션 위에 Serverless 구성 요소를 얹어 비용·확장성·가용성을 개선하는 대표적인 패턴

그래프 뷰

백링크