Kafka 디자인

우리는 대기업이가지고 있는 모든 실시간 데이터를 처리 하기 위한 통합 플랫폼의 역할을 할 수 있도록 카프카를 설계했다. 이를 위해서 광범위한 유즈 케이스를 고려했다.

실시간 로그 집계와 같은 대용량 이벤트 스트림을 처리하려면 높은 대역폭을 확보 할 수 있어야한다. 오프라인 시스템에서도 주기적인 데이터로드를 지원하기 위해서는 대규모의 백로그를 처리 할 수 있어야 한다.

또한 전통적인 메시지 사용 사례를 지원하기 위해서 빠르게(low-latency) 메시지를 처리 할 수 있어야 한다.

우리는 이러한 피드에대한 분산 실시간 처리를 위해서 파티셔닝 개념과 생산자 & 소비자 모델을 도입했다.

마지막으로 스트림이 다른 데이터 시스템에 전달되는 경우 시스템은 장애에대한 내결함성을 보장할수 있어야 한다.

이러한 요구사항을 수용하기 위해서 기존의 메시징 시스템 보다는 데이터베이스 로그와 비슷한 요소들을 포함하도록 설계했다. 다음 장에서 이들 디자인 요소에대해서 자세히 설명하겠다.

파일 시스템을 두려워하지 말라!!!

카프카는 파일시스템에 메시지의 저장를 저장하고 캐싱한다. 디스크는 느리다라는 일반적인 인식 때문에, 메모리 기반의 저장소를 선호하는 최근의 기술 트랜드에는 맞지 않는 것으로 보인다. 하지만 디스크는 싼 값에 대량의 데이터를 지속적으로 저장할 수 있다는 장점을 가지고 있다. 아주 느리지만 않다면 디스크를 사용하지 않을 이유가 없다.

실제로 디스크는 사용하는 방법에 따라서 느리게 혹은 빠르게 작동 할 수 있다. 적절히 설계된 디스크 구조는 네트워크 만큼 빠르다.

디스크 성능은 6개의 7200rpm SATA RAID-5로 구성된 JBOD에서 선형쓰기는 600MB/sec에 달한다. 반면 랜덤 엑세스는 100k/sec에 불과하다. 6000배라는 엄청난 차이다. 선형 읽기와 쓰기는 예측이 가능하고 운영체제에 의해서 최적화 되기 때문이다.

순차적인 디스크 엑세스는 어떤 경우에 랜덤 메모리 엑세스보다 빠르게 작동한다.

위 그림은 물론 메모리가 디스크보다 빠르지만, 디스크도 충분히 빠를 수 있음을 보여준다. 자세한 내용은 ACM 문서를 참고하자.

디스크의 성능을 보완하기 위해서 최신 운영체제는 메모리를 디스크 캐싱에 적극 사용하는 방식을 채택하고 있다. 최신 운영체제는 사용 가능한 모든 메모리를 기꺼이 디스크 캐싱으로 전환하기 때문에 성능저하가 거의 없다. 모든 디스크 읽기/쓰기는 통합 캐시를 통과한다. 이 기능은 운영체제가 기본으로 제공하고 있으므로 프로세스가 데이터의 in-process 캐시를 유지하더라도 운영체제의 pagecache에 저장되므로 중복저장되는 효과를 얻을 수 있다.

우리는 JVM을 기반으로 소프트웨어를 개발하고 있으며, 자바는 메모리 사용과 관련해서 아래의 두가지 특성이 있다는 것을 알고 있다.