아파치 쿠두를 통한 실시간 워크로드 최적화
실시간 분석 수행을 위한 최선의 선택으로 아파치 쿠두(Apache Kudu)에 많은 이가 주목하고 있다. 컬럼형(Columnar) 스토리지 엔진인 쿠두가 빠른 분석에 유리한 이유는 무엇일까?
빠른 분석과 빠른 데이터 처리를 위한 최선의 선택
아파치 쿠두 PMC 멤버이자 클라우데라 소프트웨어 엔지니어인 앤드류 웡은 쿠두가 왜 필요한지부터 묻는다. 스키마 변화가 많은 데이터 세트를 다루거나, 분석을 위한 스캔과 열 검색 작업을 동시에 자주 하거나, 최대한 빨리 최신 데이터를 대상으로 쿼리를 수행하고 싶을 경우라면, 스키마 업데이트가 쉽고 데이터가 들어오자마자 활용할 수 있고, 끊임 없이 업데이트와 삭제가 가능한 쿠두가 최선의 솔루션이라는 설명이다.쿠두의 특징
쿠두는 데이터가 저장되는 공간인 테이블(Table)과 이들로 구성된 태블릿(Tablet), 이들을 저장하는 태블릿 서버(Tablet Server), 쿠두 구성 요소의 메타 데이터를 담고 있는 마스터(Master)로 구성된다. 각 테이블 스키마에는 프라이머리 키(Primary Key)가, 파티션 스키마에는 파티션 키가(Partition Key)가 정의되어 있다. 태블릿 간 복제는 Raft 합의 알고리즘을 이용해 리더(Leader)와 팔로워(Follower) 관계로 구성된다. 마스터에는 태블릿과 파티션에 대한 메타 데이터가 담기고, 태블릿 서버에는 복제된 태블릿 데이터가 저장된다.쿠두에서 쓰기 작업은 다음 그림처럼 이루어진다. Raft 합의 알고리즘에 따라 리더에서 팔로워로 복제가 이루어지고 인메모리로 처리된다.
태블릿에 쓰기가 이루어질 때 쿠두는 블룸 필터와 프라이머리 키 인덱스를 이용해 불필요한 탐색을 최소화한다.
스캔을 통해 열을 읽을 때도 프라이머리 키를 참조해 관계없는 태블릿은 건너뛴다.
파티셔닝과 관련해 앤드류 웡은 몇 가지 팁을 알려 주었습다. 일반적인 쿼리의 경우 파티션 Pruning 기능을 활성화하여 디스크 I/O를 최소화한다. 쓰기는 여러 파티션에 걸쳐 이루어지게 하고, 가능하면 각 태블릿 복제본을 수십 GB 수준으로 작게 유지하는 것이 좋다.
하드웨어 자원 배분
쿠두는 WAL과 데이터 디렉토리로 저장 공간을 구분한다. WAL은 각 태블릿에 대한 로그와 메타 데이터를 저장하는 곳으로 보통 SSD, NVME 저장 장치를 사용한다. 데이터 디렉토리는 태블릿 복제본을 저장하는 곳으로 성능이 크게 중요하지 않아 일반적인 디스크를 쓴다.읽기와 스캔 작업이 몰리면 자원 부족으로 인한 문제가 생길 수 있다. 메모리가 부족하면 디스크로 작업이 쏠려 성능 전반에 영향을 줄 수 있다. 관련해 앤드류 웡은 메모리와 캐시 자원 확장에 대한 가이드를 제시했다. 메모리의 경우 디스크 상의 데이터 1TB당 1.5GB를 할당한다. MRS(MemRowset), DMS(DiskRowsets) 쓰기 작업의 경우 복제당 최소 128MB를 잡아야 하고, 만일 스캔이 잦은 테이블이라면 컬럼당 256KB를 잡아야 한다. 블록 캐시의 경우는 기본값인 512MB로 설정하면 된다.
자원 모니터링 방법
클러스터 환경에서 메모리 자원 사용에 대한 모니터링은 쿠두의 스캔 대시보드(https://tserver:8050/scans)를 이용한다.태블릿 서버 중 어떤 것이 메모리를 많이 점유하고 있는지는 쿠두가 제공하는 트랜잭션 대시보드(https://tserver:8050/transactions)에서 확인할 수 있다.
GUI 환경보다 CLI가 더 편하다면 쿠두가 제공하는 CLI 도구인 memtrackers(https://tserver:8050/mem-trackers)를 사용해도 된다. 만일 클라우데라 매니저(Cloudera Manager)를 이용할 경우에는 쿠두 관리 화면을 따로 열지 않고 단일 창에서 통합해 모니터링할 수 있다.