🚀 Facebook이 만든 분산 로그 시스템 LogDevice, 왜 주목해야 할까?

원혜린·2025년 5월 27일

실전 중심의 LogDevice 아키텍처 이해와 활용법

✨ 개요

모던 백엔드 아키텍처에서 로그는 단순한 디버깅 도구가 아닙니다.
데이터 복제, 메시지 큐, 이벤트 소싱, CDC 등 핵심 기능의 기반이죠.

Kafka가 사실상 업계 표준이지만,
Facebook(메타)은 왜 Kafka 대신 LogDevice라는 자체 시스템을 개발했을까요?

이 글에서는 LogDevice의 설계 철학, 아키텍처, 그리고 실전 활용 포인트를 깊이 있게 살펴봅니다.

🔍 LogDevice란?

LogDevice는 Facebook이 만든 고성능 분산 로그 저장소입니다.

주요 특징

🧵 수백만 개의 로그 스트림 지원
✏️ Append-only 로그 구조
💪 쓰기 성능 최적화
🔁 클라이언트 측 offset 관리
⚙️ 유연한 consistency 및 durability 설정

⚖️ Kafka vs LogDevice

항목	Kafka	LogDevice
단위	Topic + Partition	Log (ID 기반 stream)
Offset 저장	Broker (Zookeeper 등)	Client 관리
Retention	시간/용량 기준	Trim point 기반
Storage 구조	Segment 파일	Copyset + WAL
확장 방식	Partition 수 증가	로그 ID 수평 확장

LogDevice는 대규모 환경에서 partition 관리 없이 수평 확장이 가능합니다.

🧱 아키텍처 구성

1. 구성 요소

Clients: 로그 기록/소비 애플리케이션
Sequencer Nodes: 로그의 순서 관리
Storage Nodes: 실제 로그 저장
Admin API & Config Store: 설정 및 메타데이터 관리

2. Sequencer / Storage 분리

🧭 Sequencer는 로그 순서 부여 및 복제 대상 결정
🗂 Storage Node는 복제된 로그 데이터 저장

쓰기 경로와 저장 경로를 분리함으로써 병목을 줄이고 확장성을 확보합니다.

3. Copyset Replication

🔁 고정된 노드 셋에만 복제
🌐 네트워크 사용량 감소 & 빠른 복구

Kafka의 ISR보다 효율적인 복제 모델입니다.

🧪 실전에서 고려할 점

✅ 1. Offset 관리

Kafka와 달리, 클라이언트가 소비 위치를 직접 관리합니다.
→ 유연하지만, offset 저장/동기화가 까다로울 수 있음
LogDevice는 epoch 기반 읽기 API & checkpoint API를 지원합니다.

🧹 2. 로그 삭제 정책 (Trim Policy)

trim point를 기준으로 로그가 삭제됩니다.
→ 서비스 SLA, 소비자 offset 고려해서 설계 필요

🔧 3. 장애 허용성

복제본 기반 Storage Node 장애 대응 가능
Sequencer 장애 시 자동 failover
단, sequencer 메타데이터 손상 시 쓰기 불가 위험 → 메타데이터 durability 중요

🧭 어떤 상황에 적합할까?

⚙️ 복잡한 Partition 없이 로그 스트림 분리 필요
🧬 이벤트 소싱 기반 마이크로서비스
🔄 CDC / 로그 복제 시스템
🔍 OLAP 로그 수집기 또는 실시간 분석 기반

Kafka의 범용성보다는 특정 규모와 시나리오에 최적화된 대안입니다.

✅ 정리

특징	설명
유연성	로그 단위, 복제 방식, 소비자 모델이 유연
확장성	수백만 개의 로그 스트림도 무리 없이 처리
실용성	메시지 큐보다는 로그 저장/복제에 최적화

LogDevice는 로그를 일등 시민으로 다루는 시스템에서 큰 장점을 발휘합니다.

🔗 참고 자료

궁금한 점이 있거나 실무 도입 경험이 있다면 댓글로 나눠주세요! 🙌
Kafka만 알고 있다면, LogDevice도 한번 탐험해보세요!

원혜린

백엔드 개발자

이전 포스트

5분만에 이해하는 RAFT 합의 알고리즘

다음 포스트