개요:
요즘 스마트 엣지 혹은 엣지 단에서의 고속 스트림 프로세싱과 같은 표현들이 많이 보입니다. 데이터 처리 파이프라인에서, 보통 엣지 디바이스들은 센서 네트워크 등의 데이터 수집 및 전달, 그리고 서버 혹은 클라우드는 머신 러닝 및 딥 러닝 등의 알고리즘으로 데이터를 분석하는 것으로 역할이 나뉘었습니다. 따라서, 앞에서 언급한 새로이 보이는 표현들이 왜 점점 더 자주 보이는지 궁금해 하시는 분들이 많을 것 같습니다.
이번 포스팅에서는 왜 이러한 새로운 시스템 디자인 트렌드가 생겼는지 살펴보고, 국내외 스마트 엣지 플랫폼에는 현재 어떠한 것들이 있는지 살펴 보겠습니다.
스마트 엣지와 스마트 시티, 홈, 팩토리 플랫폼:
인공지능을 이용해서 가정, 공장, 그리고 주거 및 인프라를 최적화하여 가용성을 높일 뿐만 아니라, 다양한 서비스를 제공하기 위한 플랫폼을 개발하기 위해서 스마트 홈, 팩토리, 시티 등의 새로운 분야들이 생겨났습니다. 이러한 새로운 개념의 플랫폼들은 다양한 센서들로부터 실시간으로 데이터를 수집하고, 처리해야 합니다. 여기서 기존의 데이터 파이프라인 디자인과 크게 달라지는 부분은 다양한 종류의 센서들이 큰 규모로 네트워크를 형성한다는 점입니다.
다수의 영상 및 고속의 센서 데이터 스트림을 집중화된 서버나 클라우드 시스템에서 처리하는 것은 서버나 클라우드 시스템을 그만큼 크게 증설해야만 할 뿐만 아니라, 증가하는 트래픽을 감당할 네트워크 증설까지 이루어져야 합니다. 예를 들면, 출입자 체온 측정의 경우, 만약에 엣지에서 출입자를 특정해서 출입자의 이미지와 측정된 체온을 스트리밍 한다면 네트워크 트래픽 및 서버의 부하가 크게 줄어들 것입니다. 이러한 센서 플랫폼을 도시 혹은 공장 규모로 확장해 보면, 엣지에서의 프로세싱이 주는 이점을 체감할 수 있을 것입니다.
스마트 엣지 플랫폼 및 스트리밍 플랫폼:
Gartner에서 2022년까지 80%이상의 기업 IoT 프로젝트는 IoT 디바이스에 AI를 내장하게 될 것이라고 예측하고 있습니다. 트렌드에 맞춰서 이미 많은 기업들이 스마트 엣지를 기존의 플랫폼에 더하기 위해 다양한 시도를 하고 있습니다. Google은 Cloud IT Core에 엣지에서 실시간 분석 및 ML 알고리즘들을 실행하기 위한 라이브러리를 더했습니다 [그림 1]. 이 라이브러리는 구글이 개발한 Edge TPU 디바이스에 최적화되어 있습니다. 트래픽 분산 및 실시간 처리 강화 뿐만 아니라, RAW 데이터를 로컬에 둠으로서 보안 향상 및 네트워크 장애 경우에 대한 시스템의 신뢰도를 향상시킬 목적입니다. 마이크로소프트도 Azure IoT Edge플랫폼[그림 2]이라는 구글과 유사한 컨셉의 플랫폼이 있고, 스마트 팩토리, 씨티 및 홈 각각을 타겟으로 하는 솔루션들을 국내 대기업들도 개발 및 판매를 진행 중입니다.
위에 언급한 라이브러리 및 플랫폼들은 유료입니다. 오픈 소스 (무료 플랫폼)의 경우에는 위의 경우들처럼 전체 파이프라인 및 다양한 엣지 디바이스 (센서 및 게이트웨이 혹은 헤비 및 라이트)에 대해서 개발 가능하도록 편리하게 패키징 된 것은 찾기 힘든 것 같습니다. 그동안 엣지 디바이스에서의 스트림 프로세싱은 데이터 수집 및 전달 기능에 좀 더 무게 중심이 있어 보입니다. 하지만, Apache Edgent 처럼 엣지 디바이스에서 좀 더 다양한 프로세싱을 염두에 둔 플랫폼들이 있지만, 실제로 사용해보면 연동성 면에서는 조금 미흡한 부분이 있습니다. 따라서, 일반 스트림 프로세싱 플렛폼 – Apache Flink, Spark structured streaming, Storm등도 연동성 측면에서 고려대상이 될 수 있습니다.
<그림1: Google Cloud Platform overview from https://cloud.google.com/iot-core/>
<그림 2: Microsoft Azure IoT platform heavy vs light edge concept from azure.microsoft.com>
아파치 스트리밍 플랫폼들
끝으로, 위에서 언급한 아파치 플랫폼 들에 대해 간략히 정리하겠습니다. 먼저, Hadoop 및 Spark에서의 Map-reduce 모델은 다량의 데이터를 노드에 나누어 적용할 오퍼레이션을 맵핑한 다음, 처리된 데이터를 다시 key, value 쌍으로 스토리지에 저장하는 모델입니다. 네트워크 및 I/O 오버헤드를 고려하면, 데이터가 일정 이상 크기여야 오버헤드를 상쇄하고 이득을 볼 수 있습니다. 따라서, 데이터의 batch를 가지고 처리합니다.
하지만, 실시간 처리에서는 단일 이벤트 처리 관점에서의 지연 시간을 봤을 때 적합하지 않을 수 있습니다. 데이터 Batch를 가지고 최적화된 모델은 throughput, 즉, 총 처리량에 최적화된 모델이고, 실시간 처리에서는 이벤트당 처리 시간 latency에 최적화가 이루어 져야 합니다.
실시간 처리에 최적화되어 가장 먼저 주목을 받은 것은 Apache Storm입니다. 하지만, 기존의 배치 프로세싱과 너무 다른 프로그래밍 인터페이스, 그리고 빅데이터의 가장 중요한 분야인 배치 프로세싱이 처음에 지원되지 않았습니다. 따라서, 다양한 경쟁 제품 들이 나오게 됩니다. Apache Flink는 기존의 Map-Reduce프레임 워크 들과 유사한 프로그래밍 인터페이스, 그리고 batch job을 통해 어느 정도 배치 프로세싱도 지원합니다.
실시간 스트리밍 처리의 인기에 힘입어, 가장 인기있는 빅데이터 플랫폼 중에 하나인 Apache Spark에도 스트리밍 프로세싱 기능이 추가되게 됩니다. 개념적으로 batch를 쪼갠 mini batch를 만들어서 이벤트당 지연시간을 최적화하는 개념으로 구현되었습니다. 그리고, Apache Edgent처럼 엣지 디바이스에 최적화된 스트리밍 플랫폼도 등장합니다. 가볍게 만들기위해, 단일 노드안에서 실행하는 경우에 필요치 않은 여러가지 부가 매커니즘들을 없애서 가볍게 만들고, 원격으로 재설정 및 기기 생존을 체크하는 heart beat 등의 기능과 함께 구현되어 있습니다.
