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

ElasticSearch를 도입하기 전에 스스로에게 던진 질문이다. 도입하기까지의 고민과, 1년을 운영한 뒤의 답을 적는다.

무엇을 만들고 있었나#

전기차 충전소 조회 시스템을 제로에서 만들고 있었다. 전기차 이용자는 가는 충전소가 대체로 정해져 있다. 그래서 지도를 먼저 보여 주는 대신, 자주 가는 충전소가 지금 비어 있는지를 가장 빨리 알려 주는 것을 목표로 했다.

이를 위해 매분 외부 API에서 전국 충전기의 상태를 받아 MariaDB에 쌓았다. 당장은 필요 없는 과거 상태까지 남긴 건, 나중에 분석할 사람이 Raw 데이터를 찾을 때 내놓을 수 있어야 한다고 봤기 때문이다.

ElasticSearch는 예전에 로그 분석 도구를 찾다가 알게 됐다. Kibana에 로그 파일을 올려 본 게 전부였지만 인상은 강하게 남아 있었다.

ES가 아니어도 되는 이유들#

처음 떠올린 이유는 여럿이었는데, 하나씩 따져 보니 대부분은 ES가 아니어도 됐다.

• 읽기와 쓰기의 분리. 쉼 없이 쓰는 DB에 실시간 조회까지 얹고 싶지 않았다. 하지만 이건 읽기 전용 복제본이나 캐시로도 풀린다.
• 위치 기반 조회. MariaDB도 위치 검색을 지원하고, 인덱스를 잘 잡으면 당시 요구사항은 충족됐다.
• 똑똑한 검색창. 동 이름이든 개떡같이 입력된 이름이든 찰떡같이 찾아 주는 검색은 ES가 잘하는 일이다. 하지만 그건 나중 일이었고, 나중 일로 지금의 스택을 정할 수는 없다.

ES여야 했던 이유 하나#

남은 건 하나였다. 쌓이는 상태 데이터를 팀원 누구나, 개발자에게 부탁하지 않고, 직접 집계해 볼 수 있어야 한다는 것.

오늘 가장 붐빈 충전소는 어디인지, 한 달 추이는 어떤지, 이용이 급증한 곳은 어디인지. 이런 질문은 매번 달라지기 때문에 질문마다 백오피스 화면을 코딩할 수는 없다. 대시보드 도구가 필요했다.

대시보드만이라면 Grafana를 MariaDB에 바로 붙이는 방법도 있었다. 걸린 건 데이터의 크기였다. 시각화 도구가 제대로 돌려면 그 밑의 집계 성능이 받쳐 줘야 하는데, 매분 쌓이는 10만 기 이상의 상태 로그를 1년 단위로 집계하는 질의를 서비스가 쓰는 RDB에 던질 수는 없다고 판단했다. 대량의 시계열을 실시간으로 집계하는 것. 그게 ES를 고른 이유다.

치러야 할 값도 알고 있었다.

• MariaDB와 ES를 동기화해야 하고, 둘 사이에는 잠깐씩 불일치가 생긴다. 다만 충전은 수십 분에서 수 시간이 걸리는 일이라, 1~2분의 불일치는 서비스에 영향이 없다고 봤다.
• 경험이 없었다. 배우는 데 드는 시간과 체력도 스타트업에서는 비용이다. 우리가 하려는 게 ELK의 흔한 사용 사례이고 문서가 잘 되어 있다는 점에 기대기로 했다.

1년 뒤: 정말 필요했나?#

반반이다.

기대한 것은 기대대로 됐다.

• 10만 기가 넘는 충전기의 1년치 Raw 데이터를 한 번에 불러와도 Kibana는 실시간으로 그래프를 그렸다.
• 조회를 ES로 분리한 구조에서, 설계대로 충전기 상태를 1분 단위로 제공했다. 당시 비슷한 서비스들은 3~5분 간격이었다. 누군가 충전기를 꽂는 순간 시스템이 그 변화를 잡아내는 걸 지켜볼 때는 짜릿했다.
• 집계, 텍스트, 위치를 섞어 점수로 줄 세우는 질의가 한 번에 됐다.
• LogStash가 데이터를 옮기면서, 점으로 찍힌 상태 로그를 '충전의 시작과 끝'이라는 선으로 바꿔 줬다. (이 이야기는 타임시리즈 상태로그에서 작업 식별하기에 따로 썼다.)

예상하지 못한 값도 치렀다.

• LogStash가 전처리를 너무 잘해 주다 보니 MariaDB에는 없는 컬럼이 ES에만 늘어났다. 스키마가 둘로 갈라지기 시작했다.
• 컬럼 타입 하나를 바꾸려면 Re-Indexing을 해야 했다.
• SELECT 한 줄이면 될 조회를 JSON QueryDSL로 길게 써야 했다.
• 클러스터 구성 같은 ES의 안정성 기능은 제대로 쓰지 못했다.
• 그리고 정작 팀원들에게 Kibana는 어려웠다. 도입한 이유가 '누구나 직접 본다'였는데, 도구를 주는 것과 쓰게 되는 것은 다른 일이었다.

그래서, 다시 고른다면#

치른 값을 다시 읽어 보면 두 종류다.

하나는 저장소를 하나 더 들인 값이다. 스키마가 둘이 되고, 질의 언어가 둘이 되고, 무언가를 바꿀 때마다 절차가 하나 더 붙는다. 이건 ES를 어떻게 운영하든 따라온다.

다른 하나는 운영하는 값이다. 설치와 설정, 클러스터 구성, 장애 대비. 이건 관리형 서비스에 맡길 수 있었다. 당시에는 요금표를 보고 비싸다며 접었는데, 비교 대상이 틀렸다. 관리형 서비스의 값은 서버 값이 아니라 그 일을 할 사람의 시간과 견줘야 했다.

도입 전의 나는 기능을 비교했다. ES가 무엇을 할 수 있는지, MariaDB로는 어디까지 되는지. 지금이라면 표에 한 줄을 더 넣는다. 이걸 들이면 누구의 시간이 얼마나 드는가. 작은 팀에서는 그 줄이 나머지 줄을 다 합친 것보다 무겁다.