경험을 압축하는 알고리즘은 존재하지 않는다
오늘은 클릭하우스를
듀얼 클러스터로 만들어서
쓰기 전용과 읽기 전용으로 데이터 베이스를
나누는 작업을 진행했다.
이를 CQRS(command query responsibility segregation,명령 쿼리 책임 분리)라고 한다.
우리가 데이터 베이스를 클릭하우스로 선택한 이유를 설명하려면
우리가 뭘 하는질 알아야하는데
클릭랩은 클릭스트림이라고 불리는 웹사이트 사용자 행동 데이터를
초고속으로 수집 분석하는 웹 애널리틱스 플랫폼이다(구글 애널리틱스같은)
이런 주제 특성상 다음과 같은 요구사항이 있는데
- 수만~수십만 건의 이벤트를 초당 처리할 수 있는 쓰기 성능
- 다양한 조건으로 사용자 행동을 집계-분석할 수 있는 쿼리 유연성
이처럼 수많은 이벤트를 빠르게 기록하고
대용량 데이터를 효율적으로 분석해야 하는 환경에서
일반적인 관계형 데이터베이스로는
초당 수만 건의 데이터를 빠르게 쓰기 어렵고
복잡한 조건의 분석 쿼리를 처리하면
금방 느려지는 문제가 생길 것이라고 생각했다
그래서 찾아보다 발견한게 클릭하우스이다
클릭하우스는 컬럼 지향 저장 방식과
벡터화된 실행 엔진을 기반으로
대규모 데이터를 초고속으로 집계하고 필터링할 수 있는 성능을 갖추고 있다
즉 프로젝트 클릭랩에 가장 적합한 선택지처럼 보였다.
페이즈2로 넘어오면서
CQRS를 할 수 밖에 없었던 이유는
클릭랩의 시스템은 한쪽으로는
수십만 건의 사용자 행동 이벤트를 지연 없이 받아들여야 하고
다른 한쪽으로는 복잡한 조건으로 사용자 흐름을 분석하거나
시각화해야 하는 이중적인 요구를 동시에 만족시켜야 하기 때문인데
이 두 가지 작업은 기술적으로 성격이 완전히 다르다
쓰기 작업은 단순하지만 고빈도이고
읽기 작업은 빈도는 낮지만 계산이 복잡하고 리소스를 많이 사용한다
하나의 데이터베이스에 이 두 작업을 동시에 처리하려고 하면
성능 병목이나 데이터 유실의 위험이 존재하게 되고
실제로 API게이트웨이 병목으로 인한 접근 차단과
80%수준의 데이터 전송율을 통해서 직접 경험해보았기 때문에
단일 데이터베이스의 문제점을 체감했다
이를 해결하기 위해 CQRS패턴을 도입한것이다
즉, 쓰기 전용 인스턴스와 읽기 전용 인스턴스를 분리하여
데이터베이스의 분업화를 이룬 것이다
쓰기 전용 데이터베이스는 오직 이벤트 수집에 집중할 수 있도록 설계되어
SDK를 통해 수집된 클릭스트림 데이터는 쓰기전용 데이터베이스에 쌓이고
읽기 전용 데이터베이스는 쿼리 최적화와 캐싱 분석에 집중하여
프론트엔드(대시보드)와 연결되어있다.
그리고 그 둘을 동기화 시켜주기위해
클릭하우스 키퍼라는 개념또한 도입하였다.
키퍼는 쉽게 말해서
조율 도구이다
여러 데이터 베이스 인스턴스가 서로 동시기화 할때
헷갈리지 않게,
데이터를 올바르게 복제-동기화할 수 있도록 해주는 중심축이라고 보면 된다.
우리 클릭랩은 읽기전용 서버와 쓰기 전용 서버를 분리해 놓았는데
고객사 프론트에 설치된 SDK를 통해 발생한 이벤트는
먼저 우리 쓰기 전용 서버에 쓰여지고
읽기 전용 서버는 업데이트되는
쓰기 전용 서버의 데이터를 따라잡기 위해
ReplicatedMergeTree라는 엔진을 사용한다.
이 엔진은 쓰기 전용 서버의 데이터를 보면서
어떤 데이터가 새로 생겼는지
어떤 파티션이 병합됐는지
같은 걸 추적한다
그걸 키퍼를 통해 주기적으로 동기화하면서
읽기 전용 서버가 항상 최신 데이터를 갖고 있도록 해주는 것이다
결국 키퍼가 있어야,
읽기 전용 서버가 안정적으로 분석 쿼리를 처리하면서도
쓰기 서버와 데이터 불일치 없이
잘 따라갈 수 있는 구조가 만들어진다는 것.
이렇게 CQRS구현이 끝나고
이제 오토스케일링 그룹의
시작 템플릿을 만져야 했는데…
시작 템플릿은
나를 밤새게 했다…
월요일과 화요일의 기억은
오로지
시작 템플릿 뿐이다.
경험을 압축하는 알고리즘은 존재하지 않는다.AWS가 이야기하는 격언으로서,
인류를 지속적으로 진화시키는 것은 ‘직감’이 아닌,
‘직접 겪은 경험을 기반으로 한 데이터와 사고방식’이라는 뜻에서 유래되었다.
실제로 아마존은 타 회사들을 압도적으로 상회하는 수준의 Data-Driven 사고방식을 보여준다.
댓글