시스템 성능을 고려한 실시간 데이터 조회 방식(우아한 기술블로그 내용중 발췌)

우아한 기술블로그 구독중인데 보다가 좋은 내용이 있어서 가져와서 남겨둔다.

(혹시 무단 불펌이라고 생각되면 알려주세요.)

 

출처 : https://techblog.woowahan.com/19415/

 

👉🏻 시스템 성능을 고려한 실시간 데이터 조회 방식

업무 현황 보드에서 실시간 조회는 시스템 성능에 심각한 부하를 줄 수 있으므로 최적화된 접근 방식이 필요합니다.

데이터베이스 조회가 오래 걸릴 수 있는 데이터를 안정적으로 전달하기 위한 주요 방식으로 캐시(Cache), 배치(Batch), 스케줄러(Scheduler)를 고려하게 되었는데요. 각 방식의 특징을 비교해보겠습니다.

 

📍 1) Cache
캐시 방식은 데이터 조회 시 반복적으로 발생하는 동일한 요청에 대해 빠르게 응답하기 위해 사용됩니다.
데이터를 처음 조회한 후, 이를 인메모리 DB에 저장하고, 이후에는 인메모리 DB에 저장된 데이터를 활용하여 데이터베이스 조회 부담을 줄일 수 있습니다. 하지만 캐시 방식은 다음과 같은 단점이 있습니다.

 

출처 : https://javascript.plainenglish.io/thundering-herd-problem-solution-with-node-js-and-promise-e8bc55dc5105

 

첫 번째, 초기 조회 성능 문제입니다.
데이터베이스에서 처음 데이터를 가져와 메모리에 저장하기 전까지는 실제 데이터베이스 조회가 필요하므로, 첫 조회는 시간이 오래 걸릴 수 있습니다.
이 시점에 여러 개의 요청이 동시에 들어올 경우, 데이터베이스에 과도한 부하가 걸릴 수 있습니다. 예를 들어, 초기 데이터 조회 시 10개의 동시 요청이 발생하면 데이터베이스에 10번의 조회 요청이 들어가게 되는데(Cache Stampede) 이는 성능 저하를 초래할 수 있습니다.
물론 이러한 문제를 해결하기 위해 분산 락(Distributed Lock) 메커니즘을 활용할 수 있지만 구현 복잡성 증가, 운영 및 유지 보수 부담 등의 새로운 문제를 야기할 수 있습니다.

 

두 번째, 저장 데이터의 크기 문제입니다.
캐시로 저장해야 할 업무 현황과 관련한 데이터가 10MB가 넘는다는 점입니다. 메모리 사용량이 급격히 증가하여 전체 시스템 성능에 부정적인 영향을 미칠 수 있습니다.
특히 RDB의 인덱스를 활용할 수 없고 캐시에 저장된 데이터를 애플리케이션에서 매번 필터링해야 한다는 점에서 큰 비효율성이 발생합니다.

 

📍 2) Batch

배치 방식은 주기적으로 데이터를 조회 및 처리하여 별도의 통계 테이블에 저장한 후, 업무 현황 조회 시 통계 테이블에서 데이터를 가져오는 방식입니다.
데이터베이스에 실시간 부하를 최소화하는 방식으로서 유용합니다. 특히, RDB의 인덱스를 활용할 수 있는 점에서 대용량 데이터의 효율적인 조회가 가능하다는 장점이 있습니다.
통계 테이블의 데이터가 정기적으로 업데이트되고 빠르게 필터링 된 데이터를 조회할 수 있어 성능이 뛰어납니다.

하지만 배치 방식은 추가적인 오버헤드가 발생하는 문제가 있습니다. 현재 팀의 배치 수행 방식은 애플리케이션을 독립적으로 실행하는 방식입니다. 배치 작업을 실행하기 위해 애플리케이션 컨텍스트를 로드하고 서버를 시작하는 과정에서 추가적인 오버헤드가 발생합니다.

이러한 초기화 작업은 시간이 수 분 단위로 소요되기 때문에 처리 속도가 느려지게 됩니다. 따라서 적재된 통계 데이터는 실시간성이 떨어지게 됩니다.

 

📍 3) Scheduler
스케줄러 방식은 배치 방식과 비슷하게 일정한 주기로 데이터를 처리하고 저장하는 방법이지만, 더 자주 실행되어 실시간에 가까운 데이터를 제공할 수 있습니다.

통계 데이터를 별도의 테이블에 저장하기 때문에, 데이터베이스에 실시간으로 부하를 주지 않으면서도 비교적 실시간에 준하는 데이터를 제공할 수 있습니다. 이는 캐시의 속도와 배치의 대규모 데이터 처리의 이점을 모두 결합한 방식이라 생각합니다.

 

스케줄러 방식의 가장 큰 장점은 부하를 효율적으로 분산할 수 있다는 점입니다. 현재 저희 팀은 API 서버와 스케줄러 작업을 처리하는 워커 서버를 분리하여 운영하고 있어, 스케줄러 방식을 활용하기에 최적의 환경을 갖추고 있습니다.

이 구조를 통해 통계 데이터 갱신 작업을 워커 서버가 전담 처리하므로, 스케줄러 작업 주기를 유동적으로 조절하더라도 API 서버의 성능에 직접적인 영향을 주지 않아, 비즈니스 상황에 맞게 주기를 유연하게 조정할 수 있습니다.

캐시 방식은 빠른 응답 속도와 효율적인 메모리 활용이 장점이지만, 첫 조회 시 발생하는 성능 저하와 대용량 데이터 처리에서의 한계가 있습니다.

 

배치 방식은 대규모 데이터 처리에 효과적이지만 준실시간성을 보장하지 못합니다.
스케줄러 방식은 준실시간성과 시스템 부하 간의 균형을 유지하며 유연한 처리가 가능합니다.

따라서 업무 현황 보드와 같은 준실시간 데이터 조회가 필요한 시스템에서는 시스템 성능 저하를 최소화하고, 대용량 데이터를 효율적으로 처리할 수 있는 스케줄러 방식이 가장 적합하다고 생각하여 채택하였습니다.