7. AWS Lamdba(Serverless)

들어가며..

서버의 변천사

• 모놀로식 아키텍처: 모든 것을 한 곳에
  • 피해가 전체적으로 파급됨
  • 길어지는 변경 주기
• MSA
  • 하지만, MSA도 결국 모여있긴함
  • 또한, 서버를 사용해야함
    • 서버에 대해서 고민을 해야함
• Serverless 아키텍처

이제는 서버 컴퓨팅은 신경쓰지말고, 코드에만 집중할 수 있도록 하자!

AWS 서버리스 서비스 포트폴리오

Serverless 아키텍처

• 정의: 서버 없는, 이벤트 처리 방식의 검퓨팅 서비스
• 특징
  • 완전 관리형
    • 프로비저닝 없음 -> 유휴 용량 없음
    • 관리요소 없음
    • 높은 가용성
  • 개발자 생산성
    • 코드에만 집중
    • 시장에 빠른 접근
  • 지속적인 스케일링: 자동으로 스케일 업/다운

이벤트로 실행

• 직접 동기/비동기식 호출
• S3 버킷에 객체 저장
• AWS API 게이트웨이를 통한 호출

동작 원리

1. 코드 업로드
2. 이벤트 트리거 설정
3. 이벤트가 발생하면 실행이 됨

백엔드 사용 예제

 

 

AWS 람다 함수 구성

 

데모

서버리스 환경에서 뉴스 데이터를 처리하고, 이를 음성으로 변환하여 사용자에게 제공하는 시스템을 구축하는 예시

1. Client (클라이언트): 사용자나 다른 서비스에서 요청을 보냅니다.
2. Amazon API Gateway (GET 및 POST):
   • 클라이언트의 요청을 받아서 적절한 AWS Lambda 함수로 전달합니다.
   • GET 요청은 GetNews Lambda 함수로 전달되고, POST 요청은 PostNews Lambda 함수로 전달됩니다.
3. AWS Lambda:
   • GetNews Lambda: Amazon API Gateway로부터 GET 요청을 받아 Amazon DynamoDB에서 뉴스를 가져옵니다.
   • PostNews Lambda: 클라이언트의 POST 요청을 받아서 새로운 뉴스를 Amazon DynamoDB에 저장합니다.
   • ConvertAudio Lambda: DynamoDB에서 뉴스를 가져와 Amazon Polly를 통해 오디오 파일로 변환한 후, MP3 파일을 생성해 Amazon S3에 저장합니다.
4. Amazon DynamoDB: 뉴스 데이터를 저장하는 NoSQL 데이터베이스입니다. GetNews 및 PostNews Lambda 함수가 이 데이터베이스에 접근합니다.
5. Amazon SNS (Simple Notification Service):
   • PostNews Lambda 함수가 SNS로 뉴스를 게시하여 다른 서비스들이 이를 구독하고 처리할 수 있게 합니다.
   • SNS는 ConvertAudio Lambda 함수로 뉴스를 전달하여 오디오 파일로 변환하는 작업을 트리거합니다.
6. Amazon Polly: 텍스트를 음성으로 변환(TTS)하는 서비스입니다. ConvertAudio Lambda 함수가 Polly를 호출하여 뉴스를 음성으로 변환합니다.
7. Amazon S3: 변환된 오디오 파일(MP3)을 저장하는 객체 스토리지입니다.
8. IAM 역할 및 정책: 각 AWS 서비스가 필요한 권한을 가지고 상호작용할 수 있도록 IAM 정책을 설정하고, 역할을 부여합니다.

AWS SNS(Simple Notification Service)

• 여러 서비스 사이에서 메시지를 전달하는 "알림 시스템"입니다
  • 상태 변화를 알리면, 구독하고 있는 옵저버(Lambda 함수)들이 그 변화를 감지하고 작업을 수행하는 구조

 

AWS CloudFront(CDN)

CDN은 전 세계 여러 리전에 분산되어 있어요. 예를 들어, AWS의 CloudFront와 같은 CDN 서비스는 글로벌 네트워크를 통해 여러 리전에 걸쳐 있는 **엣지 로케이션(Edge Locations)**에 콘텐츠를 캐시합니다. 이를 통해 사용자는 자신과 가까운 엣지 서버에서 콘텐츠를 받아보게 되기 때문에 지연 시간이 최소화되죠.

• 목적: 전 세계에 분산된 서버들을 통해 정적 콘텐츠(이미지, HTML, CSS 등)를 사용자에게 빠르게 전달하는 것이 주된 목적입니다.
• 캐싱 범위: 전 세계에 분산된 엣지 서버에서 캐시가 이루어집니다.
• 저장 데이터: 주로 정적 콘텐츠(변경되지 않는 파일들).

 

 

전통적인 방법

이 다이어그램은 AWS 기반의 3티어 아키텍처를 보여줍니다. 이 아키텍처는 웹 애플리케이션을 배포할 때 흔히 사용되는 구조로, 각 티어(Web, App, DB)가 명확하게 분리되어 있어 확장성과 유지보수가 용이한 시스템입니다. 각 티어의 역할을 설명하겠습니다.

1. Web Tier (웹 계층):

• Content Delivery Network (CDN):
  사용자가 웹 애플리케이션에 접근할 때, CDN을 통해 콘텐츠를 전 세계에 분산 배포합니다. 사용자에게 가까운 서버에서 데이터를 제공하여 빠른 응답 시간을 보장합니다.
• Route 53:
  AWS의 DNS 서비스로, 사용자가 애플리케이션에 접속할 수 있도록 도메인 이름을 IP 주소로 변환합니다.
• Elastic Load Balancer (ELB):
  여러 웹 서버에 걸쳐 트래픽을 분산시켜 서버의 부하를 줄이고, 가용성을 높입니다. 이 웹 계층의 웹 서버로 트래픽을 전달합니다.
• S3 Bucket:
  정적 리소스(이미지, CSS, JS 파일 등) 및 백업 데이터를 저장하는 객체 스토리지입니다. 웹서버에서 정적 콘텐츠를 제공할 수 있습니다.

2. App Tier (애플리케이션 계층):

• Application Servers:
  사용자가 웹 서버를 통해 보내는 요청을 처리하는 실제 애플리케이션 로직이 위치합니다. EC2 인스턴스가 사용되며, 이 계층 역시 Elastic Load Balancer (ELB)를 통해 트래픽을 분산시킵니다. 이 계층은 여러 가용 영역(Availability Zone)에 걸쳐 분산 배치되어 있어 장애가 발생해도 고가용성을 유지할 수 있습니다.
• S3 Backup:
  백업 데이터를 저장하기 위한 용도로 S3가 사용되며, 애플리케이션 계층에서 백업이나 데이터를 저장하는 데 활용됩니다.

3. DB Tier (데이터베이스 계층):

• RDS (Relational Database Service):
  관계형 데이터베이스를 관리하는 AWS의 서비스입니다. 여기서는 여러 가용 영역에 걸쳐 분산 배치된 RDS 인스턴스가 존재합니다. 하나는 주 데이터베이스 서버(Main DB) 역할을 하고, 나머지는 보조 서버(Replication)로 동작하여 데이터를 복제하고 장애 발생 시 복구 기능을 제공합니다.
• Multi-AZ:
  RDS 서비스가 여러 가용 영역에 걸쳐 배포되어 있어, 한 가용 영역에서 장애가 발생하더라도 다른 가용 영역에서 데이터베이스가 자동으로 백업되거나 장애 복구됩니다.

주요 특성:

• 고가용성:
  여러 가용 영역(AZ)에 걸쳐 애플리케이션 서버와 데이터베이스가 분산 배치되어 있어, 특정 영역에 문제가 발생하더라도 애플리케이션이 계속 동작할 수 있습니다.
• 확장성:
  Elastic Load Balancer를 사용하여 트래픽이 늘어나면 자동으로 서버를 확장하여 부하를 분산시키고, S3나 RDS와 같은 AWS 관리 서비스를 활용해 저장소와 데이터베이스를 쉽게 확장할 수 있습니다.
• 안정성:
  데이터를 S3에 백업하고, RDS는 여러 가용 영역에 걸쳐 복제되어 데이터 손실이나 서비스 중단 가능성을 최소화합니다.

이 아키텍처는 안정성, 확장성, 고가용성을 중점으로 한 AWS 클라우드 기반의 전형적인 3티어 구조입니다.

 

이 다이어그램은 서버리스(Serverless) 아키텍처를 나타내고 있습니다. 서버리스 아키텍처는 서버를 직접 관리하지 않고, AWS의 관리형 서비스들을 사용하여 애플리케이션을 구축하는 방식입니다. 각 구성 요소는 다음과 같습니다:

1. Web Tier (웹 계층):

• CloudFront (CDN):
  사용자가 웹 애플리케이션에 접근할 때 콘텐츠를 빠르게 제공하기 위해 전 세계적으로 분산된 서버를 활용하는 콘텐츠 전송 네트워크입니다.
• S3 (Static Web Hosting):
  정적 웹사이트 호스팅을 위해 사용되는 S3 버킷입니다. HTML, CSS, JavaScript 같은 정적 파일들을 저장하고 제공하는 용도로 사용됩니다.

2. App Tier (애플리케이션 계층):

• API Gateway:
  사용자 요청을 받아서 Lambda 함수에 전달하는 역할을 합니다. HTTP 요청을 처리하고, Lambda 함수와 상호작용할 수 있는 인터페이스를 제공합니다.
• AWS Lambda:
  서버를 직접 관리할 필요 없이 애플리케이션 코드를 실행하는 서버리스 컴퓨팅 서비스입니다. API Gateway로부터 요청을 받아 처리하고, 필요한 데이터를 DynamoDB 또는 다른 서비스와 연동하여 응답을 생성합니다.

3. DB Tier (데이터베이스 계층):

• DynamoDB:
  AWS의 관리형 NoSQL 데이터베이스 서비스로, 애플리케이션에서 빠르고 확장 가능한 방식으로 데이터를 저장하고 조회할 수 있습니다. Lambda 함수에서 DynamoDB로 데이터를 저장하거나 조회하는 작업을 수행합니다.
• SQS (Simple Queue Service):
  메시지 큐잉 서비스로, Lambda 함수가 비동기 작업을 처리할 수 있도록 메시지를 큐에 저장하고, 해당 메시지를 나중에 처리하는 데 사용됩니다.

주요 특성:

• 서버리스 컴퓨팅:
  직접 서버를 관리하지 않고, Lambda와 같은 서버리스 서비스를 사용하여 애플리케이션 로직을 처리합니다. 따라서 인프라 관리를 최소화하고, 비용 효율성을 높입니다.
• 확장성:
  Lambda 함수와 DynamoDB는 자동으로 확장됩니다. 트래픽이 증가해도 AWS가 백그라운드에서 리소스를 자동으로 할당하여 성능을 유지합니다.
• 비동기 처리:
  SQS를 통해 작업을 비동기로 처리할 수 있으며, 이를 통해 시스템의 안정성을 높일 수 있습니다.

이 아키텍처는 서버리스 기술을 활용하여 애플리케이션을 구축하고, API Gateway와 Lambda를 통해 애플리케이션 로직을 처리하며, 데이터는 DynamoDB와 SQS로 관리되는 구조입니다.