SLASH 23 — 실시간 시세 데이터 안전하고 빠르게 처리하기

장중에 처리부 장애가 발생하면 시세 데이터를 쓰는 모든 서비스가 영향을 받아 사용자에게까지 잘못된 정보가 전달되고 고객센터 전화에 불이 난다. 더 까다로운 점은 처리부를 복구하더라도 API를 쓰는 서비스들은 여전히 장애를 겪는다는 것이다. 장애가 난 동안 데이터가 유실되거나 오염됐을 수 있기 때문이다. 한두 건이면 수작업으로 보정할 수 있지만 초당 수천 건을 다루는 상황에서는 찰나의 장애에도 셀 수 없는 오류가 쌓인다. 그래서 발표자가 택한 해법은 오염된 데이터를 장중에 복구하기보다, 처리부와 Redis를 두 그룹으로 만들어 두고 장애가 나면 문제없는 그룹으로 재빨리 전환하는 것이다. 평소엔 A그룹만 서비스에 쓰다가 장애 시 B그룹으로 트래픽만 돌린다. 이 구조는 배포에도 유리해 A·B를 번갈아 배포하며 결과를 비교하고, 문제가 있으면 트래픽 전환만으로 빠르게 롤백할 수 있다. 또 시스템 장애에 대비해 각 그룹의 처리부를 2개로 늘리고 주키퍼로 리더를 선출해, 중복 데이터를 막기 위해 그룹마다 리더만 데이터를 처리하게 했다.

다만 처리부 수가 늘면 수신부가 같은 데이터를 그 수만큼 반복 전송해야 해 성능이 떨어지는 새 고민이 생긴다. 이는 메시지 브로커로 수신부와 처리부를 디커플링해 수신부가 한 번만 보내게 하면 풀린다. 그런데 시세 플랫폼에서 가장 중요한 것이 낮은 지연인데 브로커를 끼우면 아이러니하게 지연이 늘어, 어떤 브로커를 고르느냐가 결정적이었다. Kafka는 높은 처리량과 안정성을 제공하고 사내에서 널리 쓰여 초기에 채택했지만, 자체 테스트에서 차선 후보인 Redis Pub/Sub보다 지연이 길어 결국 버렸다. 동일 부하 피크 기준 수신부에서 처리부까지 총 지연이 Kafka는 15ms인 반면 Redis Pub/Sub은 3ms였다. Redis Pub/Sub은 메시지를 내부 큐에 쌓지 않고 받는 즉시 채널 구독자에게 곧장 보내기 때문인데, 구독자가 없으면 데이터를 버려 유실 가능성은 있지만 지연을 줄이는 면에서 유리하다는 트레이드오프를 받아들였다.

Redis Pub/Sub의 내부를 들여다보면 pubsub_channels라는 딕셔너리에 모든 채널과 구독자 정보가 담기고, 발행자가 메시지를 보내면 채널의 연결 리스트를 순회하며 구독자들에게 차례로 전송한다. 다만 Pub/Sub이 아무리 빨라도 처리부가 늦게 처리하면 지연은 다시 늘어난다. 그래서 처리부의 일을 TCP 소켓에서 데이터를 읽는 일과 비즈니스 처리로 나눠 보면, 읽는 속도가 지연에 큰 영향을 준다. TCP 흐름 제어는 송신이 수신보다 빠를 때 유실을 막는 메커니즘으로, 수신자가 받을 수 있는 양(윈도우 사이즈)만큼만 송신자가 보낸다. 즉 처리부의 수신 버퍼가 가득 차면 Redis가 더 보내지 못해 지연이 늘므로, 읽는 스레드가 한가하도록 비즈니스 로직은 반드시 별도 스레드에 위임해야 하고 블로킹 IO가 있다면 더더욱 그렇다.

발표자는 Spring Data Redis의 리액티브 RedisTemplate을 썼는데, 이는 Lettuce 클라이언트와 그 아래 Netty를 쓴다. Netty의 채널은 소켓을 추상화한 레이어로 이벤트 루프에 등록되고, 이벤트 루프는 무한 루프를 돌며 수신 버퍼의 데이터를 읽는다. NIO 실행 흐름을 보면 버퍼 확인·읽기·변환·통보 순인데, 이 NIO 이벤트 루프가 비즈니스 로직을 처리하지 않게 하는 것이 핵심이다. 그러나 비즈니스 처리를 단순 멀티스레딩으로 분리하면 처리 순서가 역전돼, 짧은 시간에 삼성전자 체결 전문 여러 개가 들어왔을 때 앱에 엉뚱한 가격이 보일 수 있다.

그래서 멀티스레딩 대신 이벤트 루프 그룹을 썼다. 이벤트 루프는 큐로 순서를 보장하고 스레드를 하나만 써 동기화가 필요 없다. 다만 어느 루프에서 처리할지 알려면 종목 코드를 미리 알아야 했고 이를 위한 JSON 변환이 트래픽이 늘수록 NIO 이벤트 루프의 CPU를 잡아먹어 또 다른 지연 원인이 됐다. 해법은 Redis Pub/Sub의 채널 활용이었다. 수신부가 처리부의 이벤트 루프 개수만큼 채널을 나눠 보내면 처리부는 채널명만 보고 해당 루프를 찾으니, 보낸 순서를 그대로 유지하면서 NIO 이벤트 루프에서 객체 변환을 없애 성능이 올라갔다. 이벤트 루프는 Spring ThreadPoolTaskExecutor의 코어·맥스 풀 사이즈를 1로 설정해 만들었고, 큐 사이즈는 정답이 없어 너무 작으면 피크에 유실되고 너무 크면 오래된 데이터가 쌓여 실시간성이 떨어진다.

이벤트 루프 그룹은 ThreadPoolTaskExecutor를 여러 개 만들어 리스트로 구성했고 리스트 개수가 곧 이벤트 루프 개수다. 이 개수는 늘수록 컨텍스트 스위칭으로 NIO 이벤트 루프 성능을 깎으므로 줄이려 애썼지만, 무작정 줄이면 백프레셔로 지연이 훨씬 커져 목표 트래픽을 흘려보내며 각 루프의 대기를 모니터링해 적정 개수를 찾았다. 개수를 줄이려고 루프가 더 효율적으로 돌도록 세 가지를 적용했다. 첫째, Redis 저장을 논블로킹으로 바꿔 저장을 기다리지 않고 리액티브 RedisTemplate의 비동기 함수로 다음 작업을 처리했다. 둘째, 순서 역전 탓에 비동기로 못 하는 과거 데이터 조회에 로컬 캐시를 도입해, 매번 Redis를 읽는 대신 캐시를 먼저 읽어 블로킹 IO 횟수를 크게 줄였다. 셋째, 배치나 MySQL 조회 같은 무거운 작업은 별도 이벤트 루프 그룹으로 보내 기존 루프가 블로킹되는 것을 막았다.

그럼에도 높은 트래픽에서 처리량이 더 오르지 않으면 netstat·ss로 소켓 버퍼를 직접 확인했다. Recv-Q가 지속적으로 0보다 크면, NIO 이벤트 루프의 일을 다시 점검해 변환·객체 생성·로깅 같은 사소한 처리까지 다른 스레드에 위임하고, CPU 프로파일링으로 불필요한 스레드를 제거해 컨텍스트 스위칭을 줄이며(예: 톰캣 스레드 수 1), 마지막으로 NIO 이벤트 루프를 여러 개 써 소켓 버퍼 읽기를 병렬화했다. 리액티브 RedisTemplate을 여러 개 만들면 처리 시간을 낮게 유지하면서 처리량을 약 2배 높일 수 있었다. 이 모든 과정의 결과로 22,000 TPS에서 1ms 이하의 처리 시간을 달성했다. 2만 2천 TPS는 개발 당시 목표이자 향후 거래소 전송량 증폭을 고려한 수치이며, 발표자는 이 도전을 함께할 열정 가득한 동료를 찾는다는 말로 발표를 맺는다.