Offcanvas

가상화 / 빅데이터 | 애널리틱스 / 애플리케이션 / 오픈소스

칼럼 | 아파치 스파크에서 마음에 들지 않는 5가지

2015.11.17 Ian Pointer  |  InfoWorld
맵리듀스(MapReduce)가 점차 힘을 잃는 추세에 지난해 클라우데라(Cloudera), IBM과 같은 주요기업들의 전폭적인 투자까지 더해지며 빅데이터 프로세싱 플랫폼인 아파치 스파크(Spark)가 본궤도에 오르기 시작했다.

10줄 미만의 코드로 단어 개수를 계산하는 애플리케이션 데모들이 쏟아져 나왔다. 그러나 스파크에 대해 조금 더 깊이 파고들어 간 사람이라면 개념 설명을 위한 간단한 예제를 벗어나 본격적인 무언가를 하려고 할 때, 스파크에 대한 환상이 어느 정도 깨지는 것을 경험했을 것이다.

물론 스파크는 훌륭하다. 그러나 스파크는 스칼라(Scala) 코드 몇 줄만으로 끝나는 그런 간단한 개념이 아니다. 업무 현장에서 스파크를 사용할 때 직면하는 5가지 가장 큰 골칫거리를 살펴보자.

메모리 문제
대규모 데이터를 처리하는 도중에 힙 공간이 소진되는 스파크의 고질적인 문제를 이야기하는 것이 아니다. (스파크 1.5와 그 이후 나올 1.6에서 데이터브릭스(Databricks)의 주안점 중 하나인 프로젝트 텅스텐은 마침내 가비지 수집 문제를 많은 부분 해결해준다.) 여기서 이야기하는 문제는 대규모로 작업할 때 맞닥뜨리게 되는 다양한 형태의 메모리 문제다.

스파크를 몇 개월 동안 스탠드얼론(Standalone) 클러스터 모드로 사용하다가 YARN 및 메소스(Mesos)로 바꾸면서 모든 기본값이 변경될 때 겪는 일종의 적응 과정으로 생각할 수도 있다. 예를 들어 스탠드얼론에서는 가용한 모든 메모리와 코어를 자동으로 가져오지만, 스탠드얼론 외의 다른 구축 옵션에서는 실행 파일과 드라이버용 기본값이 터무니없이 작다. 쉽게 고칠 수 있는 문제지만 작업 규모를 확대할 때 누구나 반드시 한 번은 잊고 넘어가는 부분이다.

데모 수준을 벗어나서 대규모 데이터 세트를 다루게 될 때 스파크 작업이 꼬이는 전형적인 예를 보면 1.8TB 세트를 대상으로 실행하는 reduceByKey 작업이 spark.driver.maxResultSize의 기본값(1GB)을 초과하는 경우, 또는 무심코 많은 수의 병렬 작업을 실행하다가 spark.akka.frameSize의 128MB 제한에 걸리는 경우 등이다.

이러한 문제는 구성 변경으로 수정이 가능하고 스파크도 많이 개선되어 로그를 통해 예전보다 훨씬 더 쉽게 문제 부분을 찾아낼 수 있다. 그러나 이는 “데이터의 스마트폰”(이번 주 초에 데이터브릭스의 데니 리가 스파크를 이렇게 표현했음)에 많은 시행착오가 필요하다는 것을 의미한다(장기적으로 실행되는 일괄 처리 작업에서 문제가 될 수 있음). 또한, 스파크는 구성 옵션에 대한 심오한 지식을 요구한다. 컨설턴트에게는 좋은 점이지만 그 외의 다른 사람에게는 별로 좋지 않은 면이다.

해결되지 않는 작은 파일 문제
하둡으로 작업을 한 적이 있다면 작은 파일 문제에 대한 불평을 들어봤을 것이다. 작은 파일 문제란 HDFS가 다수의 작은 파일보다 한정된 수의 대용량 파일을 선호하는 방식을 일컫는다. 스파크와 HDFS를 함께 사용할 경우 이 문제에 직면하게 된다. 그러나 그 외에도 막상 경험할 때까지는 인식하지 못하는 또 다른 패턴도 있다.

S3에서 보편적으로 gzip을 이용해 데이터를 저장한다.

좋은 패턴이지만 한 가지 예외는 작은 gzip 파일이 많을 때다. 이 경우 스파크가 이 파일들을 네트워크를 통해 가져와야 할 뿐만 아니라 압축도 해제해야 한다. gzip 파일은 전체 파일이 하나의 코어에 있을 때만 압축을 해제할 수 있으므로 실행 파일은 순서에 따라 파일 압축을 해제하는 데 코어를 소모하면서 많은 시간을 낭비하게 된다.

설상가상으로 이후 각 파일은 RDD에서 하나의 파티션이 되므로 결국 RDD 하나에 자칫 백만 개의 아주 작은 파티션이 생성될 수도 있다. (RDD는 “Resilient Distributed Dataset”의 약어로, 스파크의 기본적인 추상화다.) 프로세싱 효율성을 망치지 않기 위해서는 이 RDD 파티션을 관리가 용이한 형태로 재구성해야 하는데, 이는 네트워크의 과부하를 유발하는 많은 셔플 작업이 필요하다는 것을 의미한다.

이 문제에 대해서는 스파크에 뾰족한 해법이 없다. 최선은 분할 가능한 다른 형식(예를 들어 LZO)으로 데이터를 압축하거나, S3에서 파일 크기를 늘리고 수를 줄일 방법이 있는지 알아보는 것 정도다.

스파크 스트리밍(Spark Streaming)
스파크 스트리밍은 악명 높은 스파크 API 확장이다. 스파크 스트리밍으로 인해 많은 개발자는 “최적의 blockInterval을 찾을 수만 있다면 파이프라인을 계속 가동할 수 있을 텐데!”라고 중얼거리며 출구 없는 미로를 이리저리 방황한다.

모두가 데모를 통해 봤듯이 지금은 스파크에서 스트리밍 솔루션을 정말 쉽게 구축할 수 있다. 그러나 대규모로 24/7 운영이 가능한 탄력적인 파이프라인을 구축하는 것은 전혀 다른 문제고, 많은 경우 깊은 디버깅의 늪에 빠지게 된다. 이 문제도 마찬가지로 스파크 릴리스가 거듭될수록 개선되고 있으며 스파크UI 레벨, 다이렉트 리시버, 백-프레셔(back-pressure) 등을 통해 더 많은 정보가 공개되고 있다. 그러나 여전히 컨퍼런스 프레젠테이션에서 시연한 수준의 단순함과는 거리가 멀다.

스파크 스트리밍 파이프라인 디버깅과 관련하여 도움이 필요한 경우, 또는 아파치 스톰(Storm)으로의 전환을 고려해야 하는 경우에는 필자의 최근 두 기사, 아파치 스파크 소개와 스파크와 스톰: 언제, 어디서 사용하는가?를 참고하라.

파이썬
파이썬 팬들이 몽둥이를 들고 몰려오기 전에 확실히 밝혀두지만, 필자도 파이썬을 좋아한다! 필자는 프로그래밍 언어 논쟁을 일으킬 생각은 없다. 그러나 꼭 파이썬을 사용해야 하는 경우가 아니라면 일반적으로 필자는 스파크 애플리케이션을 만드는 사람에게 스칼라를 권장한다.

이유는 크게 두 가지다. 첫째, 스파크 개발 상황을 주시해 보면 스파크 릴리스마다 스칼라/자바 측면에서 새로운 것이 추가되고 파이썬 API가 업데이트되어 이전에는 노출되지 않았던 부분을 포함하게 된다는 것을 알 수 있다(범위를 더 넓혀 스파크R(SparkR) 바인딩에서도 마찬가지). 따라서 여러분은 스파크 플랫폼에서 가능한 기능 측면에서 항상 최소 한두 단계는 뒤처지게 된다. 둘째, 순수 RDD 접근을 통해 애플리케이션을 만들고 있다면 파이썬은 항상 자바 또는 스칼라에 비해 느리다. 스칼라를 사용하라! 형 안정성(type-safety)을 받아들여라!

미칠듯한 랜덤 오류
다만 스칼라에는 존재하지 않는 numpy 또는 scikit-learn을 사용해야 한다면 파이썬을 고려해볼 수 있다. 스파크 API에서 다소 뒤처지는 것을 감수할 용의만 있다면 말이다. 파이썬 애호가들의 거센 분노가 느껴지지만 어쩔 수 없다.

미칠듯한 오류란 어떤 것인가? 예를 들어 최근 어떤 일을 하면서 스파크 작업을 실행했는데 일주일 동안 매끄럽게 돌아가던 이 작업이 갑자기 멈췄다. 실행 파일 로그는 셔플 단계에서 압축/압축 해제 오류를 가리키는 항목들로 가득 차 있었다.

스파크 지라(Jira) 로그에는 셔플 중 사용된 스내피(Snappy) 압축 체계를 문제의 원인으로 지목하는 티켓이 열려 있다. 또한, 그 티켓에 따르면 이 오류는 간헐적으로 발생하는 오류다.

다른 코덱으로 바꾸자 문제는 해결됐다. 그러나 다음 날 아침 비슷한 문제가 또 발생했다. 그날 하루 종일 여러 가지 셔플 코덱을 바꿔가며 사용하고 심지어 압축을 완전히 비활성화하기도 했지만 해결되지 않았다. 결국 어렵게 찾아낸 문제의 원인은 스파크의 네트워크 전송 시스템(네티, Netty)과 젠(Xen) 하이퍼바이저, 그리고 AWS 인스턴스에 사용 중이었던 리눅스 커널 버전 간의 부조화에 있었다. 해결책은 젠 네트워크 드라이버에 플래그를 설정하는 것이었다. 그러자 마치 처음부터 아무 문제도 없었다는 듯 모든 부분이 매끄럽게 돌아갔다. 힘든 경험이었지만 그나마 해피엔딩으로 끝나 다행이다.

이 이야기들의 교훈은 무엇일까? 비록 스파크는 아주 큰 규모에서 복잡한 데이터 프로세싱 작업을 더 쉽게 작성하고 실행할 수 있게 해주지만 대규모 작업에서 문제가 발생할 경우 이 문제를 해결하기 위해서는 구현 언어에서 커널에 이르기까지 모든 요소에 대한 경험과 지식이 필요하다. 이렇게 확언할 수 있는 이유는 필자가 주로 하는 일이 바로 이런 형태의 오류에 빠진 사람들을 돕는 것이기 때문이다. editor@itworld.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.