KubeCon Europe 참관기, 그리고 GPU Sharing

KubeCon Europe 참관기

Kubernetes 외길을 걸어온지 여느넛 1년 넘게 지났다. 회사를 들어오고 나서부터 쿠버네티스를 시작했으니 일년 넘었다. 이전에는 스터디에서 Kubernetes와 ETCD, Consul 등을 공부했었는데 지금 와서 생각해보니 아주 좋은 선택을 한 것 같다. 클라우드가 새로운 세상을 만들었고, 컨테이너를 통해서 클라우드 컴퓨팅을 아주 자유롭게 만들었으며, Kubernetes 같은 오케스트레이터의 등장으로 인해서 한 노드에서 여러 컴퓨터를 컨테이너를 통해서 손쉽게 관리할 수 있게 되었다.

이러한 것에서, 회사에서는 클라우드 네이티브 방식을 따르기 위해서 여러가지를 찾고 있다. 예전에는 많이 만들어서 사용하고 있었던 것들은 지금 와서는 있는걸 잘 사용하기 위해서 어떻게 조립할 것인가? 라는 주제로 많이 리서치를 하고 있다.

그러던 참에 저번년도에 가기로 했던 쿠베콘 유럽이 코로나로 인해서 국경이 잠기게 되면서, 해외에는 영영 못나가게 되었다. 이러한 부분을 좌절하는 것보다는 전화위복의 기회로 삼자는 생각을 하고 여러가지 Keynote를 찾아보고, 슬라이드를 찾아보는데 시간을 많이 쏟고 있다. 공교롭게도 회사에서 KubeCon Europe 2020 티켓을 사 주셔서 온라인으로 몇가지 비디오도 보고, 슬라이드도 찾아보았다.

몇달 전부터 GPU 공유에 대해서 관심이 좀 있었는데, 시간만 나면 Kubernetes Issue #52757의 "Is sharing GPU to multiple containers feasible?" 이라는 아티클에 올라온게 없나 계속 읽고 있었는데, 많은 Project들이 일어나고 있었다. 몇가지 방법이 있었던것 같았는데, 공유하자면 다음의 두가지로 압축될 것이다.

1) 물리적인 GPU를 불리는 작업.

2) GPU드라이버를 후킹(Hooking)하여 작업.

3) ...? 자본이 짱입니다 여러분!

첫번째 방법은 아주 간단하게, nvidia 의 k8s-device-plugin 을 개조해서 디바이스를 불리면 된다. 어차피 GPU ID를 가상의 GPU ID로 만들고 이 ID를 GPUID로 바꿔치기만 하면 되는 것이다. 플러그인도 Golang 으로 나와 있으니 손쉽게 바꿔치기가 될 것이다. 근데 문제는 1번의 방법은 그냥 한개 있는걸 분식회계 하듯이 2개만 알려주고, 실제로는 1개만 있는 것이니 특정 애플리케이션에서는 에러가 발생하게 되는 것이다.

이럴때 해결 방법은 TensorFlow 의 ConfigProto의 설정을 만들어서, Memory 의 양을 제한하면 된다. (코드는 귀찮으니 알아서 찾아보면 된다.) 근데 문제는 사람들은 TensorFlow 만 사용하지 않고, PyTorch 혹은 다른 딥러닝 라이브러리를 사용할 것이다. 그래서 이 방법은 공돌이라면 사용이 가능하겠는데, 모르면 안되기 때문에 더 좋은 방법을 찾아보자.

그래서 나온 방법이 두번째 방법이다. 해당 쿠다 드라이버를 후킹하는 드라이버를 만든 후에 후킹된 TensorFlow 등의 라이브러리가 CUDA 드라이버를 읽을 때 *.so 라이브러리를 읽기 위해서 접근할때 가로채서 다른 정보를 주는 것이다. 가령, SP가 몇개인지, VRAM 은 사이즈가 얼마인지를 조정해서 주면 그 "거짓" 정보를 받아들은 애플리케이션은 그 정보대로 할당을 할 것이고, 할당된 방법으로 작업을 진행할 것이다.

그러나 여기에도 많은 문제가 있는데, 해당 방법은 구현이 가능해보여도 (아주 쉬울것만 같다. 아마 C++랑 CUDA 만 공부하면 어느정도는 따라만들 수 있을것만 같다.) 해당 방법은 한국에서는 특정 기업이 특허권으로 들고 있어서 접근자체가 안되는 방법이다. (뭐, 중국을 통해서 우회하면 어차피 빠그라지니 상관은 없겠지만, 여기는 한국이기 때문에 한국법을 따라야 하겠지.)

근데 문제는 해당 방법을 통해서, Tencent에서 개발을 했다는 점이다. 슬라이드에서 이야기하기로는 Tencent에서는 NVIDIA Device Library를 자체적인 Custom Wrapper을 통해서 개발했고, 개발된 Custom Wrapper을 통해서 앞서 언급한 CUDA Core 및 VRAM 요청을 Request/Limits 를 걸 수 있도록 디자인했다. (코드는 이미 전부터 Tracking 하고 있었는데, Custom Wrapper은 C++로 제작되어 있고, Device Plugin 등은 Golang으로 작성하였다.)

그리고 2020년도 넘어서는 KubeShare이라고 하는 Kubernetes에서 GPU를 공유하는 라이브러리가 출시되었다. 앞서 언급한 Tencent에서 개발한 라이브러리와는 달리, Custom Controller을 통해서 컨트롤되고, "모 기업" 이 보유하고 있는 특허 방법을 거의 똑같은 방법으로 구현해서 개발하였다. 그리고 여러가지의 좋은 이유가 있다고는 하는데, 저들의 방법이 어떻게 되는지는 계속 코드를 읽어나가면서 좀 실증리뷰를 해봐야 되겠다.

하여간, FAANG(FACEBOOK-APPLE-AMAZON-NETFLIX-GOOGLE)들이 세계 시장을 먹어치우는 세상에서, 구글이 출시한 Kubernetes를 통해서 클라우드 환경을 손쉽게 구성하고, 이러한 환경을 사람들이 잘 사용할 수 있도록 구성해놓은 Provider 들이 Amazon, Google, Microsoft 3회사라고 생각한다. 이렇게 깔려있는 판을 보고 있자하니, 거의 그 간극을 매꾸어 주는 부분은 레거시는 거의 사라지고, 거의 다 컨테이너 환경에서 환경을 구성하고 있고, 이러한 쿠버네티스의 환경을 통해서 Cloud Native 한 환경을 구성할 수 있지 않나 싶다.

어쨌거나, 경제학과 학생이 레포트만 썼다 하면 이게 비즈니스가 되는 세상에서 살고 있는데, 다음에는 KubeShare 이라고 하는 녀석이 어떻게 작동을 하는지에 대해서 리뷰를 좀 해봐야 되겠다.

[참고 문헌]

1. "Is sharing GPU to multiple containers feasible?", https://github.com/kubernetes/kubernetes/issues/52757
2. "Is Sharing GPU to Multiple Containers Feasible? - Samed Güner, SAP", https://sched.co/ZesB
3. (해당 슬라이드) https://github.com/samedguener/slides/blob/master/kubecon-2020/August-18_Is-Sharing-GPU-to-multiple-Containers-feasible.pdf