[ TIL ] 최종 프로젝트_Day 19

오늘 진행한 내용들 🧐 

개인 발표 영상 문서 준비하기

1. 의사결정_전체 채용 공고 조회 API (필터링, 검색어 포함)에 Elasticsearch 적용

[ 내가 구현한 기능 ]

사용자가 조건 선택 및 검색어를 활용하여 원하는 채용 공고를 조회하는 API를 구현했습니다.

Elasticsearch를 활용하여 대량의 데이터를 빠르게 조회할 수 있도록 성능을 개선했습니다.

[ 주요 로직 ]

주요 로직은 총 세 부분으로 나눠집니다.

첫째, 지역, 경력 등과 같은 조건 및 사용자가 입력한 검색어가 없다면 전체 채용 공고를 조회합니다.

둘째, 지역, 학력, 경력, 채용 기간 등 사용자가 원하는 조건을 선택하여 채용 공고를 조회할 수 있습니다.

셋째, 사용자가 검색어를 입력하면 해당 검색어가 포함된 채용 공고 제목을 기준으로 관련 공고를 조회할 수 있습니다.

[ 배경 ]

기존에는 검색어를 이용한 채용 공고 조회 시 LIKE문을 사용했습니다.

하지만 LIKE 검색은 전체 데이터를 스캔하는 Full Table Scan 방식이기 때문에, 채용 공고 데이터가 증가할수록 조회 성능이 저하되었습니다.

또한 사용자가 지역, 학력, 경력 등 조건을 추가할수록 쿼리의 실행 시간이 길어졌습니다.

채용 공고 데이터는 지속적으로 추가되지만 사용자들은 짧은 시간 안에 원하는 정보를 얻을 수 있어야 합니다.

이런 이유로 대량의 데이터를 효율적으로 조회할 수 있도록 성능 개선이 필요했습니다.

[ 요구 사항 ]

1. 사용자가 전체 채용 공고 목록을 빠르게 조회할 수 있어야 합니다.
2. 사용자가 지역, 경력, 학력 등 다양한 조건을 추가해도 원하는 채용 공고를 빠르고 정확하게 조회할 수 있어야 합니다.
3. 검색어를 사용하여 관련된 채용 공고를 빠르게 조회할 수 있어야 합니다.

[ 선택지 ]

1. 인덱스 최적화

• 자주 조회하는 테이블 컬럼에 인덱스를 적용하여 조회 속도를 개선할 수 있습니다.
• WHERE 조건 기반의 조회 성능은 향상되지만, LIKE 검색은 인덱스를 효과적으로 활용하지 못해서 성능이 저하될 수 있습니다.
• 데이터 정합성을 유지하기 쉽습니다.

2. Elasticsearch 적용

• 역색인 구조를 사용하여 빠른 텍스트 검색이 가능합니다.
• LIKE 검색이 아닌 토큰화된 키워드 검색을 지원하여 검색 성능이 향상됩니다.
• 조건 검색 및 정렬이 빠르고 대량의 데이터를 효과적으로 처리할 수 있습니다.
• 데이터가 증가하더라도 수평 확장으로 성능을 유지할 수 있습니다.

[ 의사결정/사유 ]

최종적으로 Elasticsearch를 적용하여 조회 속도를 최적화했습니다.

[ 선택한 이유 ]

• 역색인 구조를 활용하여 LIKE 검색보다 빠르게 텍스트 검색을 수행할 수 있습니다.
• 여러 조건을 추가해도 필터링과 정렬을 효율적으로 처리할 수 있어 검색 속도를 유지할 수 있습니다.
• 샤딩과 리플리케이션를 활용하여 수평 확장이 가능하고 데이터가 증가해도 성능을 유지할 수 있습니다.
• 추후 사용자 맞춤형 검색 기능을 제공할 때 Elasticsearch 가 더 유리합니다.

인덱스를 활용한 최적화도 고려했지만 지속적으로 증가하는 채용 공고 데이터를 처리하는데 한계가 있었습니다.

인덱스가 많아질수록 쓰기 성능이 저하될 가능성이 존재했습니다.

또한 대량 데이터가 쌓이면 인덱스 크기가 증가해서 유지 관리 비용이 증가하는 문제가 발생할 수 있습니다.

[ 회고 ]

기술의 장단점

[ 장점 ]

• 역색인 구조를 활용하여 대량의 데이터에서도 검색 속도가 빠릅니다.
• 여러 조건을 조합해도 정확한 조회 및 정렬 기능을 지원합니다.
• 확장성이 뛰어나서 대량의 트래픽을 처리하기 용이합니다.

[ 단점 ]

• 추가적인 인프라가 필요해서 운영 비용이 증가합니다.
• 데이터 동기화가 필요하여 MySQL 데이터베이스와 데이터 일관성을 유지하는 로직이 필요합니다.

다시 시도한다면?

데이터 크기가 크지 않다면 인덱스 최적화로 충분할 수 있기 때문에 먼저 적용하고 성능을 검토 하고 Elasticsearch 도입을 결정 했을 것입니다.

실시간 동기화의 복잡성을 줄일 수 있는 비동기 방식을 활용하는 방법을 고려했을 것 같습니다.

 

2. 의사결정_최근 검색어 조회 API에 Redis 도입

[ 내가 구현한 기능 ]

사용자가 입력한 검색어를 저장하고, 가장 최근에 입력된 검색어를 최신순으로 최대 10개 조회하는 API를 구현했습니다.

Redis를 활용하여 검색어를 저장하고 조회 속도를 개선했습니다.

30분마다 MySQL 데이터베이스와 동기화하여 데이터 일관성을 유지하도록 개선했습니다.

[ 주요 로직 ]

주요 로직은 총 네 부분으로 나눠집니다.

첫째, 사용자가 입력한 검색어를 Redis의 ZSET 구조를 활용하여 검색어가 입력된 순서대로 정렬하여 저장합니다.

둘째, Redis에서 최신순으로 정렬된 검색어 중 최대 10개를 조회할 수 있습니다.

셋째, 30분마다 Redis의 검색어 데이터를 MySQL 데이터베이스에 동기화하여 데이터 보존을 보장합니다.

넷째, 1시간 동안 새로운 검색어가 저장되지 않으면 해당 사용자의 데이터를 Redis에서 자동으로 삭제합니다.

[ 배경 ]

기존에는 검색어를 MySQL 데이터베이스에 직접 저장하고 조회하는 방식을 사용했습니다.

하지만 사용자가 검색어를 입력할 때마다 INSERT 연산이 발생해서 데이터베이스 부하가 증가하는 문제가 있었습니다.

또한 검색어를 조회할 때마다 ORDER BY 연산이 수행되면서 성능이 저하됐습니다.

이러한 이유로 빠르게 검색어를 조회할 수 있고, 데이터베이스 부하를 줄일 수 있는 방식으로 성능 개선이 필요했습니다.

[ 요구 사항 ]

1. 사용자가 입력한 검색어를 Redis에 우선 저장해야 합니다.
2. 저장된 검색어를 최신순으로 최대 10개까지 빠르게 조회할 수 있어야 합니다.
3. 검색어 데이터는 30분마다 MySQL 데이터베이스에 동기화되어야 합니다.
4. 1시간 동안 새로운 검색어가 저장되지 않으면 해당 사용자의 데이터를 삭제해야 합니다.

[ 선택지 ]

1. 인덱스 최적화

• 최근 검색어 저장 테이블에 인덱스를 적용하여 조회 성능을 개선할 수 있습니다.
• 하지만 INSERT 연산이 많아지면, 인덱스 유지 비용이 증가해서 성능이 저하될 수 있습니다.
• 최신 검색어를 조회하면 ORDER BY 연산이 필요해서 검색량이 많아질수록 조회 성능이 저하될 수 있습니다.

2. Redis 적용

• 메모리 기반 저장소를 활용하여 빠르게 검색어를 조회할 수 있습니다.
• ZSET 구조를 사용하여 검색어를 입력 시간 기준으로 자동 정렬할 수 있습니다.
• 검색어 입력 및 조회를 Redis에서 처리하여 MySQL 데이터베이스 부하를 감소시킬 수 있습니다.
• 1시간 동안 새로운 검색어가 저장되지 않으면 해당 사용자의 데이터를 자동 삭제하여 불필요한 메모리 사용을 줄일 수 있습니다.

[ 의사결정/사유 ]

Redis를 도입하여 검색어 조회 성능을 개선하고 DB의 부하를 줄였습니다.

< 선택한 이유 >

• 메모리 기반 저장소이므로 조회 속도가 빠릅니다.
• 지원하는 ZSET 자료구조를 활용하여 자동 정렬이 가능해서 최신 검색어 조회가 효율적입니다.
• 검색어 데이터를 Redis에서 관리하여 MySQL 데이터베이스 접근을 최소화할 수 있습니다.
• 유효 시간인 1시간이 지나면 해당 사용자의 검색어 데이터를 자동 삭제하여 불필요한 메모리 사용을 방지합니다.

인덱스를 활용한 최적화도 고민했지만, 검색어 데이터는 지속적으로 INSERT가 발생하므로 인덱스를 유지하는 비용이 증가합니다.

또한 최신 검색어 조회 시 빠른 조회 속도가 핵심이기 때문에, 메모리 기반의 Redis가 더 적합하다고 판단했습니다.

[ 회고 ]

기술의 장단점

[ 장점 ]

• 메모리 기반 저장소이므로 검색어 데이터를 빠르게 조회할 수 있습니다.
• 검색어 데이터를 Redis에서 관리하여 데이터베이스 부하가 감소합니다.
• ZSET 자료구조를 활용하여 최신순으로 정렬된 상태로 데이터를 관리할 수 있습니다.

[ 단점 ]

• Redis를 운영할 수 있는 별도의 환경 설정 및 인프라 관리가 필요합니다.
• Redis와 데이터베이스 간 데이터 일관성을 유지하기 위한 동기화 로직이 필요합니다.

다시 시도한다면?

검색어 저장 빈도가 낮다면 인덱스 최적화만으로도 충분할 수 있습니다.

하지만 실시간 검색어 저장이 많고 빠른 조회가 필요하기 때문에, Redis 도입을 결정 했을 것입니다.

추가적으로 데이터 동기화의 복잡성을 줄일 수 있는 방법을 고려했을 것입니다.

 

주말 계획 ⏰

• 개인 발표 영상 준비 및 촬영
• 중간 발표 준비
• 기획서 작성

+ 추가 계획이 생길 수도 있습니다!