(2023-11-23) ‘신뢰성 있는 카프카 애플리케이션을 만드는 3가지 방법 / 제3회 Kakao Tech Meet’을 보고

🔗 컨텐츠

신뢰성 있는 카프카 애플리케이션을 만드는 3가지 방법 / 제3회 Kakao Tech Meet

✏️ 내용 요약

전달 신뢰도

• 정확히 한 번 : 이벤트 데이터가 발행되고 데이터를 단 한 번만 처리하는것
• 최대 한 번 : 관련 장애에 의해 데이터가 유실되는 것(중복은 발생하지 않음)
• 적어도 한 번 : 네트워크 장애 등으로 인해 데이터가 중복으로 수행되거나 적재될 수 있는 것

⇒ 많은 개발자들은 정확히 한 번을 달성하기 위해 노력.

이벤트 드리븐 아키텍처와 스트림 데이터 파이프라인

• 카프카는?
  • 이벤트 드리븐 아키텍처와 스트림 데이터 파이프라인에서 중요한 역할을 수행
  • 스트림 이벤트를 다루는데 특화 됨
  • 실시간 데이터를 처리하는데 적합
  • 시간 단위 이벤트 데이터를 다루기 위한 타임스탬프, 순서를 보장하기 위한 파티션과 메시지 키와 같은 기능이 카프카에 포함됨
• 네트워크 통신에서 데이터를 주고받을 때 메시지 전달 신뢰성이 반드시 고려해야 함.
  • 아파치 카프카를 개발할 때, 이 부분을 간과하는 경우가 종종 있지만 꼭 고려해야함.

 

Apache Kafka

• 데브원영 기술블로그 : kafka 공부할 때 참고하기

• Producer : 카프카에서 다루는 데이터의 최소 단위인 Record를 Broker로 보내는 역할
• Consumer : Broker에 적재된 데이터를 Consumer가 가져감으로써 마지막으로 데이터가 처리가 됨
• 데이터가 전달되고 적재되는 과정에서 정상적으로 적재, 수행됐는지가 각각 Acknowledgement , Offset commit 이 확인
• 정상으로 적재되었음을 확인받아야지만 다음 데이터 처리 가능
• Broker 에는 Topic (데이터를 담는 공간) 존재. 각각의 레코드에는 Offset이라고 불리는 순차적으로 증가하는 번호를 토대로 카프카 내부에서 처리가 완료되었는지 여부를 확인하는 용도로 사용

방법1) 프로듀서의 메시지 전달 신뢰도

• Producer → 특정 Topic의 파티션 : 레코드 보내기
• Acknowledgement : 다시 돌려받게 되는데 네트워크 장애 등으로 Broker의 토픽에 적재가 되었지만 유실된다면?
• Producer는 Record 다시 전송. → 중복 적재 발생 가능성 생김
• 위 과정을 방지하기 위해 카프카에서는 멱등성 프로듀서 사용

멱등성 프로듀서

• 프로듀서가 보내는 데이터 중복 적재 방지를 위해 enable.idempotence 옵션 제공
• 3.0 이후부터는 자동으로 true 설정
• 기본 프로듀서와 달리 레코드를 브로커로 전송할 때, PID와 Seq를 함께 전달
• PID Seq를 가지고 있다가 중복 적재 요청이 오면, 이후 요청된 중복 레코드는 적재하지 않음
• xor 로 설정 … .? aync produce 방식 call back 방식으로 만들어야지만 원하는 성ㄴ능을 가질 수 있다 .. 어렵네
• 동작방식

방법2) 토픽 to 토픽의 메시지 전달

• 이벤트 드리븐 아키텍처는 이벤트를 로그로 처리
• 로그란, 변경이 되지 않고 계속 append가 되는 데이터를 의미
• 적재된 이벤트를 토대로 카프카에서 지속적으로 컨슈머가 필요한만큼 연산을 수행할 수 있고 느슨한 개발, 이벤트 소싱비용 감소와 같은 특징을 가짐

광고 추천팀에서 사용하는 이벤트 드리븐 아키텍처 예시 - 광고 CPC

• 사용자의 광고 클릭 로그를 이용해 광고주에게는 비용을 청구하고 매체사에게는 CPC 수익을 제공해야하는 로직이 아토믹하게 처리해야하는 경우가 있음
• 문제는 토픽을 가져가는 컨슈머에 장애가 발생하면 하나의 이벤트가 두개의 이벤트로 발생할 때 아토믹하게 진행되는게 아니라 중복이 발생할 수 있음. 커밋을 하지 못했기 때문.
• 이를 해결할 수 있는 방법은 단 하나. 성공을 하거나 실패를 하거나 하나만 해야함.
• 카프카에서는 이런 이벤트를 하나로 묶기 위한 방법으로 트랜잭션 사용.

 

방법3) 컨슈커의 중복 적재 방지

카프카 토픽의 데이터를 컨슈머로 가져오고 어떤 DB에 적재할 때, 커밋과 프로듀서를 하나의 트랜잭션으로 묶는다면 좋은 방법이겠지만, 종류가 다른 DB의 경우 트랜잭션으로 묶는 것은 거의 불가능

데이터 적재와 커밋을 동시에 수행해야 하기 때문

이를 해결하는 방법

1. 유니크 키를 활용한 멱등성 컨슈머
   • Oracle이나 MySQL도 이 기능 제공
   • 이 레코드가 유일무이하다는 Key 사용
   • ex. 이벤트가 발생한 타임스탬프
2. Upsert를 활용하는 멱등성 컨슈머
   • 적재 시, 중복 데이터가 있다면 UPDATE
   • key가 없으면 INSERT
   • MongoDB에서 지원하는 방식
3. Write-ahead log를 활용한 컨슈머
   • 트랜잭션 일어나기 전 로그 미리 기록
   • 하나의 적재과정을 원자 단위로 묶는 것
   • 파일 2개. 각각의 데이터를 적재하고 어디까지 적재했는지 기록하는 WAL file을 통해 단 하나만 적재되는 것을 관리

내부 활용 사례 - 스마트 메시지 서비스

• 톡 채널을 소재 최적화, 타겟 최적화를 통해 적합한 유저에게 특정 광고 제공
• 카프카 Streams와 MongoDB 활용

 

마무리

• Java에 해당되는 내용임. 다른 언어는 지원 여부 확인할 것
• 메시지 전달 신뢰성 테스트는 실제 수행하기 까다로움. 레플리케이션 속도, 커밋 시점, 파티션 분배 등
• 단일 카프카 클러스터에서 대응 가능, 서로 다른 카프카 클러스터 연동 시에서는 다른 관점의 고민 필요
• 가장 중요한 것은 어느 정도 전달 신뢰성을 가질 것이냐. 정말 필요한가. 장애로 판단하고 넘어갈 수 있는가.

💭 의견

경매 기능 구현이 필요한 프로젝트를 진행하면서 카프카 도입을 의논했던 적이 있다. 다만 6주라는 짧은 시간과 다른 주요 기능들 구현에 바빠 적용하지 못해 아쉬움이 남았었다. 기회가 된다면 꼭 공부해서 구현해봐야하지 하는 생각을 가지던 중, 카카오 테크에서 가진 카프카를 주제로한 발표를 접하게 되어 열심히 내용 정리까지 하며 들어봤다.

카프카가 실시간 서비스에 적합한 기술이라는 배경지식 정도만 있는 나에게 꽤나 어려운 내용이었다. 하지만 메시지 전달 신뢰도라는 중요한 개념에 대해 접하고 이해를 더하게 되어 좋았다. 실제 프로젝트를 하면서 메시지가 중복으로 전달되는 상황을 접하긴 쉽지 않다. 하지만 수많은 상황이 발생되는 실제 서비스에서는 얼마든지 가능할 수 있겠으며, 그랬을 때의 피해는 단순히 취업준비생으로서 진행하는 프로젝트에 끼치는 영향과는 차원이 다를 거라는 생각을 했다. 따라서 고객과 사업이 걸려있는 실제 서비스라면, 금전적인 문제가 걸려있는 경우라면, 이런 부분을 절대 간과해서는 안될 것이다.