Spring cloud 02.1 - Kafka

💁🏻 Kafka

카프카는 링크드인에서 제작한 메시지 지향 미들웨어이다. 풀어서 이야기 하면, 어플리케이션 사이에서 서로 연결시켜 데이터를 교환하게 해주고, 이 때에 데이터는 메시지 전달을 통한 방법이라는 것이다. 즉 실시간으로 데이터를 게시, 구독 및 저장할 수 있는 분산형 데이터 스트리밍 플랫폼으로 정의할 수 있다.

 

다음과 같은 상황을 만들어 보았다. 각 사람은 네트워크 통신을 통해 각 사람과 연결된다. 이렇게 하면 좋은 점은 무엇일까?

일단, (물론 처음에만) 쉽고 직관적이다. 보통 이렇게 개발하고 있지는 않은가? 필자는 토이프로젝트나 또는 간단한 개발을 하게 될때 당연히 이러한 구조를 사용한다. 어떤 프로젝트에서 다른 프로젝트를 호출하게 될 때 직접적으로 주소를 요청하여 연결시키고는 한다. 이는 당연히 중간 구조가 없기 때문에 속도가 빠르다는 크나큰 장점이 있다. 우리가 지금껏 제작해온 모놀리식 아키텍처가 바로 위의 구조이다.

그러나 모놀리식 아키텍처의 단점은 spring cloud 1편에서 이야기 했듯이 확장성과 유연성이 어렵다는 것이다. 만약, 7번 사람이 추가된다면 1번부터 3번까지의 사람이 어떻게 연결되어야 하는지, 추가적인 작업은 없는지, 규약이 바뀌지는 않는지 등 여러 가지 요소를 신경써야 한다. 더욱이 시간이나 비용적인 측면에서도 서비스가 커짐에 따라 효율적이지 못하다.

전화기록부가 없는 상태에서 메시지를 직접 보내야한다고 생각해보라. 미리 저장되어 있지 않기 때문에 각자의 번호를 외워 메시지를 보내야 하며, 심지어는 아는 사람이 더욱 많아질수록 골치아프다.. 언제 또 다른 전화번호를 외워야 할지 모르기 때문이다.

이러한 문제점을 해결하기 위해서 다음과 같은 형태를 가지게 되었다.

 

🦴 Kafka 구조

 

자세히는 모르지만 '어떤 무언가'가 중간에 교환기처럼 있고, 각 사람은 메시지 큐가 존재한다. 어떤 무언가는 각 사람에게 '메시지가 왔어요!'라는 메시지를 전달해준다. 아직은 '어떤 무언가'가 뭔지 모르지만 우리는 7번 사람이 추가되어도, 8번 사람이 추가되어도 메시지를 보내는 사람은 '어떤 무언가'의 주소만 기억해내면 된다. 결국은 사람이 추가되어도 추가적으로 개발할 사항들은 대폭 줄어들고, 확장성 면에서도 충분한 이득을 본 것 같다.

이것이 바로 kafka가 하는 핵심 일이다.

실제로 링크드인에서 kafka 서비스 없이 개발할 때에는 다음과 같은 구조를 보여주었다고 한다.

출처 : https://www.confluent.io/blog/event-streaming-platform-1/

그림이 어려워보이면 정상이다!

우리는 이 그림에서 이 흐름만 이해하면 된다. 맨 위의 Apps and Services가 Monitoring, Splunk(데이터 실시간 수집 및 분석), MQ(Message Queue), Relational Databases, Log Appregation 등 많은 서비스에 직접적으로 연결되어 있다는 것을 보면 된다. 만약, 어떤 서비스를 실제로 도입한다고 했을 때에 중간에 하나 넣게 되면 그와 관련된 관계 처리는 어떻게 해야하는지 벌써부터 고민이 된다. 만약 새로운 데이터베이스를 하나 더 도입한다고 하면 그 데이터베이스를 어떻게 놓을건지 한 번 생각해보면 이해가 될 듯 한다.

또한 개발적인 측면에서 보았을 때 개발은 효율적인 측면도 중요하지만 왜 그렇게 설계했을까 하는 부분도 정말 중요한 포인트가 된다. 얽히고 설킨 저 관계들을 보면서 이해하는 부분은 비효율적인 비용이 추가적으로 드는 것이다. 그래서 링크드인은 카프카를 활용하여 데이터 처리 시스템을 재구성했다.

 

출처 : https://www.confluent.io/blog/event-streaming-platform-1/

로그 모니터링, 보안 관리, 실시간 분석 및 데이터 웨어하우스, 스트림 처리들을 kafka의 데이터로부터 받게 되고, 앱 서비스에서 나오는 이벤트 처리를 중앙에서 관리하는 형식으로 바꾸었다. 하나의 kafka 분산 처리가 전체의 흐름을 바꿀 수 있을 만큼 중요한 모습을 볼 수 있다.

기존에는 중앙화된 전송 영역의 부재가 엔드포인트를 서로 엮는데 복잡했고, 각 시스템마다 구현되는 방식이 서로 달라 확장하기가 어려웠다. 만약 이전 링크드인의 데이터 구조였다면 어느 한 곳에서 오류가 발생하더라도 그 원인지를 찾기 어려운 문제까지 발생했을 것이다. 그러나 kafka를 도입하며 서비스 확장에도 용이하며, 추가적인 장점으로 '실시간성 데이터 처리'가 생겼다. 이벤트가 발생해도 바로 요청해서 기다리는 것이 아닌, 메시징 큐에 이벤트를 보내놓고 자신이 수행할 일만 진행하고 있다가 메시징 처리가 끝나면 결과값을 받는 이름바 비동기 처리가 가능해진 것이다.

쉽게 예시를 들어보자. 이전 내용과 다 일맥상통하는데 쉬운 예시가 생각났다.
가끔 알라딘에서 책을 구매하다보면 집 앞에서 받는 택배도 있지만, 가까운 대리점에 가서 책을 픽업해가는 경우가 있다. 이러한 모습은 흡사 kafka와 같다. 알라딘 본사가 producer, 각 대리점은 kafka, 그리고 우리가 consumer가 되는 것이다. 대리점이 있기에 알라딘 본사는 우리의 주소를 생각할 필요가 없고, 대리점에게 책만 보내주면 그 알람이 consumer인 우리에게 도달하여 우리는 책만 가지러 가면 된다.

 

🔠 Kafka 용어 설명

그러면 새로운 용어를 계속 사용해야 하는데, kafka를 이해하기 위해 각 용어를 알아보자

Producer : 메시지를 생산하는 주체, 특정 토픽을 지정하여 메시지를 전달한다.
Consumer : 메시지를 가져오기를 요청. 특정 파티션을 관리하고 있는 파티션 리더에게 요청한다.
Topic : 메시지의 그룹. 프로듀서와 컨슈머 사이의 메시지 큐라고 생각하면 된다. 보통 Topic은 각 메시지 주제에 맞추어 생성한다.
Record : 메시지 또는 데이터.
Broker : kafka가 설치된 서버를 의미한다.
Cluster : apache project application으로 브로커를 구성한 것을 의미한다.

 

⚒️ Spring Cloud Kafka

🔎 Docker으로 kafka 및 zookeeper 설치

본격적으로 kafka에 도전해보자.

Spring cloud 서버 외에도 우리는 kafka server를 추가적으로 구현해야 한다. producer와 consumer는 spring cloud에서 담당한다는 이야기다. kafka를 설치하기 위해서는 docker를 사용하여 편리하게 구축할 수 있으며, docker 설치와 관련해서는 각자가 찾아보길 바란다.

docker으로 kafka와 zookeeper을 설치한다.

// zookeeper 설치
docker pull wurstmeister/zookeeper

// kafka 설치
docker pull wurstmeister/kafka

 

vi으로 docker-compose.yml 파일을 제작하고, 다음 내용을 넣는다.

docker-compose.yml

version: '2'
services:
  zookeeper:
    container_name: zookeeper
    image: wurstmeister/zookeeper
    ports:
      - "2181:2181"
  kafka:
    container_name: kafka
    image: wurstmeister/kafka
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_ADVERTISED_HOST_NAME: 127.0.0.1
      KAFKA_ADVERTISED_PORT: 9092
      KAFKA_CREATE_TOPICS: "test-topic:1:1"
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

 

다시 돌아와서 docker-compose를 실행시킨다.

docker-compose up -d

lazydocker가 다운되어 있는 경우 다음과 같이 상태를 볼 수 있다.

[Mac 기준]
없다면 brew install lazydocker로 다운을 받고
sudo lazydocker를 입력하면 다음과 같은 화면이 나온다.

화면에서 나오는 방법은 q만 누르면 된다.

여기까지 zookeeper와 kafka를 통해 kafka서버를 제작할 수 있게 되었다.
우리가 작업해야하는 두번째 단계는 kafka 내에 topic을 생성하고 producer의 메시지 전송, consumer의 메시지 읽기 및 Spring으로 producer와 consumer의 구현을 해보아야 한다.

다음을 통해 docker으로 띄운 kafka에 들어가보자

docker exec -it kafka /bin/bash

 

kafka 서버에서 topic을 생성하는 방법은 다음과 같다.

kafka-topics.sh --create --topic heony-topic --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1

 

중간에 heony-topic은 필자가 생성한 토픽의 이름이며, 본인이 하고 싶은 토픽 주제를 작성해서 써도 된다.

root@d6f8ae8b644e:/# kafka-topics.sh --create --topic heony-topic --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1
Created topic heony-topic.
root@d6f8ae8b644e:/#

 

앞서 소개한 kafka의 topic을 제작했으며, producer나 consumer 또한 카프카 서버 내에서 구현할 수 있다. 하지만 우리의 목표는 spring cloud를 통해 kafka를 구현하는 것이기 때문에 docker 내에서 구현하는 것을 생략한다.

 

🧑🏻‍💻 Spring boot에서 kafka 생성

spring boot 프로젝트를 생성하다보면 dependencies를 선택하는 부분에서 두 개의 선택지를 볼 수 있다.

두 개의 선택지를 모두 선택할 필요는 없다. 겹치게 되므로.
하지만 무엇이 다른지는 한번 집고 넘어가보자. 

spring-cloud 공식 사이트에서는 spring-cloud-stream-binder-kafka를 추가하게 되는데,
사이트를 돌아다니다 보면 그냥 spring-kafka만을 추가하는 경우가 있다.
예를 들어 다음과 같다.

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

 

spring-kafka와 spring-cloud-stream-binder-kafka와의 차이는 아래 사이트에 잘 나와있다.
https://stackoverflow.com/questions/69335758/difference-between-spring-cloud-kafka-streams-vs-spring-cloud-stream

Difference between Spring Cloud Kafka Streams Vs Spring Cloud Stream?

요약하자면,
Spring for Apache Kafka(위의 spring-kafka와 같음) - 낮은 수준의 기본 라이브러리이며 스프링 부트가 필요하지 않다
Spring Cloud Function - java 8 프로그래밍 모델을 제공하며 이는 spring boot 응용 프로그램과 함께 사용된다.
Spring Cloud Stream - 이벤트 중심 애플리케이션을 위한 프레임 워크이며 spring boot 응용 프로그램에 사용된다.
Spring Cloud Stream Kafka/Kafka Streams - Apache Kafka용 Spring을 활용하여 Spring Cloud Stream binder 구현

결국 상황에 맞는 것을 사용하면 된다. 기능에 따라 분류되므로.

 

🙆🏻 개발

개발은 git에 업로드되어 있는 프로젝트를 이용하는데, 이 외의 카프카 예시보다도 세분화되어 있어 하나의 포스트로 대체해야 할 것 같다. 다음 게시물을 통해 개발이 어떻게 이루어지는지 알아보자.