분류 전체보기

해시태그 검색어 자동완성 기능 개발기 3 - 캐싱

(이전 포스팅에서 이어집니다.)해시태그 검색어 자동완성 기능 개발기 1 - DB 조회해시태그 검색어 자동완성 기능 개발기 2 - 인덱스  들어가면서 앞선 포스팅에서 해시태그 레코드 개수 자체가 150만 건까지 늘어나는 경우에도 목표 성능을 유지할 수 있도록 커버링 인덱스와 dto 프로젝션을 적용했습니다. 하지만 잠재적인 문제점은 여전히 남아있었습니다.  커버링 인덱스를 사용한다고 하더라도, count 컬럼에 따른 filesort 작업을 매 쿼리마다 수행해야 한다는 점입니다.현재는 해시태그 데이터들을 무작위 문자열로 생성해서 넣어둔 상태라서, 특정 문자열을 prefix로 가지는 레코드 개수에 쏠림 현상이 발생하지 않습니다.예를 들어, 매우 극단적인 경우 's'로 시작하는 해시태그만 100만개가 존재할 수 ..

해시태그 검색어 자동완성 기능 개발기 2 - 인덱스

(이전 포스팅에서 이어집니다.)해시태그 검색어 자동완성 기능 개발기 1 - DB 조회  들어가면서 앞선 포스팅에서 해시태그 검색어 자동완성 및 추천 기능을 가장 간단하게 DB에서 필터링하는 방법으로 구현하고 성능 개선을 진행했었습니다. 하지만 예측되는 문제점들 중 아직 해결하지 못한 것들이 남아있었는데요, 내용은 다음과 같았습니다. 해시태그 레코드 개수 자체가 늘어나는 경우에 대한 성능 측정이 이뤄지지 않았습니다.현재는 모각코 일정에 매핑되는 해시태그 개수가 많이 늘어날 때 발생하는 성능 문제를 개선한 것이지, 해시태그 레코드 개수 자체가 늘어나는 경우에는 다른 성능 이슈가 발생할 가능성이 농후합니다.이번 포스팅에서는 해시코드 레코드 개수 자체가 늘어나도 문제가 없도록 API를 개선해보고자 합니다.  ..

해시태그 검색어 자동완성 기능 개발기 1 - DB 조회

들어가면서 최근 진행하고 있던 모각코 스케쥴러 사이드 프로젝트에서 검색어 자동완성 기능이 필요하여 개발하게 되었습니다. 모각코 일정을 생성하는 사용자는 해당 모각코에 모인 사람들이 어떤 기술 스택을 사용하는지, 어떤 키워드의 영역을 주로 다루는 사람들인지 간편하게 표시할 수 있도록 하기 위해 해시태그를 설정할 수 있습니다.   이 때 사용자는 해시태그를 직접 입력하게 되는데, 입력하는 문자열에 따라 기존에 생성되어 있던 해시태그를 추천받아 선택해서 사용할 수 있어야 합니다. 우선은 입력받은 문자열을 기반으로 DB 단에서 직접 필터링하여 조회해오는 가장 간단한 방식으로 구현한 뒤, 예상되는 문제점에 맞춰서 개선해보려고 합니다.   요구사항 정리 및 설계 해시태그 검색어 자동완성 및 추천 기능에 대한 요구사..

[JAVA] Comparator

Comparator는 기본적으로 하나의 추상 메서드만을 가지는 함수형 인터페이스입니다. 그래서 사용을 위해 다음 이미지와 같이 선언되어있는 추상 메서드인 int compare(T o1, T o2)를 구현하면 됩니다. Comparator 인터페이스의 구현 내부를 살펴보면 compare 추상 메서드 외에도 다른 메서드들이 많이 선언되어 있는 것을 확인할 수 있습니다. 처음 해당 메서드들을 접했을 때는 메서드가 이렇게 많이 선언되어 있는데 왜 FunctionalInterface로 선언될 수 있는 건지 궁금했는데요. 기본적으로 Java에서 모든 클래스와 인터페이스는 Object 클래스에 선언되어 있는 메서드들을 상속받습니다. 또한 default 메서드 혹은 정적 메소드 같은 경우는 FunctionalInterf..

[Grafana Loki] 다중 서버 환경에서 그라파나 로키를 이용해 로깅하기

들어가면서 현재 진행중인 프로젝트에서 구성했던 서버를 Scale Out 하게 되었습니다. 여기에는 여러가지 배경이 있었는데요, 가장 큰 이유는 앞으로 있을 크고 작은 업데이트를 적용할 때 무중단 배포를 수행하기 위해 블루/그린 배포 전략을 적용하기 위한 서버 이중화가 필요했었다는 것입니다. 그에 따라 배포 시에는 블루/그린 서버로 사용되지만 평소에는 nginx 로드 밸런싱 기능을 활용하여 트래픽을 분산처리할 수 있도록 하여 리소스를 최대한 효율적으로 사용하고자 했습니다. 그런데 문제가 하나 있었습니다. 기존에는 단일 서버 환경에서 수행하던 로깅 데이터 모니터링이 정상적으로 동작하지 않는 문제였는데요. 그 원인은 서버가 이중화 되면서 한 곳에 저장되던 로깅 데이터가 각 서버에 나뉘어져 저장되기 시작했다는 ..

[최적화] Tomcat 스레드 풀 튜닝에 대한 고찰

들어가면서 서비스 API 서버를 구축하고 운영하면서 Tomcat 스레드 풀과 관련된 설정값들을 어떻게 튜닝할 수 있을지 생각해볼 기회가 생겼습니다. 막연하게 최적의 설정값을 찾으면 성능이 좋아지겠다고 생각은 했지만 왜 튜닝을 해야하는지, 어떻게 진행해야 하는지 감이 잘 잡히지 않았었습니다. 그래서 나름대로 백엔드 서버에서 Tomcat 스레드 풀 관련 설정값들을 왜 튜닝해야 하는지, 어떻게 튜닝할 수 있는지를 고민해보고 정리해봤습니다. 스레드 풀의 크기를 적절하게 조절해야 하는 이유 스레드를 생성하는 것은 비용이 많이 드는 작업입니다. 새로운 스레드를 위한 메모리 공간을 할당하는데 이 메모리 공간은 JVM이 할당받은 메모리 공간을 점유하게 됩니다. 이 때 기본적으로 1MB의 메모리 영역만큼을 하나의 스레드..

[DB] 인덱스 기본 개념과 클러스터링, 논클러스터링 인덱스

들어가면서 프로젝트의 기본적인 성능 최적화를 위해 사용중인 데이터베이스에 인덱스를 적용해야 할 일이 생겼습니다. 그 전에 인덱스의 간단한 기본 개념과 클러스터링, 논클러스터링 인덱스에 대해 정리해보려합니다. 인덱스 기본 개념 및 용어 정리 인덱스란 데이터베이스에서 원하는 값을 빠르게 찾기 위해 사용하는 자료구조입니다. 인덱스를 이용하면 데이터베이스 테이블에 대한 검색 성능을 향상시킬 수 있으며, where 절 등을 통해 활용됩니다. 인덱스의 특징 인덱스는 항상 최신의 정렬상태를 유지합니다. 인덱스도 하나의 데이터베이스 객체입니다. 데이터베이스 크기의 약 10% 정도의 저장 공간을 필요로 합니다. 자주 사용되는 용어 정리 페이지 : 데이터가 저장되는 단위 (MySQL 에서는 16KB) Full Table ..

[우아한테크코스] LV3 - 4차 스프린트 회고

들어가면서 4차 스프린트는 하루스터디 서비스 사용자들이 그동안 진행했던 스터디 기록을 모아볼 수 있는 기능을 제공하기 위한 로그인 기능을 구현하는데 집중했던 기간이었다. 과거에 진행했던 스터디 기록을 다시 조회할 수 없다는 것이 서비스 사용자들에게 가장 큰 불편함으로 다가올 것이라고 판단해서 최우선적으로 구현을 하기로 결정했다. 이와 별개로 운영중인 서비스에서 발생하는 로그들을 전혀 확인할 수 없는 문제가 있었는데 이를 해결하기 위해 로깅 시스템을 구축했어야 했다. 무엇 하나 쉽지 않았던 굵직했던 주제들이라 데드라인을 맞추기 위해 팀 내에서도 분업을 해서 정신없이 진행했었다. 이번 회고에서는 바쁘게 진행했던 작업들을 되짚어보면서 그 과정들을 기록해놓고자 한다. 4차 스프린트 Oauth2.0을 이용한 로그..