[회고] API 요청 레이턴시 줄이기

목표: 뉴스 기사에서 제목이나 본문에 특정 키워드가 포함된 기사를 빠르게 조회하고자 했습니다.

 

문제점: 기존 검색 방식의 속도가 매우 느려 검색 성능이 큰 제약으로 작용했습니다.

 

초기 접근: 성능 문제를 해결하기 위해 일단은 제목에 특정 주식 이름이 포함된 경우만 검색하도록 제한했습니다. 하지만 이 방식은 주식과 관련된 기사들을 완전히 포괄하지 못하는 한계가 있었습니다.

 

제약 사항: 프로젝트가 이미 배포된 상태였고, 실제 시연까지 남은 시간이 부족했습니다. Elasticsearch 도입이 검색 성능을 개선할 수 있는 대안으로 떠올랐지만, 새로운 기술을 도입하고 테스트하며 배포하기엔 시간과 자원이 절대적으로 부족했습니다. 이에 따라, 현재 환경과 자원에서 가능한 최적화 방안을 찾는 것이 필요했습니다.

 

해결 방법: 기존에 사용하던 Spark 기반 데이터 처리 방식을 확장하여 역인덱스를 통해 검색 속도와 기능을 개선하고자 했습니다. 이미 Spark를 통해 뉴스 기사의 단어를 추출하는 파이프라인이 있었기 때문에, 이를 활용하여 단어와 기사 ID를 매핑하는 역인덱스 테이블을 만들어 Elasticsearch의 역인덱스와 유사한 구조를 구현했습니다.

구현 방식: 뉴스 기사에서 각 단어에 해당하는 기사 ID를 Spark로 추출하여 역인덱스 테이블에 저장했습니다. 이를 통해 특정 키워드를 포함한 기사를 신속하게 조회할 수 있도록 테이블을 구성했습니다.

 

해당 방식의 문제점 : 이 방식이 가능했던 이유는 뉴스 기사가 정적 데이터로 취급될 수 있기 때문입니다. 만약 뉴스 기사 데이터가 자주 변경되는 경우, 역인덱스 테이블도 함께 갱신해야 하므로 큰 오버헤드가 발생할 가능성이 큽니다.

 

개선 방법 : 만일 서비스를 지속적으로 개발될 경우, NoSQL이나 Elasticsearch를 통한 뉴스기사 관리로 전환하는 것이 맞다고 생각합니다. NoSQL을 사용하면 대규모 뉴스 데이터를 유연하게 저장할 수 있고, 비정형 데이터 처리에도 강점을 가집니다. Elasticsearch는 빠르고 정확한 키워드 검색을 제공하며, 뉴스 기사처럼 자주 변경되지 않는 정적 데이터 검색에 최적화되어 있습니다. 이 방식은 RDB를 통한 데이터 관리보다 훨씬 효율적이며, 검색 성능과 데이터 접근성을 동시에 개선할 수 있습니다.

 

---

추가적인 소감

"우리는 왜 RDB를 쓰까?"에 대해서 많이 고민하고 생각할 수 있었습니다.

제가 생각하는 RDB의 목적은 데이터가 관계성을 가질 때, 그리고 그 데이터가 변화하거나, 트랜잭션이 많을 때 RDB를 사용해야만 한다고 생각합니다.

또한 이러한 복잡한 관계 속에서 특정 부분만 조회하기 위해서는 RDB를 사용해야만 한다고 생각합니다.

 

그렇다면 어느 상황에 Nosql를 쓰지? 라고 고민했었습니다.

Nosql은 관계가 없거나 변화가 없는 정적 데이터의 경우 사용하면 좋다고 생각합니다.

또한 수평적 확장(데이터의 숫자가 많아지는)이 잦은 경우에 사용하면 좋다고 생각합니다.

저희 서비스의 경우 뉴스 기사가 정적 데이터임에도 불구하고, 주식이라는 연관성 때문에 RDB를 사용했습니다.

하지만 만약 이 주식과 뉴스 기사 간의 적은 관계성을 끊기만 했다면 더 높은 조회속도를 가질 수 있었을 것 같습니다.

 

"데이터 간의 모든 관계성을 정의하는 것이 중요하지 않을 수 있다"는 것을 알 수 있었습니다.