카프카(Kafka)와 Firehose, 굳이 왜 이렇게 복잡하게 짰을까? – AWS 아키텍처 설계 회고
처음 실시간 데이터 파이프라인 설계를 맡았을 때, 솔직히 머릿속에서 제일 먼저 든 생각이 이거였어요.
“그냥 DB에 바로 넣으면 되는 거 아닌가?”
이벤트 발생하면 바로 저장하면 끝이지, Kafka에 Firehose에… 이게 다 뭔 소리야. 처음엔 아키텍처 다이어그램 보면서 진짜 이게 오버엔지니어링 아닌가 싶었어요. 비전공자 입장에서 이 구조가 왜 필요한지 전혀 와닿지 않았거든요.
근데 공부하면 할수록, 그리고 실제로 설계를 따라가보면서 “아, 이게 그냥 복잡한 게 아니구나”를 느꼈어요. 오늘은 그 깨달음을 최대한 쉽게 풀어볼게요.
“DB에 바로 넣으면 되잖아요” – 저도 처음엔 그랬어요
비전공자한테 가장 직관적인 흐름은 이거잖아요.
사용자가 클릭 → 서버가 받음 → DB에 저장 → 끝
맞아요, 이게 틀린 건 아니에요. 트래픽이 적을 때는 이 구조가 오히려 더 깔끔하고 단순해요. 굳이 중간에 뭘 끼울 필요가 없죠.
문제는 “트래픽이 갑자기 폭증하면 어떻게 되냐”예요.
예를 들어볼게요. 평소에는 초당 100건 데이터가 들어오는 서비스가 있어요. 근데 이벤트 하나 터지면 갑자기 초당 10,000건이 들어온다고 해봐요. DB는 갑자기 100배 쏟아지는 요청을 감당 못하고 버티다가 결국 뻗어버려요. 그러면 그 사이 들어오던 데이터는? 그냥 날아가요. 없어져요.
데이터 엔지니어 입장에서 데이터 유실은 그냥 손해가 아니에요. 잘못하면 분석 결과 자체가 틀려지고, 비즈니스 판단에 영향을 줘요. 그래서 “일단 안전하게 받아두고, 천천히 처리하자”는 개념이 필요해진 거예요.
카프카(Kafka)가 하는 일: 쉽게 말하면 ‘완충 지대’예요
Kafka를 처음 들으면 뭔가 엄청 어려운 기술 같은 느낌이잖아요. 근데 저는 이렇게 이해했어요.
Kafka는 데이터의 대기실이에요.
카페를 생각해봐요. 손님이 갑자기 50명 몰려와도, 주문은 카운터에서 순서대로 받고 바리스타가 하나씩 처리하잖아요. 주문이 쏟아진다고 바리스타가 갑자기 50명이 되는 게 아니라, 대기 줄이 생기는 거예요.
Kafka가 딱 그 역할이에요.
- 데이터가 폭발적으로 들어와도 → 일단 Kafka가 다 받아둬요
- DB(또는 다음 시스템)는 → 자기 속도에 맞춰서 천천히 꺼내가요
- 중간에 시스템이 잠깐 죽어도 → Kafka에 데이터가 남아있어서 유실이 안 돼요
이걸 전문 용어로 “버퍼(Buffer)” 또는 “메시지 큐(Message Queue)”라고 해요. 근데 그냥 “데이터 대기실”로 이해해도 충분해요.
한 줄 정리: Kafka는 트래픽 폭증에도 데이터를 잃지 않기 위한 ‘안전망’이에요.
근데 Kafka만 있으면 되는 거 아닌가요? Firehose는 또 왜 나와요
저도 이게 제일 헷갈렸어요. Kafka로 안전하게 받았으면, 거기서 바로 S3에 던지면 되는 거 아닌가?
여기서 스몰 파일(Small File) 문제가 등장해요.
예를 들어, 데이터가 1초에 100건씩 들어온다고 해봐요. 이걸 들어올 때마다 바로 S3에 파일로 저장하면 어떻게 될까요? 1시간이면 360,000개 파일이 생겨요. 이게 하루 지나면 수백만 개.
문제는 이 파일들이 전부 엄청 작은 파일들이라는 거예요.
나중에 이 데이터를 분석하려고 Athena나 Spark 같은 도구를 쓸 때, 작은 파일이 수백만 개 있으면 오히려 처리가 느려져요. 파일 하나하나 열고 닫는 오버헤드가 어마어마하게 쌓이거든요. 파일 크기는 작아도 열어야 하는 횟수가 너무 많으니까요.
그래서 나온 해결책이 “일정 시간 동안 데이터를 모았다가 한 번에 파일로 저장하자”예요. 이걸 배치(Batch) 적재라고 하는데, Firehose가 딱 이 역할을 해요.
Firehose가 해결해주는 것들
AWS Kinesis Data Firehose는 한마디로 완전 관리형 데이터 적재 서비스예요.
“완전 관리형”이라는 말이 낯설 수 있는데, 쉽게 말하면 귀찮은 것들을 AWS가 다 알아서 해준다는 뜻이에요.
Firehose가 알아서 해주는 것들:
– 데이터 모으기: 설정한 시간(예: 5분) 또는 크기(예: 128MB)가 차면 자동으로 S3에 저장해요
– 파일 압축: Gzip, Snappy 같은 형식으로 압축해서 저장 비용을 줄여줘요
– 파티셔닝: 연도/월/일 폴더 구조로 자동 분류해줘요
– 오류 처리: 적재 실패하면 다시 시도해줘요
이걸 Kafka에서 직접 코드로 구현하려면… 솔직히 꽤 복잡해요. 타이머 관리, 파일 병합, 압축, 예외처리 다 직접 짜야 하거든요. Firehose를 쓰면 그냥 연결만 하면 이게 다 돼요.
한 줄 정리: Firehose는 스몰 파일 문제를 해결하고, 귀찮은 적재 작업을 자동화해주는 도구예요.
그래서 전체 구조를 다시 보면
정리하면 이 아키텍처의 흐름은 이렇게 돼요.
사용자 이벤트 발생
↓
Kafka (데이터 안전하게 수신, 버퍼 역할)
↓
Firehose (데이터 모아서 S3에 적재, 스몰 파일 방지)
↓
S3 (데이터 저장소)
↓
Athena / Spark 등으로 분석
처음엔 이 구조가 복잡해 보였는데, 각 단계가 서로 다른 문제를 해결하고 있다는 걸 알고 나면 오히려 깔끔하게 느껴져요.
- DB 직접 저장의 문제 → Kafka가 해결
- Kafka에서 파일 직접 저장의 문제 → Firehose가 해결
겉보기엔 복잡하지만, 사실 각자 역할이 명확하게 나눠진 구조예요.
비전공자로서 느낀 점
솔직히 처음에 이 구조 봤을 때 “이거 진짜 써야 해?”라는 생각이 먼저 들었어요. 공부하는 입장에서는 배울 게 너무 많아서 부담스럽기도 했고요.
근데 각각의 도구가 “어떤 문제를 해결하려고 나왔는지”를 먼저 이해하고 나니까, 오히려 왜 이렇게 설계했는지가 자연스럽게 이해됐어요.
아키텍처 공부할 때 “이게 뭔지”보다 “이게 왜 필요한지”를 먼저 물어보는 게 훨씬 빠른 것 같아요. 여러분도 새로운 기술 공부할 때 이 순서로 접근해보시면 좋을 것 같아요.