디커플링, SQS, SNS

디커플링 :

서로 결합이 되어 있는 것을 분리시키는 작업.

어떻게 하면 좀 더 유연하게 아키텍처링을 할 수 있을까에 대한 고민에서 나왔다. 

 

예를 들어 

피자 주문은 [업체 연락, 돈 차감, 레코드 갱신] 과 연관되어 있다. 

'주문 이메일 발송'이라는 새로운 로직이 추가되었다고 하자. 

'주문 이메일 발송'이라는 애플리케이션 로직을 업데이트함과 동시에 '피자 주문' 애플리케이션도 업데이트가 불가피하다. 

이러면 '긴밀한 결합'이 되어 있다고 부른다. 

 

이것을 어떻게 유연하게 만들 수 있을까?

이렇데 하면, 주문 애플리케이션을 하는 일이 이벤트 큐에 주문을 밀어넣는 것 하나밖에 없다. 

그럼 이벤트 큐를 다른 모듈들이 구독하고 있다가 변화가 생기면 각자 일을 하는 것이다. 

만약 '배달업체 연락'이라는 로직을 추가한다면, 

메시지 큐에 붙이기만 하면 된다. 

주문 애플리케이션은 오른쪽 로직이 바뀌더라도 하나도 바뀌는게 없다. 

주문 애플리케이션과 처리 로직은 분리가 되어있기 때문이다. 

 

중간에 이벤트 큐를 두는 부분이 바로 디커플링이다.

 

그러면 AWS의 대표적인 디커플링 서비스는?

 

1. Amazon Simple Queue Service (SQS)

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

 

> Amazon SQS

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

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

    - 최대 사이즈 : 256kb, 최대 14일까지 저장 가능   (S3에 업로드하고, 그 주소를 넣으면 때문에 실질적으로 저장할 수 있는 사이즈는 무한이다. )

- 주로 AWS 서비스들의 느슨한 연결을 수립하기 위해 사용

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

- AWS에서 제일 오래된 서비스 

 

 

> SQS를 활용하는 디커플링

- 예제 시나리오 

    - 사용자가 업로드한 동영상을 기반으로 모델링을 만드는 서비스 

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

    - 사용자가 몰리는 시간 (오후 2시)과 한가한 시간 (새벽 2시)이 존재 

    - 주기적으로 오토스케일링 필요 

 

 

> 디커플링 없는 아키텍처

제일 먼저 문제가 되는 건, 모든 인스턴스에서 S3 객체를 동시에 가져갈 수 있기 때문에 교통정리 역할을 해주는 마스터 노드가 필요하다. 

두번째는, 클러스터가 터지면, 더 이상 이벤트 처리가 안 될 수 있기 때문에 그대로 유저가 업로드한 영상이 증발해 버릴 수도 있다.

그리고 로직을 바꾸기가 굉장히 어렵다. 

 

 

> Amazon SQS

S3에서 파일을 업로드 하자마자 SQS로 바로 전송한다. 

SQS 대기열이 있고, 인스턴스 각각에서 큐에서 하나씩 빼서 처리를 한다. 

SQS는 하나의 메시지를 한 번만 처리한다. 다른 인스턴스에서 처리하고 있을 때는 다른 인스턴스에서 처리하지 못한다.

따라서 효율적으로 분사해서 유니크 잡을 처리할 수 있다. 

 

처리대기 큐의 용량에 따라서 오토스케일링을 할 수가 있다. 

큐에 대기가 많아지면 EC2를 늘리고, 대기열이 적으면 EC2를 죽이는 방법으로 간단하게 오토 스케일링할 수가 있다. 

 

만약 EC2들이 터지면?

이전에는 업로드하고 아무 처리 안하면 끝이었는데, 이번에는 SQS에 그대로 메시지들이 저장이 되어 있기 때문에 다음에 다시 EC2 인스턴스가 살아나면 큐에 저장되어 있는 메시지들을 다시 처리하기만 하면 된다. 

이런식으로 안정성을 확보할 수 있다. 

하나의 EC2에서 영상처리를 하다가 터졌다 하더라고, SQS에서는 메시지가 살아있기 때문에 다른 EC2 인스턴스가 그대로 들고가서 처리하면 된다. 

 

 

동영상 전처리 로직을 추가하게 되면, 디커플링에 따라 전처리 큐를 앞에 추가해준다. 

 

 

 

2. Amazon Simple Notification Service(SNS)

"Amazon Simple Notification Service(Amazon SNS)는 애플리케이션 간 (A2A) 및 애플리케이션과 사용자간 (A2P) 통신 모두를 위한 완전관리형 메시징 서비스입니다."

 

> Amazon SNS

- Pub/Sub 기반의 메시징 서비스 

    - 하나의 토픽을 여러 주체가 구독

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

- 다양한 프로토콜로 메시지 전달 가능 

    - 이메일

    - HTTP(S)

    - SQS

    - SMS

    - Lambda → 람다를 호출할 수 있으면 거의 모든 걸 할 수 있겠죠?

- 하나의 메시지를 여러 서비스에서 처리

- SQS는 하나의 메시지를 하나의 주체가 처리하는 거였다. 

 

 

 

위에서 언급했던 피자 주문 애플리케이션을 SNS로 구현해 본다면, 

SNS를 통해 동시에 다양한 주체들이 하나의 주문을 처리하게 된다. 

 

 

 

> Fan Out 아키텍처

- 예제 시나리오 

    - 사용자가 동영상을 업로드하면 인코딩을 해야 함 

    - 다양한 해상도로 인코딩이 필요

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

    - 회사 방향에 따라 필터 혹은 다른 해상도 지원을 위한 개발 가능성 있음 

S3에 동영상 업로드하면 여러 EC2들이 하나의 업로드 메시지를 처리한다. 

이렇게 하나의 메시지를 다양한 주체가 처리하는 것을 Fan out 아키텍처라고 한다. 

 

그럼 음원을 추출하는 서비스를 추가적으로 만들고 싶다면?

간단하게 오디오 처리 EC2 인스턴스만 연결하면 된다. 

 

 

SQS와 SNS는 상호 배타적인 서비스가 아니다.