오늘은 Decoupling에 대해서 간단히 알아보겠습니다!

Decoupling is isolating the code that performs a specific task from the code that performs another task

The Importance Of Decoupling In Software Development

소프트웨어적인 측면에서 디커플링이란, 서로 다른 작업을 하는 코드를 분리시키는 작업을 의미합니다.
모듈화가 대표적인 예가 되겠군요.

그렇다면 디커플링은 왜 필요한 것일까요??

기존의 아키텍쳐

위 그림은 아주 간단한 웹 서비스의 아키텍쳐입니다.
딱 봐도 각각의 컴포넌트들은 다른 컴포넌트들과 강하게 결합되어 있죠
과연 여기서는 어떠한 문제점들이 발생할 수 있을까요?

문제점 1 - 오류의 전파

첫 번째 이유는 바로 오류의 전파입니다.

모종의 이유로 웹 계층의 컴포넌트들 중 하나가 죽었다고 가정해보겠습니다.
그러면 아마 높은 확률로 다른 계층(여기서는 App 계층)에도 해당 오류가 전파될 가능성이 높고
이는 서비스의 가용성에 큰 악영향을 미치게 됩니다!!

문제점 2 - 확장의 어려움

또한 Scale-out을 할 때도 문제가 생깁니다.

웹 티어에서 컴포넌트를 하나 추가하려면 App 티어의 모든 컴포넌트와 새롭게 관계를 맺어줘야 합니다.
이러면 서비스의 원활한 확장이 어렵게 되죠

지금은 각 계층당 컴포넌트의 개수가 3~4개 정도지만... 추후에 서비스가 확장될 경우 서비스의 복잡도는 더욱 올라가게 될 것입니다!!

그래서 기존의 아키텍쳐를 개선하기 위해서 컴포넌트들을 분리, 디커플링을 하게 되는 것입니다.

Apache Kafka

아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다

[위키백과 - 아카치 카프카](https://ko.wikipedia.org/wiki/%EC%95%84%ED%8C%8C%EC%B9%98%EC%B9%B4%ED%94%84%EC%B9%B4)_

Apache Kafka Architecture and Its Components-The A-Z Guide

카프카는 컴포넌트들 사이에서 메세지를 주고 받을 때 사용하면 좋은 라이브러리입니다. Topic을 통해서 Producer와 Consumer사이에서 메세지를 주고 받습니다.

이러한 특성 덕분에 마이크로서비스 개발 환경에서 사용하기에 좋으며, 각 계층 사이의 의존성을 줄이는데 유용합니다.

Amazon SQS

Amazon Simple Queue Service

Standard Queue

SQS의 기본 서비스

Amazon에서 가장 오래된 서비스 중 하나(10년이상 서비스됨)로서 여러 개의 컴포넌트 사이의 메세지를 전달해주는 큐를 제공해주는 서비스입니다.

여러 개의 Producer가 메세지를 생산해섬 큐로 전달하면, 메세지를 수신 받아야 하는Consumer들은 큐를 Poll해서 메세지를 가져온 후, 알맞은 작업을 실행합니다.

• Queue를 사용해서 서비스함
• 낮은 지연시간 (< 10ms)
• 메세지 당 256KB 제한
• 메세지 보관 기한 (4일 ~ 14일)
• 메세지 중복 허용(메세지가 중복으로 전송되는 경우도 있으므로 적어도 한 번의 전송 이라고 표현함)
• 큐 안의 메세지는 consumer가 삭제하기 전까지 지속됨

FIFO Queue

• 메세지의 순서를 정확히 보장해주는 큐 서비스
• 기존의 서비스와는 다르게 약간의 처리량 차이가 존재함.
  - 일반은 300 msg/s
  - 배치 처리를 하면, 3000 msg/s
• 메세지간의 중복을 허용하지 않음

Amazon SNS

Amazon Simple Notification Service

Amazon SNS는 Pub/Sub 형식의 서비스입니다.
Event Producer는 단 하나의 SNS Topic으로 메세지를 전송하고.
많은 Event Receiver, Subscriber는 구독하고 있는SNS Topic으로 전달된 메세지를 수신받죠.

그리고 다음과 같은 특성을 가지고 있습니다!

• Pub/Sub 모델
• Topic 하나 당 12,500,000 구독자를 가질 수 있음
• Topic은 계정당 100,000개 까지

SNS는 다음과 같은 것들을 전달할 수 있습니다.

• Email
• SMS, 모바일 알림
• Http(s) 엔드포인트
• Amazon SQS와 같은 특정 AWS 서비스
• AWS Lambda
  등등..

SNS + SQS (Fan Out)

• 구매 서비스가 실행될 경우 사기 탐지 서비스와 배송 서비스도 호출 되어야 한다.
• 서비스 간의 의존도를 낮추고 싶다... (서비스 간의 호출을 확실하게 하고, 모니터링을 하거나 비정상적으로 종료될 경우 중간에 멈춰야 하기 때문!)

• 연관관계가 존재해야 할 서비스들에 연결된 SQS Queue가 SNS Topic을 구독하게 한다.
• Buying Service는 SNS Topic을 통해서 메세지를 각 서비스에 간접적으로 전달한다.

구매 서비스와 사기 감지, 배송 서비스는 완전히 분리되어 있으므로 하나의 서비스가 손상되어도 다른 서비스에 영향이 가지 않습니다.
그리고 연관된 서비스가 늘어나야 할 경우, SQS Queue에 연결한 후 해당 큐가 SNS Topic을 구독하도록 하면 서비스가 간단히 확장될 수 있습니다.

간단하게 서비스를 붙일 수 있다.

Amazon Kinesis

Kinesis는 실시간 스트리밍 데이터를 손쉽게 수집, 처리, 분석할 수 있도록 도와주는 AWS의 서비스입니다.
실시간 데이터는 App 로그, 측정, 웹 사이트 방문 스트림, IoT 원격 로그 등이 포함되죠

Kinesis에는 총 4가지 서비스가 존재합니다.

• Kinesis Data Stream
• Kinesis Data Firehose
• Kinesis Data Analytics
• Kinesis Data Video Stream

그 중에서 오늘은 실시간 데이터를 전달해주는 Kinesis Data Stream과, Kinesis Data Firehose에 대해서 알아보도록 하겠습니다

Kinesis Data Stream

Kinesis Data Strea은 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스입니다.
여러 개의 샤드로 구성되어 있으며(샤드의 개수는 사전에 정의함), Kinesis Data Strea로 들어오는 데이터는 모든 샤드에 분배 됩니다.

Stream에 데이터를 집어넣는 Producer는

• 어플리케이션
• 데스크톱, 휴대폰과 같은 클라이언트
• Low level의 AWS SDK, High level의 Kinesis Producer Library(KPL)
• Kinesis Agent
  등등이 올 수 있습니다.

Consumer는

• SDK, KPL을 사용하는 어플
• AWS Lambda
• Kinesis Data Firehose, Kinesis Data Analytics
  등이 올 수 있습니다

Record

Stream으로 들어와서 Kinesis Data Stream이 전송하는 데이터를 Record 라고 부릅니다.
Partition Key와 Data Blob인데요.
Partition Key의 경우에는 레코드가 사용할 샤드를 결정하고,
Data Blob은 데이터 그 자체를 의미합니다.(최대 1MB)

스트림 안에 들어온 데이터는 1~365일까지 보관이 가능하며, 스트림에 한 번 들어온 데이터는 삭제할 수 없습니다!

Kinesis Data Firehose

Kinesis Data Firehose는 스트림과는 다르게 Data Transfer 서비스입니다!
완전 관리형 서비스로 용량이 자동으로 조정되며, 서버리스이므로 관리할 서버가 존재하지 않는 서비스이기도 하죠!
Producer로 부터 데이터를 가져올 수 있는 유용한 서비스입니다.

Producer는 Kinesis Data Stream의 모든 Producer와 각종 다른 AWS 서비스들이 포함되고
Consumer는

• 서드파티 서비스
• AWS 서비스
• 자체 제작 서비스
  등으로 크게 구분됩니다.

Firehose는 Stream과는 다르게 데이터를 전달하는 것이 목적이다 보니
데이터를 보관하지 않습니다.

그리고 단일 Destination을 가지는 close-end 모델입니다.

SQS vs SNS vs Kinesis

Amazon SQS	Amazon SNS	Kinesis
Consumer가 데이터를 pull 한다	다수의 구독자들에게 데이터를 전달한다	표준 모드(pull)에서는 샤드 하나당 2MB/s 의 속도를 지원
Consumer가 데이터를 처리하면 큐에서 데이터는 삭제된다.	한 번 전송된 데이터는 지속되지 않음 (데이터를 잃을 수도 있음)	향상된 팬아웃모드에서는 Consumer에게 데이터를 푸시하며, 샤드 하나당 2MB/s 의 속도가 나옴
Worker나 Consumer의 수에 제약이 없다	SNS Topic당 1250만 명이 구독 가능	데이터가 지속되므로 데이터를 다시 소비할 수 있음
관리형 서비스이므로 처리량을 프로비저닝 할 필요 없음	최대 10만개의 Topic 까지 확장 가능	실시간 빅데이터 분석과 ETL에 사용됨
순서를 보장하고 싶으면 FIFO 큐를 사용해야 함	SQS와 결합 가능 (fan-out)	데이터를 1~365일까지 보관 가능
메세지를 일정 시간 지연시킨 뒤 큐에 넣을 수 있음

참고

• AWS Certified Solutions Architect Associate 시험합격!