조용한 개발 노트

7편에서 Kafka가 디스크를 빠르게 쓰는 이유를 스토리지 구조와 Page Cache 관점에서 살펴봤다. 이제 실무에서 가장 흔한 착각으로 넘어가 보자.“Kafka가 느린데, JVM 옵션을 더 만져야 하나?”많은 경우 이 질문은 방향이 틀려 있다. Kafka 성능 병목의 상당수는 JVM이 아니라 OS와 운영 환경에서 발생한다.왜 JVM부터 의심하게 될까Kafka는 JVM 위에서 동작한다. GC 로그도 있고, 힙도 있다. 그래서 문제가 생기면 자연스럽게 GC-힙-옵션부터 보게 된다.하지만 Kafka의 데이터 경로를 다시 떠올려보자.데이터는 파일로 append된다읽기-쓰기는 Page Cache를 통과한다네트워크 전송은 zero-copy를 활용한다즉, Kafka의 핫패스는 OS 커널 영역에 더 가깝다.CPU가..

6편에서 Exactly-once가 성립하는 조건과 한계를 살펴봤다. 이제 Kafka의 또 다른 오해로 넘어가 보자.“Kafka는 디스크에 쓰는데, 왜 이렇게 빠르지?”이 질문에 대한 답은 Kafka의 스토리지 구조가 아니라 운영체제와 IO를 바라보는 관점에 있다.Kafka는 디스크를 느리다고 가정하지 않는다많은 시스템은 디스크를 “느리고 비싼 자원”으로 취급한다. 그래서 캐시-락-복잡한 메모리 구조를 앞에 둔다.Kafka는 반대로 생각한다.디스크는 순차 쓰기라면 충분히 빠르다.이 전제가 Kafka의 모든 스토리지 설계를 결정한다.Append-only Log의 힘Kafka의 Partition은 append-only log다.항상 파일의 끝에만 쓴다중간 수정이 없다삭제는 즉시 하지 않는다이 구조 덕분에 랜덤..