RTL Germany가 Elastic Observability의 프로즌 티어로 전환 중 가동 중단 시간 없이 보존 기간을 세 배로 늘린 방법

RTL Germany는 중앙 집중식 데이터 레이크를 재구상하여 표준 보존 기간을 30일에서 90일로 늘리고, 노드 수를 거의 절반으로 줄이며, 데이터 손실 없이 마이그레이션을 완료했습니다.

RTL Germany는 거의 10년 동안 성장해 온 전사적 Elastic 데이터 레이크를 운영하고 있으며, 이는 부서 전반에 걸쳐 로깅, 애플리케이션 데이터 및 비즈니스 인텔리전스를 위한 표준 플랫폼이 되었습니다. 온프레미스 저장 공간의 100TB 제한으로 인해 표준 보존 기간이 약 30일로 고정되어, 팀이 KPI가 몇 달에 걸쳐 어떻게 진화했는지 확인하기가 어려웠으며 검색 가능한 레이크 외부의 별도 S3 버킷에 규정 준수 데이터를 보관할 수 밖에 없었습니다. 플래티넘에서 엔터프라이즈 로 업그레이드하고, 검색 가능한 스냅샷 과 프로즌 티어를 중심으로 재설계한 후, 표준 보존 기간은 3배 증가한 90일이 되었고, 결합된 용량은 동일한 라이선스 풋프린트에서 235 TB로 증가했으며, 하이퍼바이저 풋프린트는 18개에서 10개 물리적 노드로 감소했습니다. 전체 컷오버는 가동 중단 시간 없이 완료되었으며 데이터 손실도 없었습니다.

RTL Germany의 Elastic 데이터 레이크는 방송 및 미디어 사업 전반에 걸쳐 거의 10년 동안 축적된 회사 전체의 로깅, 애플리케이션 데이터 및 비즈니스 인텔리전스 데이터를 보유하고 있습니다. 2024년에 데이터 레이크는 한계에 도달했습니다. 대략 100TB인 온프레미스 저장 공간은 표준 보존 기간을 약 30일로 제한했지만, 여러 부서에서는 KPI가 시간에 따라 어떻게 발전했는지 추적하기 위해 수개월의 기록이 필요했고, 내부 정책에 따라 6개월의 보존 기대가 있는 규정 준수 데이터는 검색 가능한 플랫폼 외부의 별도 S3 버킷에 저장되고 있었습니다. 플래티넘에서 엔터프라이즈로 업그레이드하고 검색 가능한 스냅샷과 프로즌 계층을 중심으로 재설계한 후, RTL Germany은 표준 보존 기간을 90일까지 3배로 늘렸고 동일한 라이선스 풋프린트에서 용량이 235TB로 증가하였으며, 하이퍼바이저 풋프린트를 18개에서 10개의 물리 노드로 줄였습니다. 전체 전환은 가동 중단 시간 없이 완료되었고 데이터 손실도 전혀 없었습니다.

30일 블록은 단순히 더 긴 기록이 아니라 질문의 한 범주입니다: 분기 대 분기 비교, 연간 계절 주기, 추세선을 신뢰할 수 있게 만들 만큼 충분히 긴 기준선입니다. RTL Germany의 BI 사용자들에게는 레이크가 운영 데이터를 보유하고 있었으나, 분석적 질문이 시작되는 지점에는 미치지 못했습니다. 90일의 기록 표준과 일부 인덱스에 대해 최대 1년의 기록을 갖추어, 이제 운영 팀이 실시간으로 모니터링하는 동일한 데이터 레이크 내에서, 동일한 데이터를 다른 곳으로 내보내지 않고도 해당 질문의 범주에 답변할 수 있습니다.

해당 결과는 플랫폼의 수명 주기 동안 두 가지 뚜렷한 전환에 달려 있습니다. 2023년 기업 합병으로 두 번째 로깅 플랫폼이 도입된 후 Elastic으로 통합된 것과 이후 라이선스 업그레이드로 저장 공간 아키텍처가 재구성되어 라이선스 적용 범위를 늘리지 않고도 보존 기간을 3배로 늘릴 수 있게 된 것입니다.

RTL Germany의 Elastic 환경은 약 10년 전 공유 인프라 도구로 시작하여 팀별로 성장하여 회사 전체의 데이터 레이크로 발전했습니다. 두 가지 사건이 오늘날의 플랫폼을 형성하는 데 영향을 미쳤습니다.

첫 번째는 2023년의 합병 후 통합이었습니다. 새롭게 합류한 회사 법인이 다른 로깅 플랫폼을 운영하고 있었습니다. RTL Germany의 Elastic 환경은 이미 여유로운 용량으로 온프레미스에 있었고, 두 플랫폼을 병렬로 운영하는 것은 재정적으로도 운영적으로 타당하지 않았습니다. 레거시 로깅 도구로부터의 마이그레이션은 약 5개월 동안 진행되었으며 가장 큰 어려움은 의사소통과 수년에 걸쳐 팀이 구축한 대시보드와 알림 워크플로우를 재구축하는 것, 그리고 인제스트 파이프라인을 재작업하는 것이었습니다.

두 번째는 저장 공간 한계와 그곳에서 나가는 통로였습니다. Elastic{ON} Munich에서 검색 가능한 스냅샷과 프로즌 티어를 본 후, 팀은 저장 공간 문제에 직접 부합하는 설계를 발견했습니다. 라이선스된 공간은 유지하고, 롱테일 데이터를 S3 지원 프로즌 저장 공간으로 옮기며, 해제된 핫티어 헤드룸을 이용해 보존 기간을 연장하는 방식입니다. 실행하기 전에, 팀은 중요한 단일 질문에 초점을 맞춘 개념 증명을 구축했습니다. 프로즌 티어의 오래된 데이터에 대한 쿼리가 얼마나 빠르게 실행되느냐는 것이었습니다. 결과가 매우 빠르게 나타났기 때문에 전체 클러스터를 핫앤콜드 방식에서 핫앤프로즌 방식으로 재설계하기로 쉽게 결정을 내릴 수 있었습니다.

재설계 이전에는 RTL Germany의 표준 데이터 보존 기간은 약 30일로 제한되었으며, 온프레미스 저장 공간 용량은 100TB였습니다. 데이터 레이크는 양호한 상태였지만, 세 가지 운영상의 현실이 동시에 한계에 다다르고 있었습니다.

비즈니스 인텔리전스 요구 사항이 지난 30일을 초과했습니다. 일부 부서에서는 KPI가 시간에 따라 어떻게 변화하는지 추적하고 싶어했습니다. 30일 분량의 데이터는 데이터 레이크에서 작업을 완료하기에 부족했습니다. 팀에 운영에 필요한 데이터는 있었지만, 분석에 필요한 기간은 부족했습니다.

규정 준수 데이터가 레이크 외부에 저장되어 있었습니다. 내부 정책에서 6개월 보존 기대치를 두는 방화벽 데이터는 검색 가능한 플랫폼이 아닌 별도의 S3 버킷에 저장되었습니다. 데이터는 유지되었으나, 조사 중에 접근하려면 객체 저장소에서 데이터를 꺼내어 검색 가능한 형태로 로드해야 했습니다. 팀은 이것이 실제 사례에서 매우 번거로운 일이라고 설명하였습니다.

하드웨어가 노후화되고 있었습니다. 해당 클러스터는 대략 5~6년 된 서버에서 실행되고 있었으며, NVMe가 아닌 일반 SSD가 장착되어 있었습니다. 팀은 아키텍처가 변경되든 안 되든 하드웨어 갱신이 다가오고 있다는 것을 알고 있었습니다.

팀의 시간은 기존 플랫폼을 최대한 건강하게 유지하는 데 소요되었고, 나머지 비즈니스에 대해 플랫폼이 할 수 있는 일을 확장하는 데는 소요되지 않았습니다.

팀은 플래티넘에서 엔터프라이즈로 업그레이드하여 검색 가능한 스냅샷과 프로즌 티어를 해금한 다음, 저장 공간 레이아웃을 핫앤콜드 모델에서 S3에 의해 뒷받침되는 핫앤프로즌 모델로 재설계했습니다.

엔드 투 엔드 데이터 흐름은 이전과 동일하게 유지되었습니다. Logstash 노드는 조직 전체의 데이터 소스에서 데이터를 수집하여 Elastic에 쓰세요. 핫 인덱스는 새 클러스터의 로컬 NVMe SSD에 저장됩니다. 오래된 인덱스는 프로즌 티어로 이동하여, 그곳에서 S3에 저장되고 쿼리 시 필요에 따라 로컬 캐시로 불러옵니다. 클러스터 간 검색은 전환 과정 중에 기존 클러스터와 새 클러스터를 연결하여 사용자가 환경을 전환하지 않고도 과거 데이터에 접근할 수 있도록 했습니다.

성능 상의 절충은 관리할 수 있는 것으로 확인되었습니다. 프로즌 티어의 인덱스에 대한 첫 번째 쿼리는 관련 데이터가 프로즌 노드의 캐시에 로드되는 동안 약 30초가 소요됩니다. 그 이후에는 동일한 데이터에 대한 쿼리가 핫 티어 속도로 실행됩니다.

• 최신 데이터에 대한 핫티어 쿼리 속도: 최신 서버의 35 TB NVMe SSD가 KVM에서 실행됩니다.
• 저렴한 비용으로 수개월에서 수년간 보존: 검색 가능한 스냅샷을 통해 200TB의 S3 기반 프로즌 저장 공간이 제공됩니다.
• 동일한 라이선스 공간에서 3배 용량: 결합 시 235TB(핫 35TB 및 및 프로즌 200TB)이며 라이선스 리소스 단위가 증가하지 않았습니다.
• 더 작고 빠른 클러스터: 하이퍼바이저 점유 물리 노드 수가 18개에서 10개로 줄었으며, 노드당 코어 수가 더 많은 최신 하드웨어를 사용합니다.
• 파이프라인 재구성 없이 작업 부하별 컷오버: Logstash는 수집을 계속 처리했으며, 마이그레이션 중 데이터 소스별로 대상이 리디렉션되었습니다.
• 마이그레이션 중 과거 데이터에 대한 액세스 손실 없음: 클러스터 간 검색이 전반에 걸쳐 활성화되어 사용자는 새로운 데이터가 새 클러스터로 흐르는 동안 레거시 클러스터에서 오래된 인덱스를 계속 읽을 수 있습니다.
• 첫 번째 쿼리 이후 오래된 데이터에 대한 핫 티어 속도: 초기 쿼리에서 프로즌 티어 캐시 수화에 약 30초가 소요되며, 후속 쿼리는 핫 티어 속도로 실행됩니다.

팀은 갑작스러운 시스템 전환 대신, 기존 클러스터 옆에 새로운 클러스터를 구축하고 가장 큰 데이터 소스부터 시작하여 워크로드를 순차적으로 마이그레이션했습니다. Logstash를 통해 수집이 실행되기 때문에, 작업 부하를 옮기는 것은 종종 Logstash 노드에서 이전 클러스터의 마스터에서 새 클러스터로 대상을 변경하는 것만큼 간단했습니다. 클러스터 간 검색을 통해 사용자는 새로운 환경에서 여전히 오래된 클러스터에 있는 데이터에 읽기 액세스 권한을 유지할 수 있었기 때문에, 과거 데이터는 계속해서 접근 가능했습니다.

또한, 팀은 가능한 경우 사용자 지정 인제스트 파이프라인을 Elastic의 유지 관리 통합으로 마이그레이션하는 기회를 활용하였으며, 이것이 미래를 위해 더 나은 방향이라고 설명했습니다.

Elastic 지원은 하드웨어 출하가 지연되었을 때 중복 기간을 연장하였으며, 팀은 이것이 일정이 원활하게 진행되게 한 요소 중 하나라고 콕 집어 언급했습니다.

개념 증명 자체는 약 2주가 걸렸습니다. 6~8주에 걸친 PoC(개념 증명) 일정의 대부분은 테스트보다는 하드웨어 조달 및 준비에 소요되었습니다. 전체 시스템 전환은 약 3개월에 걸쳐 진행되었으며, 가동 중단 시간이나 데이터 손실 없이 완료되었습니다.

데이터 레이크를 매일 사용하는 부서에서는 변화가 거의 느껴지지 않았습니다. 사용자는 일시적인 중복 기간 동안 새 URL로 북마크를 지정해야 했고, 전환 후 표준 도메인으로 다시 전환해야 했습니다. 클러스터 간 검색을 통해 기존 클러스터의 역대 데이터에 계속 접근할 수 있었기 때문에, 아무도 새로운 워크플로우를 배우거나 두 시스템을 조회하여 오래된 데이터를 찾을 필요가 없었습니다.

규정 준수 측면에서, 이전에는 개별 S3 버킷에 저장되어 있던 데이터가 이제 검색 가능한 데이터 레이크 내에 저장됩니다. 6개월 방화벽 보존은 더 이상 워크플로우 문제가 아닙니다. 부서가 전체 보존 기간을 되돌아볼 필요가 있는 경우, 데이터 레이크 내 다른 항목에 대해 쿼리하는 것과 같은 방식으로 쿼리합니다.

이 프로젝트에서 몇 가지 실용적인 교훈이 두드러졌습니다.

가능한 한 관리형 통합을 사용합니다.RTL Germany는 수년간의 사용자 정의 인제스트 파이프라인을 보유하고 있었으며, 전환 과정에서 많은 부분을 Elastic이 유지 관리하는 통합으로 마이그레이션했습니다. 팀은 이것을 이 프로젝트뿐만 아니라 미래를 위한 더 나은 길이라고 설명했습니다.

마이그레이션은 새로운 단장입니다. 노후한 하드웨어를 교체하고, 아키텍처를 현대화하며, 통합을 재검토하는 동시에 단독으로 수행하는 것보다 프로젝트 가치가 배가되었습니다.

호스팅 모델을 정직하게 평가합니다. RTL Germany의 기존 리소스와 상업적 고려 사항을 고려하면 온프레미스는 합리적입니다. 내부적으로 클러스터를 구축하고 실행할 역량이 부족한 소규모 조직의 경우, 팀은 운영 오버헤드를 피하기 위해 Elastic의 SaaS 옵션을 추천합니다.

어려운 부분은 복잡성이 아니라 데이터 양입니다. 한 클러스터에서 다른 클러스터로 데이터 수집을 전환하는 것은 간단합니다. 진정한 어려움은 수많은 파이프라인과 그 간단한 변경 사항을 거쳐야 했던 방대한 데이터 양에 있었습니다.

두 가지 결과가 다음 단계를 결정짓습니다. 첫째: Elastic AI 에이전트를 RTL Germany의 내부 대규모 언어 모델(LLM)에 연결하여 새 팀 구성원이 올바른 데이터 뷰를 찾는 데 걸리는 시간을 단축합니다. 이를 통해 새로운 팀원들이 플랫폼을 탐색하고 올바른 데이터 뷰를 더 빠르게 찾을 수 있습니다. 이는 역사적으로 온보딩 단계 중 더 어려운 부분 중 하나였습니다.

두 번째: 라이선스 풋프린트를 다시 거치지 않고도 데이터 레이크에 더 많은 애플리케이션 로그를 흡수할 수 있습니다. 이것은 모든 애플리케이션의 더 많은 애플리케이션 로그를 데이터 레이크에 적재하는 내부 프로그램입니다. 새 아키텍처는 이러한 성장을 염두에 두고 의도적으로 설계되었습니다. S3 지원 용량이 200TB이고 스토리지를 쉽게 확장할 수 있기 때문에 팀은 라이선스 풋프린트를 다시 검토하지 않고도 용량을 흡수할 수 있습니다.

귀사에서 현재 방송 및 미디어 사업 전체를 아우르는 10년 된 데이터 레이크를 운영하고 있지 않을 수 있으나, 몇 테라바이트의 로그 데이터로 시작하든 235TB 규모의 핫앤프로즌 아키텍처로 확장하든 동일한 원칙이 적용됩니다. 즉, 라이선스 사용량은 보존 기간에 따라 증가할 필요가 없습니다.

RTL Germany는 독일 최대의 방송 및 미디어 회사인 RTL 그룹에 속해 있으며, 텔레비전, 스트리밍, 콘텐츠 제작을 망라한 사업을 운영하고 있습니다.

Elastic Observability의 프로즌 티어가 비용 증가 없이 유지 기간을 연장한 방법을 확인해 보세요. 지금 무료 체험을 시작할 수도 있습니다.

• Elastic Observability
• 로그 모니터링
• Elasticsearch
• Logstash
• 데이터 통합
• Observability Labs
• Elastic 설명서

주제: Elastic Observability, Elasticsearch, Logstash, 프로즌 티어, 검색 가능한 스냅샷, 계층형 저장 공간, 클러스터 간 검색, 로그 분석, 데이터 레이크, 규정 준수 데이터 보존, 미디어 및 방송, 미디어 및 엔터테인먼트