[Paper] Serverless 추상화: 단기 실행 및 경량 스트림을 위한

Source: arXiv - 2603.03089v1

개요

이 논문은 스트림 함수를 소개한다. 이는 짧은 수명과 가벼운 데이터 스트림을 실행, 상태, 스케일링의 기본 단위로 취급하는 새로운 서버리스 추상화이다. Function‑as‑a‑Service(FaaS)의 탄력성과 스트림 엔진의 반복자‑스타일 처리를 결합함으로써, 저자들은 전통적인 서버리스 또는 스트림‑처리 플랫폼보다 예측 불가능하고 상태를 갖는 워크로드를 훨씬 효율적으로 처리할 수 있음을 보여준다.

주요 기여

• 스트림‑함수 추상화: 기존 FaaS 모델을 확장하여 스트림 (단일 이벤트가 아니라)이 실행 경계가 되도록 합니다.
• 이터레이터 기반 API: next() 스타일의 간단한 인터페이스를 제공하여 개발자가 이벤트별 로직을 작성할 수 있게 하고, 런타임이 상태와 스케일링을 관리합니다.
• 제로‑투‑다수 탄력성: 즉시 제로 스케일링 및 다수 동시 인스턴스로 자동 확장과 같은 서버리스 이점을 유지합니다.
• 성능 평가: 성숙한 스트림 처리 엔진(Apache Flink)과 비교하여 비디오 처리 벤치마크에서 처리 오버헤드가 최대 99 % 감소했음을 보여줍니다.
• 프로토타입 구현: 기존 서버리스 플랫폼(OpenWhisk) 위에 구축하여 실현 가능성을 검증하고 지연 시간, 비용 및 자원 사용량을 측정했습니다.

Methodology

1. Problem framing – 저자들은 먼저 격차를 확인합니다: 짧고 급증하는 스트림(예: 몇 초짜리 비디오 프레임, IoT 센서 버스트)은 순수 FaaS(이벤트당 콜드 스타트 비용 발생)에는 너무 무겁고, 전통적인 스트림 프로세서는(오래 실행되는 작업을 유지)에는 너무 가볍습니다.
2. Design of stream functions –
   • Execution unit: 스트림은 스트림이 지속되는 동안만 존재하는 임시 컨테이너로 구현됩니다.
   • State handling: 상태는 컨테이너 내부 메모리에 보관되며 스트림이 종료될 때 자동으로 체크포인트되어 외부 저장소 왕복을 피합니다.
   • API: 개발자는 스트림을 반복자(for event in stream:)로 받아 결과를 내보내거나 내부 상태를 업데이트하는 함수를 작성합니다.
3. Prototype – OpenWhisk 위에 레이어를 추가하여 구현했으며, 기존 스케줄러, 컨테이너 풀, 자동 스케일링 로직을 활용합니다.
4. Benchmark – 비디오 처리 파이프라인(프레임 추출 → 필터 → 집계)을 스트림‑함수 프로토타입과 Apache Flink 두 가지로 실행합니다. 수집된 메트릭: 종단 간 지연시간, CPU‑seconds, 그리고 금전적 비용.

결과 및 발견

이 결과는 짧게 실행되는 경량 스트림의 경우, 전체 스트림 처리 작업을 유지하는 오버헤드가 실제 계산 작업보다 훨씬 크다는 것을 확인시켜줍니다. 스트림 함수는 이러한 오버헤드를 제거하면서도 정확히 한 번 실행 보장과 상태ful 처리를 제공합니다.

Practical Implications

• Edge & IoT workloads – 센서 데이터가 폭발적으로 발생하는 장치(예: 몇 초 동안의 가속도계 측정값)는 전용 스트림 클러스터를 프로비저닝하지 않고도 거의 지연과 비용이 없는 상태로 처리할 수 있습니다.
• Media pipelines – 짧은 비디오 클립, 라이브 스트림 하이라이트, 또는 사용자가 만든 GIF를 클립 재생 시간 동안만 서버리스 컨테이너를 띄워 실시간으로 변환하고, 이후 사라지게 할 수 있습니다.
• Micro‑service orchestration – 중간 상태가 필요한 복잡한 이벤트 체인(예: 다단계 사기 검사)을 단일 스트림 함수로 표현할 수 있어 배포와 가시성을 단순화합니다.
• Cost optimization – 스트림이 종료되면 컨테이너가 즉시 종료되므로 실제 사용한 컴퓨팅 비용만 지불하게 되어 사용량 기반 클라우드 예산에 매력적입니다.
• Developer ergonomics – 이터레이터 API가 일반적인 Python/Node.js 루프와 유사하게 동작해 전체 스트림 처리 DSL을 배우는 것보다 학습 곡선을 낮춥니다.

제한 사항 및 향후 작업

• 스트림 길이 제한 – 현재 프로토타입은 스트림이 짧다고 가정합니다(초~분). 매우 긴 스트림은 기존 엔진에서 보던 동일한 자원 낭비 문제를 다시 초래할 수 있습니다.
• 상태 내구성 – 컨테이너가 스트림 중에 충돌하면 메모리 내 상태가 손실됩니다; 향후 작업에서는 경량 체크포인팅이나 외부 상태 저장소를 통합할 수 있습니다.
• 플랫폼 의존성 – 구현은 OpenWhisk의 컨테이너 모델에 의존합니다; 다른 서버리스 런타임(AWS Lambda, Azure Functions)으로의 이식성은 추가 엔지니어링이 필요합니다.
• 스케줄링 세분성 – 프로토타입은 간단한 “스트림당 하나의 컨테이너” 정책을 사용합니다; 보다 정교한 패킹 알고리즘은 고동시성 시나리오에서 자원 활용도를 향상시킬 수 있습니다.

핵심: 스트림 함수는 서버리스 함수의 탄력성을 필요로 하면서도 짧은 데이터 폭발에 대한 상태 유지 및 이벤트별 로직이 필요한 개발자에게 매력적인 중간 지점을 제공합니다. 클라우드 제공업체가 서버리스 서비스를 지속적으로 발전시킴에 따라, 이 추상화는 실시간이며 비용 효율적인 데이터 파이프라인을 위한 표준 빌딩 블록이 될 수 있습니다.

저자

• Natalie Carl
• Niklas Kowallik
• Constantin Stahl
• Trever Schirmer
• Tobias Pfandzelter
• David Bermbach

논문 정보

• arXiv ID: 2603.03089v1
• 분류: cs.DC
• 출판일: 2026년 3월 3일
• PDF: PDF 다운로드