시스템 엔지니어의 ES 삽질기 #1
Linux Opensource
이번 글에서는 시스템 엔지니어 입장에서 ES 클러스터를 구축하면서 겪었던 삽질기에 대해서 다루려고 합니다. 제가 겪었던 삽질기를 공유함으로써 더 좋은 아키텍처를 고민할 수 있는 좋은 기회가 되었으면 합니다.
문제의 발단
문제의 발단은 이렇습니다. ES는 특히 Logstash, Kibana와 함께 ELK 스택이라 불리며 로그 수집 및 분석 용도의 툴로 계속해서 사용이 늘고 있었으며, 그 외에도 사용자에게 제공할 서비스 데이터를 NoSQL 방식으로 접근해서 저장과 검색을 통해 제공해 줄 수 있기 때문에 개발자들의 서버 요청이 계속해서 늘고 있었습니다. 하지만, ES에 대한 모니터링 및 관리 포인트가 발생하고, ES에 문제가 있을 때에는 ES 문제 해결을 위해 시간은 빼앗겨 정작 중요한 개발 업무에 영향을 미치게 되는 경우가 있었습니다. 그러다 문득, ES는 오픈소스인데, 이걸 꼭 개발자가 설치해서 사용할 필요는 없지 않을까?
인프라 팀에서 ES 구축 및 모니터링을 전담해 주고, 개발자들을 그냥 가져다 쓰기만 하게 되면 개발 생산성도 더 높아지고 인프라 팀의 위상도 높아지지 않을까 라는 생각이 들었습니다.
그래서 겁도 없이 ES 클러스터 구축 업무를 지원하기 시작했습니다.
nginx를 이용한 ES 팜
초창기 모델은 제가 이전에도 올렸던 것처럼 nginx를 이용한 ES 팜이었습니다. (https://brunch.co.kr/@alden/20) 고사양의 서버를 이용해서 여러 개의 ES 인스턴스를 올리고 nginx의 server_name을 이용해서 upstream으로 분기시키는 구조였습니다. 이 모델을 생각했던 이유는 ES 용도로 너무 많은 서버들이 투입되고 있고, 그 서버들도 하드웨어 성능을 최대한으로 뽑아내지 못하고 있기 때문에 서버 투입도 줄이고 집적화를 통해서 더 효율적으로 사용할 수 있을 것이라고 생각했기 때문입니다.
nginx를 이용한 ES 팜 구조하지만 이 모델은 결과적으론 실패하게 되었는데요, 그 이유는 첫 째, 특정 클러스터의 사용률이 너무 높으면 같은 서버에 올라가 있는 다른 클러스터들도 영향을 받게 됩니다. 한 클러스터의 데이터 저장이 많아져서 노드를 늘리게 되면 결국 같은 노드에 올라가 있는 모든 인스턴스를 다 같이 설치해야 하는 번잡스러움이 있습니다. 두 번째로는 생각보다 많은 커뮤니케이션 비용이었습니다. 하나의 노드에 문제가 있을 경우 결국 5~6개의 클러스터에 영향이 가게 되는데 이렇게 되면 5~6명의 개발 담당자들과 커뮤니케이션을 해야 하기 때문에 이것도 무시할 수 없는 비용이었습니다. 그리고 세 번째로 하나의 서버에 여러 개의 노드를 포트를 다르게 해서 올리다 보니간혹 수작업으로 작업을 해야 할 경우 실수로 전혀 상관없는 클러스터에 영향을 미칠 수 있게 되었습니다. 사실 이 문제가 가장 컸다고 봐야 합니다.
위에 언급된 문제들은 자동화된 툴을 개발해서 작업을 전부 자동화 하게 되면 큰 이슈가 없을 수도 있었지만, 그것보다 하나의 서버에 여러 개의 ES 인스턴스를 올리는 게 좋은 구조인가 라는 그 근본적인 질문에 좋은 답을 찾지 못해서 실패 하게 된 부분도 있습니다.
클러스터 별로 별도의 서버군 구성
결국 nginx를 이용한 ES 팜 모델은 실패로 끝나고, 클러스터 별로 별도의 서버군으로 구성하는 일반적인 모델로 돌아오게 됩니다.
마스터 노드, 데이터 노드를 구분하지 않는 모델이 모델은 마스터 노드, 데이터 노드를 별도로 구분하지 않고 사용하는 모델로 별 고민 없이 사용할 경우 가장 일반적으로 사용되는 모델입니다. 대부분의 경우 문제가 발생하지는 않습니다만, 이 모델은 아주 치명적인 약점이 있습니다.
맨 처음 디자인했을 때와 달리 클러스터가 커질 경우 일부 노드들 간의 네트워크 문제가 발생하면 split brain 현상이 발생할 수 있게 됩니다.
위의 예제처럼 맨 처음 클러스터를 구축할 때 4개의 노드로 시작하고 zen.minimum_master_nodes 값을 3으로 설정했다고 가정합니다. 이 후로 사용량이 늘어서 2대의 노드가 더 늘어났다고 가정해 보겠습니다. 그러다가 네트워크 적인 이슈로 인해 노드들이 3개씩 쪼개졌다고 가정하게 되면, 두 개의 쪼개진 클러스터 모두 minimum_master_nodes:3을 충족하기 때문에 클러스터가 무너지지 않고 유지됩니다. 즉, 하나의 클러스터가 두 개로 쪼개진 split brain 현상이 일어나게 됩니다.
split brain 현상의 위험성물론 클러스터 구축 후 신규로 들어가는 노드들의 경우 데이터 노드의 역할만 하게 투입할 수 있지만, 일관성 없는 설정은 후에 더 큰 장애의 위험을 만들어 낼 수 있기 때문에 지양하는 것이 좋습니다.
마스터 노드와 데이터 노드의 분리
세 번째로 시도한 모델은 마스터와 데이터 노드를 분리하는 모델입니다. 아마도 대규모의 클러스터에서는 가장 많이 사용되는 모델이 아닐까 합니다.
마스터 노드와 데이터 노드를 분리한 모델마스터 노드를 초기 디자인할 때 3대로 설정하고 사용량이 날 때 마다 데이터 노드만 증설하는 형태입니다. 이렇게 되면 마스터 노드의 경우는 그 숫자가 늘어나지 않기 때문에 split brain 현상도 막을 수 있고 용량이 부족할 경우 데이터 노드만 증설해 주면 되기 때문에 증설 작업도 어렵지 않습니다. 그래서 현재도 용량이 크지 않은 중, 소규모의 클러스터의 경우 위 모델로 대부분 구축이 됩니다.
Hot-Warm 아키텍처의 도입
마스터 노드와 데이터 노드를 분리하는 세 번째 모델 만으로도 대부분의 클러스터에 대한 구축 요청은 처리할 수 있었지만 필요로 하는 클러스터의 크기가 수십 TB 사이즈가 되면 데이터 노드의 수도 급증하게 되는 단점이 있었습니다. 게다가 데이터 노드의 표준 사양으로 SSD를 선택했기 때문에 비용도 기하급수적으로 늘어나게 됩니다. 그래서 도입한 것이 Hot-Warm 아키텍처입니다. 이미 같은 고민을 하신 분들이 많은지 Elastic 쪽에서도 블로그를 통해 발표한 구조입니다. (https://www.elastic.co/blog/hot-warm-architecture)
Hot Warm 아키텍처로그성 데이터의 경우 조회가 잦은 최근 데이터들만 SSD로 구성된 Hot 데이터 존에 담아두고, 기한이 오래되어 상대적으로 조회가 뜸한 데이터들은 SATA로 구성된 Warm 데이터 존에 담아두는 구조입니다. 이렇게 되면 수십 TB의 저장 공간이 필요한 클러스터라도 최근 데이터 수 TB 정도만 SSD에 담아두고 나머지는 상대적으로 저렴하고 많은 데이터를 넣을 수 있는 SATA 쪽으로 옮기게 되어 서버 대수를 많이 줄일 수 있게 됩니다.
마치며
이번 글에서는 ES 클러스터를 구축하면서 겪었던 이슈들을 이야기해보며 어떻게 클러스터의 구성이 변화했는지를 살펴봤습니다. 다음 글에서는 어떻게 모니터링 시스템을 구성해서 사용하고 있는지에 대해 살펴보겠습니다.
긴 글 읽어 주셔서 감사합니다.
