8. Microservice Architecture 인프라 결합 해제

1. 독립 구성 아키텍처

 

-  느슨한 결합은 확장 프로세스를 간편하게 해줌

 

-  여러 티어에 분산 시스템 사용 시 관리형 로드 밸런서 또는 대기열 시스템에서 트래픽이 전달되고 검색될 수 있는 단일 엔드포인트 제공

 

-  즉 시스템이 느슨하게 결합될수록 더 쉽게 확장되며 내결함성도 강화할 수 있음

2. 느슨한 결합 전략

 

2.1 서버가 아니라 서비스를 설계

 

다양한 AWS 서비스를 활용하고 인프라를 서버로 한정하지 않음

안티 패턴	모범 사례
간단한 애플리케이션이 영구 서버에서 실행	서버리스 솔루션이 필요할 때 프로비저닝 됨
애플리케이션이 서로 직접 통신	메시지 대기열이 애플리케이션 간의 통신을 처리
정적 웹 자산이 로컬로 인스턴스에 저장	정적 웹 자산은 Amazon S3와 같은 외부에 저장
백엔드 서버가 사용자 인증 및 사용자 상태 스토리지를  처리	사용자 인증 및 사용자 상태 스토리지는 관리형 AWS 서비스에서 처리

 

2.2 서비스 지향 아키텍처 (SOA) 구현

 

-  애플리케이션 구성 요소가 통신 프로토콜을 통해 다른 구성 요소에 서비스를 제공하는 아키텍처 접근 방식

 ㅁ  SOA를 사용하는 목적은 애플리케이션 서비스의 결합을 느슨하게 하기 위함

 ㅁ  애플리케이션의 작업 대부분 또는 전부가 아키텍처의 같은 부분 안에서 완료되는 모놀리식 애플리케이션을 가져와 이 작업 중 일부를 서로 독립적으로 운영되는 개별 “단위”로 분산 시킴

 

-  서비스는 구현 세부 정보가 더 이상 관련되지 않는 기능이 자체 포함되어 있음

 ㅁ  애플리케이션 사용자는 운영 체제, 언어 또는 위치와 같은 구현 세부 정보에 더 이상 신경을 쓰지 않음

 

2.3 마이크로 서비스

 

-  SOA 내 더 작고 정밀하며 독립적인 프로세스

 

-  각 프로세스는 하나의 작은 작업을 수행하는데 주력

 

-  프로세스는 JSON/REST를 활용하는 언어에 구애받지 않는 API를 사용하여 서로 통신

 

-  기능을 개별 구성 요소로 분할

 

2.4. 마이크로 서비스의 장점

 

-  마이크로 서비스는 독립적으로 확장 가능

 ㅁ  시스템의 다른 구성 요소는 그대로 두고, 관련 구성 요소만 손쉽게 확장 또는 축소 가능   

 ㅁ  수평적 확장 가능한 개별 파트 사용

 

-  인시던트에 견고함

 ㅁ  가용성은 점진적으로 저하됨

 ㅁ  연속 장애는 발생하지 않도록 장애를 염두에 두고 구축되어 내결함성을 가중

 

-  구성 요소간 스왑이 가능함

 ㅁ  특정 파트를 업데이트하거나 업그레이드할 때 한 구성 요소를 다른 구성 요소가 대체함

 

-  유지 관리 코드 규모가 작음

 ㅁ  반복할 파트가 더 작아짐

 ㅁ  테스트할 영역이 축소됨

 ㅁ  변경에 따른 위험이 감소됨

 

2.5 아키텍처 스타일 비교

-  기존 애플리케이션 아키텍처는 모닐리식으로 시스템의 모든 구성 요소가 함께 밀결합 됨

 

-  마이크로 서비스 기반 아키텍처는 구성 요소를 느슨하게 결합된 방식으로 서로 연결된 독립적 서비스 수행

 

2.6. 마이크로 서비스 아키텍처 모범 전략

 

-  Provider/Consumer 사이의 인터페이스는 계약서 수준으로

 ㅁ  기능 변경이 소비자에게 영향을 주어서는 안됨

 ㅁ  쉽게 변경되지 않는 인터페이스로 계약

 

-  간단한 API 사용

 ㅁ  서비스 사용 비용을 절감

 ㅁ  복잡성 증가는 변경에 대한 저항 증가를 의미

 ㅁ  적게 공유할수록 오류도 적음

 ㅁ  상세 정보를 숨길 수 있음

 

-  기술에 구애를 받지 않도록 유지

 ㅁ  변화를 지원하여 새로운 혁신을 받아드릴 수 있도록

 

-  장애를 염두에 두고 설계

 ㅁ  실패 시나리오는 운영 환경에서 항상 발생

 ㅁ  강제하지 않으면 테스트 도중에는 거의 발생하지 않음

 

-  환경을 모니터링

 ㅁ  인프라만 모니터링해서는 안됨

 ㅁ  확인 상태 추출이란 이를 서비스에서 수집한다는 의미.

 

-  서버를 상태 비저장 모드로 처리

 ㅁ  서버는 그룹에서 상호 교환이 가능한 구성원으로 보여야 함

 ㅁ  워크로드를 처리할 만큼 충분한 용량이 있는지 집중

 ㅁ  상태 비저장 모드를 사용하여 Auto Scaling을 훨씬 더 쉽게 인스턴스를 추가하고 제거 가능

 

3. Queue를 사용한 구성 요소 간 안정적 통신

 

3.1. Amazon Simple Queue Service (SQS)

 

Amazon SQS는 완전 관리형 메시지 대기열 서비스로 메시지를 손실하거나 다른 서비스를 항상 가용 상태로 유지 하지 않고 처리량과 관계없이 모든 볼륨의 메시지를 전송

3.2. Amazon SQS 대기열 유형

 

-  표준 대기열

 ㅁ  최소 1회 전송

 ㅁ  최선의 노력으로 순서화

 

-  FIFO 대기열

 ㅁ  정확한 1회 처리

   > 중복은 도입되지 않음

 ㅁ  제한된 처리량

   > 초당 최대 300건의 전송, 수신 삭제

 

3.3 QUEUE를 통한 느슨한 결합

 

대기열 체인 패턴을 사용하면 비동기식 처리가 가능

http://en.clouddesignpattern.org/index.php/CDP:Queuing_Chain_Pattern

CDP:Queuing Chain Pattern - AWS-CloudDesignPattern

 

-  해결할 문제

이미지 처리

 ㅁ  예: 이미지를 업로드, 저장 및 인코딩하는 순차적 작업, 썸네일 생성 및 저작권은 서로 밀접하게 연결되어 있음

 ㅁ  이러한 긴밀한 연결은 장애가 발생했을 때 복구 작업을 복잡하게 함

 

-  대기열 체인 패턴 (시스템간 비동기식 연결)

 ㅁ  시스템 간에 대기열을 사용하고 작업을 전송하는 메시지를 교환함으로 시스템의 느슨한 결함 실현

 ㅁ  이 방법을 사용 시 메시지를 병렬로 수신 및 처리하는 가상 서버의 수를 늘릴 수 있음

 ㅁ  처리할 이미지가 없는 경우, Auto Scaling을 구성하여 불필요한 서버를 종료 가능

 

-  이점

 ㅁ  비동기식 처리를 사용하여 응답을 신속하게 반환

 ㅁ  Amazon EC2 인스턴스를 느슨하게 결합하여 시스템을 구성

 ㅁ  단순히 작업 처리에 사용되는 Amazon EC2 인스턴스의 수를 늘리거나 줄이는 방법으로 성능 및 서비스 요구 사항을 해결

 ㅁ  Amazon EC2 인스턴스가 실패하더라도, 메시지가 대기열 서비스에 남아 있어 Amazon EC2 인스턴스가 복구되는 대로 처리 계속 가능하여 장애에 강한 시스템을 구현

 

3.4. Amazon Simple queue Service(SQS) 이점

 

-  확장성

 ㅁ  잠재적으로 수백만 건의 메시지 처리

 

-  안정성

 ㅁ  모든 메시지가 여러 데이터 센터 및 여러 서버에 중복 저장

 

-  동시 읽기/쓰기 가능

 

- 보안

 ㅁ  API 자격 증명 필요

 

3.5. 분산 대기열의 속성 이해

 

         

-  메시지 순서

 ㅁ  Amazon SQS는 대기열의 분산 특성으로 인해 전송한 순서 그대로 메시지를 수신할 것이라고 보장할 수 없음

 ㅁ  시스템에서 순서 유지를 필요로 하는 경우, 수신 시 메시지의 순서를 재정리할 수 있도록 메시지에 시퀀스 정보를 포함해야 함

 

-  최소 1회 전송

 ㅁ  Amazon SQS는 중복성과 고가용성을 위해 여러 서버에 메시지 복사본을 저장

 ㅁ  드문 경우로 메시지를 수신 또는 삭제할 때 해당 메시지 복사본을 저장하고 있는 서버 중 하나에 장애 발생 가능

 ㅁ  이 경우 장애가 발생한 서버에 있는 메시지 복사본은 삭제 되지 않으며 메시지를 수신할 때 장애 서버에 있던 메시지 복사본을 받게 될 수 있음

 ㅁ  따라서 애플리케이션은 같은 메시지를 두 번 이상 처리할 때 부정적인 영향을 미쳐서는 안됨

 

-  메시지 샘플

 ㅁ  대기열에서 메시지를 검색하는 동작은 짧은 폴링, 기본 동작 또는 긴 폴링 중 어느 것을 사용하는지에 따라 달라짐

 ㅁ  짧은 폴링의 경우

    Queue에서 메시지를 검색할 때 Amazon SQS가 서버의 서브넷을 샘플로 하여 해당 서버에서만 메시지를 반환, 즉 특정 수신 요청은 모든 메시지를 반환하지 않을 수 있음

    즉, 특정 수신 요청은 모든 메시지를 반환하지 않을 수 있음

    또한 Queue에 있는 메시지 수가 많지 않은 경우(1,000개 미만), 특정 요청은 어떤 메시지도 반환하지 않고, 다음 요청에서 메시지가 반환 될 수 있음

    Queue를 계속해서 검색하면, Amazon SQS에서 모든 서버를 샘플로 하게 되므로 모든 메시지를 수신하게 됨.

 

3.6 Amazon SQS 주요 기는ㅇ

 

3.6.1.  가시성 제한 시간

 

가시성 제한 시간은 여러 구성 요소가 같은 메시지를 처리하는 것을 방지

-  메시지를 수신하면 처리하는 동안 ‘잠김’ 상태가 되며, 이는 다른 구성 요소에서 해당 메시지를 처리하는 것을 방지

-  메시지를 수신한 구성 요소는 메시지를 처리한 다음, 이를 대기열에서 삭제

-  메시지 처리에 실패하면, 잠금이 해제되면서 메시지가 다시 처리 가능한 상태로 바뀜(내결함성)

 

3.6.2.  배달 못 한 편지 대기열(Dead Letter Queue, DLQ)

 

배달 못 한 편지 대기열은 처리되지 못한 메시지 대기열임

-  DLQ는 최대 처리 시도 수에 도달한 후에 메시지를 수신

-  DLQ는 대역 외 분석을 위해서 처리할 수 없었던 메시지를 분리하는 기능을 제공

-  배달 못 한 편지 대기열을 사용하는 이유는?

 ㅁ  성공적으로 처리되지 못 한 메시지를 열외로 분리할 수 있음

 ㅁ  FIFO가 활성화된 상태이고 메시지를 처리할 수 없는 경우 메시지 흐름을 복원

 ㅁ  배달 못 한 편지 대기열은 이를 사용하는 다른 대기열과 같은 계정 및 같은 AWS 리전에 상주해야 함.

 

3.6.3.  리소스 기반 권한: 대기열 공유

 

-  공유 대기열

 ㅁ  대기열은 다른 AWS 계정 및 익명 사용자와 공유 가능

 ㅁ 권한은 다른 사람에게 특정 방법으로 자신의 대기열을 사용할 수 있는 액세스 권한을 부여

 ㅁ  정책은 부여한 권한이 포함된 실제 문서

 

-  대기열 액세스를 공유하면 비용은 누가 지불

 ㅁ  공유 대기열 액세스 비용은 대기열 소유자가 지불

 

3.6.4. Amazon SQS 사용 사례

 

-  작업 대기열

 ㅁ  동일한 양의 작업 일부를 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리

 

-  배치 작업 버퍼링

 ㅁ  아키텍처에 확장성과 안정성을 더하고, 메시지를 손실하거나 지연 시간을 늘리지 않고 일시적은 볼륨 스파이크를 원활하게 처리

 

-  요청 오프로딩

 ㅁ  요청을 전송하여 대화식 요청 경로에서 속도가 느린 작업을 제거

 

-  팬아웃

 ㅁ  Amazon SQS를 Amazon SNS와 결합하여 동시 처리를 위해 병렬로 여러 대기열에 메시지의 동일한 사본을 보냄

 

-  Auto Scaling

 ㅁ  Amazon SQS 대기열을 사용하여 애플리케이션의 로드를 결정하고, Auto Scaling과 결합할 시기를 결정하며, 트래픽 볼륨에 따라 Amazon EC2 인스턴스 수를 확장 또는 축소 가능

 

4. Amazon Simple Notification Service (SNS)

 

4.1. Amazon SNS 기본

 

Amazon SNS를 사용하면 알림을 설정 및 운영하고 구독 서비스 기타 애플리케이션에 알림을 전송할 수 있음

-  주제별 메시지 게시 가능

 

-  해당 주제의 구독자가 메시지를 수신

 

-  모바일 푸시 메시징

 ㅁ  Amazon SNS를 사용하면 API 또는 사용이 간편한 관리 콘솔을 통해 모바일 디바이스나 분산 서비스로 메시지를 푸시 할 수 있음

 

-  SNS를 사용해 주제별로 여러 수신자를 그룹화 가능

 

4.2. Amazon SNS 구독자 유형

 

-  이메일 (일반 또는 JSON)

-  HTTP/HTTPS

-  SMS(문자 서비스) 클라이언트

-  Amazon SQS 대기열

-  모바일 푸시 메시징

-  AWS Lambda 함수

 

4.3. Amazon SNS 특성

 

-  단일 게시 메시지

 ㅁ  모든 알림 메시지에는 게시 메시지가 하나만 포함

-  순서는 보장되거나 관련되지 않음

 ㅁ  Amazon SNS는 게시자가 주제에 게시한 메시지를 그 순서 그대로 전송하려고 시도

 ㅁ  네트워크 문제 등으로 구독자에게 순서가 바뀌어 전송 가능

-  회수 안됨

-  HTTP/HTTPS 재시도

-  메시지당 최대 256KB

 ㅁ  게시된 데이터의 64KB 청크마다 1개의 요청으로 청구됨

 ㅁ  예를 들어 256KB 페이로드를 사용하는 단일 API 호출은 4개의 요청으로 청구

 

4.4. Amazon SNS와 Amazon SQS 차이

 

Amazon SQS와 Amazon SNS 모두 AWS의 메시징 서비스

구분	Amazon SNS	Amazon SQS
메시지 지속성	아니요	예
전송 메커니즘	푸시(수동적)	풀링(능동적)
생산자/소비자	게시/구독	송신/수신
배포 모델	일대다	일대일

 

5. SNS/SQS 사용 사레: 팬아웃

 

-  Amazon SNS 사용 시 애플리케이션에서 정기적으로 업데이트를 확인하거나 폴링 할 필요 없이 푸시 메커니즘을 통해 다수의 구독자에게 타임 크리티컬 메시지를 보낼 수 있음

- Amazon SQS는 분산 애플리케이션이 폴링 모델을 통해 메시지를 교환하는 데 사용하는 메시지 대기열 서비스로, 각 구성 요소를 동시에 사용하지 않고도 전송 및 수신 구성 요소를 결합 해제하는 데 사용 가능

-  위 예에서는 SNS를 통해 이미지가 업로드 되었다는 알림을 확인 한 후 3개의 SQS를 사용하여 썸네일, 모바일용 크기, 웹용 크기 조정을 진행하는 아키텍처 예를 볼 수 있습니다.

- 팬아웃 전체 아키텍처

 

6. 마이크로 서비스 기본 아키텍처 예

7. Amazon MQ

 

7.1 Amazon MQ란?

 

Amazon MQ는 Apache ActiveMQ(http://activemq.apache.org )를 위한 관리형 메시지 브로커 서비스

-  클라우드에서 메시지 워크플로를 설정하고 운영

-  고가용성(HQ)을 위해 자동으로 프로비저닝

-  ActiveMQ 콘솔을 직접 액세스

-  다양한 메시징 기술을 지원

-  JMS, NMS, AMQP, STOMP, MQTT 및 WebSocket

-  기존 메시징 코드를 다시 작성할 필요 없음

 

7.2. Amazon MQ 특징 

 

-  메시지 페이로드(최대 32MB)

-  JMS 로컬 및 분산(XA) 트랜잭션 지원

-  99.99999%의 메시지 내구성

-  초기 투자, 최소 수수료 없음

-  메시징 인스턴스 및 스토리지 사용에 대한 종량 과금제

-  mq.t2.micro 인스턴스에서 750시간 포함 프리티어

-  1년 동안 1GB/월 포함 프리티어

 

8. 기타 AWS 기반 결합 해제 서비스

 

8.1 Amazon DynamoDB

 

DynamoDB는 높은 처리량으로 처리 결과를 저장 및 검색하는데 적합한 솔루션

느슨하게 결합된 시스템은 DynamoDB와 같은 관리형 NoSQL 데이터베이스 솔루션과 원활하게 연동됨.

-  고가용성

-  내결함성

-  완전 관리형

 

8.1.1.  Amazon SQS 및 DynamoDB의 예제 패턴

     

8.1.2.  Tokyu Hands Architect 예

https://aws.amazon.com/ko/blogs/aws/how-tokyu-hands-architected-a-cost-effective-shopping-system-with-amazon-dynamodb/

How Tokyu Hands Architected a Cost-Effective Shopping System with Amazon DynamoDB | Amazon Web Services

 

8.2. Amazon API Gateway

 

8.2.1.  Amazon API Gateway 개요

 

애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스 할 수 있도록 ‘현관문’ 역할을 하는 API를 생성 할 수 있음

완전 관리형이며, 수십만 개의 동시 API 호출을 수락 및 처리하는 데 관련된 모든 작업을 처리

다음에서 실행되는 워크로드를 처리할 수 있음

-  Amazon EC2

-  AWS Lambda

-  모든 웹 애플리케이션

 

8.2.2.  Amazon API Gateway 기능

 

-  다양한 버전과 단계의 API를 호스팅 및 사용

-  개발자에게 API 키를 생성하여 배포

-  서명 버전 4를 활용하여 API에 대한 액세스 승인

-  요청을 제한하고 모니터링하여 백엔드 보호

-  AWS Lambda와 긴밀하게 통합

-  AWS Marketplace와 통합

-  프라이빗 VPC와 엔드포인트 통합

 

8.2.3.  Amazon API Gateway의 이점

 

-  관리형 캐시를 사용하여 API 응답을 저장

-  Amazon CloudFront를 통해 지연 시간 단축 및 분산 서비스 거부(DDoS) 보호

-  iOS, Android 및 JavaScript용 SDK 생성

-  OpenAPI Specification (Swagger) 지원

 ㅁ  Swagger는 RESTful 웹 서비스를 설명, 생산, 소비 및 시각화하기 위한 사양 및 완전한 프레임워크 구현

-  요청/응답 데이터 변환

 

8.2.4.  API Gateway를 사용한 서버리스 아키텍처

 

-  API Gateway가 백엔드에 대한 요청의 응답을 수신 후 해당 응답을 자체 캐시에 캐싱

-  동일한 요청이 다시 들어오면 API Gateway는 해당 요청을 백엔드에 확인할 필요 없이, 캐시에서 확인하여 반환

 

8.3. AWS LAMBDA 

 

8.3.1.  AWS Lambda란?

 

-  AWS Lambda는 고가용성과 제한된 비용으로 데이터를 처리하는데 적합한 솔루션

-  AWS Lambda를 사용하면 기존 서버를 간단한 마이크로 프로세스로 대체하여 인프라를 결합 해제 가능

 

8.3.2.  AWS Lambda 특징

 

-  서버를 프로비저닝 하거나 관리하지 않고 코드 실행

-  사용한 컴퓨팅 시간에 대해서만 비용을 지불

-  코드를 실행하지 않을 때 비용 발생하지 않음

-  AWS 서비스에서 자동으로 트리거되도록 코드 설정

-  모든 웹이나 모바일 앱에서 직접 호출

-  AWS Marketplace와 통합

 

8.3.3.  AWS Lambda를 사용한 서버리스 컴퓨팅

 

AWS Lambda는 다음과 같은 이벤트 발생 후 수 밀리초 내에 코드 시작

-  이미지 업로드

-  인-앱 활동

-  웹 사이트 클릭

-  연결된 디바이스의 출력

다음의 경우 AWS Lambda를 고려

-  간단한 함수 또는 처리 애플리케이션을 실행하는 데 전체 인스턴스를 사용하고 있는 경우

-  HA, 조정, 배포 또는 관리에 대해 신경 쓰고 싶지 않은 경우

 

8.3.4.  AWS Lambda 함수의 트리거

 

8.3.5.  AWS Lambda를 통해 리소스 크기 조정

 

-  AWS Lambda 는 현재 다음과 같은 범위에서 23개의 다양한 리소스 할당 수준 제공

 ㅁ  128MB의 메모리와 가장 낮은 CPU 파워에서

 ㅁ  3GB의 메모리와 가장 높은 CPU 파워

-  CPU 집약적 워크로드의 경우 더 많은 리소스 = 더 짧은 지연 시간

-  컴퓨팅 가격은 리소스 수준에 따라 달라짐

-  함수는 100밀리초에서 5분 사이로 실행 될 수 있음

-  프리티어: 100만 건의 무료 요청 및 월별 400,000GB/S 의 컴퓨팅 시간

-  AWS Lambda 요금제

 ㅁ  https://aws.amazon.com/ko/lambda/pricing/

 

8.3.6.  AWS Lambda 사용 방법

-  코드를 AWS Lambda에 업로드 (zip 형식)

 ㅁ  콘솔의 편집기에서 직접 코드 작성, Amazon S3 버킷에서 가져올 수 있음

-  예약된 함수: 실행 빈도 지정,
이벤트 중심의 함수: 이벤트 소스 파악

-  필요한 컴퓨팅 리소스를 지정 (메모리 128MB ~ 3GB)

-  제한 시간 기간을 지정

-  액세스해야 하는 리소스의 VPC를 지정

-  함수를 시작. 끝

 

8.3.7.  AWS Lambda 사용 예시

-  JavaScript를 사용하는 정적 HTML은 Amazon S3가 제공

-  브라우저에서 수행된 작업에 대한 응답으로 Lambda 코드를 실행

-  AWS Lambda 함수는 DynamoDB 테이블에 쓰고 Amazon SNS 주제로 알림을 푸시

 

8.3.8.  일반적인 데이터 처리 솔루션

        

온프레미스에서 사용되는 일반적인 데이터 처리 솔루션의 예

①. 데이터 소스에서 시작하며, RDBMS, 데이터웨어하우스, 검색 또는 메시지 서비스, 기타 대규모 데이터 스토어가 데이터 소스가 될 수 있음

②. 서버 집합이 변경 사항(업데이트된 필드, 새 데이터, 삭제된 데이터 등)이 있는지 데이터 소스를 폴링

   i. 애플리케이션이 찾도록 설계된 것이 무엇이든 서버 집합은 이러한 변경 사항이 발행할 때까지 계속 실행

③. 지정된 변경 사항이 탐지되면, 서버 집합이 작업을 대기열 서비스로 푸시

④. 작업자 집합이 작업을 위해 해당 대기열을 폴링하고, 작업이 발견되면, 가져와서 처리를 수행

⑤. 이 솔루션의 고가용성을 보장하기 위해, 백업/장애 조치 사이트가 생성 및 유지되므로 프로세스 일부에 장애가 발생해도 작업은 중단되지 않음

위 경우는 매우 복잡한 다중 구성 요소 시스템으로, 상당한 유지 관리가 필요하고 낭비되는 리소스가 생김

 

8.3.9.  AWS Lambda를 사용한 데이터 처리

9. 결합 해제 예

 

9.1. 예시 1 : 안전한 설문 조사 제공

         

이 예에서는 서버리스 아키텍처가 안전한 설문 조사를 제공, 전송 및 처리하며, 모든 작업이 관리형 서비스에서 수행됨

①.    고객이 HTTPS를 통해 웹 사이트를 요청. 웹 페이지는 Amazon S3에서 직접 제공

②.    고객이 설문 조사는 AJAX호출을 통해 Amazon API Gateway로 제출

③.    Amazon API Gateway는 AJAX 호출을 AWS Lambda 함수의 이벤트 트리거로 변환하여 AWS Lambda 함수가 설문 조사 데이터를 가져와서 처리

④.    AWS Lambda 함수가 Amazon S3 버킷으로 설문 조사 결과를 전송, 결과는 버킷에서 서버 측 암호화로 보안

⑤.    개인 식별 정보가 포함되지 않은 설문 조사의 메타데이터는 DynamoDB 테이블에 작성 및 저장. 메타데이터는 나중에 쿼리 및 분석에 사용 될 수 있음

 

9.2 예시 2: Amazon CloudWatch Logs 처리

 

         

이 예에서는 서버리스 아키텍처가 다양한 용도로 로그를 처리

①.    Lambda 함수는 로그가 지정된 Amazon S3 버킷에 저장되자마자 로그를 가져옴

②.    로그를 읽고 중요한 결과를 DynamoDB 테이블에 저장하여, 다른 애플리케이션이 해당 데이터를 읽을 수 있도록 함

③.    로그를 다양한 형식으로 변환하고 새 로그 파일을 Amazon S3에 다시 저장 가능

④.    또한, 사전 처리된 데이터를 Amazon Redshift 클러스터로 전송

⑤.    Amazon Redshift 클러스터가 이를 사용하여 로그에 대한 분석 작업을 수행하고, 대상에 최적화된 방식으로 최종 사용자에 대한 통찰력을 제공함

 

9.3 예시 3: 실시간 메시지 처리 워크플로

 

         

이 예에서는 대용량 실시간 메시징 시스템 처리하는 예를 보여줌

①.    Lambda 함수는 새 메시지를 탐지하고, 수 밀리초 이내에 실행을 시작

②.    메시지의 컨텐츠를 해석한 후, 필요에 따라 Amazon SNS의 다른 주제에 정보를 전송하여 애플리케이션의 다른 파트에서 이를 사용할 수 있도록 함

③.    또한 함수는 대용량 메시징 시스템과 같은 높은 처리량의 스트리밍 데이터를 처리하도록 설계된 Amazon Kinesis에 정보를 전송

 

9.4 예시 4: CRUD 백엔드 워크플로

 

 

         

AWS Lambda 함수를 CRUD 백엔드로 사용하여, 데이터베이스에 저장할 지 Amazon S3와 같은 파일 스토어에 저장할지 등 다양한 종류의 API 호출을 지능적으로 처리 가능