Edge Computing Server Deployment Technique for Cloud VR-based Multi-User Metaverse Content

클라우드 VR 기반 다중 사용자 메타버스 콘텐츠를 위한 엣지 컴퓨팅 서버 배치 기법

Abstract

Recently, as indoor activities increase due to the spread of infectious diseases, the metaverse is attracting attention. Metaverse refers to content in which the virtual world and the real world are closely related, and its representative platform technology is VR(Virtual Reality). However, since VR hardware is difficult to access in terms of cost, the concept of streaming-based cloud VR has emerged. This study proposes a server configuration and deployment method in an edge network when metaverse content involving multiple users operates based on cloud VR. The proposed algorithm deploys the edge server in consideration of the network and computing resources and client location for cloud VR, which requires a high level of computing resources while at the same time is very sensitive to latency. Based on simulation, it is confirmed that the proposed algorithm can effectively reduce the total network traffic load regardless of the number of applications or the number of users through comparison with the existing deployment method.

1. 서론

1.1 메타버스의 확산과 클라우드 VR

최근 감염병의 확산으로 실내 활동이 증가함에 따라 메타버스 산업이 주목받고 있다. 메타버스 개념은 기존에는 게임 콘텐츠 등에서 제한적으로 적용되어오던 개념이었으나, 재택근무, 원격회의와 같은 감염병 확산으로 촉발된 새로운 산업들의 등장으로 전방위적으로 관심을 받고 있다. 메타버스의 활용 사례로는 아바타 기반 원격회의 및 시연회, 원격 세미나 및 행사, 가상현실(VR; Virtual Reality) 및 증강현실 (AR; Augmented Reality) 기반 시뮬레이션 등이 있을 수 있다. 메타버스 기반의 콘텐츠와 기존의 2D/3D 디지털 콘텐츠와의 핵심적인 차이점은 가상세계와 현실세계가 어떤 식으로든 밀접하게 연관된다는 것이다. 현실의 사용자 움직임이나 제스쳐가 가상세계에 반영되거나, 현실에 존재하는 물체를 가상세계에서 다른 사용자와 함께 검토하는 콘텐츠가 그 예가 될 수 있으며, 따라서 현재의 메타버스를 지원하기 위한 재생 기술은 몰입감이 높은 VR/AR이 가장 적절하다고 할 수 있다[1].

메타버스 콘텐츠가 확산됨에 따라 VR 사용자 및 사용량도 함께 증가하고 있다. 가상현실 하드웨어는 HMD(Head-Mounted Display)가 가장 대표적이다. VR HMD 하드웨어는 여타 제품군과는 달리 VR의 필수장비이자 대부분의 기술이 집약되어 있는 장비로서 다양한 종류의 스펙으로 구성된다. 콘텐츠 재생 품질을 위하여, 화면 크기, 해상도, PPI, 주사율, 밝기, 명암비와 같은 전통적인 그래픽 표시 능력뿐만 아니라, 시야각, 프레임율, 응답 시간과 같은 영상처리 능력을 갖추어야 한다. 게다가 접안렌즈의 성능, 지원하는 이동 자유도 (3-DoF, 6-DoF 등), 연결 방식 (유무선), 전방 카메라, 근처 공간 감지, 손 제스처 인식, 또한 당연하게도 착용 장비이기 때문에 무게 경량화까지 갖추어져야 한다[2, 3, 4, 5]. 안타깝게도 VR HMD 는 비교적 고가의 제품이며 더 나은 성능과 착용감을 위해서는 더 높은 비용을 감수해야만 한다. 사용자 또는 기업들은 메타버스를 제대로 활용하기 위해서는 높은 수준의 콘텐츠 재생 능력이나 경량화된 무게와 같이 적정 수준 이상의 HMD가 갖춰져야 한다고 인지하고는 있으나, 비용 문제로 인해 VR이 아닌 2D/ 3D 콘텐츠와 같은 차선책을 선택하게 된다. 이러한 현상은 메타버스 생태계의 확산을 저해할 수 있다.

클라우드 VR은 이러한 문제를 기술적으로 해결하려는 접근이다. 이는 클라우드 게이밍과 유사하게, 클라이언트 하드웨어의 성능 한계를 극복하기 위해 제안된 기술이다 [6]. 클라우드 서버는 클라이언트로부터 수신한 사용자 입력들을 종합하여 정보를 최신화한 후, 해당 사용자를 위한 그래픽 렌더링을 직접 수행하여 그 결과물을 클라이언트로 스트리밍한다. 클라이언트에서는 스트리밍되는 영상을 단지 실시간으로 재생만 함으로써 콘텐츠를 구현한다. 즉, 높은 연산 능력을 요구하는 렌더링 과정은 클라이언트가 아닌 클라우드 서버에서 수행되므로, 자연스럽게 클라이언트 하드웨어의 성능 이슈에 대한 해결책이 될 수 있다.

1.2 메타버스를 위한 클라우드 VR을 지원하는 엣지 컴퓨팅의 도전 과제

클라우드 VR의 대표적인 기술적 단점은 네트워크 지연이다. 게임과 같은 스트리밍 기반 상호작용콘텐츠는 영상 스트리밍 서비스와는 상이한 핵심 성능 지표를 가진다. 영상과 같은 멀티미디어 콘텐츠의 스트리밍은 네트워크 대역폭을 핵심 지표로 삼는 반면, 상호작용 콘텐츠는 네트워크 대역폭뿐만 아니라 사용자의 입력에 대한 반응 시간도 매우 중요한 성능지표가 된다. 게임 사용자는 키 조작이나 IMU(Iner- tial Measurement Unit) 결과값 등 자신의 입력이나 동작에 대한 결과가 즉각적으로 화면에 표시되길 원한다. 클라우드 VR의 동작 원리에 의하면 입력 반응시간에는 클라우드 서버와 데이터를 주고받는 시간, 즉, 네트워크 지연이 가장 큰 부분을 차지하게 된다.

클라우드 게임 사용자들은 반응 시간이 100ms를 초과하면 QoE(Quality of Experience)가 저하되었다고 느낀다[7,8]. 클라우드 VR 콘텐츠는 MTP(Motion- to-Photon) latency 측면에서 반응시간이 더욱 중요해진다. MTP latency란 HMD에서 감지되는 머리 또는 몸의 이동 또는 회전이 발생한 시점부터 그 결과가 뷰포트에 표시되기까지의 시간을 의미한다. 이 시간이 20ms를 초과하는 경우 VR Sickness라고 불리는 멀미 현상이 발생하여 QoE를 심각하게 저해하므로 이 수치는 반드시 지켜져야 한다[9,10]. 하지만 클라우드 VR을 클라우드 서버에서 지원하는 경우, VR HMD와 클라우드 데이터센터와의 물리적 거리로 인해 MTP latency가 증가하게 되는 문제가 필연적으로 발생하게 된다.

엣지 컴퓨팅은 클라우드 서버가 수행하던 동작을 네트워크 엣지에 위치한 컴퓨팅 개체가 일부 분담하는 개념으로, 클라우드 통신 모델의 단점이었던 지연시간 문제를 해결할 수 있어 기술적 영향력을 확대하고 있다. 클라우드 VR의 지연시간 이슈 역시 엣지 컴퓨팅을 기반으로 한다면 어느 정도 대응 가능하다. 하지만 엣지 컴퓨팅 환경은 데이터센터에 비해 상대적으로 부족하고 분산된 컴퓨팅 자원으로 구성되어있는 등 태생적인 한계가 존재한다. 따라서 높은 수준의 컴퓨팅 및 네트워킹 작업 부하를 요구하는 클라우드 VR 서비스를 엣지 컴퓨팅 네트워크에서 지원하기 위해서는 콘텐츠 특성과 엣지 도메인 내 다양한 리소스를 종합적으로 고려해야 한다[11,12].

이에 본 연구에서는 클라우드 VR 기반 메타버스콘텐츠를 위한 엣지 네트워크 구성 기법에 대해 다룬다. 네트워크 관점에서 다중 사용자를 기반으로 하는메타버스 콘텐츠에 대한 다양한 고려사항을 제시한다. 또한, 다중 사용자 애플리케이션의 엣지 서버 배치 시, 평균적인 네트워크 거리가 증가하지 않게 유지하면서 동시에 네트워크 혼잡도를 감소시키기 위한 구성 알고리즘을 제시하며, 이는 시뮬레이션을 통해 기존 알고리즘들과 객관적 지표를 통해 비교 검증된다.

2. 관련 연구

엣지 컴퓨팅 환경에서 엣지 서버를 구성하는 기법은 다양한 상황을 고려하여 제시되어 왔다. 엣지 서버의 위치는 단지 네트워크 관점에서만 바라볼 수 있는 것이 아니라 컴퓨팅 워크로드의 관점도 필요하다. 즉, 엣지 서버 구성 시에는 주어진 환경의 네트워크 리소스와 컴퓨팅 리소스를 모두 고려해야 한다. 최근에는 네트워크 혼잡 제어 및 애플리케이션 QoS/ QoE 향상을 위해 엣지 서버를 멀티 컴포넌트 형태로 구성하는 연구도 존재한다.

클라우드 데이터센터에서 벡터 빈 패킹 알고리즘을 통해 가상머신을 배치하는 연구는 이전부터 활발하게 수행되어 왔다. [13]에서는 데이터센터에서 벡터 빈 패킹 알고리즘을 활용하여 가상머신을 물리 장비에 배치하며, 패킹을 통해 가상머신이 배치되는물리머신의 개수를 줄임으로써 데이터센터의 전력 소모를 줄이는 기법을 연구했다. 이러한 클라우드 환경에서의 연구는 엣지 컴퓨팅에서 고려될 수 있는 여러 요소를 반영하지 못하는 한계가 있다. 즉, 엣지 환경에서는 네트워크 토폴로지, 데이터센터에 비해 낮은 수준의 가용 컴퓨팅 리소스 등에 대한 고려가 추가로 필요하다.

데이터센터에서의 연구는 주로 얼마나 적은 물리머신을 가지고 동일한 서비스를 제공할 것인가에 초점이 맞춰져 있다. 운용되지 않는 물리 머신은 전원을 차단함으로써 전력 소모량을 감소시킬 수 있기 때문이다. 하지만 엣지 컴퓨팅 환경에서는 네트워크 엣지에서 얼마나 적은 노드를 운용할 것인가는 다소 사소한 문제가 된다. 엣지 컴퓨팅의 주안점은 지연시간이며, 즉, 지연시간에 영향을 미치는 네트워크 내 다양한 요소들의 운용관리가 핵심적이다. 이 네트워크 운용에는 컴퓨팅 리소스를 고려하면서, 요청자로부터 얼마나 멀리 떨어져 있는가 하는 전통적인 홉 카운트뿐만 아니라 네트워크 혼잡도까지 고려 대상이 된다.

[14]와 [15]는 엣지 컴퓨팅의 최종 사용자의 체감지연 시간 관점에 집중하였다. 정해진 지연시간 허용치가 있는 특정 태스크는, 로컬 시스템에서 기한 내에 처리되지 못할 것 같으면 primary coverage 내의 primary 엣지 노드에게 오프로드된다. 이 과정에서 전송 지연 시간은 어느정도 희생되지만, 넉넉한 가용컴퓨팅 리소스를 활용하여 컴퓨팅 지연을 줄일 수 있다. 만약 primary 엣지 노드의 가용 컴퓨팅 리소스로 해당 태스크를 기한 내에 처리할 수 없다면, 전송지연 시간을 추가로 희생하면서 클라우드 또는 secondary 엣지 노드에게 오프로드된다. 이러한 방식으로 엣지 컴퓨팅 사용자의 체감 지연시간을 최대한 보장한다. 이 연구는 CPU 사이클과 같이 컴퓨팅 리소스에 대한 좀 더 구체화된 접근을 했으나, 개별 사용자에만 집중하였다는 한계점이 있다.

[16]에서는 클라우드 VR의 사용자 뷰포트 (사용자가 현재 바라보고 있는 시야)와 렌더링해야 하는가 상 공간과의 차이를 활용하여, 스트리밍 영상 품질과 전송 지연 간의 균형을 공동으로 최적화하는 연구를 진행하였다. 즉, 원격 렌더링과 사용자 HMD 회전 대응을 분리함으로써 MTP 지연을 최소화하며, 실시간 클라우드 렌더링을 위한 엣지 가속 시스템을 제시하였다. 공동 최적화는 혼합 정수 비선형 계획법으로 공식화하여 수행하였다. 해당 연구는 클라우드 VR 의 최종 단계인 렌더링에 집중하였으나, 다중 사용자환경에서의 엔진 프로세싱에 대해서는 고려하지 않은 한계가 존재한다.

우리의 이전 연구 [17]에서는 엣지 컴퓨팅 환경에서 서버를 배치하는 알고리즘을 제시하였다. 클라이언트, 데이터소스, 외부 네트워크 요소로 구성되는 엣지 서비스를 지원하는 엣지 서버를 가상 서비스 플로우(VSF; Virtual Service Flow)로 간주하였다. 클라이언트별로 생성된 VSF를 대상으로 예비 서버 위치에 대한 트래픽 부하 추정치를 연산하여 드래프트를 구성하였으며, 이들을 컴퓨팅 리소스를 고려하면서 휴리스틱 방식으로 배치하였다. 해당 연구는 VSF의 구성 요소가 다양하여 연산 복잡도가 상당히 높고, 네트워크가 혼잡해질 시 알고리즘 성공률이 비교적 저하되는 한계가 있었다. 또한 단일 클라이언트를 대상으로 VSF를 구성하였으므로 다중 사용자를 기반으로 하는 메타버스 콘텐츠를 지원하는 엣지 컴퓨팅 구성에는 적절하지 않다.

3. 클라우드 VR 기반 메타버스 콘텐츠를 위한 엣지 네트워크 구성 방법

3.1 메타버스 콘텐츠를 지원하는 클라우드 VR 동작 프로세스

단일 사용자 환경에서 일반적인 클라우드 VR의 동작 프로세스는 Fig. 1과 같다. 사용자의 입력값과 모션 센싱 데이터는 클라이언트 내에서 감지되어 엣지 서버로 전달된다. 엣지 서버는 이 입력을 기반으로 VR 콘텐츠 프로세싱을 한 후, 사용자의 뷰포트 화면을 렌더링한다. 렌더링된 결과는 인코딩되어 클라이언트로 전송되며, 클라이언트는 이를 재생하는 방식으로 콘텐츠를 구현한다. 엣지 서버는 네트워크 내의 서버 인스턴스로, 입력 신호 처리와 그래픽 렌더링, 영상 인코딩을 클라이언트 대신 수행한다. 네트워크 지연을 최소화해야 하므로 사용자와 물리적/ 지리적으로 가까운 곳에서 동작한다. 본 연구에서는 엣지 서버가 동작하는 네트워크 내 물리적 서버는 엣지 노드라 한다. 엣지 노드는 네트워크 장비 그 자체거나 그와 직접적으로 연결된 물리머신으로, 네트워크 노드와 동일하게 간주될 수 있다.

Fig. 1. Cloud VR process overview.

이러한 상황에서 네트워크 관점에서 고려해야 할 점은 다음과 같다. 특정 애플리케이션에 대해, 컴퓨팅 및 네트워크 리소스 요구치, 네트워크 지연 허용치, 컴퓨팅 및 네트워킹 부하 변화량 등의 정보를 고려해야 하며, 엣지 노드의 가용 컴퓨팅 리소스도 고려되어야 한다. 특정 애플리케이션의 엣지 서버는 사용자별로 분리되어 구성되며, 콘텐츠 및 네트워크 성능 지표 향상을 위해 서버가 동작할 엣지 노드가 결정된다.

이에 반해 메타버스 콘텐츠는 다중 사용자인 경우가 일반적이다. 다중 사용자 콘텐츠가 클라우드 VR 기법으로 동작할 때의 프로세스 구성은 Fig. 2와 같다. 각 사용자는 각각의 입력과 동작을 서버로 전송하며, 이 입력은 일반적으로 사용자 상호 간 뷰포트에 영향을 미친다. 기존 온라인 콘텐츠는 입력 신호만 공유되어 각 클라이언트에서 개별적으로 처리하는 방식이나, 클라우드 VR에서는 인접한 모든 사용자의 입력을 중앙집중화된 서버에서 처리해야 할 필요가 있다. 즉, 각 사용자의 입력은 중앙 서버로 전달되어 데이터 취합 후 엔진 프로세싱 과정을 거치며, 이 결과는 각 사용자와 연관된 엣지 서버로 전달되어각 사용자의 뷰포트에 대해 렌더링된 후 클라이언트로 전송된다. 또한, HMD 모션 프로세싱과 같은 지연시간에 민감한 동작은 중앙 서버와 엣지 서버에 동시에 보내져 처리될 수도 있다. 중앙 서버에 보내진 모션 데이터는 엔진 프로세싱을 하여 자신과 다른 사용자의 뷰포트를 구성하는데 활용되며, 동시에 엣지 서버에 보내진 모션 데이터는 HMD 동작에 따른 신속한 뷰포트 렌더링에 활용될 수 있다.

Fig. 2. Process overview of cloud VR for metaverse content.

본 연구에서 클라우드 VR 기반 메타버스 콘텐츠는 로컬 네트워크 범위 내 4인 이하의 인원이 참여한다고 가정한다. 또한 하나의 애플리케이션을 위해 하나의 통합된 엣지 서버를 운용한다고 가정한다. 이가정을 기반으로 Fig. 3과 같은 프로세스 모듈 구성예시를 살펴보자. 해당 애플리케이션의 참여자는 2 인이며 각각을 클라이언트 A, B라고 했을 때, 각 클라이언트를 위한 입력 처리 및 렌더링 모듈은 클라이언트별로 존재하게 된다. 엔진 프로세싱 모듈은 각 입력 처리 모듈과 통신하여 입력 데이터를 수집 및 취합한다. 그 결과는 R_A와 R_B 렌더링 모듈로 전달되고, 각 렌더링 결과는 각 클라이언트로 스트리밍된다. 여기서 각 모듈은 개별 프로세스로 구성될 수 있다. 즉, 위 구성에서는 Docker와 같은 하나의 서버 인스턴스 내에 다섯 개의 프로세스가 동작하고 있는 것이다.

Fig. 3. Configuration of processing modules of the edge server for multi-user cloud VR.

만약 동일한 로컬 네트워크라는 가정이 없다면 클라이언트 A 입장에서는 E 모듈 또는 I_B, R_B 모듈부터는 외부 네트워크에 존재할 수 있게 되며, 이를 위해서는 별도의 엣지 서버 구성이 필요하다. 4인 이하라는 가정이 없다면 대규모 사용자가 동일한 메타버스 원격회의에 참여할 수 있으며, 이를 위한 정보 수집 및 엔진 프로세싱 모듈의 구성은 지금과는 다른 대규모 다중 사용자 콘텐츠의 문법을 따르게 된다. 또한 하나의 통합된 엣지 서버라는 가정이 없다면 각 모듈은 모든 클라이언트가 동일한 로컬 네트워크에 존재하더라도 별도의 엣지 서버를 구성할 수 있다. 이를 위해서는 멀티 컴포넌트 엣지 서버 구성 기법이 별도로 요구된다.

3.2 다중 사용자 클라우드 VR 콘텐츠를 위한 엣지 서버 배치 알고리즘

Fig. 3과 같은 2대의 클라이언트와 1대의 엣지 서버로 구성된 세트를 본 연구에서는 VCN(Virtual Content Network)이라 한다. VCN은 4대 이하의 클라이언트와 1대의 엣지 서버로 구성될 수 있다. 네트워크 내 클라이언트의 위치는 고정되어 있으므로, 각 VCN들의 엣지 서버 동작 위치를 지정함으로써 VCN 의 지연시간 감소뿐만 아니라 전체 네트워크의 트래픽 부하 감소 및 컴퓨팅 리소스 균형을 달성할 수 있다.

VCN의 엣지 서버를 적절한 엣지 노드에 배치하기 위해 본 연구에서는 2단계의 알고리즘을 제안한다. 첫 번째 단계로, 각 VCN에 대해 엣지 서버 배치 후보지를 구한다. 배치 후보지는 네트워크 내 모든 노드가 될 수 있으며, 특정 노드에 배치되었을 때 예상되는 네트워크 비용을 기반으로 배치 후보지를 정렬한다. 두 번째 단계로, 네트워크 내 모든 VCN의엣지 서버를 최우선 후보 노드에 가상으로 배치한다. 이때 특정 노드의 가용 컴퓨팅 리소스가 해당 노드에 진입하게 될 모든 엣지 서버들의 리소스 요구치의 합을 충족시킬 수 없다면, 그중 일부 VCN의 엣지 서버를 다른 노드로 재배치한다. 여기서 컴퓨팅 리소스는 합산 및 비교가 용이하도록 워크로드 단위로 추상화된다. 이러한 방식으로 네트워크 및 컴퓨팅 부하를 함께 고려하면서 네트워크 내에 모든 VCN의엣지 서버를 배치할 수 있다.

Table 1은 특정 VCN의 엣지 서버를 배치할 후보 노드 목록을 생성하는 알고리즘을 나타낸다. VCN을구성하는 클라이언트 집합 C와 VCN 애플리케이션의 링크별 트래픽 팩터인 τ_app을 활용하여 후보별 예상 트래픽 부하를 구한다. 링크별 트래픽 팩터란 엣지 서버와 클라이언트 사이의 네트워크 경로 상 각 링크에 요구되는 트래픽 부하를 의미한다. 네트워크 내 모든 노드 집합 N의 각 노드 n에 대해, 해당 노드와 각 클라이언트 간 최단경로의 합과 트래픽 팩터의 곱으로 후보 노드 n의 예상 트래픽 부하 \(\hat{t} \)를 구한다. 즉, VCN의 엣지 서버가 노드 n에 배치되었을 때 발생할 것으로 예상되는 트래픽 부하가 \(\hat{t} \)라는 의미다. 이렇게 구해진 후보 노드는 예상 트래픽 부하를 기준으로 오름차순 정렬되어 VCN의 후보 목록을 구성한다. 동일한 방식으로 네트워크 내 모든 VCN에 대해 각각의 후보 목록을 생성한다.

Table 1. Algorithm to find candidate nodes where VCN’s edge server will be deployed.

Table 2는 컴퓨팅 리소스를 고려하여 VCN의 후보들을 선택하는 알고리즘을 나타낸다. 모든 VCN의가장 좋은 후보 노드에 엣지 서버를 배치하는 것이 최선이겠지만, 특정 노드의 컴퓨팅 리소스가 부족하여 해당 노드에 엣지 서버를 모두 배치할 수 없을 수도 있다. P는 각 VCN의 후보 노드 선택 상황을 나타내며, 배치 계획이라고 한다. 최초에는 모든 VCN의 가장 좋은 후보 노드가 선택된 것으로 초기화된다. 다섯 번째 줄에서, |R| 는 고려 중인 컴퓨팅 리소스 종류의 개수를 의미하며 \(r^{i}_{n}\)는 노드 n의 i번째 컴퓨팅 리소스, \(r^{i}_{req}\) 는 계획 P에서 노드 n을 후보로 선택한 모든 엣지 서버의 i번째 컴퓨팅 리소스 요구량의 합을 의미한다.

Table 2. Algorithm to select VCN candidates considering computing resources.

알고리즘 2의 9번째 줄에서, 리소스 초과 노드 n_x 가 없다면 알고리즘이 종료되고 계획 P가 확정되어 VCN의 엣지 서버가 실제로 해당 후보 노드에 배치된다. 하지만 리소스 초과 노드가 존재한다면 해당 노드에 배치될 예정이었던 엣지 서버 중 일부를 교체해야 한다. 교체 노드 선택 방법은 Weighted Vector Bin Packing(W-VBP)을 활용한다[18]. VBP 기반교체 기법이란 노드의 리소스 구성 비율과 엣지 서버의 리소스 구성 비율의 차이가 가장 큰 서버를 교체하는 방법이다. 이는 벡터를 기반으로 하므로 리소스개수에 제약이 없으며, 일부 리소스만 고갈되어도 다른 타입의 리소스를 사용하지 못하는 부작용을 최소화한다. 교체 대상 VCN의 모든 후보가 고갈되었다면 알고리즘은 최종적으로 실패한 것으로 간주되므로, 특정 VCN의 후보만 연속하여 고갈되는 상황을 방지하기 위해 VCN별 잔여 후보 비율을 가중치로 고려하였다. VBP의 결과인 벡터각과 가중치를 곱한 결과인 θ값이 가장 큰 엣지 서버가 교체 대상이 된다.

교체 대상이 된 엣지 서버를 보유한 VCN은 현재 선택된 후보 노드를 P에서 제거하고 자신의 후보 목록에서 다음 후보 노드를 선택한다. 그런 다음, 현재 상태의 P를 기반으로 초과 노드 존재 여부를 다시 검사한다. 알고리즘의 실패는 네트워크 내 메타버스콘텐츠들의 컴퓨팅 리소스 요구량이 총 가용 리소스에 가까워지거나 초과할 때 발생할 수 있다. 이러한 상황은 하드웨어를 추가하거나 또는 콘텐츠들의 엣지 컴퓨팅으로의 오프로드 수준을 낮추는 대책을 적용함으로써 극복할 수 있다.

4. 시뮬레이션 결과 분석

본 연구에서 제안하는 클라우드 VR 기반 다중 사용자 콘텐츠를 위한 엣지 네트워크 구성 방법은 시뮬레이션을 통해 기존의 배치 기법들과 비교된다. 이를 통해 제안 기법이 어떻게 네트워크 수준에서 엣지 컴퓨팅 콘텐츠를 잘 지원할 수 있는지 검증한다.

네트워크 토폴로지는 Fig. 4와 같이 구성되며, 트래픽 팩터나 컴퓨팅 리소스 팩터와 같은 애플리케이션 특성이나 클라이언트 위치는 시뮬레이션 목적에 따라 임의로 변경된다. 기본적인 시뮬레이션 파라미터는 다음과 같으며, 이 수치들은 각 시뮬레이션 시 특별한 언급이 없는 한 기본값으로 적용된다. 제시된 수치들은 실제 환경에 비해 사용량이 좀 더 집중된 상황 또는 꽤 빈약한 컴퓨팅 파워를 가진 엣지 노드를 반영한다. 즉, 리소스 초과 노드가 빈번하게 발생할 수 있는 상황으로 설정하였다. 엣지 노드의 가용 리소스는 모두 \(r_{n}^{i} \in[100,1000 R I G H T]\)(workload) 중임의의 값을 가지며 균등 분포를 따른다. 애플리케이션의 리소스 팩터는 \(r^{i}_{app}\)∈[50.150](workload per cli- ent), τ_app∈[1,5](Mbps) 중 임의의 값을 가지며 정규분포를 따른다. 네트워크 내에는 5개의 애플리케이션이 존재하며, 각 애플리케이션은 최소 2대에서 최대 4대의 클라이언트에 의해 사용된다. 매 시뮬레이션마다 변화하는 요소는 노드의 컴퓨팅 리소스, 애플리케이션의 리소스 팩터, 클라이언트 위치가 있다. 임의성에 의한 왜곡을 최소화하기 위해 모든 시뮬레이션은 100, 000회 수행되었으며, 각 결과값은 알고리즘이 성공했을 때의 결과만을 산술 평균하였다.

Fig. 4. Simulation topology.

제안하는 알고리즘은 First Fit Decreasing(FFD), Best Fit Decreasing(BFD), FFD by traffic(FFDt), 홉카운트 기반 배치 기법(HC), 그리고 우리의 이전논문(VSF)과 비교된다[17,19]. FFD의 경우, 컴퓨팅 리소스 요구치별 내림차순 정렬된 VCN들의 서버를 임의로 정렬된 노드에 순서대로 배치한다. 예를 들어, 노드를 3, 1, 5, 2, 4로 임의순 정렬한 후, 컴퓨팅 리소스 요구치가 가장 높은 VCN부터 3에, 다음 VCN은 3에 배치될 수 없다면 1에 서버를 배치하게 된다. BFD는 FFD와 동일하나 VCN 서버를 배치했을 때 가용 컴퓨팅 리소스가 가장 적게 남는 노드 순대로 배치된다. FFDt는 FFD와 동일하나 VCN을 컴퓨팅 리소스 요구량이 아니라 예상 트래픽 부하 평균을 기준으로 정렬한 뒤 배치한다. HC는 트래픽 부하를 고려하지 않고 클라이언트와 서버와의 거리만 최소화하도록 배치하는 기법이며, VSF는 재배치 시 잔여 후보 개수를 고려하지 않으며 우수한 후보만 남긴다는 점에서 제안 기법과 차이가 있다.

Fig. 5은 네트워크 내 서비스되는 애플리케이션 개수 변화에 따른 알고리즘별 배치 결과를 나타낸다. Fig. 5(a)는 애플리케이션 개수가 1개에서 20개로 변화함에 따른 트래픽 부하를 나타낸다. Fig. 5(b)는 동일한 시뮬레이션에서 알고리즘의 성공률을 나타낸다. 애플리케이션 개수가 증가할수록 네트워크 내 총컴퓨팅 리소스 요구량이 증가하여 알고리즘이 실패할 확률이 높아진다. BFD, FFD, FFDt, VCN, HC, 그리고 VSF의 순서대로 성공률이 높은 것을 확인할 수 있다. 상위 3개는 네트워크 지표를 고려하지 않고 최대한 단순하게 배치하는 것이 목적이므로 성공률이 높으며, 하위 3개는 네트워크 부하 지표를 고려하므로 성공률이 약간 낮아지게 된다. 시뮬레이션은 성공한 상황만 평균에 포함시키므로 보정이 필요하게 된다. 성공률이 낮다는 것은 컴퓨팅 리소스 요구량이 높은 상황에서는 알고리즘이 실패하였으며, 리소스요구량이 낮은 상황에 대해서만 배치를 성공하였다는 것이며, 이렇게 배치 난이도가 낮은 상황만 결과에 포함하는 것은 결과에 왜곡을 야기하게 된다. 따라서 실패한 시도에 대해서는 FFD의 결과를 해당 알고리즘의 결과로 간주하여 산술 평균한다. 예를 들어, VSF 알고리즘이 10회 수행 중 7회만 성공하였다면, 7회는 해당 알고리즘의 결과를, 3회는 동일한 상황의 FFD 알고리즘의 결과를 사용하여 산술 평균하게 된다. Fig. 5(c)는 이렇게 보정된 결과 중 FFD의트래픽 총량 대비 주요 알고리즘인 HC, VCN, VSF 의 결과만을 비교하였다. VCN은 어떤 상황에서든 다른 알고리즘 대비 가장 높은 트래픽 감소율을 보여준다. Fig. 5(d)는 전체 시뮬레이션에 대해 VCN별총 홉 카운트의 평균을 나타내며, 홉 카운트를 중시하는 HC가 가장 낮고, 다음으로 VCN, VSF가 낮다. 다만, HC는 총 네트워크 거리는 짧지만 트래픽을 고려하지 않아 네트워크 혼잡을 야기할 가능성이 높아진다. VCN은 네트워크 거리도 낮은 수준이면서 네트워크 트래픽 부하도 가장 낮은 수준으로 유지하는 것을 확인할 수 있다.

Fig. 5. Simulation results for the network performance indicators of each algorithm according to the change in the number of applications, (a) calibrated traffic load, (b) algorithm success rate, (c) traffic load decreased rate of major algorithms versus FFD, and (d) total hop count average over the entire simulation.

Fig. 6은 최대 클라이언트 개수 변화에 따른 주요 알고리즘들의 FFD 대비 트래픽 감소율과 배치 성공률을 보여준다. 매 시뮬레이션마다 VCN들은 2대에서 최대 클라이언트 개수 중 임의개의 클라이언트로 구성된다. 앞선 시뮬레이션에 비해 본 시뮬레이션은 엣지 서버 한 대로 좀 더 많은 수의 클라이언트들을 커버해야 하므로 리소스 요구치가 높아져 배치 성공률이 크게 저하된다. 앞서 언급한대로 과도한 리소스 요구치 설정으로 인해 전반적 성공률 수준이 낮아지게 되었다.

Fig. 6. Simulation results according to changes in the maximum number of clients per application, (a) traffic load decreased rate of major algorithms versus FFD and (b) algorithm success rate.

Fig. 7은 애플리케이션의 컴퓨팅 리소스 팩터 최소값의 변화에 따른 주요 알고리즘들의 FFD 대비트래픽 감소율과 배치 성공률을 보여준다. VCN의엣지 서버는 클라이언트 개수마다 최소 50*리소스팩터에서 최대 150까지의 워크로드 중 정규 분포에 따라 선택된 워크로드 값을 컴퓨팅 리소스 요구치로 가진다. 즉, 팩터가 0.1이면 요구 워크로드는 5-150중에서 선택되며, 2이면 100-150중에서 선택된다. 클라이언트별 리소스 사용량이 증가할수록 성공률과 트래픽 감소율이 저하된다. 하지만 모든 구간에 걸쳐 제안된 VCN 알고리즘은 타 주요 기법에 비해 트래픽 감소율과 알고리즘 성공률이 가장 높은 수준이라는 것을 확인할 수 있다.

Fig. 7. Simulation results according to changes in the minimum computing resource factor of applications, (a) traffic load decreased rate of major algorithms versus FFD and (b) algorithm success rate.

5. 결론

본 연구는 다중 사용자를 수반하는 메타버스 콘텐츠가 클라우드 VR을 기반으로 동작할 때, 엣지 네트워크 환경에서의 서버 구성 및 배치 방법에 대해 다룬다. 제안된 알고리즘은 높은 수준의 컴퓨팅 리소스를 요구하면서 동시에 지연시간에 매우 민감한 클라우드 VR을 위해 네트워크와 컴퓨팅 리소스를 동시에 고려하고, 특히 다수의 클라이언트 위치도 함께 고려하여 엣지 서버를 배치한다. 이를 통해 서버와 클라이언트 간 네트워크 거리를 최대한 짧게 유지하면서 네트워크 혼잡도를 감소시킴으로써 지연시간에 영향을 줄 수 있는 요소들을 최소화하였다. 제안된 알고리즘은 시뮬레이션을 기반으로 기존 배치 기법과의 비교를 통해 애플리케이션 종류가 많거나 동시 접속자 수의 많고 적음에 관계없이 네트워크 내 트래픽을 큰 폭으로 감소시킬 수 있음을 확인하였다.

향후 본 연구 주제와 관련된 시스템 모델을 수립하고 문제를 공식화하여 네트워크 및 컴퓨팅 리소스분배를 다양한 관점에서 최적화할 수 있는 연구를 진행할 예정이다. 이를 통해 실제 네트워크 사용 환경에 가까운, 특히, 높은 품질의 스트리밍 콘텐츠가 존재하는 상황에 대한 시뮬레이션의 신뢰도를 높이고자 한다. 또한, 메타버스 콘텐츠 사용자가 원격에 존재하거나 다수 존재할 때, 멀티 컴포넌트 엣지 서버 구성, 네트워크 간 협업, 그리고 계층화된 엣지 서버 구성 등 다양한 방식을 통해 네트워크 지연을 감소시키는 기법에 대해 연구하고자 한다. 이를 통해메타버스 콘텐츠를 확산시킬 수 있는 클라우드 VR 및 엣지 컴퓨팅 분야에 지속적으로 기여하고자 한다.