[밋업후기] 2023 KAFKA KRU 오프라인 밋업 후기

안녕하세요!

8/9일 19시 SKT 타워에서 열린 KAFKA 한국 사용자 모임 밋업을 다녀왔습니다!

채팅 서버를 구현하는 프로젝트를 진행하고 있는데 이때, 메시지 브로커로 아파치 카프카를 사용하느라 알아보고 있는 상황에서 이렇게 카프카 모임 밋업이 있어서 고민없이 바로 신청하여 다녀왔습니다!!

1. “1000만 회원, MAU 500만을 위한 빅데이터 아키텍처” 와 2) 카프카 클러스터 인증/인가의 중요성 이렇게 2개의 세션으로 구성되어 있었습니다.

세션을 간략하게 정리한 것을 공유하겠습니다!

먼저, “1000만 회원, MAU 500만을 위한 빅데이터 아키텍처” 세션입니다.

데이터 아키텍처 변화의 필요성

• 거래액, 브랜드, 회원 수 및 인원(동료)의 증가로 인해 무신사의 데이터 아키텍처 변화의 필요성이 대두됨.

지금의 구조가 문제를 해결 가능한가?

• 문제가 발생할 경우 바로 해결하거나, 불가능할 경우 아키텍처를 개선한다.
• 아키텍처 의사결정 기록(ADR)이 중요하며, 이를 통해 아키텍처 변경의 이유를 기록하고 설명한다.

주요 문제점 및 개선점

1. 긴 기간의 데이터 조회 문제
   • 직접 DB에 접속하여 데이터를 조회하는 방식이 비효율적임.
   • 개선: DB 데이터를 파일 기반으로 저장하여 분산 처리 가능한 EMR 환경 구축.
2. near-realtime 추천
   • 사용자 행동 데이터를 실시간으로 추천하는 요구사항.
   • 개선: API GW와 kinesis를 통해 실시간 데이터 수집 환경 구축.
3. API GW + kinesis의 비용 문제
   • API GW의 사용량 증가로 인한 비용 급증.
   • 개선: API를 직접 개발하고 kinesis를 MSK로 대체.

물리적 및 논리적 데이터 아키텍처

• 데이터 아키텍처의 논리적 구조를 잘 정의하는 것이 중요함.
• “데이터 커버넌스” → 논리적 아키텍처를 통해 데이터에 대한 정의 및 원본 데이터 처리 방식을 명확히 한다.
  • 원본 데이터 = object + activity으로 분리
  • 예: "김신사"가 "슬랙스"를 "클릭"하는 데이터를 "회원정보"라는 object , "상품정보"라는 object , "액션"으로 분리할 수 있다.

더 많은 동료가 데이터에 접근

1. N명의 동료와 일하기
   • 데이터 파이프라인을 구축하는데 유용한 pyspark와 같은 도구 도입.
   • 각 팀원 간의 소통을 원활하게 하기 위한 SQL 등의 통일된 언어 사용.
   • 기술 의사 결정은 팀과 함께한다.
2. 다른 데이터 조직 랜딩
   • SQL, python notebook, BI 환경 제공.
   • 작업 흐름 환경과 데이터 레이크 제공.
   • 요청이 두 번 이상 오면 자동화 프로세스 도입.
3. N백명의 동료와 일하기
   • 데이터 거버넌스 구축: 접근 권한 설정 및 데이터 카탈로그 제공.
   • 데이터 활용 수준에 따라 다양한 환경 제공.
   • 질의 응답이 아닌 가이드를 중심으로 일하기.

다음으로 2번째 세션인 “카프카 클러스터 인증/인가의 중요성 ”에 대해 요약 정리를 해봤습니다.

카프카 클러스터의 인증과 인가는 클러스터 내 데이터의 보안과 안정성을 위해 꼭 필요하고 하셨습니다. 잘못된 인증이나 인가 설정은 데이터 유출, 장애 및 다양한 문제를 초래할 수 있습니다. 인증 인가의 여러 방식에 대해서 설명해주셨습니다. 또한, SASK/OAUTHBEARER 인증 구성에 대한 자세한 내용은 연사님께서 최근에 올려주신 “”에서 확인하실 수 있습니다.

1. 인증과 인가의 중요성

• Producer:
  • 메시지를 생성하여 특정 토픽이나 파티션에 추가한다.
  • 잘못된 포맷의 메시지를 관련 없는 토픽에 추가하면 문제가 발생할 수 있다.
• Consumer:
  • 특정 토픽이나 파티션의 메시지를 읽어온다.
  • 인가 없이 다른 컨슈머 그룹에 참여하면 문제가 발생할 수 있다.
• CLI 도구:
  • 무분별하게 모든 기능을 사용할 수 있어서 문제가 될 수 있다.
• Admin Client API:
  • 관리용 함수 제공.
  • 존재하지 않는 토픽을 만들려는 시도가 있다.

2. 인증 프로토콜

• 인증 없음:
  • PLAINTEXT: 평문 통신.
  • SSL: 암호화 통신으로 서버 확인.
• 인증 사용:
  • SASL_PLAINTEXT: 평문 통신.
  • SASL_SSL: 암호화 통신.

3. SASL (Simple Authentication and Security Layer)

• 클라이언트와 서버 간의 인증 매커니즘을 협상하는 프로토콜.

4. 인증 구성 방법

• GSSAPI: Kerberos v5 기반, 복잡한 구성.
• PLAIN: Username과 password로 인증, client 인증 정보를 static file에 보관 → 불편
• SCRAM: zookeeper에 계정정보 보관, kraft storage에 인증정보 보관, 해시된 값 비교, 카프카와 가장 잘 통합되어 있음
• OAUTHBEARER:카프카 3.1.0 버전에서 릴리즈 , OAuth 위에 OIDC 기반, keycloak 등 OIDC 지원 인증 서버와 연계 가능.

5. 인가 구성

• ACL (Access Control Lists):
  • P: 주체 (client)
  • O: 작업
  • H: 호스트
  • R: 토픽에 대한 읽기/쓰기 허용.

6. 고급 기능

• 위임 토큰: 인증 정보의 임시 발행과 갱신.
• 사용량 제한 (Throttling): 전체 서비스 품질을 보장하기 위해 특정 작업 혹은 클라이언트의 대역폭 등을 제한할 필요가 있음 → 특정 작업이나 클라이언트의 리소스 사용을 제한. → 카프카에 내장된 기능 인 Client Quotas: 네트워크 대역폭과 요청 속도 할당량 설정 가능.

좋은 세션을 준비해주신 연사님들과 데보션분들께 감사드립니다! 🙇‍♀️

(데보션에서 준비해주신 샌드위치와 과일 정말 맛있었습니다!!)👍