넷플릭스가 클릭하우스를 최적화시킨 방법

 

How Netflix optimized its petabyte-scale logging system with ClickHouse

클릭하우스 공식 블로그를 번역 + 개인적인 의견을 첨가한 포스팅 

---

 

모든 종류의 로깅 시스템을 압도한다고 말하는데 얼마나 대단하면 이런 말을 할 수 있는 것인가 ㅎㅎ 넷플릭스는 자부심이 대단한듯

 

Safe to say, this is a scale that would overwhelm most logging platforms. Making that kind of interactivity possible—logs that are searchable within seconds, queries that feel instant—took not just the right database (ClickHouse!) but a series of carefully engineered optimizations.

 

Clickhouse 는 시스템의 중심에 있으며 hot tier 로 동작한다. 속도가 생명인 최신 로그를 저장하고 빠른 쿼리와 상호작용하는 디버깅을 제공한다. 클릭하우스 덕분에 최신 데이터를 빨리 보내줄 수 있다고 관계자는 말한다 (Daniel)

 

ClickHouse sits at the heart of the system as the hot tier. It stores recent logs where speed is critical, powering fast queries and interactive debugging. “Thanks to ClickHouse, we’re able to serve this data very fresh,” Daniel says. “All the buffering we do along the way doesn’t really affect us much.”

 

시스템이 거의 동시에 일어나고 있는것처럼 느껴진다. 로그는 발생한지 20초만에 조회가 가능하고 종종 2초 latency 만에 라이브 로그를 전달받기도 한다고함.

 

The result is a system that feels almost instantaneous. Logs are usually searchable within 20 seconds of being generated, far faster than Netflix’s 5-minute SLA. In some cases, engineers can even stream live logs with two-second latency. They can click into events, expand JSON payloads, group millions of messages by fingerprint hash, or drill into surrounding logs, all without waiting for queries to churn.

 

아무튼 여기까지가 넷플릭스 성능에 대한 자랑이었고 다음부터는 최적화 기법에 대해서 설명하고 있다.

 

Ingestion - Fingerprinting

 

로그 사용성을 높이기 위해서 우선 비슷한 메시지끼리 묶어주는 처리를 함. Fingerpinting 이라고 부르는 기법인데 요 방식이 수백만개의 비슷한 요소들을 하나의 패턴으로 묶어서 노이즈를 줄이게 해줌. 이게 없으면 로그에서 조회하는 작업은 매우 압도적이라고 할 수 있음.

 

처음에는 머신러닝 모델을 이용해서 로그를 그룹화하는 시도를 했음. 이론적으로는 동작했으나 실전에서는 모델을 돌리기에는 컴퓨팅 리소스가 부족했음.

 

그러고 나서 정규표현식 패턴 매칭 방식을 사용했고 generic token 을 swap out 했음. 동작은 했으나 정규표현식은 초당 천만데이터는 따라잡지 못했음.

 

팀은 Fingerprinting 을 다시 조정했고 자바로 구현된 tokenizer JFlex Lexer 라는 것을 만들어냈음. 런타임에 복잡한 정규표현식을 평가하는거 대신 이 시스템은 패턴을 효율적인 코드로 컴파일했음.

 

넷플릭스처럼 돈많은 회사들도 비용절감을 위해 상당히 로우레벨로 까지 내려가고있다는 점. 이래서 회사에서 알고리즘을 면접때 보는 것일지도 모르겠다 

 

Hub - Serialization

 

로그를 fingerprint 했으면 클릭하우스에 작성돼야함. 다른 병목이 있는데 바로 직렬화임.

 

처음에는 JDBC 배치 inserts 방식에 의존했음. 간단하고 친숙했지면 효과적이지 않았다. 모든 준비된 구문들이 클라이언트가 스키마와 직렬화에 대해서 협상해야했고 오버헤드가 있었음.

 

추상화 스택을 포기하고 클릭하우스 low level 자바 클라이언트에게 노출된 RowBinary 포맷을 사용하기로함. 칼럼 단위로 수동으로 직렬화를 시켜줌. 성능이 매우 증가했으나 충분하지는 않았다고함

 

RowBinary 포맷을 사용하면 불필요한 인코딩 데이터들이 포함되지 않기 때문에 데이터 양도 적고 속도도 빨라지게 된다

 

So the team dropped down a level in the abstraction stack, using the RowBinary format exposed by ClickHouse’s low-level Java client. This meant manually serializing data column by column—writing map lengths, encoding DateTime64 as nanoseconds since the epoch, and handling other quirks. It gave them a “huge performance boost,” Daniel says, but it still wasn’t enough.

 

input 포맷별 벤치마크에 대한 블로그 글을 읽고 혁신적인 방식을 고안함. native protocol 이 RowBinary 보다 더 나은 성능을 보였으나 Java client 는 지원하지 않았고 Go client 만 지원했음.

 

 

Beyond the ClickHouse command-line client, the native interface is currently supported only by the C++ and Go clients, with Rust support planned. All main language clients, except C++, support the HTTP interface.

 

직렬화까지 내려간거면 정말 낮은 시스템 레벨에서 성능을 올리기 위해 고민해본거라 할 수 있을것 같다. 일반적인 서비스에서는 고민하기 힘든 일임. 그래서 넷플릭스 개발자들이 돈을 많이 받는 이유일지도 모르겠다 ㅋㅋ

 

나도 일을 하면서 이정도까지 깊이 있게 파본적은 없는거 같은데. 아무튼 대단하고 동기부여가 된다

 

Queries - Custom Tag

 

Ingestion, Serialization 은 쓰기가 오래 걸리는 작업이라면 세번째 병목은 읽는 부분이었음. 엔지니어들은 tag 에 강하게 의존하고 있는데 요 태그가 마이크로서비스, 요청 id, 그외 다른 속성들을 걸러주는 역할을 함. 유용할 수록 태그는 시스템에서 가장 머리아픈 구석이 됨.

 

태그는 원래 Map(String, String) 타입으로 저장되어 있었음. 내부적으로 클릭하우스는 키와 값으로 구성된 두개의 병렬 배열 로 표현함. Lookup 할 때마다 특정 키를 찾기 위해선 배열을 linear 하게 스캔해야함. 넷플릭스 환경에선 시간당 25,000 개의 unique key 와 천만개의 unique values 가 쿼리 성능 저하시키는 요인임

 

클릭하우스 창업자와 얘기한 결과 LowCardinality types 라는 걸 추천 받았고 키 값에는 효과가 있었으나 값은 너무 다양했기 떄문에 완전히 해결하진 못함

 

해결책은 의외로 간단했는데 map 을 샤드하는 방식이다. 태그 키들을 31개의 작은 맵으로 쪼개고 나니 쿼리가 모든 키 값을 확인할 필요 없이 바로 다음 샤드를 확인하게 됐따.