[Kafka] 왜 카프카 인가

1. 문제 

- 개발 업무를 진행하면서 점점 성능의 중요성을 깨닫게 된다. 

- 회사에선 성능을 개선하기 위해서 다양한 방법을 각각의 위치에서 수행하고 있는데, 

- 나같은 저 연차 개발자들은 주로 간단한 SQL 튜닝 업무를 하는 것에서 부터 시작해서 

- DB 엔진을 교체하거나 프로시저 쿼리 배치로 이관하는 프로젝트들이 진행되고 있다. 

- 그 중 가장 언급이 많이 되는 것이 바로 "캐시" 라는 개념인데, 성능을 위해선 레디스 캐시 그리고 가격의 빠른 반영을 위해서 레디스를 기반으로둔 미래 캐시 등을 도입하여 사용하고 있다. 

 

- 한 단계 더 나아가, 데이터에 무언가 가공(ETL)이 가해지는 상황에서 트래픽이 많거나

- 다수의 클라이언트에서 동일한 데이터를 사용하는 경우

• => 인바운드 아웃바운드의 데이터를 동일하게 할 수 있는 방법이 무엇일까 생각하게 되었다. 
• => 카프카를 데이터 파이프라인으로 두고, 컨슈머가 레디스 캐시로 데이터를 검증한다면? 

 

 

2.  과정 : 카프카 장점 

[주요 장점]

• 1) 높은 처리량 
• 2) 빠른 응답속도 
• 3) 안정성 

[세부장점]

• 1) 분산 시스템
  • 네트워크상 연결된 컴퓨터들의 그룹
  • 하나의 서버가 장애가 발생하면, 다른 서버 또는 노드가 대신 처리 

• 2) 페이지 캐시 
• 3) 배치 전송 
• 4) 압축 전송 

 

 

 

3.  결과:  카프카 실전 사용 예시

- 데이터 파이프라인 (넷플릭스)

넷플릭스 tech blog

 

- 데이터 통합 (우버)

 

 

 

4. 질문사항

1) 비동기 처리라는 것은? 

- 동기화 방식

인바운드 API -> postgreSQL -> CRUD 타입 구성 -> 데이터베이스 완료 -> 아웃바운드 이벤트 생성 

데이터 베이스 오차는 줄일 수 있지만 

=> 여러 네트워크 이용하는 환경에서 모든 데이터 변경에 대한 올바른 전달 불확실 

=> 동일한 데이터 수정시에 정확한 순서 보장 어려움 

=> 빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트 지원 어려움 

 

- 비동기화 방식 

프로듀서 토픽 생성 -> 프로듀서 서버 완료 

* "카프카" 데이터 확보 (데이터 파이프라인 역할)

컨슈머 토픽 리슨 -> 컨슈머 서버 진행 

=> 하나의 로직 처럼 보이지만, 각각의 서버는 요청을 하고 그 스레드는 완료됨 

 

2) 토픽은 왜 파티션에 나누어 저장되는가? 

[프로듀서]

- 토픽 : 이메일 주소와 같은 개념 ("토픽", 보낼 값(=객체))

- 토픽의 값은 토픽 안에 파티션에 저장됨 

- 메세지의 키 값을 "해시" 처리해 파티션 구함 

(메세지의 키 값이 동일하면 해당 메세지들은 모두 같은 파티션으로 전송) 

=> 많은 양의 메세지가 들어오는 경우, 파티션을 늘릴 수 있는 기능도 제공 

 

[컨슈머]

- 해당 토픽 리스닝

 

 

---

참고 서적 

- 실전 카프카 개발부터 운영까지

- 아파치 카프카 애플리케이션 프로그래밍 with 자바