[Cloud Computing] Serverless Computing

해당 게시글은 국민대학교 이경용 교수님의
수업 내용을 바탕으로 작성하였습니다.

 

 

Decoupling Modules

전체 시스템을 독립적인 컴포넌트로 디자인 하는 것.

 

 

시스템이 loose coupled 될수록 시스템의 확장성을 보장하는 것이 쉬움.

Web Server -> Nginx 또는 Apache Tomcat (proxy가 각 엔드포인트에 대해 요청을 뿌려줌)

 

장점

각 컴포넌트 간의 종속성 최소화. (casecading failure 방지)

• tightly coupled : 한 응용 서버의 문제가 모든 웹서버에 전파됨
• loosely coupled : 로드밸런서가 응용서버의 실패를 가려줌 (health check)

 

모듈을 Decoupling 하는 방법

• 서버를 구축해서 모든 서비스를 만드는 시도는 좋지 않음.
  • 서버를 만들지 말고 마이크로서비스를 만들기
• 다양한 클라우드 서비스를 활용하여 서버와 서비스를 분리하기
  • serverless computing, message queuing, s3 등

 

Service-Oriented-Architecture (SOA)

• 여러 응용 컴포넌트들은 다른 컴포넌트들에게 약속된 기법으로 서비스를 제공하는 구조
• 서비스는 완전하게 동작하는 독립적인 개체
• 추상화를 통한 API 제공
• 목적 : 응용 서비스들 간의 coupling 최소화

 

 

MicroService

• SOA에서 작고 독립적인 프로세스
• 각각의 마이크로서비스 프로세스는 하나의 작은 작업을 하는 것에만 집중
• 여러 마이크로서비스가 합쳐져서 하나의 응용 서비스를 제공할 수 있음
• 마이크로서비스 간에도 API를 통한 호출 (JSON, REST API)

 

• 여러 기능들을 각각의 컴포넌트로 분리
  • 테스트할 시나리오 감소
  • 업데이트 비용 최소화
  • 각 서비스의 독립적 확장 가능

 

마이크로 서비스를 활용한 Loose Coupling

• 개별 컴포넌트는 손쉽게 테스트 되어야 하고 업그레이드가 쉬워야 함.
  • 다른 서비스에 제공해주는 인터페이스 변경 최소화
• 간단한 API의 사용
  • 서비스 사용 시 소요되는 비용 절감
• 특정 기술에 얽매이지 않음 -> 요구사항에 따라 다양한 서비스 사용하기
  • ( In-memory KV DB [DynamoDB] vs RDBMS [RDS] )
• stateless로 디자인
  • 언제든지 바꿀 수 있는 자원으로 인식되어야 함.
  • Auto Scaling을 활용한 자원의 추가/제거는 stateless 서버에서 쉬움

---

Message Queue를 활용한 서비스 Decoupling

 

AWS Simple Queue Service (SQS)

• fully-managed 메시지 큐잉 서비스
• Message (FIFO)
  • 큐에 저장되어 처리되는 메시지
• Queue
  • 송신자, 수신자 사이의 버퍼 역할
  • 하나의 큐에서 여러 reader 프로세스와 write 프로세스 지원

 

SQS를 활용한 서비스들의 Coupling 해소

• Queue를 활용하므로써 다른 컴포넌트들이 비동기 방식으로 메시지를 주고 받음
  • 예 : 이미지 업로드 시 저장, 인코딩, 썸네일 추출, 카피라이트 문구 추가 등의 작업이 일련의 작업으로 구성된다고 가정
  • 각각의 작업들은 개별 EC2에서 일어남. (MSA)
• 일련의 과정을 하나의 파이프라인으로 구축 시 한 서버의 실패가 전체에 영향을 미침
• Queuing 되어있는 메시지를 고려하여 Auto Scaling 가능

 

특징

• Scalable
  • 확장성 제공
  • I/O 병렬 처리 가능
• Reliable
  • 모든 메시지들은 여러 데이터 센터의 여러 서버에 복제되어 있음.
  • API credential을 지원

 

분산 큐에서 메시지 읽어오기

 

 

분산 Queue를 통한 메시지 전달 시 주의사항

• Message Ordering
  • SQS 서비스는 메시지가 write된 차례를 보존할 수 없음.
  • 보존이 필요한 경우 -> Message 자체에 Sequence 정보 삽입 필요.
• At least once delivery
  • SQS에서 메시지들은 여러 분산 서버에 저장되어 있기에, 같은 메시지가 여러번 수신될 수 있음
  • 응용프로그램이 idempotent(멱등성)하게 만드는 것이 중요. => 여러번 반복해도 결과가 일정함.
    
• Message sampling
  • 메시지를 가지고 오는 서비스를 랜덤하게 선택하기에, 반복적인 polling을 실시해야 함.
• 메시지 중복 처리 방지 (Amazon SQS visibility timeout)
  
  • 여러 컴포넌트들이 하나의 메시지를 중복해서 처리하는 것을 방지해줌
  • 프로세스가 메시지를 읽으면 해당 메시지는 lock 됨.
  • 특정 시간 이후 메시지가 삭제되지 않으면, lock이 해제되고 다른 프로세스 처리가 가능해짐.

 

Amazon SQS 타입

• Standard Queue (분산 큐)
  • 최소 한 번의 배달은 보장
  • 큐에 삽입된 순서는 보장 x
• FIFO Queue
  • 전달 차례 보장 (FIFO)
  • 반복 처리 x 보장
  • 최대 처리 throughput 제한
  • 발신 차례 보존 x (보존 -> 응용 담당) [싱글 쓰레드 기반]

---

메시지 공지 (Notification) 서비스

Amazon Simple Notification Service (SNS)은 여러 응용 서비스 간에 notification 주고 받을 수 있게 해주는 서비스

 

특정 토픽에 메시지가 등록되면 구독하는 응용들에게 전달 됨.

수신, 발신 용량 제한 x (on-demand 요금)

발신 메시지가 여러 수신 개체들에게 전달될 수 있음.

 

특징

• 메시지를 보내는 역할
• 수신/처리 보장 x
• 송수신 차례를 보장 x -> 네트워크 이슈 등으로 인한 out-of-order 발생 가능

 

SNS의 구독자 -> Email, HTTP, SMS, SQS, Lambda

 

Amazon SNS vs Amazon SQS

 

SNS : 여러 응용에게 동시에 메시지 전송 / SQS : 하나의 응용이 메시지 처리

Message Persistence : 메시지가 반드시 처리 될 수 있음을 보장 (SQS)

Delivery mechanism : SNS는 지속적인 polling 없이 메시지 전달받게 해줌 / SQS는 수신자가 Queue에서 Polling 해야 함.

 

 

 

---

DynamoDB를 활용한 컴포넌트 Decoupling

• DynamoDB (NoSQL)
  • GET, SET, 복잡한 Join x
  • KV 저장 서비스
  • 결과물을 저장함과 동시에 다른 컴포넌트들이 결과물을 읽게함으로써 decoupling 기능 제공
  • 고가용성 보장
  • Fault-tolerance 기능 내재

 

Amazon SQS와 DynamoDB를 활용하는 패턴

 

 

웹 기반 응용의 특성

 

 

웹페이지에는 수많은 프로토콜과 컴포넌트들이 존재한다.

 

위 컴포넌트들에 대한 사용 불가로 인해 가용하지 않을 경우 -> 매출 감소, 브랜드 이미지 및 고객 잃음.

 

웹 자료 저장 패턴

• 정적 자료
  • 웹의 자료 중 변하지 않은 내용 (HTML, 이미지, 비디오 자료 등)
• EC2에서 제공 시 문제점
  • 서버의 위치에 따라 가변적인 사용자의 위치에 따라 응답시간이 길어질 수 있음.
  • 사용자가 업로드한 자료가 있을 경우, 해당 자료는 모든 웹서버에서 접근 가능해야 함.
• 보다 나은 정적 파일 저장 방법
  • 정적 파일 -> S3에 저장 후 해당 위치로부터 제공 (public 설정 필요)
• 적절한 Region의 거리, 서비스 서버 간의 거리 고려 -> CloudFront 사용

 

CloudFront를 활용한 빠른 응답 시간

• Amazon CloudFront
  • AWS에서 제공하는 Content Delivery Network (CDN) 서비스
  • 분산 저장 및 캐싱을 통한 빠른 응답 시간 제공
  • CloudFront에 저장된 파일에 대한 요청이 올 경우, 요청 사용자와 지리적으로 가까운 CloudFront Edge location으로 자동으로 요청이 전달됨. Edge Location에서 캐시 서비스 제공
    • 요청 파일이 캐싱 시 즉각 제공
    • 없는 경우 S3에서 파일을 읽어들인 후 제공

 

웹 호스팅 예제

Route53 -> CloudFront -> LoadBalancer / S3

'

CloudFront 동작시키는 방법

1. Origin 서버 설정
2. Origin Server에 데이터 업로드
3. CloudFront에 Origin server 등록, 필요 옵션 설정
4. CloudFront 서비스 별 URL 설정 (HTTP Endpoint)
5. 각 Edge location에 object에 대한 정보 배포

 

Cache Control Header 활용

HTTP 요청의 Cache Control Header를 활용하여 정적/동적 자료 여부를 설정할 수 있음

 

TTL (Time To Live)

• 객체를 expire 시키는 시간
• 정적 자료는 길게, 동적 자료는 짧게
• TTL이 지난 경우, CloudFront는 Origin에 If-Modified-Since로 파일의 업데이트 여부 확인
• 변하지 않았으면 캐시 제공

파일명의 변경은 즉각적으로 cache invalidate 시킴.

 

---

Amazon API Gateway를 활용한 Decoupling

• 웹서버의 기능을 해주는 API 생성
• 백엔드 서비스들에 요청 전달
• 수십만건의 동시 요청 처리 가능한 Fully-managed 서비스
• 원시적으로 80번 포트를 통한 HTTP 기능 제공
• 서비스 내부에 DDoS 방어 매커니즘 내재

 

---

AWS Lambda를 활용한 Decoupling

• 자원 관리의 부담 없이 사용자 작성 코드를 동작하게 해줌
• stateless 응용이 적합함 (어떤 서버에서 동작해도 결과의 차이가 없음)
• 기존의 서버를 lambda로 변형 가능 -> stateless로 설계하여 decoupling 향상

 

람다 특징

• 제공 서비스
  • 서버 관리
  • 필요에 의한 자원 추가 및 제거 (Auto Scaling)
  • 코드 배포
  • 실행 환경 업데이트
• 사용자 관점에서의 특징
  • 사용하지 않는 자원에 대해서는 과금 x
  • 병렬 수행 가능

 

활용법

• 작성한 코드가 실제로 동작한 시간에 비례한 과금
• 다른 서비스들이 lambda를 동작시킬 수 있음.
• 다른 웹서비스나 앱에서 직접 호출 가능
  • AWS Button : 버튼으로 클릭시 람다 함수 실행 기능 제공
• EC2 인스턴스가 분리 가능한 간단한 작업을 한다면 람다 활용 가능

 

사용 환경 설정

• 컴퓨팅 자원 할당
  • 람다 함수 설정 시 최대 메모리 사용량 지정 -> 비례한 CPU 성능 제공
• 함수 실행 패키지 및 사이즈 제한 -> 250MB
  • 큰 사이즈 패키지 사용 시 Layer 또는 EFS 사용
  • 함수 실행 컨테이너 이미지로 생성하여 활용 가능
    • Docker Image에 Lambda 실행 코드 업로드 => ECR에서 사용

 

사용 예제

1. 이미지 썸네일 생성

S3에 이미지 업로드 -> Lambda 트리거

 

2. ETL ( 온라인 주문 )

DynamoDB에 저장 -> Lambda 트리거

 

3. Web Application (Serverless Computing)

S3에서 정적 웹 호스팅 -> API Gateway에서 특정 엔드포인트 호출 -> Lambda가 DB에서 데이터 가져옴.

 

4. Lambda를 활용한 Web Server

 

Lambda 자원 설정 및 과금

함수 실행 시간이 활용하는 메모리 (128MB ~ 10GB)

메모리 할당량에 비례하여 CPU 자원 할당 (Network, IO는 비례하지 않음)

과금 금액은 메모리 할당량과 실행 시간에 비례

                   ∝ !(network, IO)
과금 금액 ∝ 메모리 할당 ∝ CPU 자원
        ∝ 실행 시간

 

코드의 최대 실행 시간 = 15분

 

Cold-Start

• Lambda는 기본적으로 stateless로 동작하여, 호출될 때마다 컨테이너를 새로 생성하거나 기존 것을 재활용함.
• 이때 함수 실행 컨테이너를 초기화 하는데 실행 환경 준비에 오랜 시간이 걸림.
  • Provisioned Concurrency를 활용해 해결 가능 (추가 과금) -> 컨테이너를 미리 생성하여 준비 상태로 유지하는 기능
• 실제 함수 실행 시 handler 코드만 실행.

[Warm-start -> 미리 실행 환경이 준비 됨]

 

Lambda 실행 방법

• 람다 코드 작성
  • 코드 에디터 활용 ()
  • 코드와 필요한 라이브러리를 압축하여 람다에 업로드
• 이벤트 등록
• 메모리 사이즈 설정 (128MB ~ 10GB)
• 타임 아웃 설정 (최대 15분)
• 필요 시 VPC 설정

---

Decoupling 예제