Kafka Intro : Line Engineering3

Jamangstangs·2022년 5월 3일

Kafka

목록 보기

3/5

Line Development Day 2018에서 Yuto Kawamura님이 발표한 내용에 기반한 블로그 글을 바탕으로 필자가 알아야 할 내용을 보충설명 하였습니다.

Broker가 Fetch 요청을 처리한다.
이 과정에서 sendfile 호출 -> Page Cahe에 데이터가 없고, Disk Read가 필요하면, Network Thread의 Event Loop가 차단이 된다.
이렇게 되면
- 현재 처리중인 Request
- 후속 Response
- 다른 관련 API
가 싹다 차단된다는 가설, 같은 Network Thread로 처리되는 관련 없는 API의 Response까지 차단된다.

이를 통해, 원래 관련이 없던 Produce API의 응답 시간이 저하된 것도 설명이 가능하다.

Request Handler Thread로 옮겨도 문제가 없나? -> 하나의 큐를 전체가 Polling, 차단이 발생해도 다른 Thread에 영향을 주지 않는다.
- 하나의 Queue를 전체가 Polling : request queue를 보자,
  1. F : Fetch API
  2. P : Produce API
  Queue에 대기하고 있는 Fetch, Produce API를 전체가 Polling 하는 것을 위의 그림에서 확인할 수 있다.
- Polling : 한 프로그램이나 장치에서 다른 프로그램이나 장치들이 어떤 상태에 있는지를 지속적으로 검사하여 일정한 조건을 만족하면, 송수신등의 자료처리를 하는 방식
WarmUP Page Cache : 필요한 데이터가 Page Cache에 없고, Disk에서 불러와야 할 때, 이것을 Network Threads에서 처리하지 않고, Request Handler Threads에서 처리한다.
- 순서를 볼때, 미리 Page Cache에 올려놓으니까 WarmUp Page Cache라고 이해하면 된다.
- 그렇다면, WarmUP을 어떻게 처리할까?

처리하는 방식에 있어서 시행착오가 있었고, 1번 방법은 Kafka의 효율적인 특성을 잃어버리고, 2번 방법을 통해 문제를 해결했다고 한다.

대상 데이터에 Read를 호출 -> sendfile에 비해서 Overhead가 크다.
- read() : data가 Disk에서 로딩 된 다음, User Space의 Buffer에 복사되어버린다.
- sendfile systemcall : 로컬 디스크의 데이터를 Client Socket에 바로 복사하게 해주는 API
즉, 효율을 유지하기 위해서는, read보다는 sendfile system call을 사용해야한다.

sendfile을 호출하면서 목적지를 /dev/null로 설정한다.
- Linux Kernel : /dev/null을 목적지로 호출 -> 메모리 복사를 하지 않는다
- 즉, Disk -> Page Cache로 데이터가 로딩 -> 그 이후 메모리 복사는 진행되지 않는다.