1쇄 정오표 (최종 업데이트: 2024년 12월 22일)
| 쪽 | 수정 전 | 수정 후 |
|---|---|---|
| 7 | 프로듀서는 메시지를 파티션으로 대응시켜 주는 다름의 규칙을 가진 커스텀 파티셔너를 사용할 수도 있다. | 프로듀서는 메시지를 파티션으로 대응시켜 주는 나름의 규칙을 가진 커스텀 파티셔너를 사용할 수도 있다. |
| 21 | cp > /usr/local/zookeeper/conf/zoo.cfg << EOF |
cat > /usr/local/zookeeper/conf/zoo.cfg << EOF |
| 22 | 주키퍼가 사용하는 부하 부산 알고리즘 때문에 앙상블은 홀수 개의 서버(예: 3개, 5개, …)를 가지는 것이 권장된다. | 주키퍼가 사용하는 부하 분산 알고리즘 때문에 앙상블은 홀수 개의 서버(예: 3개, 5개, …)를 가지는 것이 권장된다. |
| 23 | 정 파일의 모든 호스트명을 localhost로 지정하고 모든 peerPort, leaderPort에 서로 다른 포트를 할당함으로써 |
설정 파일의 모든 호스트명을 localhost로 지정하고 모든 peerPort, leaderPort에 서로 다른 포트를 할당함으로써 |
| 38 | 만약 클러스터가 10TB의 데이터를 저장해야하는데 하나의 클러스터가 저장할 수 있는 용량은 2TB라면, 클러스터의 최소 크기는 5대가 된다. | 만약 클러스터에 10TB의 데이터를 저장하고 있어야 하는데 하나의 브로커가 저장할 수 있는 용량이 2TB라면, 클러스터의 최소 크기는 브로커 5대가 된다. |
| 49 | 파티셔너과 | 파티셔너와 |
| 51 | (그림 3-1 ‘카프카 프로듀서 요소 개괄’ 에서 ‘시리얼라이저’ 아래에 ‘프로듀서’ 라고 되어 있음. 즉, 그림 안에 ‘프로듀서’ 가 2개.) | (‘시리얼라이저’ 아래에는 ‘파티셔너’ 임.) |
| 70 | 직렬화된 데이터를 객체로 객체로 복원하는 디시얼라이저(deserializer) | 직렬화된 데이터를 객체로 객체로 복원하는 디시리얼라이저(deserializer) |
| 71 | Customer 객체를 인수를 |
Customer 객체를 인수로 |
| 74 | broker의 CPU 사용량을 줄인다. | 브로커의 CPU 사용량을 줄인다. |
| 74 | (파티셔너에 접착성 처리가 있을 경우를 설명하는 오른쪽 그림에 7이 2개 있음) | (P0 오른쪽은 0, 1, 2.) |
| 74 | 별 것 아니 것으로 | 별 것 아닌 것으로 |
| 81 | 주의할 점은 이 값들이 쓰기 쿼터/읽기 쿼터에 의해 발생한 스로틀링 때문에 지연된 시간을 가리킬 수도 있고, 요청 쿼터 때문에 지연된 시간을 가리킬 수도 있고, 둘 다 때문에 지연된 시간을 가리킬 수도 있다는 점이다. | 주의할 점은 이 값들이 쓰기 쿼터나 읽기 쿼터에 의해 발생한 스로틀링(초당 처리량 기준) 때문에 지연된 시간을 가리킬 수도 있고, 요청 쿼터에 의한 스로틀링(요청을 처리하는 시간 비율 기준) 때문에 지연된 시간을 가리킬 수도 있고, 둘 다 때문에 지연된 시간을 가리킬 수도 있다는 점이다. |
| 83 | 애플리케이션을 구현하기 위해 커슈머 API가 어떻게 활용되는지를 | 애플리케이션을 구현하기 위해 컨슈머 API가 어떻게 활용되는지를 |
| 86 | 하지만, G2 전체를 놓고 보면 다른 컨슈머 그룹과는 상관없이 여전히 전체 메시지를 된다(그림 4-5). | 하지만, G2 전체를 놓고 보면 다른 컨슈머 그룹과는 상관없이 여전히 전체 메시지를 받게 된다(그림 4-5). |
| 99 | 일반적으로 모든 컨슈머들은 동일한 토픽들을 구독하기 때문에 RoundRobin 방식을 선택할 경우 모든 컨슈머들이 완전히 동일한 수(혹은 많아야 1개 차이)의 파티션을 할당받게 된다. | 일반적으로, 만약 컨슈머 그룹 내 모든 컨슈머들이 동일한 토픽들을 구독한다면 (실제로 그런 게 보통이다) RoundRobin 방식을 선택할 경우 모든 컨슈머들이 완전히 동일한 수(혹은 많아야 1개 차이)의 파티션을 할당받게 된다. |
| 101 | 컨슈머에 정작 그룹 멤버십 기능을 적용하기 위해 사용되는 설정으로 … | 컨슈머에 정적 그룹 멤버십 기능을 적용하기 위해 사용되는 설정으로 … |
| 109 | ConsumerRebalance에는 다음과 같이 3개의 메서드를 구현할 수 있다. |
ConsumerRebalanceListener에는 다음과 같이 3개의 메서드를 구현할 수 있다. |
| 122 | consumer.assign(partitions); |
(예제 코드 내의 메소드 호출이 중복 인쇄되었음) |
| 125 | 아파치 카프카 버전 0.11 이전까지는 명령줄 프로그램으로만 가능했던 관리 기능이 가능했지만, … | 아파치 카프카 버전 0.11 이전까지는 명령줄 프로그램을 사용해서만 관리 기능을 사용할 수 있었지만, … |
| 130 | topics.name()는 토픽 이름의 집합에 대한 … |
topics.names()는 토픽 이름의 집합에 대한 … |
| 132 | admin.\ deleteTopics(TOPIC_LIST).\ all().get(); |
(토픽 삭제 코드는 누락되고 삭제를 확인하는 부분만 있음.) |
| 137 | description은 해당 그룹에 대한 상세한 정보를 담는다. |
groupDescription은 해당 그룹에 대한 상세한 정보를 담는다. |
| 152 | 요약하자면, 컨트롤러는 브로커가 클러스터에 추가되거나 제거될 때 파티션과 레플리카 중에서 리더를 선출할 책임을 진다. | 요약하자면, 카프카는 컨트롤러를 선출하고 브로커가 클러스터에 들어오거나 나갈 때 컨트롤러에 알려 주기 위해 주키퍼의 Ephemeral 노드 기능을 사용한다. 컨트롤러는 브로커가 클러스터에 들어오거나 나갈 때 파티션과 레플리카 중에서 리더를 선출할 책임을 진다. |
| 155 | Bridge Release | 브리지 릴리스 |
| 155 | Pre-KRaft: | KRaft 이전: |
| 156 | Post-KRaft: | KRaft 이후: |
| 160 | 만약 팔로워 레플리카가 10초 이상 메시지 요청을 보내지 않거나 10초 이상 가장 최근의 메시지를 가져가지 않을 경우 해당 레플리카는 동기화가 풀린 것으로 간주된다. | 만약 팔로워 레플리카가 일정 시간 이상 읽기 요청을 보내지 않거나, 읽기 요청을 보내긴 했는데 가장 최근에 추가된 메시지를 따라잡지 못하는 경우 해당 레플리카는 동기화가 풀린 것으로 간주된다. |
| 160 | 팔로워 레플리카가 아웃-오브-싱크 레플리카로 판정되기 전, 비활성 상태이거나 뒤쳐진 상태일 수 있는 시간은 replica.lag.time.max.ms 설정 매개변수에 의해 결정된다. | 팔로워 레플리카가 동기화가 풀린 것으로 판정될 때까지 걸리는 시간, 즉 읽기 요청을 보내지 않거나 뒤쳐진 상태로 있을 수 있는 ‘일정 시간’은 replica.lag.time.max.ms 설정 매개변수에 의해 결정된다. (옮긴이 각주: replica.lag.time.max.ms의 기본값은 10초였으나 2.5.0부터 30초로 변경되었다.) |
| 170 | 클러스터의 크기를 키우거나 줄일 때, 파티션의 위치를 다른 브로커로 옮기는 데 걸리는 시간은 파티션의 수에 따라 결정된다. | 예를 들어서 클러스터의 크기를 키우거나 줄이거나 할 때, 파티션의 위치를 다른 브로커로 옮기는 데 걸리는 시간은 파티션의 크기에 따라 결정된다. |
| 171 | 만약 파티션 0의 리더가 브로커 2에 있다면, 팔로워들은 브로커 3과 4에 배치될 수 있다. 하지만 2에 팔로워 브로커가 또 배치되거나 3에 두 개가 모두 배치될 수는 없다. | 만약 파티션 0의 리더가 브로커 2에 있다면, 팔로워들은 브로커 3과 4에 배치될 수 있다. 하지만 브로커 2에 팔로워가 또 배치되거나 (즉 브로커 2에 리더와 팔로워가 하나씩 함께 배치) 브로커 3에 팔로워 두 개가 함께 배치될 수는 없다. |
| 178 | 맵의 각 항목은 메시지 키의 16비트 해시와 같은 키값을 갖는 이전 메시지의 오프셋(8비트)으로 이루어진다. | 맵의 각 항목은 메시지 키의 16바이트 해시와 같은 키값을 갖는 이전 메시지의 오프셋(8바이트)으로 이루어진다. |
| 204 | 7.6 요약 | 7.7 요약 |
| 232 | 보안(Security)는 | 보안(Security)은 |
| 265 | 또 다른 장점은 데이터 중복(redundancy)와 … | 또 다른 장점은 데이터 중복(redundancy)과 … |
| 266 | 만약 동일한 데이터셋을 여러 위치에서 비동기적으로 읽고써야 하는 문제를 해결할 방법을 찾고 있다면 이 아키텍처가 매우 권장된다. | 만약 동일한 데이터셋을 여러 위치에서 비동기적으로 읽고 썼을 때 발생하는 문제점을 해결할 방법이 있다면, 이 아키텍처가 매우 권장된다. |
| 276 | 원본 토픽에 새 파티션이 추가될 경우, 자동으로 대상 토픽을 생성한다. | 원본 토픽에 새 파티션이 추가될 경우, 자동으로 대상 토픽에 새 파티션이 생성된다. |
| 276 | 복제 흐름(replication flow)는 | 복제 흐름(replication flow)은 |
| 281 | 새로운 원본 파티션이 탐지되었을 때 토픽을 추가해주기 위한 대상 클러스터의 Topic:Alter 권한 |
원본 토픽에 새로 추가된 파티션이 탐지되었을 때 대상 클러스터 쪽에 새 파티션을 추가해주기 위한 대상 클러스터의 Topic:Alter 권한 |
| 288 | fetch.min.bytes and fetch.max.wait.ms | fetch.min.bytes, fetch.max.wait.ms |
| 316 | 이미 존재하던 사용자를 삭제할 경우 해당 사용자가 새로운 연결을 맺을 수는 없지만, 기존 연결은 계속해서 작동하게 된다. | (삭제 - 앞 문장과 중복.) |
| 320 | (인쇄 오류) | |
| 324 | 메시 지 암호화는 대개 AES와 같은 | 메시지 암호화는 대개 AES와 같은 |
| 324 | 매시지를 복호화하는 데 | 메시지를 복호화하는 데 |
| 327 | Allow|Deny |
Allow | Deny |
| 334 | (인쇄 오류) | |
| 330 | 쉽표(,)로 구분하는 … | 쉼표(,)로 구분하는 … |
| 353 | --bootstrap-server |
--bootstrap-server localhost:9092 |
| 368 | 만약 첫 어떤 파티션을 어디로 옮기고 싶은지 정확히 아는 경우, 첫 번째 단계를 생략하고 JSON을 직접 생성할 수 있다는 점을 알아 두자. | 만약 어떤 파티션을 어디로 옮기고 싶은지 정확히 아는 경우, 첫 번째 단계를 생략하고 JSON을 직접 생성할 수 있다는 점을 알아 두자. |
| 376 | 클러스터 안의 브로커가 하나도 … | 클러스터 안의 브로커가 하나라도 … |
| 392 | … 기능을 사용해서 하드웨어의 상태를 모해야 할 것이다. | … 기능을 사용해서 하드웨어의 상태를 모니터링해야 할 것이다. |
| 414 | 경보 설정에 모두 사용할 수 있는 속성에 하나 더 있는데, … | 경보 설정에 모두 사용할 수 있는 속성이 하나 더 있는데, … |
| 431 | 시템의 99분위를 찾아내는 식이다. | 시스템의 99분위를 찾아내는 식이다. |
| 432 | 세션 갭 이상으로 이벤트가 도착하지 않으면 … | 세션 간격 이상으로 이벤트가 도착하지 않으면 … |
| 460 | 대체로 네트워크는 내부 침임은 잘 방어하는 편이지만 … | 대체로 네트워크는 내부 침입은 잘 방어하는 편이지만 … |