마이크로소프트는 2025년 1월 말, 매니지드 서비스인 AKS(Azure Kubernetes Service)에서 WASI(WebAssembly System Interface) 노드 풀에 대한 실험적 지원을 종료할 것이라고 발표했다. 쿠버네티스에서 WASI의 발전 과정을 지켜본 사람에게 놀라운 소식은 아니다. AKS에서 서버 측 WASI 코드를 사용하는 경우 지원 종료에 따라 대체 런타임으로 마이그레이션하기 위한 얼마간의 작업이 필요하다.

마이크로소프트가 제안하는 2가지 옵션이 WASI에서 벗어난다는 의미는 아니다. 웹어셈블리와 쿠버네티스는 잘 어울리는 기술이다. 실제로 여러 오픈소스 프로젝트가 빈 틈을 메워 AKS 플랫폼에 새로운 계층을 추가하고 중단을 최소화하면서 계속 운영할 수 있게 해준다.

AKS에서 WASI 노드 풀을 사용하는 경우 5월 5일을 마지막으로 그 이후에는 새 노드 풀을 만들 수 없다. 기존 WASI 워크로드를 계속 사용할 수는 있지만, 이제 새로운 개발과 업그레이드를 위한 대안을 살펴볼 시점이다. 마이크로소프트 자체의 WASI AKS 서비스가 중단될 때까지 기다려서는 안 된다. 2가지 대안에 대한 공식적인 지원을 이용해 지금 바로 전환 계획을 시작할 수 있다.

크러슬릿에서 무엇으로?

AKS WASI 노드 풀의 큰 문제는 러스트를 사용해서 웹어셈블리 지원 큐블릿을 빌드한 실험적 크러슬릿(Krustlet) 프로젝트에 대한 종속성이다. 크러슬릿은 클라우드 네이티브 컴퓨팅 파운데이션 샌드박스 프로젝트였음에도 불구하고 팀원들이 다른 프로젝트로 옮겨가면서 유지 관리가 중단됐다. 유지 관리자가 없으면 앞으로 쿠버네티스와 웸어셈블리의 발전을 따라가지 못하고 프로젝트는 뒤처지게 된다.

핵심 종속성에 더 이상 의존할 수 없게 된 만큼 마이크로소프트도 AKS에서 웹어셈블리에 대한 접근 방식을 변경할 수밖에 없었을 것이다. 마이크로소프트 입장에서 다행인 점은 AKS가 쿠버네티스와 함께 작동하기 위한 관리되는 방식을 제공하면서 표준 API를 통해 광범위한 쿠버네티스 생태계를 지원한다는 것이다. 덕분에 마이크로소프트는 자체 플랫폼에서 WASI를 실행하기 위한 대안을 제공할 수 있다.

스핀큐브를 사용해 AKS에서 웹어셈블리 함수 실행

한 가지 옵션은 다른 WASI를 쿠버네티스 환경에서 실행하기 위한 프로젝트의 런타임을 사용하는 것이다. 스핀큐브(SpinKube)는 표준 쿠버네티스 컨테이너 호스트인 containerd에 대한 심(shim)을 개발해 왔으며, 이를 통해 기반 쿠버네티스 인프라를 변경하지 않고도 runwasi를 사용해 WASI 워크로드를 호스팅할 수 있다. 웹어셈블리 전문 기업인 퍼미온(Fermyon)이 후원하는 스핀은 쿠버네티스 툴의 역사를 잇는 솔루션으로, 헬름(Helm)과 브리게이드(Brigade)를 만든 개발자들로 구성된 팀이 오랜 기간에 걸쳐 구축했다.

스핀큐브는 WASI 워크로드를 사용하고 쿠버네티스로 이를 관리하는 서버리스 컴퓨팅 플랫폼이다. containerd-shim-spin 툴은 runwasi 지원을 추가하므로 노드가 WASI 코드를 표준 쿠버네티스 리소스로 취급해 호스팅할 수 있다. 노드는 WASI 런타임을 호스팅하고 레이블을 통해 워크로드가 적절히 예약되도록 보장하므로 WASI와 표준 컨테이너를 동시에 실행할 수 있으며, 이벤트 기반 작업을 위한 KEDA(Kubernetes Event-driven Autoscaling)와 같은 툴도 사용할 수 있다.

그 외의 스핀 툴은 심을 배포하고 수명 주기를 관리해 항상 최신 버전을 실행하고 포함된 심이 애플리케이션에 포함되어 배포되도록 보장한다. 이를 통해 WASI 워크로드 작업을 자동화할 수 있다. 이 구성은 원래의 WASI 노드 풀 구현에 비해 더 많은 관리가 필요하지만 모든 작업을 명령줄과 kubectl을 통해 수행해야 하는 상황에서 벗어난다는 유익한 측면이 있다.

마이크로소프트는 자사 툴의 대체재로 스핀큐브를 권장하며 AKS에서 스핀큐브를 사용하는 방법에 대한 지침도 제공한다. 스핀큐브는 윈도우 기반 쿠버네티스 인스턴스와 함께 사용할 수 없기 때문에 리눅스 기반 AKS 클러스터가 필요하다. 스핀큐브를 기존 AKS 클러스터에 배포할 수 있으므로 처음부터 새로 시작할 필요는 없다. 이 방식을 사용하면 스핀큐브 기반 WASI 노드 풀로 마이그레이션하면서 인프라 업데이트를 완료할 때까지 마이크로소프트 자체 툴을 사용해 운영을 지속할 수 있다.

AKS에 스핀큐브 배포

애저 마켓플레이스를 통해 제공된다고는 해도 스핀큐브와 AKS를 사용하기 위한 지침의 대부분은 플랫폼 자체 리포지토리에서 쿠버네티스 툴을 사용해 설치하는 방법에 기초한다. 이게 더 복잡한 방식일 수 있지만 대부분의 쿠버네티스 오퍼레이터가 설치되는 방식과 더 잘 맞고 커뮤니티 지원을 받기에도 용이하다.

AKS 클러스터를 만든 후 스핀큐브를 배포하려면 애저 CLI가 필요하다. 애저 CLI에서 AKS 자격 증명을 사용해 쿠버네티스 kubectl 툴을 실행한다. 클러스터는 헬름을 사용해 배포할 수 있는 cert-manager를 실행해야 한다. 이 단계까지 마치면 스핀큐브의 runtime-class-manager와 관련 오퍼레이터를 설치한다. 자체 리포지토리에서 원래 이름인 KWasm으로 찾을 수 있다.

이제 kubectl에서 annotate node 명령을 사용해 containerd 심을 클러스터에 배포할 수 있다. 이 명령은 runtime-class-manager에 심을 배포하고 사용할 준비가 된 노드에 레이블을 지정하도록 알려준다. 이제 kubectl을 사용해 깃허브에서 스핀 구성요소를 복사하고 클러스터에 적용해서 스핀큐브 맞춤형 리소스 정의와 런타임 클래스를 클러스터에 추가할 수 있다. 여기까지 완료되면 헬름을 사용해 SpinAppExecutor를 추가하기 전에 spin-operator를 배포한다.

시작하고 실행하는 과정이 비교적 복잡하지만 애저 CLI 스크립트에 전체 배포 프로세스를 래핑하는 옵션이 있다. 이를 통해 프로세스를 자동화하고 여러 애플리케이션 인스턴스와 애저 지역에 걸쳐 반복할 수 있다.

스핀큐브 노드가 준비되면 WASI 애플리케이션을 새 환경으로 가져올 수 있다. 스핀은 OCI 호환 레지스트리에서 WASI 코드를 로드하므로 애저 인프라에 이러한 레지스트리를 설정해야 한다. 깃허브 패키지 서비스에 포함된 것과 같은 CI/CD 통합 레지스트리를 사용하는 방법도 있다. 이 방법을 선택하는 경우 깃허브 엔터프라이즈 계정을 사용해 레지스트리를 비공개로 유지해야 한다.

이 방식을 사용하면 깃허브 액션의 일부로 코드를 WASI로 컴파일하고 동일한 액션을 사용해 리포지토리에 저장할 수 있다. AKS 애플리케이션은 항상 WASI 모듈의 최신 빌드에 액세스하게 된다. 모든 쿠버네티스 애플리케이션이 그렇듯이 코드에 대한 YAML 설명을 정의하고 코드의 실행자로 containerd 심을 사용해야 한다.

와즘클라우드와 함께 AKS에서 WASI 마이크로서비스 사용

스핀큐브의 대안으로 와즘클라우드(wasmCloud)라는 또 다른 CNCF 프로젝트를 사용할 수 있다. 이 경우 다양한 와즘클라우드 구성요소를 동시에 설치하기 위해 헬름 차트가 필요하다. 애저 포털과 통합되지 않으므로 애저 CLI와 kubectl이 AKS를 관리하도록 해야 한다. 또한 아키텍처 접근 방식에 상당한 차이가 있기 때문에 처음부터 새로 시작해서 와즘클라우드에서 사용할 수 있도록 클러스터와 애플리케이션 아키텍처를 다시 설계해야 한다.

헬름을 사용해 와즘클라우드 플랫폼 구성요소를 설치하기 전에 우선 와즘클라우드를 위한 쿠버네티스 네임스페이스를 만든다. 포드가 재시작되면 kubectl을 사용해 와즘클라우드 인스턴스를 시작한 다음 애플리케이션을 구성하는 구성요소를 배포한다. 와즘클라우드에는 자체 명령줄 관리 툴이 있다. 이 툴을 사용하려면 관리 포드로 트래픽을 전달해야 한다.

여기서도 YAML을 사용해 애플리케이션을 설명해야 한다. 다만 이제는 와즘클라우드의 자체 오케스트레이션 툴을 사용하므로 애플리케이션 구성요소에 대한 해당 툴의 설명을 사용하면 된다. 완료되면 명령줄 툴을 사용해 애플리케이션을 배포하고 실행할 수 있다. 와즘클라우드는 애플리케이션을 빌드하고 실행하기 위한 구성요소 모델을 지원하도록 설계됐으며, 그 목적은 코스모닉(Cosmonic)의 지원을 통해 WASI 구성요소를 설명하고 호출하는 표준 방법을 제공하는 데 있다.

철학적 차이

마이크로소프트 WASI 노드 풀에 대한 2가지 대안을 고려하면 AKS의 웹어셈블리에는 여전히 미래가 있다. 그런데 WASI를 다루고 실행하는 데 있어 완전히 다른 2가지 방식이 존재하는 이유는 무엇일까?

와즘클라우드와 스핀큐브의 기본 철학은 매우 다르다. 와즘클라우드는 본격적인 WASI 기반 애플리케이션을 호스팅하고 마이크로서비스 구성요소를 조합 및 조율하도록 설계됐고, 스핀큐브는 AWS 람다 또는 애저 펑션과 같은 서비스의 대안으로 WASI 기반 함수를 신속하게 출시하고 매우 짧은 시간 내에 확장하는 데 중점을 둔다. AKS에서 두 가지 모두 지원하므로 필요에 맞는 WASI 플랫폼을 선택할 수 있다.

웹어셈블리가 무엇을 할 수 있는지 여전히 탐색하는 중임을 감안하면 AKS에서 한 가지 작업 방법에 묶이지 않는다는 점은 다행이다. 다양한 선택 옵션은 분산 애플리케이션을 구축하고 관리하는 방법이라는 면에서 쿠버네티스의 대표적인 특징이다. 서버리스 함수든 대규모 엔터프라이즈 서비스든, 어떤 언어로 작성되고 어느 containerd 호환 환경에 호스팅되든 관계없이 PC 및 서버와 마찬가지로 애플리케이션을 위한 유연하고 강력한 플랫폼이다.
dl-itworldkorea@foundryco.com