[Web] ElasticSearch 적용 방안 탐색

📍 ElasticSearch 기본 개념 요약

우선 이번 프로젝트를 진행하면서 적용한 ElasticSearch에 대해 정리해보고자 한다.

내가 ElasticSearch를 공부하며 중요하게 작용한 부분들만 추려서 적어본다.

 

💡 ELK

ElasticSearch에 대해 공부를 하다보면 ELK Stack이라는 말을 많이 볼 수 있다.

 

ELK는 ElasticSearch, Logstash, Kibana의 줄임말인데

데이터 로그들이 Logstash를 거쳐 ElasticSearch에 저장되고, 이를 시각화하여 Kibana에서 볼 수 있다는 내용이다.

• Logstash  |  다양한 데이터 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 ElasticSearch로 전달
• ElasitcSearch  |  Logstash로부터 받은 데이터를 저장하고, 검색 및 집계하여 필요한 정보를 획득
• Kibana  |  ElasticSearch의 동작을 시각화 및 모니터링

 

💡 ElasticSerach 데이터 저장

ElasitcSearch를 처음 접하는 분들이라면 데이터를 어디에 저장하는건지 의문이 들 수 있는데,

ElasticSearch만의 데이터 저장소가 있고, 또 그들만의 데이터 저장 형태가 정해져있다.

 

흔히 사용되는 RDB와 비교하자면

Database는 Index, Table은 Type, column은 Field, row는 Document로 각각 매핑된다.

https://steemit.com/elasticsearch/@secmon/elasticsearch

 

그리고 RDB와 성능적인 측면에서도 비교되는 부분이 있는데,

데이터에 대한 삽입, 수정, 삭제에 대해서는 RDB가 성능이 우월하며

하나의 텀(혹은 단어)를 포함하는 문서를 찾도록 해주는 기능에 있어서는 ElasticSearch가 좋은 성능을 보인다.

 

💡 역색인

ElasticSearch가 전체 문서를 하나씩 비교하지 않아도 금방 하나의 단어를 찾을 수 있는 비결이 바로 역색인이다.

저장 데이터를 어떠한 분석기(선택 가능)를 사용하여 분석하고, index에 저장한다.

 

ElasticSearch의 기본 분석기는 WhiteSpace를 기준으로 데이터를 분석하는데,

예를 들어 '동해물과 백두산이'라는 단어가 있다면 '동해물과'와 '백두산이'로 쪼개어 저장하는 것이다.

 

---

📍 Elastic Search 적용 방안 탐색

위의 개념을 가지고 우리 프로젝트에 적용할 방안을 탐색했던 과정을 서술한다.

 

💡 ELK가 필요한가?

내가 진행중인 프로젝트에서는 전통주의 이름에 대한 정보를 Index로 저장하고,

전통주 검색 시 키워드로 검색할 수 있는 기능을 제공하고자 ElasticSearch 도입을 결정했다.

 

처음에는 ElasticSearch를 공부하며 ELK를 사용하는 것이 당연한 수순같이 느껴져서

Logstash를 이용하여 주기적으로 MySQL의 전통주 테이블을 확인하여 싱크를 맞춰주는 작업을 진행했다.

(input 쿼리를 작성하고 cron 표현식을 사용하여 Logstash 작성)

 

그러나 생각해보니 여러 이유로 Logstash 사용이 무의미함을 깨달았다.

전통주의 이름 데이터의 경우에는 변동이 거의 없으므로

MySQL을 주기적으로 확인하여 싱크를 맞춰주는 작업이 비효율적일 것이며,

변동이 있다고 해도 하나씩 새로운 데이터를 삽입해주는 과정이 RDB에 비해

성능상의 이점이 없기 때문에 굳이 Logstash를 이용할 이유가 없었다.

 

추가적으로, 두 가지 포스팅을 참고하여 ELK를 사용하지 않기로 확정했다.

1️⃣ '시작하세요! 엘라스틱서치'를 집필하신 김종민님의 글

엘라스틱서치 사용법 - Jongmin's Lifelog (kimjmin.net)

엘라스틱서치 사용법 - Jongmin's Lifelog

 

위 글에서는 현업의 ElasticSearch 활용 방안에 대한 내용이 적혀있는데, 요약하자면 아래와 같다.

혹시 모를 데이터 유실 등에 대비하여 원본 데이터를 Logstash에 입력 가능한 JSON 형식으로 저장하고,
S3에 압축하여 보관하는 것을 권장함

김종민님의 경우, 매일 10GB정도 되는 데이터를 JSON으로 변환하고,
Logstash로 입력한 다음 변환 파일은 tar.gz로 압축하여 S3 버킷에 매일 날짜별로 백업하는 식으로 운영
👉 텍스트 파일이기 때문에 압축 시 1/100 정도로 줄어들며, S3는 사용료가 저렴하여 백업하기 좋음

운영하는 서비스에 따라 다르지만,
ES에 저장되는 데이터는 변형이나 가공을 되도록 지양하고 무결성에 대한 기대도 하지 않으며
순수하게 검색과 통계를 위해서 사용하는 것을 추천함
(데이터를 무결하게 유지하고자 지나치게 자주 Logstash를 이용해 RDB를 검사하게 되면
성능에 안좋은 영향을 미칠 수 있음)

 

위의 내용으로 보았을 때, 불필요하게 MySQL을 검사하는 것은 성능상 좋지 못하며

ElasticSearch에 저장하는 데이터는 주기적으로 '한 번에' 넣고 빼는 것이 권장된다고 보여졌다.

(특히 데이터 변동이 거의 없는 전통주 이름 데이터의 경우에는 더더욱!)

 

2️⃣ 배달의 민족 테크 블로그의 ElasticSearch 활용 포스팅

검색을 위한 데이터 다루기 | 우아한형제들 기술블로그 (woowahan.com)

검색을 위한 데이터 다루기 | 우아한형제들 기술블로그

 

위의 글에서는 건바이건으로 ElasticSearch의 데이터를 update 하는 것보다,

한 번에 모든 데이터를 update 해주는 것이 효율적임을 다루는 내용이 있다.

요약하자면 아래와 같다.

초기 시스템 설계 시 들어오는 데이터의 양이 그렇게 많지 않았고,
예측이 가능했기 때문에 개별적으로 들어오는 이벤트를 건바이건으로 update request를 만들어 반영함

👉 가게가 증가함에 따라 오픈하는 시간대나 주문이 많아 메뉴 품절 등의 상황이 많이 발생하는 경우
이벤트를 많이 수신하게 되었고, 그에 따라 ElasticSearch에 대한 부담이 집중되면서
request가 reject되는 문제 등이 기하급수적으로 상승함

문제의 원인으로, 잦은 변경에 의한 Dish I/O 문제 건바이건 요청으로 인한 thread pool 초과 이슈 발견

💡 정답은 언제나 기본에 있다.
MySQL Doc을 보면 아래와 같은 말이 있음
"insert 성능을 높이기 위해서는 작은 여러 개의 연산을 하나의 큰 연산으로 만들어라."
ElasticSearch또한 같은 개념을 갖고 있고,
단건 request보다 Bulk request의 효능이 큰 것은 입증된 사실임

 

위의 내용을 보고 건바이건 요청보다 한 번에 데이터를 변경해주는 것이 더 효율적일 것을 확신했고,

ElasticSearch의 Bulk API를 사용할 것을 결정했다.

 

---

결론

오늘 정리한 ElasticSearch의 개념과 적용 방안 탐색 과정을 기반으로,

우리는 ELK 대신 Bulk API를 활용하여 데이터를 저장하는 방식을 채택했다.

다음 글에서는 적용한 방법을 정리해보겠다.

 

2023.04.02 - [🟢[ Web ]/기타] - [Web] ElasticSearch nori & Bulk API 활용