Ⅰ. 서론
유연하고, 유지 보수 가능하며, 확장 가능한 소프트웨어 애플리케이션 및 정보 시스템을 구축하기 위한 분야에 있어서 서비스 지향 아키텍처, 특히 마이크로서비스 아키텍처(MSA)가 많은 기여를 해왔다 [1]. 자동차 소프트웨어 시스템이 현대 자율차량의 개발에 똑같이 복잡하고 중요해지고 있어서, MSA 개념은 그러한 시스템의 구조에 긍정적인 영향을 미칠 수 있다. 몇 가지 잠재적 장점은 (1) 기능 재사용, (2) 행위보다는 데이터에 초점을 맞추고, (3) 캡슐화되고 독립적인 서비스 행동, (4) 지속적인 서비스 통합 및 제공, (5) 차량 내 계층적 기능과 소프트웨어 아키텍처, (6) 명확하고 명시적인 서비스 문서, (7) 전자 제어 장치(ECU), 에지 노드, 또는 클라우드 서버로 서비스 배포에 있어 유연성 등이 있다.[2]
MSA는 기존의 부피가 큰 Monolithic기반 차량 소프트웨어 서비스의 복잡성을 감소시키지만, 그럼에도 불구하고, 원하는 마이크로서비스를 가져오기 위한 기초 통신 아키텍처 부분에 있어 비효율적인 기존의 주소 기반프로토콜(TCP/IP 및 WAVE와 같은)을 활용한다. TCP/IP 프로토콜 스택은 빠르게 변화하는 토폴로지와 자체 및 도로변 장치(RSU)와의 무선 채널 오류로 인한 잦은 간헐적 연결 오류 때문에 차량 통신 환경에는 효과적이지 않은 것으로 나타나 있다. 반면에, 차량 환경의 무선 액세스(WAVE) 프로토콜 스택은 새로운 경량 무선액세스 단기 메시지 프로토콜(WSMP)을 통해 IP 오버헤드 없이 시간에 민감한 짧은 중요한 안전 메시지 및 트래픽 관리 메시지의 교환을 지원하고 있다. [3]. 또한 매체접근제어(MAC) 계층에서 IEEE 802.11p는[4] 기본 서비스세트(BSS)의 구성원이 아닌 노드가 예비 인증 및 연결 없이 데이터를 전송할 수 있도록 허용함으로써 적대적인 차량 환경에서 통신을 용이하게 하는 새로운 작동 모드를 추가하였다. Outside the Context of a BSS (OCB)[3]로 언급되는 이 모드는 접속 지연과 신호 오버헤드를 현저하게 감소시키기 때문에 차량 네트워크에 효과적인 것으로 평가된다. 그러나 차량 네트워크의 잦은 동적 환경에 대처하기 위한 이러한 여러 시도를 감안하더라도 WAVE 스택은 기존의 TCP/ UDP/IPv6 프로토콜을 사용하여 비안전성 데이터를 교환하고 있다.
오히려 시간과 공간 관련성(예: 위치 기반 서비스, 도로 정체 정보)으로 인해 많은 차량 서비스가 네트워크 내 데이터 캐싱 및 복제를 이용하는 정보 보급을 위한 소비자 중심 프로토콜의 혜택을 받을 것이다.[5] 후자의 개념은 정보 중심 네트워킹(ICN)의 주요 특징 중 하나이며, 애플리케이션, 서비스 및 네트워크가 정보를 주요 기본요소로 사용하여 상호 작용할 수 있도록 하는 미래 인터넷 아키텍처를 위해 구상된 새로운 패러다임이다. ICN 은 IP 주소로 식별된 호스트 간의 엔드투엔드 통신을 유지하는 대신 명명된 컨텐츠를 찾아 전달하는 데 초점을 맞추고 있다.
따라서 본 논문에서는 독립적 차량을 위한 MSA와 함께 ICN 패러다임을 기본 통신 아키텍처로 활용할 것을 제안한다. 본 연구에서는 자율 주행 차량 시스템을 구축하기 위한 마이크로서비스 접근방식이 효과적인 서비스활용, 효율적인 분배 및 균일한 서비스 발견을 달성하기 위해 클린 상태 ICN을 활용해야 함을 주장한다. 유연하고 확장 가능한 컴퓨팅, 스토리지 및 네트워킹의 주요 요소들을 통해 가상화된 ICN 패러다임에 기반한 차량 마이크로서비스를 설계하면 미래 차량 클라우드에서 컨텐츠 지향 마이크로서비스와 애플리케이션을 지배하는 설계 원칙 간의 공통성을 실현하여 전반적으로 시스템 설계를 개선할 수 있을 것이다.
본 논문의 2장에서는 MSA의 기초와 그것의 일반적인 잠재적 편익에 관해 설명한다. 3장은 ICN 기반의 통신아키텍처를 제시하는데, 특히 주요 초점은 자율 주행 차량에서 MSA를 위한 ICN의 활용과 기존 주소 기반 통신아키텍처의 한계를 동기화하는 것이다. 4장은 ICN과 마이크로서비스를 결합하는 논의와 향후 방향을 제시하며, 마지막으로 섹션 5은 본 논문을 마무리한다.
Ⅱ. Monolithic에서 마이크로 서비스로.
애플리케이션을 구현할 때, 기존의 접근 방식은 애플리케이션 기능을 모듈이라 불리는 작은 부분으로 나누는것을 고려한다. 이 방법론은 모듈형 프로그래밍이라고불리는 패러다임에 기초하고 있으며, 각 모듈에는 특정한 목표를 실행하고 달성하는 데 필요한 도구들이 포함되어 있다. 애플리케이션이 완전히 구축되면, 모든 모듈은 일반적으로 모노리스라고 불리는 단일 소프트웨어로 결합되고 모듈화는 대부분 코드 레벨에 있다(예: 모듈의내용은 폴더에 의해 분리됨). 실제로 모듈이 다른 모듈의리소스를 필요로 하는 경우, 모듈은 데이터베이스, 시스템 파일 또는 메모리를 통해 직접 리소스에 접근하는데, 모노리스의 문제는 모듈들이 독립적으로 실행될 수 없다는 것이다. 즉, 애플리케이션을 확장할 때 모든 모듈을 포함하는 인스턴스가 배치되어야 한다는 것을 의미한다. 그러므로 요청도가 높은 모듈의 인스턴스(즉, 도로변 장치에서 차량 응용 프로그램에 대한 트래픽 조건 요청)를만들려면 전체 응용 프로그램의 인스턴스가 배치되어야한다. 게다가, 모노리스들은 일반적으로 개발자들이 원래의 응용 프로그램과 다른 프로그래밍 언어나 프레임워크를 사용하는 것을 제한한다. 또한, 라이브러리를 교체하거나 업데이트하면 단일 모듈이 아닌 전체 애플리케이션이 손상될 수 있기 때문에 유지 관리가 어려울 수 있다.
특히 분산형 시스템에서 모노리스에 의해 제시된 문제는 마이크로서비스 아키텍처(MSA)의 광범위한 채택으로이어졌으며, 일부에서는 이를 서비스 지향 아키텍처 (SOA)의 개선된 버전으로 보고 있다. 컴퓨터 과학에서 서비스는 클라이언트에 대한 태스크를 실행하는 소프트웨어 기능의 그룹으로 정의될 수 있는데. MSA는 반드시단일 프로그래밍 언어에 얽매이지 않고 독립적으로 배치되며 네트워크 프로토콜(일반적으로 REST API 또는 메시지 대기열)을 통해 통신하는 소규모 서비스로 구성된애플리케이션 개발로 구성된다. 실제적인 측면에서, MSA와 SOA 간의 가장 눈에 띄는 차이점 중 하나는 서비스 간 통신에 있다. SOA에서 각 서비스는 엔터프라이즈 서비스 버스(ESB)[7]라는 공통 통신 메커니즘을 공유해야 한다. ESB는 전체 엔터프라이즈의 단일 장애 지점이 될 수 있으며, 단일 서비스가 느려지면 전체 시스템에 영향을 미칠 수 있다. 반대로, MSA에서는 개별 마이크로서비스가 어떤 통신 프로토콜을 사용하는지 명확하게 정의된다.
1. 자율차량의 마이크로서비스 적용
클라우드 기반 서비스의 마이크로서비스 혁명이 시스템과 그 개발을 개선하는 중요한 변화를 가져온다고 가정할 때, 이러한 변화는 자율주행차량 시스템에서 어떤 형태로 다가올 것인지, 그리고 클라우드에서의 성공이 어떻게 광범위하게 자율주행 시스템에 적용되어야 하는가? 라는 질문에 대해 생각을 해볼 필요가 있다. 여러 가지 면에서, 서비스 지향 시스템 개발 접근법과 웹 기반시스템 사이에는 이미 수많은 연결고리가 존재한다. 분명한 연결점 중 하나는 자율주행 시스템의 클라우드 서비스 구성요소이다. 기술적으로, 사물인터넷이나 이의확장 기술 범주에 들어가는 자율주행 시스템은 기존의 인터넷과 웹 개발에서 물려받은 기술 스택을 사용하여 클라우드 서비스 구성요소를 구축할 수 있다. 이러한 공통성을 감안할 때 마이크로서비스 패턴은 기존의 시스템에 적용하기에 비교적 간단해야 한다. 마이크로서비스기반 시스템은 하나 이상의 개별 자급식 독립적 배포 가능 구성요소, 즉 메서드 호출로 추상화된 메시지(예: RPC)로 상호 작용하는 마이크로서비스 또는 구독 이벤트 게시를 통해 구성될 수 있다. 서비스 소비자의 관점에서 마이크로서비스는 단순한 콘텐츠 요청 API에서 극도로 복잡한 컴퓨팅 요청 API에 이르기까지 다양한 종류의 API를 모아 놓은 것이다. 좀 더 이해를 돕기 위하여 다음에서는 자율주행 차량의 마이크로서비스 실제 사용 사례를 조명해 본다.
MSA는 AV에 대한 소위 "종적 군집" 알고리즘을 탐구하는 맥락에서 가장 적합한 아키텍처가 될 수 있다. 종방향 군집은 여러 대의 차량이 도로를 주행하는 동안 근접성을 유지하는 물리적으로 국부적 체인을 형성한다는 것을 의미한다[7]. 각 차량은 다른 차량에 이벤트 서비스를 제공하는 동시에 다른 차량에 연결하는 독립적인 사물인터넷 하위 시스템이 될 수 있다. 이벤트 서비스에는 데이터 및 제어 API가 모두 포함된다. 예를 들어, 차량은 차량 상태를 제공하기 위해 이벤트 스트림 보고서 상태 마이크로서비스를 제공하고, 선도 차량이 합류할 차량을 승인할지를 결정하기 위해 안전 제약 조건을 점검할 수 있도록 참여와 탈퇴 마이크로서비스들을 제공할 수 있다. 군집화는 촘촘한 군집을 유지하는 데 필요한 경우 속도와 가속 및 빈번한 움직임 조정을 포함하여 차량 움직임과 위치 데이터의 지속적인 상호 통신을 필요로 한다. 모션 데이터는 크루즈 컨트롤에서 가져오고 위치 데이터는 초음파 레인지 파인더에서 수집된다. 데이터는 WIFI 를 통해 차량 간(V2V) 통신을 통해 교환된다.[1] 군집 알고리즘은 군집 리더 차량을 사용할 수 있으며, 군집 리더차량은 전체 클러스터로 모션 데이터를 전송하며, 체인의 서로 다른 리더 차량은 뒤에 있는 이웃과 모션 정보를 교환한다. 군집 계산은 비례-적분-미분 제어기(PID)를 사용하여 이전 상태뿐만 아니라 이전 상태와의 분리 거리를 기반으로 원하는 속도를 계산하며, 또한 리더의 상태를 사용하여 전체 군집의 끈 안정성을 유지하여 속도진동을 방지한다. 군집은 센서 판독값을 수집하고 초당 10회 목표 주행 속도를 조절한다. 더 낮은 레벨에서 차량모션 컨트롤러는 크루즈 컨트롤을 구동하여 차량 속도를 조정하거나 유지한다.
군집 시스템은 그림 1과 같이 분산형 마이크로서비스 아키텍처에 따라 구축될 수 있다. 차량에 의해 제공되는 서비스는 별도의 군집 및 상태 보고 마이크로서비스의 형태로 서비스의 일관적이지만 느슨하게 결합된 부분을 수집하는 마이크로서비스로 분해될 수 있다. 실제 상황에서 미래 자동화 차량은 제조자가 제공하는 이러한 군집 서비스 외에 제3 자가 제공하는 다양한 다른 마이크로서비스를 가질 수 있으며 각각은 다른 마이크로서비스 컨테이너에 배치될 수 있다. 더욱이, 각 차량에는 서비스를 통합하는 자체 API 게이트웨이가 있을 수 있으므로 마이크로서비스를 다르게 배치하거나 마이크로서비스에 대한 독립 프로토콜 진화를 관리하는 것이 더 간단하다. 또한, API 게이트웨이는 액세스 제어 정책을 구성하고 시행하기 위한 유연하고 세분화된 위치를 제공할 수 있다. 군집 마이크로서비스는 차량 속도와 같은 중요한 안전 기능을 제어할 수 있고 접근의 적합성은 군집 마이크로서비스 자체의 "소유"가 아닌 상황에 따라 달라질 수있으므로 게이트웨이는 시행을 구현하기에 가장 적합한위치일 수 있다.
그림 1. 처량 군집 주행을 위한 마이크로서비스간 통신의 예[1]
Fig. 1. An Example of Communication among Microservices for Vehicular Platooning[1]
2. 마이크로서비스의 장점
마이크로 서비스 기반 접근 방식은 여러 가지 이점을 제공한다. 첫째, 시스템을 지원하는 전용 및 단일 하드웨어가 필요하지 않는 대신 모든 마이크로 서비스는 서로다른 클라우드/에지 시스템에 업로드 되고 필요한 경우 개별적으로 호출된다. 둘째, 크고 부피가 큰 서비스를 마이크로 서비스로 분해하면 트래픽 피크를 더 잘 처리할 수 있다. 셋째, 분산형 클라우드/에지를 사용하는 소규모 서비스보다 단일 애플리케이션으로 독립 실행형 서버를 공격하는 것이 더 쉬우므로 DDOS 공격에 보다 탄력적이다. 잠재적 마이크로서비스 이점에 대한 자세한 설명은 다음 하위섹션에 자세히 나와 있다.
가. 모듈화 및 재사용
마이크로 서비스는 컨테이너화 되며 메시지 또는 지정된 API를 통해 통신하므로, 기본 하드웨어는 보조 하드웨어가 된다. 또한, 필요에 따라 각 서비스를 결합하여 새 시스템을 만들거나 기존 시스템을 지원할 수 있다. 모듈화의 또 다른 이점은 단일 고장 지점을 더 쉽게 피할수 있다는 점이다. 설계자가 탄력성을 염두에 두고 서비스를 구현할 때, 서비스에 문제가 발생하더라도 시스템은 여전히 동작할 수 있다. 대부분의 자동차 기능은 계층화 또는 구성요소 기반 아키텍처 스타일로 실현되기 때문에, 이 이점은 완전히 새로운 것이 아니라 더욱 강화되며 마이크로 서비스 아키텍처에 의해 단순화될 수 있다. 높은 모듈화의 특성은 인터넷을 통해 활성화되고 설치되는 차량 특징의 추세에도 도움이 될 수 있다. 기술적 수준에서, 이는 모든 생산 차량에 처음부터 내장된 표준 ECU 및 구성요소를 통해 실현된다. 소프트웨어를 다운로드하고 설치하고 이 구성요소를 차량 시스템 전체에 추가하면 기능이 활성화됩니다. 전기 자동차 제조업체인 Tesla는 이미 판매된 자동차에 새로운 기능이나 지연 기능을 추가하기 위해 이 과정을 이미 사용하고 있다. 작은 크기, 명확하게 정의된 API 및 그에 따른 모듈화 때문에 마이크로 서비스는 이 프로세스의 소프트웨어 부분을 다루는 데 매우 적합하다.
나. 확장성
차량 시스템 내에서 클라우드 컴퓨팅, 빅 데이터 처리 및 인공지능의 중요성이 점차 커지고 있다. 그러나 데이터의 양이나 네트워크 품질 저하로 인해 이 작업을 모두 외부에서 처리하기는 쉽지 않다. 이러한 이유로 사용하지 않는 컴퓨팅 리소스를 온 디맨드 상태로 유지하는 것이 바람직하다. 이를 위해서는 소프트웨어가 특히 병목현상이 발생할 경우 차량과 운전자 모두의 요구에 적응할 수 있어야 한다. 이러한 목적을 위해 컨테이너형 마이크로 서비스는 자동으로 복제되어 ECU에 배포될 수 있으며, ECU는 완전히 활용되지 않는다. 이 작업을 위해부하 분산 장치는 거의 힘을 들이지 않고 시스템에 통합될 수 있다. 컨테이너화를 통해 도커 이미지를 복제하고 추가 수정 없이 도커 합성 파일에서 추가 서비스를 호출할 수 있다. 확장성의 강점으로 인해 사용 가능한 리소스의 활용도가 높아져 비용 또한 절감될 수 있다.
다. 독립적인 개발, 배치 및 테스트
MSA에서 각 서비스는 독립 팀에 의해 개발 및 배치될 수 있다. 배포 단위가 작고 서로 독립적이기 때문에 모든 서비스는 시스템에 영향을 미치지 않고 구축, 테스트 및 배포할 수 있다. 또한, 컨테이너형 마이크로 서비스는 단순히 동일한 입력 데이터를 사용하고 출력을 감시함으로써 서비스의 다른 버전을 비교할 가능성을 제공하다. 소규모 소프트웨어 모듈의 또 다른 이점은 배포 워크플로우의 일부가 다른 서비스와 독립적으로 자동화, 버전화 및 개발될 수 있다는 것이다. 이는 소프트웨어 기능, 또는, 업데이트의 신속한 통합으로 이어진다. 소스 코드 저장소를 통해 기존 서비스에 쉽게 액세스할 수 있는 반면, 다른 서비스는 독립적으로 변경 및 개발할 수 있다. 또한, 전체적인 시스템 구조에 중요한 변경을 적용하지 않고도 개별 서비스의 다른 버전을 시험할 수 있다.
라. 마이크로 서비스 아키텍처에서의 통신
API 게이트웨이는 둘 이상의 마이크로 서비스 간에 호출 또는 요청을 전달하는 인터페이스이다. API 게이트웨이는 여러 마이크로 서비스에 대한 API를 하나의 클라이언트 인터페이스로 집계할 수 있으며 한 진입점에서 여러 대상 마이크로 서비스로 호출 또는 요청을 배포하거나 라우팅할 수도 있다. 그러므로, 마이크로 서비스들간의 직접 통신을 허용하는 대신에, API 게이트웨이를 그들 사이에 배치할 수 있으며, 이것은 게이트웨이의 집합과 배포 기능을 통해 상호 연결성을 조정하는 효과를 가질 수 있다. 마이크로 서비스 연결은 등록을 통해 이루어집니다. 마이크로 서비스는 고유한 ID를 가진 하나 이상의 종료 포인트를 생성한다. 이 종료 포인트는 정적 구성 또는 API 게이트웨이와의 동적 협상을 통해 이벤트 채널 또는 메서드에 추가로 바인딩할 수 있다. 마이크로서비스 외에도, 어떤 사용자나 머신 클라이언트는 API 게이트웨이와 상호 작용하여 관련 마이크로 서비스에 액세스하기 위해 ID를 식별자의 이름으로 제시해야 할 수도 있다. ID 관리 및 인증 서비스는 SSO(Single Sign-On) 또는 OAuth와 같이 계정을 관리하는 기존 시스템을 활용할 수 있다.
Ⅲ. 자율주행을 위한 정보 중심 기반 마이크로서비스
1. 정보 중심 기반의 마이크로 서비스
이전 섹션에서 논의한 바와 같이 MSA는 불가피하게 경량 및 독립 서비스 개발을 위한 기반을 마련하여 새로운 구현이 기존 모듈에 지속적으로 통합되는 과정을 완화하였다. 그러나 네트워킹 관점에서 MSA는 TCP/IP와같은 비효율적인 주소 기반 통신 프로토콜을 이용한다. 예를 들어, 다양한 마이크로 서비스 간의 통신을 가능하게 하기 위해 MSA에서 일반적으로 사용되는 Restful APIs는 네트워크 계층에서 IP 프로토콜을 이용한다. IP 프로토콜의 한 가지 분명한 단점은 노드가 처음에는 안정적인 연결을 설정하려고 시도한다는 사실이며, 어떤이유로 인해 연결이 끊어지면 지연을 초래하는 통신이 처음부터 다시 시작되야 한다. IP 기반 통신의 또 다른 단점은 애플리케이션 계층 패킷이 네트워크 계층으로 전달될 때, 모든 애플리케이션 계층 컨텐츠가 페이로드에 캡슐화되고 소스 및 대상 광고가 포함된 헤더 정보만 포함되기 때문에 중간 노드가 그들이 어떤 종류의 요청을 촉진하는지 모른다는 것이다. IP 기반 프로토콜의 이러한 구현은 1) Interest 집계와 2) 네트워크 캐싱이라는두 가지 중요한 기능을 활용하여 성능을 향상시키는 부분에 제한적 기능으로 작용한다. 노드가 어떠한 콘텐츠가 통과하고 있는지를 인식하지 못하기 때문에 유사한콘텐츠/마이크로 서비스의 요청을 Aggregation할 수 없으며, 이는 결국 공급자 노드에 과부하를 초래하고 특히 초고밀도 네트워크 트래픽 시나리오에서 서비스 거부 (DoS) 문제로 이어질 수 있다. 마찬가지로 중간 노드는 엔드포인트 주소 정보를 기반으로 자주 사용되는 마이크로서비스/콘텐츠의 결과를 캐시할 수 없다. 이러한 제한은 DoS를 초래할 뿐만 아니라 대역폭 활용률을 높이고 네트워크의 정체 가능성을 증가시킬 수 있다.
다행히 이름 기반 전달 메커니즘을 갖춘 ICN은 노드가 요청 집계 기능과 네트워크 내 캐싱 기능을 모두 이용하도록 촉진하고 소비자와 공급자 간의 안정적인 연결 필요성을 제거한다. ICN에서 소비자 노드는 콘텐츠/마이크로 서비스의 이름을 애플리케이션 계층 모음 패킷에삽입하여 네트워크에 전달할 수 있습니다. 일단 모음 패킷이 전달되면, 계층적이고 의미론적으로 의미 있는 이름을 이용하여 원하는 콘텐츠를 가져오는 것이 네트워크의 책임이다. ICN에서, 네트워크는 반드시 원래 제공자 노드로 패킷을 전달할 필요는 없으며, 중간 노드의 캐시에서 원하는 콘텐츠를 가져올 수 있다. 이러한 ICN의 유망한 기능은 MSA가 활용할 경우 효율적인 마이크로 서비스 배포 및 통신 측면에서 전반적인 성능을 더욱 향상시킬 수 있다. 멀티 플래토닝 AV의 마이크로 서비스 사용 사례 시나리오를 통해 정보 중심 접근 방식이 전체적인 성능을 어떻게 더욱 향상시킬 수 있는지 이해하고자한다.
소대 1의 리더 노드가 10km 구역의 교통 조건을 계산하는 getTraffic Condition(10)이라는 이름의 마이크로 서비스에 관심을 갖는 그림 2에 제시된 멀티 플래토닝 자율주행차 시나리오를 고려한다. 리더 노드는 수신입력 매개 변수(10km)를 기준으로 트래픽 조건을 스스로 계산하는 패킷을 근처의 RSU로 전달하거나 클라우드노드를 통해 계산을 참조할 수 있습니다(전체 요청 영역이 현재 RSU 범위에 있지 않은 경우). 클라우드 컴퓨팅의 경우, 기존의 통신 프로세스를 따름으로써 요청은 IP 프로토콜을 활용하고 원하는 결과를 가져온다. 소대 2의리더 노드도 유사한 마이크로 서비스에 관심이 있고 동시에 동일한 RSU로 패킷을 전달한다고 가정하자. RSU 가 IP 프로토콜을 채택하고 있기 때문에 동일한 마이크로 서비스의 새로운 요청이 클라우드 노드로 전달되어 백홀 네트워크 트래픽이 증가한다. 반대로 잘 정의된 마이크로서비스 명명 체계를 활용하여 ICN 개념을 채택하면 단일 요청만 클라우드 노드로 전달된다. 예를 들어, 소대 1의 리더 노드는 "AV/getTraffic Condition/10/" 라는 이름의 Interest 패킷을 생성하는데, 이는 AV(소대 1의 리더 노드)가 10km 영역 내의 트래픽 조건에 관심을 갖는다는 것을 설명한다. RSU에 의해 Interest 패킷이 수신되면 먼저 요청을 이행할 수 있는지 여부를 확인하고, 요청된 영역이 현재 RSU의 범위에 있지 않은 경우 PIT 항목을 확인하여 동일한 이름에 대한 요청이 이미 대기열에 있는지 확인한다. 노드에 일치하는 PIT 항목이 있는 경우, 해당 노드는 레코드를 업데이트하고 현재 요청의 수신 면(이 경우 수신 면은 Ad-hoc) 정보를 저장한다. 그러나 PIT 항목이 존재하지 않는 경우 CS에서 원하는 결과를 확인하고 데이터 패킷의 계산 결과로 응답할 수 있다.
그림 2. 다중 군집 자율 차량의 예
Fig. 2. An Example of Multi-platoon Autonomous Vehicles
Ⅳ. 토론과 향후 방향
1. 마이크로 서비스 이름 지정
기존 연구에서와 같이[7], 자율 차량을 위한 ICN 기반마이크로 서비스 아키텍처는 요청된 콘텐츠와 콘텐츠에 적용될 필요한 마이크로 서비스를 모두 식별하는 임시지정 명명 체계를 활용할 수 있다. 특히, 레거시 NDN 전달에 영향을 미치지 않도록 컨텐츠 이름 뒤에 마이크로서비스 이름을 추가하여 컨텐츠와 마이크로 서비스 이름을 계층적으로 지정할 수 있다. AMS와 같은 특정 태그 또는 인스턴스 '|'의 구분 문자를 사용하여 마이크로 서비스 이름과 내용 이름을 구분할 수 있다. AMS 태그 또는 '|'가 포함되지 않은 경우, Interest 패킷은 자율 주행차량에 의한 레거시 NDN 콘텐츠 요청으로 처리된다. 마이크로 서비스 이름에는 제한된 매개 변수 집합이 실행을 위한 입력으로 포함될 수도 있다.
2. 서비스 검색
마이크로 서비스 아키텍처는 애플리케이션을 여러 구성 요소 마이크로 서비스로 분해하며, 이 서비스는 경량메커니즘을 사용하여 서로 통신한다. 현재 마이크로 서비스는 표준 정의에 부합하지 않고 있다.[8] 그러나 일반적으로 특정 기능은 대부분의 마이크로 서비스가 소유하고 있는 것으로 간주된다. 상당히 중요한 기능은 검색 가능성 기능이며, 이는 서로 다른 마이크로 서비스가 현재 네트워크에서 실행 중인 다른 마이크로 서비스 인스턴스를 찾을 수 있어야 함을 의미한다. 서비스 발견은 소비자가 필요로 하는 서비스 제공자의 위치를 파악할 수 있게하는 과정이며, 따라서 이 두 기관 간의 커뮤니케이션을 가능하게 한다. 이름 기반 마이크로 서비스 아키텍처에는 계층 이름을 사용하여 다른 마이크로 서비스 인스턴스를 정확하게 찾을 수 있는 정확한 정보를 제공하는 서비스 검색 메커니즘이 필요하다. 서비스 검색 솔루션은 중앙 집중형 또는 분산형일 수 있다. MSA는 시스템에서 제공하는 각 서비스의 정확한 위치 정보를 반영하도록 동적으로 수정될 수 있는 분산형 솔루션을 요구한다.
마이크로 서비스 기반 시스템은 매우 역동적이다. 즉, 마이크로 서비스는 즉시 생성되고 등록 취소될 수 있다. 마이크로 서비스 인스턴스의 수명 동안 다른 호스트로 마이그레이션 할 수 있다. 마이크로 서비스를 위한 명명된 기반 서비스 검색 솔루션은 이러한 모든 시나리오를 처리할 수 있어야 한다. 서비스 검색 솔루션은 구현된 마이크로 서비스의 변화에 따라 확장 또는 축소되어야 하므로 확장 가능해야 한다.
3. 라우팅
MSA를 사용하여 설계된 애플리케이션은 여러 마이크로 서비스 단위를 포함한다. 다른 마이크로 서비스는 다른 기능을 제공한다. 동일한 기능을 제공하는 다른 마이크로 서비스 인스턴스도 네트워크에서 사용할 수 있다. 소비자 서비스 요청을 받을 때, 요청이 지시될 수 있는 마이크로 서비스 인스턴스를 결정하기 위해 효율적인 이름 기반 라우팅 및 전달 기능이 필요하다. 소비자 요청은 공개적으로 노출되는 마이크로 서비스 시스템의 구성 요소인 API 게이트웨이로 전달될 수 있다. 라우팅 계층은 API 게이트웨이에서 적절한 마이크로 서비스 인스턴스로 요청을 전달하는 역할을 처리한다. 연구자들은 마이크로 서비스 애플리케이션에서 라우팅 솔루션을 개발하려고 시도했다. 연구원들이 직면한 한 가지 독특한 과제는 동일한 마이크로 서비스의 다른 버전이 존재할 수 있다는 것이다. 성능 또는 복원력 테스트와 같은 사용 사례의 경우 요청은 특정 버전을 대상으로 할 수 있다. 이 맥락에서 ICN 명명법은 가장 적합할 수 있으며, 버전 마이크로 서비스를 특별히 대상으로 하는 명명된 라우팅 메커니즘을 위해 버전 인식 명명 체계를 고안할 수 있다.
4. 부하 분산
마이크로 서비스 생태계는 상호 작용하는 여러 마이크로 서비스 단위를 포함한다. MSA의 주요 매력 중 하나는 부하에 따라 다양한 마이크로 서비스 유닛이 확장될 수있다는 점이다. 수신되는 이름 기반 마이크로 서비스 요청을 동일한 마이크로 서비스의 서로 다른 인스턴스 간에 효과적으로 분배하기 위해 이름 기반 로드 밸런싱 구성요소가 도입될 수 있다. 이를 위해 현재 실행 중인 마이크로 서비스 인스턴스를 지정하는 인스턴스별 명명 체계가 필요하다. 로드 밸런싱 작업은 마이크로 서비스를호스팅하는 생산자 노드(서버)에서 수행되거나 소비자측에서 수행될 수 있으므로 두 가지 유형의 로드 밸런싱이 발생할 수 있다. 서버측 로드 밸런싱에서 모든 요청은 로드 밸런서를 호스트하고 시스템에 있는 모든 마이크로서비스 인스턴스의 디렉토리를 유지하는 프록시 노드로 전달된다. 그런 다음 서버는 로드 밸런싱 알고리즘을 적용하여 현재 요청을 처리할 수 있는 인스턴스를 결정한다. 소비자 측 부하 분산은 소비자에게 더 많은 전력을 맡긴다. 각 소비자는 먼저 요청을 서비스 검색 에이전트로 보냅니다. 서비스 레지스트리에서 요청을 처리할 수있는 모든 잠재적인 마이크로 서비스 인스턴스를 반환한다. 모든 실행 중인 인스턴스의 정보를 수신하면, 소비자는 현재 요청을 어디로 보내야 하는지 결정하기 위해 라운드 로빈 알고리즘과 같은 로드 밸런싱 알고리즘을 적용할 수 있다. 또는 각 요청에 대해 서비스 레지스트리와의 통신을 방지하기 위해 로컬 캐시를 소비자 측에 보관할 수 있다.
Ⅴ. 결론
본 논문에서, 우리는 MSA를 위한 ICN 통신 패러다임을 기본 통신 프로토콜로 채택하는 비전을 제시한다. 이논문은 3가지 기능을 강조하는데, 먼저, 마이크로 서비스의 내부 구조에 대한 일반적인 모델과 AV 영역에서 마이크로 서비스의 주요 이점을 제공한다. 둘째, 마이크로 서비스를 위한 대체 기반 통신 패러다임으로 ICN을 제시하였다. 셋째, ICN과 MSA를 통합하는 맥락에서 몇 가지미래 방향을 제시하였다. 미래 연구 주제로써 에지 및 클라우드 노드에 구축된 NET Core 기반 마이크로 서비스를 포함한 ndnSIM 시뮬레이션과 함께 ICN 기반 MSA 의 프로토타입을 개발하여 성능을 평가할 예정이다.
※ 본 연구는 산업통상자원부와 한국산업기술진흥원의 “이전공공기관연계육성(R&D,P0015131)”사업의 지원을 받아 수행된 연구결과임.
References
- D. Lu, D. Huang, A. Walenstein, and D. Medhi, "A Secure Microservice Framework for IoT," IEEE Symposium on Service-Oriented System Engineering (SOSE), San Francisco, CA, pp. 9-18, 2017, DOI: https://doi: 10.1109/SOSE.2017.27.
- J. Lotz, A. Vogelsang, O. Benderius, and C. Berger, "Microservice Architectures for Advanced Driver Assistance Systems: A Case-Study," IEEE International Conference on Software Architecture Companion (ICSA-C), Hamburg, Germany, pp. 45-52, 2019, DOI: https://doi: 10.1109/ICSA-C.2019.00016.
- M. Kim, C. Park, and K. Ko, "Development and Performance Analysis of Channel Estimation Schemes Using Decoding Information for WAVE System", Journal of KII, Vol. 15, No. 11, pp. 93-101, 2017.
- IEEE 802.11p, "Amendment 6: wireless access in vehicular environments", 2010.
- F Bai and B. Krishnamachari, "Exploiting the wisdom of the crowd: localized, distributed information-centric VANETs topics in automotive networking", IEEE Commun. Mag., Vol. 48, No. 5, pp. 138-146, 2010. https://doi.org/10.1109/MCOM.2010.5458375
- IBM Cloud Team, "SOA vs. Microservices: What's the Difference?", https://www.ibm.com/cloud/blog/soa-vs-microservices
- M. Amadeo, C. Campolo, A. Molinaro, and G. Ruggeri, "IoT data processing at the edge with Named Data Networking," European Wireless conference, Catania, Italy, pp. 1-6, 2018.
- C.T. Joseph and K. Chandrasekaran, "Straddling the crevasse: A review of microservice software architecture foundations and recent advancements", Softw. Pract. Exper., Vol. 49, No. pp. 1448-1484, 2019. DOI: https://doi.org/10.1002/spe.2729.