공간 쿼리를 데이터 관점으로 완전 개선하다.

취준생으로 이루어진 팀이다보니, 인프라에 돈을 최대한 아끼고자 t4g.micro로 DB를 운영하기로 결정했다. 그런데, 이 스펙에서 공간 쿼리를 수행하게 되면 CPU 집약적인 공간 쿼리 특성상 약 2~3초의 시간이 걸려 응답이 올만큼 느려졌다.

 

그래서 처음에는 공간 쿼리 자체를 최적화 하기 위해서 여러 방안을 시도했다.

 

기존에는 $nearSphere라는 공간 쿼리를 통해 주어진 사용자의 위치에서 반지름이 1~3km로 이루어진 원 이내에 포함 및 걸쳐 지나가는 러닝 코스를 조회하고 있었다. 그래서 MongoDB에서 제공하고 있는 공간 쿼리 중 나머지 2개를 통해 이를 최적화 해보고자 했다.

 

• $geoIntersects

해당 쿼리는 기준이 되는 도형이 주어지면, 그 도형을 지나는 공간 데이터를 조회해준다. 다만, 사용자 위치로부터 1~3km 내에 위치한 공간 데이터를 조회하기 위해서 '원'이 아닌 '사각형'을 이용해야 했다. 그 이유는 기본적으로 공간 데이터는 Point, LineString, Polygon을 제공하고 있기 때문에 원을 표현하려면 원을 위한 수 많은 좌표를 알아야했기 때문이다.

 

그래서 요구사항 자체를 완전 충족하지 않을 뿐만 아니라 속도도 기존 쿼리와 비슷한 응답 시간을 보여줬다.

 

• $geoWithin

해당 쿼리는 기준이 되는 도형이 주어지면, 그 도형 내에 포함되는 공간 데이터를 조회해준다. 또한, $centerSphere와 함께 사용해서 1~3km 반지름을 가지는 원을 기준 도형으로 설정할 수도 있었다. 하지만 단점은 공간 데이터가 '포함'되어야 하기 때문에 러닝 코스 좌표 중 하나라도 원 내에 포함되지 않으면 조회되지 않는다는 문제가 있었다.

 

해당 쿼리 또한 요구사항 자체를 완전 충족하지 않을 뿐만 아니라 속도도 기존 쿼리와 비슷한 응답 시간을 보여줬다.

 

이렇게 대표적으로 제공되고 있는 공간 쿼리 3개 모두 비슷한 속도를 보여줬다. 그래서 왜 이렇게 느린 속도로 조회되는지를 먼저 파악해보기로 했다. 그러면, 문제의 해결방안을 다른 관점으로 바라볼 수 있다고 생각했기 때문이다.

 

그래서 이전에 올린 MongoDB 인덱스 글과 함께 쿼리의 동작을 실행계획을 통해 분석해 결론을 냈다.

searchIntervals: [ { 
	minDistance: 0, 
	maxDistance: 3000, 
	maxInclusive: true, 
	nBuffered: 5, //후보군 
	nReturned: 1 
} ]

searchIntervals: [ { 
	minDistance: 0, 
	maxDistance: 1704.1646476730755, 
	maxInclusive: false, 
	nBuffered: 19, //후보군 
	nReturned: 11 
} ]

 

결론은 모든 공간 쿼리가 FETCH 단계에서 nBuffered에 해당하는 후보 데이터가 많을수록 쿼리의 시간이 증가하는 것을 알게되었다. 이는 코스별로 좌표 데이터가 약 1000개에서 많으면 5만 개까지 존재하기 때문에, 좌표 하나하나의 수학적 거리를 계산하는 연산량 자체가 많기 때문이었다. 즉, 데이터 자체가 병목 지점이 되고 있었다.

 

그래서 데이터를 줄이는 방법에 집중해보기로 했다. 기존에는 두 좌표 쌍을 하나씩 비교하며 100m 이내에 위치해있다면 하나의 점을 제거하여 원본 데이터보다 작은 좌표를 유지하도록 하였으나, 이렇게 하여도 제거되는 좌표는 수는 그렇게 많지 않았다. 또한, 코스의 형태를 생각하지 않고 제거하다보니 가끔 코스의 형태가 바뀌는 문제도 발생했다.

 

그래서 코스의 형태를 유지하며 좌표를 줄일 수 있는 수학적인 알고리즘으로 접근해보고자 했고, Douglas-Peucker 알고리즘을 알게되었다. 해당 알고리즘은 선분으로 구성된 곡선을 더 적은 점으로 이루어진 유사 곡선으로 축소하는 알고리즘이다. 알고리즘에 대한 자세한 내용은 여기를 참고했다.

 

해당 알고리즘 외에도 여러 알고리즘이 있지만, 러닝 코스의 정확한 형태의 데이터가 아니라 근사 데이터만 존재해도 쿼리에 문제가 없었기 때문에 해당 알고리즘을 선택했다.

 

그리고, 이를 빠르게 적용하고 임의의 10개 데이터를 뽑아 오차 범위에 따른 코스의 모양을 시각화하여 비교해보았다.

 

회색 선이 원본 데이터이지만, 잘 보이지 않는다.

 

그 결과, 오차 범위 10m가 코스의 형태를 가장 잘 유지하면서 좌표 수를 약 90% 이상 제거할 수 있었다. 그래서 이러한 변경 사항을 개발 서버에 선 적용해보았고, 요청 시 약 2.4초가 걸리던 응답 시간을 평균 200~300ms로 감소시킬 수 있었다.

기존 응답

알고리즘 적용 후

 

또한 해당 알고리즘을 적용하면서, 사용자에게 간소화된 코스를 응답으로 줄지 혹은 원본 데이터를 줄지 고민했었다. 왜냐하면, 쿼리는 근사 데이터로 가능하지만 사용자는 직접 코스를 보기에 정확한 데이터를 원할 수 있기 때문이다. 이는 팀원들의 의견을 반영하여 원본 데이터를 응답으로 주는 것으로 했다.

 

그래서 쿼리에는 단순화된 데이터를 사용하고, 응답은 원본 데이터를 내려주는 방식으로 구현했다. 이 과정에서 기존 원본 데이터까지 그대로 저장하면 데이터 크기에서 손해를 볼 수 있었기 때문에 압축률이 좋고, 속도가 빠른 Zstd 압축 알고리즘을 적용하여 원본 데이터의 크기를 줄여 저장할 수 있게 했다.

기존 데이터 크기

Zstd 압축 후 데이터 크기

 

이를 통해 압축 전 약 21.0 KB → 압축 후 약 9.6 KB, 약 54.4% 감소할 수 있었다.

 

이러한 과정을 모두 마친 후 개발 서버에서 운영 서버로 적용 범위를 확대하였고, 최종적으로 평균 응답 시간을 3.8s에서 약 82.8ms로 45.9배 개선할 수 있었다. 해당 경험을 통해 문제의 원인이 항상 눈에 보이는 곳에 있지 않다는 것과 도메인의 특성과 기술의 원리를 이해할 때 비로소 근본적인 해결책을 찾을 수 있다는 것을 배울 수 있었던 것 같다.

기존 평균 응답 시간

개선 후 평균 응답 시간