[3차 과제] 우리 서비스가 TPS 1000이 된다 가정하고, 톰캣, 스프링 설정값 고민해 보기

[ckkim817]

어떤 구간이 병목지점이 될지 고민하기

외부 API를 호출하는 부분(지오코딩, 리버스 지오코딩)이 많고, 이는 네트워크 지연 및 외부 서비스의 처리 속도에 의존적입니다. 만약 호출 결과를 받는 데에 지연이 생기면, 서비스 내부 쓰레드는 해당 API 응답을 기다리는 동안 블로킹됩니다(동기 방식일 경우).

→ 지금은 스케줄링을 통한 배치/Preprocessing 로직으로 사전에 DB에 공간, 위치 관련 정보를 적재하는 방식으로 성능을 많이 개선하고자 했으며, 추후 WebFlux나 CompletableFuture 등을 사용하여 외부 API 호출을 비동기로 전환해 응답을 기다리는 동안 블로킹되지 않고 성능/효율을 높이고자 합니다. (현재는 OpenFeign을 사용 중인데, 동기적으로 동작하기 때문에 다른 클라이언트로 바꿀 예정)

스케일 아웃하는 서버 수 혹은 스케일 업을 어떤 스펙으로 등 어떻게 트래픽을 받아볼 수 있을지 고민하기

• 스케일 아웃
  • 서버의 수를 늘려 트래픽을 분산처리하는 방식
  • 로드 밸런싱과 함께 사용되며, 클라이언트 요청을 여러 서버로 분산하여 부하를 낮출 수 있습니다.
  • 얼마만큼의 서버를 늘릴지 측정하기 위해서는 각 서버가 처리 가능한 TPS를 측정한 후, 필요한 서버 수를 결정해야합니다.
  • 예를 들어 요구 TPS가 1000이고 한 서버가 TPS 300을 처리할 수 있다면 서버는 총 4대가 필요합니다
• 스케일 업
  • 단일 서버의 성능을 향상하여 한 서버가 더 많은 트래픽을 처리할 수 있도록 하는 방식
  • TPS 1000 기준으로 했을 때 서버가 적어도 1000개의 병렬 요청을 해야하기에 멀티코어 CPU 16 코어 이상, RAM 32GB 이상이어야 합니다.
  • 해당 방식은 단일 서버에 의존하므로 서비스 전체가 중단될 위험이 있습니다.
  • 또한 물리적 자원에 대한 한계에 도달하면 더 이상 확장이 불가하다는 특징이 있습니다.

톰캣 워커 쓰레드 수, db 커넥션 수에 대해 고민하기

우리 서비스의 TPS가 1000 정도 된다고 가정했을 때, 가장 많이 쓰이면서 가장 무거운 메인 API인 위치 기반 장소 추천 API의 호출 시간이 60ms에서 130ms 사이기 때문에, 평균 ~100ms 정도의 응답 시간을 가지고, Little’s Law에 따라 단순하게 계산했을 때 대략 동시 요청 수가 100개 정도 되리라 생각합니다.

현실적으로는 트래픽이 일정하게 분포되지 않을 수 있고, 순간 피크(Spike)가 더 높게 발생할 수 있기 때문에 (GC나 네트워크 지연 등으로 인해 일부 스레드가 잠깐씩 대기 상태가 될 가능성도 있음) 동시 요청 수의 1.5배 ~ 2배 정도인 150~200개 정도의 워커 쓰레드 수를 둔다면 적합할 것이라 생각합니다. (너무 많다면 컨텍스트 스위칭이 잦아져 CPU 오버헤드가 증가할 것, 너무 적다면 순간적인 피크 트래픽을 처리하지 못해 큐잉이 다수 발생하고 응답이 지연될 것)

API 호출마다 DB를 꼭 사용한다고 가정하면, 최대로 동시에 열릴 수 있는 DB 커넥션 수는 동시 처리 요청 수와 밀접한 관계가 있지만 (모든 스레드가 동시에 DB 작업을 하지는 않지만, 동시에 DB를 사용하는 순간이 생길 수 있음) 일반적으로 DB 커넥션 풀이 너무 크면 DB 서버 자원(메모리, CPU)도 과부하가 걸릴 수 있으므로, 워커 스레드 수 대비 1:1로 두기보다는 약간 작게 100~150개 정도를 두면 좋을 것 같습니다.

특히 우리 서비스에서 주로 사용되는 PostGIS 등 공간 연산이 포함된 쿼리를 많이 사용하면, 일반 쿼리보다 CPU/메모리를 더 많이 쓰는 경향이 있으므로 커넥션 수가 너무 많으면 오히려 쿼리 간 경쟁 때문에 성능이 떨어질 수 있기에 이 부분도 고려해야 할 것 같습니다.