1. 배경: 페이스북, 트위터, 유투브 등 실시간 애플리케이션들은 많은 사용자 상호작용(예: 좋아요, 댓글)을 처리해야 합니다. 이러한 애플리케이션들은 매분 수백만 건의 쓰기 요청을 받을 수 있으며, 쓰기 작업은 읽기보다 시간이 더 많이 소요됩니다. 이로 인해 동시성 문제가 복잡해지고, 특히 카운터(노드 메모리 내의 변수)의 동시 쓰기가 증가하면 잠금 경합이 비선형적으로 증가합니다.

2. 분산 카운터의 필요성: 단일 트윗이 백만 개의 좋아요를 받을 때, 각 좋아요에 대한 쓰기 요청을 처리해야 합니다. 이를 동시에 처리하면 데이터 불일치가 발생할 수 있습니다. 이를 해결하기 위해, 요청들은 데이터 일관성을 위해 큐에서 순차적으로 처리됩니다. 하지만 이 방법은 지연을 추가합니다. 실시간 애플리케이션은 사용자 경험의 질을 높이기 위해 가능한 한 최소한의 지연 시간을 제공하고자 합니다.

3. 분산 카운터의 도입: 샤딩된 카운터는 각 카운터에 필요한 수만큼의 샤드를 지정하여 다양한 계산 단위에서 병렬로 실행하는 방식입니다. 이를 통해 성능을 향상시키고 경합을 줄일 수 있습니다. 사용자가 특정 트윗에 좋아요를 누를 때, 시스템은 해당 트윗 카운터로 쓰기 요청을 전달하고, 사용 가능한 샤드 중 하나를 선택하여 좋아요 수를 증가시킵니다.

4. 분산 카운터의 설계: 샤딩된 카운터를 생성할 때 샤드의 수를 결정하는 것이 중요합니다. 샤드 수가 적으면 쓰기 경합이 높아지고, 많으면 읽기 작업에 더 많은 오버헤드가 발생합니다. 샤드 수는 특정 카운터에 대한 단기적인 쓰기 부하를 예측하는 여러 요인에 따라 결정됩니다. 예를 들어, 많은 팔로워를 가진 사용자의 트윗은 적은 팔로워를 가진 사용자의 트윗보다 더 많은 샤드를 가질 수 있습니다.

5. 분산 카운터의 운영: 샤딩된 카운터는 라운드 로빈, 무작위 선택, 메트릭스 기반 선택 등 다양한 방법으로 샤드를 선택할 수 있습니다. 읽기 요청이 있을 때, 시스템은 모든 샤드의 값을 집계하여 총 카운트를 반환합니다. 샤딩된 카운터의 배치는 특정 사용 사례에 따라 달라질 수 있으며, 카운터 값은 적절한 데이터 저장소에 저장될 수 있습니다.

6. 평가: 샤딩된 카운터는 단일 장애 지점의 위험을 제거하고, 시스템의 가용성을 높입니다. 또한, 필요에 따라 샤드를 추가하여 확장성을 제공하며, 각 쓰기 요청을 적절한 샤드에 매핑하여 신뢰성을 향상시킵니다.

https://medium.com/@sureshpodeti/sharded-counters-8a9a760a7b53