각종 정보를 실시간으로 배포하는 데이터 소스는 이미 꽤 많다. 모바일 애플리케이션의 사용자 인터액션 이벤트, 금융 서비스 트랜젝션, 의료 모니터링 시스템, IoT 장치 등이 대표적이다. 이러한 데이터 소스를 다루는 개발자는 실시간 스트리밍 데이터를 캡처할 아키텍처에 대해 생각해볼 필요가 있다. 몇 년 내에 기업 경쟁력의 원천이 될 수도 있기 때문이다.
과거에는 대규모로 실시간 정보를 처리할 수 있게 만드는 것이 아주 어려웠다. 레이턴시(지연 시간)가 낮도록 하드웨어 아키텍처를 엔지니어링해야 했으며, 소프트웨어에는 데이터를 수신해 처리한 후 효율적으로 보내는 고급 프로그래밍 기법을 도입해 적용해야 했다. 하지만 상황이 달라지고 있다.
데이터 프로세싱에 발생한 ‘패러다임 변화’
최근 스트라타 데이터 컨퍼런스(Strata Data Conference)에 참석한 필자는 이 곳에서 패러다임 변화를 발견했다. 개발자가 데이터 스트리밍이나 실시간 데이터 처리 페이로드를 처리할 수 있도록 도와주는 여러 프레임워크(오픈 소스 및 상용)가 등장하고 있다. 또 데이터 스트림의 데이터 관리, 모니터링, 스케일링(크기 조정), 프로그래밍을 능률화 해주는 상용 도구들이 부상하고 있다.
세상은 더 이상 ‘배치’(batch)가 아니다. 불과 2-3년 전과 비교해도, 데이터 스트림을 처리할 수 있는 도구에 대한 접근성이 훨씬 더 높아졌다.
현재의 도구, 아키텍처, 접근법은 배치 처리의 시대에 사용됐던 것들과 크게 다르다. 예전에는 대부분 플랫 파일에서 데이터를 추출, 사용할 수 있는 구조로 변환하고, 이를 데이터베이스나 다른 데이터 관리 시스템에 로드 하는 스크립트를 개발하거나, 이런 일을 했었다.
이런 ETL(Extract, Transform, Load) 스크립트를 서버에 직접 배포하고, 유닉스Cron 같은 도구로 실행하도록 예약했다. 또는 새로운 데이터를 사용할 수 있을 때 실행시키는 서비스였다. 또는 인포매티카(Informatica), 탈렌드(Talen), IBM, 마이크로소프트, 기타 공급업체의 ETL 플랫폼에서 엔지니어링을 했다.
그러나 지금은 데이터를 획득한 후, 실시간으로 분석과 머신러닝을 처리해야 하는 수요가 증가하고 있는 추세이다. 대부분 비즈니스 경쟁력 때문이다. 금융기관은 새로운 정보, 소셜 미디어, 금융정보를 처리한, 또는 트레이더(거래인)들이 실시간 분석으로 시장 상황에 대응할 수 있도록 만든다.
실시간 고객 경험(환경) 촉진에도 사용된다. 상점에 들어오는 고객을 즉시 인식, 이들이 상품을 둘러볼 때 개인화된 상품 제안을 하는 컨슈머 소매 플랫폼을 예로 들 수 있다. 이상한 부분이나 안전 상태를 즉시 파악하고, 사람들에게 경고를 하기 위해 중요한 정보를 분석하는 병원, 공항, 건설 현장, 발전소 등의 경우 삶과 죽음의 문제와 연결되어 있기도 하다.
데이터 스트리밍을 위한 기술적 요구사항(요건) 파악
데이터 스트림을 관리할 기술을 선정하기에 앞서 파악해야 할 것들이 있다. 아키텍처와 플랫폼, 구현 요건을 선택하기 이해서는 타깃화된 분석에 대해 이해하고, 데이터 소스, 데이터 처리 요건을 확인하는 것이 중요하다. 필자는 스트라타 데이터 컨퍼런스에서 솔루션 공급자 및 실무자들과 스트리밍에 대해 대화를 나눴다. 다음은 이를 통해 파악한 고려할 요소들이다.
– 데이터 소스의 수, 데이터 형식(JSON, XML, CSV 등), 인터페이스(API, 플랫 파일, 소스 데이터베이스), 스키마 복잡성, 데이터 품질 요소, 데이터 속도는 데이터 스트림 프로세서를 디자인할 때 고려할 요소들이다. 또 데이터 소스가 완전한 레코드를 전송하는지, 변경된 레코드 및 수정된 필드만 전송하는지 아는 것이 좋다. 개발자는 데이터 소스 퍼블리셔가 제공한 데이터 사전이나 다른 문서를 검토, 기업이 데이터와 관련된 ‘의미’와 비즈니스 규칙’을 이해하도록 만들어야 한다.
– 데이터 스트리밍 플랫폼을 선택 및 구성할 때 데이터 속도와 양, 데이터 기간을 고려해야 한다. 타깃화된 분석에 반드시 필요하기 때문이다. 여기에 더해 레이턴시와 관련된 요건을 현실적으로 규정하는 것이 중요하다. 레이턴시란 소스가 새 데이터를 공유할 때부터 데이터 스트림이 데이터나 분석을 완전히 처리하기까지 시간이다. 많은 볼륨(양), 속도, 스토리지 요구사항, 낮은 레이턴시와 관련된 요건이 플랫폼과 아키텍처 선택에 영향을 준다. 또한 기반이 되는 인프라의 크기 및 비용과 관련된 요소들이다.
– 수행할 분석의 종류, 액세스할 데이터의 크기, 업데이트 주기 및 빈도에 초점을 맞춘다. 또한 개발자는 분석이 얼마나 자주 변경될지, 새 알고리즘 버전을 배포할 때 다시 처리가 필요한지 여부를 고려해야 한다.
– 개발자는 퍼블릭 클라우드, 프라이빗 클라우드, 엣지 장치 등 데이터 스트림 배포 장소를 고려해야 한다. 일부 데이터를 장치나 로컬 장치 그룹에서 처리한 후 통합 데이터를 중앙 분석 시스템으로 보내는 IoT 유즈 케이스(사용 사례)가 많다. 주행 관련 결정을 내리기 위해 데이터를 처리한 후 교통 및 도로 상황을 중앙 분석 프로세서와 공유하는 자율주행 자동차를 예로 들 수 있다.
데이터 스트리밍 플랫폼: 카프카(Kafka), 스파크(Spark), 기타 대안
이런 요구사항들은 데이터 스트림을 지원하고, 접근법을 검증할 볼륨이 작은 파일롯을 디자인할 수 있는 고수준 아키텍처 결정에 도움을 준다. 데이터 스트리밍 아키텍처는 3가지 아키텍처 구성요소로 구성된 경우가 많다.
– 데이터 소스의 데이터를 캡처해 처리를 시작하는 메시징 구성요소 스트라타 컨퍼런스에서 가장 지배적이었던 제품이 아파치 카프카(Apache Kafka)였다. 또한 이에 대해 언급된 세션도 많았다. 대안이 될 수 있는 제품은 아파치 펄사(Apache Pulsar)와 아마존 키네시스(Amazon Kinesis)이다.
– 분석을 실행시킬 수 있는 분산형 내결함성(Fault-tolerant) 컴퓨터 시스템 컨퍼런스에서 가장 많이 언급된 기술은 아파치 스파크 스트리밍(Apache Spark Streaming)과 스파크 스트럭처드 스트리밍(Spark Structured Streaming)용 새 API였다. 그러나 아파치 스톰(Apache Storm), 카프카 스트림(Kafka Streams), 아파치플링크(Apache Flink), 아파치 헤론(Apache Heron)이 대안이 될 수 있다.
– 결과를 공유 또는 저장할 수 있는 다운스트림 시스템 하둡(Hadoop)이나 카산드라(Cassandra), SQL 관계형 데이터베이스 같은 빅 데이터 플랫폼, 플랫 파일, 데이터 비주얼리제이션 도구, 아파치 북키퍼(Apache BookKeeper) 같은 로우 레이턴시 스토리지 도구, 키네티카(Kinetica) 같은 GPU 데이터베이스, MemSQL 같은 분산형 데이터베이스가 될 수 있다.
카프카, 스톰, 플링크, 스파크 스트리밍을 고려할 때 디자인 측면에서 중요한 요소 중 하나는 애플리케이션에 도착한 데이터를 처리하는 네이티브 스트리밍이 필요한지 여부, 일부 레이턴시 및 마이크로 배치 프로세싱을 지원할 수 있는지 여부이다.
처리 요건이 기본적인 경우, 카프카와 카프카 스트림 사용만으로 충분할 수 있다. 네이티브 처리가 필요한 경우, 스톰과 플린트가 스파크 스트리밍 보다 성숙한 기술이다. 스트라타 컨퍼런스에서는 카프카와 스파크 스트림이 가장 많이 언급된 아키텍처였다. 발표자들은 사용 편의성, 확장성, 다용성을 강조했다.
데이터 스트리밍 아키텍처 옵션
필자는 생태계의 규모를 바탕으로 아키텍처의 성숙 여부를 판단한다. 플랫폼을 이용해 성공을 일궈낸 팀이 많을 수록 더 튼튼하고, 공급업체의 지원이 충실하다. 공급업체는 전문가와 전문성을 제공한다. 또 도구는 기술 구현이 더 쉽고, 더 많은 사용자가 이용할 수 있다. 적용할 수 있는 유즈 케이스도 더 많다.
아마존 웹 서비스(Amazon Web Services), 마이크로소프트 애저 HDInsight(Microsoft’s Azure HDInsight), 구글 클라우드 스트림 애널리틱스 솔루션(Google Cloud’s Stream Analytics Solution), IBM 클라우드 스트리밍 애널리틱스(IBM Cloud Streaming Analytics)를 사용해 직접 아키텍처를 구성할 수 있다. 이런 서비스를 활용, 셋업과 구성을 처리할 수 있다. 또 여러 아키텍처 구성요소를 유지관리 할 수 있다.
대형 기업은 클라우데라(Cloudera), MapR, 호튼웍스(Hortonworks) 같은 빅데이터 플랫폼의 데이터 스트리밍 기술과 지원을 활용할 수 있다. ETL에 많이 투자한 대기업은 인포매티카 빅 데이터 스트리밍(Informatica Big Data Streaming) 및 탈렌드 데이터 스트림(Talend Data Streams)같은 벤더의 데이터 스트리밍 기술을 검토할 수 있다.
다른 벤더들도 대안이 될 수 있는 아키텍처를 최적화해 공급하고 있다. 예를 들어, Streaml.io는 메시징에 아파치 펄사, 스트림 처리에 아파치 헤론, 스토리지에 아파치 북키퍼를 결합해 사용한다. 이 회사는 훨씬 더 쉽게 구축할 수 있는 아키텍처이며, 아파치 스파크와 비교되는 지원을 제공한다고 주장한다.
이런 기술들을 시작하는 정도라면 무료 트라이얼을 제공하는 데이터브릭스 커뮤니티 에디션(DataBricks Community Edition)과 스트림애널리틱스(StreamAnalytics)를 시험해볼 수 있다. 이런 도구를 사용함으로써 인프라 구성 없이 데이터를 로드하고, 스트리밍 알고리즘을 개발하는 일을 시작할 수 있다.
짧은 요구사항(요건) 리스트로 시작
선택한 접근법이 무엇이든, 베스트 프랙티스에 해당되는 ‘출발점’은 기술적 요건을 정의하고, 이런 요소들과 비용, 기타 고려사항을 근거로 접근법을 짧은 리스트로 규정하는 것이다.
개발 팀은 이 짧은 리스트를 가지고 적은 양의 데이터와 속도를 적용, 개념 증명을 실시한다. 이런 개념 증명의 핵심 성공 요소 중 하나는 개발 용이성과 원하는 분석을 전달하는 유연성을 평가하는 것이다. 이후 데이터 스트림의 양과 속도를 증가시켜 성능과 안정성을 평가한다.
실시간 데이터 스트리밍은 도입 초기 단계의 기술이다. 그러나 향후 몇 년 간 이를 성공적으로 도입해 활용한 기업들은 경쟁력을 얻게 될 것이다.
* Isaac Sacolick은 애자일과 데브옵스, 데이터 과학 분야를 주로 다루는 전문 기고가다. 스타CIO의 대표이자 CIO닷컴 등에서 오랜 기간 블로거로 활약해왔다.dl-ciokorea@foundryco.com
