UiPath가 Databricks에서 확장 가능한 실시간 ETL 파이프라인을 구축하는 방법

실시간 에이전트 자동화의 약속을 이행하려면 빠르고 신뢰할 수 있으며 확장 가능한 데이터 기반을 필요로 합니다. UiPath에서는 Maestro 와 Insights와 같은 제품을 지원하기 위해 현대적인 스트리밍 아키텍처가 필요했습니다. 이를 통해 에이전트 자동화 메트릭이 펼쳐지는 대로 실시간 가시성을 제공할 수 있습니다. 이 과정에서 우리는 Azure Databricks에서 Apache Spark™ 구조화된 스트리밍을 사용하여 배치와 스트리밍을 통합하게 되었습니다. 이를 통해 비용 효율적이고 낮은 지연 시간의 분석을 가능하게 하여 기업 전체에서 에이전트 결정을 지원합니다.

이 블로그는 이러한 개선 사항의 기술적 접근법, 타협 사항, 그리고 영향에 대해 자세히 설명합니다.

스트리밍이 UiPath Maestro와 UiPath Insights에게 중요한 이유

UiPath에서는 Maestro 와 Insights 와 같은 제품들이 시의 적절한 신뢰할 수 있는 데이터에 크게 의존합니다. Maestro는 우리의 에이전트 자동화 플랫폼을 위한 오케스트레이션 계층으로 작동하며, 실시간 이벤트를 기반으로 AI 에이전트, 로봇, 그리고 사람들을 조정합니다. 시스템 트리거에 반응하거나, 장기 실행 워크플로우를 실행하거나, 인간이 참여하는 단계를 포함하는 것이든, Maestro는 빠르고 정확한 신호 처리에 의존하여 올바른 결정을 내립니다.

UiPath Insights는 이러한 자동화를 모니터링하고 분석하는 데 힘을 실어주며, 주요 지표와 행동 신호를 거의 실시간으로 캡처하여 추세를 파악하고 ROI를 계산하며 이슈 탐지를 지원하는 또 다른 수요 계층을 추가합니다.

이러한 종류의 결과 - 반응적인 오케스트레이션과 실시간 관찰 가능성 - 을 제공하려면, 단지 지연 시간이 짧은 것뿐만 아니라 확장 가능하고, 신뢰할 수 있고, 유지 관리가 가능한 데이터 파이프라인 아키텍처가 필요합니다. 이러한 필요성이 우리가 Azure Databricks에서의 스트리밍 아키텍처를 재고하게 된 원인입니다.

스트리밍 데이터 기반 구축

강력한 분석과 실시간 모니터링의 약속을 이행하려면 확장 가능하고 신뢰할 수 있는 데이터 파이프라인의 기반이 필요합니다. 지난 몇 년 동안, 우리는 새로운 제품 기능을 지원하고 변화하는 비즈니스 요구 사항에 대응하기 위해 여러 파이프라인을 개발하고 확장했습니다. 이제 우리는 이 파이프라인을 최적화하여 비용을 절약하고, 더 나은 확장성을 가지며, 새로운 서비스인 Maestro와 같은 데이터를 지원하기 위한 최소 한 번의 배송 보장을 얻을 수 있는 기회를 평가할 수 있습니다.

이전의 설정(위에 표시된)은 고객에게 잘 작동했지만, 개선이 필요한 영역도 드러났습니다.

1. 배치 파이프라인은 최대 30분의 지연 시간을 도입하고 복잡한 인프라에 의존했습니다
2. 실시간 파이프라인은 더 빠른 데이터를 제공했지만 비용이 더 높았습니다.
3. Robotlogs, 우리의 가장 큰 데이터셋에 대해, 우리는 역사적이고 실시간 처리를 위한 별도의 수집 및 저장 경로를 유지하였고, 이로 인해 중복성과 비효율성이 발생하였습니다.
4. 새로운 UiPath 제품인 UiPath Maestro의 새로운 ETL 파이프라인을 지원하기 위해서는 적어도 한 번의 전달 보장을 달성해야 합니다.

이러한 도전을 해결하기 위해, 우리는 주요한 아키텍처 개편을 진행했습니다. 우리는 Robotlogs의 배치 및 실시간 수집 프로세스를 하나의 파이프라인으로 통합하고, 실시간 수집 파이프라인을 더욱 비용 효율적이고 확장 가능하게 재구성했습니다.

왜 Spark 구조화된 스트리밍을 Databricks에서 사용하는가?

우리가 파이프라인 아키텍처를 단순화하고 현대화하기 위해 나설 때, 우리는 고처리량 배치 작업과 저지연 실시간 데이터를 모두 처리할 수 있는 프레임워크가 필요했습니다—운영 오버헤드를 도입하지 않으면서. Azure Databricks에서의 Spark 구조화된 스트리밍(SSS)은 자연스러운 선택이었습니다.

Spark SQL과 Spark Core 위에 구축된 구조화된 스트리밍은 실시간 데이터를 무제한 테이블로 처리하여, 익숙한 Spark 배치 구조를 재사용하면서도 내결함성이 있고 확장 가능한 스트리밍 엔진의 이점을 얻을 수 있게 해줍니다. 이 통합 프로그래밍 모델은 복잡성을 줄이고 개발을 가속화했습니다.

우리는 이미 Spark 구조화된 스트리밍을 활용하여 Databricks에서 상태 유지 스트림 처리를 활용하는 실시간 알림 기능을 개발했습니다. 이제 우리는 다음 세대의 실시간 수집 파이프라인을 구축하기 위해 그 기능을 확장하고 있습니다. 이를 통해 저 지연, 확장성, 비용 효율성, 그리고 적어도 한 번의 전달 보장을 달성할 수 있습니다.

실시간 수집의 다음 세대

아래에 표시된 새로운 아키텍처는 이전에 별도로 존재하던 컴포넌트를 통합하여 Databricks에서 Spark 구조화된 스트리밍을 사용하는 통합, 확장 가능한 파이프라인으로 데이터 수집 과정을 대폭 단순화합니다:

이 새로운 설계의 핵심은 이벤트 소스에서 직접 읽는 스트리밍 작업 세트입니다. 이 작업들은 파싱, 필터링, 평탄화를 수행하고, 가장 중요하게는 각 이벤트를 참조 데이터와 결합하여 데이터 웨어하우스에 쓰기 전에 이를 풍부하게 만듭니다.

우리는 이러한 작업을 Databricks Lakeflow Jobs를 사용하여 조정하며, 이는 일시적인 실패의 경우 재시도 및 작업 복구를 관리하는 데 도움이 됩니다. 이 간소화된 설정은 개발자의 생산성과 시스템의 신뢰성을 모두 향상시킵니다.

이 새로운 아키텍처의 이점은 다음과 같습니다:

• 비용 효율성: 인프라 복잡성과 컴퓨팅 사용량을 줄여 COGS를 절약합니다
• 낮은 지연 시간: 수집 지연 시간은 평균적으로 약 1분이며, 이를 더 줄일 수 있는 유연성이 있습니다
• 미래를 대비한 확장성: 처리량은 코어 수에 비례하며, 우리는 무한히 확장할 수 있습니다
• 데이터 손실 없음: Spark는 실패 복구를 담당하여 적어도 한 번 전달을 지원합니다.
  • 미래 개발에서 하류 싱크 중복 제거를 통해, 정확히 한 번 의 전달을 달성할 수 있을 것입니다.
• Spark DataFrame API덕분에빠른 개발 주기
• 단순하고 통합된 아키텍처

저 지연

현재 우리의 스트리밍 작업은 1분 간격의 마이크로 배치 모드에서 실행됩니다. 이는 이벤트가 우리의 이벤트 버스에 게시되는 순간부터 일반적으로 데이터 웨어하우스에 27초 정도로 도착하며, 레코드의 95%는 51초 이내에, 99%는 72초이내에 도착한다는 것을 의미합니다.

구조화된 스트리밍은 구성 가능한 트리거 설정을 제공하여 지연 시간을 몇 초로 줄일 수 있습니다. 지금은 비용과 성능 사이의 적절한 균형을 찾기 위해 1분 간격의 트리거를 선택했으며, 요구 사항이 변경되는 경우에는 이를 더 낮출 수 있는 유연성이 있습니다.

확장성

Spark는 큰 데이터 작업을 파티션으로 나누어 Worker/Executor CPU 코어를 최대한 활용합니다. 각 구조화된 스트리밍 작업은 단계로 나뉘며, 이들은 더욱 작은 작업으로 나뉘어, 각각이 단일 코어에서 실행됩니다. 이런 수준의 병렬화는 우리가 Spark 클러스터를 완전히 활용하고 데이터 볼륨이 증가함에 따라 효율적으로 확장할 수 있게 해줍니다.

메모리 내 처리, Catalyst 쿼리 계획, 전체 단계 코드 생성, 벡터화된 실행과 같은 최적화 덕분에, 우리는 확장성 검증에서 초당 약 40,000개의 이벤트를 처리합니다. 트래픽이 증가하면, 소스 이벤트 버스의 파티션 수를 증가시키고 더 많은 작업 노드를 추가함으로써 단순히 확장할 수 있습니다—최소한의 엔지니어링 노력으로 미래의 확장성을 보장합니다.

전달 보장

Spark 구조화된 스트리밍은 체크포인팅 시스템 덕분에 기본적으로 정확한 한 번의 전달을 제공합니다. 각 마이크로 배치 후, Spark는 각 소스 파티션의 진행 상황(또는 "epoch")을 write-ahead 로그로, 그리고 작업의 애플리케이션 상태를 상태 저장소에 유지합니다. 실패 시, 작업은 마지막 체크포인트에서 재개되어 데이터가 손실되거나 건너뛰어지지 않습니다.

이는 원래의 Spark 구조화된 스트리밍 연구 논문에서 언급되었으며, 정확한 전달을 달성하려면 다음이 필요하다고 명시하고 있습니다.

1. 입력 소스는 재생 가능해야 합니다
2. 멱등성 쓰기를 지원하는 출력 싱크

하지만 종종 언급되지 않는 세 번째 요구 사항도 있습니다: 시스템은 실패를 감지하고 우아하게 처리할 수 있어야 합니다.

이는 Spark가 잘 작동하는 곳입니다—그것의 강력한 실패 복구 메커니즘은 작업 실패, 실행기 충돌, 드라이버 문제를 감지하고, 재시도나 재시작과 같은 자동 수정 조치를 취할 수 있습니다.

현재 우리는 아직 출력 싱크가 멱등성을 가지지 않기 때문에 적어도 한 번의 전달로 운영하고 있음을 유의하십시오. 만약 우리가 미래에 정확히 한 번의 전달에 대한 추가 요구 사항이 있다면, 우리가 멱등성에 대한 추가 엔지니어링 노력을 기울인다면, 우리는 그것을 달성할 수 있어야 합니다.

원시 데이터가 더 좋습니다

우리는 또한 다른 몇 가지 개선 사항을 도입했습니다. 이제 우리는 모든 테이블에 공통 rawMessage 필드를 포함하고 유지하였습니다. 이 열은 원래의 이벤트 페이로드를 원시 문자열로 저장합니다. 스시 원칙을 인용하자면(비록 우리가 여기서는 약간 다른 의미를 가지고 있지만): 원시 데이터가 더 좋습니다.

원시 데이터는 문제 해결을 크게 단순화합니다. 무언가 잘못되었을 때-예를 들어 필드가 누락되거나 예상치 못한 값이 있을 때-우리는 원래의 메시지를 즉시 참조하고 문제를 추적할 수 있습니다. 로그나 상위 시스템을 찾아다닐 필요가 없습니다. 이 원시 페이로드 없이는 데이터 문제를 진단하는 것이 훨씬 더 어렵고 느려집니다.

단점은 저장 공간이 약간 증가하는 것입니다. 하지만 저렴한 클라우드 저장소와 우리의 웨어하우스의 컬럼 형식 덕분에, 이것은 최소한의 비용을 발생시키며 쿼리 성능에는 영향을 미치지 않습니다.

간단하고 강력한 API

새로운 구현은 개발 시간을 줄여줍니다. 이는 대부분 Spark의 DataFrame API 덕분입니다. 이 API는 분산 데이터 처리에 대한 고수준의 선언적 추상화를 제공합니다. 과거에는 RDD를 사용하면 실행 계획에 대해 수동으로 추론하고, DAG를 이해하고, 조인과 필터와 같은 연산의 순서를 최적화해야 했습니다. DataFrames는 우리가 계산하고자 하는 로직에 집중할 수 있게 해주며, 어떻게 계산할지에 대해서는 신경 쓸 필요가 없습니다. 이는 개발 과정을 크게 단순화합니다.

이는 또한 운영을 개선하였습니다. 우리는 더 이상 수동으로 실패한 작업을 다시 실행하거나 여러 파이프라인 구성 요소에서 오류를 추적할 필요가 없습니다. 간소화된 아키텍처와 더 적은 이동 부품으로 개발과 디버깅이 훨씬 쉬워집니다.

UiPath에서 실시간 분석을 주도

이 새로운 아키텍처의 성공은 눈에 띄지 않을 수 없습니다. 이것은 빠르게 UiPath에서 실시간 이벤트 수집의 새로운 표준이 되었습니다. UiPath Maestro와 Insights에 대한 초기 구현을 넘어서, 이 패턴은 실시간 분석 요구 사항을 위해 여러 새로운 팀과 프로젝트에서 널리 채택되었습니다. 이에는 최첨단 이니셔티브를 진행 중인 팀들도 포함됩니다. 이 널리 채택된 것은 아키텍처의 확장성, 효율성, 확장 가능성에 대한 증거로, 새로운 팀이 쉽게 참여할 수 있게 하고, 강력한 실시간 분석 기능을 가진 새로운 세대의 제품을 가능하게 합니다.

만약 운영 부담 없이 실시간 분석 작업 부하를 확장하려고 한다면, 여기에 개요가 제시된 아키텍처는 Databricks와 Spark 구조화된 스트리밍에 의해 구동되며, AI와 대리 시스템의 다음 세대를 지원할 준비가 되어 있습니다.

UiPath에 대하여
UiPath (NYSE: PATH)는 에이전트 자동화 분야의 글로벌 리더로, 기업이 AI 에이전트의 전체 잠재력을 활용하여 복잡한 비즈니스 프로세스를 자동으로 실행하고 최적화할 수 있게 합니다. UiPath Platform™은 통제된 에이전시, 개발자 유연성, 그리고 원활한 통합을 독특하게 결합하여, 기관이 에이전트 자동화를 안전하고 확신을 가지고 확장할 수 있도록 돕습니다. 보안, 거버넌스, 상호 운용성에 대한 약속을 통해 UiPath는 자동화가 AI의 전체 잠재력을 발휘하여 산업을 변혁하는 미래로의 전환을 지원합니다.

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