검색엔진 도입기와 인간 뉴렐릭 시절 회고

– Elasticsearch, Haystack, 그리고 htop으로 버텨낸 그 시절 이야기

---

시작하며

지금이야 Sentry, Datadog, CloudWatch 같은 모니터링 툴 없으면 불안해서 서버 못 만지지만,  
그때는 2017년. 그런 거 잘 안 쓰던 시절이었다. 서버 상태는 감으로 느끼고, 장애는 몸으로 겪었다.

그 시절, 나는 모니터링 시스템이자 에러 알림 툴,  
그야말로 인간 뉴렐릭이었다.

이 글은 내가 검색 성능 때문에 Elasticsearch를 도입하면서 겪은 삽질과,  
서버가 터질 때마다 htop으로 위기 넘긴 그 시절, 2017년 이야기다.

---

검색 성능 터지기 직전

참고로 당시 내가 담당했던 서비스는 해당 블로그 에서 확인이 가능하다.
지금은 사라졌지만, 그 시절엔 실제 사용자도 많았고 트래픽도 꽤 됐다.  
상품도 100만 건 넘게 등록돼 있어서, 검색 한 번 누르면 서버가 한숨 쉬는 상황이었다.

당시 운영하던 서비스에서 상품 수가 100만 건을 넘기면서 검색이 슬슬 버벅대기 시작했다.

• 상품 검색 속도가 눈에 띄게 느려졌고,
• 연관 검색은 아예 못 보여주고 있었음.

예를 들어, 유저가 "빨간 원피스" 검색하면
red, 빨강, 붉은 등도 함께 검색돼야 했는데,
ORM으로 OR 조건 조합해서 쿼리 짜는 건 한계가 있었고,
속도도 느리고 검색 결과도 부정확했다.

그때 처음으로 "이건 ORM으로 해결할 게 아니다" 라는 걸 느꼈다.

---

검색엔진을 알아보다

검색 성능 이슈를 해결하려고 검색엔진 도입을 고민했다.
지금처럼 Elasticsearch가 당연한 선택지는 아니었고,
그냥 검색엔진이라는 단어조차 익숙하지 않았다.

당시 알아봤던 건 대충 이 3가지였다.

1. elasticsearch-py

공식 Python 클라이언트인데, 너무 로우레벨이라
직접 쿼리 짜고 통신 처리해야 해서 조금 버거웠다.

2. AWS Elasticsearch

지금은 OpenSearch로 바뀌었지만,
그때는 비용이 부담스럽기도 했고,
기능 제약도 있어서 패스.

3. Django Haystack + Elasticsearch

이건 Django ORM처럼 검색을 다룰 수 있어서
처음 도입할 때 편할 것 같았다.

---

결국 Haystack 선택

결국 Haystack을 선택했다.
검색엔진 경험도 없었고, 일단 익숙한 Django 스타일로
시작하는 게 맞다고 판단했다.

• Django 모델인 Product 기반으로
  search_indexes.py에 인덱스 정의
• Elasticsearch랑 연동해서 검색 처리

여기까지는 괜찮았다.
문제는 인덱싱 작업에서 터졌다.

---

rebuild_index, 그리고 서버 다운

Haystack에는 rebuild_index라는 명령어가 있다.
검색 인덱스를 밀고 새로 쌓는 작업이다.
쉽게 말하면 기존 걸 다 날리고,
전체 데이터를 로드해서 다시 Elasticsearch에 보내는 작업.

문제는, 이걸 돌리자마자 서버가 터졌다.

• 전체 데이터를 메모리에 올리면서 OOM(Out of Memory) 발생
• DB I/O도 많고, Elasticsearch로 bulk 요청이 미친 듯이 나감
• 근데 문제는 이걸 서버랑 Elasticsearch가 같은 EC2 인스턴스에서 돌리고 있었다는 거

결국 서버 자체가 멈춤. SSH 접속도 안 됨. 공포.

---

모니터링은 htop으로

당시엔 Sentry도 없고, CloudWatch 알람 같은 것도 안 썼다.
서버 이상하면 그냥 직접 SSH 접속해서 htop 켰다.

ssh ubuntu@서버아이피
htop

딱 보면 메모리, CPU 사용률 다 나옴.

CPU: 98%
MEM: 91%
Swap: 40%

Elasticsearch가 메모리를 다 먹고 있었음.
바로 F9 → 9 (Kill)로 죽이고 다시 띄움.
이게 그때 내가 하던 모니터링의 전부였다.

---

그래도 해결은 해야 하니까

서버 죽어나가니까 방법을 찾아야 했다.
찾아보니 rebuild_index 명령어에
--batch-size 옵션이 있다는 걸 발견.

이걸로 한 번에 인덱싱하는 양을 줄이니까
서버가 버틸 수 있었고, 시간은 오래 걸렸지만
어쨌든 서버 다운 없이 인덱싱 성공.

---

지금 생각하면

지금은 Datadog, Sentry, CloudWatch 알람으로
서버 상태 실시간으로 확인하고,
에러는 Slack으로 실시간 알림 받는다.

근데 그때는 진짜 나 자신이 모니터링 툴이었다.
서버 이상한지 감으로 느끼고, htop으로 실시간 확인하고,
직접 문제 찾아서 고치던 그 시절.

---

정리

그때 경험하면서 느낀 건:

• 검색엔진 도입은 단순히 라이브러리 추가하는 게 아니라 구조 설계까지 고려해야 한다.
• 서버 자원, 인덱싱 전략, 데이터 양 다 포함해서 계획해야 한다.
• 그리고 진짜 모니터링 툴은 필수다. 감으로는 못 버틴다.

---

 

마무리

지금 돌아보면 진짜 고생했지만,
덕분에 실전에서 많이 배운 프로젝트였다.
그리고 서버가 터질 때마다
htop과 함께 했던 그 시절,
나는 진짜로 인간 뉴렐릭이었다.

 

 

 

---