조용한 개발 노트

성능 이슈가 발생하면 가장 먼저 떠오르는 접근은 보통 이렇다.“느린 쿼리가 있다 → 쿼리를 고치자.”물론 쿼리가 원인인 경우도 있다. 하지만 InnoDB 환경에서 반복적으로 관측되는 성능 문제의 상당수는, SQL 문법이나 실행 계획 이전에 메모리와 IO 구조에서 발생한다.InnoDB에서 쿼리는 어디를 지나갈까InnoDB에서 쿼리가 실행될 때, 실제로 가장 빈번하게 오가는 경로는 다음과 같다.인덱스 페이지 접근데이터 페이지 접근Buffer Pool 히트 또는 미스필요 시 디스크 IO즉, 쿼리 성능은 SQL 문장 자체보다 페이지가 메모리에 있는지, 디스크에 있는지에 훨씬 민감하다.Buffer Pool은 InnoDB 성능의 중심이다InnoDB의 Buffer Pool은 디스크에 있는 데이터와 인덱스 페이지를 메..

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