ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Google Stadia 분석: Specification(사양)편
    Analysis 2019. 5. 10. 19:00

    Stadia Specifications

    Stadia Data Center

     

    Stadia는 클라우드 서버를 그 근간으로 하고 있다. 현대의 클라우드 서버는 여러대의 서버 인스턴스를 모아놓은 랙과 이 랙들이 모여있는 거대한 룸의 형태로 이루어져 있는데, 그 하나의 서버 인스턴스를 블레이드 서버라고 지칭한다. 책장에 꽂힌 책들처럼 여러 대의 블레이드 서버가 모여 클라우드 서버를 구성한다. 구글은 Stadia를 구성하는 블레이드 서버의 하드웨어 사양을 다음과 같이 발표했다.

     

    GPU CPU Memory

    10.7 Teraflops

    56 compute units

    HBM2 Memory

    Custom x86 Processor

    2.7 GHz

    Hyperthreaded

    AVX2

    16 GB of total RAM

    Up to 484GB/s transfer speed

    L2+L3 Cache of 9.5MB

     

    AMD와의 협업을 통해 Custom 제작한 GPU, 역시 Custom 제작을 한 CPU, 그리고 16기가의 램이 그 내용인데, 블레이드 서버 하나가 하이엔드 PC에 비견될 수 있는 성능을 가질 것으로 보인다. Stadia 블레이드 서버의 스펙에서 가장 주목해야 할 부분은 GPU이다. 구글은 Stadia 발표에서 현존하는 콘솔 게임기에 대비해 Stadia의 성능이 더 뛰어남을 강조했다.

     

    PlayStation 4 Pro Stadia Xbox One X
    4.2 teraflops 10.7 teraflops 6.0 teraflops

     

    사실 GPU스펙을 보여주는 것은 어느 정도 부풀려진 이미지를 노린 것이다. Stadia의 블레이드 서버는 PC에 준하는 형태를 가지고 있다. 그런데 사람들의 일반적인 인식으로는 플레이스테이션이나 엑스박스와 같은 게임 전용 콘솔의 GPU 성능이 PC보다 월등히 뛰어나다 믿기에 Stadia의 성능이 더욱 대단해 보이는 것이다. 그러나 한 번 출시되면 10년 가까이 유지되는 게임 전용 콘솔의 특성상 게임 전용 콘솔의 GPU 성능은 동시대의 하이엔드 PC보다 떨어지는 것이 일반적이다. 즉, 현존하는 최고 성능의 게임 기기는 게임 전용 콘솔이 아닌 하이엔드 PC이다. 그렇다면 현존하는 하이엔드 PC의 GPU 성능과 Stadia를 비교하면 어떨까?

     

    TITAN V Radeon RX Vega 64 GeForce GTX 1080 Ti Radeon R9 295X2 Stadia
    13.8 teraflops 12.7 teraflops 11.3 teraflops 11.2 teraflops 10.7 teraflops

    source: https://www.geeks3d.com/

     

    PC 코어 게이머들의 로망인 GeForce GTX 1080 Ti 정도면 Stadia의 성능을 충분히 상회한다. 거기에 단순히 스펙상의 gflops 숫자로 나타나지 않는 NVidia의 게임 플레이 최적화된 GPU 설계와 성능을 고려하면 체감되는 게임의 구동 성능은 하이엔드 PC쪽이 훨씬 더 뛰어날 것이다.

     

    Linux + Vulkan

     

    Stadia는 Linux기반의 Vulkan을 활용한다고 발표했다. Vulkan에 대한 부연 설명이 조금 필요한데, Vulkan은 표준화 그룹인 Khronos의 주도로 제정된 새로운 그래픽 라이브러리 표준이다. 기존 윈도우즈에서는 DirectX라는 마이크로소프트의 독자 표준을 사용해 왔고, Linux진영에서는 OpenGL이라는 역시 Khronos 그룹이 제정한 표준을 사용해 왔다. 모바일 기기에서는 OpenGL이 너무 무겁기 때문에 OpenGL ES라는 OpenGL의 부분집합 개념의 표준을 사용했다. 대부분의 모바일 기기들에서는 OpenGL ES 라이브러리가 제공되었고 운영체제나 어플리케이션들은 이 라이브러리를 사용해 그래픽을 표현했다. 안드로이드의 최하단 Rendering을 담당하는 SurfaceFlinger 역시 OpenGL ES를 사용하여 렌더링 연산을 수행해왔다.

     

    문제는 이 OpenGL ES가 오랜 세월을 거치면서 상당히 많은 기능이 추가되었고, 이에 따라 점점 무거운 라이브러리로 변형되어 왔다는 점이다. 이를 극복하기 위해 Khronos에서는 가벼운 형태의 새로운 그래픽 라이브러리 표준을 정의하게 되는데 이것이 바로 Vulkan 라이브러리다. 참고로 애플은 독자적으로 DirectX와 비슷하게 Metal이라는 표준을 만들어 사용하고 있으며, 이는 Vulkan보다 먼저 상용화되었다. 성능 이점으로 인해 Vulkan 라이브러리는 점차 여러 모바일 기기에서 지원되기 시작했고, Linux에서도 역시 지원이 가능해졌다.

     

    구글의 발표는 Stadia는 Linux기반의 운영체제를 탑재하고 있으며 Vulkan을 사용해 성능 향상이 기대된다는 점을 강조한 것이다. 그런데, 사실 모바일 기기가 아닌 PC에서 Vulkan의 유용성이 클지는 의문이다. Stadia의 블레이드 서버 인스턴스는 PC에 준하는 형태를 띄고 있으며 서버이기에 무제한의 전력을 공급받으며 발열이 발생해도 적정 온도가 유지되는 환경에서 구동된다. 저전력과 발열 감소를 위해 클럭을 희생해야 하는 모바일 기기와는 확연히 다른 환경이다. 그리고 Linux + Vulkan 조합이 Windows + DirectX 조합보다 높은 성능을 가지기는 어렵다. Vulkan과 같은 시도를 사실상 90년대 부터 시작한 것이 DirectX이고 그간 다양한 게임을 통해 성능이 검증된 플랫폼이라는 점을 감안한다면 구글의 선택이 성능 향상보다는 라이센스 비용 감소가 그 목적이 아닐까 하는 합리적인 의심을 해볼 수 있다.

     

    Multiple Server Instances

     

    소개편의 Features에서 다루겠지만 구글은 하나의 블레이드 서버 인스턴스로는 감당하기 어려운 특장점들을 소개한다. 그리고 이를 가능하게 하기 위해서 하나의 하드웨어가 아닌 데이터 센터를 활용함을 강조한다. 다시 말해서 하나의 게임을 구동하기 위해 다수의 블레이드 서버 인스턴스를 동원하고, 다수의 GPU나 CPU를 해당 게임의 구동을 위해 활용한다는 것이다. 이 역시 듣기에는 그럴듯하지만, Parallel Processing이 무한대의 성능을 보장해 주지 않는다는 점에서 생각해볼 여지가 남는다. 여러 개의 하드웨어를 사용할수록 연산을 분리하고, 또 분산된 결과를 취합하는 오버헤드도 늘어나게 된다. 이 오버헤드가 임계점을 넘으면 결국 성능이 일정하게 유지되거나 오히려 저하되는 결과로 이어지는 것이 현실이기 때문이다.

     

    또한 데이터 센터를 활용한 GPU/CPU Farm 형태의 솔루션은 서버 비용의 증가로 직결된다. 과거에 존재했던 클라우드 서버 기반의 게임 스트리밍 서비스들의 경우 서버 비용을 줄이기 위해 하나의 서버 인스턴스를 여러 사용자가 나누어 쓰는 기술을 공들여 개발하고 적용해왔다. 인스턴스 당 유저 숫자가 높을수록 더 싼 스트리밍 서비스가 가능하기 때문이었다. Stadia는 이와 정반대로 한 명의 유저가 다수의 서버 인스턴스를 점유하고 사용하는 형태의 서비스를 제공한다고 발표했다. 루머에 따르면 Stadia 서비스는 게임을 구매하는 비용을 제외하면 사용자에게 스트리밍 서비스 사용에 대한 과금을 하지 않는다고 한다. 사용자가 많아질수록, 또한 스트리밍을 많이 사용할수록 트래픽 비용이 급증하게 될 것이 쉽게 예측되는데, 아무리 마케팅 비용으로 큰 투자가 가능한 구글이라지만 유료 게임 판매와 게임내 구매를 통해서 안정적인 비즈니스 모델을 만들어 낼 수 있을지 의문이다.

     

    Stadia Controller

     

    구글은 Stadia 전용 컨트롤러를 발표했다. PC 게임을 즐기는 사용자들에게 게임 컨트롤러는 익숙한 악세사리이며, 최근의 PC 게임들은 콘솔화를 의식해서 대부분 게임 컨트롤러를 지원하고 있다. PC보다 규모는 적지만 스마트폰이나 태블릿과 연동하여 사용할 수 있는 게임 컨트롤러 역시 크고 작은 제조사에서 다양한 제품이 출시되어 있다. 구글은 사용자가 이미 가지고 있는 게임 컨트롤러를 Stadia에 활용할 수 있다고 언급했으며, 이와 동시에 Stadia 전용의 게임 컨트롤러를 발표한 것이다.

     

    구글이 언급한 Stadia 전용 게임 컨트롤러는 일반적인 컨트롤러와 다른 2개의 버튼이 존재한다. 첫 번째 버튼은 Capture 버튼이다. 이 버튼을 통해 사용자는 게임의 다양한 부분들을 Capture하여 다른 사용자들에게 공유할 수 있다. 두 번째 버튼은 Google Assistant 버튼이다. 이 버튼을 누르면 컨트롤러에 내장된 마이크로폰이 작동하며, 사용자는 음성 명령을 통해 게임의 요소들을 호출할 수 있다. Capture 버튼의 경우는 플레이스테이션 컨트롤러에도 유사하게 비디오 캡쳐 기능을 하는 버튼이 존재해서 그리 새로운 기능은 아니다. Google Assistant 버튼의 경우 Stadia만의 특색이기는 하지만 게임 중간에 이 버튼을 누르고 굳이 음성을 통해 명령을 내릴 일이 많을지는 미지수이다. 음성입력을 활용하는 몇몇 게임이나 FPS 게임에서 팀원들과 의사소통을 위한 용도 이외에는 크게 쓰일 일이 없을 것으로 보인다.

     

    그러나 위에 언급한 기능을 위해 전용 컨트롤러를 만든 것은 구글의 주된 목적이 아닌 것으로 보인다. Stadia 전용 컨트롤러의 가장 큰 특징은 컨트롤러가 클라이언트 기기가 아닌 Stadia의 데이터센터로 와이파이망을 통해 직접 연결된다는 점이다. 전통적인 클라우드 게임 스트리밍에서 게임 컨트롤러는 블루투스나 유선 연결의 형태로 클라이언트 기기에 연결이 되고 클라이언트 기기는 여기서 발생하는 입력 신호를 클라우드 서버로 전송하는 구조를 가진다.  Stadia 전용 컨트롤러는 이 중간 과정을 생략하고 사용자의 입력을 데이터센터로 직접 전송한다. 이 방법을 통해 Stadia는 입력 Latency를 획기적으로 줄일 수 있다고 설명한다.

     

    사실 서버로의 컨트롤러 직접 연결은 안드로이드 운영체제의 오래된 문제를 해결하기 위한 고육지책이다. 애플의 아이폰이나 지금은 사라진 윈도우즈폰의 운영체제는 네이티브 기반이고 이런 운영체제에서는 블루투스를 통한 컨트롤러 연결의 Latency가 현저히 낮게 처리된다. 그러나 안드로이드는 네이티브 스택 위에 자바로 이루어진 커다란 스택이 존재하며, 블루투스를 통해 안드로이드 기기에 연결된 컨트롤러의 Latency는 좋지 않은 성능을 보인다. 이는 안드로이드 초창기부터 있어왔던 오래된 문제이며, 특히 오디오 신호를 전달하는 헤드셋이나 마이크, 연주와 관련된 장치에서는 큰 문제가 되어왔다. 최근 안드로이드 버전에서 많은 개선이 있기는 했지만, 여전히 변화무쌍한 Latency를 보이는 경우가 많다.

     

    Stadia는 안드로이드의 블루투스 성능 저하를 딛고 사용자의 게임 입력을 원활하게 처리하기 위해 컨트롤러를 데이터센터에 직접 연결한 것이다. 문제를 극복하기 위한 좋은 시도로 보이지만, 컨트롤러가 직접 인터넷에 연결이 되어 있어야 한다는 점에서 사용자 시나리오가 그리 좋을 것 같지는 않다. 디스플레이가 없는 컨트롤러를 와이파이에 연결하기 위해서는 결국 클라이언트 기기를 통해 설정을 해주어야 하는데, 최근 프린터의 무선 셋팅에서 보듯이 이런 형태의 설정은 엔트리 레벨의 사용자에게 쉬운 작업이 아닐 것이다. 또한 연결이 끊어지거나, 망이 전환되는 등의 예외 상황 처리도 녹록하지는 않아 보인다.

     

    Google Backbone

     

    구글은 클라우드 게임의 레이턴시 이슈를 의식하여 이를 개선하기 위한 시도로 Public Internet이 아닌 자사의 Backbone 망을 활용한 Stadia 서버와의 연결을 제시했다. 인터넷의 특성상 네트워크 패킷은 목적지에 도착하지만 어떤 경로로 패킷이 전달될지는 보장되지 않는다. 패킷이 도착하는 순서가 각각 달라져서 의미있는 데이터를 확보하는데 기대치보다 오랜 시간이 걸리는 경우가 발생해 고른 품질의 스트리밍이 보장되지 않는 점을 개선하기 위해 구글은 자사가 그동안 투자한 해저 케이블 등 전용 망을 이용하여 Stadia서버와 연결된다고 설명했다. 이를 통해 예측 가능한 Latency, 안정적인 연결, 그리고 덤으로 보안성도 강화된다는 설명이다. 이는 실제로 기술적으로 상당히 유의미한 부분이라고 할 수 있다.

     

    그러나 사실 전용망을 통한 클라우드 서버 연결은 클라우드 서비스를 하기 위해서는 기본적으로 선행되어야 할 부분이다. 스트리밍 서비스 제공자나 Low Latency의 네트워크 서비스를 제공하는 벤더들의 경우 대부분 서비스 제공 지역에 자체 Backbone 망을 구축하고 있거나 Backbone을 대여하여 사용한다. 사실상 타 사업자들의 서비스에서도 Stadia와 같은 형태의 서비스가 제공되는 것임을 고려하면 Stadia만의 큰 차별점이라 보기는 어렵다. 물론 구글의 전용망은 전세계의 대부분을 커버할 수 있다는 점과 유투브를 통해서 그 안정성이 입증되어 있다는 점은 구글만의 장점이라고 할 수 있겠다.

     

    또 하나의 맹점은 사실 최근의 클라우드 서버 연결은 인터넷 망뿐만이 아닌 이동통신망을 통해서 이루어지는 경우가 늘어나고 있다는 점이다. 구글이 전용망을 운영하더라도 사용자의 클라이언트 기기가 이동통신망에 물려 있다면 전용망의 장점이 반감될 수밖에 없다. 사실 이를 극복하기 위해 최근에는 Edge Computing이 대두되고 있다. 클라우드 서비스를 인터넷망이 아닌 이동통신망 내부에 구축하는 방법을 통해 이동통신망에 물린 기기들이 인터넷망으로 나가지 않고 이동통신망 내에서 클라우드 서비스를 접근하는 방식이다. 이를 지원하기 위해서는 이동통신망 내부에 클라우드 서비스를 위한 서버를 구축하는 작업이 필요하다. Stadia도 이동통신사와 협력을 통해 이와 같은 방식의 접근을 하는 것이 미래의 통신 환경을 대비하는 방법이 될 것이다.

     

     

    Fin.

    반응형

    댓글

Calvin's Memo