[Paper] Spark-on-AWS-Lambda에서 Silent Data Loss 특성화 및 해결, Open Table Formats와 함께

발행: (2026년 4월 22일 AM 09:57 GMT+9)
9 분 소요
원문: arXiv

Source: arXiv - 2604.20081v1

개요

최근 연구에서는 Spark‑on‑AWS‑Lambda (SoAL)에서 숨겨진 신뢰성 버그를 발견했으며, 이는 경고 없이 데이터를 조용히 삭제할 수 있습니다. 데이터 업로드 단계 직후, 메타데이터 커밋 단계 이전에 AWS가 Lambda 컨테이너를 (잡을 수 없는 SIGKILL)으로 종료하면, 고아 Parquet 파일이 S3에 남아있고 테이블의 카탈로그는 변경되지 않습니다. 저자들은 이 “조용한 데이터 손실”이 Delta Lake와 Apache Iceberg에서 얼마나 자주 발생하는지 정량화했을 뿐만 아니라, 깨끗한 롤백과 감사 추적을 보장하는 가벼운 해결책 SafeWriter를 제공했습니다.

주요 기여

  • 버그 특성화: 세 가지 데이터셋 크기에 걸친 860개의 킬‑인젝션 실험에 대한 실증 분석으로, SIGKILL이 인터‑페이스 간격에 도달할 때 100 % 무음 손실률을 보임.
  • 크로스‑포맷 영향: S3에서 가장 많이 사용되는 두 개의 오픈‑테이블 포맷인 Delta Lake와 Apache Iceberg 모두에 대한 취약성을 입증함.
  • SafeWriter 프로토타입: Lambda 타임아웃 30 초 전에 워치독 스레드를 생성하고, SQL을 통해 포맷 고유 롤백을 트리거하며, S3에 체크포인트 문서를 기록하는 언어‑수준 래퍼.
  • 최소 오버헤드: 최악의 킬 시나리오에서도 SafeWriter는 일반 쓰기 지연에 < 100 ms만 추가함.
  • 운영 가시성: 체크포인트 문서는 다운스트림 모니터링 도구가 롤백을 자동으로 감지하고 알림을 보낼 수 있게 함.

방법론

  1. Controlled kill injection: 저자들은 SoAL 작업에 계측을 추가하여 쓰기 파이프라인 중 임의의 순간에 SIGKILL을 의도적으로 전송하도록 했습니다.
  2. Three data scales: 작은(≈ 10 GB), 중간(≈ 100 GB), 큰(≈ 1 TB) Parquet 워크로드를 사용해 문제가 크기에 의존하지 않음을 검증했습니다.
  3. Two table formats: Delta Lake와 Apache Iceberg 각각에 대해 별도의 테스트 스위트를 실행했으며, 각 포맷의 고유 커밋 프로토콜을 사용했습니다.
  4. SafeWriter integration: 래퍼를 Spark 드라이버 코드에 추가했습니다. 워치독 스레드는 남은 Lambda 실행 시간을 모니터링하고, 남은 시간이 30 초 이내이면 사전에 ROLLBACK(Delta) 또는 DROP SNAPSHOT(Iceberg)을 발행하고 지정된 S3 프리픽스에 JSON 체크포인트를 기록합니다.
  5. Metrics collection: 각 실험에 대해 성공/실패 비율, 지연 오버헤드, S3에 남은 고아 파일 수를 기록했습니다.

결과 및 발견

시나리오SafeWriter 없이 무음 데이터 손실SafeWriter 사용 시 성공적인 롤백평균 추가 지연
인터‑페이즈 간격 중 SIGKILL (Delta)100 % (전체 860 회)100 % (전체 회)78 ms
인터‑페이즈 간격 중 SIGKILL (Iceberg)100 % (전체 860 회)100 % (전체 회)92 ms
다른 위치에서 무작위 SIGKILL< 5 % 무음 손실100 % 정상 롤백< 30 ms
  • 인터‑페이즈 간격(Parquet 파일을 업로드하고 트랜잭션을 커밋하는 사이의 몇 초짜리 창)은 AWS가 강제하는 SIGKILL이 복구 불가능한 손실을 초래하는 유일한 지점입니다.
  • SafeWriter의 롤백 로직은 포맷을 인식합니다: Delta Lake에는 DELETE FROM delta. 를, Iceberg에는 DROP SNAPSHOT 을 사용하여 카탈로그 상태가 S3의 실제 데이터와 일치하도록 합니다.
  • 체크포인트 문서(예: s3://my-bucket/checkpoints/job‑12345.json)에는 Lambda ID, 타임스탬프, 영향을 받은 테이블, 롤백 상태가 포함되어 있어 사후 분석이 간단합니다.

Practical Implications

  • Data pipelines on serverless Spark become production‑grade: 개발자는 이제 보이지 않는 데이터 공백을 걱정하지 않고 SoAL을 ETL 작업에 신뢰할 수 있습니다.
  • Simplified monitoring: 기존 S3 이벤트‑기반 알림이 체크포인트 프리픽스를 감시할 수 있으며, 새로운 체크포인트가 생성될 때마다 알람이나 티켓이 트리거됩니다.
  • Cost savings: 고아가 된 Parquet 파일이 스토리지 비용을 급격히 증가시킬 수 있는데, SafeWriter가 그 낭비를 제거합니다.
  • Ease of adoption: SafeWriter는 Spark 드라이버 코드 주변에 얇은 래퍼일 뿐이며, 기본 Lambda 런타임이나 AWS 구성에 변경이 필요하지 않습니다.
  • Cross‑cloud relevance: 이 패턴(워치독 → 롤백 → 체크포인트)은 유사한 강제 종료 특성을 가진 다른 서버리스 컴퓨팅 서비스(Google Cloud Functions, Azure Functions)에도 이식할 수 있습니다.

제한 사항 및 향후 작업

  • 쓰기 전용 워크로드에만 제한된 범위: 이 연구는 트랜잭션 중간에 중단될 수 있는 읽기 또는 업데이트 작업을 다루지 않습니다.
  • 포맷 고유 롤백 API에 의존: 향후 테이블 포맷에 명시적인 롤백 명령이 없을 경우 SafeWriter는 다른 전략이 필요합니다(예: 수동 매니페스트 정리).
  • Lambda 타임아웃 세분화: 워치독은 30 s의 안전 여유를 가정합니다; 매우 짧은 타임아웃(< 60 s)은 정상적인 롤백을 위한 시간 창을 줄일 수 있습니다.
  • 보다 광범위한 실패 모드: 저자들은 네트워크 파티션, S3 최종 일관성, 다중 리전 복제 시나리오 등을 탐색하여 솔루션이 더 복잡한 실패 패턴에서도 유지되는지 확인할 계획입니다.

핵심 요약: Spark‑on‑AWS‑Lambda에서 발생하는 무음 실패 코너 케이스를 공개하고 실용적이며 낮은 오버헤드의 해결책을 제공함으로써, 이 작업은 개발자들에게 데이터 손실이라는 숨겨진 위험 없이 대규모 서버리스 Spark 작업을 프로덕션에서 실행할 수 있는 자신감을 제공합니다.

저자

  • Srujan Kumar Gandla

논문 정보

  • arXiv ID: 2604.20081v1
  • 분류: cs.DC
  • 출판일: 2026년 4월 22일
  • PDF: Download PDF
0 조회
Back to Blog

관련 글

더 보기 »