실시간 트렌드 분석기라는 프로젝트 특성상, 처음엔 요즘 많이 사용한다는 kafka와 같은 메시지 큐 시스템이 필수라고 생각했습니다.
여러 언론사에서 데이터를 지속적으로 수집하고, 그걸 바로바로 처리해야되기 때문입니다.
그래서 표면적으로만 보면, 실시간으로 뉴스 기사를 분석하는 제 프로젝트에 MQ가 필수적이라고 생각하는 것이 이상하지 않습니다.
꼭 MQ를 써야할까?
먼저 kafka는 대용량 데이터 스트림을 안정적이고 확장성 있게 설계된 기술입니다.
넷플릭스나 링크드인같은 기업에서 초당 수백만 건의 이벤트를 처리하기 위해 만들어졌습니다.
하지만 제 프로젝트가 그 정도 규모일까요?
- "여기서 말하는 대용량은 실제로 어느 정도의 데이터량인가?"
- "MQ를 사용하지 않으면 정말 구현이 불가능한가?"
실시간과 대용량이라는 키워드만 보고 MQ를 선택한 건 아닐까?
그래서 실제로 MQ가 해결해야하는 병목이 제 프로젝트에도 존재하는지 검증해보기로 했습니다.
팩트 체크: 뉴스 데이터가 정말 '대용량'일까?
이 프로젝트가 감당해야 할 데이터의 양을 정확히 파악하기 위해, '한국언론진흥재단(Big Kinds)'의 통계를 바탕으로 추정해봤습니다.
- 한국언론진흥재단이 수집하는 국내 주요 언론사들의 일평균 기사 발행량은 약 15,000 ~ 20,000건입니다.
- 여기에 주요 경제지, 연예/스포츠 기사까지 포함하면 양은 더 늘어납니다.
저는 시스템 부하를 충분히 테스트할 수 있는 수치로, 일일 30,000을 기준으로 잡았습니다.
트래픽 계산
- 하루 총량: 30,000건
이 수치를 초당 트랜잭션으로 환산해보면 결과는 더욱 처참(?)합니다.30,000(건) / 86,400(초) ≒ 0.35
초당 0.35건. 즉 1초에 기사가 한 건도 안 들어옵니다. 단순히 데이터의 총량만 놓고 보면, MQ 도입은 확실한 오버엔지니어링이 맞습니다.
그럼에도 검증이 필요한 이유: '양'보단 '구조'
데이터 양이 적다는 것은 확인했습니다. 그렇다면 정말 MQ가 필요 없을까요?
뉴스 데이터는 24시간 일정하게 들어오지 않습니다. 어떤 사건이 터지면 순간적으로 폭증할 수 있고, 분석 로직은 데이터 수집보다 훨씬 무거운 작업입니다.
MQ가 해결해야 하는 병목이 '데이터 양'이 아니라 '시스템 간의 의존성'에 있다면 충분히 도입할 가치가 있다고 판단했습니다.
검증 시나리오 설계
결국 MQ의 필요성을 검증하려면, MQ가 해결해주는 문제가 실제로 내 프로젝트에도 존재하는지를 테스트 해봐야할 것 같습니다. MQ 없이 직접 데이터베이스에 연결하는 환경에서 두 가지 테스트를 진행할 예정입니다.
Test 1) 데이터 수집과 저장에서 생기는 병목
- 시나리오: n개의 RSS 피드에서 n 개의 데이터를 동시에 수집
- 확인 포인트: DB에 락이 걸리거나 응답이 지연될 때, 수집기까지 멈춰버리는가?
- 목적: 데이터 수집과 저장의 결합도를 끊어내는 것이 얼마나 중요한지 확인
(구현한 후 작성 예정)
Test 2) 트래픽 폭주 시 서버의 생존 여부
뉴스 기사 하나를 분석하는 데에는 형태소 분석, 키워드 추출 등의 작업이 필요합니다. (CPU 작업을 진행하게 될텐데, 제 프로젝트 서버는 node.js 이기에 이것 또한 고려해봐야합니다.)
- 시나리오: 평소 초당 0.35 건이 아니라, 속보가 터져 짧은 시간에 대량의 기사가 유입될 때를 가정.
- 확인 포인트:
- 단일 분석 서버가 감당 가능한 임계점이 어디인지
- 임계점을 넘었을 때 서버 다운이나, 데이터 유실이 있는지.
- 목적: MQ가 제공하는 백프레셔(backpressure) 기능이 실제로 필요한 상황인지 검증
(구현한 후 작성 예정)
부록: kafka와 다른 메시지 큐 비교
(작성 예정)
