목차 1. 개요 2. 카프카? 3. 그렇다면 클러스터링은 언제 해야 할까? 4. 클러스터링 환경 구축 ( Docker ) 5. 마치며 개요 최근 업무로 다뤄볼일이 생겼고, 개인적으로도 카프카에 관심이 생겨 책을 통해 학습을 진행하며 공부를 하고 있다. 또한 업무 중, 현재 진행하고 있는 프로젝트의 개선을 진행할 일이 생겼는데 이때 첫 번째로 눈에 띄었던 건 로컬과 테스트환경, 실서버의 카프카가 서로 다른 환경에 있는 문제가 처음 눈에 띄었다. 서로의 환경이 다르기에, 배포 전 완벽한 테스트를 진행하는 것이 어려웠고 이를 통한 사이드 이펙트들이 발생할 수 있다고 생각했다. 그렇기에, 해당 부분에 대해 개선을 진행하였고 이를 기억하고자 글을 작성하게 되었다. 또한, 이런 학습을 기준점으로 삼아 비트코인 프로..

카프카의 구동 원리 ( Pub sub ) Pub / Sub 전송자가 데이터를 보낼 때 직접 수신자로 보내지 않는다는 특징을 가진다. 전송자가 메시지를 보내고 수신자는 이런 메시지를 중계해 주는 중개인을 통해 메시지를 전달받는다 초기의 Pub sub System 초기에는 서버에서 매트릭 서버로 로그를 쌓았다. 하지만 해당 방법자체가 오래가지 않아 장기간 지표값을 분석하려 한다면 해당 대시보드가 제대로 작동되지 않는다는 걸 알게 된다고 한다. 아마, 추측하건대 장기간 지표값을 분석하게 되면 서버 측의 메트릭들을 하나의 UI 서버가 구독하고 있기에, 데이터가 많아질수록 UI의 랜더링이라던지 성능 저하가 발생하는 걸 이야기하지 않을까 싶었다. 해당 아키텍처에서 필요에 의해 하나씩 발전시킨다고 하면 아래의 아키텍..

1. 개요 이전, 비트코인 개선 기를 올린 지 약 두어 달이 지났다. 그동안 동아리 내에서 신규 서비스 : 북마크 아카이빙 서비스 런칭이 얼마 안 남은 시점이기도 하였고 회사 내에서도 신규 프로젝트를 진행하고 개인적인 이런저런 일들이 많아 포스팅이 뒤로 미뤄졌었다. 해당 프로젝트의 경우 단순 “카프카”, “코틀린” 두가지를 학습해 보자라는 취지로 시작했었는데 하다 보니 실시간성을 유지하며 프로젝트를 발전시켜보고 싶었고 이와 더해 최근 관심이 생긴 애플리케이션 아키텍처를 통해 좀 더 고도화를 해보고 싶단 생각이 들었다. 그렇기에, 이번 목표는 다음과 같이 선정해보았다. 기존 애플리케이션 아키텍처 개선 빗썸 Open Websocket을 활용한 실시간 데이터 송수신 나름대로(?)의 MSA 상황을 연출해 보고 ..