신뢰성 있는 데이터 전달 방법

본격적으로 카프카 시리즈를 연재하기 전에 적어보는게 좋을것 같단 생각이 들어 작성해 보았다.

 

이 포스트는 카프카 핵심 가이드 6장을 읽고 작성하였다.

6장의 내용인 만큼 카프카에 대한 기본 이해가 있다면 더 쉽게 읽을 수 있다.

---

신뢰성 있는 데이터 전달은 시스템 설계 단계부터 고려되어야 한다.

신뢰성은 시스템의 속성이기 때문에 카프카와 통합된 시스템도 중요하다.

 

🔐신뢰성 보장

보장(guarantee)이란?

서로 다른 상황에서 시스템이 지켜주기로 약속한 행동을 의미한다.

 

신뢰성이 보장되면, 안전한 어플리케이션을 작성할 수 있다.

시스템이 약속한것이 무엇이고, 서로 다른 상황에서 어떻게 동작하는지 정확히 알 수 있기 때문이다.

 

예를 들어, AICD가 있다.
어떤 데이터 베이스가 AICD를 준수한다면, 트랜잭션 처리와 관련하여 약속된 행동을 보장한다는 의미를 가진다.

• AICD :  관계형 데이터베이스가 보편적으로 지원하는 가장 표준화된 신뢰성 보장 원칙 
  • Atomicity(원자성)
  • Consistency(일관성)
  • Isolation(고립성)
  • Durability(지속성)

그렇다면, 카프카는 무엇을 보장할까?

📌카프카가 보장하는 것들

• 파티션의 메세지 순서
• 프로듀서가 브로커에서 수신되는 방법을 3가지 중 하나 선택할 수 있다.( 커밋(모든 레플리카에 씀) / 리더가 씀 / 응답대기x)
• 최소한 하나의 리플리카가 살아있다면, 커밋된 메세지는 유실되지 않는다.
• 컨슈머는 커밋된 메세지만 읽을 수 있다.

그러나, 신뢰성 있는 데이터를 구축할 때는 trade-off가 수반된다.

카프카는 이를 제어하기 위해 신뢰성의 정도를 결정할 수 있게 개발되었다. 

 

아래의 매개변수들을 적절히 선택하여 신뢰성의 정도를 결정한다. 

 

< trade-off를 제어할 수 있는 구성 매개변수 >

• 메세지 저장의 중요도
• 가용성
• 높은 처리량
• 낮은 지연 시간
• 하드웨어 비용의 중요도

이 매개변수들이 어떤 식으로 적용되는지 자세히 알아보자.

 

1. 복제

카프카 신뢰성 보장의 핵심이다.

 

< 어떤 trade-off가 발생할 수 있을까? >

• 동기화에 약간 뒤처진 동기화 리플리카는 컨슈머의 처리 속도를 저하할 수 있다.
  → 메세지가 커밋되기 전에 모든 동기화 리프리카의 메세지 수신을 기다리기 때문이다.
  
  
• 동기화 리플리카의 수가 더 적으면 파티션 복제가 그만큼 덜 되는 것
  → 중단 시간이나 데이터 유실의 측면에서 위험이 증가 할 수 있다.

2. 브로커 구성

카프카는 토픽마다 신뢰성에 관련된 trade-off를 제어할 수 있다.

복제 팩터

<가용성과 하드웨어 간의 Trade-off>

• 복제 팩터가 클수록 가용성과 신뢰성은 높아지고 장애에 따른 데이터 유실은 적어진다.
  • 복제 팩터가 n일 때, n-1개가 중단 되더라도 신뢰성 있게 읽거나 쓸 수 있다.
    → 가용성을 높이는 대신 하드웨어가 더 많이 소요된다.
  • 반면에, n개이면 최소한 n개의 브로커가 필요하고, n개의 복사본을 저장해야 하므로 n배의 디스크 공간이 필요하다.
  • 토픽의 중요도와 높은 가용성에 따른 지불 가능비용을 고려하여 결정한다.
• 레플리카의 위치
  • 랙 수준의 장애를 방지하기 위해 다수의 랙에 브로커를 위치시킨 후 각 브로커에 랙의 이름을 설정해야 한다 .→ 다수의 랙에 분산되어 있는 상황을 확인할 수 있다.

언클린 리더 선출

아래는 클린 리더에 대한 짧은 정의이다.

• 클린 리더 선출

파티션의 리더가 더 이상 사용할 수 없게 되어 동기화 리플리카 중 하나가 새로운 리더로 선출되는 것
(데이터가 유실되지 않는다는 것이 보장)

사용할 수 없게 된 리더 제외 동기화 리플리카가 존재하지 않는 경우, 아래 3가지 방법이 있다.

• 비동기화 리플리카가 리더가 될 수 있도록 → 언클린 리더 선출(unclean election)
  • unclean.leader.election.enable = true
  • 데이터 유실
  • 일관성 결여
    ex ) 실시간 클릭 정보 분석
• 리더가 될 수 없게
  • unclean.leader.election.enable = false
  • 원래 리더가 사용가능할때까지 대기 → 가용성 떨어짐
    ex ) 신용카드 결제 시스템 (품질과 일관성**)

• 브로커 수준에서만 사용(실제로는 클러스터)

최소 동기화 리플리카

• 가용성과 일관성 둘 중에 어느 쪽에 비중을 둘지 선택한다.
• 커밋된 데이터를 하나 이상의 리플리카에 확실히 쓰고자 한다면, 최소 개수를 늘려야 한다.
  • min.insync.replicas=2 → 리플리카가 3개일 때, 최소 2개가 동기화 되어야 토픽의 파티션에 쓸 수 있다
  • 3개중 2개를 못쓰면, 브로커들이 더 이상 쓰기 요청 받지 않고, 1개가 읽기 전용이 된다.
    • 쓰려고 하면 NotEnoughReplicasException 발생
    • 언클린 리더 선출이 되지 않도록, 바람직하지 않은 데이터를 작성하지 않도록

 

오늘은 신뢰성을 보장하는 시스템을 카프카로 구현하기 위해서

복제와 브로커 구성에 대해 다뤄 보았다.

다음 시리즈에서는 신뢰성 있는 시스템에서 프로듀서와 컨슈머를 어떻게 사용하는지에 대해 작성할 예정이다.