2018.10.01

데이터 스트리밍을 실시간 처리!··· 새 시대가 열린다

Isaac Sacolick | InfoWorld

각종 정보를 실시간으로 배포하는 데이터 소스는 이미 꽤 많다. 모바일 애플리케이션의 사용자 인터액션 이벤트, 금융 서비스 트랜젝션, 의료 모니터링 시스템, 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)이다.
 

2018.10.01

데이터 스트리밍을 실시간 처리!··· 새 시대가 열린다

Isaac Sacolick | InfoWorld

각종 정보를 실시간으로 배포하는 데이터 소스는 이미 꽤 많다. 모바일 애플리케이션의 사용자 인터액션 이벤트, 금융 서비스 트랜젝션, 의료 모니터링 시스템, 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)이다.
 

X