# Jepsen: Bufstream 0.1 검증 결과

> Clean Markdown view of GeekNews topic #17754. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17754](https://news.hada.io/topic?id=17754)
- GeekNews Markdown: [https://news.hada.io/topic/17754.md](https://news.hada.io/topic/17754.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-11-14T11:02:39+09:00
- Updated: 2024-11-14T11:02:39+09:00
- Original source: [jepsen.io](https://jepsen.io/analyses/bufstream-0.1.0)
- Points: 1
- Comments: 1

## Topic Body

### 업데이트_2024-11-13

- 초기 보고서에서는 auto-commit이 활성화된 소비자가 최근 poll에서 반환된 오프셋을 자동으로 커밋하여 데이터 손실이 발생할 수 있다고 주장했음.
- 그러나 여러 독자들은 auto-commit 소비자가 실제로는 최근 poll이 아닌 그 이전 poll의 오프셋을 커밋한다고 반박했음.
- Java Kafka 클라이언트 실험 결과도 이를 뒷받침하며, 클라이언트마다 다르게 동작할 수 있음.
- auto-commit에 대한 구체적인 주장을 보고서에서 제거했으며, 추가 연구가 필요함.

### 배경

- Kafka는 복제, 샤딩, append-only 로그를 제공하는 인기 있는 스트리밍 시스템임.
- Bufstream은 클라우드 환경에서 데이터 거버넌스와 비용 효율성을 우선시하는 Kafka의 대체 솔루션임.
- Kafka와 유사하게 Bufstream은 _토픽_이라 불리는 부분적으로 정렬된 로그 모음을 제공하며, 각 토픽은 _파티션_으로 나뉨.
- Bufstream은 표준 Kafka 클라이언트와 호환되며, Kafka API를 제공하는 무상태 서비스인 _에이전트_, 데이터를 저장하는 _오브젝트 스토어_, 그리고 _조정 서비스_로 구성됨.
- Bufstream은 데이터 저장을 오브젝트 스토리지 서비스에 직접 기록하여 비용을 절감하고, 무상태, 자동 확장 가능한 VM으로 운영될 수 있음.

#### 클라이언트 안전성

- Bufstream은 다양한 스트리밍 애플리케이션을 위해 설계되었으며, 안전한 동작을 위해 다양한 클라이언트 구성 옵션을 설정함.
- Kafka와 마찬가지로 `acks = all`을 기본으로 사용하며, `enable.auto.commit = false`로 설정하여 데이터 손실을 방지함.
- `auto.offset.reset = earliest`를 사용하여 소비자가 전체 로그를 관찰할 수 있도록 함.

#### 트랜잭션

- Bufstream은 Kafka의 트랜잭션 시스템을 지원하며, 복잡한 구성을 통해 약한 형태의 원자성을 제공함.
- 소비자는 `read_uncommitted` 또는 `read_committed` 격리 수준에서 실행될 수 있으며, `read_committed`는 일부 현상(G1a, G1c)을 방지함.
- Kafka, Redpanda, Bufstream 모두에서 G0 현상이 발생하며, 이는 문서화된 격리 수준과 일치하지 않음.

### 테스트 설계

- Bufstream 0.1.0부터 0.1.3까지 테스트했으며, Jepsen 테스트 라이브러리와 Java Kafka Client를 사용함.
- 테스트는 다양한 결함을 주입하여 Bufstream의 안전성을 평가함.

#### 큐

- Kafka의 데이터 모델에 맞춘 큐 작업 부하를 설계하여 Bufstream에서 사용함.
- 각 논리적 프로세스는 프로듀서, 소비자, 관리자 클라이언트를 실행하며, 다양한 키에 대해 레코드를 전송함.

#### 중단

- 예상치 못한 결과를 바탕으로 트랜잭션을 중단하고 오프셋을 추적하는 작업 부하를 설계함.
- 중단된 트랜잭션 후의 오프셋을 네 가지 범주로 분류함: _진행_, _되감기_, _더 되감기_, _기타_.

### Bufstream 결과

#### 멈춘 소비자 (#1)

- 0.1.0부터 0.1.3-rc.8까지 `consumer.poll()` 호출이 즉시 반환되며 레코드를 반환하지 않는 문제가 발생함.
- Bufstream은 0.1.3-rc.6에서 캐시를 새로 고침하여 문제를 해결함.

#### 멈춘 프로듀서 및 소비자 (#2)

- 0.1.3-rc.6에서도 `InitProducerId` 호출이 실패하거나 `listOffsets` 호출이 실패하는 문제가 발생함.
- Bufstream은 추가 폴링 로직을 추가하여 문제를 해결함.

#### 잘못된 0 오프셋 (#3)

- 0.1.0부터 0.1.3-rc.2까지 잘못된 0 오프셋이 할당되는 문제가 발생함.
- Bufstream은 0.1.3-rc.6에서 이 문제를 해결함.

#### 트랜잭션 쓰기 손실 (#4)

- 0.1.2에서 커밋된 트랜잭션의 레코드가 사라지는 문제가 발생함.
- Bufstream은 0.1.3-rc2에서 문제를 해결함.

#### 서버 측 필터링으로 인한 쓰기 손실 (#5)

- 0.1.3-rc.8에서 경미한 결함에 반응하여 쓰기 손실이 발생함.
- Bufstream은 0.1.3-rc.12에서 문제를 해결함.

### Kafka 결과

#### 오해의 소지가 있는 오류 메시지 (KIP-588)

- `ProducerFencedException`이 트랜잭션 타임아웃에도 발생하는 문제가 있음.
- Kafka 팀에 오류 메시지 변경을 권장함.

#### 소비자 종료 시 무한 대기 가능성 (KAFKA-17734)

- `Consumer.close()` 호출이 네트워크 IO에서 무한 대기하는 문제가 있음.
- KAFKA-17734를 통해 문제를 추적함.

#### 트랜잭션 실패 후 예측 불가능한 소비자 오프셋 (KAFKA-17582)

- 트랜잭션 실패 시 소비자 오프셋의 의도된 동작에 대한 문서가 부족함.
- 소비자가 중단된 트랜잭션 후 오프셋을 되감거나 계속 진행할 수 있음.

## Comments



### Comment 31235

- Author: neo
- Created: 2024-11-14T11:02:40+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=42115611) 
- Kafka에서 발생하는 문제를 조사하던 중, 보이지 않는 쓰기가 발견됨. 이는 지연된 Produce 메시지가 미래의 트랜잭션에 포함되어 트랜잭션 보장을 위반할 가능성을 제기함. Kafka Java Client가 요청 시간 초과 시 시퀀스 번호를 재사용할 수 있다는 의심도 있음. 더 많은 Kafka 테스트가 필요함
  - Jepsen이 Kafka에 대한 심층 조사를 다시 해야 할 것 같음. 마지막 조사는 2013년에 있었고, Kafka 자체에서 많은 문제를 발견할 가능성이 있음. "쓰기 확인 후 조용히 폐기" 같은 문제는 매우 심각해 보임

- Bufstream의 제품 페이지를 보고 두 가지 진술이 어떻게 호환되는지 궁금함
  - Bufstream은 AWS 또는 GCP VPC 내에서 완전히 실행되어 데이터, 메타데이터 및 가동 시간을 완전히 제어할 수 있음. Bufstream은 절대 외부와 통신하지 않음
  - Bufstream의 가격은 단순함: 압축되지 않은 GiB당 $0.002 (약 $2 per TiB). 코어, 에이전트, 호출당 요금은 없음
  - 전체 사업을 신뢰 시스템에 기반하여 운영할 것 같지는 않음

- Kafka의 auto-commit 기능에 대해 놀라움을 느낌
  - Kafka 소비자는 실제로 처리되었는지 여부와 관계없이 오프셋을 자동으로 커밋할 수 있음. 이는 소비자가 레코드를 폴링하고 커밋한 후 충돌하면 레코드가 손실될 수 있음을 의미함
  - 문서에 따르면, auto-commit이 활성화되면 poll 메서드가 호출될 때마다 반환된 메시지의 오프셋을 자동으로 커밋할 준비가 됨. 메시지 처리가 완료되지 않으면 충돌 시 메시지 진행이 손실될 위험이 있음
  - auto-commit 간격을 조정하면 중복 처리에 도움이 되지만 메시지 손실에는 도움이 되지 않음

- Kafka 트랜잭션 프로토콜이 근본적으로 문제가 있으며 수정이 필요함
  - 훌륭한 조사 작업과 작성임

- Kyle이 NATS Jetstream을 검토했는지 궁금함

- bufstream의 GitHub 프로젝트를 찾지 못했음. 단서가 있는지 궁금함

- 관련 블로그 게시물과 문서를 읽은 후, Kafka는 "정확히 한 번 전달"을 "읽기-처리-쓰기 작업"의 속성으로 정의함. 이는 트랜잭션으로 설명하는 것이 더 나을 것 같음

- "트랜잭션은 일부 또는 전체를 관찰할 수 있음"이라는 문구는 "소비자는 일부 또는 전체를 관찰할 수 있음"으로 읽어야 할 것 같음

- 이 소프트웨어는 무엇에 사용되는지 궁금함. 계측? 블랙박스?