2023 NAVER deview trino, kafka 세션 리뷰

CQuery: 우당탕탕 Trino와 썸타기

Hive+Tez vs Trino

• 하이브 대비 SQL 조회 성능이 매우 빠름

• 하이브는 Yarn에서 리소스를 할당받아 HDFS클러스터에서 데이터를 가져와 쿼리를 처리하는 시간 즉 얀 오버헤드와 쿼리타임이 합쳐진 시간이 전부 처리 시간이 됨

• JVM위에서 띄우기 때문에 얀 오버헤드가 없음
• 코디네이터에서 필요한 메타데이터를 얻고 최적화된 쿼리플랜을 생성함
• 스케줄러에는 워커들에게 작업을 할당하면서 데이터 위치정보를 함께 넘겨줌
• 워커들에서 커넥터로 구분에 여러 디비에서 데이터를 가져와서 읽고 쓸 수 있음
• 여러 스테이지서 나눠진 파이프단위로 워커들의 메모리에 데이터를 올려서 처리

Trino 기능

• 커널, 디스크/네트워크 버퍼 등으로 20% 사용
• Tread stacks, GC, off heap 메모리 등으로 30% 사용
• 스타버스트 피셜 쿼리 실제 처리 가용 메모리는 서버의 56%
  • ex) 100GB 서버 → 80GB JVM(-20%) → 56GB 쿼리 메모리(-30%) → 총 44 GB(-44%)손실
• 워커 안에서 처리되는 객체 페이지>블럭>슬라이스 단위로 잘게 나뉘어서 처리
  • 슬라이스는 메모리를 접근하고 특정 데이터로부터 읽는 라이브러리
• 코디네이터 WEB UI는 DB가 아니라 코디네이터 메모리에 저장되서 날아감

• access-rules.json 파일로 WEB UI에서 보여지는 쿼리에 대한 조회 접근을 제한하고 있음
• Rerty policy: 쿼리 작업 실패 시 자동으로 재시도
  • Fault-tolerant execution 옵션 설정 켜기
  • 특정 작업에 대해서 재시도가 불필요한 경우 사용자가 임의로 끌수 있도록 허용
• Stage 0: 코디네이터에서만 실행되는 태스크로 stage1 작업의 결과 최종 집계
• 스테이지 N(1): Distributed stage로 각 워커에서 작업을 수행하는 단계

ops

• web ui 히스토리 개수만큼 GC가 되지 않기 때문에 개수를 너무 늘리면 OOM, 서버 무응답 등 장애 발생
• JMX로 제공하는 지표를 프로메테우스와 연동해서 사용
• 이벤트리스너를 통한 쿼리별 실행 정보를 엘라스틱서치와 연동
  • 실행한 쿼리 정보
  • 사용한 리소스 정보
  • 실패한 쿼리 exception 정보
• Event Listener
  • Query Creation: 사용자 쿼리가 입력되고 실행되기 전 발생하는 이벤트
  • Query Completion: 사용자 쿼리가 종료된 이후 발생하는 이벤트
  • Split Completion: 쿼리 실행 중 각각의 Stage마다 split 완료될 때마다 발생하는 이벤트

• 이벤트 리스너를 직접 구현해서 사용중
• 리소스 그룹: 그룹내에서 실행되는 쿼리에 대해 대기열 정책을 적용하거나 메모리 CPU 제한을 부여하는 기능

• 특정 사용자의 다수의 쿼리 어뷰징 문제(For문을 통해 기간만 바꿔서 대량의 쿼리 요청)
  • 단기간 요청이 많을 경우 시스템 불안정
• Guard: 어뷰징 쿼리로 인해 클러스터 리소스 전부 잠식하는 경우 발생
  • 특정 worker 장비에서 장기간 CPU 로드 과부하로 인해 클러스터 데이터 처리 지연
  • count(distinct) 함수는 고유값을 찾는 로직이라 무거움 문서에서도 approx_distinct()함수 사용 권장

• 조회 기간이 제한 범위 이내면 쿼리가 정상적으로 실행
• 그래도 UNION, JOIN 등 메모리 과다 사용시 실패 → SPil to Disk 기능 사용(OS의 페이지스왑핑과 흡사한 기능)→일시적으로 한도 이상 메모리 사용가능

To be

• 스케일아웃으로는 한계가 있어서 스케일업을 하려고함→dram보다는 느리지만 저렴한 cxl 기반 메모리 사용

• 저용량에서는 CXL 메모리가 오히려 성능 하락

• 확장된 CXL 저가 메모리는 spilled data가 발생하지 않음 Disk IO까지 사용하는 빈도를 줄여 빠른 쿼리 성능을 기대할 수 있음

• Lyft처럼 앞단에 프록시 게이트웨이를 두어서 쿼리 특성에 따라서 클러스터 자동 전환
  • 반드시 성공을 보장 받아야하는 쿼리는 독립된 클러스터에서 실행
• Hive Table Format에서 Iceberg Format으로 변경
  • PB단위를 넘어섰고 갈수록 증가하는 데이터에서는 Hive MetaStore의 RDBMS, Hadoop NameNode 병목이 가장 큰 문제

네이버 스케일로 카프카 컨슈머 사용하기

Kafka Consumer 동작 원리

• Topic: 1개 이상의 Partition으로 분할, 1개 이상의 Replica로 복제된 log 자료 구조
• Client
  • Producer: 쓰고자 하는 Topic Partition의 맨 끝에 record를 추가
  • Consumer: 읽어오고자 하는 Topic의 Partition에 저장된 record를 순차적으로 읽어옴
• 카프카란? 로그 자료 형태를 분산 스토리지 형태로 만든 것
  • 로그는 레코드를 추가된 순서대로 저장하는 자료구조→순서보장이 가장 큰 특징
  • 카프카에서 제공되는 로그는 분할되고 복제된 로그(파티션, 레플리카)
  • 고가용성, 단일파티션 내에서만 순서보장, 읽기쓰기 리더 레플리카에서만 일어남
  • 하나의 컨슈머는 하나의 파티션을 독점적으로 읽게 됨
  • 컨슈머끼리는 서로 협력해야함
• Consumer Group
  • 같은 group.id 설정값을 가진 Consumer들은 하나의 Consumer Group을 이룬다
  • 같은 Consumer Group에 속한 Consumer들이 Topic에 속한 Partition들을 나눠서 읽는다
  • 컨슈머 리벨런스를 통해서 컨슈머나 파티션에 증감이 있을때 자동으로 멈췄다가 조정해서 시작함

• 컨슈머 추상화 객체→논리적인 컨슈머
• 컨슈머 그룹 기능이 제대로 동작하기 위해 필요한 두가지
  • Partition Assignment기능
    • 중복도 누락도 없이 할당하는 할당 메커니즘
  • Offset Commit 기능
    • 어디서부터 작업을 재개하면 되는지 저장하고 읽는 매커니즘

• 서버가 아니라 컨슈머 그룹중 하나의 컨슈머 리더가 되서 토픽의 파티션들을 컨슈머들에게 할당
  • 컨슈머들끼리는 직접적인 통신을 하지 않고 브로커가 컨슈머 그룹 코디네이터 역할로 경유해서 간접적으로 통신
  • 브로커를 재시작할 필요없이 유연하고 확장 가능한 파티션 할당을 지원하기 위해 이런 구조로 구성됨
• max.poll.interval.ms: 컨슈머가 토픽을 가져올때(poll)의 최대 시간
• session.timeout.ms: 컨슈머가 백그라운드 스레드에서 컨슈머 코디네이터에 보내는 하트비트 신호없이 동작하는 최대 시간
  • heartbeat.interval.ms
• partition.assignment.strategy: ConsumerPartitionAssignor class들의 목록이 들어감
  • 파티션 할당 전략으로 선택
• group.instance.id
  • 정상적 재시작 이전에 할당되어 있던 파티션들을 다시 할당하므로 리벨런스가 발생하지 않음
  • 단순 pod 재시작으로 파티션 리벨런스가 발생하는 사태를 방지
  • 카프카 스트림이 내부적으로 이 설정을 사용함

요약

1. 카프카 컨슈머에는 컨슈머 그룹이라는 개념이 있으며, 같은 컨슈머 그룹에 속한 컨슈머들은 토픽을 읽어올 때 여기 속한 파티션들을 자동으로 나눠가진다.
2. 클라우드 환경에서 컨슈머 그룹 기능을 사용하는 것이 쉽지많은 않으며, 2.x 이후에 업데이트된 기능과 설정들을 적절히 활용함으로써 문제 발생을 막을 수 있다
3. Rack 관련 최적화 기능이 추가된 Partition Assignor는 가능하며, 멀지않은 미래에 보편적인 기능이 될 것이다.