[Volume 2][Chapter 04] Q&A

[KKambi]

122p. 회전디스크

높은 순차 탐색 성능

seek time + rotation time + transfer time

• 접근 패턴이 순차적일 때 좋은 성능
• 이리저리 이동하거나, 랜덤 액세스할 경우 시간이 더 걸린다...

적극적 디스크 캐시 전략

검색하니까 안나오는데, 124p에 나온 디스크 데이터를 메모리에 아주 적극적으로 캐시 이 의미인 것 같음

127p. 순환 중복 검사(Cyclic Redundancy Check, CRC)

특정 수학적 연산에 기초하여 계산한다.

• 받은 데이터를 통해 CRC를 계산하고, 받았던 CRC와 일치하는지 확인
• 네트워크를 통해 데이터를 전송하는 과정에서 오류가 있었는지 확인하기 위함 (노이즈, 간섭이 많다네요)
• 프로토콜 계층에서 물리층에 가까운지, 전송층에 가까운지에 따라 계산 방식이 다르다는데 정확히는 잘 모르겠다. (하드웨어적 vs 소프트웨어적)
• 하드웨어적 : 직렬데이터(한 비트씩 전송)에 기반한 출력
• 소프트웨어적 : 바이트 단위 기반 출력

132p. Long Polling

Short Polling

• 클라이언트(소비자)가 브로커에 새로운 메세지를 주기적으로 요청한다.
• 서버는 바로 응답한다 (메세지 여기 있어요 or 없어요)
• 커넥션이 자주 발생

Long Polling

• 클라이언트(소비자)가 브로커에 새로운 메세지를 주기적으로 요청한다.
• 서버는 응답을 지연시킨다.
• 메세지가 생기면 응답하거나, 타임아웃이 발생한다 (=최대 어느 정도 시간까지 기다리도록 함)
• 빈 응답이 감소한다.

Short / Long의 차이가 클라이언트의 요청 주기라고 생각했는데 아니었음 Short : 잦은 실시간 통신이 필요한 경우 좋지 않으나, 정기적인 업데이트나 간단한 정보 요청에 유리

152p. 카프카의 exactly once에 관한 이야기

카프카 기본 = at least once

• 유실은 없으나, 중복이 발생할 수 있음
• 평소에는 정확히 한 번만 메세지를 전달함. 문제가 생겼을 때만 at least once라는 것.

문제가 발생해도 exactly once를 보장하기 위한 카프카 기능

1. 멱등성 프로듀서 : Producer unique ID + Sequence ID 전달
2. 트랜잭션 프로듀서/컨슈머
   • 프로듀서 : 여러 레코드를 원자 단위로 묶어 전달
   • 컨슈머 : 트랜잭션이 완료된 메세지만 읽음
   • 추가적으로 : 컨슈머의 오프셋 커밋을 트랜잭션에 포함하는 기능 (sendOffsetsToTransaction)
   • This method should be used when you need to batch consumed and produced messages together, typically in a consume-transform-produce pattern.

데브원영 - 아파치 카프카 Exactly-once 처리의 진실과 거짓 결론 = 정확히 한 번을 달성할 수 있는 구간이 정해져있다.

1. 프로듀서 → 토픽 : 멱등성 프로듀서
2. 토픽A → 컨슈머 → 프로듀서 → 토픽B : 트랜잭션 프로듀서/컨슈머

토픽 → 컨슈머 구간만 봤을 때, 카프카로만 정확히 한 번을 달성할 수 없다.

• 즉, 토픽에서 특정 컨슈머가 정확히 1번만 소비하도록 보장할 수 없다.
• ex) 가져온 레코드를 데이터베이스에 넣는 작업 : 카프카와 데이터베이스는 서로 다른 서비스라 하나의 트랜잭션으로 묶을 수 없다. → 소비한 오프셋을 저장할 때 문제가 발생한다면, 동일한 레코드를 또 저장하게 될 것 → 연동된 서비스에서 중복 적재에 대한 대응이 있다면(유니크 키?) 정확히 한 번 달성 가능

따라서 세 구간을 나눠서 생각한다.

1. 프로듀서->토픽 : 멱등성 프로듀서
2. 토픽->컨슈머->프로듀서->토픽 : 트랜잭션 프로듀서/컨슈머
3. 토픽->컨슈머 : (카프카가 아닌 곳에서도) 멱등성 처리

[zziri]

• 카프카로 푸시 모델 구현이 가능할까? (p.131)
  • 안되는 듯 하다
  • 대부분의 메시지 큐는 푸시 모델 대신 풀 모델을 지원한다
  • 그렇다면 Spring의 KafkaListener는 polling을 하는 걸까
• 카프카로 '정확히 한 번(exactly-once)' 메시지 전달이 가능한가? (p.151)
  • 단순한 형태에서는 가능해보인다 링크
• 카프카 브로커는 무엇인지에 대한 기본적인 이해 링크
• 카프카에서 필터링은 어떻게 할까? (p.152)
  • spring kafka 에서 지원하는 듯 하지만 어떤 원리인지는 모르겠음 링크
• 계층적 타이밍 휠 (p.154)
  • 타이밍 휠 자료구조 링크
  • 타이밍 휠로 긴 시간 간격을 다루면 슬롯이 많아져야하는데, 계층적 구조로 해결한 것이 계측적 타이밍 휠
  • 상위 계층은 하위 계층보다 긴 시간 간격을 다룸
  • 책의 링크는 File Not Found 링크
  • Hashed and hierarchical timing wheels 링크

[kihyun-yang]

p124 WAL?

• MySQL redo log가 WAL(Write Ahead Log)로 구현되어 있다.
  • WAL은 파일에 데이터 변경 내용을 로그(디스크)에 먼저 기록하고 이후 메모리에 적재된 데이터 유실 시, 정합성을 유지하기 위한 기법
    • https://nays111.tistory.com/12
• 접근 패턴이 순차적일 때 디스크는 아주 좋은 성능을 보인다?
  • 회전식 디스크가 느려지는 것은 데이터 접근 패턴이 무작위(random)일 때다.
    • https://velog.io/@kimkevin90/Kafka%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-High-throughput%EC%9D%84-%EB%8B%AC%EC%84%B1%ED%95%A0%EA%B9%8C

[travelbeeee]

p.122 ~ 123

• 메시지가 생산자로부터 소비자에게 전달되는 순간까지 아무 수정 없이도 전송이 가능하도록 메시지 자료 구조를 설계 & 활용
  • => 그러면 메시지 복사에 드는 비용을 최소화해서 높은 대역폭을 제공하는데 도움이 된다
  • ❓메시지 복사는 말 그대로 A 라는 메시지가 있을 때, 가져와서 복사하는건데 아무 수정 없이도 전송이 가능한게 어떤 장점이 있는거지...?
  • 아무 수정 없이도 전송이 가능하다는 뜻이 메시지를 수정할 수 없어서 원본과 복사본이 데이터가 동일함을 보장해준다는 뜻인가...??
  • 뒤에를 읽어보면 그런 것 같다...! ( p.125 메시지 자료 구조 => 소비자에게 전달되는 과정에서 메시지 변경을 막아서 값비싼 복사를 막는다. )

p.125 디스크 성능 관련 유의사항

• RAID : 저장장치 여러 개를 묶어 고용량, 고성능인 저장 잔치 한 개와 같은 효과를 얻기 위한 기법
• 결국, 파티션 내에 데이터를 순차적으로 쌓고, 순차적으로 Consuming 할 것이므로 현대 디스크 성능에서는 크게 이슈가 없을 거다! 라고 책에서 말하는 것으로 이해함

[meloncha]

p.122

• '디스크 기반 자료구조'를 활용한다는 데, 디스크 기반이 아닌 다른 자료구조에는 무엇이 있을까? (SSD??)
• '적극적 디스크 캐시 전략' 이 뭘까?
  • 디스크 캐시 : 디스크 버퍼나 페이지 캐시를 의미할 수 있다.
  • https://en.wikipedia.org/wiki/Disk_cache

p.154

• 카프카 브로커에도 '브로커 내부의 임시 저장소' 가 있을까? 지연 전송 -> 안되는 것 같음
• RabbitMQ 에는 지연 큐(delayed queue) 가능으로 메시지 지연 전송 가능 https://blakes-organization.gitbook.io/springboot2/message-queue/rabbitmq-delayed-queue

[janeljs]

p.123

• 갱신, 삭제 연산이 발생하지 않는 이유?
  • 뒤에 append만 해서 그런가?
  • 디스크에 쓴다는 이야기 보니까 그런듯

p.124

• 지속성을 보장해야 하는 메시지는 디스크에 Write-Ahead Log로 보관할 것을 추천?
• 일관성 vs 지속성
  • 일관성( Consistency ) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것
  • 지속성( Durability ) : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함

p. 134

• kafka coordinator
  • 클러스터의 브로커 중 하나가 coordinator 역할을 함
  • consumer group 상태 체크
  • consumer에 장애 발생 시 파티션을 다른 consumer에게 할당 (rebalancing)
• heartbeat thread
  • data processing과 health check를 같이하면 즉각적으로 consumer의 상태를 점검할 수 없기 때문에 별도 쓰레드로 동작

p. 151

• exactly once는 어떻게 구현하는거지?
  • producer - acks = all 설정
  • enable.idempotence = true 설정
  • broker에게 producer id를 전송해서 중복체크를 한다고 함
  • consumer는 메시지에 대한 consume 기록을 db에 저장해서 재시도가 가능하게 한다고 함
  • kafka streams에서는 지원하는듯?
  • processing.guarantee=exactly_once 설정하면 embedded producer client가 transaction id로 atomicity를 보장해줌

[easyfordev]

저 책을 3단계 초반까지밖에 못읽었어요 ㅜ 이번 챕터는 카프카를 설계하는거구나...정도로 이해했습니다..

p.115

• '전통적인 분산 메시지 큐는 보통 소비 순서는 보중하지 않음'
  • 다수의 소비자가 동시에 큐에서 메시지를 가져갈 수 있기 때문에 소비 순서가 보장되지 않을 수 있다고 서술한 것으로 이해했는데 맞을지.?
  • 121p 보면, 병렬로 소비하기 때문이라고 나와있음