🙂2024.10.17

일일 회고 27회차

Keep

1. 일일 회고를 꾸준히 하면서 성장하기 위해 노력하는 것

Problem

1. 명확한 원인을 파악하지 않고 문제를 해결하는 것

2. 여러 개의 방법 중에 최선의 방법이 아닌 빠른 방법을 선택하는 것

Try

1. 일일 회고를 통해 원인을 명확하게 파악하고 문제를 해결했는지 검토

2. 일일 회고를 통해 최선의 방법을 선택했는지 검토

오늘 할 일

• 회사 업무

  • 대량 변화 탐지시 조회 성능 측정

  • 변화탐지 모델 연동

경험 및 배움

회사 업무

대량 변화 탐지시 조회 성능 측정

20MB 크기의 Geometry 정보를 문자열로 변환하여 조회했을 때 1초 미만의 시간이 소요되는 것을 확인했다. 이는 데이터가 너무 커서 오래 걸리는 것이 아니라 쿼리에 문제가 있다는 것으로 판단됐다. 조회 쿼리의 어느 부분에서 지연이 발생하는지 분석을 진행했으며 두 Geometry 정보의 교차 영역을 계산하는 st_intersection 함수에서 지연이 발생하는 것을 발견했다.

이러한 이유는 MultiPolygon에 대량의 Polygon 정보를 모두 교차 영역 계산을 수행하고 하나의 MultiPolygon으로 다시 합치는 연산이 오래 걸리는 것으로 판단됐다. 쿼리의 성능을 올리기 위해서 st_intersection 함수의 연산 비용을 줄이는 방법을 찾고 고민해 봤다.

첫 번째 해결 방법으로 st_intersection 할 데이터의 크기를 줄이는 것을 생각해냈다. 공간 객체의 좌표를 지정한 그리드 크기로 스냅(정렬)시켜, 좌표값을 단순화하는 함수인 st_snaptogrid 를 사용하여 데이터의 크기를 줄이고 사용자가 보고 있는 특정 영역의 데이터만 조회되도록 st_intersection 하는 방법이다. 이 방법이 성능이 잘 나오고 해결 방법으로 적절한지는 검증이 필요하다.

두 번째 해결 방법으로 Geometry 컬럼에 공간 인덱스를 설정하는 것이다. 하지만 공간 인덱스를 설정하는 것으로 인해 MultiPolygon 하나의 값에 대해 st_intersection 하는 것이 개선이 될지는 모르겠다. 공간 인덱스를 설정했을 때 어떤 연산이 이루어지며 실제로 개선이 되는지를 검증해 볼 필요가 있다.

변화탐지 모델 연동

기존에는 변화탐지를 수행할 경우 API 서버에서 랜덤 데이터를 생성하여 저장하도록 구현했다. 이후 모델 서빙 서버에 모델 탑재가 되어 랜덤 데이터를 생성하던 로직을 제거하고 실제로 서빙 서버에 변화탐지 요청을 보내도록 수정했다.

수정된 서버를 테스트 서버에 배포한 후에 작은 영상 두 개를 변화탐지 했을 때 정상 동작하는 것을 확인했다. 하지만 큰 용량의 영상 두 개를 변화탐지 했을 때 AI 모델에서 OOM이 발생하는 것을 발견했다. ML 엔지니어의 의견으로는 패치로 자른 데이터를 리스트에 그대로 축적하여 메모리가 터지는 것 같다고 하셨다. 해당 문제를 ML 엔지니어가 해결한 후에 다시 테스트를 할 것이다.

앞으로 할 일

• 회사 업무

  • 대량 변화 탐지시 조회 성능 측정

    • 일반 문자열로 조회시 속도 확인

    • st_snaptogrid 방식의 해결 방법 검증

    • 공간 인덱스 검증

  • 대량 변화 탐지시 조회 성능 개선

• 사이드 프로젝트

  • 알림 기능 테스트 구현