[AWS Architecting]서버리스

1. 운영 오버헤드 줄이고 리소스 비용 최적화하기

운영 오버헤드와 비용을 줄일 수 있는 방법 중 하나는 서버리스 아키텍처를 채택하는 것입니다. 

서버리스 컴퓨팅 사용 시에는 인프라를 프로비저닝하거나 관리할 필요가 없습니다.

서버리스 아키텍처는 크기를 자동으로 조정할 수 있으며, 사용한 리소스에 대한 비용만 지불하면 되므로 비용을 제어할 수 있습니다.

 

AWS 서버리스:

컴퓨팅	AWS Lambda, AWS Fargate
API 프록시	Amazon API Gateway
스토리지	Amazon S3
데이터베이스	Amazon DynamoDB, Amazon Aurora Serverless
인증	Amazon Cognito
프로세스 간 메시징	Amazon SNS, Amazon SQS
오케스트레이션	AWS Step Functions
분석	Amazon Kinesis, Amazon Athena

 

 

2. 안전한 백엔드 API 제공

Amazon API Gateway를 사용하여 백엔드 서비스와 상호작용하는 REST API 및 WebSocket API를 모두 제공할 수 있습니다.

 

API Gateway를 사용하여 API 생성, 게시, 유지관리, 모니터링 및 보호할 수 있습니다.

API Gateway를 사용하여 애플리케이션을 AWS 서비스와 기타 퍼블릭 또는 프라이빗 웹사이트에 연결할 수 있습니다.

또한 모바일 및 웹 애플리케이션이 AWS 서비스 및 AWS 외부에서 호스팅 되는 다른 리소스에 액세스할 수 있도록 일관된 RESTful 및 HTTP API를 제공합니다.
API Gateway는 최대 수십만 개의 동시 API 호출 수락하고 처리하는 데 관련된 모든 태스크를 처리합니다.

이러한 작업에는 트래픽 관리, 권한부여 및 액세스 제어, 모니터링, API 버전 관리가 포함됩니다.

 

 

 

3. 신뢰할 수 있는 서비스 간 통신

출처: https://aws.amazon.com/ko/blogs/compute/building-loosely-coupled-scalable-c-applications-with-amazon-sqs-and-amazon-sns/

Amazon SQS 사용 시에는 소프트웨어 구성요소 간에 메시지를 전송, 수신 및 저장할 수 있습니다. 

Amazon SQS는 관리형 서비스이므로 메시지 지향적 미들웨어를 관리 및 운영할 필요가 없습니다.

이 서비스는 하루에 수십억 건의 메시지를 처리할 수 있습니다.

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

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

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

 

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

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

스트리밍 SIMD(Single Instruction Multiple Data) 확장(SSE)은 AWS KMS에서 관리되는 키를 사용하여 SQS 대기열에 있는 메시지의 콘텐츠를 보호합니다.

SIMD 확장은 Amazon SQS가 메시지를 수신하는 즉시 이를 암호화합니다.

이 메시지는 암호화된 형태로 저장되며 Amazon SQS는 권한이 있는 사용자에게 전송할 메시지만 복호화 합니다.

 

SQS 대기열 사용 시 이점:

느슨한 결합	- 전처리 단계를 컴퓨팅 단계 및 후처리 단계와 분리 가능 - 비동기식 처리    - 생산자 로직이 소비자 로직과는 별도의 자체 구성요소에 격리됨
내결함성	- 애플리케이션 예외나 트랜잭션 장애가 발생하는 경우 주문처리 재시도 가능 - 최대 재시도 횟수에 도달하면 Amazon SQS DLQ(Dead Letter Queue)로 메시지 리디렉션    - 나중에 이 대기열에서 메시지 재처리 및 디버그 가능 - 한 노드 또는 작업이 손실되어도 일반적으로 전체 계산이 지연되지 않음
급증하는 트래픽 처리	- 시스템 복원력 향상 - 대기열은 급증하는 트래픽 처리를 위한 버퍼로 사용되므로,   애플리케이션이 확장 작업을 완료할 수 있는 추가시간이 제공됨 - 급증하는 트래픽 처리를 위한 유휴 컴퓨팅 리소스를 프로비저닝할 필요 없음(비용 효율성 상승)

 

SQS 대기열 사용 사례:

작업 대기열	- 분산 애플리케이션의 구성요소 분리 - 애플리케이션의 요구사항에 따라 표준대기열 또는 FIFO(선입선출) 대기열을 선택할 수 있음
버퍼링 및 배치작업	- 아키텍처의 확장성 및 안정성 증가 - 메시지를 손실 및 지연시간 감소 - 일시적인 볼륨 스파이크를 원활하게 처리
요청 오프로딩	느린 요청을 대기열에 추가
인스턴스 자동 크기 조정	- 트래픽 볼륨에 따라 Amazon EC2 인스턴스 수 조절 가능

 

SQS 대기열 유형:

표준 대기열	- 최소 1회 메시지 전송 - 최선의 정렬로 제공 - 일반적으로 수신된 순서와 동일한 순서로 메세지 전송 - 분산 아키텍처 특성상 순서가 맞지 않게 전송될 수 있음 - 거의 제한이 없는 초당 API 호출 수
FIFO 대기열	- 작업 및 이벤트 순서가 중요하거나 중복 항목이 허용되지 않는 경우 사용 - 애플리케이션 간 메시징 강화 - 제한된 초당 API 호출 수

 

SQS 대기열 구성 최적화:

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

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

1. 가시성 제한 시간

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

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

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

 

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

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

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

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

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

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

 

2. 폴링 유형

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

 

짧은 폴링	- 요청을 수신하는 즉시 소비자에게 응답을 전송하므로 응답이 더 빠름 - 응답수가 늘어나므로 비용도 증가
긴 폴링	- 메시지가 하나 이상 도착하거나 폴링 시간이 초과될 때까지는 응답을 반환하지 않음 - 응답 빈도는 낮아지지만 비용도 감소

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

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

메세지 대기열 사용 사례:

적합	부적합
서비스 간 통신	특정 메세지 선택
비동기 작업 항목	대용량 메세지
상태 변경 알림

 

 

4. 애플리케이션에 푸시 알림 보내기

애플리케이션간 통신과 애플리케이션 및 사용자 간 통신에 Amazon SNS를 사용할 수 있습니다.

Amazon SNS는 분산시스템과 이벤트 중심 아키텍처 간의 메시징을 지원합니다.

그리고 SMS, 모바일 푸시 및 이메일을 통해 사용자에게 대규모로 메시지를 보낼 수도 있습니다.

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

게시자는 자신이 생성한 주제 또는 게시할 권한이 있는 주제로 메시지를 보냅니다.
게시자는 각 메시지에 특정 대상 주소를 포함하는 대신 메시지를 해당 주제로 전송할 수 있습니다.

Amazon SNS는 주제와 해당 주제의 구독자 목록을 일치시켜 각 구독자에게 메시지를 전송합니다.
각 주제에는 Amazon SNS 엔드 포인트를 식별하는 고유한 이름이 있으므로, 게시자는 메시지를 게시하고 구독자는 알림을 받도록 등록할 수 있습니다. 

구독자가 구독하는 주제에 게시된 모든 메시지를 수신합니다. 특정 주제의 모든 구독자는 동일한 메시지를 수신합니다.

 

Amazon SNS는 암호화된 주제를 지원합니다. 

암호화된 주제에 메시지를 게시하면 Amazon SNS는 AWS KMS 키를 사용하여 메시지를 암호화합니다.

 

Amazon SNS 사용 사례:

- Auto Scaling 그룹에 특정 변경사항이 발생하는 등의 이벤트가 있을 경우, 사용자는 즉시 알림을 받을 수 있습니다.
- 구독자에게 이메일 또는 SMS로 특정 뉴스 헤드라인을 푸시 할 수 있습니다.

   수신한 이메일 또는 SMS 문자를 받은 사람은  웹사이트를 방문하거나 애플리케이션을 시작할 수 있습니다.
- 업데이트가 가능함을 나타내는 알림을 앱으로 전송할 수 있습니다.

  알림 메시지는 업데이트를 다운로드 및 설치하기 위한 링크를 포함할 수 있습니다.

 

Amazon SNS 특성:

- 메시지가 성공적으로 전송되면 다시 회수할 수 없습니다.

- Amazon SNS 전송 정책을 사용해 재시도 패턴(선형, 기하학, 지수 백오프, 최대/최소 재시도 지연 및 기타 패턴)을 제어할 수 있습니다.
- 메시지가 손실되지 않도록 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 중복 저장됩니다.
- 애플리케이션이 무제한의 메시지를 게시할 수 있습니다.
- 다양한 디바이스의 애플리케이션 및 최종사용자가 모바일 푸시 알림에 의한 알림을 수신할 수 있습니다.

  (Apple, Google 및 Kindle Fire 디바이스, HTTP 또는 HTTPS, 이메일 또는 이메일-JSON, SMS 또는 Amazon SQS 대기열, Lambda 함수 등)
- Amazon SNS는 액세스 제어 메커니즘을 갖추고 있어 주제와 메시지가 무단 액세스로부터 확실하게 보호됩니다.

- 주제의 소유자가 주제별로 일정한 정책을 수립해 주제를 게시하거나 구독할 수 있는 대상을 제한할 수 있습니다.

- 주제 소유자는 전송 메커니즘을 HTTPS로 지정하여 알림을 암호화할 수도 있습니다

Amazon SNS 팬아웃:

https://docs.aws.amazon.com/ko_kr/sns/latest/dg/sns-common-scenarios.html

일반적인 Amazon SNS 시나리오 - Amazon Simple Notification Service

팬아웃 시나리오에서는 메시지가 SNS 주제로 전송된 후 복제되어 여러 SQS 대기열, HTTP 엔드포인트 또는 이메일 주소로 푸시 됩니다.

따라서 비동기식 병렬처리가 허용됩니다.

 

Amazon SNS vs Amazon SQS:

	Amazon SNS	Amazon SQS
메세지 지속성	X	O
전송 메커니즘	푸시(수동)	폴링(능동)
생상자 및 소비자	게시자 및 구독자	발송 또는 수신
배포 모델	일대다	일대일

 

 

5. 스트리밍 데이터 수집

Amazon Kinesis를 사용하면 실시간 스트리밍 데이터를 수집, 처리 및 분석할 수 있습니다.

Amazon Kinesis를 사용하면 다음 작업을 수행할 수 있습니다:

- 실시간으로 데이터스트림을 수집, 처리, 분석할 수 있습니다.

- Kinesis는 어떤 규모에서든 스트리밍 데이터를 처리할 수 있는 용량을 제공합니다.

- 그러므로 애플리케이션의 요구사항을 충족하는 도구를 유동적으로 선택할 수 있습니다.
- 비디오, 오디오, 애플리케이션 로그, 웹사이트 클릭 스트림, 사물 인터넷(IoT) 원격 측정 데이터와 같은 실시간 데이터를 수집할 수 있습니다.

-수집된 데이터는 기계학습, 분석 및 기타 애플리케이션에 사용할 수 있습니다.
- 정형 쿼리 언어(SQL) 또는 Apache Fink를 사용하여 수신되는 데이터를 처리 및 분석한 후 응답을 즉시 제공합니다.

- 모든 데이터가 수집될 때까지 기다렸다가 처리를 시작할 필요가 없습니다

 

Kinesis Data Streams:

https://docs.aws.amazon.com/ko_kr/streams/latest/dev/introduction.html

Amazon Kinesis Data Streams - Amazon Kinesis Data Streams

Kinesis Data Streams 사용을 시작하려면 스트림을 생성하고 샤드 수를 지정합니다.

각 샤드는 스트림에서 고유하게 식별되는 데이터 레코드 시퀀스입니다.

스트림은 각 샤드에서 초당 1MB를 수신할 수 있습니다.

각 샤드에는 2 MBs 애플리케이션 읽기 제한이 있습니다.

스트림의 총 용량은 해당 샤드 용량의 합계입니다.

리샤딩을 사용하여 필요에 따라 스트림의 샤드 수를 늘리거나 줄입니다.

생산자는 스트림에 데이터를 씁니다.

생산자는 EC2 인스턴스, 모바일 클라이언트, 온프레미스 서버 또는 IoT 디바이스일 수 있습니다.

인프라 로그, 애플리케이션 로그, 시장 데이터 피드, 웹 클릭 스트림 데이터 등의 데이터를 전송할 수 있습니다.

 

소비자는 생산자가 생성하는 스트리밍 데이터를 읽습니다.

소비자는 EC2 인스턴스 또는 AWS Lambda에서 실행 중인 애플리케이션일 수 있습니다.

EC2 인스턴스에 있는 애플리케이션은 스트리밍 데이터 증가에 따라 확장되어야 합니다.

이러한 경우 Auto Scaling 그룹에서 애플리케이션을 실행할 수 있습니다.

소비자 애플리케이션을 쓰는 또 한 가지 방법은 Lambda 함수를 사용하는 것으로, 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있습니다.

스트림의 동일한 데이터를 처리하는 애플리케이션이 두 개 이상 있을 수 있습니다.

Amazon S3, Amazon DynamoDB 및 Amazon Redshift 등의 AWS 서비스를 사용하여 소비자 애플리케이션의 결과를 저장할 수 있습니다.

 

Kinesis Data Firehose:

https://docs.aws.amazon.com/ko_kr/firehose/latest/dev/what-is-this-service.html

Amazon Kinesis Data Firehose Firehose란 무엇입니까? - Amazon Kinesis Data Firehose

Kinesis Data Firehose는 레코드를 Amazon S3, Amazon Redshift, Amazon OpenSearch Service 및 사용자가 소유한 임의의 HTTP 엔드포인트로 전송할 수 있습니다.

또한 레코드를 Datadog, New Relic, Splunk 등 모든 서드파티 서비스 공급자로 전송할 수 있습니다.
Amazon S3로 데이터를 전송하기 위해 Kinesis Data Firehose는 전송 스트림의 버퍼링 구성을 기반으로 여러 수신 레코드를 연결합니다.

그런 다음 연결된 레코드를 Amazon S3에 S3 객체로 전달합니다.

Amazon Redshift에 데이터를 전송하기 위해, Kinesis Data Firehose는 다음 작업을 수행합니다.

1. 수신 데이터를 앞서 설명한 형식으로 S3 버킷에 전송합니다.

2. Amazon Redshift COPY 명령을 실행하여 S3 버킷에서 Amazon Redshift 클러스터로 데이터를 로드합니다.

 

Amazon OpenSearch Service는 OpenSearch API 및 실시간 분석 기능을 제공하는 완전 관리형 서비스입니다.

처리된 데이터를 사용하여 기존 비즈니스 인텔리전스 도구 및 대시보드로 준 실시간 분석을 생성할 수 있습니다.

Amazon OpenSearch Service를 사용하면 Kinesis Data Firehose가 전송 스트림의 버퍼링 구성에 따라 수신 레코드를 버퍼링 합니다.

그런 다음 Kinesis Data Firehose는 대량 요청을 생성하여 Amazon OpenSearch Service 클러스터에 여러 레코드를 인덱싱합니다.

 

 

6. 다단계 워크플로 오케스트레이션

Step Functions를 사용하면 여러 서비스와 시스템을 연결하는 상태 저장 워크플로를 구축할 수 있습니다.

 

https://docs.aws.amazon.com/ko_kr/step-functions/latest/dg/connect-to-services.html

다른AWS 서비스에 전화하기 - AWS Step Functions

Step Functions는 다음 AWS 서비스와 통합됩니다. 

Step Functions에서 직접 API 작업을 호출하고 파라미터를 다음 서비스의 API로 전달할 수 있습니다. 

 

컴퓨팅 서비스	AWS Lambda, Amazon ECS, Amazon EKS, AWS Fargate
데이터베이스 서비스	Amazon DynamoDB
메시징 서비스	Amazon SNS 및 Amazon SQS
데이터처리 및 분석 서비스	Amazon Athena, AWS Batch, AWS Glue, Amazon EMR, AWS Glue DataBrew
기계학습 서비스	Amazon SageMaker
기타 서비스	API Gateway에 의해 생성된 API

 

Step Functions 특징:

- 시각적 워크플로를 사용한 마이크로서비스 조정

- 애플리케이션 기능을 단계별로 실행 가능

- 각 단계를 자동으로 시작하고 추적

- 단계가 실패할 경우 간단한 오류 파악 및 로깅을 제공

 

Step Functions 상태 머신:

상태 머신은 출력을 결정하기 위해 이전 조건에 의존하는 일련의 작동 조건을 가진 객체입니다.

상태 머신의 일반적인 예는 탄산음료 자판기입니다.

자판기는 작동상태(거래 대기)에서 시작하여 고객이 동전 또는 지폐를 투입하면 탄산음료 선택 상태로 전환됩니다.

그러면 판매 상태가 시작되어 탄산음료가 고객에게 제공됩니다.

완료 후 운영상태로 돌아갑니다.

 

Step Functions를 사용하면 AWS 환경에서 사용자 고유의 상태 머신을 생성하여 자동화할 수 있습니다.

Step Functions는 JSON 기반 Amazon States Language를 사용합니다.

Amazon States Language에는 다양한 상태, 태스크, 선택, 오류 처리 등으로 구성된 구조가 포함되어 있습니다.

 

Step Functions 상태:

상태는 상태 머신의 요소입니다. 

상태는 상태 머신에서 다양한 기능을 수행할 수 있습니다. 

 

Task 상태	상태 머신에서 몇 가지 태스크 수행
Choice 상태	실행할 브랜치 선택
Fail 또는 Succeed 상태	오류 또는 성공으로 실행 중지
Pass 상태	입력을 출력으로 전달하거나 일부 수정된 데이터 전달
Wait 상태	특정 시간 동안 또는 지정된 시간/날짜까지 실행 지연
Parallel 상태	병렬 브랜치 시작
Map 상태	동적으로 단계 반복

 

Step Functions 워크플로 유형:

https://docs.aws.amazon.com/ko_kr/step-functions/latest/dg/concepts-standard-vs-express.html

표준 워크플로와 익스프레스 워크플로우 비교 - AWS Step Functions

Standard Workflow	- 내구성이 우수하며 감사가 가능한 장기 실행 워크플로 - 최대 1년까지 실행 가능 - 워크플로가 완료된 후 최대 90일 동안 워크플로 활동의 전체 기록에 액세스 가능 - 사용되는 1회 모델에서 재시도 동작을 지정하는 경우가 아니면 태스크와 상태가 2회 이상 실행되지 않음
Express Workflow	- IoT 데이터수집, 스트리밍 데이터처리 및 변환, 모바일 애플리케이션 백엔드 등의 대용량 이벤트 처리 워크 로드 - 최대 5분까지 실행 가능 - 사용되는 최소 1회 모델에서는 태스크와 상태가 여러 번 실행 가능

 

 

 

 

 

 

 

 

 

 

 

 

Architecting on AWS 7.4.6 (KO): Student Guide  참고