[검색서비스] 어쩌다보니 이세계 검색서비스 담당자

ElasticSearch 를 사용해본 경험이 있다는 것 하나로 어쩌다보니 검색 서비스 담당자가 되었다. 

당시에 검색 관련해서 물어볼 사람이 없었기에 구축하는 과정에서 스트레스를 정말 많이 받았었는데, 혹시라도 나같은 사람이 있다면 조금이나마 도움이 되고자 글을 작성해본다.

 

 

검색서비스 구축 순서는 보통 아래와 같이 진행한다.

1. 검색엔진 세팅 -> 2. 인덱싱 프로세스 구축 -> 3. API 개발

 

---

 

1. 검색엔진 세팅

우리의 경우 AWS OpenSearch 를 사용했는데, ElasticSearch 와 마찬가지로 인덱스 별로 settings 와 mappings 정보를 세팅해줘야 한다. 

• settings: tokenizer, analyzer 등과 관련된 정보 세팅
• mappings: 인덱스 별로 필요한 필드명, 데이터 타입, 형태소 분석이 필요한 필드의 경우에는 위 settings 에서 설정해준 analzyer 등의 정보 세팅 

[참고]

• [ElasticSearch] Settings, Mapping 설정하기
• [OpenSearch] Settings, Mapping 설정하기

 

2. 인덱싱 프로세스 구축

검색에 필요한 데이터를 말아서 검색엔진 인덱스에 넣어주는 과정을 의미한다. 보통은 정적색인, 동적색인 2가지로 구성한다. 

• 정적색인: 전체 데이터 인덱싱하는 방법
• 동적색인: 수정된 데이터만 인덱싱

 

데이터 파이프라인 구축 방법으로는 여러가지가 있는데, 내가 Version 1 에서 구현했던 방법은 아래와 같으니 참고만 바란다.

 

Version 1. AWS DMS + Athena 사용

 

정적색인은 아래와 같은 프로세스로 구축했다. 

(1) DMS 를 이용하여 RDS -> S3 에 DB 데이터가 parquet 로 떨어짐 

(2) Glue 에서 S3 에 떨어진 parquet 데이터를 크롤링하여 Athena 테이블 업데이트 

(3) Athena 쿼리 실행 

(4) Athena 쿼리 실행 결과가 S3 에 csv 로 떨어짐  

(5) Lambda 가 위 S3 이벤트를 트리거하여 OpenSearch/Elasticsearch bulk 실행

 

동적색인은 아래와 같은 프로세스로 구축했다. 

(1) 상품, 브랜드, 카테고리 등 색인이 필요한 도메인의 내부 CRUD 관련 코드에서 AWS SNS 로 메시지 publish

(2) SQS 가 위 SNS 를 구독

(3) Lambda 가 위 SQS 이벤트를 트리거하여 OpenSearch/Elasticsearch upsert 실행

 

 

Version 1 의 경우 Athena 를 사용하여 Main DB 와 분리되어 있기 때문에 DB 에 영향을 안미치고, 추후 활용도도 높을 것으로 보였으나 인덱싱 프로세스 구축부터 API 개발 및 테스트까지 모두 혼자서 해야 했기에 관리포인트가 너무 컸다.

그리고 사업 내부적으로도 개발 리소스 비용 절감이 우선순위 1순위로 오르며, 다른 방법을 빠르게 모색해야 했다.

 

따라서 Version 1 을 대체할 방법으로 몇가지 방안을 고민해봤었는데, 

 

 

1. RDS Read 클러스터를 추가하여, 데이터 정제용으로만 이용

1) AWS DMS: Main RDS 테이블 데이터가 정제용 RDS 에 그대로 복사됨

2) Lambda 스케쥴링을 이용하하여 10분마다 정제용 RDS 에 SQL SELECT Query 를 날려서 코드 상에서 데이터 정제 

3) OpenSearch/Elasticsearch 인덱싱 

▶ 장점

- SQS 트리거하는 Lambda 에서 SELECT 하는 부분이 많은데, 해당 엔드포인트를 정제용 RDS 로 바꿈으로써 connection pool 문제 완화될 것으로 예상

- ERP, 데이터마트 등의 구축에 필요한 데이터를 정제하는 것도 정제용 RDS 를 이용하면 됨

▶ 단점

- RDS -> RDS 로 바로 Upsert 하기 때문에 어떤 상품만 수정됐는지 확인 불가. 따라서 전체 상품을 full scan 해야 하기 때문에 slow query 발생 우려 -> 데이터가 많아질수록 더 느려질 것임

- 따라서 기존과 같이 SQS 이벤트를 트리거하여 OpenSearch/Elasticsearch upsert 실행하는 함수 필요

 

2. Amazon Kinesis 의 도입 

1. AWS DMS 1 (전체 로드 용도): Main RDS 테이블 데이터가 정제용 RDS 에 그대로 복사됨

2. AWS DMS 2 (지속적 복제 용도): Main RDS 테이블에서 수정이 일어난 데이터만 Amazon Kinesis 로 전송됨 

▶ 장점

- 수정된 row 만 upsert 가능하기 때문에 인덱싱이 훨씬 빠라질 것으로 예상됨 

- Lambda 에서 해당 Kinesis 이벤트를 트리거하면, 업데이트된 테이블명 및 컬럼명만도 추출 가능

- ERP, 데이터마트 등의 구축에 필요한 데이터를 정제하는 것도 정제용 RDS 를 이용하면 됨

▶ 단점 

- 사실상 SQS 대신 Kinesis 를 사용하는 것일 뿐

 

3. Amazon MSK(Kafka) 의 도입 

1. AWS DMS: Main RDS 테이블 데이터가 Amazon MSK 로 전송됨 

2) Kafka 에 대장되어 있는 함수로 데이터 정제 

3) 정제된 데이터 -> Amazon DocumentDB (MongoDB) -> OpenSearch/Elasticsearch upsert  

▶ 장점

- 다른 많은 플랫폼에서 인덱싱시 Kafka 를 사용하는 이유가 있을 것임

▶ 단점 

- Kafka 러닝 커브

 

---

 

시간이 없었기에, 결국 1번 방식을 택하여 Version 2 를 구축하게 되었다. 

 

Version 2. RDS Read 클러스터 추가 a.k.a 정제 DB

 

정적색인과 동적색인 모두 (3) 에서 사용하는 schedule 주기와 SQL 쿼리만 다를뿐 똑같은 프로세스를 이용하여 구축했다. 

(1) RDS 에 데이터 정제용 클러스터 추가

(2) DMS 를 이용하여 RDS Main DB -> RDS 데이터 정제용 DB 

(3) Lambda schedule 이벤트를 이용하여 일정시간마다 RDS 데이터 정제용 DB 에 직접 접근

(3-1) 정적색인의 경우 전체 데이터 OpenSearch bulk

(3-2) 동적색인의 경우 SQL 쿼리에서 WHERE 조건문에 updatedDate 비교 추가

 

3. API 개발  및 테스트

화면정의서 및 기획서에 맞춰서 ES 쿼리를 짜고, 해당 ES response 값을 가공해 준다. 

 

나의 경우 기획서에서 어떤 API 를 사용하고 파라미터를 어떻게 해서 호출해야 하는지, [기획서 API 매핑] PPT를 만들어서 프론트개발팀에게 공유한 후 작업을 진행했는데,

 

조금 귀찮긴 하나 이를 통해

1. API 명세를 어떻게 작성할지 대략적으로 감을 잡을 수 있었고,

2. 프론트개발팀에서도 백엔드 API가 개발 완료되기만을 기다리지 않고 해당 PPT를 토대로 먼저 작업을 시작할 수 있기 때문에,

3. 개발 시간도 훨씬 줄고 커뮤니케이션 미스도 줄일 수 있었다고 생각한다.

 

 

 

References

https://esbook.kimjmin.net/05-search