서버리스 빅데이터 오픈소스 소프트웨어를 준비하며

* 본 아티클의 원문은 2020년 10월 22일 Google Cloud 블로그(영문)에 게재되었습니다. 

Apache Hadoop, Apache Spark, Presto 등의 빅데이터 오픈소스 소프트웨어(OSS)는 엔터프라이즈 데이터 레이크와 빅데이터 아키텍처의 업계 표준으로서 그 입지를 공고히 하고 있습니다. 많은 기업이 공급업체 종속성을 탈피하고 비용을 절감하며 커뮤니티 혁신 역량을 강화하고자 온프레미스 OSS 배포 환경을 선택하고 있지만 기업의 요구사항(보안, SLA 등)과 비즈니스 니즈를 적절히 절충하는 데에는 어려움을 겪고 있습니다. 이와 같은 업계의 변화 속에서 Google의 Dataproc 플랫폼은 이미 사용 중인 데이터 및 OSS 시스템을 관리하고, 분석하며, 최대로 활용할 수 있는 길을 열어 줍니다. 

이 모든 변화는 2010년 Apache Hadoop의 온프레미스 배포에서 시작되었지만 독립적인 확장이 불가능하고 많은 미세 조정과 테스트 과정이 필요한 정적인 머신을 다뤄야 했기에 당시 빅데이터 설계자로서는 아쉬운 점이 많았습니다. 다음번 데이터 급증 또는 OSS 출시가 파이프라인이나 쿼리의 중단을 유발할지 여부도 예측할 수 없었습니다. 그러던 중 출시된 클라우드는 이 많은 문제의 해결책이 되었습니다. 2015년 Google Cloud의 Dataproc이 출시되자 많은 기업이 스토리지에서 컴퓨팅을 분리하고 커스텀 OSS 클러스터를 커스텀 머신과 함께 구축할 수 있게 되었습니다. 클러스터 구축과 확장이 자동화된 덕분에 흔히 발생하던 온프레미스 문제를 예방하고 고객이 OSS에 곧 닥쳐올 '서버리스'라는 큰 변화에 대비하는 데 도움이 되었습니다.

다가올 서버리스의 미래를 살펴보기에 앞서 이 산업의 시작과 현재 모습을 알아보겠습니다.

온프레미스 OSS의 시작과 문제점 

빅데이터 오픈소스 소프트웨어는 데이터 센터에서 클러스터의 하드웨어 설정을 간소화하고 데이터 애플리케이션에서 하드웨어 장애의 영향을 최소화하기 위한 목적으로 시작되었습니다. 또한 빅데이터 OSS는 관리 간소화 및 모든 가용 리소스의 효율적인 활용을 통해 비용을 최적화하면서도 전체 오픈소스 커뮤니티에 공개되는 혁신 기술까지 활용할 수 있는 장점이 있습니다. 이와 같은 전략은 개발자가 데이터 센터 재구성 없이 각자의 판단하에 적합한 방식으로 기본 하드웨어를 활용할 수 있는 자유를 제한하지 않도록 주의하여 사용해야 합니다.

초창기 버전의 빅데이터 분석은 처리 작업에 데이터를 가져오던 기존의 처리 패러다임을 데이터에 처리 작업을 가져오는 방식으로 바꿨습니다. 그 밖에도 설계가 간소화된 덕분에 데이터 센터팀이 Linux를 실행하는 상용 서버의 상호 연결 랙을 설정하는 작업에 집중할 수 있게 되었습니다. 그런 다음 이 랙은 데이터 애플리케이션 처리 환경을 구성하고 최적화하는 작업을 수행하도록 빅데이터 개발자에게 전달되었습니다. 핵심 빅데이터 오픈소스 구성요소인 Hadoop은 분산형 파일 시스템 및 처리 프레임워크(맵리듀스)를 구현하여 데이터 애플리케이션 실행을 간소화하고 모든 하드웨어 장애를 원활하게 처리했습니다. 

결과적으로 소규모의 데이터 센터 엔지니어팀으로도 수천 대의 머신을 관리할 수 있게 되었습니다.

처리와 데이터가 구분되어 있었으나 애플리케이션 개발자는 데이터 근접성에 특히 주의를 기울였습니다. 물리적 서버의 위치는 데이터 처리 애플리케이션에 필요한 I/O 대역폭을 확보하는 데 여전히 중요한 역할을 했습니다. 결과적으로 이러한 처리 환경의 구성에는 처리 환경의 편성 방식(물리적 서버 구성, 연결된 스토리지, 랙 안팎의 네트워크 링크)에 대한 깊은 이해가 필요했습니다. 개발자는 가용 메모리, I/O 특성, 스토리지, 컴퓨팅 같은 기본적인 물리적 환경을 최대로 활용하기 위한 소프트웨어도 설계했습니다. 

하지만 이러한 환경에도 나름의 문제가 뒤따랐습니다. 

온프레미스 OSS의 문제점

• 자본 투자 및 리드 타임: 온프레미스 인프라 설정에는 사전 투자와 장기간의 리드 타임이 필요합니다. 데이터 센터 구축에는 여러 해가, 전원 및 냉각 용량 업그레이드에는 수 분기가, 신규 서버 설치에는 구성에만 수개월이 소요됩니다. 이러한 모든 증설 작업에는 막대한 계획과 실행이 필요하기 때문에 대부분의 데이터 개발자에게는 역량 밖의 일입니다.

• 모든 니즈를 만족하는 하드웨어 구성 선택: 하드웨어 구성을 마무리하려면 여러 머신 구성을 주의 깊게 실험하며 다양한 워크로드에 맞는지 검증해야 합니다. 대부분의 오픈소스 소프트웨어는 표준화에 의존하므로 새로운 비즈니스 니즈를 충족하도록 하드웨어 구성을 변경하기가 어렵습니다. 새로운 기술을 활용하기 위해 하드웨어를 재정비할 때도 사용자 생태계에 미치는 지장이 최소화되도록 세심하게 계획해야 합니다.

• 데이터 센터 제약조건 관리: 데이터 센터 계획에는 사용률을 극대화하기 위한 전원, 냉각, 물리적 공간의 최적화 작업이 필수입니다.

• 마이그레이션: 네트워크에서 데이터를 이전하는 데 만만치 않은 비용이 드는 만큼 데이터 센터의 재배치는 간단한 일이 아닙니다. 데이터와 애플리케이션을 재배치하는 데 드는 비용과 수고를 피하기 위해 사용자가 하드웨어를 트럭에 싣고 직접 마이그레이션하는 방법을 사용하는 경우도 있었습니다.

• 재해 대응 계획: 여러 데이터 센터 위치에서 성공적으로 장애를 복구하는 동시에 네트워크 지연을 최소화하려면 충분한 네트워크 대역폭을 확보해야 하므로 재해 복구 계획에는 많은 문제점이 따릅니다. 실제 상황이 발생하기 전에 인계 시스템을 설계하고 검증해야 하는 것은 물론입니다.

클라우드 기반 OSS

가상화 기술의 혁신 덕분에 가용 I/O 대역폭, 가상화 취약성, 스토리지 성능 같은 일부 온프레미스 환경의 설계상 제약이 사라졌습니다. 또한 클라우드 컴퓨팅 환경에서는 스토리지와 컴퓨팅 용량을 신속하게 이용할 수 있으므로 데이터 개발자가 주문형 확장의 이점을 활용할 수 있습니다. 데이터 개발자는 클라우드 컴퓨팅을 통해 처리 니즈에 맞는 커스텀 환경을 선택하여 기본 인프라보다는 데이터 애플리케이션에 집중할 수 있습니다. 이러한 모든 역량이 클라우드 기반 데이터 분석 환경에 대한 선호도를 크게 높였습니다. 이제 개발자는 높은 수준의 애플리케이션 구성에 주력하고 새로운 클라우드 경제학을 십분 활용하는 소프트웨어를 설계할 수 있습니다.

클라우드 기반 OSS의 문제점

• 인프라 구성: Infrastructure as a Service 덕분에 데이터 센터의 로지스틱을 계획할 필요가 없게 되었지만 복잡한 클러스터 구성 업무는 아직 과제로 남아 있습니다. 데이터 처리 환경을 구성하는 사용자는 클라우드 인프라의 구체적인 문제점과 제약조건을 이해하고 있어야 합니다. 

• 처리 환경 구성: 클라우드에서는 복잡한 처리 환경의 구성이 수월하게 진행됩니다. 하지만 클라우드에서 처리 환경을 최적화하려면 데이터와 워크로드 특성에 대한 깊은 이해를 갖추고 있어야 합니다. 환경에서 데이터 구성, 스토리지 형식, 위치와 같은 데이터 또는 처리 알고리즘에 대한 변화를 감행해야 할 때도 있기 때문입니다.

• 비용 최적화: 실행 환경에 드는 총 운영 비용을 최소화하도록 구성을 설정하려면 데이터와 워크로드를 지속적으로 모니터링하고 관리해야 합니다.

• 지연 시간 최적화: 시간이 지나면서 워크로드가 진화함에 따라 SLO 관리가 매우 중요하며 지속적인 모니터링과 미세 조정 작업이 필요합니다. 극단적인 경우에는 SLO 관리를 위해 스토리지 형식 또는 처리 패러다임을 다시 설계해야 합니다. 

다가올 서버리스 미래를 대비하는 동시에 오늘날의 OSS 클라우드 문제를 경감해 주는 Dataproc

Dataproc은 사용하기 쉬운 완전 관리형 클라우드 서비스로서 Apache Spark, Apache Presto, , Apache Hadoop 클러스터 같은 관리형 오픈소스를 더욱 간단하고 비용 효율적인 방식으로 실행합니다. 조사에 따르면 기업은 초당 가격 책정, 비활성 클러스터 삭제, 자동 확장 등을 통해 비용 이점을 누리기 위해 빅데이터 워크로드를 클라우드로 마이그레이션하는 것으로 나타났습니다. 최근 Dataproc은 개방형 분석 환경의 관리를 간소화해 주는 다음과 같은 미리보기 기능을 출시했습니다.

• 개인 클러스터 인증: 클러스터의 대화형 워크로드를 최종 사용자 ID로 안전하게 실행할 수 있습니다. Cloud IAM 메모장을 사용하면 사용자 인증 정보로 워크로드가 실행되고 데이터 액세스를 수행합니다. 이에 따라 ID 액세스 제어 및 로깅이 개선되므로 관리자가 사용자 액세스 관리를 간소화하는 동시에 환경 보안을 효과적으로 관리할 수 있게 됩니다. 

• 유연성 모드: Dataproc은 선점형 VM(PVM)과 자동 확장을 지원합니다. 자동 확장을 통해 수요에 따라 클러스터 규모를 적절하게 조정할 수 있어 예산을 현명하게 사용할 수 있습니다. 유연성 모드 기능을 사용하면 작업 실패율을 줄이는 동시에 클러스터 작업 비용을 추가로 최적화할 수 있습니다. 유연성 모드에서는 기본 워커 노드에 모든 Spark 중간 데이터를 저장할 수 있어 엄격한 자동 확장 정책을 설정하거나 보조 노드에 선점형 VM을 추가로 활용하거나 두 가지 조치를 동시에 취할 수도 있습니다. 중간 셔플 데이터는 '작업자'(맵리듀스의 매퍼 및 Spark의 실행자) 외부에 저장되므로 작업 중 작업자 머신이 삭제(또는 선점)된 후 이어지는 축소 이벤트 동안 작업 진행률이 손실되지 않습니다.

• 영구 기록 서버: 이제 클러스터가 오프라인일 때도 작업 로그와 클러스터 구성을 확인할 수 있습니다. 오프라인은 임시 클러스터가 현재 실행 중이 아니거나 클러스터가 삭제되었다는 의미입니다. Cloud Storage에 작업 로그가 보관되도록 클러스터를 구성한 다음 일련의 Cloud Storage 위치에서 로그를 볼 수 있도록 영구 기록 서버를 구성해야 합니다. 하나의 영구 기록 서버가 여러 클러스터의 로그를 취합하도록 구성하여 워크플로와 데이터 애플리케이션의 관리 가능성 및 디버그 가능성을 간소화할 수 있습니다. 

Dataproc을 도입하는 기업은 새로운 OSS를 신속하게 테스트하고, 코드를 개발하고, 파이프라인 및 모델을 배포하고, 프로세스를 자동화하여 유지관리보다는 빌드에 더 집중할 수 있게 됩니다. Google은 Dataproc을 통해 지속적으로 OSS 테스트/개발, 배포, 자동화 개발 주기를 향상하는 한편, 다가올 서버리스 미래를 대비하기 위한 인텔리전스를 계속해서 Google Cloud 서비스에 빌드하여 제공할 것입니다. 

다음 단계: 서버리스 OSS 

고객에게 주어진 수많은 선택사항으로 인해 데이터 분석 플랫폼(처리 및 스토리지)의 미세 조정/구성이 복잡해지는 데다 사용량과 사례가 진화하면서 데이터 애플리케이션의 수명 주기에 맞춰 최적화된 플랫폼을 선택하는 판단이 더욱 어려워지고 있습니다. 서버리스 OSS가 이 상황에 변화를 가져옵니다. 

미래의 서버리스 개념은 복잡성과 문제를 해결하는 데 중점을 두기 때문에 기본이 되는 플랫폼이 지능적인 선택을 내리는 동안 사용자는 서비스 품질(QoS)에 더 집중할 수 있게 됩니다. 어렵게 느껴질 수 있지만 몇 단계를 거치면 해결할 수 있는 과제입니다. QoS를 실현하기 위해 선택할 수 있는 3가지 주요 요소가 있습니다.

• 클러스터: 원하는 QoS를 달성하기 위한 워크로드를 실행하기에 적합한 클러스터 선택

• 인터페이스: 워크로드에 적합한 인터페이스 선택(Hive, SparkSQL, Presto, Flink 등) 

• 데이터: 위치, 형식, 데이터 구성의 선택

서버리스 세상에서는 인프라가 아닌 워크로드에 초점을 맞춥니다. Google은 비용 또는 성능처럼 사용자가 중요하게 생각하는 측정항목을 기준으로 최적화할 수 있도록 클러스터와 작업의 구성과 관리를 자동화합니다.