[리눅스 기초 #82] 멈추지 않는 데이터의 흐름: Kafka Streams와 Flink로 실시간 분석 시스템 완성하기

리눅스 기초 시리즈의 82번째 시간입니다! 지난 시간에는 데이터의 고속도로인 Apache Kafka를 통해 시스템 간의 결합도를 낮추고 대용량 메시지를 안정적으로 유통하는 법을 배웠습니다. 이제 우리 서버의 혈관에는 끊임없이 데이터가 흐르고 있습니다.

하지만 혈관에 피가 흐르는 것만으로는 부족합니다. 그 피 속에 영양분이 충분한지, 혹은 유해한 물질이 섞여 있지는 않은지 실시간으로 판단하고 정화해야 하죠. 오늘은 Kafka라는 고속도로 위를 달리는 데이터를 멈추지 않고 그 자리에서 즉시 분석하고 가공하는 기술, 스트림 프로세싱(Stream Processing)의 핵심인 Kafka Streams와 Apache Flink를 저의 경험담과 함께 정리해 보겠습니다.

---

1. 나의 경험담: "데이터가 '죽은 뒤'가 아니라 '살아있을 때' 잡아야 한다"

IT 개발자로서 유튜브 쇼츠 자동화 시스템을 운영하다 보면, 특정 영상의 조회수가 급증하는 '골든타임'을 포착하는 것이 무엇보다 중요합니다. 초기에는 1시간마다 DB를 뒤져서 조회수를 집계했는데, 그러다 보니 이미 유행이 지난 뒤에야 알림을 받는 경우가 허다했습니다. 마치 면역력이 이미 다 떨어진 뒤에야 영양제를 챙겨 먹는 것처럼 사후 약방문이었죠.

이때 저는 스트림 프로세싱을 도입했습니다. Kafka로 들어오는 실시간 시청 이벤트를 그 자리에서 1분 단위로 묶어(Windowing) 급상승 키워드를 추출했습니다. 이제는 조회수가 폭발하는 순간 0.1초 만에 시스템이 감지하고 관련 영상을 추가로 생성하는 '선제적 대응'이 가능해졌습니다. 영화 '하빈'에서 첩보원들이 찰나의 정보를 가로채 작전의 승패를 결정짓듯, 리눅스 서버 운영에서도 데이터가 머무르는 찰나를 지배하는 자가 비즈니스의 승기를 잡는다는 것을 깨달았습니다.

---

2. Before: "배치 처리의 한계와 정보의 노후화"

스트림 프로세싱 이전의 방식은 대량의 데이터를 쌓아두었다가 한꺼번에 처리하는 '배치(Batch)' 방식이었습니다. 하지만 이 방식은 데이터가 생성된 시점과 분석된 시점 사이의 간극인 '레이턴시(Latency)'를 피할 수 없었습니다.

과거의 느린 데이터 분석 (Before):

Batch Processing Pipeline

 

# 1. 데이터를 DB에 일단 저장 (수 분 소요)

2. 크론탭(Cron)이 매 시간마다 SQL 실행
3. 결과 보고서 생성
"아... 1시간 전 데이터네? 지금은 상황이 변했는데..."

(▲ Before: 데이터가 창고에 쌓일 때까지 기다려야 했기에, 실시간성이 생명인 금융 이상 거래 감지나 광고 클릭 분석 등에는 치명적인 약점이 있었습니다.)

---

3. Action: Kafka Streams로 실시간 로그 필터링하기

이제 리눅스 서버에서 가볍게 돌릴 수 있는 Kafka Streams 라이브러리를 활용해 보겠습니다. 별도의 클러스터 구축 없이 애플리케이션 안에서 직접 스트림을 처리하는 예시입니다.

실시간 로그 필터링 (Python Faust 라이브러리 예시):

Python (Faust Stream Processing)

 

import faust

app = faust.App('youtube-analytics', broker='kafka://localhost:9092')

Kafka 토픽 정의
view_topic = app.topic('video-views', value_type=dict)

@app.agent(view_topic)
async def process_views(views):
async for view in views:
# 실시간 조회수가 10,000회를 넘는 영상만 골라내기
if view['count'] > 10000:
print(f"🔥 인기 영상 발견! ID: {view['id']}, 조회수: {view['count']}")
# 이후 슬랙 알림이나 자동화 스크립트 실행 로직 추가 가능

(▲ Action: 데이터가 흐르는 파이프라인 중간에 촘촘한 '필터'를 설치한 것과 같습니다. 조건에 맞는 데이터만 즉시 골라내어 다음 행동으로 이어지게 합니다.)

---

4. After: "정보에서 통찰로 이어지는 초저지연 시스템"

스트림 프로세싱을 도입한 뒤 제 인프라는 '살아 숨 쉬는 유기체'가 되었습니다.

혁신적인 변화들:

• 즉각적인 반응성: 장애 징후나 트래픽 급증을 초 단위로 파악하여 대응 시간이 비약적으로 짧아졌습니다.
• 효율적인 리소스 사용: 모든 데이터를 저장한 뒤 분석하는 게 아니라, 필요한 것만 필터링하여 저장하므로 DB 부하가 60% 이상 줄었습니다.
• 복잡한 패턴 분석: 단순히 현재 값이 아니라, "최근 5분간의 평균 대비 급증" 같은 시간대별 패턴(Stateful Processing) 분석이 가능해졌습니다.

---

5. Kafka Streams vs Apache Flink 비교

구분	Kafka Streams	Apache Flink
운영 방식	라이브러리 형태 (단독 실행)	독립 클러스터 환경 (강력한 엔진)
복잡도	낮음 (기존 앱에 통합 가능)	높음 (전문적인 운영 필요)
주요 장점	Kafka와의 완벽한 일체감	극강의 처리 성능 및 정확도
비유	개인용 고성능 필터기	거대 정수 처리장

---

6. 마치며: 당신의 데이터에 '생명력'을 불어넣으세요.

리눅스 기초 82단계를 거치며 우리는 이제 데이터를 단순히 옮기는 것(Kafka)을 넘어, 그 안에서 실시간으로 가치를 추출하는 경지에 도달했습니다. 데이터는 멈추는 순간 과거의 기록이 되지만, 흐르는 순간에는 미래를 바꾸는 정보가 됩니다. 여러분의 인프라 위로 흐르는 수많은 로그와 이벤트에 스트림 프로세싱이라는 마법을 더해보세요.

오늘의 인사이트: "가장 신선한 데이터는 파이프라인을 통과하고 있는 지금 이 순간의 데이터다."

---

82번째 이야기를 마칩니다. 이제 우리 인프라는 실시간 지능을 갖췄습니다. 다음 시간에는 이렇게 방대해진 분산 데이터 환경에서 내가 원하는 정보를 단 0.1초 만에 찾아내는 '검색의 혁명: 리눅스 서버에서 Elasticsearch 클러스터 운영하기'에 대해 다뤄보겠습니다.

이 글이 실시간 분석 시스템 설계에 영감을 주었나요? 혹시 스트림 프로세싱 도중 데이터가 중복 처리될까 봐 걱정되시나요?

단 한 번만 처리됨을 보장하는 'Exactly-once Semantics' 설정법을 다음 포스팅 부록으로 준비해 드릴까요?