마이크로소프트가 6월 25일 KB5039302 업데이트 배포를 중단했다. 이 업데이트에는 몇 가지 흥미로운 내용이 포함되어 있지만, 윈도우 11 PC가 연속적으로 다시 시작될 수 있는 것으로 밝혀졌다.
특히 윈도우 11 버전 23H2와 윈도우 11 버전 22H2가 이 버그의 영향을 받는다. 윈도우 서버는 영향을 받지 않는다.
마이크로소프트는 다음과 같이 설명했다. 2024년 6월 26일에 릴리즈된 업데이트(KB5039302)를 설치한 후 일부 디바이스가 다시 시작되지 않을 수 있다. 영향을받는 시스템은 반복적으로 다시 시작될 수 있으며 정상적인 사용을 복원하려면 복구 작업이 필요할 수 있다.
이 문제는 가상 머신 도구 및 가상화 중첩 기능(예: 클라우드PC, 데브박스(DevBox), 애저 가상 데스크톱)을 사용하는 디바이스에 영향을 미칠 가능성이 높다. 이 문제가 발생할 수 있는 정확한 조건을 파악하기 위해 조사 중이다. 개인 환경에서는 가상화가 덜 널리 사용되기 때문에 윈도우 홈 에디션 사용자는 이 문제를 경험할 가능성이 적다.
조사가 진행 중인 동안 이 업데이트는 윈도우 업데이트 및 비즈니스용 윈도우 업데이트 형태로 배포되지 않는다. 따라서 현재 디바이스에 이 업데이트가 제공되지 않을 수도 있다.
마이크로소프트는 이 문제에 대한 해결 방법을 연구 중이며 향후 업데이트에 포함할 예정이다.
다시 시작이 멈춘 경우 수행 방법 컴퓨터에 업데이트를 설치했는데 끝없는 재부팅이 계속되는 경우 윈도우 11이 자체적으로 윈도우 11 복구 환경을 시작할 때까지 기다려야 한다.
복구 환경이 시작되면 문제 해결, 고급 옵션, 업데이트 제거를 차례로 선택한 다음 마지막으로 최신 품질 업데이트 제거를 클릭한다. 그런 다음 업데이트 제거를 확인해 보자. editor@itworld.co.kr
2013년 도커가 등장한 시점에서 보면 리눅스 컨테이너가 마치 하룻밤 사이에 성공한 것처럼 느껴질 수 있다. 하지만 사실 컨테이너, 마이크로서비스와 쿠버네티스의 진화는 리눅스 운영체제의 커널 프리미티브를 기반으로 수십년에 걸쳐 이뤄졌다.
도커는 가볍고 사용하기 쉬운 소프트웨어 패키징 형식을 만들기 위해 이러한 프리미티브, 즉 cgroup과 네임스페이스를 빌딩 블록으로 사용했다. 리눅스 컨테이너는 오래전부터 구글을 비롯한 여러 기업에 사용됐는데 단지 도커가 등장하면서 주류 개발자가 컨테이너에 쉽게 액세스할 수 있게 된 것이다.
ⓒ Getty Images Bank
지금의 eBPF는 그렇게 해서 리눅스 커널 프리미티브에서 탄생한 또 다른 기술이다. 현재 모든 주요 네트워킹, 관찰가능성 및 보안 벤더는 “eBPF 기반” 제품을 제공한다고 주장한다. 실리움(Cilium), 테트라곤(Tetragon), 팔코(Falco)와 같은 eBPF 툴이 엔터프라이즈 아키텍처와 클라우드 서비스 제공업체 제품에서 모두 자리를 잡고 있다. 또한 eBPF를 만든 장본인 한 명에 따르면 지금은 eBPF 기반 혁신의 시작에 불과하다.
Infoworld는 eBPF의 공동 창시자이며 현재 리눅스 커널의 eBPF 공동 유지관리자인 대니얼 보크만에게서 이 기술의 기원, eBPF가 리눅스 커널 프로그래밍과 커스터마이징을 위한 표준 접근 방법으로 부상한 이유, 그리고 이것이 리눅스와 플랫폼 엔지니어링의 미래 측면에서 의미하는 바에 대한 이야기를 들어봤다.
솔라리스 학생에서 리눅스 커널 유지관리자로
eBPF를 향한 대니얼 보크만의 여정은 솔라리스의 내부를 이해하기 위한 탐구에서 시작됐다. 당시 솔라리스는 보크만이 다니던 대학의 컴퓨터과학 교육과정에서 아직 가르치던 과목이었다. 그러나 정작 원리를 살펴보기 위한 소스 코드의 부재는 이해를 가로막는 큰 장벽이었다. 보크만은 운영체제 수업의 이론에도 흥미를 느꼈지만 늦은 밤까지 리눅스 커널 소스 코드, 깃 로그, 메일링 리스트를 공부하는 데 열중하면서 본격적인 관심을 갖게 됐고, 커널과 접하는 저수준 사용자 애플리케이션을 만들기 시작했다.
곧 보크만은 패킷 필터, tcpdump와 libpcap, 그리고 패킷이 다양한 계층을 오갈 때 네트워크 스택이 어떻게 작동하는지를 탐구했다. 보크만은 여가 시간에 더 효율적인 tcpdump 클론을 만들어서 리눅스 네트워킹 스택에 작은 코드 개선을 보내기 시작했다. 석사 과정을 시작할 시점에 독일 라이프치히 지역의 스타트업에서 리눅스 커널 코드 개발 업무를 담당하는 첫 직장을 구했다.
보크만은 2010년에 인터페이스당 여러 rx_hook를 실행할 수 있도록 netpoll을 확장하는 첫 번째 패치를 리눅스 커널에 제출했는데, 스스로의 표현에 따르면 “완전한 초보” 시절이라 커널에 교착 상태를 유발하는 버그를 일으켰다. 다행히 다른 기여자가 신속하게 이를 발견해 수정했다. 그러나 보크만은 이 일에 매료됐다. 그에게 리눅스 커널 개발은 천직이라고 할 만큼 매력적인 환경이었다.
보크만은 커널을 위한 조합 가능한(composable) 네트워킹 스택 개발을 주제로 한 석사 논문을 완성하기 위해 취리히로 거처를 옮겼다. 프리BSD의 netgraph에서 영감을 받아 네트워킹 블록을 FPGA로 오프로드하고 패킷 처리를 위한 조합 가능한 그래프를 구축하는 방법을 실험했다. 그러나 이 과정에서 보크만은 학술 논문이 너무 단조로우며 장기적이고 실질적인 영향은 미미하다는 사실을 깨닫고 리눅스 커널에 풀타임으로 기여하는 것이 훨씬 더 보람 있는 일이라는 생각을 갖게 됐다. 보크만은 스위스 도메인(.ch) 이메일을 사용하는 토마스 그라프라는 리눅스 기여자를 알게 되어 자연스럽게 연락했고, 초대를 받아 레드햇의 리눅스 커널 네트워킹 팀에 합류했다(두 사람 모두 이후 실리움의 공동 제작자가 됨).
현재 보크만은 전 세계 상위 1%의 리눅스 커널 기여자다.
리눅스 OS의 네트워킹에 대한 재고
eBPF의 기원은 2011년까지 거슬러 올라간다. 당시는 소프트웨어 정의 네트워킹(SDN)이 부상하고 리눅스 도입이 급증하던 시기였다. 리눅스 서브시스템은 하나의 서버와 호스트 운영체제가 아니라 리눅스 머신 클러스터에서 실행되는 마이크로서비스 아키텍처와 분산 애플리케이션의 새로운 패러다임에 보조를 맞춰야 했다.
보크만이 속한 네트워킹 스택의 커널 개발은 SDN과 클라우드 네이티브 네트워킹 요구사항을 충족하기 위한 작업이 이뤄지는 최전선이었다. cgroup(CPU, 메모리 처리), 네임스페이스(net, mount, pid), SELinux, seccomp, Netfilter, Netlink, AppArmor, Auditd, Perf 등 리눅스 빌딩 블록의 상당수가 10년 이상 전에 설계된 만큼 리눅스에는 새로운 추상화가 필요했다. 또한 보크만은 당시 가장 진보적인 SDN 프로젝트였던 오픈 vSwitch(OVS)뿐만 아니라 netfilter의 nftables와 같은 기술이 “차세대” 리눅스 네트워킹으로 추진되는 모습을 보면서 더 나은 방법이 있다고 생각했다.
리눅스 커널은 더 높은 네트워킹 속도에 보조를 맞추기 위해 확장되고 있었지만 새로운 맞춤형 기능을 프로그래밍하기 위한 유연성이 부족했다. 또 다른 제약은 “사용자 공간을 망가뜨리면 안 된다”는 요건이었다. 즉, 리눅스 커널은 클라우드 네이티브 애플리케이션이 등장하기 훨씬 전에 개발된 모든 소프트웨어를 계속해서 지원해야 했다. 아쉽게도 이 “레거시의 무거운 짐”으로 인해 네트워킹 혁신의 일부가 커널에서 사용자 공간으로 이동했다.
간단히 말해 새로운 클라우드 운영 모델은 훨씬 더 많은 자동화, 기능의 이동, 확장, 그리고 더 까다로운 네트워크 성능 요구사항을 불러왔다. 그러나 리눅스 커널의 독립적인 서브시스템에는 커널에서 이 모든 새로운 클라우드 컨텍스트를 푸시하고 집계하고 관련하여 조치를 취하기 위한 규칙이 없었다.
리눅스 프로그래밍에서 패킷 처리(구문 분석, 조작, 필터링, 포워딩)는 “가능한 것”에 대한 가장 기본적인 관심사다. 이는 네트워크 패킷이 스택을 따라 이동할 때 커널 개발자가 이 패킷을 라우팅, 제어, 검사하기 위한 메커니즘이다. 커널의 네트워킹 스택에서 패킷 처리의 역할은 엔진에서 기화기, 들로리안 타임머신에서 플럭스 커패시터의 역할과 같다.
애플리케이션 개발자는 대부분 사용자 공간에서 애플리케이션을 작성하면서 커널에 필요한 시스템 호출로부터 애플리케이션을 보호하는 추상화를 사용한다. 따라서 애플리케이션은 하드웨어와 인터페이스해야 하는 경우, 즉 화면에 쓰거나 파일에 쓰거나 네트워크 패킷을 보내야 하는 경우 커널의 도움이 필요하다. 커널은 사용자 공간 애플리케이션과 하드웨어 사이에 일반적인 공통 인터페이스를 제공하며, 동시에 실행되는 여러 사용자 공간 프로세스를 조율한다.
가상화에서 컨테이너로 진화하면서 iptables, nftables, OVS, 리눅스 트래픽 제어(TC)를 비롯해 패킷 필터링을 위한 많은 접근법이 리눅스 커널 내에서의 자리를 두고 경쟁했다. 이 경쟁에서 네이티브 성능으로 프로그램을 실행하면서 표현력과 검증자에 의한 안전까지 결합된 eBPF가 부상했다. 즉, eBPF는 사용자가 다른 대안으로는 불가능한 방식으로, 커널 손상에 대한 위험 없이 커널을 프로그램할 수 있게 해준다.
더 ‘프로그래머블’한 리눅스 커널
보크만이 처음 eBPF에 끌린 이유는 eBPF가 네트워킹에 가져올 수 있는 유연함과 성능이었지만 이 새로운 기술의 이점은 네트워킹을 훨씬 더 뛰어넘어 확장이 가능하다는 사실이 드러났다.
보크만은 “eBPF는 빌드하고 즉시 배포할 수 있는 기본 기능을 통해 큰 문제를 해결했다. eBPF가 내장된 오케스트레이션 프로그램을 만들어서 기반 커널 버전에 관계없이 배포할 수 있다. 또한 코어 커널 ABI 안정성을 위해 대형 벤더에 막대한 비용을 지불하는 대신 이제 eBPF를 사용하면 된다. 다양한 사용 사례에 따라 커널을 확장하기 위한 모듈이 필요 없다”고 말했다.
eBPF는 사용자가 리눅스 커널 내에 맞춤형 프로그램을 로드해서 안전하게 실행할 수 있게 해주는 범용 어셈블리 언어, 즉 런타임에 운영체제에 온갖 종류의 기능을 추가할 수 있는 방법이 됐다. 엄격한 형식이 지정되고 안정적인 명령어 집합을 갖고 있으며 확장 기능은 하위 호환된다.
보크만은 “eBPF는 일반적인 모놀리식 커널과 마이크로커널 사이의 간극을 잇는 새로운 유형의 소프트웨어라고 생각하면 된다. 신뢰할 수 있는 사용자 공간에서 안전하게 커널을 확장한다. eBPF의 좋은 점은 일반 커널 코드만큼 빠르다는 것이다. eBPF는 샌드박스가 아니며 검증자는 이 프로그램을 완전히 파악해서 신뢰할 수 있는 환경에서 실행하기에 안전한지 여부를 판단한 다음 네이티브 코드로 JIT 컴파일할 수 있다”고 말했다.
eBPF는 안전하고 빠를 뿐만 아니라 네이티브 속도로 작동한다. 매우 유연해서 다양한 사용자가 다양한 방식으로 사용할 수 있다. 보크만은 “eBPF의 강점은 사용 사례가 있거나 특정 방식으로 무언가를 처리해야 할 때만 사용자 관점에서 코드를 활성화할 수 있다는 것이다. 다른 부분에 불이익을 주지 않는다. 커널에 하드코딩되어 핵심 경로를 점점 더 느리게 하고 결국 성능을 죽이는 것과는 다르다”고 설명했다.
실리움의 그라프는 “eBPF가 나오기 전에는 대부분의 사용자가 엔터프라이즈 리눅스 배포판을 사용하거나 자신의 디바이스에 설치된 커널 버전을 그냥 실행했다. eBPF는 이를 근본적으로 바꿔 놓았다. 런타임이 존재하므로 어떤 아이디어든 몇 년이 아니라 며칠만에 eBPF 프로그램으로 바꿔서 런타임에 로드할 수 있다. 우리는 무엇을 먼저 다시 구축할지를 결정해야 했다”고 말했다.
보편화된 커널 엔지니어링
구글 보그(Borg)를 비롯해 하이퍼스케일러에서 탄생한 다른 기술과 마찬가지로 eBPF도 처음에는 커널 개발 기술을 갖춘 소수의 소프트웨어 엔지니어링 업체에서만 사용됐다. 커널 엔지니어링과 eBPF 프로그램 작성을 위해 필요한 저수준 C 프로그래밍 기술을 갖춘 개발자는 많지 않았다.
그러나 현재 이 소수의 전문가들이 수백만 명의 사용자들과 접하는 프로그램을 만들고 있다. eBPF 기반 프로그램은 네트워킹, 보안, 관찰가능성을 담당하는 플랫폼 엔지니어링 팀 관점에서 가장 흥미로운 분야이며, 이러한 프로그램을 사용하는 많은 사람들은 그것을 가능하게 해주는 기반 eBPF 추상화에 대해 아무것도 알 필요가 없다. 보크만은 eBPF에 대한 최근 워크숍 기조 연설에서 “클라우드 네이티브로부터의 조용한 플랫폼 혁명이라고 생각하면 된다”고 말했다.
방대한 eBPF 환경의 많은 애플리케이션을 잠깐 살펴보면 다음과 같다.
실리움은 컨테이너 워크로드 사이에 3계층 및 4계층 연결을 제공하기 위한 컨테이너 네트워크 인터페이스(CNI)의 eBPF 기반 구현으로 시작됐지만, 이후 발전하면서 대부분의 클라우드 서비스 제공업체의 쿠버네티스를 위한 기준 네트워크 계층이 됐다. 실리움은 쿠버네티스 팟 사이, 그리고 외부 서비스로 가는 트래픽에 대한 분산 로드 밸런싱을 구현하며, 거의 무제한의 규모에서 eBPF의 효율적인 해시 테이블을 사용해서 kube-proxy를 완전히 대체할 수 있다. 또한 3계층부터 7계층까지의 정책 시행, 통합 인그레스 및 이그레스 게이트웨이, 대역폭 관리, 엔보이(Envoy)와 결합된 서비스 메시, 심층 네트워크 가시성과 같은 고급 기능도 지원한다.
테트라곤 역시 eBPF 프로그램으로, 보안 관찰가능성과 런타임 실행 기능을 제공한다. 테트라곤은 eBPF의 낮은 오버헤드를 활용해서 플랫폼 팀이 네트워크 흐름과 기타 커널 내 이벤트를 매우 구체적인 프로세스 및 관련 프로세스 트리에 이르기까지 쿠버네티스 객체(레이블, 팟, 네임스페이스)에 연결할 수 있게 해준다. XZ 유틸즈(XZ Utils)와 같은 소프트웨어 공급망 보안 익스플로잇이 등장한 이후 테트라곤은 플랫폼 팀에 특정 소프트웨어가 환경의 어느 위치에서 실행되는지 찾고 커널 수준에서 구체적인 정책 조치를 취할 수 있는 더 심층적인 방법을 제공하는 데 목표를 두고 있다.
픽시(Pixie)는 eBPF를 사용해서 “수동 계측 없이 자동으로 텔레메트리 데이터를 캡처”한다. 차세대 애플리케이션 성능 관리 및 모니터링 벤더 사이에서 인기 있는 빌딩 블록으로 부상했다. 구글에서 “observability AND eBPF”를 검색해 보면 eBPF의 성능이 텔레메트리 데이터를 얼마나 풍부하게 변화시키고 있는지 볼 수 있다. 클라우드 네이티브 시스템의 실시간 상태 추론을 위해 지금까지는 상관관계를 파악할 모니터링 데이터를 축적해야 했다. 이 텔레메트리 데이터 컬렉션을 커널 가까이 가져오면 일관성을 대폭 높이고 리소스 사용량을 줄일 수 있다.
카트란(Katran)은 커널 내 패킷 처리를 기반으로 하는 새로운 접근 방식을 통해 독점적인 3계층 및 4계층 로드 밸런서의 위상에 도전할 수 있는 C++ 라이브러리다. 모두가 eBPF 프로그램을 만들 수 있는 것은 아니지만 현재 개발되고 있는 여러 프로그램은 기업 인프라에서 지금까지 비교적 정체된 영역을 대상으로 하며, 클라우드 네이티브 사용 사례를 위한 현대화를 이끌고 있다.
보크만은 “인프라 소프트웨어의 다음 10년은 eBPF를 사용할 수 있는 플랫폼 엔지니어와 eBPF를 활용하여 더 고수준 플랫폼을 위한 적절한 추상화를 만드는 프로젝트에 의해 정의될 것이다. 클라우드 네이티브 컨텍스트의 부재라는 커널 문제를 eBPF가 해결했다”고 말했다.
이달은 쿠버네티스 10주년이지만 그럼에도 여전히 분산 애플리케이션, 컨테이너 오케스트레이션, 플랫폼 엔지니어링은 현재 초창기다. 커널 수준에서 eBPF를 직접 엔지니어링하는 사람은 거의 없지만 수많은 사람들이 eBPF 기반 프로그램을 사용하게 될 것이다. 여러분이 대형 퍼블릭 클라우드 제공업체 플랫폼 중 하나의 쿠버네티스에서 워크로드를 실행 중이라면 이미 eBPF 기반 프로그램을 사용 중일 가능성이 높다. editor@itworld.co.kr
