GN⁺: WASM은 컨테이너를 대체하게 될 것
(creston.blog)"WebAssembly는 진정한 Write-Once-Run-Anywhere임"
"2030년이 되면 아무도 쿠버네티스를 기억하지 못하게 될것"
이동성 (Portability)
- 컨테이너는 소프트웨어 개발의 많은 문제를 해결했으며, VM보다 사용성이 뛰어났음
- 하지만 현재 컨테이너는 복잡한 도구와 프로그램-컨테이너-Linux의 강한 결합으로 인해 다루기 번거로워짐
- 개발자는 코드 작성과 기능 배포에 집중하고 싶어 하며, Docker 학습은 방해 요소가 됨
- WebAssembly(WASM)는 이미 일부 영역에서 컨테이너를 대체하고 있으며, "한 번 작성하면 어디서나 실행 가능"한 경험을 제공함
- 여러 언어를 WASM으로 컴파일할 수 있으며, 시스템 인터페이스 부족이 널리 채택되는 것을 막고 있지만, 이는 곧 해결될 것
- 현재 WASM의 주요 한계는 파일 접근, 네트워킹 등의 시스템 인터페이스 부족이지만, 이는 시간이 지나면 해결될 문제임
JVM과의 비교
- WASM이 JVM과 비슷한 "한 번 작성하면 어디서나 실행" 개념을 제공하지만, JVM은 웹 브라우저에서 실행되지 않음
- 웹 브라우저는 중요한 애플리케이션 배포 대상이며, 이로 인해 많은 개발자가 JVM을 피하게 됨
- 최근에는 GraalVM, Kotlin Native, Scala Native 등의 정적 바이너리 컴파일러가 JVM의 대안으로 떠오르는 추세임
마이크로서비스 (Microservices)
- 마이크로서비스 아키텍처에서는 HTTP, RPC 또는 메시지 브로커를 사용하여 서비스를 연결함
- 네트워크 통신의 비용과 신뢰성 문제는 주요 단점이지만, 대부분의 기업은 장점이 더 크다고 판단함
- AWS Lambda와 같은 서버리스 플랫폼이 등장하면서, 마이크로서비스는 개별 함수 단위로 배포할 수 있게 됨
- Cloudflare Workers는 V8 샌드박스 내에서 실행되며, 네트워크 요청 없이 동일한 런타임에서 함수 호출이 가능함
- 이는 마이크로서비스의 개발 장점과 모놀리식 아키텍처의 런타임 성능을 동시에 제공함
- Wasmer 등 다른 업체들도 WASM 기반 솔루션을 개발 중임
WASM의 도입 (Adoption)
- WASM은 아직 초기 기술이지만 빠르게 발전하고 있으며, 지원도 증가하는 추세임
- 현재 모든 환경에서 완벽하게 작동하지는 않지만, Cloudflare와 같은 플랫폼을 통해 미래를 미리 경험할 수 있음
- Python, Ruby, PHP와 같은 동적 언어 사용자라면 WASM의 발전을 기다리면서 Go나 Rust 같은 컴파일 언어를 추가로 학습하는 것이 유리함
결국 wasm 런타임 성능에 얹혀가는 모양새가 되는데 V8이 JVM과 동일한 계층이 되지 않을까요.
V8 버전에 따라서 WASM 동작이 달리지고 그걸 디버깅하는 미래가 기다리는게 아닐까 걱정됩니다.
여기에 구현 사례 모음이 있는데.
(개인적으로는) 주로 캐드나 이미지처리 같은 분야가 제일 그럴듯 해 보입니다.
예전에 웹에서 고해상도 의료 이미지 구현에 대해 고민을 하던 솔루션 개발팀이 막 생각나고 그렇습니다.
결국 docker도 wasm도 알아야하게 되는 것인가요 ㅎㅎ 그래두 docker도 기술이 무르익으면서 접근이 쉬워졌으니 wasm도 비슷하게 접근이 쉬워지는 방향으로 가지 않을까 싶어요
Hacker News 의견
- 시스템 인터페이스 부족이 더 넓은 채택을 막고 있는 주요 요인임. 파일 접근, 네트워킹 등이 시간이 지나면 통합될 것임
- 그러나 파일 접근, 네트워킹 등을 추가하면 보안 취약점이 생길 수 있음. 이는 Java의 '한 번 작성, 어디서나 실행' 약속을 무너뜨린 요인임
- WASM은 컨테이너와 다른 문제를 해결함. WASM은 샌드박스 코드 실행에 효율적임
- WASM은 Functions-as-a-Service 구현 등에서 표준이 될 가능성이 높음
- 컨테이너는 그 문제를 해결하지 못함. 보안 경계로서 적합하지 않으며, WASM 바이너리보다 무겁고 시작 비용이 큼
- 컨테이너는 여러 프로세스, 스레드를 실행하고 OS 기본 기능을 사용하는 데 적합함
- WebAssembly는 진정한 '한 번 작성, 어디서나 실행' 경험을 제공함
- 그러나 외부와 상호작용하면 이야기가 달라짐. 각 V8 런타임은 미묘하게 다른 인터페이스를 가짐
- Docker의 성공은 POSIX가 이미 확립된 표준이었기 때문임
- PlatformOps(이전의 DevOps, SRE, Ops)는 복잡한 도구와 프로그램-컨테이너-리눅스의 긴밀한 결합으로 인해 약속이 훼손됨
- 개발자는 코드 작성과 기능 배포를 원함
- PlatformOps는 문제를 해결하기 위해 고군분투함
- WASM은 컨테이너를 대체하는 솔루션이 아님. 컨테이너는 PHP의 다른 버전을 충돌 없이 실행하는 문제를 해결함
- WASM은 그 문제를 해결하지 못함
- WASM의 미래는 언제 올 것인가? 8년이 지났지만 안정적이고 사용하기 쉬운 도구 체인이 없음
- Rust는 2012년에 출시되어 8년 후 안정적이었음
- WASM은 실제 하드웨어에서 실행되지 않음. 가상 머신으로 간주될 수 있음
- 컨테이너는 실제 하드웨어에서 직접 실행되는 애플리케이션을 패키징함
- WASM은 런타임이 필요함. 애플리케이션 내에서 실행됨
- WASM은 JVM과 .NET이 해결하는 '이식성' 문제를 해결함
- 컨테이너는 애플리케이션과 종속성을 번들로 묶음
- 기술은 상호 보완적일 수 있음
- Docker 사용법을 배우는 것은 방해 요소가 아님
- Dockerfile만 있으면 됨
- WASM 앱은 여전히 Kubernetes가 필요함
- WebAssembly는 앞으로 5년간 크게 성장하지 않을 것임
- WASM은 또 다른 추상화 계층임. 모든 것을 대체할지는 다른 솔루션과의 절충에 달려 있음