안녕하세요, 여러분. 15년 차 백엔드 개발자이자, 수많은 밤을 데이터 파이프라인과 씨름하며 보낸 여러분의 동료입니다. 오늘은 개발자라면 누구나 한 번쯤 겪어봤을, 아니 어쩌면 지금 이 순간에도 겪고 계실지도 모르는 '그 문제'에 대해 이야기해보려 합니다. 바로 Elasticsearch(엘라스틱서치)의 대용량 로그 색인(Indexing) 속도 저하 문제입니다.
혹시 이런 경험 있으신가요? 로그 시스템을 처음 구축했을 때는 키바나(Kibana) 대시보드가 날아다녔습니다. 데이터가 들어오자마자 그래프가 그려지고, 검색하면 0.1초 만에 결과가 떴죠. 그런데 서비스가 성장하고, 트래픽이 늘어나고, 하루 로그량이 100GB를 넘어서면서부터 이상 징후가 보이기 시작합니다.
"어? 방금 발생한 에러 로그가 왜 안 보이지?" 하고 확인해보면, 로그가 10분, 30분, 심지어 1시간씩 지연되어 들어오고 있습니다. 클러스터 상태는 노란색(Yellow)이나 빨간색(Red)을 오가고, CPU는 비명을 지르며 100%를 찍고 있죠. 개발팀 슬랙 방에는 "로그 시스템 또 멈췄나요?"라는 메시지가 올라오고, 여러분은 식은땀을 흘리며 노드 재시작 버튼을 누를까 말까 고민하게 됩니다. ☕ 커피를 아무리 마셔도 해결되지 않는 이 답답함, 저도 뼈저리게 겪어봤습니다.
많은 분들이 이때 하드웨어 스펙을 올리는 'Scale-up'을 먼저 고려합니다. 물론 돈으로 해결하는 게 가장 빠를 수 있습니다. 하지만 엘라스틱서치의 내부 동작 원리를 모르고 무작정 메모리만 늘린다면, 마치 밑 빠진 독에 물 붓기와 같습니다. 128GB 램을 꽂아도 설정 하나 잘못되면 4GB 램을 쓰는 것보다 느릴 수 있거든요. 제가 실제로 컨설팅했던 한 물류 스타트업은 고가의 장비를 쓰고도 초당 2,000건 처리에 허덕이고 있었지만, 튜닝 후에는 동일 장비로 초당 50,000건을 처리하게 되었습니다.
오늘 이 가이드에서는 단순한 설정값 복사-붙여넣기가 아니라, "왜 느려지는지"에 대한 근본적인 원리부터, 실전에서 즉시 적용 가능한 샤드 배치 전략과 JVM 힙 메모리 튜닝, 그리고 제가 현장에서 피눈물 흘리며 배운 노하우들을 아주 상세하게 풀어보려 합니다. 교과서적인 이야기는 빼고, 진짜 '밥벌이'에 도움 되는 이야기만 담았습니다. 준비되셨나요? 그럼 엘라스틱서치의 엔진 뚜껑을 열어보겠습니다.
1. 색인 속도의 핵심, 샤드(Shard) 배치 전략의 모든 것
엘라스틱서치 성능 문제의 80%는 잘못된 샤드 설정에서 시작됩니다. 샤드는 데이터를 분산 저장하는 최소 단위입니다. 이를 이해하기 쉽게 도서관에 비유해 볼까요? 도서관에 책(데이터)이 100만 권 들어온다고 가정해 봅시다. 사서(노드) 한 명이 이 모든 책을 혼자 정리하려면 과로로 쓰러질 겁니다. 그래서 우리는 여러 명의 사서에게 책을 나눠서 정리하게 시키죠. 이때 책을 나누는 묶음이 바로 '샤드'입니다.
그런데 여기서 딜레마가 발생합니다. 사서들에게 책을 너무 잘게 쪼개서 주면(샤드 과다), 사서들은 정리하는 시간보다 서로 "이 책 어디 있어?"라고 묻고 관리 장부를 쓰는 데 시간을 더 낭비하게 됩니다. 반대로 책을 너무 큰 묶음으로 주면(거대 샤드), 묶음 하나를 옮기는 데 너무 많은 힘이 들어 작업 속도가 현저히 느려집니다. 이것이 바로 '샤드 개수와 크기의 균형'이 중요한 이유입니다.
📉 오버 샤딩(Over-Sharding)의 함정
많은 초보 개발자분들이 범하는 가장 흔한 실수가 바로 '오버 샤딩'입니다. "분산 처리가 좋으니까 샤드를 많이 만들면 빠르겠지?"라고 생각해서, 하루에 1GB도 안 쌓이는 로그 인덱스에 샤드를 5개, 10개씩 할당하는 경우입니다. 제가 봤던 최악의 사례는 100GB 전체 데이터에 샤드가 5,000개가 넘는 클러스터였습니다.
왜 이게 문제일까요? 각 샤드는 루씬(Lucene) 인스턴스입니다. 샤드 하나하나가 CPU 스레드, 메모리 버퍼, 파일 디스크립터를 소비합니다. 샤드가 너무 많으면 클러스터 상태(Cluster State) 정보가 비대해져서 마스터 노드가 이를 관리하느라 멈춰버립니다. 검색뿐만 아니라 색인할 때도 어느 샤드에 넣을지 계산하고 메타데이터를 갱신하는 비용이 기하급수적으로 늘어납니다.
⚖️ 황금 비율: 샤드 크기 최적화 가이드
그렇다면 적절한 샤드 크기는 얼마일까요? 정답은 없지만, 엘라스틱서치 커뮤니티와 제 경험상 통용되는 '황금 규칙'이 있습니다. 바로 로그 데이터의 경우 샤드 하나당 30GB에서 50GB 사이를 유지하는 것입니다. 검색 위주의 데이터라면 20GB 내외가 좋고, 단순히 저장하고 가끔 조회하는 로그라면 50GB까지도 무방합니다.
예를 들어, 하루에 100GB의 로그가 들어온다고 가정해 봅시다. 이 경우 프라이머리 샤드(Primary Shard)를 2개에서 3개 정도로 설정하면 샤드당 33GB~50GB가 되어 적절합니다. 만약 하루 로그가 1GB 미만이라면? 무조건 샤드 1개로 설정해야 합니다. 주 단위(Weekly)나 월 단위(Monthly) 인덱스로 변경하는 것도 필수적으로 고려해야 합니다.
또한, JVM 힙 메모리 1GB당 샤드 개수를 20개 이하로 유지하는 것이 좋습니다. 예를 들어 노드의 힙 메모리가 30GB라면, 해당 노드는 최대 600개의 샤드만 보유하는 것이 안전합니다. 이 범위를 넘어서면 Full GC(Garbage Collection)가 빈번하게 발생하여 색인 성능이 급격히
댓글
댓글 쓰기