[카프카 핵심 가이드(개정증보판)]_오탈자

현재까지 발견된 이 책의 오탈자 정보와 오류를 안내합니다. 번역과 편집 시에 미처 확인하지 못하고 불편을 끼쳐드려 죄송하다는 말씀을 드립니다. 아래의 오탈자 사항은 추후 2쇄 시에 반영하도록 하겠습니다.

 

이외의 오탈자 정보를 발견하시면 이 책의 공식 웹사이트에서 '오타 신고 및 내용 문의' 기능을 이용하여

(https://github.com/dongjinleekr/kafka-the-definitive-guide-v2/issues)  제보해주시면 고맙겠습니다. 

 

최종수정일자: 2024년 2월 26일  1쇄본 오탈자

7쪽 12번째 줄에서(고명석 님 제보)

다름의 규칙을 가진 컨스텀 파티셔너를 사용할 수도 있다.

⇒
다름의 규칙을 가진 커스텀 파티셔너를 사용할 수도 있다.

 

38쪽 밑에서 5~4번째 줄에서(신수웅 님 제보)

만약 클러스터가 10TB의 데이터를 저장해야 하는데 하나의 클러스터가 저장할 수 있는 용량은 2TB라면, 클러스터의 최소 크기는 5대가 된다.

⇒
만약 클러스터가 10TB의 데이터를 저장하고 있어야 하는데 하나의 브로커가 저장할 수 있는 용량이 2TB라면, 클러스터의 최소 크기는 브로커 5대가 된다.

 

51쪽 그림 3-1 '카프카 프로듀서 요소 개괄'에서(옮긴이 지적)

점선으로 둘러싸인 사각형 안에 ‘시리얼라이저’ 아래에 ‘프로듀서’ 라고 되어 있는 것을 ‘프로듀서’가 아니라

‘파티셔너’로 바꿔야 함

 

74쪽 4번째 줄에서(옮긴이 지적)

broker의 CPU 사용량을 줄인다.

⇒
브로커의 CPU 사용량을 줄인다.

 

74쪽 파티셔너에 접착성 처리가 없는 경우(왼쪽)와 있는 경우(오른쪽) 그림의 첫 줄에서(신수웅 님 제보)

P0  0, 1, 7                  P0  0, 1, 7

⇒
P0  0, 1, 7                  P0  0, 1, 2

 

74쪽 옮긴이 설명 박스 끝줄에서(옮긴이 지적)

별것 아니 것으로 보이지만,

⇒
별것 아닌 것으로 보이지만,

 

81쪽 10~12번째 줄에서(옮긴이 지적)

주의할 점은 이 값들이 쓰기 쿼터/읽기 쿼터에 의해 발생한 스로틀링 때문에 지연된 시간을 가리킬 수도 있고, 요청 쿼터 때문에 지연된 시간을 가리킬 수도 있고, 둘 다 때문에 지연된 시간을 가리킬 수도 있다는 점이다.

⇒
주의할 점은 이 값들이 쓰기 쿼터나 읽기 쿼터에 의해 발생한 스로틀링(초당 처리량 기준) 때문에 지연된 시간을 가리킬 수도 있고, 요청 쿼터에 의한 스로틀링(요청을 처리하는 시간 비율 기준) 때문에 지연된 시간을 가리킬 수도 있고, 둘 다 때문에 지연된 시간을 가리킬 수도 있다는 점이다.

 

86쪽 9~10번째 줄에서(옮긴이 지적)

하지만, G2 전체를 놓고 보면 다른 컨슈머 그룹과는 상관없이 여전히 전체 메시지를 된다(그림 4-5).

⇒
하지만 G2 전체를 놓고 보면, 다른 컨슈머 그룹과는 상관없이 여전히 전체 메시지를 받게 된다(그림 4-5).

 

99쪽 RoundRobin 절의 마지막 문장에서(옮긴이 지적)

일반적으로 모든 컨슈머들은 동일한 토픽들을 구독하기 때문에 RoundRobin 방식을 선택할 경우 모든 컨슈머들이 완전히 동일한 수(혹은 많아야 1개 차이)의 파티션을 할당받게 된다.

⇒
일반적으로 만약 컨슈머 그룹 내 모든 컨슈머들이 동일한 토픽들을 구독한다면(실제로 그런 게 보통이다), RoundRobin 방식을 선택할 경우 모든 컨슈머들이 완전히 동일한 수(혹은 많아야 1개 차이)의 파티션을 할당받게 된다.

 

101쪽 4.5.15 group.instance.id 절의 첫 줄에서(doyoung0205 님 제보)

컨슈머에 정작 그룹 멤버십 기능을 적용하기 위해 사용되는 설정으로,

⇒
컨슈머에 정적 그룹 멤버십 기능을 적용하기 위해 사용되는 설정으로,

 

160쪽 10~11번째 줄에서(LDesire 님 제보)

만약 팔로워 레플리카가 10초 이상 메시지 요청을 보내지 않거나 10초 이상 가장 최근의 메시지를 가져가지 않을 경우 해당 레플리카는 동기화가 풀린 것으로 간주된다(‘아아웃-오브-싱크 레플리카out-of-sync replica’).

⇒
만약 팔로워 레플리카가 일정 시간 이상 읽기 요청을 보내지 않거나, 읽기 요청을 보내긴 했는데 가장 최근에 추가된 메시지를 따라잡지 못하는 경우 해당 레플리카는 동기화가 풀린 것으로 간주된다(‘아아웃-오브-싱크 레플리카out-of-sync replica’).

 

160쪽 17~18번째 줄에서(LDesire 님 제보)

팔로워 레플리카가 아웃-오브-싱크 레플리카로 판정되기 전, 비활성 상태이거나 뒤쳐진 상태일 수 있는 시간은 replica.lag.time.max.ms 설정 매개변수에 의해 결정된다.

⇒
팔로워 레플리카가 동기화가 풀린 것으로 판정될 때까지 걸리는 시간, 즉 읽기 요청을 보내지 않거나 뒤처진 상태로 있을 수 있는 ‘일정 시간’은 replica.lag.time.max.ms 설정 매개변수에 의해 결정된다.
(옮긴이 각주: replica.lag.time.max.ms의 기본값은 10초였으나 2.5.0부터 30초로 변경되었다.)

 

170쪽 5~6번째 줄에서(LDesire 님 제보)

클러스터의 크기를 키우거나 줄일 때, 파티션의 위치를 다른 브로커로 옮기는 데 걸리는 시간은 파티션의 수에 따라 결정된다.

⇒
클러스터의 크기를 키우거나 줄일 때, 파티션의 위치를 다른 브로커로 옮기는 데 걸리는 시간은 파티션의 크기에 따라 결정된다.

 

171쪽 밑에서 5~4번째 줄에서(LDesire 님 제보)

하지만 2에 팔로워 브로커가 또 배치되거나 3에 두 개가 모두 배치될 수는 없다.

⇒
하지만 브로커 2에 팔로워가 또 배치되거나(즉 브로커 2에 리더와 팔로워가 하나씩 함께 배치), 브로커 3에 팔로워 두 개가 함께 배치될 수는 없다.

 

178쪽 밑에서 12~11번째 줄에서(LDesire 님 제보)

맵의 각 항목은 메시지 키의 16비트 해시와 같은 키값을 갖는 이전 메시지의 오프셋(8비트)으로 이루어진다.

⇒
맵의 각 항목은 메시지 키의 16바이트 해시와 같은 키값을 갖는 이전 메시지의 오프셋(8바이트)으로 이루어진다.

 

204쪽 '요약' 절 제목에서(옮긴이 지적)

7.6 요약 ⇒ 7.7 요약

 

266쪽 2번째 단락 1~2번째 줄에서(옮긴이 지적)

만약 동일한 데이터세트를 여러 위치에서 비동기적으로 읽고 써야 하는 문제를 해결할 방법을 찾고 있다면 이 아키텍처가 매우 권장된다.

⇒
만약 동일한 데이터세트를 여러 위치에서 비동기적으로 읽고 썼을 때 발생하는 문제점을 해결할 방법이 있다면, 이 아키텍처가 매우 권장된다.

 

276쪽 밑에서 7번째 줄에서(LDesire 님 제보)

원본 토픽에 새 파티션이 추가될 경우, 자동으로 대상 토픽을 생성한다. 

⇒
원본 토픽에 새 파티션이 추가될 경우, 자동으로 대상 토픽에 새 파티션이 생성된다. 

 

281쪽 밑에서 10째 줄에서(LDesire 님 제보)

새로운 원본 파티션이 탐지되었을 때 토픽을 추가해주기 위한 대상 클러스터의 Topic:Alter 권한

⇒
원본 토픽에 새로 추가된 파티션이 탐지되었을 때 대상 클러스터 쪽에 새 파티션을 추가해주기 위한 대상 클러스터의 Topic:Alter 권한

 

288쪽 밑에서 8번째 줄에서(옮긴이 지적)

fetch.min.bytes and fetch.max.wait.ms

⇒
fetch.min.bytes, fetch.max.wait.ms

 

324쪽 밑에서 5번째 줄에서(옮긴이 지적)

메시 지 암호화는 대개 AES와 같은

⇒
메시지 암호화는 대개 AES와 같은

 

324쪽 끝줄에서(옮긴이 지적)

매시지를 복호화하는 데 필요한

⇒
메시지를 복호화하는 데 필요한

 

327쪽11.5.1 'AclAuthorizer' 절의 '권한 유형' 항에서(옮긴이 지적: | 좌우 간격 띄우기)

Allow|Deny;

⇒
Allow | Deny;