AdminClient 설계방식#

Concept

• CAP Theory : : 분산시스템 설계시 고려하는 중요 3가지 원칙. Consistency(일관성 : 모든 노드가 동시에 같은 데이터를 보여줘야 함. 노드 간 데이터 동기화가 중요) , Availability, Partition Tolerance로 구성됨. 핵심은 기본적으로 3가지 원칙중 2가지만 설계에서 가져갈 수 있고 시나리오에 따라 어떻게 가져가야할 지가 달라진다는 것
• Consistency : 일관성. 분산 시스템에서 Consistency는 기본적으로 모든 노드가 동시에 같은 데이터를 보여줘야 한다는 것을 의미한다. 노드간 동기화가 중요.
• Availability : 시스템이 다운되지 않는게 최우선 순위인것. 모든 요청에 대해 성공/실패와 관계없이 계속 응답을 해야한다.
• Partition Tolerance : 시스템을 구성하는 요소중 하나가 망가지더라도(네트워크 통신 문제 등) 시스템이 계속 동작해야 한다는 특성
• Eventual Consistency : 분산 데이터 스토어 하에서의 모든 노드에서의 읽기작업이 최종적으로 동일한 값을 반환하는 것을 이론적으로 보장하는 것. 고가용성을 보장해야하는 시나리오와 관련있다. 핵심은 단기적으로 일관성을 잃더라도 결국에는(Eventually) 데이터 일관성을 보장하는것.
• Strong Consistency : 특정 한 노드에 변경이 일어나면 즉시 시스템의 모든 노드가 동일하게 동기화되는 것. 핵심은 일단 Transaction이 일어나면 일관성을 유지해야 한다는 것. Consistency를 보장해야 하는 시나리오와 관련있다. 기본적으로 어플리케이션의 확장성과 성능과 트레이드오프를 가진다. 구체적으로는 데이터의 업데이트 또는 복제 프로세스 도중에는 Lock를 통해 다른 프로세스에서 동일 데이터를 업데이트 하지 않도록 해야한다.

Admin Client Config#

토픽#

1
ListTopicsResult topics = adminClient.listTopics(); // Future 객체의 Wrapper
2
topics.names().get().forEach(System.out::println)

설정 가능한 자원#

• 브로커
• 브로커 로그
• 토픽

설정관리 시나리오#

컨슈머 그룹#

재해 복구 등의 시나리오에서 쓴다

클러스터 메타데이터#

파티션 추가하기#

• 보통 토픽이 생성될 때 파티션 수도 같이 결정된다.
• 보통 메시지들이 키를 가진 경우 같은 키를 가진 메시지는 동일한 파티션에 들어가 동일한 순서로 처리될 거라고 예상한다.
• 파티션을 추가할 경우 이와 같은 예상에서 벗어날 수 있기에 위험하다.
• 어지간 하면 안하는게 좋다.

1
Map<String,NewPartition> newPartitions = new HashMap<>();
2
newPartitions.put(TOPIC_NAME, NewPartitions.increaseTo(NUM_PARTITIONS+2));
3
admin.createPartitions(newPartitions).all.get();

레코드 삭제#

• deleteRecords 사용 삭제
• 호출 시점을 기준으로 더 오래된 레코드에 대해서 컨슈머가 읽지 못하도록 삭제 플래그를 거는것
• 실제로 레코드를 디스크에서 지우는 작업은 비동기적으로 일어남

리더 선출#

Concept

• preferred leader : 각 파티션은 기본적으로 선호 리더라는 레플리카를 하나씩 가진다.
• unclean leader : 리더 레플리카가 사용불능인 상황에서 리더가 될 수 없는 레플리카 하나를 리더로 삼는 것. 이 경우 데이터 유실이 일어난다 (예전에 리더에 쓰여졌지만 새 리더로 복제되지 않는 데이터는 모두 유실됨)

레플리카 재할당#

• 레플리카를 어떤 브로커에서 다른 브로커로 이동하는 것
• 레플리카를 추가하는 것
• 레플리카를 재할당하는 일은 기본적으로 대량의 데이터 복제를 초래하기에 네트워크 대역폭에 주의하고 복제 작업을 쓰로틀링 해줄 필요가 있다.