[Udemy] Apache Kafka 시리즈 - 초보자를 위한 아파치 카프카 강의 v3

 

 

저번 글에서는 Udmey 의 Docker & Kubernetes 실전 가이드 강의를 후기작성하였습니다.

이번 블로그 챌린지에서 Udemy 인강 2개를 제공해주셨기 때문에 그 중 하나인 Apache Kafka 시리즈 - 초보자를 위한 아파치 카프카 강의를 소개하고자 합니다.

 

 

왜 Kafka 강의를 선택했는가?

 

https://www.osckorea.com/post/blog-02

 

Apache Kafka 는 오픈 소스 분산형 스트리밍 플랫폼입니다. 단어 뜻 그대로 오프된 소스코드를 가진 소프트웨어이며, 데이터를 실시간으로 처리하고, 처리된 결과를 다른 시스템으로 전송하는 플랫폼의 역할을 합니다.

 

 

https://always-kimkim.tistory.com/entry/kafka101-broker

 

 

위의 그림처럼 이벤트나 정보를 수집한 Producer 애플리케이션이 요청을 하게 되고, 이를 Consumer 애플리케이션이 수행하게 되는 플랫폼입니다.

 

하나의 애플리케이션에서 모든 요청을 수행하는 모놀리식 아키텍처 (Monolithic Architecture) 에서 점차 MSA (Microsoft Architecture) 로 수요가 생기게 되면서 각 서버 간의 데이터 흐름이 중요해졌습니다. 같은 역할을 하는 서버를 여러대 배포하는 것이 아닌, 서비스에서 해야하는 일을 분리, 분배하고 각 서버 간의 데이터 교류를 통해 역할을 수행하는 형태로 변화하였기 때문입니다.

 

가령, 쇼핑몰의 예를 들면 쇼핑몰의 공지사항에 대한 기능 요청에 대한 비중보다 주문 및 장바구니에 대한 기능 요청 비중이 훨씬 높기 때문입니다. 주문에 대한 기능을 다른 서버로 분리해놓고 보다 높은 사양의 서버를 운영하면 효율적으로 자원과 역할을 수행할 수 있기 때문입니다.

 

그러나 위와 같이 서버가 분리되기 때문에 각 서버간에 이벤트를 전달하는 것이 중요해졌습니다. 상품을 주문하면 주문에 대한 알림 카톡이 오는 것과 같이 다른 서버에 필요한 이벤트를 요청하는 형태입니다.

 

이러한 서버 간 데이터를 실시간으로 전달할 수 있는 도구로 Kafka가 가장 주목을 받고 있었기에 이 강의를 선택하였습니다.

 

https://www.udemy.com/course/apache-kafka-korean/?couponCode=ST20MT50724

 

 

Udemy 의 가장 커다란 차별점은 바로 자막에 있다고 생각합니다.

 

타 온라인 강의 사이트에서는 한국인들이 만든 강의들만 있다보니 여러 인터넷 강의를 접하기가 어렵습니다. 특히 우리나라의 IT 소프트웨어에서는 Java 의 비중이 워낙 높기 때문에 Java, SpringBoot 관련 주제가 많고, 다른 주제에 대해서는 선택의 비중이 높지 않습니다.

 

Udemy 는 글로벌 단위로 인터넷 강의를 제작하기 때문에 자막만 잘 되어 있으면 다양한 선택의 폭으로 필요한 주제를 선택할 수 있습니다.

 

 

 

총 121 개의 강의, 8시간 30분의 강의시간으로 19,000 원에 구매할 수 있는 것은 가격 점에서도 매우 매력적입니다.

 

Kafka 의 공식문서를 따라가면서 강의를 구성하는 것이 아니라 Kafka 내용을 인지하는 것에 필요한 이미지들을 직접 강사님이 만들어 제공합니다.

처음 Kafka 를 접하기 위해 다른 강의를 들었을 때에는 직관적으로 이해되지 않았지만, 이번 강의에서는 강사님이 직관적인 이미지 자료를 제공해주어 이해하기 손쉬웠습니다.

 

특히나 Kafka의 설치부터 CLI, Java 기반으로 Producer, Consumer 애플리케이션을 구축할 수 있는 실습까지 세세하게 안내를 하고 있습니다. 강의의 초반 부에서 기본 이론을 챙긴 후 실습을 쭉 따라가다보면 Kafka 에 대한 기초지식을 잘 쌓을 수 있을 것이라 생각합니다.

 

 

인강을 듣고 난 후의 도전해볼 것?

제가 관심있는 사이드 프로젝트로 예정되어 있는 것은 바로 Group Chatting Server 입니다. 네이버나 트위터 등에서 사용되는 실시간 그룹채팅을 Redis 와 Kafka 이 2개로 나눠서 구현을 해볼 예정입니다.

 

 

Line Live 의 Chatting-Server 아키텍처

Line Live 의 Chatting-Server 아키텍처에서 중점적으로 다뤄보고 싶은 내용은 바로 Redis 의 Pub/Sub 구조입니다.

 

 

사용자 A가 채팅 메시지를 보내면, 채팅 메시지를 받는 사용자들에게 메시지가 즉시 전달되는 것이 아니라 Redis 서버의 내부 처리 큐에 등록하여 순차적으로 처리되는 구조입니다. 우리는 채팅 메시지가 수신자 모두에게 전달되기까지 기다릴 필요 없이 Redis 내부 큐에 등록되기만 하면 작업이 완료되는 것입니다.

 

Redis 의 Pub/Sub 구조를 통해 Chatting-Server 간 메시지 전송도 비동기적으로 처리하여 대량의 메시지를 처리하는 높은 성능을 확보하게 되었습니다.

 

이러한 Redis 의 Pub/Sub 구조의 장단점은 다음과 같습니다.

 

장점

• 높은 성능
  • Redis Pub/Sub 은 대량의 메시지를 처리할 수 있는 높은 성능을 가지고 있습니다.
  • 메시지 처리가 비동기 방식으로 이루어지기 때문에 대규모 메시지 전송에도 빠르고, 안정적으로 처리할 수 있습니다.
• 확장성
  • Redis 의 Pub/Sub 은 여러 개의 서버로 확장하여 클러스터링을 구성할 수 있습니다.
  • 대규모 서비스에서도 높은 확장성을 보장할 수 있습니다.
• 실시간성
  • Redis Pub/Sub 은 메시지를 즉시 처리하여 실시간성을 보장할 수 있습니다.

 

단점

• 지속성
  • Redis Pub/Sub 은 메시지 전송 후 삭제되기 때문에 메시지의 지속성을 보장하지 않습니다.
  • 최대 1회 전송 (at-most-once) 패턴, 메시지가 유실될 수 있으나 최대 1회만 전송한다.
• 대규모 요청에 따른 성능 저하
  • Redis Pub/Sub 은 Push 방식으로 Subscribe 에게 메시지를 밀어주기 때문에 Subscribe 가 많을 수록 성능이 저하될 수 있습니다.

Line Live Chatting-Server 는 Redis Pub/Sub 구조로 인해 메시지 유실 우려에 대해서는 MySQL 에 주기적으로 마이그레이션 하는 방법을 통해 극복을 하였습니다. 현재 네이버 Line Live Chatting Server 는 100대 이상의 인스턴스에서 동작하며 성능과 안정성을 증명해내고 있습니다.

 

 

 

Kafka 기반의 Chatting Server

대규모 채팅 데이터 처리라고 하면 빼놓을 수 없는 키워드 중 하나가 바로 Kafka 입니다.

일단, Kafka 에 대해 간략하게 설명한다면 Kafka 는 Source Application 과 Target Application 의 결합도를 낮추기 위한 메시지큐라고 볼 수 있습니다.

 

 

 

서버 간 데이터 통신을 메시지큐로 처리하여 비동기방식으로 이루어낸 것을 말합니다.

 

Kafka 의 구성요소는 다음과 같습니다.

• Kafka Broker : Kafka Broker 는 카프카가 설치되어 있는 서버 단위를 말합니다.
• Topic : 카프카에서 데이터가 들어갈 수 있는 공간으로 큐의 역할을 합니다.
• Partition : Partition 은 Topic 하나 당 Partition 을 여러개 보유할 수 있으며, 데이터 대기열을 물리적으로 분산된 것을 말합니다.
• Producer : 메시지를 발행하는 주체입니다.
• Consumer : 메시지를 구독하는 주체입니다.

먼저 Kafka 를 사용한다면 chatting-server architecture 가 어떤식으로 구성되는지 아래 예시를 통해 들어보겠습니다.

 

https://www.joinc.co.kr/w/man/12/Kafka/chatting

 

 

• REST API 로 채팅방이 개설 요청을 하게 되면 Chatting-Server 는 Kafka 에 채팅방에 대한 Topic 을 생성합니다.
• Client 는 Chatting-Server 와 WebSocket 방식으로 커넥션을 가져갑니다.
• Client 는 WebSocket 으로 접속할 때 Request 로 던지는 채팅방_아이디를 기준으로 해당 Topic 을 Subscribe 합니다.
• 메시지가 들어올 때마다 채팅방 Topic 을 Subsribe 하는 서버는 Client 에게 메시지를 전달합니다.

 

 

💡 우선 동작하는 건 알겠는데, Kafka 가 채팅 메시지 처리를 하는 것에 있어 장점이 있을까요?

 

 

 

Kafka 는 아래 3가지 장점을 가지고 있습니다.

• High throughput message capacity
  • Kafka 는 고 가용성으로, Producer (Websocket을 받는 Chatting-Server) 가 메시지를 발행하는 순간 Partition 에 메시지를 보관합니다.
  • 분산처리가 가능하기 때문에 짧은 시간 내에 엄청나게 많은 데이터를 Consumer 에게 전달할 수 있습니다.
  • 짧은 시간 내에 많은 데이터를 Consumer 에게 전달할 수 있습니다.
• Scalability 와 Fault tolerant
  • 카프카는 확장성이 뛰어나므로, 브로커 중 몇대가 죽더라도 Replica 로 복제된 데이터로 안전하게 보관할 수 있습니다.
  • 가령, Websocket 으로 연결된 채팅 서버 중 1대가 죽거나 Restart 가 된다 하더라도, 해당 채팅메시지는 Kafka 의 Topic 에 보관되어 있기 때문에 재시작 후 다시 채팅 메시지를 받을 수 있습니다.
  • 기존, 연결이 끊어졌을 때 채팅메시지를 못 받았던 부분을 kafka 를 이용한다면 client 에서 다시 Reconnect 하는 것만으로 이전 채팅 메시지들을 다시 받을 수 있습니다.
• Undeleted log
  • 컨슈머의 그룹 아이디만 다르게 하면 동일한 데이터도 각각 다르게 처리 가능합니다.
  • 동일한 데이터를 채팅서버 메시지 전달용, 통계용, 등등 다양한 데이터파이프 라인으로 활용할 수 있습니다.

 

결론

처음 Kafka를 접하시고, 사용하려고 하시는 분들에게 이 강의를 매우 추천합니다. 이론 부분을 소개해주시는 부분도 필요한 키워들에 대해서 설명해주셔서 배경지식을 갖기도 좋고, 개발하면서 궁금한 부분을 찾아보면서 진행할 수 있게 도와줍니다. 가격적인 측면에서도 저렴한 편이라 Kafka 를 잠깐 맛만 보기위해 알아보는 것에도 매우 좋을 듯 싶네요

위의 사이드프로젝트를 도전해보면서 Udemy 에서 배운 내용과 연관도가 높은 주제는 따로 포스팅해서 다뤄볼 예정입니다.