오늘은 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
소프트웨어적인 측면에서 디커플링이란, 서로 다른 작업을 하는 코드를 분리시키는 작업을 의미합니다.
모듈화가 대표적인 예가 되겠군요.
그렇다면 디커플링은 왜 필요한 것일까요??
위 그림은 아주 간단한 웹 서비스의 아키텍쳐입니다.
딱 봐도 각각의 컴포넌트들은 다른 컴포넌트들과 강하게 결합되어 있죠
과연 여기서는 어떠한 문제점들이 발생할 수 있을까요?
첫 번째 이유는 바로 오류의 전파입니다.
모종의 이유로 웹 계층의 컴포넌트들 중 하나가 죽었다고 가정해보겠습니다.
그러면 아마 높은 확률로 다른 계층(여기서는 App 계층)에도 해당 오류가 전파될 가능성이 높고
이는 서비스의 가용성에 큰 악영향을 미치게 됩니다!!
또한 Scale-out을 할 때도 문제가 생깁니다.
웹 티어에서 컴포넌트를 하나 추가하려면 App 티어의 모든 컴포넌트와 새롭게 관계를 맺어줘야 합니다.
이러면 서비스의 원활한 확장이 어렵게 되죠
지금은 각 계층당 컴포넌트의 개수가 3~4개 정도지만... 추후에 서비스가 확장될 경우 서비스의 복잡도는 더욱 올라가게 될 것입니다!!
그래서 기존의 아키텍쳐를 개선하기 위해서 컴포넌트들을 분리, 디커플링을 하게 되는 것입니다.
아파치 카프카(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 Simple Queue Service
SQS의 기본 서비스
Amazon에서 가장 오래된 서비스 중 하나(10년이상 서비스됨)로서 여러 개의 컴포넌트 사이의 메세지를 전달해주는 큐를 제공해주는 서비스입니다.
여러 개의 Producer
가 메세지를 생산해섬 큐로 전달하면, 메세지를 수신 받아야 하는Consumer
들은 큐를 Poll해서 메세지를 가져온 후, 알맞은 작업을 실행합니다.
consumer
가 삭제하기 전까지 지속됨Amazon Simple Notification Service
Amazon SNS
는 Pub/Sub 형식의 서비스입니다.
Event Producer
는 단 하나의 SNS Topic
으로 메세지를 전송하고.
많은 Event Receiver, Subscriber
는 구독하고 있는SNS Topic
으로 전달된 메세지를 수신받죠.
그리고 다음과 같은 특성을 가지고 있습니다!
SNS는 다음과 같은 것들을 전달할 수 있습니다.
Amazon SQS
와 같은 특정 AWS 서비스AWS Lambda
SQS Queue
가 SNS Topic
을 구독하게 한다.Buying Service
는 SNS Topic
을 통해서 메세지를 각 서비스에 간접적으로 전달한다.구매 서비스와 사기 감지, 배송 서비스는 완전히 분리되어 있으므로 하나의 서비스가 손상되어도 다른 서비스에 영향이 가지 않습니다.
그리고 연관된 서비스가 늘어나야 할 경우, SQS Queue
에 연결한 후 해당 큐가 SNS Topic
을 구독하도록 하면 서비스가 간단히 확장될 수 있습니다.
간단하게 서비스를 붙일 수 있다.
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 Strea
은 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스입니다.
여러 개의 샤드로 구성되어 있으며(샤드의 개수는 사전에 정의함), Kinesis Data Strea
로 들어오는 데이터는 모든 샤드에 분배 됩니다.
Stream에 데이터를 집어넣는 Producer
는
Consumer는
AWS Lambda
Kinesis Data Firehose
, Kinesis Data Analytics
Stream으로 들어와서 Kinesis Data Stream
이 전송하는 데이터를 Record 라고 부릅니다.
Partition Key와 Data Blob인데요.
Partition Key의 경우에는 레코드가 사용할 샤드를 결정하고,
Data Blob은 데이터 그 자체를 의미합니다.(최대 1MB)
스트림 안에 들어온 데이터는 1~365일까지 보관이 가능하며, 스트림에 한 번 들어온 데이터는 삭제할 수 없습니다!
Kinesis Data Firehose
는 스트림과는 다르게 Data Transfer 서비스입니다!
완전 관리형 서비스로 용량이 자동으로 조정되며, 서버리스이므로 관리할 서버가 존재하지 않는 서비스이기도 하죠!
Producer로 부터 데이터를 가져올 수 있는 유용한 서비스입니다.
Producer는 Kinesis Data Stream
의 모든 Producer와 각종 다른 AWS 서비스들이 포함되고
Consumer는
Firehose는 Stream과는 다르게 데이터를 전달하는 것이 목적이다 보니
데이터를 보관하지 않습니다.
그리고 단일 Destination을 가지는 close-end 모델입니다.
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일까지 보관 가능 |
메세지를 일정 시간 지연시킨 뒤 큐에 넣을 수 있음 |