애저 최고기술책임자 마크 러시노비치는 이그나이트 2025에서 ‘애저 혁신’ 발표 두 번째 파트를 통해, 개발자가 클라우드 네이티브 애플리케이션을 구축하는 데 활용하게 될 핵심 소프트웨어 플랫폼을 집중 조명했다.
애저는 애플리케이션을 위한 배관 역할을 제공하는 플랫폼 서비스 환경으로 출발해, 인프라를 고민하지 않아도 되도록 모든 요소를 자동화하고 API로 감추며 웹 포털을 통해 설정할 수 있게 했다. 시간이 흐르면서 애저는 가상 인프라와 명령줄 환경을 지원하게 됐고, 애플리케이션 관리뿐 아니라 자체적인 인프라 코드형 개발 도구와 언어도 제공하게 됐다.
이런 변화에도 불구하고 서버리스 애저라는 비전은 온디맨드 컴퓨트 플랫폼인 함수부터 패브릭의 대규모 데이터 환경, 마이크로서비스인 애저 컨테이너 인스턴스를 지탱하는 호스팅 확장형 오케스트레이션 플랫폼에 이르기까지 수많은 혁신의 핵심 동력으로 작용해 왔다. 이 비전은 러시노비치가 소개한 새로운 도구와 서비스 상당수의 기반이 되며, 개발자가 코드에 집중할 수 있는 플랫폼을 제공하는 데 초점을 맞추고 있다.
이 접근 방식이 애저를 위한 새로운 하드웨어와 인프라 기능 개발을 멈추게 하지는 않는다. 이런 요소는 여전히 많은 워크로드에 필수적이며, 새로운 클라우드 네이티브 모델을 지원하는 핵심 기반이다. 코드 위에서 사용하는 추상화 계층 아래에 무엇이 있는지를 이해하는 일은, 코드로 구현할 수 있는 한계를 규정한다는 점에서 중요하다.
대규모 서버리스 컨테이너
애저의 핵심 서버리스 기술 가운데 하나는 애저 컨테이너 인스턴스다. 애저 컨테이너 인스턴스는 쿠버네티스 환경을 직접 관리하고 운영하지 않아도 쿠버네티스의 장점을 상당 부분 활용할 수 있는 방식으로 이해할 수 있다. 컨테이너를 대신 호스팅하고 관리하며, 확장과 컨테이너 생명주기를 처리한다. 인프라 발표에서 러시노비치는 새로운 직접 가상화 도구를 통해 애저 컨테이너 인스턴스에서 실행되는 컨테이너가 그래픽 처리 장치 같은 애저 하드웨어에 접근할 수 있게 됐다고 설명했다.
마이크로소프트는 애저 컨테이너 인스턴스에 큰 비중을 두고 있으며, 애저와 마이크로소프트 365 전반의 주요 서비스 구성 요소 다수를 이 플랫폼 위에서 운영하고 있다. 여기에는 엑셀의 파이썬 지원, 코파일럿 액션 에이전트, 애저 배포 및 자동화 서비스가 포함되며, 더 많은 서비스가 개발 중이거나 이전을 진행하고 있다. 러시노비치는 애저 컨테이너 인스턴스를 “마이크로소프트 내부 인프라의 공식 계획”이라고 표현했다.
애저 컨테이너 인스턴스 개발은 인프라 계층에만 국한되지 않는다. 컨테이너를 관리하는 오케스트레이션 서비스에서도 변화가 이어지고 있다. 대표적인 신규 기능은 엔그룹스로, 표준 컨테이너 이미지 기반의 플릿을 정의해 필요에 따라 확장하거나 순간적으로 규모를 늘릴 수 있도록 한다. 이 모델은 수초 내 배포가 가능한 신속 확장 대기 풀을 지원하며, 필요한 경우 맞춤 설정을 적용할 수 있다.
애저 컨테이너 인스턴스는 멀티테넌트 운영을 지원해야 하므로, 컨테이너 간 공정한 관리형 자원 공유가 요구된다. 그렇지 않으면 악의적인 컨테이너가 서버 자원을 빠르게 독점할 수 있다. 동시에 하나의 구독 내 컨테이너들이 필요에 따라 자원을 공유할 수 있어야 하는데, 러시노비치는 이 모델을 ‘자원 초과 할당’이라고 설명했다.
이 개념은 애저에 추가되고 있는 직접 가상화 기능을 기반으로 한 새로운 기능인 확장형 인스턴스와도 연결된다. 확장형 인스턴스에서는 중앙 처리 장치와 메모리의 최소·최대 값을 정의하고 부하 변화에 따라 조정할 수 있다. 기존에는 컨테이너가 주로 수평 확장을 통해 규모를 늘렸다면, 확장형 인스턴스는 서버의 가용 여유 범위 내에서 수직 확장과 축소도 가능하게 한다.
관리형 실리움을 통한 컨테이너 네트워킹 개선
과거에도 언급된 바 있는 컨테이너 네트워킹 영역에서는 확장 버클리 패킷 필터 지원 강화와 함께, 실리움(Cilium) 네트워크 가시성 및 보안 도구에 대한 애저 지원이 개선되고 있다. 확장 버클리 패킷 필터는 리눅스와 윈도우 모두에서 커널 내부에 안전하게 프로브와 규칙을 적용할 수 있게 해 주며, 운영에 영향을 주지 않는다. 쿠버네티스 환경에서 네트워킹을 관리하는 강력한 방식으로, 실리움은 쿠버네티스 보안 스택의 중요한 구성 요소로 자리 잡았다.
지금까지 애저는 깊은 수준의 확장 버클리 패킷 필터 지원을 제공했지만, 관련 도구를 직접 가져와 관리해야 했고 대규모 운영에는 전문성이 요구됐다. 모든 사용자가 쿠버네티스 플랫폼 엔지니어는 아니며, 애저 쿠버네티스 서비스처럼 클라우드 네이티브 애플리케이션을 위한 관리형 환경이 확산되는 상황에서 관리형 확장 버클리 패킷 필터 환경은 중요한 업그레이드다. 새로운 애저 관리형 실리움 도구는 호스트 라우팅에 이를 활용할 수 있는 간편한 방식을 제공하며, 아이피테이블 기반 네트워킹에서 발생하던 오버헤드를 크게 줄인다.
가장 큰 개선 효과는 작은 메시지 크기의 파드 간 라우팅에서 나타난다. 메시지가 작을수록 아이피테이블을 사용할 때 라우팅 오버헤드가 커진다는 점을 고려하면 자연스러운 결과다. 작은 메시지가 3배 빠르게 전달되는 환경에서는 이런 성능 향상을 활용하도록 애플리케이션 메시징 설계를 최적화할 필요가 있다.
실리움이 애저 쿠버네티스 서비스와 통합되면서, 파드 호스트에서 컨테이너 네트워킹을 관리하는 기본 방식이 됐다. 이는 자체 설치 방식 대비 38% 빠른 성능을 제공하며, 기존 고급 컨테이너 네트워킹 서비스 도구 체계와 함께 작동한다. 여기에 더해 마이크로소프트는 실리움 인스턴스를 최신 상태로 유지하고, 자체 구축 환경에서는 받을 수 없는 지원을 제공한다.
사용자가 애저 하드웨어와 직접 상호작용할 가능성은 낮지만, 러시노비치가 언급한 플랫폼 혁신 다수는 이전 이그나이트 세션에서 설명된 인프라 변화에 기반한다. 특히 애저 부스트의 네트워크 가속기 같은 요소가 핵심이다.
이런 변화는 로컬 엔브이엠이 저장소와 애저 스토리지 서비스를 사용하는 원격 스토리지를 모두 지원하는 애저 컨테이너 스토리지 업그레이드로 이어지고 있다. 여기에는 분산 캐시가 포함되며, 쿠버네티스 클러스터가 매번 모든 파드로 데이터를 내려받는 대신 로컬 스토리지를 활용해 데이터를 공유할 수 있도록 한다. 추론 처리를 위해 새로운 파드와 노드를 빠르게 생성하는 애플리케이션에서 점점 문제가 되고 있던 부분이다. 이 캐시를 사용하면 수분이 걸리던 다운로드가 수초 만의 로컬 파일 접근으로 대체된다.
운영체제 수준의 컨테이너 보안
애저를 비롯한 하이퍼스케일러는 사용자에게 전용 서버를 제공하는 사업 모델을 취하지 않는다. 가상 머신과 다수의 테넌트를 활용해 하드웨어 활용도를 극대화하는 구조다. 이 접근 방식은 이미지 강화와 격리를 통한 가상 인프라 분리를 포함해, 보안에 대한 깊은 집중을 요구한다. 서버리스 컨테이너 환경, 특히 새로운 직접 가상화 기능이 적용된 상황에서는 애저 컨테이너 인스턴스 기반 컨테이너가 동일한 호스트 운영체제를 공유하므로 가상 머신보다 더 강력한 잠금이 필요하다.
애저는 선언적 정책을 통해 컨테이너 기능을 제한하고, 손상된 컨테이너 이미지가 다른 사용자에게 영향을 미칠 위험을 줄이고 있다. 동시에 애저 컨테이너 인스턴스에서 사용하는 리눅스 기반 호스트 운영체제 보안도 강화하고 있다. 셀리눅스(SELinux)는 호스트 이미지를 잠가 변경 불가능한 운영체제로 만드는 데 활용된다. 다만 셀리눅스 정책은 컨테이너 경계를 넘지 못해, 컨테이너 사용자 공간은 여전히 취약할 수 있다.
마이크로소프트는 컨테이너에서 실행되는 코드를 검증할 수 있도록 리눅스에 새로운 기능을 추가해 왔다. 무결성 정책 적용이라는 새로운 기능은 운영체제 가드의 일부로 제공되며, 또 다른 신규 기능인 디엠 버리티도 포함된다. 디바이스 매퍼 버리티(Device-mapper-verity)는 레지스트리에 저장된 컨테이너와 이를 구성하는 레이어 전체에 대해 분산 해시를 제공하는 방식이다. 운영체제 이미지부터 바이너리까지 모든 구성 요소에 서명할 수 있으며, 운영체제 가드를 사용해 서명되지 않거나 신뢰되지 않은 컨테이너 실행을 차단할 수 있다.
안전한 핫 패치
정책 기반 보안 접근 방식은 문제를 신속하게 완화하는 데 유리하다. 예를 들어 공통 컨테이너 레이어에 취약점이 발견되면, 패치 레이어를 생성해 검증한 뒤 빠르게 배포할 수 있다. 컨테이너 전체를 패치할 필요 없이 관련 구성 요소만 수정하면 된다. 마이크로소프트는 내부 프로젝트 코파세틱을 통해 운영체제 기능에 이런 방식을 적용해 왔으며, 파이썬 같은 도구의 최신 패키지를 포함한 패치를 생성해 공통 런타임과 라이브러리까지 확장하고 있다.
이 접근 방식은 오픈소스로 제공되며, 마이크로소프트는 디엠 버리티를 리눅스 커널에 업스트림으로 반영하기 위해 작업 중이다. 새로운 변경 불가능 이미지 빌드 사이에 컨테이너에 핫픽스를 배포하는 수단으로 볼 수 있으며, 문제가 있는 코드를 신속히 교체해 애플리케이션을 계속 운영하면서 다음 릴리스를 빌드·테스트·검증할 수 있다. 러시노비치는 이를 “수일이 아닌 수시간 내 핫픽스 배포”라고 설명했다.
애플리케이션 전달 보안을 위한 도구 제공은 컨테이너를 애저 애플리케이션의 표준 패키지로 정의하려는 마이크로소프트 전략의 일부에 불과하다. 컨테이너 플릿을 더 효과적으로 확장하는 기능과 네트워킹 개선 역시 핵심 요구 사항이다. 러시노비치가 컨테이너에 집중하는 이유는, 컨테이너가 서비스에 필요한 모든 구성 요소를 감싸 안전하게 대규모로 실행할 수 있기 때문이다.
애저 인프라 개선을 기반으로 한 새로운 소프트웨어 서비스가 등장하면서, 애저 플랫폼의 양측이 함께 움직여 큰 그림을 완성하고 있음이 분명해지고 있다. 개발자는 코드를 작성하고 패키징한 뒤, 일부 기본적인 정책 기반 설정을 제외하면 나머지 작업을 애저에 맡기는 구조다. 이런 환경이 단기간에 완성되지는 않겠지만, 이미 현실로 다가오고 있는 만큼 기업이 활용을 준비해야 할 단계에 접어들고 있다.
dl-itworldkorea@foundryco.com
Simon Bisson editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.