[ AWS ]- 디커플링

긴밀한 결합

: 주체끼리 높은 의존성을 가져 변경이 어려움.

ex) 우리 몸

 

느슨한 결합

: 주체끼리 낮은 의존성을 가져 쉽게 변경할 수 있고 유연함.

ex) 전동 공구, 로봇

 

 

디커플링(확장성)

긴밀한 결합 --> 느슨한 결합

==> 이벤트 큐를 더함

- 모듈들이 큐에서 나온 메세지를 구독하고 들음

- 다른 모듈이 추가되도 기존의 모듈들에 영향을 안끼침.

- 기존 모듈이 수정되도 오류 안생김

 

 

SQS(Simple Queue Service)

- 마이크로 서비스 ,분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메세지 대기열 서비스

- AWS에서 제공하는 큐 서비스

- 다른 서비스에서 사용할 수 있도록 메세지를 잠시 저장하는 용도

- 하나의 메시지를 한번만 처리

 

 

 

SQS를 활용한 디커플링

- S3에 업로드한 동영상을 EC2에서 처리해서 다시 S3버킷으로 업로드

- 사용자가 주로 이용하는 시간대가 다름.

 

 

 

  디커플링이 없는 아키텍처

  - S3에서 전달한 데이터를 여러 EC2가 동시에 받게 될 수 있음(마스터 노드가 따로 처리해줘야함)

  - S3에서 받은 데이터를 EC2가 처리하는 중에 문제가 생기면(처리 못함) -> 처리가 안되서 사용자에게 응답이 안감.

  - 데이터를 가져오는 위치를 S3에서 파일 서버에서 가져오게 된다면 -> 모든 EC2를 업데이트 해야함.

  - Auto Scaling에도 문제: S3에 존재하는 데이터 숫자 만으로 EC2개수 조절하기 어려움.

 

==> 여러 EC2앞에 SQS를 놓는다.

 

 

Amazon SQS

 - S3에서 데이터 업로드 되면 SQS에 자동으로 업로드

- EC2는 SQS에 쌓여있는 데이터를 각각 하나씩 빼서 사용함

- 하나의 EC2가 SQS에서 메세지를 빼서 처리할 때, 다른 EC2들은 아무 동작을 하지 못함

- SQS에 데이터가 많이 쌓여있으면 Auto Scaling을 통해 EC2 개수 조절 가능

- 만일 EC2 중 하나가 문제가 생기면 --> 기존에는 데이터를 처리하지 못했지만, SQS에 데이터가 저장 되어있기 때문에, 다시 처리할 수 있음(다른 EC2가 처리할 수도 있음 / User가 보낸 데이터를 못 보는 일이 없음)

 

 

 

SNS(Simple Notification Service)

- 애플리케이션 <-> 애플리케이션, 애플리케이션 <-> 사용자 모두를 위한 완전관리형 메세징 서비스

- Pub/Sub기반 메세징 서비스

- 토픽에 전달된 내용을 구독한 모든 주체가 전달받아서 처리함.

- 다양한 프로토콜(HTTP, 이메일, SQS, SMS, Lambda) 사용 가능

- 하나의 메세지를 여러 서비스에서 처리할 수 있음

 

 다양한 서비스 앞에 SNS가 위치함.

 

 

Fan Out Architecture

: 하나의 메세지를 다양한 주체가 처리하는 것

-  사용자가 동영상을 업로드하면 다양한 해상도로(인스턴스 여러 개) 인코딩 해야함.

- 동영상 특정부분을 썸네일로 만들어야 함.

- 회사의 방향에 따라 다른 해상도 지원도 할 수 있어야함.

- ex) 오디오 추출 기능 필요 --> 오디오 추출 인스턴스를 만듦