카프카는 과하다
Kafka는 훌륭한 도구지만 PostgreSQL로도 어지간한 지점까지 MQ를 쓸 수 있다는 글. OpenAI조차 아직도 단일 PostgreSQL 쓰기 인스턴스로 운영하고 있고, Figma도 2022년까지 샤딩 없는 PostgreSQL로 서비스를 운영했다. 실행 가능한 최소한의 인프라에 굉장히 동의한다. - Haze
최근에 프로젝트 적용한 EFK 스택이랑 인프라 관련해서 살펴보다가 관련 글이 떠서 관심있게 보기로 했다. 블로그 내용은 해당 글을 읽고 나름대로 주절주절한 내용이다.
내용
기술계는 두 진영
유행을 쫓는 진영과 상식을 쫓는 진영
카프카 세계가 특히 전자에 속한다. 그들은 ‘혁신적인 아키텍처’를 추구하며 최신 기술을 좇는다.
후자는 불필요한 복잡성을 제거하고 과도하게 설계된 솔루션을 경계한다.
결국은 기본 원칙을 고려해야 한다. 최신을 경계하고 회의론적 시각으로 접근한다.
역사적으로 전자가 목소리가 컸지만 현재 2가지 흐름으로 후자의 의견이 강해지고 있다.
첫째는 스몰 데이터 운동.
사실 데이터는 그렇게 크지 않다. 또 컴퓨도 커지고 있다.
즉 기본 용량, 피지컬 자체가 좋아지다보니 그렇게 복잡하고 혁신적인 구조를 좇을 필요가 없다는 것이다. (이해한 건 이럼)
두번째는 Postgres 르네상스. 해당 분야의 놀라운 성장이다.
지난 2년 동안 “Just Use Postgres (for everything)“라는 캐치프레이즈가 핫했다고 한다 (첨듣지만 그렇군)
+간단디비흐름
간단하게 Postgres, PostgreSQL은 RDBMS, 오픈소스 관계형 데이터베이스 관리시스템이다. 데이터를 테이블 형태로 저장하고 sql로 조작한다. 단순 sql db를 넘어 json, 벡터, 검색 등의 비정형 데이터까지 다룰 수 있어 올인원 데이터베이스로 불린다.
전통적인 RDB에서 NoSQL 붐으로 흘렀다가, 최근에는 RDB의 안정성과 NoSQL의 유연성을 가진 포스트그레스?의 시대가 왔다.
Just Use Postgres (for everything)
다시 돌아와서 포스트그레스로 대부분의 문제가 해결된다는 것이다.
실제로 많은 기업이 MongoDB나 Elasticsearch → Postgres로 회귀 중이라는데
Elasticsearch, mongoDB, Redis…그리고 카프카. 이런 것들과 경쟁이 가능하다.
물론 시스템만의 장점들이 있겠지만, 대부분의 Postgres로 대체가 가능하다. 이것이 논지.
카프카는 과하다!!! 과하지 않냐 이런.
옛날에 팀장님 말씀이 떠오른다. 약간 연차가 높으신 분들일수록 그러시는 것 같은데
저거 후자의 의견, 즉 기술을 회의론적으로 바라보는 태도가 중요한듯하다
결국 새로운 기술 도입은 어떤 식으로든 문제를 일으킬 확률이 높고, (도입안하면 0이니)
기존에 사용하던 것으로 확장하거나 그 해결할수 있다면 최고의 해결이 아닌가
암튼
카프카를 사용해서는 안된다
500KB/s 워크로드에서는 카프카를 사용해서는 안된다. 기술 업계에서는 문제가 발생하면 가능한 가장 좋은 기술을 선택하려는 경량이 있는데 이는 잘못된 접근이다. 해답은 가장 간단한 기술이다.
카프카는 뭔가
- 분산형 메시지 큐 시스템으로 데이터 스트림을 퍼플리시-구독 pub/sub 형태로 처리한다.
- 데이터를 토픽 단위로 분류하고 각 토픽은 파티션으로 나뉘어 병렬처리가 가능하다.
- 데이터는 프로듀서가 쓰고, 컨슈머가 읽고, 브로커가 중간에서 저장,전달을 담당한다.
실시간 로그 수집, 이벤트 스트리밍, 마이크로서비스 간 비동기 통신 등에서 사실상 표준으로 쓰인다.
- 실시간 데이터 파이프라인을 위한 고성능 분산 메시지 시스템.
Efk 스택에서 이제 로그 모든 fluents?인가랑 엘라스틱 서치 > 시각화해주는 친구
사이에서 카프카로 실시간 데이터 전송해주는 창구?역할을 한다.
왜 카프카를 쓰냐면 서버가 많고 커질수록 이 실시간 데이터들일 폭발적으로 늘어날텐데
카프카가 일시정으로 데이터를 버퍼링해서 수십 속도와 저장 속도를 분리시켜준다…오
그래서 장애나 일시적 부하에도 데이터 유실 없이 로그들이 저장된다.
카프카의 주요 포인트
카프카의 강점은 ‘버퍼링’이다.
대규모의 데이터도 카프카는 브로커,를 통해 중간에서 데이터를 분산 저장, 복제하는 구조로 ‘중간버퍼’의 역할을 통해 트래픽 폭주에도 서버가 다운되지 않고, 데이터 유실되지 않고, 생산자와 소비자의 처리 속도를 분리=디커플링할 수 있다.
즉 fluentd가 너무 빨리, 많은 데이터를 보내고 카프카가 중간버퍼의 역할을 하면서 엘라스틱 서치로 보내는 데이터 전송속도를 조절해준다는 것.
그렇다면 어떻게 대체할 수 있을까?
1. Pub/Sub
카프카의 핵심 중 구독 구조이다. 하나의 메시지를 여러 소비자가 구독할 수 있다.
- Postgres에서
INSERT,SELECT,OFFSET테이블을 이용했고, 충분히 안정적으로 처리할 수 있었다.
2. 대기열 실험
큐는 하나의 메시지가 단 한번만 소비되고 삭제되는 구조이다.
- Postgres에서
SELECT ... FOR UPDATE SKIP LOCKED구문을 이용해 “동시에 여러 워커가 작업을 뺏지 않고 병렬로 처리”**하도록 구현했습니다.
- Postgres에서
결과: 초당 2,800~20,000 메시지를 안정적으로 처리하며 CPU 60% 수준에서 동작.
즉, RabbitMQ나 SQS 같은 큐 시스템을 대체할 수 있을 정도의 성능을 보여줬습니다.
결론
유행을 쫓을 것인가 상식을 쫓을 것인가?
카프카는 필수적이지 않다. 물론 공부용으로 써보..는건 좋겟죠..? ㅎㅎ
오랜만에 블로그 쓰니까 신난다 지식 커지는 느낌
끗