Maru's Study Memo

2011년 SNS 사이트인 Linked-in에서는 파편화된 데이터 수집 및 분배 아키텍처를 운영하는데 큰 어려움을 겪었습니다.

데이터를 생성하고 적재하기 위해서는, 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타깃 애플리케이션들을 연결해야 하는데, 초기에는 단방향 통신을 통해 소스 애플리케이션에서 타깃 애플리케이션으로 연동하는 소스 코드를 직접 작성했고 아키텍처가 복잡하지 않았기 때문에 운영이 힘들지 않았습니다.

하지만 시간이 지날수록 아키텍쳐는 점점 거대해졌고, 소스와 타깃 애플리케이션의 개수가 많아지면서 문제가 생겼습니다. 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작해져 소스-타깃을 연결하는 파이프라인의 개수가 많아지면서 소스코드 및 버전 관리 이슈가 많아졌습니다. 그리고 타깃 애플리케이션에 장애가 생기면 그 영향이 소스 애플리케이션에 그대로 전달되었습니다.

이렇게 점점 복잡해지는 Linked-in 백엔드 아키텍쳐에서, 파편화된 데이터 파이프라인은 서비스를 안정적으로 운영하는 데에 걸림돌이 되었습니다. 이를 해결하기 위해 Linked-in 데이터 팀에서는 기존 상용 데이터 프레임워크와 오프 소스를 아키텍처에 녹여내서 데이터 파이프라인의 파편화를 개선하려고 시도했었습니다. 다양한 메시지 플랫폼과 ETL 툴을 이용했지만, 데이터 파이프라인의 복잡도를 낮춰주는 아키텍처가 되지는 않았습니다.

결국 Linked-in 데이터 팀은 신규 시스템을 만들기로 결정했고, 그 결과물이 바로 Apache Kafa입니다.

Kafka는 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아서 처리할 수 있도록 중앙 집중화했습니다. Kafka를 통해 웹사이트, 앱, 센서 등에서 취합한 데이터 스트림을 한 곳에서 실시간으로 관리할 수 있게 처리할 수 있게 되었습니다.

카프카 내부에 데이터가 저장되는 파티션의 동작은 큐 자료구조와 유사합니다. 이 큐에 데이터를 보내는 것이 프로듀서(Producer)이고, 큐에서 데이터를 가져가는 것을 컨슈머(Consumer)라고 부릅니다.

상용 환경에서 Kafka는 최소 3대 이상의 서버에서 분산 운영해서 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록합니다. 즉, 일부 서버에 장애가 발생해도 데이터를 지속적으로 복제하기 때문에 안전하게 운영 가능합니다.

또한 이렇게 주고받는 데이터를 배치 전송 하기때문에, 낮은 지연과 높은 데이터 처리량을 가지게 되었습니다.

즉 Kafka는 많은 양의 데이터를 안전하고 빠르게 처리하는 강점을 가지고 있기 때문에, 많은 IT 기업에서 사용하고 있습니다.