2017.08.02

“모든 스트리밍 데이터는 아파치 카프카로” 실시간 데이터 인기와 함께 급부상

Matt Asay | InfoWorld

느린 하둡 및 데이터 호수(Data Lake)에서 실시간 스트림으로 시장의 관심이 이동하면서 아파치 카프카가 꾸준히 부상하고 있다.

아파치 카프카(Kafka)가 순풍을 타고 있다. 레드몽크(Redmonk)의 핀탄 라이언이 전했듯이 작년 한해 동안 개발자 인기도가 무려 260% 뛰었다. 실시간 스트리밍 데이터에 대한 IoT 및 기타 엔터프라이즈의 수요가 널리 확산되고 나서부터 카프카의 인기는 수직 상승 중이다. 링크드인(LinkedIn)에서 탄생한 카프카의 엔지니어링 팀이 분사해 만든 컨플루언트(Confluent)가 아파치 카프카 프로젝트를 주도적으로 이끌고 있다.

하지만 컨플루언트뿐만이 아니다. 카프카의 중요성이 높아지면서 오브젝트로켓(ObjectRocket, 랙스페이스에 인수됨)의 공동 창업자인 케니 고먼과 에릭 비브가 시작한 이벤타도어(Eventador)를 포함한 많은 업체가 참여하고 있다. 오브젝트로켓은 몽고DB 데이터베이스를 서비스로 제공하는 반면 이벤타도어는 완전히 관리되는 형태의 카프카 서비스를 제공, 스트리밍 데이터에 대한 장벽을 더욱 낮추고 있다.

이벤타도어 공동 창업자들과의 대화를 통해 명확히 알 수 있는 사실은 "실시간으로 변이하는 데이터가 새로운 사용 사례와 새로운 가능성을 실현한다"는 면에서 스트리밍 데이터는 "새로운 시각"이 필요한, 기존과는 다른 영역이라는 점이다. 일단 기업이 스트리밍 데이터에 의존하게 되면 이전으로 되돌아가기는 어렵다. 핵심은 스트리밍 데이터에 의존하는 지점까지 가는 것이다.

카프카 대 하둡
아파치 하둡은 많이 사용되지만 현대 엔터프라이즈의 진화하는 요구 사항에 맞추기엔 속도가 너무 느리다. 고먼이 말했듯이 기업들은 "실시간에 가까울수록 데이터의 가치가 증가한다"는 것을 인식하고 있다. 기업이 제품 및 서비스에 실시간 데이터 흐름을 추가하기를 주저한다면 현실에 안주하지 않는 경쟁업체들에 비해 뒤처질 위험에 처하게 된다.

이 추세는 최대한 실시간에 가깝게, 안정적이고 확장성 있게 데이터를 제공하고 처리할 수 있는 기술의 도입을 이끌고 있다. 이 아키텍처만을 위한 새로운 프레임워크가 필요했고 그 필요성에 의해 탄생한 것이 아파치 카프카다.

아파치 스파크는 어떨까? 고먼이 지적했듯이 스파크는 실시간 처리가 가능하긴 하지만 최적화되어 있진 않다. 스파크 스트리밍 프레임워크는 본질적으로 여전히 마이크로 배치(micro-batch)다.

결국 남는 것은 카프카다. 고먼은 카프카가 "전송 및 처리 프레임워크 두 가지 모두를 위한 진정한 단발적(one-at-a-time) 처리 솔루션을 제공할 수 있다"고 설명했다. 그 외에 아파치 플링크(Flink), 빔(Beam)을 비롯한 부가적인 구성 요소들이 실시간 파이프라인의 기능을 확장해 손쉬운 변형과 집계, 필터링 등을 가능하게 해준다. 이 모든 요소가 결합되어 성숙하고 포괄적인 실시간 데이터 처리 시스템을 형성한다.

카프카의 펍-섭(pub-sub) 모델
이것이 중요한 이유는 카프카의 성격이 학습하고 구현하는 데 있지 않기 때문이다. 고먼이 강조했듯이 "아파치 카프카의 미덕은 강력한 API를 노출하면서 의미 체계가 아주 단순하다는 데 있다. 접근성이 매우 뛰어나다." 그뿐만 아니라 카프카의 API는 많은 프로그래밍 언어에서 구현되었으므로 각 개발자가 선호하는 언어에 드라이버가 있을 가능성이 높다.

카프카에는 토픽이라는 개념이 있다. 토픽은 단순히 데이터 스트림에 대한 네임스페이스다. 데이터를 토픽에 게시하기는 아주 간단하고, 라우팅, 확장성, 내구성, 가용성 등은 카프카가 알아서 처리한다. 여러 소비자가 토픽에 대한 구독을 조율하여 데이터를 불러오고 처리하거나 라우팅한다. 이러한 특성이 애플리케이션 개발 환경에 어떻게 반영되는지에 대해 묻자 고먼은 "카프카와 연동되는 애플리케이션을 구축하기는 아주 쉽다. 클라이언트 라이브러리가 통신의 세세한 부분을 대부분 처리하므로 개발자는 API를 활용해 데이터 스트림을 게시하거나 구독하면 된다"고 강조했다.

문제는 기술이 아니다. 중요한 것은 패러다임이다.

고먼은 개발자에게 정말 필요한 것은 "새로운 시각으로 스트리밍 데이터 사용에 대해 생각하는 것"이라고 말했다. "실시간으로 변이하는 데이터가 새로운 사용 사례와 새로운 기회를 실현하기 때문"이다.

실질적인 예를 보자. 클라이언트에서 차량 함께 타기 서비스의 이용자 수에 관한 데이터를 게시한다. 일단의 소비자가 이 스트림을 분석해서 동적 가격 결정을 위한 머신러닝 알고리즘을 수행하고, 이후 다른 일단의 소비자가 고객의 모바일 기기로 자동차의 위치와 가용 여부를 알리기 위해 이 데이터를 읽는다. 또 다른 소비자가 내부 대시보드에 이용자 수 데이터에 대한 집계 프레임워크를 전달한다. 카프카는 비즈니스가 요구하는 온갖 것들을 모두 실시간으로 전달할 수 있는 데이터 아키텍처에서 중심에 위치한다.

클라우드의 카프카
이는 개발자와 이들이 일하는 회사에게 좋지만 카프카에 대한 수요가 이벤타도어의 성공을 보장하지는 않는다. 카프카를 만든 장본인이라는 차별점을 가진 컨플루언트와 경쟁해야 하기 때문이다. 또한 컨플루언트 역시 이벤타도어의 카프카 서비스와 경쟁하게 될 가능성이 높은 클라우드 상품을 발표했다.


2017.08.02

“모든 스트리밍 데이터는 아파치 카프카로” 실시간 데이터 인기와 함께 급부상

Matt Asay | InfoWorld

느린 하둡 및 데이터 호수(Data Lake)에서 실시간 스트림으로 시장의 관심이 이동하면서 아파치 카프카가 꾸준히 부상하고 있다.

아파치 카프카(Kafka)가 순풍을 타고 있다. 레드몽크(Redmonk)의 핀탄 라이언이 전했듯이 작년 한해 동안 개발자 인기도가 무려 260% 뛰었다. 실시간 스트리밍 데이터에 대한 IoT 및 기타 엔터프라이즈의 수요가 널리 확산되고 나서부터 카프카의 인기는 수직 상승 중이다. 링크드인(LinkedIn)에서 탄생한 카프카의 엔지니어링 팀이 분사해 만든 컨플루언트(Confluent)가 아파치 카프카 프로젝트를 주도적으로 이끌고 있다.

하지만 컨플루언트뿐만이 아니다. 카프카의 중요성이 높아지면서 오브젝트로켓(ObjectRocket, 랙스페이스에 인수됨)의 공동 창업자인 케니 고먼과 에릭 비브가 시작한 이벤타도어(Eventador)를 포함한 많은 업체가 참여하고 있다. 오브젝트로켓은 몽고DB 데이터베이스를 서비스로 제공하는 반면 이벤타도어는 완전히 관리되는 형태의 카프카 서비스를 제공, 스트리밍 데이터에 대한 장벽을 더욱 낮추고 있다.

이벤타도어 공동 창업자들과의 대화를 통해 명확히 알 수 있는 사실은 "실시간으로 변이하는 데이터가 새로운 사용 사례와 새로운 가능성을 실현한다"는 면에서 스트리밍 데이터는 "새로운 시각"이 필요한, 기존과는 다른 영역이라는 점이다. 일단 기업이 스트리밍 데이터에 의존하게 되면 이전으로 되돌아가기는 어렵다. 핵심은 스트리밍 데이터에 의존하는 지점까지 가는 것이다.

카프카 대 하둡
아파치 하둡은 많이 사용되지만 현대 엔터프라이즈의 진화하는 요구 사항에 맞추기엔 속도가 너무 느리다. 고먼이 말했듯이 기업들은 "실시간에 가까울수록 데이터의 가치가 증가한다"는 것을 인식하고 있다. 기업이 제품 및 서비스에 실시간 데이터 흐름을 추가하기를 주저한다면 현실에 안주하지 않는 경쟁업체들에 비해 뒤처질 위험에 처하게 된다.

이 추세는 최대한 실시간에 가깝게, 안정적이고 확장성 있게 데이터를 제공하고 처리할 수 있는 기술의 도입을 이끌고 있다. 이 아키텍처만을 위한 새로운 프레임워크가 필요했고 그 필요성에 의해 탄생한 것이 아파치 카프카다.

아파치 스파크는 어떨까? 고먼이 지적했듯이 스파크는 실시간 처리가 가능하긴 하지만 최적화되어 있진 않다. 스파크 스트리밍 프레임워크는 본질적으로 여전히 마이크로 배치(micro-batch)다.

결국 남는 것은 카프카다. 고먼은 카프카가 "전송 및 처리 프레임워크 두 가지 모두를 위한 진정한 단발적(one-at-a-time) 처리 솔루션을 제공할 수 있다"고 설명했다. 그 외에 아파치 플링크(Flink), 빔(Beam)을 비롯한 부가적인 구성 요소들이 실시간 파이프라인의 기능을 확장해 손쉬운 변형과 집계, 필터링 등을 가능하게 해준다. 이 모든 요소가 결합되어 성숙하고 포괄적인 실시간 데이터 처리 시스템을 형성한다.

카프카의 펍-섭(pub-sub) 모델
이것이 중요한 이유는 카프카의 성격이 학습하고 구현하는 데 있지 않기 때문이다. 고먼이 강조했듯이 "아파치 카프카의 미덕은 강력한 API를 노출하면서 의미 체계가 아주 단순하다는 데 있다. 접근성이 매우 뛰어나다." 그뿐만 아니라 카프카의 API는 많은 프로그래밍 언어에서 구현되었으므로 각 개발자가 선호하는 언어에 드라이버가 있을 가능성이 높다.

카프카에는 토픽이라는 개념이 있다. 토픽은 단순히 데이터 스트림에 대한 네임스페이스다. 데이터를 토픽에 게시하기는 아주 간단하고, 라우팅, 확장성, 내구성, 가용성 등은 카프카가 알아서 처리한다. 여러 소비자가 토픽에 대한 구독을 조율하여 데이터를 불러오고 처리하거나 라우팅한다. 이러한 특성이 애플리케이션 개발 환경에 어떻게 반영되는지에 대해 묻자 고먼은 "카프카와 연동되는 애플리케이션을 구축하기는 아주 쉽다. 클라이언트 라이브러리가 통신의 세세한 부분을 대부분 처리하므로 개발자는 API를 활용해 데이터 스트림을 게시하거나 구독하면 된다"고 강조했다.

문제는 기술이 아니다. 중요한 것은 패러다임이다.

고먼은 개발자에게 정말 필요한 것은 "새로운 시각으로 스트리밍 데이터 사용에 대해 생각하는 것"이라고 말했다. "실시간으로 변이하는 데이터가 새로운 사용 사례와 새로운 기회를 실현하기 때문"이다.

실질적인 예를 보자. 클라이언트에서 차량 함께 타기 서비스의 이용자 수에 관한 데이터를 게시한다. 일단의 소비자가 이 스트림을 분석해서 동적 가격 결정을 위한 머신러닝 알고리즘을 수행하고, 이후 다른 일단의 소비자가 고객의 모바일 기기로 자동차의 위치와 가용 여부를 알리기 위해 이 데이터를 읽는다. 또 다른 소비자가 내부 대시보드에 이용자 수 데이터에 대한 집계 프레임워크를 전달한다. 카프카는 비즈니스가 요구하는 온갖 것들을 모두 실시간으로 전달할 수 있는 데이터 아키텍처에서 중심에 위치한다.

클라우드의 카프카
이는 개발자와 이들이 일하는 회사에게 좋지만 카프카에 대한 수요가 이벤타도어의 성공을 보장하지는 않는다. 카프카를 만든 장본인이라는 차별점을 가진 컨플루언트와 경쟁해야 하기 때문이다. 또한 컨플루언트 역시 이벤타도어의 카프카 서비스와 경쟁하게 될 가능성이 높은 클라우드 상품을 발표했다.


X