현재 캡스톤 프로젝트에는 사용자 개인의 마인드맵 CRUD 과정이 이루어지는 기능이 들어간다.
간단히 말하자면,
1. 사용자가 마인드맵을 생성 (마인드맵의 Root Node 생성)
2. 사용자가 마인드맵을 수정 (마인드맵에서 노드를 생성하고 가지를 뻗어나가는 과정)
이때, 사용자의 지속적인 마인드맵 수정 작업이 이루어지는 로직을 기획하고 있었다.
[x, y 좌표 배치 및 노드 데이터 변경]
현재는 데이터베이스에 직접 end-to-end 방식으로 API를 호출하는 방식으로 아키텍쳐를 구상한 상황이지만, 크게 4가지의 잠재적인 문제점을 내포했다.
1. 시스템 복잡도의 증가
- 중앙화된 데이터 전송 영역이 없어, 데이터의 흐름을 파악하기 어렵고, 시스템 관리가 복잡함.
- 시스템의 일부분에 문제가 발생하면, 연결된 모든 애플리케이션들을 확인해야 함.
2. 데이터 일관성 유지의 어려움
- 데이터가 여러 시스템과 데이터베이스에 분산되어 있는 경우, 한 시스템에서 변경된 데이터가 다른 시스템에 즉시 반영되지 않아 데이터의 일관성을 유지하기 어려움.
3. 데이터 실시간 처리의 어려움
- 전통적인 메시지 큐 시스템이나 데이터베이스는 대부분 배치 처리 방식을 사용함.
- 이는 데이터를 실시간으로 처리하는 것이 어렵다는 것을 의미.
4. 확장성 제한
- 대부분의 전통적인 메시지 큐 시스템은 한정된 리소스 내에서 작동하므로, 대량의 데이터를 처리하는 데 제한이 있음.
- 데이터의 양이 증가하면서 시스템을 확장해야 하는 상황에서 이런 제한이 큰 문제가 될 수 있음.
따라서, 중간에 데이터를 중재해주는 분산 스트리밍 플랫폼의 필요성을 깨닫게 되었고, 해당 프로젝트에서 Kafka를 사용하므로써 데이터 분산 메시지 큐 아키텍처를 활용하고자 한다.
Kafka 란?
Apache 재단에서 관리하는 Kafka 는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 application을 위한 오픈 소스 분산 이벤트 스트리밍 플랫폼.
Kafka 는 세 가지 주요 기능을 결합하여 end-to-end 이벤트 스트리밍을 구현할 수 있다.
- 이벤트 스트림을 지속적으로 발행(publish) & 구독(subscribe)
- 이벤트 스트림을 원하는 만큼 내구성 있고 안정적으로 저장(store)
이러한 특징과 더불어 Kafka 는 확장성이 뛰어나고 탄력적이며 내결함성이 있으며 안전한 방식으로 제공된다.
MOM 아키텍쳐
MOM(Message Oriented MiddleWare)는 Asynchronous 메세지를 사용하는 각각의 응용프로그램 사이의 데이터 송수신을 의미하며 메세지(이벤트) 기반의 매개체이다.
MOM 을 구현한 시스템을 MQ(Message Queue) 라고 하며, 현재 많이 사용되는 오픈소스 MQ 에는 RabbitMQ, Kafka 등이 있다.
Kafka의 기본 구조
1. 프로듀서(Producer)
- Kafka에 메시지를 발행하는 역할을 하는 컴포넌트
- 다양한 데이터 소스로부터 데이터를 가져와 Kafka의 특정 토픽에 메시지를 발행.
2. 브로커(Broker)
- Kafka의 핵심 서버 컴포넌트로, 프로듀서로부터 메시지를 받아서 저장하고, 컨슈머에게 메시지를 전달
- Kafka 클러스터는 여러 브로커들로 구성되며, 각 브로커는 하나 이상의 토픽의 메시지를 저장하고 관리함.
3. 토픽(Topic)
- Kafka에서 데이터를 분류하는 단위
- 프로듀서는 메시지를 특정 토픽에 발행하고, 컨슈머는 토픽을 구독하여 메시지를 소비
- 토픽은 여러 파티션으로 나뉘어질 수 있고, 이를 통해 데이터를 병렬 처리 가능
- 각 파티션은 순서가 보장된 메시지 스트림을 제공하며, 브로커가 클러스터 내에서 파티션을 분산하여 저장
4. 컨슈머(Consumer)
- Kafka의 특정 토픽을 구독하고, 해당 토픽의 메시지를 소비하는 역할
- 하나 이상의 토픽을 구독할 수 있으며, 토픽의 파티션을 동시 소비 가능
기존의 Queue를 활용한 Message Broker 방식과는 다른 이벤트 스트리밍 플랫폼의 장점
Kafka는 큐를 구현하지 않는다.
토픽(Topic)으로 불리는 카테고리에 데이터 집합을 저장하며, 각각의 토픽에 분할된 메시지 로그를 가지고 있다.
즉, 메시지 브로커와 다르게 토픽(Topic)이라는 것이 Event Streamer에 저장된다.
Event producer가 이벤트를 생성하면, 토픽이라고 불리는 이벤트의 레코드 로그를 streamer에 순서대로 기록하게 된다.
그 후 해당 토픽을 구독(subscribe)한 컨슈머에게 전달하게 된다.
메시지 브로커와는 다르게 해당 토픽을 폴링하는 과정에서 Event Stream에서 계속 Topic을 유지함.
따라서 장애 발생 상황에서도 이벤트를 다시 발행할 수 있다!
Kafka와 Zookeeper의 관계
Kafka Cluster란?
- Kafka Broker 들의 모임
- Kafka 는 확장성과 고가용성을 위하여 Broker 들이 클러스터로 구성
- 여러개의 Kafka Broker 로 운영을 하면 동시에 더 많은 데이터를 처리할 수 있으며, 필요에 따라 Broker 을 추가할 수 있음.
- 여러 Kafka Broker 로 구성된 Kafka cluster 에서는 하나의 Broker 가 실패하더라도 다른 Broker 를 통해 고가용성 보장 가능.
Zookeaper와의 관계
- Kafka는 Apache Zookeeper를 사용하여 클러스터를 관리함.
- Zookeeper는 브로커, 토픽, 파티션 등 Kafka의 메타데이터 정보를 저장하고 관리
- Kafka 클러스터의 상태를 일관되게 유지하고, 브로커의 실패 및 복구를 감지하는 등의 역할을 수행함.
- Kafka를 띄우기 위해서 Zookeeper가 반드시 실행돼야 함.
참고
https://dkswnkk.tistory.com/705
'Infra & Cloud' 카테고리의 다른 글
| [Apache Kafka] Kafka Producer의 데이터 멱등성 보장하기 (0) | 2025.03.26 |
|---|---|
| [EC2] 인스턴스 HikariCP Connection 고갈 문제 (1) | 2025.01.28 |
| [Nginx] 413 Request Entity Too Large 오류 (0) | 2024.11.27 |