Batch 토픽 발행과 2,000개 파드의 동시 몽고 조회 : 시스템 장애를 막는 분산 전략
in Java on Java
간만에 다시 쓰는 문제 해결 블로그
MSA 환경에서 거의 모든 프로젝트에서 쓰는 공통적인 정보가 있다.
변경이 잦진 않지만 조회는 매우 많은 편.
이런 환경들을 고려하여 하루에 N번씩 카프카를 통해 메시지를 발행하면
모든 프로젝트에서 해당 메시지를 컨슘하면 특정 DB에서 전체 데이터를 조회하여 메모리에 올려서 사용하고 있었다.
메시지를 컨슘하고 DB를 조회하고 메모리에 올려서 사용하는 부분은 각 프로젝트 소스가 아닌 프레임워크 소스로 관리되고 있다.
문제없이 한참 사용하다가 MSA 서비스가 늘어나고 행사기간이라 파드를 늘려놓았더니 문제가 발생하기 시작했다.
데이터는 4만개 파드는 2천개
로우는 약 4만개정도. 파드가 5~600개 수준에서는 문제가 없었다.
하지만 MSA 서비스도 늘어나고, 트래픽을 위해 조금씩 스케일업을 더한 결과 현재는 약 2천여개의 파드가 존재하는 상황.
각 파드의 메모리에 올려야 하기 때문에 각 파드의 hostname으로 컨슈머 그룹이 설정되어있고 메시지는 단 1회만 발행된다.
하나의 메시지가 발행되면 모든 파드들이 동시에 컨슘을 진행. 파드 개수만큼 조회가 일어나고 아주 잠깐이지만 db가 밀리는 현상이 발생하기 시작하였다.
해결을 위한 조건
해결방안이야 수십가지는 있겠지만 현재 상황에서 내가 중요하게 생각했던 부분이 몇가지 있었다.
- 최소한의 변경
프레임워크 소스다 보니까 수정이 잦으면 좋지 않다고 생각했다. 변경하는 부분을 최소화 해야 추가적인 수정이 없을 거라고 생각.
- 최소한의 종속
비슷한 이유. 프레임워크 소스다보니 무언가 다른 시스템에 종속적으로 해결을 하고싶지 않았다.
- 성능
당연한소리!
내가 생각한 해결책
내가 처음 생각한 방법은 토픽 자체를 여러개로 나누는 것이였다.
토픽은 배치가 발행해주고 있기 때문에 토픽명을 0~9까지 나눠서 10초마다 순차적으로 발행하고
ex) 토픽-0 , 토픽-2 , 토픽-9
컨슘하는 프레임워크 소스에선 토픽명뒤에 랜덤으로 숫자를 붙이는 것.
( 랜덤 숫자는 호스트명 해쉬번호 % 10 으로 하려고했다. )
| 호스트명 | hashCode() | % 10 |
|---|---|---|
my-service-pod-abc12 | 1,234,567,890 | 0 |
my-service-pod-xyz99 | 987,654,321 | 1 |
my-service-pod-def45 | -1,111,222,333 | 3 |
배치에서 토픽을 10초마다 0~9까지 발행시키는 변경 프레임워크 토픽명에 숫자를 더하는 1줄의 변경
총 7줄의 소스로 가능한 변경이였지만. 탈락시켰다
탈락이유
- 현재보다 파드가 10배가 늘어나면 똑같은 이슈가 발생 가능.
탈락시킨 AI가 추천해준 해결책
- 메인 파드 하나만 컨슘 후 특정 db에 업데이트 값 저장. sub 파드들은 주기적 폴링을 통해서 업데이트
탈락이유 : 특정 db를 수천개의 파드가 주기적으로 조회를 해야하는 부분이 성능 이슈를 일으킬 수 있을수도 있겠다 생각.
- 레디스 분산락을 통해 순차 조회
탈락이유 : 레디스를 안붙이고 싶은 프로젝트도 있음. 종속성을 가지게 됨 + AI한테 시켜봤는데 소스 변경이 너무 많았다..
선정한 AI 추천 해결책 jitter 패턴
jitter 패턴이란?
Jitter 패턴은 여러 클라이언트/파드가 동시에 같은 작업을 실행하는 걸 방지하기 위해 실행 시점에 랜덤한 지연(흔들림)을 추가하는 패턴
사실 이 방법은 AI가 완벽한 정답이라고 한건 아니지만
내 기준과 가장 부합했다. 최소한의 변경, 최소한의 종속, 성능까지!
메인스레드에 sleep을 걸면 성능 이슈가 발생할 수도 있을 것 같아서 버츄얼스레드를 사용하는 경우에만 sleep을 걸도록 수정. (대부분의 프로젝트가 버츄얼스레드를 사용중이기에 가능)
뭔가 더 멋있게(?) 해결 할 수도 있을 것 같고 AI는 최선의 정답은 아니라고 추가적인 개선을 해야한다고 자꾸 말하지만.
가장 간단하고, 가장 보기쉽고, 가장 안전한 방법이라고 생각했다.
나중에 후임 개발자가 보면 욕하진 않겠지..?
