[ NAVER D2 ] NELO Alaska: 대용량 로그 데이터 저장을 위한 Apache Iceberg 도입기

 

 

---

 

이 글은 NAVER D2에서 게시한 [ NELO Alaska: 대용량 로그 데이터 저장을 위한 Apache Iceberg 도입기 ]를 읽고 작성한 글입니다.
(https://d2.naver.com/helloworld/8998207)

 

 

---

 

배경

 

로그 모니터링 시스템은 서비스 운영을 위해 반드시 필요한 시스템이다.

이러한 로그 모니터링 시스템을 구축할 때는 인덱스 기반의 빠른 검색을 제공하는 Elastic Search 검색 엔진이 주로 사용된다.

 

네이버도 Elastic Search 기반의 로그 모니터링 시스템을 구축했으며, 수천 대의 서버로 대규모의 로그 데이터를 저장하였다.

그러나, 최근 들어 서비스 규모가 확장되고 저장해야 하는 로그 데이터의 규모와 트래픽 양이 급속도로 증가하면서 Elastic Search 기반의 로그 모니터링 시스템은 비용 문제, 확장성 문제에 직면하였다!

 

---

문제 인식

 

출처 : https://d2.naver.com/helloworld/8998207

 

네이버의 로그 모니터링 시스템 플랫폼인 NELO에서 기존에 사용하던 시스템 구조는 위와 같다.

클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후, Elastic Search에 저장된다.

 

여기서 네이버는 Elastic Search를 두 계층으로 구분하여 관리한다.

• Hot 계층 (Hot Tier)
  • SSD 타입의 스토리지로 구성
  • 빈번히 사용되는 로그 데이터를 3일간 저장하다가, 사용되지 않으면 Warm 계층으로 전달
• Warm 계층 (Warm Tier)
  • HDD 타입의 스토리지로 구성
  • Hot 계층으로부터 받은 로그 데이터를 최대 90일까지 저장

 

이를 통해, 검색이 비번하게 발생하는 데이터와 빈번하게 발생하지 않는 데이터를 구분함으로써, 로그 데이터를 효율적이면서 저비용으로 저장하는 것이다.

로그 모니터링 시스템은 수년간 이와 같은 구조로 운영되었다고 한다.

 

하지만, 데이터가 증가함에 따라 Warm 계층에 저장된 데이터의 크기도 급증하였다.

Elastic Search는 단일 클러스터에 저장할 수 있는 데이터의 크기에 제한이 있기 때문에, 여러 Elastic Search 클러스터를 구성해 클러스터 수준의 확장을 진행했다고 한다.

이로 인해, 모든 클러스터가 한계 수준까지 도달해 운영 장애를 빈번히 겪었으며, 연간 수십억 원의 인프라 사용 비용이 발생했다고 한다!

더이상 Elastic Search 기반의 로그 모니터링 시스템 구조는 로그 데이터를 효율적으로 저장하지 못하는 것이다.

 

---

분석

 

출처 : https://d2.naver.com/helloworld/8998207

 

네이버는 이러한 문제를 해결하기 위해 먼저 로그 데이터가 어떻게 사용되고 있는지 분석하였다.

기존 로그 모니터링 시스템이 한계에 도달하면서, 이러한 장기간 로그 데이터 저장에 대한 요구 사항을 Elastic Search로 수용하는 것이 적합한지 검토한 것이다.

 

위 그래프는 한 달 동안 사용자들의 검색 요청 로그를 분석한 그래프이다.

X축은 데이터가 저장되고 지난 시간을 의미하며, Y축은 데이터를 검색한 쿼리의 비율을 의미한다.

분석 결과, 전체 검색 쿼리 중 95%의 쿼리가 당일에 발생한 데이터에 대한 것이었으며, 99%의 쿼리가 일주일 이내의 데이터에 대한 것이었다.

단 0.5%의 쿼리만 2주 이상 지난 데이터를 요청한 쿼리였다고 한다.

 

Elastic Search는 일반적으로 데이터 저장과 쿼리 계산을 위한 컴퓨팅을 동일한 노드에서 담당하고 있기 때문에, 이렇게 거의 검색되지 않는 데이터를 저장하는 것은 비효율적인 일이다.

최신 버전의 Elastic Search는 원격 스토리지에 데이터를 저장하고 검색하는 기능을 제공하기는 하지만, 마스터 노드가 관리할 수 있는 메타데이터의 규모에도 한계가 있기 때문에, 네이버의 거의 검색되지 않는 방대한 양의 로그 데이터를 저장하기에 Elastic Search는 적합하지 않았던 것이다.

 

---

대안

 

네이버는 이러한 문제를 해결하기 위해 Elastic Search에는 검색이 자주 일어나는 단기간의 데이터 저장만 허용하고, 장기간 데이터를 저장할 새로운 스토리지가 필요하다는 결론을 내렸다.

이를 위해 Elastic Search를 대체하는 신규 스토리지는 데이터 저장을 위한 스토리지와 검색을 위한 컴퓨팅이 분리되어야 하며, Elastic Search처럼 특정 쿼리 엔진에 제한되지 않는 오픈 데이터 포맷을 가져야 한다는 기준을 잡고 설계를 시작하였다.

 

다양한 저비용의 스토리지에 데이터를 저장할 수 있는 여러 방식을 비교, 분석, 시뮬레이션 하면서, 네이버는 결국 Iceberg라는 대안책을 찾아냈다.

Iceberg로 실행한 시뮬레이션에서는 기존 시스템보다 최소 50% 이상의 비용을 절감할 수 있다는 결과를 얻어낸 것이다.

 

네이버는 Iceberg를 기반으로 새로운 로그 모니터링 컴포넌트인 Alaska를 개발해낸다.

기존 Elastic Search 기반의 로그 모니터링 시스템은 유지하되, 장기간 보관이 필요한 데이터는 Alaska를 활성화하여 저장하도록 설계한 것이다.

네이버는 Iceberg Java SDK를 기반으로  Orca, Polarbear, Puffin 컴포넌트를 개발하여 사용하였다.

 

---

결과

 

Iceberg 기반의 신규 로그 모니터링 시스템을 오픈하면서 기존 Elasticsearch 기반의 로그 데이터는 최대 데이터 보관 기간이 14일로 단축되었다.

이를 통해, 2000대 이상의 Elastic Search 노드를 줄일 수 있었으며, 데이터 용량도 수 페타바이트 규모에서 수백 테라바이트 규모로 감소되었다고 한다.

또한, 예상되는 인프라 비용이 매년 수 십억 원까지 절감되었다.

늘어나는 트래픽 추세를 감안하면 절감되는 비용은 매년 그 이상이 될 것이라 예상한다고 한다.

 

---

결론

 

네이버의 기존 로그 모니터링 시스템은 Elastic Search를 기반으로 구성되었으며, 수 천대의 서버로 수 페타바이트 규모의 로그 데이터를 저장하였다.

하지만 데이터 쿼리 패턴을 분석한 결과, 대규모 데이터 중에서 70%의 데이터는 검색이 거의 이루어지지 않는 콜드 데이터다.

네이버는 이러한 데이터를 고비용, 고성능 저장소인 Elastic Search 에 저장해야 할지 검토하였고, 검색이 거의 이루어지지 않지만 법적 요구 사항과 사후 분석을 위해 장기간 로그 저장에 대한 요구 사항이 많았기 때문에 새로운 저비용의 로그 검색 시스템을 구축하기로 결정하였다.

NELO 팀은 Alaska 컴포넌트를 개발하여 이러한 요구 사항을 만족하면서 획기적으로 비용을 절감하였다.

 

---

느낀점

 

Elastic Search는 전세계에서 손꼽히는 대표적인 검색 엔진 중 하나이다.

네이버도 기존에는 Elastic Search를 활용하여 로그 모니터링 시스템을 구축하였다.

 

하지만, 네이버는 문제점을 발견하고 이를 해결하기 위해 다양한 기술로 시뮬레이션하며 가장 효과적인 해결책을 찾으려고 노력하였다.

사용하는 인원이 많다고 항상 답은 아니라는 것이다.

내가 어떤 기술을 사용해 프로젝트를 진행한다면, 해당 기술을 선택한 명확한 이유가 있어야 한다.

 

남들이 많이 사용해서, 그냥 편해서 등의 이유로 기술을 선택적으로 사용하면 각박한 개발자 생태계에서 살아남을 수 없다.

다른 기술도 효용이 있다면 언제든지 검토할 열린 마인드를 가져야 한다!

 

 

---

 

 

출처 : https://d2.naver.com/helloworld/8998207