Tech Career/System designs

Distributed Counter (분산 카운터): 분산 시스템 첫걸음

naubull2 2025. 7. 17. 23:49
반응형

들어가며: 숫자를 세는 일, 왜 분산 환경에서 어려울까?

게시글 '좋아요' 수, 웹사이트 방문자 수, 특정 이벤트 발생 횟수… 개발자라면 카운터 기능을 구현해본 경험이 많을 것입니다. 단일 서버 환경에서는 간단한 변수 증가나 데이터베이스의 숫자 필드 업데이트만으로 충분하죠. 하지만 이러한 카운터가 수많은 서버에 분산되어 동작하고, 초당 수천, 수만 건의 요청을 처리해야 한다면 어떨까요? 갑자기 문제가 복잡해집니다.

분산 카운터는 언뜻 쉬워 보이지만, 분산 시스템에서 발생하는 데이터 일관성, 동시성, 성능 등의 핵심적인 문제들을 이해하는 데 아주 좋은 예시가 됩니다. 복잡한 서비스도 아니기 때문에 주니어 개발자를 대상으로 질문하기에도 좋은 주제고요. 이번 포스팅에서는 분산 카운터를 설계하는 과정을 통해, 분산 시스템 설계의 기본 원칙과 다양한 트레이드오프를 살펴보겠습니다.

1. 단일 카운터의 한계와 분산 카운터의 필요성

먼저, 왜 단순한 카운터가 분산 환경에서 문제가 되는지부터 짚어보겠습니다.

  • 단일 서버 카운터:
    • 장점: 구현이 매우 간단하고 빠릅니다.
    • 문제점:
      • 단일 장애점 (Single Point of Failure): 서버에 문제가 생기면 카운터 기능 전체가 마비됩니다.
      • 확장성 한계: 트래픽이 증가하면 단일 서버가 처리할 수 있는 부하를 넘어설 수 있습니다. CPU, 메모리, 네트워크, 디스크 등 자원에 병목이 발생합니다.
      • 동시성 문제 (Concurrency Issue): 여러 요청이 동시에 카운터 값을 업데이트하려 할 때 데이터 손실(Race Condition)이 발생할 수 있습니다. (예: 100에서 동시에 +1 요청 2개가 들어왔을 때, 102가 아닌 101이 되는 경우)
  • 분산 카운터의 필요성:
    • 위와 같은 단일 서버의 한계를 극복하고, 고가용성(High Availability)과 확장성(Scalability)을 확보하기 위해 여러 서버에 분산하여 카운터 기능을 제공해야 합니다.

2. 분산 카운터 설계 시 고려사항

분산 카운터를 설계할 때 우리는 어떤 요소들을 고민해야 할까요?

  • 정확성 (Accuracy) vs. 성능 (Performance):
    • 카운터 값이 항상 정확해야 하는가? (예: 잔고 카운터) 아니면 약간의 오차를 허용해도 되는가? (예: 게시물 조회수)
    • 정확성을 높이려면 동시성 제어가 필요하고 이는 성능 저하로 이어질 수 있습니다.
  • 읽기 (Read) vs. 쓰기 (Write) 비용:
    • 카운터를 읽는 작업이 많은가, 아니면 업데이트하는 작업이 많은가?
    • 어떤 작업에 최적화할지에 따라 설계가 달라질 수 있습니다.
  • 데이터 지속성 (Durability):
    • 서버 재시작 시에도 카운터 값이 유지되어야 하는가? (DB, 영구 저장소 필요)
  • 동시성 제어:
    • 여러 프로세스/쓰레드가 동시에 카운터에 접근할 때 어떻게 일관성을 유지할 것인가? (락, 트랜잭션 등)

3. 분산 카운터 구현 전략 (트레이드오프와 함께)

이제 구체적인 구현 전략들을 살펴보겠습니다. 각 전략에는 장단점, 즉 트레이드오프가 존재합니다.

3.1. DB를 활용한 분산 카운터 (중앙 집중식)

가장 먼저 떠올릴 수 있는 방법은 역시 데이터베이스를 사용하는 것입니다.

  • 개념: 카운터 값을 데이터베이스에 저장하고, 업데이트 시 데이터베이스의 트랜잭션과 락(Lock) 기능을 활용하여 동시성 문제를 해결합니다.
  • 장점:
    • 강력한 일관성 (Strong Consistency): 데이터베이스의 ACID 속성을 활용하여 항상 정확한 카운터 값을 보장할 수 있습니다.
    • 데이터 지속성: 데이터가 영구적으로 저장됩니다.
  • 단점 (트레이드오프):
    • 성능 병목: 모든 업데이트 요청이 단일 DB 서버로 집중되므로, 트래픽이 많아지면 DB에 부하가 심해져 병목 현상이 발생합니다. DB 스케일링이 어려울 수 있습니다.
    • 가용성 문제: DB 서버가 다운되면 카운터 기능 전체가 마비됩니다.
  • 개선 방안:
    • DB 레플리카 (Read Replica): 읽기 요청을 분산하여 읽기 성능을 높일 수 있지만, 쓰기 병목은 여전합니다.
    • Optimistic Locking: 버전 관리를 통해 락 경합을 줄일 수 있지만, 충돌 시 재시도 로직이 필요합니다.

3.2. Redis (or Memcached) 를 활용한 분산 카운터 (캐싱/인메모리 DB)

고성능 읽기/쓰기가 필요한 경우 Redis와 같은 인메모리 데이터 저장소를 고려할 수 있습니다.

  • 개념: Redis의 INCR (increment) 명령어를 활용합니다. Redis는 단일 쓰레드(Single-threaded)로 동작하여 원자적(Atomic) 연산을 보장하므로, 동시성 문제를 별도의 락 없이 해결할 수 있습니다.
  • 장점:
    • 높은 성능: 인메모리 동작으로 매우 빠른 읽기/쓰기 성능을 제공합니다.
    • 원자적 연산 보장: INCR 명령어로 동시성 문제를 안전하게 처리합니다.
  • 단점 (트레이드오프):
    • 데이터 지속성 문제: Redis는 기본적으로 인메모리 저장소이므로, 서버 재시작 시 데이터 손실 가능성이 있습니다 (AOF, RDB 설정을 통해 어느 정도 보완 가능).
    • 스케일링 한계: 단일 Redis 인스턴스도 결국은 한계가 있습니다. 대규모로 확장하려면 Redis Cluster와 같은 분산 환경 구축이 필요합니다.
  • 고려 사항: 카운터의 지속성이 매우 중요하다면, Redis와 함께 영구 저장소(DB)를 동기화하는 전략을 고려해야 합니다.

3.3. 샤딩 (Sharding) 기반 분산 카운터 (분할 및 합산)

매우 높은 쓰기 처리량이 요구되지만, 실시간으로 완벽한 정확성을 요구하지 않는 경우 유용한 방법입니다.

  • 개념: 전체 카운터를 여러 개의 샤드(Shard) 또는 파티션으로 나누어 각 샤드에 대한 카운터를 독립적으로 관리합니다. 이후 필요할 때 이 값들을 합산하여 최종 카운터 값을 만듭니다.
    • 예시: '좋아요' 카운터를 100개의 샤드로 나누고, 사용자 ID의 해시값에 따라 특정 샤드에 '좋아요' 요청을 보냅니다.
  • 장점:
    • 뛰어난 쓰기 확장성: 각 샤드가 독립적으로 업데이트되므로, 쓰기 요청이 특정 서버에 집중되지 않아 높은 처리량을 달성할 수 있습니다. 이론적으로 샤드 수를 늘리면 선형적으로 확장 가능합니다.
    • 고가용성: 일부 샤드에 문제가 발생해도 전체 시스템이 멈추지 않고, 부분적인 서비스만 영향을 받습니다.
  • 단점 (트레이드오프):
    • 결과적 일관성 (Eventual Consistency): 실시간으로 정확한 전체 카운터 값을 얻기 어렵습니다. 모든 샤드의 값을 합산하는 데 시간이 걸릴 수 있고, 합산 시점에는 이미 일부 샤드의 값이 변경되었을 수 있습니다.
    • 읽기 비용: 최종 카운터 값을 얻기 위해 모든 샤드에 쿼리를 날려 합산해야 하므로, 읽기 성능에 영향을 줄 수 있습니다.
    • 복잡성: 샤딩 키 선정, 샤드 관리, 합산 로직 등이 복잡해집니다.
  • 개선 방안:
    • 비동기 합산/캐싱: 주기적으로 모든 샤드 값을 합산하여 캐시해두고, 읽기 요청 시 캐시된 값을 제공하여 읽기 성능을 향상시킬 수 있습니다. 이때 카운터의 "최신성"에 대한 트레이드오프를 감수해야 합니다.
    • Rollup 테이블/서비스: 특정 주기(예: 매시간)마다 샤드별 카운터 값을 집계하여 별도의 테이블이나 서비스에 저장해두는 방법도 있습니다.

4. 종합: 어떤 전략을 선택할 것인가? (트레이드오프)

위에서 살펴본 전략들은 각각 장단점이 명확합니다. 어떤 전략을 선택할지는 결국 요구사항과 트레이드오프에 달려 있습니다.

  • 강력한 일관성 & 낮은 트래픽: DB 기반 카운터 (예: 금융 거래 잔고)
  • 높은 성능 & 결과적 일관성 허용: Redis를 활용한 인메모리 카운터, 또는 샤딩 기반 카운터 (예: 실시간 조회수, 좋아요 수)
  • 매우 높은 쓰기 트래픽 & 실시간 정확성 불필요: 샤딩 기반의 분할 및 합산 방식 (예: 대규모 이벤트 로그 카운팅)

실제 시스템에서는 여러 전략을 하이브리드하여 사용하는 경우가 많습니다. 예를 들어, Redis로 빠르게 카운트를 처리하되, 주기적으로 DB에 최종 값을 동기화하여 지속성을 확보하는 방식이죠.

마치며: 작은 문제에서 큰 원리를 배우다

분산 카운터라는 비교적 간단해 보이는 문제를 통해 우리는 분산 시스템 설계의 핵심 원칙인 확장성, 가용성, 일관성, 성능, 그리고 트레이드오프를 깊이 있게 들여다볼 수 있었습니다. 모든 설계에는 정답이 없으며, 주어진 요구사항과 제약 조건 하에서 최적의 해답을 찾아가는 과정이 중요합니다.

다음 포스팅에서는 분산 시스템 설계의 필수 개념인 CAP 이론에 대해 더 자세히 알아볼 예정입니다. 오늘 다룬 분산 카운터의 일관성 문제와도 밀접하게 연결되니, 다음 글도 기대해주시기 바랍니다!

궁금한 점이 있으시다면 언제든지 질문해 주십시오!

 

참고: 실전 시스템 디자인 인터뷰에서의 Distributed Counter

더보기

특히, Distributed Counter와 같은 특정 컴포넌트는 실제 시스템 디자인 면접에서 단독 문제로 출제되는 경우는 드뭅니다. 만약 단독 문제로 주어진다면, 단순히 기존 DB 솔루션이나 캐시 시스템을 사용하는 것을 넘어 해당 솔루션(예: Distributed key-value 저장소)을 직접 설계하는 과정을 요구할 수 있습니다.

하지만 대개의 경우, Distributed Counter는 사용자 수 추이, '좋아요' 기능 등 특정 서비스 설계 과정에 필요한 컴포넌트 중 하나로 등장합니다. 이때 면접관은 해당 컴포넌트의 필요성을 설명하고, 트래픽 규모나 요구되는 일관성 수준에 따라 어떤 솔루션을 선택할 것인지, 그리고 그 선택의 트레이드오프는 무엇인지에 대한 여러분의 합리적인 의사결정 과정을 보고 싶어 합니다.

따라서 이 포스팅에서 다룬 각 구현 전략의 장단점을 명확히 이해하고, 주어진 상황에 맞춰 최적의 방안을 제시할 수 있는 능력을 키우는 것이 중요합니다.

반응형
저작자표시 비영리 변경금지 (새창열림)