지체에서 민첩성으로: Freshworks의 데이터 수집 아키텍처 재창조

고객과 직원의 경험을 향상시키는 직관적이고 AI 기반의 비즈니스 솔루션을 제공하는 글로벌 소프트웨어 서비스(SaaS) 회사입니다. Freshworks는 실시간 데이터를 활용하여 의사결정을 내리고 75,000 이상의 고객들에게 더 좋은 경험을 제공하는 데 의존합니다. 제품 간 일일 이벤트가 수백만 개에 이르러 방시간 데이터 처리가 중요하게 됩니다. 이런 필요성을 충족하기 위해 Freshworks는 Databricks 위에 실시간 수집 파이프라인을 구축하였고, 이 파이프라인은 다양한 스키마를 제품 간에 관리하고 분당 수백만 건의 이벤트를 처리하는 데 있어 30분 안에 이뤄지는 서비스 수준 계약(SLA)을 유지하면서 다중 세입자 환경에서 세입자 수준의 데이터 격리를 보장할 수 있습니다.

이를 달성하기 위해 강력하고 유연하며 최적화된 데이터 파이프 라인을 구축하려 했습니다.

레거시 아키텍처와 변화를 위한 케이스

Freshworks의 기존 파이프라인은 Python 소비자로 구축되었습니다; 여기서 각 사용자의 액션은 실시간으로 제품에서 Kafka로 이벤트를 전송하며, 이 Python 소비자들은 이런 이벤트를 변환하고 새로운 Kafka 주제로 라우팅합니다. 그 뒤에 Rails 배치 시스템은 이런 변환된 데이터를 AWS S3에 저장된 CSV 파일로 변환하고, Apache Airflow 작업은 이런 배치 데이터를 데이터 웨어하우스로 로드합니다. 수집 후에는 중간 파일이 삭제되어 저장 공간이 관리됩니다. 이런 아키텍처 구조는 초기 성장에 적합했으나, 이벤트 볼륨이 급증하면서 한계에 부딪혔습니다.

급속한 성장은 핵심 과제들을 드러냈습니다:

• 확장성: 파이프라인은 특히 피크 시간에 분당 수백만 건의 메시지를 처리하는 데 어려움을 겪었고, 수동적인 확장이 자주 필요했습니다.
• 운영 복잡성: 다단계 프로세스는 스키마 변경과 유지 보수를 위험하고 시간이 많이 소요되게 만들어, 종종 불일치와 실패를 초래했습니다.
• 비용 비효율성: 저장 및 계산 비용이 불필요한 처리와 최적화 부족으로 인해 빠르게 증가했습니다.
• 응답성: 레거시 설정은 Freshworks의 확장에 맞춰 실시간 수집이나 빠르고 신뢰할 수 있는 분석을 요구할 수 없었습니다. 지연된 데이터 수집은 데이터 신선도를 손상시키고 고객 인사이트에 영향을 미쳤습니다.

규모와 복잡성이 증가함에 따라, 기존 시스템의 취약성과 오버헤드는 비즈니스 성장과 분석 요구를 지원하기 위한 통합적이고 확장 가능하며 자율적인 데이터 아키텍처의 필요성을 명확하게 드러냈습니다.

새로운 아키텍처: Apache Spark 및 Delta Lake을 이용한 실시간 데이터 처리

솔루션 - Spark 구조화된 스트리밍 과 Delta Lake를 중심으로 한 근본적인 재설계는 거의 실시간 처리, 확장가능한 변환, 그리고 운영의 단순성에 초점을 맞추었습니다.

우리는 Spark 구조화된 스트리밍이 Kafka에서 직접 데이터를 소비하고, 이 데이터를 변환한 후 Delta Lake에 기록하는 하나의 아키텍처를 설계했습니다 - 이 모든 과정이 하나의 작업에서 Databricks 내부에서 실행됩니다.

이런 변화로 데이터 이동이 줄어들고, 유지 보수와 문제 해결이 단순화되며, 인사이트 도달 시간이 가속화되었습니다.

새로운 아키텍처의 핵심 구성 요소:

스트리밍 구성 요소 : Spark 구조화된 스트리밍

Kafka에서 들어오는 각 이벤트는 Spark 스트리밍에서 정확도, 규모, 비용 효율성을 최적화한 일련의 변환 단계를 신중하게 진행합니다:

1. 효율적인 중복 제거:
   UUID로 식별된 이벤트는 스트리밍 배치 간의 중복을 필터링하기 위해 이전에 처리된 UUID의 델타 테이블과 대조됩니다.
2. 데이터 유효성 검사:
   스키마와 비즈니스 규칙은 필요한 필드를 보장하고 null 값을 처리하는 데 있어 잘못된 레코드를 필터링합니다.
3. JSON-e를 사용한 맞춤 변환:
   JSON-e 엔진을 통해 조건문, 반복문, Python UDF 등 고급된, 재사용 가능한 로직을 구현하며, 제품 팀이 각 제품에 맞는 동적이고 재사용 가능한 로직을 정의할 수 있습니다.
4. 플랫형으로 변환:
   변환된 JSON 이벤트는 수천 개의 구조화된 테이블로 플랫하게 만들어집니다. 별도의 내부 스키마 관리 도구(2만개 이상의 테이블과 500만개 이상의 칼럼 관리)를 통해 제품 팀은 스키마 변경을 관리하고, 자동으로 프로덕션에 적용하여 델타 레이크에 등록되고, Spark 스트리밍에 원활하게 반영됩니다.
5. 플랫 데이터 중복 제거:
   저장된 칼럼의 해시가 Redis에서 처리된 지난 4시간의 데이터와 비교되어, 중복 수집을 막고 계산 비용을 줄입니다.

저장 구성요소: 레이크하우스

변환된 후에, 이 데이터는 몇 가지 강력한 최적화를 활용하여 직접 Delta Lake 테이블 에 기록됩니다:

• 멀티프로세싱에 따른 병렬 쓰기:
  하나의 Spark 작업은 일반적으로 약 250개의 Delta 테이블에 기록하며, 다양한 변환 로직을 적용합니다. 이것은 Python 멀티프로세싱을 사용하여 실행되며, 클러스터의 이용 효율을 극대화하고 지연 시간을 줄이기 위해 Delta 병합을 병렬로 수행합니다.
• 삭제 벡터를 통한 효율적인 업데이트:
  배치당 레코드의 최대 35%가 업데이트 또는 삭제입니다. 대용량 파일을 다시 작성하는 대신, 우리는 삭제 벡터를 활용하여 연기 삭제를 활성화합니다. 이로 인해 업데이트 성능이 3배 향상되어 테라바이트 규모에서 실시간 업데이트가 실용적이게 됩니다.
• 디스크 캐싱을 통한 가속화된 병합:
  디스크 캐싱은 자주 접근되는 (핫) 데이터가 메모리에 남아 있도록 보장합니다. 병합에 필요한 열만 캐싱함으로써, 우리는 I/O와 컴퓨팅 비용을 줄이면서 최대 4배 빠른 병합 작업을 달성합니다. 오늘날, 병합 읽기의 95%가 캐시에서 직접 제공됩니다.

실시간 조정 & 적응

자동 조정은 파이프 라인에 내장되어 있어, 시스템이 동적으로 크기를 조절하여 볼륨과 비용을 가장 효율적으로 처리할 수 있도록 보장하면서 성능에 영향을 주지 않습니다.

스케일링은 배치 지연과 실행 시간에 의해 주도되며, 실시간으로 모니터링됩니다. Resizing은 Spark의 QueryListener (각 배치 후의 OnProgress 방법)를 통해 작업 API를 통해 트리거되어, 처리 중인 작업이 방해받지 않게 합니다. 이렇게 하면 시스템은 수동 개입 없이 반응적이고 탄력적이며 효율적입니다.

내장된 탄력성: 실패를 세련되게 처리하기

데이터 무결성 및 가용성을 유지하기 위해, 이 아키텍처는 견고한 장애 복구를 포함합니다:

• 변환이 실패한 이벤트는 Kafka를 통해 백오프 로직으로 재시도 됩니다.
• 영구적으로 실패한 레코드는 데이터 손실 없이 오프라인 검토 및 재처리를 위해 Delta 테이블에 저장됩니다.
• 이 디자인은 피크 시간이나 스키마 변경 중에도 사람이 개입하지 않아도 데이터 무결성을 보장하고, 실패한 데이터를 나중에 재게시할 수 있는 능력을 제공합니다.

각 단계에서의 관찰 가능성과 모니터링

강력한 모니터링 스택—Prometheus, Grafana, 그리고 Elasticsearch로 구축된—이 Databricks와 통합되어 우리에게 종단 간 가시성을 제공합니다:

• 메트릭 수집:
  Databricks에서의 모든 배치에서는 중요한 메트릭들 - 입력 레코드 수, 변환된 레코드, 오류율 등을 로깅하며, 이는 Prometheus에 통합되어 실시간으로 지원팀에 알람을 전달합니다.
• 이벤트 추적:
  이벤트 상태는 Elasticsearch에 로그가 남아 있어, 세밀한 디버깅을 가능케 하며 제품(생산자) 팀과 분석(소비자) 팀이 문제를 추적할 수 있습니다.

변환 & 배치 실행 메트릭:

위의 메트릭을 사용하여 변환 건강 상태를 추적하고, 문제를 식별하며, 신속한 조사를 위한 알림을 트리거하세요.

복잡성에서 신뢰성으로

아마도 가장 크게 변화한 것은 단순성입니다.

한때는 다섯 시스템과 수많은 통합 포인트가 포함되었던 것이 Databricks 내에서 완전히 작동하는 단일, 관찰 가능, 자동 조정 파이프라인 으로 바뀌었습니다. 우리는 불안정한 의존성을 제거하고, 작업을 간소화하고, 팀이 더 빠르게 그리고 더 큰 자율성으로 작업할 수 있게 했습니다.본질적으로 움직이는 부분이 줄어들면서 놀람이 줄어들고 신뢰도가 상승하였습니다.

스트리밍과 Deltalake을 중심으로 데이터 스택을 상상해 보면, 우리는 오늘날의 규모뿐만 아니라 내일의 성장에 대응할 수 있는 시스템을 구축하였습니다.

Databricks를 선택해야 하는 이유

데이터 아키텍처를 재상상하면서 우리는 몇 가지 기술을 평가하였는데, 이 가운데에는 Amazon EMR의 Spark, Apache Flink, 그리고 Databricks 등이 있었습니다. 철저한 벤치마킹 후에, Databricks가 가장 적합한 선택으로 부상하였는데, 이는 성능, 단순성, 그리고 Freshworks의 발전하는 요구 사항을 충족시켜 줄 수 있는 생태계 조정의 독특한 혼합을 제공하기 때문입니다.

데이터 처리를 위한 통합된 생태계

여러 도구를 결합하는 대신, Databricks는 작업 조정, 데이터 거버넌스, 그리고 CI/CD 통합, 을 포괄하는 종단 간 플랫폼을 제공하여 복잡성을 줄이고 개발을 가속화합니다.

• Unity Catalog 는 데이터 거버넌스에 대한 신뢰할 수 있는 단일 원천입니다. 세분화된 접근 제어, 계보 추적, 중앙화된 스키마 관리를 통해, 이 도구는
  • 우리의 팀은 모든 데이터 자산을 안전하게 보호하고, 각 세입자에게 철저한 접근 경계를 유지하면서 잘 구성된 데이터 접근을 허용할 수 있게 만들었습니다.
  • 모든 이벤트와 행동이 감사 테이블에 감사되어야하며, 누가 어떤 자산에 액세스할 수 있는지에 대한 정보와 함께 규제 요구 사항을 준수하세요.
• Databricks 잡 은 내장된 오케스트레이션을 가지고 있고, Airflow와 같은 외부 오케스트레이터에 대한 의존성을 대체하였습니다. 기본적인 일정 관리와 파이프 라인 실행은 운영적인 마찰을 줄이고 신뢰성을 향상시켰습니다.
• CI/CD와 REST APIs 를 통해 Freshworks 팀들은 모든 것을 자동화하였습니다 - 작업 생성, 클러스터 스케일링, 스키마 업데이트 등입니다. 이런 자동화는 릴리즈를 가속화시키고, 일관성을 향상시키고, 수동적인 오류를 최소화하여, 빠르게 실험을 해보고 학습할 수 있도록 하였습니다.

최적화된 Spark 플랫폼

• 수백만 건의 레코드를 처리할 수 있는 자동 리소스 할당, 통합 배치 & 스트리밍 아키텍처, 실행기 결함 복구, 그리고 동적 스케일링과 같은 주요 기능은 우리가 교통칠 때나 인프라 장애 시에도 일관된 처리량을 유지할 수 있도록 도와주었습니다.

고성능 캐싱

• Databricks 디스크 캐싱은 필요한 데이터 지연 시간을 충족하는 데 핵심 요소였으며, 대부분의 병합들이 디스크 캐시에 저장된 핫 데이터에서 제공되었습니다.
• 그것의 능력은 자동으로 underlying data 파일에서 변경 사항을 감지하고 캐시를 최신 상태로 유지하게 함으로써, 배치 처리 간격이 계속해서 필요한 SLA를 충족하는 데 필요했습니다.

Delta Lake: 실시간 및 신뢰성 있는 수집을 위한 기초

Delta Lake은 파이프라인에서 중요한 역할을 하며, 대규모에서 지연 시간이 짧은 ACID 준수, 고무질적인 데이터 처리를 가능하게 합니다.

그래서, Databricks Spark의 속도, Delta Lake의 안정성, 그리고 Databricks의 통합 플랫폼을 결합함으로써, Freshworks의 실시간 분석을 위한 확장성 있는, 견고하고, 비용 효율적인 미래 준비 기반이 만들어졌습니다.

배운 점: 주요 통찰

변환은 그것의 도전 없이 이루어지지 않습니다. 그동안 우리는 몇 가지 놀라운 점들을 경험하며 귀중한 교훈들을 배웠습니다:

1. 상태 저장소 오버헤드: 높은 메모리 사용량과 안정성 문제

Spark의 dropDuplicatesWithinWatermark 사용은 높은 메모리 사용과 특히 자동 스케일링 도중에 불안정성을 초래하고, 작은 파일들 때문에 S3 리스트 비용이 증가하였습니다.

해결: 중복 제거를 위해 Delta 기반 캐싱으로 전환하면서 메모리 효율성과 안정성이 크게 향상됐습니다. 전체 S3 목록 비용과 메모리 사용량이 크게 줄어들어서, 데이터 중복 제거의 시간과 비용을 줄일 수 있었습니다.

2. 액체 클러스터링: 공통적인 도전 사항들

다수의 칼럼에 클러스터링하면 데이터 분포가 듬성듬성해져 데이터 스캔이 늘어나고 쿼리 성능이 저하됩니다.

쿼리에는 여러 차차로 조건이 있는 기본 조건이 있었고; 여러 열에 클러스터링하면 기본 조건 열에 데이터가 흩어지게 되었습니다.

해결: 단일 주요 열에 클러스터링을 하는 것은 더 나은 파일 조직화를 이끌어내고, 데이터 스캔을 최적화함으로써 쿼리를 더 빠르게 만들었습니다.

3. 가비지 컬렉션(GC) 문제: 작업 재시작 필요

장기 실행 작업(7일 이상)은 성능이 느려지고 가비지 컬렉션 주기가 더 자주 일어나게 됩니다.

해결: 우리는 지속적인 GC 주기와 성능 저하를 완화하기 위해 주간 작업 재시작을 도입해야 했습니다.

4. 데이터 왜곡: Kafka Topic 불균형 처리하기

서로 다른 Kafka 주제별로 데이터량이 불균형하게 변동하는 것을 관찰되었습니다. 이로 인해 처리 노드 간에 불균형한 데이터 분포를 초래하여 작업 부하가 왜곡되고 리소스 이용이 비균등하게 되었습니다.

해결: 변환 전에 다시 파티션하면 데이터 분포가 고르고 균형이 맞게 되어 데이터 처리 부하를 균형화하고 처리량을 향상시킵니다.

5. 조건별 병합: 병합 성능 최적화하기

필요한 컬럼이 몇 개뿐이라도, 병합 작업은 대상 테이블에서 모든 컬럼을 로드하였고, 이로 인해 병합 시간과 I/O 비용이 높았습니다.

해결: 우리는 병합 전에 안티조인을 구현했고, 늦게 도착하거나 관련 없는 레코드를 조기에 폐기하여, 불필요한 데이터가 로드되지 않도록 함으로써 병합 속도를 크게 향상시켰습니다.

결론

Databricks와 Delta Lake를 사용하여 Freshworks는 데이터 아키텍처를 재정의하였습니다 - 파편화되고 수동적인 작업흐름에서 현대적이고 통합된 실시간 플랫폼으로 이동하였습니다.

이는

• 트래픽이 급증할 때 데이터 동기화 시간이 4배 개선되었습니다.
• ~25%의 비용 절감은 확장 가능하고 비용 효율적인 연산으로 인한 것이며, 이는 다운타임이 없습니다.
• 유지 보수 노력 50% 감소
• 피크 로드 시에도 고가용성과 SLA 준수 성능을 보장합니다.
• 실시간 인사이트를 통한 고객 경험 향상

이러한 변화는 Freshworks의 모든 고객이 IT부터 지원까지, 비즈니스 요구들을 지원하고 처리하는 데이터의 크기에 대해 걱정하지 않고 더 빠르게 데이터 기반의 결정을 내릴 수 있도록 지원합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)