11. 서버리스

 

서버리스란 무엇인가

요구사항 : "운영 오버헤드를 줄이고 리소스 비용을 최적화할 수 있는 방법은 무엇입니까?"

 

 

서버리스

서버리스는 민첩한 애플리케이션을 구축하는 데 사용할 수 있는 서비스, 사례 및 전략이다.

AWS에서 용량 프로비저닝, 패치 적용 등의 인프라 관리 태스크를 처리하므로 고객을 위한 코드 작성 작업만 중점적으로 수행할 수 있게 된다.

 

 

서버리스 컴퓨팅의 이점

• 프로비저닝하거나 관리할 인프라가 없음 -> 서버를 프로비저닝, 운영 또는 패치할 필요가 없음
• 서버 단위가 아니라 소비 단위별로 오토 스케일링
• 종량제 결제 모델(서버 단위가 아니라 해당 단위에 대한 비용을 지불)
• 가용성 및 내결함성 기본 제공 ( AWS에서 관리함 )

 

 

AWS 서버리스 포트폴리오

 

AWS에서는 서버리스 애플리케이션을 구축 및 실행하는 데 사용할 수 있는 완전관리형 서비스를 제공한다.

서버리스 애플리케이션 사용 시에는 백엔드 구성 요소용 서버를 프로비저닝, 유지 및 관리할 필요가 없다.

백엔드 구성 요소의 예로는 컴퓨팅, 데이터베이스, 스토리지, 스트림 처리, 메시징, 대기열에 추가 등이 있다.

뿐만 아니라 애플리케이션 내결함성 및 가용성에 관해 걱정할 필요가 없다. AWS가 이 모든 기능을 제공한다.

 

 

 

서버리스 아키텍처의 예

1. POST 요청이 수신됨

2. 요청이 메시지 대기열로 전송된 후 작업자 서비스에서 처리될 때까지 대기됨

3. 작업자 서비스가 메시지를 처리하고 Amazon DynamoDB에 씀

4. 작업자 서비스가 구독된 사용자에게 SMS 알림을 전송하라는 메시지를 알림 서비스에 표시함

 

슬라이드에는 서버리스 아키텍처의 예로 메시징 애플리케이션이 나와 있다.

 

이 예에서는 Amazon API Gateway를 사용하여 API 호출 수락 및 처리와 관련된 모든 태스크를 처리한다.

API Gateway는 SQS의 기본 제공 애플리케이션 메시징 대기열에 메시지를 제공한다.

이 대기열에서는 작업자 서비스가 메시지를 처리한다.

이 대기열은 트래픽 급증 시 작업자 서비스용으로 버퍼를 제공한다.

컨테이너화된 작업자 서비스는 AWS Fargate의 서버리스 호스팅 기능을 사용한다.

AWS Fargate는 새로 시작된 각 컨테이너를 사용하여 호스팅 용량의 크기를 자동으로 조정한다.

작업자 서비스는 처리된 메시지를 DynamoDB 테이블에 쓴다.

작업자가 성공 응답을 수신하면 해당 작업자는 SNS에 알림을 보낸다.

Amazon SNS는 구독된 모든 사용자에게 SMS 알림을 푸시한다.

 

 

 

Amazon SQS

• 완전관리형 메시지 대기열 서비스
• 처리 및 삭제될 때까지 메시지를 저장
• 발신자와 수신자 간 버퍼 역할을 담당

Amazon SQS는 관리 부담이 없으며 최소한의 구성으로도 바로 사용할 수 있는 완전관리형 서비스이다.

이 서비스는 방대한 규모로 작동하므로 하루에 수십억 건의 메시지를 처리할 수 있다.

Amazon SQS는 여러 이중화 가용영역을 사용하여 가용성이 높은 단일 AWS 리전에 모든 메시지 대기열과 메시지를 저장한다.

그러므로 단일 컴퓨터, 네트워크 또는 가용 영역 장애로인해 메시지에 엑세스하지 못하는 경우가 없다.

메시지는 동시에 보내고 읽을 수 있다.

 

개발자는 SQS 대기열을 익명으로 또는 특정 AWS 계정과 안전하게 공유할 수 있다.

특정 IP 주소와 트정 시간으로 대기열 공유를 제한할 수도 있다.

 

 

Amazon SQS를 통한 느슨한 결합

• 애플리케이션 구성 요소를 느슨하게 결합
  • -> 결국 노드간 주소로 다이렉트로 연결 안 하게 됨으로써 스케일 아웃 처리에 유리하다는거네
• 비동기식 처리 사용
• 실패한 단계에 대한 내결함성 제공
• 급증하는 수요 처리 가능

 

슬라이드의 예에서는 생산자 애플리케이션이 고객 주문을 생성한 후 SQS 대기열로 전송한다.

소비자 애플리케이션 티어가 생산자 애플리케이션 티어의 주문을 처리한다.

이 애플리케이션은 대기열을 폴링하고 메시지를 수신한다.

그런 다음 RDS 데이터베이스에 기록하고 처리된 메시지를 SQS 대기열에서 삭제한다.

SQS는 처리할 수 없는 메시지를 나중에 처리할 수 있는 DLQ(Dead Letter Queue)로 전송한다.

이 대기열에서 해당 메시지를 나중에 처리할 수 있다.

 

 

Amazon SQS 사용 사례

SQS 대기열을 사용하는 방법은 여러 가지가 있다.

 

• 작업 대기열 - 동일한 양의 작업을 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리한다.
  애플리케이션의 구성 요소를 분리한다. 애플리케이션의 요구 사항에 따라 표준 대기열 또는 FIFO 대기열을 선택할 수 있다.
• 버퍼링 및 배치 작업 - 아키텍처에 확장성과 안전성을 더하고, 메시지를 손실하거나 지연 시간을 늘리지 않고 일시적인 볼륨 스파이크를 원활하게 처리한다.
• 요청 오프로딩 - 요청을 대기열에 전송하여 대화식 요청 경로에서 속도가 느린 작업을 이동한다.
• 인스턴스 자동 크기 조정 - SQS 대기열을 사용하여 애플리케이션의 로드를 확인할 수 있다.
  자동 크기 조정과 함께 사용하면 트래픽 볼륨에 따라 EC2 인스턴스 수를 늘리거나 줄일 수 있다.

 

SQS 대기열 유형

표준 대기열은 최소 1회 메시지 전송을 지원하고 최선의 정렬로 제공한다.

메시지는 일반적으로 수신된 순서와 동일한 순서로 전송된다.

하지만 고도로 분산된 아키텍처의 특성상 때로는 2개 이상의 메시지 사본이 순서가 맞지 않게 전송될 수 있다.

표준 대기열은 처리할 수 있는 초당 API 호출 수에 거의 제한이 없다.

한 번 이상 잘못된 순서로 도착하는 메시지를 애플리케이션에서 처리할 수 있는 경우, 표준 메시지 대기열을 사용할 수 있다.

 

FIFO 대기열은 작업 및 이벤트 순서가 중요하거나 중복 항목이 허용되지 않는 경우에 애플리케이션 간 메시징을 강화하도록 설계되어있다. 또한 FIFO 대기열은 정확히 한 번 처리를 제공하지만 초당 API 호출 수가 제한된다.

 

 

SQS 대기열 구성 최적화

SQS 대기열 애플리케이션을 생성할 때는 애플리케이션이 대기열과 상호작용하는 방식을 고려해야 한다.

이 정보는 대기열 구성을 최적화하여 비용을 제어하고 성능을 향상시키는데 도움이 된다.

 

가시성 제한 시간

소비자가 수신한 SQS 메시지는 소비자가 삭제할 때까지 대기열에 유지된다.

해당 메시지가 일정 기간 동안 다른 소비자에게는 표시되지 않도록 SQS 대기열의 가시성 제한 시간을 설정을 할 수 있다.

그러면 다른 소비자가 같은 메시지를 처리하지 못하도록 설정할 수 있다.

가시성 제한 시간의 기본값은 30초이다.

소비자는 처리를 완료한 메시지를 삭제한다.

가시성 제한 시간이 만료되기 전에 소비자가 메시지를 삭제하지 않는 경우, 다른 소비자가 메시지를 볼 수 있게 되며 해당 메시지는 다시 처리될 수 있다.

 

일반적으로 가시성 제한 시간 설정 시 애플리케이션이 대기열에서 메시지를 처리하고 삭제하는 데 걸리는 최대 시간으로 설정해야 한다.

시간 제한을 너무 짧게 설정하면 애플리케이션이 메시지를 두 번 처리할 가능성이 높아진다.

반면 가시성 제한 시간을 너무 길게 설정하면 후속 메시지 처리 시도가 지연된다.

 

폴링 유형

짧은 폴링이나 긴 폴링을 사용하도록 SQS 대기열을 구성할 수 있다.

 

짧은 폴링을 사용하는 SQS 대기열의 특성은 다음과 같다.

-> 애플리케이션에서 SQS에 메시지가 존재하는지 확인하는 주기를 말하는 듯, 짧은 폴링, 긴 폴링

• 요청을 수신하는 즉시 소비자에게 응답을 전송하므로 응답이 더 빠르게 제공된다.
• 응답 수가 늘어나므로 비용도 증가한다.

긴 폴링을 사용하는 SQS 대기열의 특성은 다음과 같다.

• 메시지가 하나 이상 도착하거나 폴링 시간이 초과될 때까지는 응답을 반환하지 않는다.
• 응답 빈도는 낮아지지만 비용도 감소한다.

대기열에 메시지가 도착하는 빈도에 따라서는 짧은 폴링을 사용하는 대기열의 응답 중 대다수가 빈 대기열을 보고하게 될 수 있다.

애플리케이션이 폴링 요청의 응답을 즉시 받아야 하는 경우가 아니면 긴 폴링 옵션을 사용하는 것이 좋다.

 

 

메시지 대기열을 사용해야 하는 경우

O	X
서비스 간 통신	특정 메시지 선택
비동기 작업 항목	대용량 메시지
상태 변경 알림

 

 

 

Amazon Simple Notification Service (Amazon SNS)

요구사항 : "애플리케이션에 푸시 알림을 보낼 수 있는 기능을 제공하려면 어떻게 해야 합니까?"

 

애플리케이션 개발 관리자가 애플리케이션에 푸시 알림 전송 기능을 추가하는 방법을 문의해 왔다.

이 회사는 애플리케이션 업데이트, 프로모션 메시지 등의 특정 이벤트 발생 시 사용자에게 알림을 보내려고 한다.

그리고 이메일 및 문자 메시지를 사용하여 이러한 메시지를 전송하려고 한다.

그러므로 AWS 클라우드에서 이 작업을 가장 쉽게 수행할 수 있는 방법을 조사해야 한다.

 

 

Amazon SNS

Amazon SNS는 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있는 웹 서비스이다.

이 서비스는 게시-구독(pub-sub) 메시징 패러다임을 따르며 푸시 메커니즘을 사용하여 클라이언트에 알림을 전달한다.

 

사용자는 주제를 생성하고 어떤 게시자 및 구독자가 주제와 통신할 수 있는지를 결정하는 정책을 정의함으로써 주제에 대한 엑세스를 제어한다.

게시자는 자신이 생성한 주제 또는 게시한 권한이 있는 주제로 메시지를 보낸다.

 

 

Amazon SNS 사용 사례

• Amazon CloudWatch 경보 알림
• 메일 발송 목록 이메일 및 SMS 메시지
• 앱 업데이트 푸시 알림

 

 

Amazon SNS의 특성

• 게시된 단일 메시지
• 회수 옵션이 없음
• HTTP 또는 HTTPS 요청
• 표준 또는 FIFO 주제