시스템 규모 확장
- 이 시스템의 주요 컴포넌트인 메시지 큐, 집계 서버, 데이터베이스의 규모 확장은 다음과 같다.
메시지 큐
- 메시지 큐에 대한 내용은 4장에서 자세히 다루었다.
- 생산자는 독립적으로 확장할 수 있다.
- 소비자는 그룹 내의 재조정 작업을 고려하여 확장해야 한다.
- 소비자 추가는 시스템 사용량이 많지 않은 시간대에 진행하는 것이 좋다.
브로커
- 파티션의 수가 변경되면 동일한 ad_id를 갖는 이벤트가 다른 파티션에 기록될 수 있으므로 이에 유의한다.
- 토픽을 여러 개로 세분화하면 아래와 같은 장단점이 있다.
- 장점
- 시스템의 처리 대역폭을 높일 수 있다.
- 소비자 그룹의 재조정 시간이 단축된다.
- 단점: 복잡성이 증가하고 유지보수 소요가 증가한다.
- 장점
집계 서비스의 규모 확장
- 집계 서비스의 대역폭을 늘리기 위한 방법은 두 가지가 있다.
- 방안 1. ad_id마다 별도의 처리 스레드로 분리
- 방안 2. 집계 서비스 노드를 아파치 하둡 YARN과 같은 리소스 프로바이더에 배포
Q. 하둡 YARN?
Resource Manager가 전체 클러스터를 관리하고,Node Manager가 각 노드의 리소스를 관리하며,Application Master가 개별 애플리케이션의 실행을 담당하는 구조
데이터베이스의 규모 확장
- 카산드라의 가상 노드를 활용하여 데이터베이스의 규모 확장
핫스팟 문제
- 특정 ad_id에 대한 클릭 이벤트가 몰리는 경우 핫스팟 문제가 발생할 수 있다.
- 이러한 특정 집계 서비스에 대한 부하가 커지는 경우, 자원 관리자에게 이를 요청하여 추가적인 집계 서비스 노드를 추가한다.
- 이러한 방법 외에도, 전역-지역 집계(Global-Local Aggregation)이나 고유 집계(Split Distinct Aggregation) 등의 방법을 사용할 수 있다.
결함 내성
- 현재 기획안대로 집계를 메모리 내에서만 진행하면, 장애가 발생하는 경우 데이터 손실이 발생할 수 있다.
- 이러한 경우, 모든 집계를 원시 데이터를 다시 읽어 재계산하면 손실은 막을 수 있으나, 데이터 처리 시간이 증가하게 된다.
- 이를 방지하기 위해 현재 시스템 상태(계산 중인 데이터 등)를 스냅샷으로 저장하고, 장애복구 시 이를 복구하는 방법을 사용할 수 있다.
- 이렇게 되면 장애가 발생했을 때, 처리중인 데이터는 스냅샷을 사용해 복구하고, 이후 데이터는 자연스럽게 새로운 집계 서비스 노드가 처리하게 된다.
안녕하세요!