Please enable JavaScript.
Coggle requires JavaScript to display documents.
프로필 검색에 왜 ElasticSearch를 사용했나요? - Coggle Diagram
프로필 검색에 왜 ElasticSearch를 사용했나요?
최고의 검색 경험
성능
RDBMS가 제공하는 수준을 뛰어넘는 검색 성능
확장성
미래 사용자 증가에 대비한 수평적 확장성
생산성
REST API를 통한 높은 개발 생산성
빠른 검색 원리 : 역색인
기존 RDBMS 방식 : LIKE '%검색어%' 방식
테이블 전체를 스캔하기 때문에 데이터가 많아질수록 검색 속도가 현저히 느려짐
B-Tree Index
'정렬된 순서'를 기반으로 동작
앞 글자부터 일치해야 효율적
앞에 와일드카드(%)가 붙으면 정렬된 시작점을 찾을 수 없어 인덱스를 타지 못하고 결국 테이블 전체를 스캔(Full Scan)
책 맨 뒤의 '찾아보기'와 같음
검색과정
색인(Indexing)
'이름', '소개' 등의 텍스트를 작은 단위의 언어로 분리하고 분석(토큰화, 소문자 처리 등)하여 역색인에 기록
검색(Search)
사용자가 '프론트엔드 개발자' 라고 검색
'프론트엔드', '개발자' 단어가 포함된 문서 ID 목록을 역색인에서 즉시 찾아냄
해당 ID의 문서만 사용자에게 반환
수백만 건의 프로필 데이터 속에서도 거의 실시간에 가까운 빠른 검색 속도를 보장
정교한 랭킹 알고리즘(BM25)
검색어의 빈도, 문서의 길이 등을 복합적으로 계산하여 가장 관련성 높은 결과를 상단에 노출시킵니다.
형태소 분석기
'개발자'를 '개발'이라는 어근으로 분석하여 저장
사용자가 '개발'로 검색해도 '개발자'가 포함된 프로필을 찾아줌
오타보정, 동의어 처리도 가능
왜 다른 것은 안되나
Full-Text Search
기본적인 텍스트 검색은 가능, 복잡한 조건이나 형태소 분석, 동의어 처리 등 고급 검색 기능이 제한적. 정확도 정교하게 튜닝 어려움
데이터베이스 자체를 수평확장하는 것은 구조가 복잡하고 비용이 많이 듦
검색 부하가 증가하면 DB 전체에 부담
검색 로직이 데이터베이스에 종속되어 있어 유연성이 떨어짐
Apache Solr
강력한 클러스터링을 지원
초기 설정이 상대적으로 복잡
아키텍쳐 관리를 위해 주키퍼에 대한 의존성이 높음
XML기반으로 시작하여 JSON도 완벽 지원
API의 직관성이나 문서화 측면에서 아쉬움이 있음
Elasticsearch
Lucene 기반의 강력한 분석기
형태소 분석, 오타보정, 동의어 처리 등 복잡하고 정교한 검색이 가능
사용자가 원하는 프로필을 정확하고 빠르게 찾아주는 '검색품질' 측면에서 Elasticsearch가 월등
서비스 성장에 따라 데이터와 트래픽이 증가하더라도 안정적인 서비스 운영이 가능
쿼리 언어 제공
설계 단계부터 분산환경을 고려하여 손쉬운 수평 확장이 가능
노드 추가만으로 간단하게 클러스터를 확장
증가하는 데이터와 트래픽에 유연하게 대응
샤드(Shard)
샤드라는 작은 단위로 분할하여 여러 노드에 분산 저장
검색요청 - 각 노드가 자신이 가진 샤드만 병렬적으로 검색 후 결과 취합
복제본 (Replica)
각 샤드에 대한 복제본을 다른 노드에 자동으로 생성
특정 노드에 장애가 발생해도 복제본이 즉시 원본의 역할을 대신
데이터유실 없이 무중단 서비스를 보장
읽기 요청을 복제본으로 분산
부하를 줄임
솔루션 네이티브
분산 노드 관리가 매우 자동화
클러스터 구성 및 확장이 간편
노드 발견 기능이 내장되어 있어 관리가 용이
더 빠르고 간편한 스케일 아웃이 가능
인프라 관리 부담을 줄일 수 있음
JSON over REST API을 중심으로 설계
현대적인 웹 개발환경에 친화적
ELK(Elasticsearch, Logstash, Kibana) 스택
강력한 생태계와 방대한 커뮤니티를 보유
문제해결 및 정보 획득이 용이
방대한 커뮤니티 자료, 직관적인 API는 개발과정에서 발생하는 문제를 신속하게 해결, 개발속도를 높임
Kibana
강력한 시각화 도구를 통해 개발자가 코딩 없이도 데이터를 탐색하고 검색 쿼리를 테스트하며 결과를 즉시 확인
디버깅 및 분석 시간을 획기적으로 단축
객체를 JSON으로 변환하는 것은 매우 간단
유연한 스키마
스키마 없이 JSON 문서 바로 색인 가능
새로운 필드가 포함된 데이터가 들어오면 자동으로 매핑 추가
요구사항이 빠르게 변하는 애자일 환경에서 압도적인 유연성 제공
RDBS
수직확장 (Scale-up)
더 좋은 사양의 서버로 교체하는 방식
비용이 많이 들고 물리적인 한계가 명확
RDBMS도 샤딩(Sharding)을 통해 수평 확장이 가능
'애플리케이션 레벨'에서 직접 구현해야 하는 복잡한 작업
(어떤 데이터를 어느 샤드에 넣을지, 여러 샤드에 걸친 데이터를 어떻게 조회할지 등을 개발자가 직접 코드로 처리해야 함)
SQL이라는 별도의 언어 사용 필요
애플리케이션의 객체와 관계형 테이블 간의 불일치를 해결하기 위해 ORM같은 추가 계층 필요
엄격한 스키마
데이터를 저장하기 전에 ALTER TABLE 등을 통해 테이블 구조를 명확히 정의해야함
필드 하나 추가하는 것도 배포 부담이 큼