Redis 논리적 파티셔닝으로 트래픽 병목 현상 해결!

본문에서는 단일 Ready Queue의 HOL Blocking 문제를 해결하기 위해 논리적 파티셔닝(Logical Partitioning)을 도입했다. 기존에는 모든 TaskGroup의 Job이 단일 Redis Sorted Set에 적재되어 대량 TaskGroup의 Job이 다른 요청 처리를 지연시키는 문제가 발생했다. 해결책으로 Redis 인스턴스 자체를 분리하는 대신, Keyspace 분리(Keyspace Separation)를 통해 Queue를 여러 개로 나누는 방식을 택했다. TaskGroupID를 기준으로 해시(Hash)하여 각 Job을 특정 Partition으로 라우팅하고, 각 Partition은 독립적인 Consumer + Worker 파이프라인을 갖도록 설계했다. 이로써 TaskGroup 간의 간섭을 줄이고, TaskGroup 단위의 우선순위 관리 및 상태 추적이 용이해졌다. 결과적으로 HOL Blocking 문제 해결(HOL Blocking Resolution)과 더불어 시스템의 안정성을 확보했다.

본문에서는 Coordinator를 활용하여 Partition별 Worker 수를 독립적으로 관리하는 방법을 제시한다. Coordinator는 각 Partition의 부하 상태를 주기적으로 관찰하고, 스케일링이 필요하다고 판단되면 해당 Partition의 Scaling Command Queue에 커맨드를 발행한다. 각 Consumer는 자신의 Command Queue를 감시하다가 커맨드가 도착하면 Worker 수를 조절한다. 이 아키텍처는 Partition 간의 간섭을 최소화하고, 각 Partition이 독립적으로 스케일링될 수 있도록 설계되었다. 또한, Consumer 프로세스 재시작 시 Worker 수 정보를 Redis에 저장(Checkpoint)하여 스케일링 수렴 시간을 단축했다. Coordinator는 관찰(Observation), 결정(Decision), 실행(Execution)의 역할을 분담하여 시스템의 유연성을 높였다.

파티셔닝 적용 시 가장 중요한 결정 중 하나는 파티셔닝 기준이다. 본문에서는 세 가지 후보 — 고객사(Channel) 단위, 벌크액션 유형(Type) 단위, 벌크액션(TaskGroup) 단위 — 를 비교 분석하고, 최종적으로 벌크액션(TaskGroup) 단위 파티셔닝을 선택했다. 고객사 단위는 특정 고객사에 부하가 집중될 수 있고, 벌크액션 유형 단위는 Job 규모 차이로 인해 격리 효과가 제한적일 수 있다는 단점이 있었다. 벌크액션 단위 파티셔닝은 각 요청을 독립적으로 분배하여 부하 분산을 극대화하고, 특정 대규모 요청의 영향을 최소화하는 데 기여했다. 라우팅 시 TaskGroupID를 Partition Key로 사용하며, 같은 TaskGroup의 Job은 항상 같은 Partition으로 라우팅되도록 설계했다. 이로써 부하 분산(Load Balancing)과 격리(Isolation)를 동시에 달성했다.

논리적 파티셔닝과 동적 스케일링 도입 결과, 10만 건 기준 처리 시간이 25분에서 4분으로 84% 단축되는 획기적인 성능 개선을 달성했다. 또한, HOL Blocking 문제 해결과 더불어 Partition별 Worker 수를 부하에 따라 자동 조절함으로써 개발자의 수동 개입 없이 시스템이 자동으로 부하에 대응하도록 개선되었다. 배포 전략 섹션에서 설명한 4단계 전환은 서비스 중단 없이 완료되었으며, 기존에는 부하 상황에서 개발자가 직접 Worker 수를 조정해야 했지만, 동적 스케일링 도입 이후에는 수동 개입 없이 시스템이 자동으로 부하에 대응하게 되었다. 이러한 자동화는 운영 효율성(Operational Efficiency)을 크게 향상시켰다.

현재 구조는 몇 가지 한계점을 가지고 있다. 첫째, Partition 수가 설정 시점에 결정되어 운영 중 동적으로 변경할 수 없다는 점이다. Partition 추가/제거 시에는 재배포가 필요하다. 둘째, 해시 기반 라우팅으로 인해 Hot Partition이 발생할 가능성이 있다. 이러한 문제를 해결하기 위해 Shuffle Sharding 도입을 고려해볼 수 있다. 또한, 논리적 파티셔닝에서 물리적 파티셔닝으로 전환해야 하는 Redis 부하 임계점을 구체적으로 정의해야 한다. 현재는 Redis CPU 사용률을 모니터링하며 필요 시 전환할 계획이다. 이러한 과제들을 해결함으로써 시스템의 확장성(Scalability)과 안정성(Stability)을 더욱 향상시킬 수 있을 것이다.