클라우드에서 플링크와 스파크 성능 비교 재현 실험

초록

본 논문은 Karamel이라는 배포 자동화 도구를 활용해 Apache Flink와 Apache Spark의 배치·스트리밍 벤치마크를 퍼블릭 클라우드(AWS EC2)에서 재현 가능하도록 설계하였다. Terasort와 HiBench·Yahoo Streaming 벤치마크를 통합하고, 시스템·애플리케이션 수준 메트릭을 수집해 두 엔진의 메모리 설정, 실행 시간, 처리량 등을 비교하였다.

상세 분석

이 연구는 빅데이터 처리 엔진의 성능 평가에서 가장 큰 걸림돌인 “재현성” 문제를 해결하고자 Karamel이라는 DSL 기반 오케스트레이션 프레임워크를 도입했다. Karamel은 Chef cookbook을 재사용해 EC2, Google Cloud 등 다양한 클라우드에 단일 클릭으로 클러스터를 구축하고, 실행 순서를 DAG 형태로 관리한다. 논문은 두 종류의 벤치마크를 선택했다. 배치 처리에서는 Hadoop 기반 Terasort를 변형해 Flink와 Spark용 구현을 각각 제공했으며, 데이터 생성 단계는 Hadoop MapReduce 기반 Teragen을 이용해 200 GB, 400 GB, 600 GB 규모의 입력을 만든다. 스트리밍 처리에서는 Yahoo Streaming과 Intel HiBench Streaming을 재현했는데, 둘 다 Kafka와 Zookeeper를 필요로 하며, 전자는 광고 캠페인 시뮬레이션, 후자는 7개의 마이크로 벤치마크를 포함한다. 특히 HiBench에 Flink 마이크로 벤치마크를 새로 구현해 비교 가능하도록 했다.

성능 측정은 애플리케이션 레벨(실행 시간, 지연, 처리량)과 시스템 레벨(CPU, 메모리, 네트워크, 디스크) 두 축으로 진행했으며, 시스템 레벨은 경량 모니터링 툴 collectl을 자동화한 collectl‑monitoring을 사용해 5초 간격으로 데이터를 수집했다. 실험 환경은 마스터 노드에 m3.xlarge, 워커 노드에 i2.4xlarge 인스턴스를 사용했으며, 메모리 할당을 Spark는 executor 100 GB, driver 8 GB, Flink는 jobmanager 8 GB, taskmanager 100 GB로 조정했다. 이러한 파라미터는 Karamel DSL 파일이나 웹 UI를 통해 쉽게 변경 가능하도록 설계돼, 사용자는 동일한 실험을 다양한 메모리 설정으로 반복할 수 있다.

결과적으로 Terasort 배치 테스트에서 입력 데이터가 증가할수록 두 엔진 모두 선형에 가까운 실행 시간 증가를 보였으며, 메모리 할당량이 충분히 큰 경우 Flink가 약간 더 빠른 경향을 보였다. 스트리밍 테스트에서는 Kafka‑Zookeeper 기반 데이터 흐름에서 Spark와 Flink가 각각 다른 지연 특성을 나타냈으며, Yahoo Streaming의 광고 캠페인 시뮬레이션에서는 처리량 면에서 Spark가 우세했지만, Flink는 안정적인 지연을 유지했다. 전체적으로 Karamel을 통한 자동화는 복잡한 의존성 관리와 클러스터 설정을 크게 단순화했으며, GitHub에 공개된 cookbook과 DSL 파일 덕분에 다른 연구자나 실무자가 동일한 실험을 손쉽게 재현하고, 필요에 따라 파라미터를 조정해 새로운 시나리오를 탐색할 수 있게 되었다. 다만, 실험이 AWS Spot 인스턴스에 의존했기 때문에 인스턴스 중단 위험과 비용 변동성이 결과에 미치는 영향을 완전히 배제하지 못했으며, 메모리 중심 워크로드에 초점을 맞춘 점이 다른 유형의 작업(예: I/O‑bound) 평가에는 제한적일 수 있다.