도커 환경에서의 Kafka UI 설정알림 기능이 제대로 동작하는 지 검증하기 앞서 Kafka 브로커가 설계한 대로 작동하는 지 Kafka UI를 통해 확인해보자. Kafka UI는 Kafka 브로커에 저장된 메시지와 메타데이터를 조회해 시각적으로 표현하는 HTTP 기반의 외부 웹 UI 도구이다. 일반적으로 Docker 컨테이너로 배포되며 브라우저를 통해 Kafka 브로커의 운영 및 모니터링 환경을 제공한다. 다음의 Docker 설정을 통해 브라우저 접속 환경을 구성할 수 있다.kafka-ui: image: provectuslabs/kafka-ui:latest container_name: kafka-ui ports: - "8085:8080" # 호스트의 브라우저는 8085로 접속 가능 env..

도커 환경에서의 Kafka 설정Kafka의 로그 서버는 스프링 애플리케이션과 분리된 외부 브로커로 동작하며, 프로듀서와 컨슈머 클라이언트를 통해 애플리케이션과 통신한다. 따라서 일반적으로 도커 컨테이너나 별도의 서버 환경에서 운영된다. 여기서는 Kafka를 도커 컨테이너 안에서 실행하는 방식으로 설계했다. 스프링 애플리케이션은 로컬 환경에서는 IDE에서, 배포 환경에서는 도커 컨테이너 안에서 실행되므로 어느 환경에서 접속하더라도 도커 내부의 Kafka 브로커를 정확히 식별해 연결해야 한다. 이를 위해 Kafka는 도커 환경에서 포트를 2개 열어 두고, 각각에 리스너를 설정하여 두 가지 방식으로 접근하는 클라이언트와 모두 통신할 수 있도록 구성한다. 도커 내부에서는 클라이언트끼리 직접 연결 가능하므로 외부..

Kafka를 이용한 확장성 문제 해결Kafka는 애플리케이션 외부에서 동작하는 로그 시스템이므로 메시지의 저장 상태를 유지하는 데에 애플리케이션 JVM의 자원을 소모하지 않는다. 따라서 대량의 메시지가 발생하더라도 애플리케이션 처리량에 직접적인 영향을 주지 않는다. 이런 측면에서 Kafka는 처리량 문제를 완화하기도 하지만, 근본적으로 대량의 이벤트 처리를 제어할 수 있는 구조적 수단을 제공하는 것이다. 실제 메시지 처리는 애플리케이션 내부에서 일어나므로 높은 처리량의 핵심은 어느 메시지(작업)를 누가, 언제 소비(처리)하느냐에 달려 있다. 즉, 한정된 JVM 자원을 최대 효율로 활용하는 것은 전적으로 오케스트레이션 방식에 의존한다. Kafka는 자체적으로 대량의 작업을 안정적으로 분배하고 병렬 처리할 ..

Kafka를 적용하게 된 개인적인 문제의식과 수평적 확장성을 보장하는 이벤트 기반 비동기 작업 처리 구조 구축 과정, 그리고 이를 이용해 알림 기능을 구현한 사례를 기록하고자 한다. 이 과정에서 Kafka에 대해 공부하고 개인적으로 정리한 학문적인 내용까지 포함한다. Spring 프로젝트에서 알림 기능을 담당한 적이 있다. 당시 기능 구현에 있어서 기초적인 스키마는 다음과 같다. 알림은 멤버 단위로 관리되므로 멤버 엔티티와 관계 설정이 필요하다. 멤버를 직접 참조하는 알림 엔티티 구조를 사용할 경우, 모든 멤버에게 동일한 내용을 전달하는 공통 알림의 메시지가 레코드마다 중복 저장되고 심각한 공간 낭비가 발생한다. 따라서 메시지와 몇 개의 메타 정보를 저장한 별도의 알림 엔티티를 두고, 알림의 수신 관계..