왜 ElasticSearch를 도입하려고 하시나요.review

사내 유일한 소프트웨어 개발자로서 스스로에게 던지는 질문이다. 기술의 선택은 향후 많은 것에 영향을 미칠수있다. 기술적인 부분은 물론 추후 인력수급의 문제까지. ElasticSearch 도입을 하기까지의 과정과 1년이 지난 지금의 생각들을 정리해본다.

ElasticSearch 와의 첫만남🔗

과거 공공기관에 파견되어 유지보수 프로젝트를 하던 당시에 운영되던 설치형 웹로그 분석툴이 있었다. 인수인계를 받을 때 뭐이런 것이 있다는 식으로 전달받았지만, 여러가지 통계를 분석할 때 사용해야 할 일이 많았다.

정확한 집계를 내어주지 않는데다, 느리기까지 했다. 초기 프로젝트 도입시 세팅된 채로 변화에 대응이 되어있지 않았던 것이다.

HTTP 오류코드가 주로 어디에서 많이 기록되는지, 페이지별 응답속도는 어떻게 되는지 의심스러운 방문자 IP 확인같은 작업을 grep, awk, sort, uniq 조합 말고 전문적인 툴의 도움을 받아 자세히 알아보고 개선시키고 싶었다. 그때 검색을 통해 알게된 것이 ElasticSearch였다.

그런것이 있다고 알았지만 정식으로 바로 도입하지는 못했다. 당시 도입이 만만치 않았던 것이 내가 컨트롤할 수 있는 것은 매일매일 쌓이는 log.txt 파일이었는데, 알아보니 ElasticSearch는 엔진일 뿐이고, 여기에 LogStash나 FileBeat를 추가해 log.txt 같은 분석대상 소스를 Feed해주고, Kibana 까지 있어야 실제로 화면으로 분석 같은 것을 할 수 있는 것이었다.

어찌어찌 Docker에 Kibana를 띄워보니 반갑게도 GUI로 log.txt파일을 업로드해서 분석할 수 있었고, 정말 미려한 UI/UX로 분석결과를 보여주는 kibana는 신세계였다… 하지만 혼자 운영업무를 하는데 쌓여있는 개발이슈만으로도 벅찬 상황이라 제대로 도입하지 못하고 꾸역꾸역 기존 시스템을 활용하며 그렇게 마음에 담아두었다.

ElasticSearch를 다시 떠올리게 된 시점🔗

현재 회사로 이직을 한 후에 EV사용자용 EV충전소 모바일앱을 출시해야 하는 상황이었다. 모든 것이 제로인 상황에서 어떻게 설계하고 어떤 스택을 꾸려야 할 지 결정할 것이 많았다.

EV이용자들은 자주가는 충전소나 루틴이 어느정도 정해져있다고 판단했다. 메인컨셉은 지도화면을 먼저 보여줄것이 아니라, 자주가는충전소가 현재 이용가능한지 아닌지를 가장 빠르게 보여줄 수 있는 앱이었다.

충전소의 실시간 상태여부를 공급해주는 백엔드 스택을 고려하며 아래와 같은 스택을 구성하기로 했다.

• RDB: MariaDB 10+
• > 검색엔진 및 대시보드 : ELK Stack
• API서버: Node.js (Express.js)
• 인프라: Naver Public Cloud, Cloud Functions, Docker

나는 조금 이른 시점이지만 여기서 ElasticSearch를 떠올렸는데, 당시 이유는 몇가지가 있었다.

ElasticSearch도입의 긍정적영향🔗

• RDB와의 역할분리

  매 분 Cloud Function에서 외부 API를 찌르고 충전소 데이터와 충전상태 데이터를 잔뜩 불러온다. 그리곤 1차적으로 MariaDB에 쓰도록 설계했다.

  충전중인지 아닌지 등의 상태를 굳이 과거 정보까지 보관해야 해야 할까 싶었지만 나중에 데이터분석가를 모셨을때 지금 당장 Raw데이터를 내놓으시죠! 하실때 짠! 여기있습니다. 할 수 있어야 한다고 생각했다.

  어쨋든, 매분 쓰기 작업을 무한히 하고 있는 DB에 실시간 쿼리를 위해 랜덤 읽기부하를 추가하는 것 보다, 읽기 및 검색을 위한 역할의 분리가 필요하다고 생각했다.

  이것을 위해서 Redis같은 캐시를 사용하거나, 읽기전용 복제본을 활용할 수도 있을 것이다. 근데 아래의 몇가지 이유가 더 있었다.

• 데이터시각화 및 대시보드 (Kibana)

  충전소 데이터를 개발자 부탁없이 자율적으로 확인할 수 있어야한다고 생각했다. 그렇다면 내가 백오피스를 만들어서 주요지표를 보여주는 웹을 또 코딩해야하나? 그냥 Kibana를 활용하는 것이 최선이라고 생각했다. 그러러면 ElasticSearch가 필요하다.

• 실시간 집계

  오늘 가장 이용량이 많은 충전소가 어디인지, 1달은 어떤지, 변화량이 급증한 곳은 어디인지 이렇게 궁금한 것들이 많이 생기는데 이런 실시간 집계를 뚝딱뚝딱 해내는 것도 ElasticSearch였다.

• 장기적 관점: 강력한 검색엔진 기능

  이건 나중 이야기겠지만, 충전소 검색창에

  • 동이름, 충전소 이름
  • 사용자가 입력한 meta정보
  • 개떡같이 입력된 데이터

  무엇을 쳐도 위치에 기반해 내가 원하는 충전소를 턱 내주는 구글창을 꿈꿨다. 그러려면 의미파악을 위한 형태소 분석도 해야하고, 집계도 잘해야하고, FullText 검색도 잘 해야한다. 이미 이런부분에서 ElasticSearch는 잘 구현되어 있으므로 장기적으로 변화에 잘 대응할 것이라고 생각했다.

ElasticSearch도입의 망설임요인🔗

• 복잡성 증가

  MariaDB로는 위 사항을 구현하지 못할까? DB복제로 역할을 분리하고, MariaDB에서도 위치기반 검색을 할 수 있고, 쿼리를 최적화하고, 인덱스를 잘 활용한다면 현재 요구사항을 만족시킬 수 있었다. 물론, 데이터 공유는 숙제로 남는다.

• 동기화 비용

  MariaDB에서 ElasticSearch로 최신데이터를 동기화 해야한다. 필연적으로 최신데이터와의 일시적인 불일치가 생긴다. 또 소스데이터의 변화가 생겼을때의 대응이나 동기화를 수행하기 위한 관리비용이 추가된다.

• 경험없음

  내가 과연 이것을 유지할 수 있을까? 하는 고민이 컸다. 일단 ELK를 자세히 경험한 적이 없었고 도와줄 수 있는 사람도 없었다. 업무 외시간이라 하더라도 내가 공부하는 시간과 체력도 스타트업에서는 비용이라고 생각했다.

우리는 결국 ELK를 도입하게 되었다.🔗

기술을 논의하고 실행할 수 있는 사람이 나혼자인 상황에서는 셀프 주장과 셀프 반박을 해서 최선의 결정을 해야한다. 이 과정은 정말 외롭고 불안하다. 좋은 동료의 필요성을 간절히 느꼈다.

어느 한쪽을 선택하기 위해 반대의 모든 부분을 반박하고 순전히 이것을 사용해야만 하는 이유로 몰아가는 것은 도리어 부자연스럽다고 생각한다. 아래 내용은 반대의 경우로 충분히 반박할 여지가 있다고 생각하지만 최종적으로 결정하게된 몇가지 이유를 소개하는 정도로 봐주시면 좋을 것 같다.

• 데이터공유 및 분석

  필연적으로 ELK가 필요하다고 느꼈던 부분은 모든 팀원의 자유로운 데이터분석 및 공유부분이다. 과거의 경험때문인지 이 부분이 핵심 기술스택을 고려할만큼 정말 중요하다고 생각했다.

• 동기화 비용의 Trade-off 수십분 ~ 수시간이 걸리는 충전사이클에서 동기화과정의 데이터 불일치는 무시할 수 있는 수준이라고 생각했다. 그리고 이것으로 치환되는 전체 시스템 안정성이 더 큰 이점이라고 생각했다.

• 이미 많은 사용사례와 잘 작성된 문서

  우리가 ELK로 아주 특별한 작업을 하려는 것이 아니었다. 첫번재 사용범위는 일반적인 사용사례중 하나라고 생각했다.

도입 그 이후 회고: 정말 ELK는 필요했었나?🔗

반반이라고 대답한다면 실패한걸까? 1년 정도 운영한 시점에서 돌이켜보았다.

좋았던 점🔗

• 예상대로 Kibana의 시각화 도구는 강력했다. 확인하고자 했던 거의 모든 형태의 정보를 실시간으로 확인할 수 있었고 10만기 이상의 충전 Raw데이터를 1년 구간의 데이터를 동시에 불러와도 실시간으로 그래프를 만들어내고 집계한다. 어마어마하다.

• 설계대로 충전기 상태를 1분 정도의 실시간으로 제공할 수 있었다. 당시 카카오맵에서 제공하는 정보나 다른 비슷한 서비스들은 3~5분 정도의 텀을 두고 정보를 내어주고 있었다. 그리고 임의의 충전소에서 누군가 충전기를 꽂을때 시스템에서 설계대로 그 변화를 잡아 냈을 때, 그것을 관찰했을 때 쾌감이 짜릿했다.

• 기본쿼리 능력이 정말 뛰어났다. 충전기 집계, 텍스트 검색, Geo 등 여러 정보를 선별 혼합해 결과를 스코어로 랭크해주는 것이 여러번의 쿼리과정없이 한방에 쉽게 쿼리할 수 있었다.

• LogStash로 전처리 후처리 기능이 강력했다. MariaDB에서 데이터를 당겨올 때 다른 서비스 레이어를 거치지 않고 원하는 형태로 가공해서 바로 Elastic으로 전달이 가능했다. 이를 통해 [점] 이벤트로 이루어진 로그성 기록을 충전[시작과 끝]의 선이벤트로 구분하는 과정을 데이터를 불러옴과 동시에 처리 할 수 있었다.

아쉬웠던 점🔗

• 사실상 RDB 테이블과 ES의 테이블(인덱스) 두개의 스키마가 점점 분리되기 시작했다. LogStash가 전처리를 너무 잘해주다보니, MariaDB에는 없는 컬럼들이 우후죽순 늘어났고 뭔지는 모르겠지만 점점 불안했다.

• 또 중간에 ES의 인덱스에서 특정컬럼의 타입변경이 일어날 경우 기존 데이터를 Re-Indexing 해주어야하고, 이런 생소한 과정이 발목을 턱턱잡아 생산성을 느리게 만들었다.

• 데이터조작 및 질의가 불편했다. 어느정도 예상했지만 꽤 공수가 컸다. SQL기반이 아니라 JSON 기반의 QueryDSL을 작성하고 API호출을 해야하는데 이 QueryDSL작성에 오버헤드가 많았다. SQL 이라면 SELECT 로 금방 조회할 수 있는 내용도 JSON으로 길게 작성해서 API에 실어보내야 한다. 익숙함의 문제인 것 같다.

• 사실 Elastic은 클러스터 구성으로 높은 안정성을 확보할 수 있는데, 그런 설정들을 제대로 활용하지 못했다.

• 다른 팀원들에게도 Kibana 자체의 러닝커브가 높았다.

결론🔗

개발자 규모가 많을 때와 적을 때의 기술 결정에 요인이 많이 달라질 수 있음을 느꼈다. 회사에서 1인 혹은 소수 개발자라면 누군가와 상의할 수 없는 어려움을 극복하면서도, 결정한 기술이 회사에 어떤 영향을 미칠지를 예측하고 준비하는 것이 중요하다.

관리형 Elastic 서비스가 많이 나와있는 것으로 알고있다. 영세한 팀의 입장에서 사용비용이 만만치 않아 도입하지 못했는데, 지금와서 다시 생각해보면 ElasticSearch 기술이 꼭 필요하다면 관리형 서비스는 좋은 옵션인 것 같다. 서비스 자체에 좀 더 집중할 수 있게 하는힘이 소규모 팀에는 필요하고 거기서 발생하는 관리비용은 둘째문제로 느껴졌다. 사실 사람 한명 더 쓸 비용을 관리형 서비스로 저렴하게 활용할 수도 있는것인데, 그렇게 생각하지는 못했다.

회사가 성장해서 좋은 개발자분들을 소위 모셔와서 함께하고 싶다는 생각이 정말 많이드는 요즘이다. 나의 경험을 한번 정리해보았는데, 혹시나 비슷한 상황을 겪고 계시거나 읽고 공감하고 계신분들께 유용한 인사이트를 제공하는 글이 되었으면 좋겠다.