KR20230136458A - 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처 - Google Patents

Abstract

영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처로,
적어도 둘 이상의 모듈; 및 상기 복수 개의 모듈의 동작과 제어를 수행하는 런타임을 포함하며, 상기 모듈간 데이터 흐름은 분리된 채, 상기 런타임은 상기 모듈을 제어하는 것을 특징으로 하는 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처가 제공된다.

Description

영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처 {Microservices-based edge device architecture for video analytics}

본 발명은 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처에 관한 것으로, 보다 상세하게는 다중 어플리케이션, 멀티 테넌시를 지원하기 위한 마이크로서비스 기반 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처에 관한 것이다.

오늘날 비디오 카메라 및 기타 엣지 단말의 유비쿼터스 배치와 함께 엣지 컴퓨팅(edge computing) 발전이 놀라운 속도로 진행되고 있다. 그러나 아직 개발되지 않은 엣지에서 실시간 비디오 분석 기술은 제한된 리소스 집합으로 다중 테넌트, 다중 애플리케이션 시나리오를 처리하는 기술이지만, 종래 기술은 다중 테넌트, 다중 애플리케이션 시나리오를 처리함에 있어 충분한 성능을 제공하지 못하거나, 워크로드를 처리하기 위해 엣지 또는 클라우드 서버에 너무 많이 의존하는 문제가 있다.

최근 몇 년 동안 엣지 컴퓨팅은 분산 시스템 영역에서 관심 분야로 부상했다. 클라우드에서 개념과 아이디어를 차용한 엣지 컴퓨팅은 강력한 컴퓨팅 플랫폼을 제공하지만 추가 대기 시간이 필요하지 않다는 장점이 있다. 이러한 엣지 컴퓨팅의 장점은 엄격한 성능 및 대기 시간 요구 사항이 있는 비디오 분석(Video Ananlysis, VA) 응용 기술(애플리케이션)과 완벽하게 일치하는 장점 있다.

Jetson Nano(비특허 선행문헌 1), Jetson TX2(비특허 선행문헌 2) 및 최신 폰(phone)과 같은 엣지 단말는 그 어느 때보다 향상된 처리 능력을 갖추고 있다. CPU와 GPU가 더 빨라질 뿐만 아니라 사용 중인 SoC도 딥 러닝 작업을 가속화하기 위해 신경 엔진(Apple) 또는 AI 엔진(Qualcomm)이라고 하는 특수 NPU(신경 처리 디바이스)를 통합하고 있다(비특허 선행문헌 3 및 4 참고). 그 결과 불과 몇 년 전만 해도 불가능했던 더 복잡하고 심층적인 ML 모델을 처리할 수 있다.

엣지 컴퓨팅을 위한 핵심 애플리케이션(killer application, 비특허 선행문헌 5 참조)이라고 불리는 비디오 분석 기술은 많은 관심을 받았으며, 이러한 비디오 분석기술은 제한된 디바이스에서 실행하기 위한 필수 기계 학습 모델의 최적화, 압축 및 양자화부터 신중하게 설계된 워크로드 스케줄링 시스템, 복잡한 엣지 클라우드 분산 배치에 이르기까지 폭넓은 범위로 연구되고 있다.

엣지 컴퓨팅을 위한 비디오 분석은, 주어진 애플리케이션 시나리오의 필수 요구 사항을 달성하도록 구성되는데, 간단히 말해서 애플리케이션 구성 요소를 최적화하는 데 중점을 두는 작업과 실시간 비디오 분석 사용 사례를 지원하기 위해 새로운 시스템이나 아키텍처를 제안하는 작업으로 나눌 수 있다.

이러한 모든 접근 방식은 VA 처리에 특정 측면에서 장점을 제공하지만, 일반적으로 대부분 정적인 환경에서 상대적으로 특정한 응용 프로그램만 분석, 조사하는 한계가 있다. 즉, 단일 응용 프로그램이기는 하지만 카메라 감시 시스템의 역동성은 끊임없이 변화하기 때문에 이러한 측면을 과소평가하면 안되지만, 엣지 단말에서 다중 테넌시 및 다중 응용 프로그램에 대한 지원을 조사하는 선행연구와 기술은 거의 없다.

실제로 다중 사용자 환경에 대해 여러 애플리케이션을 지원하는 것은 단일 애플리케이션에 대한 쿼리를 관리하는 것보다 더 어렵우므로, 이를 위해서는 SLO(서비스 수준 목표) 목표를 충족하기에 충분한 성능으로 VA를 위한 아키텍쳐가 필요한다.

엣지 VA를 용이하게 하기 위해 Distream 및 EdgeEye와 같은 이전 작업은 종종 엣지 서버의 도움을 활용하여 분석 파이프라인의 많은 부분을 처리한다.

Distream은 엣지 단말에 파이프라인 실행의 작은 부분을 할당하여 작업의 수직 분산을 생성하는 동시에 엣지 단말 간에 수평으로 요청 워크로드의 균형을 맞춘다. 하지만, 모놀리식 설계에 기인하는 이러한 아키텍처에서는 여러 애플리케이션에 대한 지원이 부족하다는 문제가 있다.

반면 EdgeEye는 엣지 서버가 계산을 수행하도록 하여 두 부분을 설계하는 반면, 엣지 단말는 파이프라인을 정의 및 제어하고 서버 측에서 원격 서비스에 요청한다. 이 접근 방식은 다중 애플리케이션을 지원할 수 있지만 인접 엣지 단말의 리소스를 충분히 활용하지 못하는 문제가 있다. 즉, 잠재적 컴퓨팅 리소스의 수평적 리소스 프로비저닝이 처리되지 않는다.

따라서, 다중 어플리케이션, 멀티 테넌시를 지원하기 위한 새로운 비디오 분석 아키텍쳐에 대한 개발이 필요하다.

본 발명이 해결하고자 하는 과제는, 엣지 단말에서 다중 어플리케이션, 멀티 테넌시를 지원하기 위한 마이크로서비스 기반 비디오 분석 아키텍처를 제공하는 것이다.

상기 과제를 해결하기 위하여, 본 발명은 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처로, 적어도 둘 이상의 모듈; 및 상기 복수 개의 모듈의 동작과 제어를 수행하는 런타임을 포함하며, 상기 모듈간 데이터 흐름은 분리된 채, 상기 런타임은 상기 모듈을 제어하는 것을 특징으로 하는 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처를 제공한다.

본 발명의 일 실시예에서, 상기 런타임은 상기 모듈에 처리되어야 하는 비디오 프레임만 있는 경우 상기 모듈을 실행한다.

본 발명의 일 실시예에서, 상기 런타임은 디바이스 당 하나씩 포함하며, 상기 복수 개의 모듈은 대기열을 공유한다.

본 발명의 일 실시예에서, 상기 복수 개의 모듈은 디코더, 추론부, 후처리기, 트랙커, ReID, Rol 모니터, 및 자르기 모듈을 포함한다.

본 발명에 따르면, 네트워크 엣지 중에서도 가장 말단인 엣지 디바이스에서 비디오 분석 파이프라인(video analytic pipeline)을 수행함으로써 엣지 단말 자원을 효율적으로 활용하여 엣지 서버 또는 클라우드의 의존도를 낮출 수 있으며, 엣지 서버 또는 클라우드까지의 네트워크 대역폭을 절약할 수 있다. 따라서, 본 발명에 따른 비디오 분석 아키텍처를 통해 다수의 엣지 자원을 활용하여, 그 효율성을 증가시킬 수 있다.

도 1은 본 발명에 따른 아키텍쳐의 노드와 런타입의 개략도이다.
도 2는 제어 플레인에서 지원하는 주요 API 엔드포인트의 요약 결과를 보여준다.
도 3은 런타임에 두 개의 모듈을 생성하기 위한 요청의 예이다.
도 4는 본 발명의 일 실시예에 따른 시스템의 모듈 상호 작용 및 기본 구성 요소의 블록도이다.
도 5는 본 발명의 일 실시예에 따른 실험 구성을 설명하는 도면이다.
도 6은 본 발명의 일 실시예에 대한 실험 시나리오이다.
도 7은 케이스 A-C의 비교 스킴이고, 도 8은 비교예로서의 비디오파이프이다.
도 9는 단일 디바이스, 단일 애플리케이션에 대한 성능평가 결과이다.
도 10은 도 9 환경에서 두 개의 애플리케이션을 사용하는 경우의 성능 평가 결과이다.
도 11은 세 개의 애플리케이션(Track & Reid & ROI)을 수해하는 단일 디바이스의 성능평가 결과이다.
도 12는 2개 및 3개의 애플리케이션을 하나의 비디오 소스에 적용한 이중 장치에 대한 성능평가 결과이다.
도 13은 통신 오버헤드 평가 결과이다.

이하, 도면을 참조하여 본 발명의 구체적인 실시형태를 설명하기로 한다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.

본 발명을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 또한 본 발명의 기술적 사상은 청구범위에 의해 결정되며, 이하의 실시 예는 본 발명의 기술적 사상을 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 효율적으로 설명하기 위한 일 수단일 뿐이다.

상기 과제를 해결하기 위하여, 본 발명에 따른 비디오 분석 아키텍쳐는 이미 배치된 시스템에서 새로운 응용 프로그램을 동적으로 추가하고 실행할 수 있는 기능과 다른 인접 엣지 단말에 파이프라인을 수평으로 배치하는 기능을 가지며, 그 결과 본 발명은 디바이스 당 여러 개의 동시 응용 프로그램을 사용하여 평가하는 프로토타입을 구현, 생성하는 아키텍쳐를 제공한다. 그 결과 본 발명에 따르면, 기존 작업보다 더 많은 유연성을 제공하여 대기 시간이 20% 개선되고 처리량이 3.9배 증가하였는데, 이는 이하 본다 상세히 설명한다.

본 발명의 일 실시예에서는 외부 컴퓨팅 지원 없이도 카메라 클러스터 내 리소스를 효율적으로 활용할 수 있는 스마트 카메라 제품군에서 실행되는 빠르고 유연한 VA 아키텍처를 제공하는 것이다.

본 발명의 일 실시예에서 실시간 VA용 스마트 카메라(예: Nividia Jetson nano) 집합에서 작동하는 서버리스 마이크로서비스 아키텍처를 제안하며, 다음을 지원하는 조건을 갖는다.

1. 동적 멀티테넌트, 다중 애플리케이션 사용

2. 엣지 단말 전반에 걸쳐 수평적으로 협업 파이프라인 배치 및 실행

3. 보다 효율적인 활용을 위해 동일한 디바이스에서 실행되는 애플리케이션 간에 파이프라인 구성 요소 공유

본 발명은 실시간 엣지 VA 서비스를 제공하기 위해 서버리스(serverless) 기능과 마이크로 서비스 개념을 조합하였으며, 이것은 종래 기술과 구분되는 새로운 시도이다. 즉, 이전 작업은 서버리스 마이크로서비스 아키텍처를 통한 멀티 테넌시/애플리케이션 지원을 위해 서버 측에 크게 의존했지만 엣지 단말의 리소스는 탐색되지 않았다. 하지만, 본 발명은 데이터 플레인과 컨트롤 플레인 작업을 모두 처리하는 런타임을 기반으로 하는 시스템의 프로토타입을 제작하여 최소한의 오버헤드로 여러 모듈을 동시에 실행할 수 있었으며, 그 결과는 기존 작업에 비해 대기 시간이 20% 개선되고 처리량이 3.9배 증가하는 것으로 나타났다.

이하 본 발명에 따른 아키텍쳐를 보다 상세히 설명한다.

아키텍쳐 구조

마이크로서비스 기반한 본 발명의 아키텍처는 VA 구성 요소를 자체 독립 모듈로 분할한다. 각 구성 요소를 자체 모듈로 순수하게 배치하는 것 외에도 더 나아가 네트워크 비용 없이 동일 디바이스에서 모듈간 상호작용을 가능하게 하는 FaaS 런타임 개념을 본 발명은 활용한다. 이로써 디바이스당 그리고 "마이크로서비스"당 복수 모듈을 갖는다.

도 1은 본 발명에 따른 아키텍쳐의 노드와 런타입의 개략도이다. 여기에서 사용환경에서의 각 디바이스는 클러스터에서 노드로 표시되며, 모든 노드에는 컨테이너 런타임 기능을 수행하는 도커 컨테이터(Docker Container)와, 애플리케이션을 호스팅하는 단일 컨테이너만을 갖는다. 본 명세서에서는 이들 응용 프로그램(애플리케이션)을 "런타임"으로 지칭하며, 런타임은 모듈의 동작과 제어를 수행한다. 또한, 모듈은 런타임에서 생성되는 것으로, 이것은 가장 작은 구성 요소인 기능으로 구성되는데, 이것은 본 발명에서 가장 작은 빌딩 블록이다.

도 1을 참조하면, 녹색은 런타임을 나타내고 빨간색은 모듈(예: VAP 구성 요소)을 나타낸다. 또한, 본 발명의 일 실시예에서 런타임에는 실행을 제어하는 제어 메커니즘을 가지며, 예를 들어 모듈 실행 제어 및 모듈 배치, 모듈 구성이 실행 제어의 예이다.

본 발명의 일 실시예에 따르면, 모듈에서의 비디오 프레임은 제어 흐름을 알 필요 없이 처리되는데, 각 모듈은 다음 요소가 동일 디바이스에 있는지 또는 네트워크에 있는지 알지 못한다. 즉, 본 발명의 일 실시에에 따른 아키텍쳐의 제어 흐름에서 데이터 흐름은 분리된다고 볼 수 있다.

또한, 본 발명에서 각 디바이스에는, 디바이스당 하나의 런타임, 그리고 런타임 하나에는 많은 모듈을 가지며, 서버리스 방법과 같이 시스템의 각 모듈은 처리할 비디오 프레임이 있을 때만 실행된다.

런타임

기존 마이크로서비스 아키텍처에서 동일한 노드에서 두 개의 모듈을 배치하고 실행할 경우 각 모듈은 자체 컨테이너 프로세스에서 실행된다. 하지만, 이러한 분리는 데이터가 두 모듈 간에 전송될 때마다 모듈이 동일한 노드에 같은 위치에 있더라도 네트워킹을 거쳐야 함을 의미한다. 모듈간 분리는 보안에 중요하지만 본 발명은 대상 환경인 폐쇄된 환경의 동일한 컨테이너에서 두 가지를 모두 실행하는 것은 문제가 되지 않는점에 주목하였다.

따라서, 본 발명의 일 실시예에서는 FaaS 런타임과 유사하게 작동하도록 컨테이너당 단일 런타임만 실행되며, 이 단일 런타임에서는 여러 모듈이 배치될 수 있다.

또한, 본 발명의 일 실시예에 따른 런타임은 제어 및 데이터 플레인에 동작하여, 모듈 배치/구성, 파이프라인 실행 제어, 모듈 통신 제어 및 모듈 호스팅과 같은 기능을 모두 수행하며, 이는 도 1에 도시된 바와 같으며, 도 1에서 색상은 런타임(녹색)과 모듈(보라색)에서 제어되는 변수를 구별한다.

제어 플레인(Control Plane)

제어 플레인은 모듈 간에 공유 런타임이 있기 때문에 필요하다. 하지만, 이러한 공유 런타임 때문에 Kubbernetes 플랫폼을 사용하여 파이프라인 배치와 구성을 특정할 수 없었다.

하지만, 본 발명은 통상의 제어 플레인을 사용하기 때문에, 런타임의 일반 오케스트레이션과 같은 Kubernetes 기능의 이점을 유지하면서보다 많은 사용자 지정 옵션을 가질 수 있다.

도 2는 제어 플레인에서 지원하는 주요 API 엔드포인트의 요약 결과를 보여준다. 이들 엔드포인트는 파이프라인의 실행과 배치를 제어하기 위하여 사용자가 상호작용하여야 하는 것들이다.

가장 중요한 것으로, 업데이트 엔드포인트를 사용하면 파이프라인이 실행되는 동안 수정할 수 있다는 점이다. 예를 들어 이미 처리 중인 오브젝트 감지 모듈에 새로운 애플리케이션을 추가하는 경우, 도 2의 마지막 항목인 sink()는 파이프라인에서 데이터를 앞으로 이동하기 위해 모듈이 호출하는 런타임 함수가 된다.

도 3은 런타임에 두 개의 모듈을 생성하기 위한 요청의 예이다. 여기에서 일부 세부 사항은 생략되었다.

도 3은 키인 모듈로 구성된 딕셔너리이며, 그 값은 모듈에 대한 특정 인수와 런타임에 대한 공통 인수를 나타낸다. 도 3의 예에서 본 발명은 디코더와 추론이라는 두 요소의 파이프라인을 만들고 디코더는 추론을 출력 모듈 중 하나로 사용한다. 이는 멀티테넌트 사용 사례를 허용하는 일대일 매핑이 아니라 모듈이 다중 입력과 다중 출력을 모두 가질 수 있는 복잡한 파이프라인을 지원할 수 있음을 나타낸다.

데이터 플레인

본 발명에 따른 아키텍쳐에서 모듈 간 통신은 런타임에서 처리하는 또 다른 기능으로, 모듈 간의 연결을 단순화하고 최적화한다.

도 4는 본 발명의 일 실시예에 따른 시스템의 모듈 상호 작용 및 기본 구성 요소의 블록도이다.

도 4를 참조하면, 본 발명의 일 실시에에 따른 시스템은 2개의 디바이스로, 첫 번째 디바이스는 두 개의 모듈을 처리하고 두 번째 디바이스는 하나의 모듈을 처리하도록 나눠졌다. 데이터가 삭제되지 않음을 보장하기 위해 입력 및 출력 대기열을 갖도록 각 모듈을 설계하였다.

정상 작동 중에 이러한 대기열은 일반적으로 모듈에 의해 병목 현상이 발생하지 않는 한 거의 비어 있어야 한다. 또한 일괄 처리를 위해 여러 요청에 대해 대기열을 함께 사용할 수 있다. .

본 발명에서 이러한 대기열은 모듈 간의 통신 매체 역할도 하며, 런타임은 target_module 및 message의 두 필드로 구성된 모듈의 출력 대기열에서 항목을 읽는다.

런타임은 대상 모듈이 동일한 런타임에 같은 위치에 있는지 확인하며, 확인 후 그렇다면 메시지를 대상 모듈의 입력 대기열에 넣습니다. 그렇지 않으면 메시지가 직렬화되고 네트워크 호출을 사용하여 대상 모듈을 담당하는 런타임으로 전달된다.

모듈 및 기능

모듈은 모듈 내의 기능이 모듈의 목적에 절대적으로 필요한 기능만 있도록 설계된다. 도 4에서 볼 수 있듯이 모듈은 일반적으로 몇 가지 기능과 입력/출력 대기열로 구성됩니다.

오브젝트를 다음 모듈로 보내는 것과 같은 다른 특징은 제어 플랜에서 수행되며, 이를 통해 모듈 개발자는 나머지 구조나 흐름에 대해 걱정하지 않고 특정 기능 실현에만 집중할 수 있다. 이러한 추출에 의하여 본 발명은 확장 가능한 시스템을 구현할 수 있다.

실시예

모듈 구성

본 발명의 일 실시예에 따른 모듈들은 디코더, 추론부, 후처리기, 트랙커, ReID, Rol 모니터, 그리고 자르기 모듈이다. 여거에서 디코더는 비디오 프레임을 디코딩, 크기 조정, 트랜스포즈하며. 추론부(Inference)는 비디오 프레임에 대한 예측을 출력하여 ResNet10 모델이 탑재된 Triton Inference 서버를 사용하여 프레임에 어떤 객체가 있는지 알려준다. 후처리기(Postprocessor)는 예측의 신뢰도 및 클래스 정보와 함께 경계 상자 정보를 출력한다. 또한 트랙커는 IoUtracker 또는 SORT를 사용하여 궤적을 출력하고, Reid는 감지된 객체를 특징 벡터로 변환하여 코사인 유사성을 출력한다. 또한 ROI 모니터는 물체가 관심 영역에 있는지 확인하며 자르기(Crop) 모듈은 이미지의 경계 상자 위치를 자른다.

본 발명의 일 실시예에서는 Triton 추론 서버를 DNN 예측으로 활용하였는데, 이는 파이프라인의 다양한 모듈과 관련된 다양한 DNN 모델이 있기 때문에 모듈에 이를 캡슐화하는 것이 일응 비효율적이지만, 추론 서버는 모듈 외부에서 모델 관리를 처리하게 된다. 만약, 이렇지 않는다면 VAP에 변경 사항이 있을 때마다 DNN 모델 및 해당 라이브러리를 로드 및 언로드하여 시스템이 엄청난 어려움을 겪을 것입니다.

도 5는 본 발명의 일 실시예에 따른 실험 구성을 설명하는 도면이다.

도 5를 참조하면, 본 실험에서는 최대 5대의 카메라로 구성된 Jetson Nano 테스트베드를 사용하였고, docker를 기반으로 활용하고 k3를 활용하여 컨테이너를 배치하였다. 또한 비디오 세트는 15FPS로 재생되며 약 5000프레임으로 구성되며, 프레임당 e2e 지연 시간(ms), 초당 프레임의 처리량, 초 단위의 오버헤드를 비교하였다.

도 6은 본 발명의 일 실시예에 대한 실험 시나리오이다.

도 6을 참조하면, 먼저 다양한 애플리케이션(단일, 이중, 삼중)으로 단일 디바이스를 평가하고, 그 다음에 다양한 응용 프로그램을 가진 이중 디바이스를 평가하였다. 디바이스 수가 증가함에 따라 비디오 입력 스트림의 수도 증가하는 점에 주목할 필요가 있다.

도 7은 케이스 A-C의 비교 스킴이고, 도 8은 비교예로서의 비디오파이프이다.

도 7을 참조하면. 케이스 A는 고립된 모놀리식 접근 방식, 케이스 B는 공유 모듈 접근 방식, 케이스 C는 본 발명으로 VAP 모듈이 에지 디자이스에서 수행되는 방식이다. 특히 본 발명은 모듈당 하나의 런타임을 사용하고, 동기화된 프레임 처리를 사용하는 비디오파이프과 달리, 디바이스당 하나의 런타임만을 사용하면서도 비디오파이프의 핵심 기능을 모두 구현할 수 있다.

도 9는 단일 디바이스, 단일 애플리케이션에 대한 성능평가 결과이다.

도 9를 참조하면, 애플리케이션이 케이스 A에 하나만 있기 때문에 케이스 B도 본질적으로 동일합니다. Y는 e2e 지연 시간(초)을 표시하고 x는 프레임 인덱스를 표시한다. 도 9의 결과를 통하여 전체 비디오에서 성능이 다소 일관성이 있음을 알 수 있다. 특히 reid 애플리케이션은 다른 애플리케이션에 비해 2개의 GPU 집약적 DNN 추론이 필요하기 때문에 e2e 지연 시간이 가장 큰 것을 알 수 있다.

도 10은 도 9 환경에서 두 개의 애플리케이션을 사용하는 경우의 성능 평가 결과이다.

도 10에서 e2e 지연 시간(초)을 표시하고 x는 프레임 인덱스를 표시하며, 케이스 A의 분리된 VAP를 가지며, 중복된 모듈을 실행한다. 또한 빨간색 선은 케이스 A의 reid 애플리케이션을 보여준다. 장치가 다른 트랙 응용 프로그램을 제공할 때 리소스 경쟁이 발생하므로 50%의 추가 e2e 대기 시간을 나타낸다.

파란색 선은 케이스 A의 트랙 애플리케이션을 보여줍니다. e2e 대기 시간은 기하급수적으로 증가하고 비디오 프레임이 모든 모듈에서 큰 대기열을 생성함에 따라 결국 충돌하게 된다. 케이스 B에서, VAP 모듈을 공유하며, 따라서 보라색과 갈색의 두 응용 프로그램은 모두 짧은 e2e 대기 시간으로 VAP를 실행할 수 있다.

도 11은 세 개의 애플리케이션(Track & Reid & ROI)을 수해하는 단일 디바이스의 성능평가 결과이다.

도 11을 참조하면, Y는 e2e 지연 시간(초)을 표시하고 x는 프레임 인덱스를 표시한다. 케이스 A의 경우 트랙 응용 프로그램 시작에서긴 지연을 생성, 다른 두 응용 프로그램에 도미노 효과에 의하여 긴 지연을 일어난다. 모든 애플리케이션에서 모든 대기열이 채워진 후에야 reid 및 roi 애플리케이션이 높은 e2e 지연 시간으로 안정화된다.

케이스 B의 경우 듀얼 애플리케이션 시나리오에 비해 e2e가 약간 높지만 지속적으로 15fps를 제공할 수 있는 것을 알 수 있다.

도 12는 2개 및 3개의 애플리케이션을 하나의 비디오 소스에 적용한 이중 장치에 대한 성능평가 결과이다.

도 12를 참조하면, 둘 이상의 장치가 관련된 분산 시나리오를 실험하였고, 비교를 위해 본 발명의 아키텍처에 가장 가까운 비교예인 VideoPipe가 도 12에도 도시된다.

본 실험에서는 두세 가지 응용 프로그램을 실험하였다. 그래프 플롯은 2/3 애플리케이션 중에서 e2 레이턴시가 많은 컴퓨팅 집약적 애플리케이션만을 사용하였다. VideoPipe의 경우 가장 무거운 애플리케이션(예: Reid)의 e2e 지연 시간은 평균 0.25초 정도였다. 또한 3개의 애플리케이션 시나리오는 동시에 처리해야 하는 추가 애플리케이션으로 인해 e2e 대기 시간에 약간 추가가 있음을 알 수 있다. 이 값은 주로 원격 호출로 인해 단일 애플리케이션 시나리오보다 약간 큰 값이다.

본 발명에 따른 시나리오인 케이스 C의 경우 VideoPipe 방식에 비해 e2e 지연 시간(50ms)이 20% 적은 것을 알 수 있다. 이 차이는 두 개의 모듈이 동일한 장치에 있는 경우 네트워크 호출을 피하기 때문이다.

하지만, e2e 그래프는 파이프라인의 시작부터 끝까지 프레임이 소비된 시간만 보여준다. 두 가지 접근 방식의 FPS를 살펴보면 각 구성 요소에서 동기화된 프레임 처리로 인해 VideoPipe의 평균 FPS는 입력 프레임 속도가 15로 설정되어 있을 때 4FPS에도 가깝지 않았는데, 이것은 들어오는 프레임의 약 75% 손실을 의미한다.

하지만 본 발명에 따른 케이스 C는 비차단 실행으로 인해 지연 시간의 차이에 관계없이 15FPS의 처리량을 갖는다.

도 13은 통신 오버헤드 평가 결과이다.

도 13을 참조하면, 전송 비용이 발생하는 여러 장치에 모듈을 배치할 때 Reid 애플리케이션을 분석하고 아키텍처 오버헤드를 분석하였다. 이는 1) 메시지 직렬화, 2) 전송, 3) 메시지 역직렬화의 세 단계로 표현되며, 측정은 TO로 표시되고 누적 오버헤드는 TCO로 표시된다.

도 13의 결과는 오버헤드의 누적 대기 시간을 보여주는데, 중간의 빨간색 선은 두 장치 간의 네트워크 전송을 나타낸다. .

여기에는 VideoPipe는 각 모듈을 자체 런타임에 배치하므로 모듈이 동일한 장치에 있더라도 네트워크 요청을 사용해야 하는데, 이는 추가 오버헤드로 직접 변환된다. 하지만, 본 발명과 같이 같은 위치에 있는 모듈에 단일 런타임을 사용하면 시스템 설계에서 이러한 오버헤드를 완전히 피할 수 있다.

도 14는 본 발명에 따른 아키텍쳐의 확장성을 분석한 결과이다.

도 14를 참조하면, 2~5대의 카메라를 사용하는 Reid & Tracking 애플리케이션으로 구성된 듀얼 애플리케이션 시나리오를 실행하였다. 도 14에서 장치의 수가 증가함에 따라 대기 시간이 증가하는 것을 볼 수 있다. 이 작업에서는 모듈을 여러 장치에 수동으로 배치하였다.

이전 실험 결과에서 이미 보았듯이 3개의 추적 및 리드 및 ROI를 모두 실행하는 것은, 입력 15FPS 요구 사항을 손상시키지 않는데 있어 거의 한계 수준인 것을 알 수 있다.

도 14의 결과는 67ms 데드라인을 충족하면서 5개의 디바이스에 대하여 2개와 3개 디바이스 등의 다양한 조합이 가능함을 알 수 있다. 따라서, 본 발명에 따른 아키텍처는, 확장성을 허용하지만 사용 가능한 리소스를 요청된 응용 프로그램과 일치시켜 보다 정교한 서비스 오케스트레이션 메커니즘이라는 효과를 얻을 수 있다는 것을 시사한다.

Claims (5)

1. 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처로,
   적어도 둘 이상의 모듈; 및
   상기 복수 개의 모듈의 동작과 제어를 수행하는 런타임을 포함하며,
   상기 모듈간 데이터 흐름은 분리된 채, 상기 런타임은 상기 모듈을 제어하는 것을 특징으로 하는 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처.
2. 제 1항에 있어서,
   상기 런타임은 상기 모듈에 처리되어야 하는 비디오 프레임만 있는 경우 상기 모듈을 실행하는 것을 특징으로 하는 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처.
3. 제 1항에 있어서,
   상기 런타임은 디바이스 당 하나씩 포함되는 것을 특징으로 하는 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처.
4. 제 1항에 있어서,
   상기 복수 개의 모듈은 대기열을 공유하는 것을 특징으로 하는 마이크로서비스 기반 엣지 디바이스 아키텍처.
5. 제 1항에 있어서,
   상기 복수 개의 모듈은 디코더, 추론부, 후처리기, 트랙커, ReID, Rol 모니터, 및 자르기 모듈을 포함하는 것을 특징으로 하는 엣지 디바이스 아키텍처.