“쿠버네티스는 GPU를 잘 활용하기 힘든 플랫폼”

“쿠버네티스는 클라우드의 운영체제라 불릴 정도로 스테이트리스 서비스 운영의 기본 선택지로 자리잡았다. 그렇게 좋은 쿠버네티스지만, CPU와 메모리 자원을 최적화하는 걸 목적으로 태어났기 때문에, 학습과 추론의 AI 워크로드를 운영할 때 GPU를 효율적으로 활용하기에 어려운 부분이 많다. 쿠버네티스에서 GPU를 잘 활용하려면 실제 플랫폼을 구축할 때 발생하는 문제를 운영 관점에서 어떻게 해결할 수 있을 지 봐야 한다.”

강대명 래블업 엔지니어는 지난 24일 <바이라인네트워크>에서 개최한 ‘AI 시대를 준비하는 쿠버네티스’ 웨비나에서 ‘쿠버네티스에서의 효율적인 GPU 활용 방법’을 주제로 발표하며 이같이 설명했다.

강대명 엔지니어는 “GPU는 성능, 메모리, 연결성, 분할 방식, 공유 방식 등에 따라 여러가지가 달라지고, AI 워크로드는 저마다 다른 특성을 갖고 있어 저마다의 GPU 요구 조건을 갖고 있다”며 “쿠버네티스는 디바이스 플러그인 방식으로 GPU를 할당하는 게 기본적인데, 이는 GPU 자원의 이름과 개수를 노출해 정수 단위로 할당하는 방식”이라고 말했다.

그는 “GPU의 개수와 이름만 정의하는 게 대규모 학습에선 문제를 보이지 않지만, 추론이나 다양한 워크로드에서 자원 단편화 문제가 드러나게 된다”며 “GPU 운영의 중심 축이 학습에서 학습+추론 혹은 추론 범위 확장 등으로 가면서 GPU의 활용이 더 중요해지고 있다”고 덧붙였다.

미국 국립 에너지 연구소의 지피유 메모리 활용 측정에 의하면, AI 워크로드에서 GPU 메모리 사용량이 높지 않다. 추론 워크로드마다 어떤 건 빠르게 응답하기도 하고, 어떤 건 느리게 응답하기도 하는데, 이런 AI 추론 워크로드의 비정형성은 부하분산, 자원 효율화를 어렵게 한다.

그는 “디바이스 플러그인 기반으로 ‘GPU를 한개 할당’ 같은 식의 방법은 AI 추론에서 규모의 역설을 만들어낸다”며 “AI 모델마다 필요한 GPU 메모리가 다르고, 최신 GPU는 메모리와 성능이 갈수록 커지는 상황에서 추론 시 단순한 모델로 하나의 GPU를 풀로 쓰기는 어렵다”고 말했다.

쿠버네티스에서 GPU를 공유하는 흔한 방법은 ‘시분할 방식(Time Slicing)’이다. GPU 활용 작업(Job)을 시간을 나눠서 사용하는 것이다. 디바이스 플러그인은 미리 정의된 자원만 할당할 수 있고, 시분할 방식은 사전에 최대 시분할 개수를 정해 그만큼만 GPU를 공유할 수 있다. 사전에 워크로드에 맞춰 최대로 쓸 수 있는 구성을 만들어놔야 하는 것이다.

데이터센터 GPU에서 제공되는 MIG는 물리적으로 GPU를 미리 나누게 하는 좋은 방안이지만, 최대 7개만 분할 가능하다. MIG는 고정된 자원을 변경하기 위해 GPU 하드웨어를 재설정해야 한다.

또한 정수 단위로만 할당 가능하므로, 여러 모델이 GPU 한개의 메모리만으로도 충분하더라도 한 워크로드에 할당된 GPU를 다른 워크로드에서 쓸 수 없다는 단점도 있다. GPU마다 사양이 다르고, 여러 GPU가 NV링크로 연결돼 있기도 하며, MIG 분할 인스턴스가 쪼개져 있기도 하다. 리소스 이름만 파악하는 디바이스 플러그인 방법은 인스턴스의 특성을 알지 못해 개수만 다룰 수 있다.

강대명 엔지니어는 “쿠버네티스가 이런 단점을 극복하는 방안으로 ‘다이내믹 리소스 얼로케이션(DRA)’이란 방법을 도입하긴 했다”며 “DRA는 디바이스 플러그인 방식의 자원 개수 할당법 대신에, 자원 특성을 명시적으로 기술하고 요청하는 방식으로 확장된 모델”이라고 설명했다.

그는 “DRA 드라이버로 메모리 사양, 하드웨어 토폴로지, NUMA, 멀티 GPU 연결 상태 등의 정보를 다 노출하고, 요청 시 특성에 따라 할당하게 하는 방법”이라며 “하드웨어 프로파일을 정의한 ‘디바이스 클래스’, 노드별 가용 자원 상태를 보유했다가 그에 맞춰 할당하는 ‘리소스 슬라이스’, 개별 자원 할당을 요청하는 ‘리소스 클레임’, 반복적인 클레임 생성을 위한 ‘리소스 클레임 템플릿’ 등의 API가 있다”고 말했다.

그는 쿠버네티스에서 GPU 할당과 공유가 어려운 이유를 쿠버네티스의 초점과 GPU 아키텍처의 차이로 지적하면서 4가지 이유를 설명했다. 시간적 공유의 한계, 공간적 분할의 경직성, 네트워크나 토폴로지의 종속성, 내부 연산 유닛 격리의 어려움 등이다.

시간적 공유의 한계는 ‘L2 캐시 스래싱(Thrashing)’ 문제다. CPU처럼 GPU도 내부에 L2 캐시 메모리가 있고, 할당된 AI 워크로드의 컨텍스트가 캐시에 존재한다. 시분할 방식으로 GPU를 공유하면, 논리적으로 시분할 하더라도 물리적인 L2 캐시와 메모리 대역폭은 공유된다. 여러 프로세스가 동시에 GPU에 접근하면 서로의 캐시 라인을 파괴하고, 단독 실행 대비 극심한 성능 저하와 예측 불가능한 지연을 유발한다.

강 엔지니어는 “워크로드별로 연산 유닛을 많이 하는 것과, 메모리 대역폭을 많이 쓰는 게 있을 때, 워크로드 특성에 맞게 영역을 나눠 작업을 하면 L2 캐시 스래싱이 덜 일어난다”고 말했다.

공간적 분할의 경직성은 고정된 MIG 기반의 GPU 파티션에서 발생한다. MIG의 경우 미리 GPU를 최대 7개로 나눠 쓸 수 있고, 그에 따른 메모리 프로파일을 설정하게 된다. 사전 프로파일이 정해지면, 파티션은 고정된다. 이는 메모리와 컴퓨팅의 완벽한 격리를 제공함으로써 성능을 높이는 장점을 갖지만, 프로비저닝이 지나치게 경직되는 문제가 있다. 워크로드의 실시간 요구 사항에 맞춰 슬라이스의 크기를 유동적으로 변경하거나, 조각난 잉여 자원을 통합할 수 없다. 프로세스가 H100의 10GB로 나뉜 메모리 영역을 활용한다면, 남는 용량이 생기거나 모자랄 수 있다.

강 엔지니어는 “MIG는 고가의 GPU에만 있기도 하고, 너무 잘 나눠진다는 게 단점”이라며 “프로파일에 맞는 파티션 정보를 바꾸려면 GPU 리셋을 해야 하고, 그 작업이 수십초에서 수분까지 걸리는데, 대량의 GPU를 돌려야 할 때 매번 MIG 설정을 바꿔가야 하면, 쿠버네티스의 스케줄링을 동적으로 워크로드에 맞춰 만들기 어려워 딜레이를 유발한다”고 설명했다.

네트워크 및 토폴로지 종속성은 멀티 GPU 워크로드와 NUMA 토폴로지의 병목 문제다. 중앙의 스케줄러에게 노드에 GPU 4개가 있다는 단편적인 정수 정보만 제공해선 분산 학습을 최적화하기에 부족하다. GPU 간 통신이 PCIe를 통하는 지, NV링크를 통하는지, NUMA 경계를 넘어야 하는지에 따라 분산 학습(DDP) 성능이 달라질 수 있다. 어떤 GPU에 연결된 버스냐에 따라 통신 시 느려질 수 있다.

강 엔지니어는 “같은 NUMA에 물린 GPU를 할당해주는 게 속도를 더 빠르게 할 텐데, 디바이스 플러그인의 경우 NUMA 정보를 알 수 없으므로 서로 떨어진 형태로 GPU를 할당할 수 있다”며 “네트워크도 마찬가지여서 다른 노드의 GPU를 통신할 때 멀리 떨어진것과 통신하면 문제가 생긴다”고 설명했다.

내부 연산 유닛 격리의 어려움은 단일 GPU 내부의 TPC 할당과 격리의 난해함이다. 단일 GPU 내 남는 연산유닛(TPC/SM)을 쪼개 쓰는 건 메모리 용량을 나누는 것과 저혀 다른 차원의 복잡성을 갖는다. 연산 유닛의 중첩을 막고 독립적인 컨텍스트를 유지하는 하드웨어 지원이 없으면, 진정한 의미의 내부 공유는 불가능에 가깝다는 게 그의 설명이다.

강 엔지니어는 “물리적으로 연산 유닛을 정확히 나누는 방법은 복잡할 뿐 아니라, 물리적으로 나누려 해도 제대로 명시적으로 동작하지 않는다”며 “엔비디아는 SM, AMD는 CU, 인텔은 EU 등 저마다 사용 방법도 달라 전부 이해해야 한다”고 말했다.

이런 문제에서 쿠버네티스의 DRA가 완전한 해법도 아니다.

그는 “DRA를 정확하게 사용하려면 드라이버에서 정보를 다 제공해야 하고, 이 정보를 사용자가 모두 이해하고 있어야 한다”며 “새로운 GPU가 나오거나 NUMA 인덱스 같은 분야를 잘 모른다면 잘 사용하기 어렵다”고 했다.

다음으로 그는 금융, 의료, 공공 등 정보보호 규제에 민감한 산업에서 컨테이너 방식 대신 가상머신(VM)으로 더 강한 격리 환경을 구성해야 하는 상황의 어려움에 대해 설명했다.

쿠버네티스의 원래 리눅스 컨테이너를 위한 운영체제다. 한 호스트 상의 여러 컨테이너는 OS 커널을 공유하고 서로 연결돼 있고, 호스트 관리자가 컨테이너 정보를 읽을 수 있다. 더 강한 격리를 원하는 엔터프라이즈 환경에서 VM을 쿠버네티스로 관리할 수 있게 하는 기술이 ‘쿠베버트(KubeVirt)’다. 쿠베버트는 쿠버네티스 POD 내부에서 VM을 실행해 개별 게스트OS를 제공한다. 만약 쿠베버트로 쿠버네티스에서 VM을 쓰고, AI 워크로드를 운영해야 하는 경우 GPU 할당이 더 어려워진다.

그는 “컨테이너는 NUMA 정보부터 GPU 사양 등 호스트 정보를 다 알고 있어서 자원 공유가 쉽지만, VM은 PCI 패스스루를 통해 GPU 하나 혹은 N개를 VM이 전부 관리하는 게 일반적”이라며 “VM 안에서 GPU를 쓰면, VM 밖에서 GPU 정보를 볼 수 없고, 이를 위한 엔비디아 vGPU는 고가의 라이선스를 구매해야 해서 도입 제약과 비용 제한이 크다”고 말했다.

전통적인 고성능컴퓨팅(HPC)은 슬럼(slurm)을 사용해 워크로드를 관리한다. 각각의 노드에 슬럼디(Slurmd)란 데몬을 둬 전체 노드를 쓰게 한다. 래블업의 AI 인프라 운영 플랫폼인 ‘백엔드닷에이아이(Backend.AI)’도 ‘소코반 스케줄러’를 통해 클러스터 레벨에서 GPU를 스케줄링하고, 에이전트가 단일 스케줄에서 호스트 정보를 쓰고 GPU를 컨테이너 별로 할당한다. 플랫폼이 GPU를 완전히 쓰기 위해 호스트 전체를 잘 관리하는 형태로 동작하는 것이다.

플랫폼으로 AI 인프라 호스팅의 문제를 해결한다고 해도 문제는 있다. 쿠버네티스 상에 네이티브하게 GPU를 올리거나, 외부 플랫폼을 쿠버네티스로 미러링해서 동작을 보는 방법이 일반적인 두 방향이다.

‘네이티브 온 쿠버네티스’의 경우 관리형 코드가 쿠버네티스 상에서 돌아가며, 슬럼은 하나의 큰 컨테이너 코드를 할당 받아 다시 쪼개 쓰고, API, RBAC, 배포/관측 도구와 자연스레 통합된다. ‘미러 투 쿠버네티스’의 경우 실제 워크로드를 실행하는 플랫폼은 그대로 두고, 돌아가는 모든 워크로드를 쿠버네티스에 가상으로 보여줘 쿠버네티스의 툴이 상태와 객체를 인식하고 관리하게 하는 것이다.

강 엔지니어는 “GPU는 원래 추상화하기 어려운 자원이고, 현재의 쿠버네티스는 GPU를잘 활용하기 어려운 플랫폼”이라며 “네이티브온쿠버네티스도 그 안에서 서로 워크로드 간 통신이 더 복잡하고, 미러투쿠버네티스는 미러링을 계속해야 해서 쿠버네티스에 완벽히 맞춰 돌아가기 어렵기 때문에 기술적 선택이 필요하다”고 말했다.

글. 바이라인네트워크
<김우용 기자>yong2@byline.network