SLASH 23 - 대규모 로그 처리도 OK! Elasticsearch 클러스터 개선기

수백 테라바이트 규모가 되며 장애가 종종 발생했다. 클러스터가 느려져 인덱싱·검색이 지연되고 데이터 노드가 내려가기도 했는데, 공통적으로 매우 많은 필드 데이터(fielddata) 메모리를 쓰고 긴 GC가 빈번했다. 원인은 일부 필드에 필드 데이터 옵션을 잘못 켜둔 것이었다. doc_values 도입 전에는 애그리게이션·정렬에 필드 값을 힙에 올려야 했는데, 큰 인덱스 필드를 메모리에 올리며 JVM 메모리가 부족해진 것이다. 단 7개 필드뿐이었지만 유입 로그량이 워낙 많아 금세 힙이 찼다. 지금은 컬럼 기반 doc_values로 발전해 특별한 경우가 아니면 필드 데이터를 쓸 일이 없다.

또 하나의 위협은 매핑 익스플로전(mapping explosion)이었다. 입력 JSON의 키가 너무 많으면 매핑이 폭발하고 마스터 노드가 불안정해진다. 해결은 키 수를 줄이거나, flattened 타입을 쓰거나, 다이나믹 템플릿(dynamic template)으로 지정 없는 문자열을 keyword로 매핑하고 `dynamic: false`로 통제하는 것이다. 샤드 설정도 헤비 인덱스는 프라이머리 샤드 수를 핫 노드 수에 맞추고, refresh 60초·flush 1GB로 머지·플러시 빈도를 낮췄다. 이어 90여 개 파이프라인을 모두 쓰던 Logstash가 JVM 기반이라 메모리를 200GB 넘게 쓰자, Rust 기반 경량 로그 슈퍼 Vector로 전환해 메모리를 약 260GB에서 10GB로 96% 감소, CPU도 55코어에서 27코어로 절반 줄였다.

데이터 센터 이중화로 새 DC가 추가되며 새 DC 로그를 수집할 클러스터가 필요해졌다. 클러스터를 통째로 한 세트 더 두는 대신, 두 데이터 센터에 걸쳐 하나의 클러스터를 구축할 수 있을지 검토했다. 서로 다른 DC의 노드를 하나로 묶는 것은 Elasticsearch가 권장하지 않지만(DC 간 레이턴시가 성능을 떨어뜨림), 두 DC가 가깝고 레이턴시가 작다면 AWS 리전 내 가용성 존처럼 볼 수 있고 약간의 지연보다 비용 절감 이득이 크다고 판단했다.

대신 샤드 복제·복구 트래픽을 위해 전용 회선을 별도 구축하고, 한 IDC 장애에 대비해 리플리카 샤드는 서로 다른 IDC에 저장하며, 투표 전용 마스터 노드가 필요하다. 각 IDC에 투표 전용 마스터 노드를 두고, 투표만 하는 노드는 제3의 장소인 AWS에 배치해 타이브레이커 역할로 스플릿 브레인을 방지했다. 샤드 어웨어니스(shard awareness)로 프라이머리·리플리카를 다른 IDC에 배치하고, 포스 어웨어니스(forced awareness)로 두 IDC 노드가 모두 합류했을 때만 샤드 배치가 일어나게 해 과도한 복제를 막았으며, 전송 계층 압축으로 대역폭도 아꼈다.

마지막으로 IDC-1과 IDC-2의 노드들을 하나의 클러스터로 묶은 전체 아키텍처를 정리한다. DC 간 네트워크 단절이 생기면 한쪽 IDC에서 투표로 마스터가 선출되고 같은 구역 노드만 남으며, 장애가 해소되면 반대편 IDC 노드가 다시 합류한다. 이 구조 덕분에 하나의 데이터 센터 장애에도 견디는 클러스터를 운영하게 됐다.

1년의 여정을 다시 짚으면, hot-warm 아키텍처로 비용을 절감하고, 필드 데이터 오용과 매핑 익스플로전을 잡아 안정성을 확보하고, Logstash를 Vector로 바꿔 리소스를 극적으로 줄였으며, 두 IDC를 하나의 클러스터로 묶어 데이터 센터 장애에 견디는 구조를 만들었다. 서비스가 커질수록 더 도전적인 엔지니어링이 기다리고 있고 그 결과를 다시 공유하겠다는 다짐으로 마무리한다.