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 같은 컴파일 언어를 추가로 학습하는 것이 유리함
여기에 구현 사례 모음이 있는데.
(개인적으로는) 주로 캐드나 이미지처리 같은 분야가 제일 그럴듯 해 보입니다.
예전에 웹에서 고해상도 의료 이미지 구현에 대해 고민을 하던 솔루션 개발팀이 막 생각나고 그렇습니다.
결국 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은 또 다른 추상화 계층임. 모든 것을 대체할지는 다른 솔루션과의 절충에 달려 있음