KR20200142043A

KR20200142043A - 소프트웨어 컨테이너 성능 및 격리를 개선하기 위한 방법 및 시스템

Info

Publication number: KR20200142043A
Application number: KR1020207032437A
Authority: KR
Inventors: 지밍 쉔; 레네스 로버트 반; 하킴 웨더스푼
Original assignee: 코넬 유니버시티
Priority date: 2018-04-11
Filing date: 2019-04-11
Publication date: 2020-12-21
Also published as: US20210109775A1; EP3776194A1; CN112236752A; AU2019252434A1; JP2021521530A; WO2019200102A1; AU2019252434B2; CA3096872A1; EP3776194A4

Abstract

일 실시 예에서 방법은 커널 기반 격리 층을 구현하는 단계, 전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하는 단계, 및 상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하는 단계를 포함한다. 상기 방법은 각각 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 클라우드 기반 처리 플랫폼, 엔터프라이즈 처리 플랫폼 또는 다른 유형의 처리 플랫폼에 의해 수행된다. 상기 라이브러리 운영 체제는 실례로 상기 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 권한 수준과 동일한 권한 수준으로 상기 소프트웨어 컨테이너에서 실행된다. 상기 라이브러리 운영 체제는 실례로 시스템 호출들을 대응하는 함수 호출들로 변환하는 것과 관련하여 상기 하나 이상의 사용자 프로세스의 경계들의 자동 변환을 지원하도록 구성된다.

Description

소프트웨어 컨테이너 성능 및 격리를 개선하기 위한 방법 및 시스템

우선권 주장

본 출원은 2018년 4월 11일자로 출원된 "Method and System for Improving Software Container Performance and Isolation(소프트웨어 컨테이너 성능 및 격리를 개선하기 위한 방법 및 시스템)"이라는 명칭의 미국 가 특허 출원 제62/656,051호의 우선권을 주장하며, 이는 여기에 그 전체가 참고로 통합된다.

정부 지원 성명

본 발명은 국립 과학 재단(NSF)에서 부여한 약정 번호 CSR-1422544, CNS-1601879, CSR-1704742, 1053757, 및 0424422; 미국 국립 표준 기술원(NIST)에서 부여한 약정 번호 60NANB15D327 및 70NANB17H181; 및 미국 국방부 고등 연구 계획국(DARPA)에서 부여한 약정 번호 FA8750-10-2-0238, FA8750-11-2-0256 및 D11AP00266에 따라 정부 지원으로 이루어졌다. 정부는 본 발명에 대한 특정 권리들을 갖는다.

기술분야

본 기술분야는 개괄적으로 정보 처리 시스템들, 보다 구체적으로는 그러한 시스템들에 이용되는 소프트웨어 컨테이너들에 관한 것이다.

컨테이너들은 애플리케이션들을 패키징하는 바람직한 방법이 되었고 서버리스 아키텍처들 및 기타 다양한 유형의 처리 플랫폼에서 핵심 구성요소이다. 동시에, 엑소커널 아키텍처는 엑소커널들의 역할을 하는 하이퍼바이저들 및 많은 라이브러리 운영 체제(OS)가 제공되거나 개발 중에 있는 등 주목을 받고 있다. 엑소커널들은 작은 신뢰 컴퓨팅 기반(TCB, Trusted Computing Base) 및 공격 대상 영역(attack surface)으로 인해, 우수한 보안 격리 속성들을 갖는 한편, 라이브러리 OS들은 특정 애플리케이션에 맞게 사용자 지정될 수 있다. 불행하게도, 이러한 두 트렌드는 현재 서로 호환되지 않는다. 현재 라이브러리 OS들은 최신 애플리케이션 컨테이너들을 실행하는 데 필요한 바이너리 호환성 및 여러 프로세스에 대한 지원이 부족하다.

예시적인 실시 예들은 여리서 X-컨테이너들로 지칭되는 개선된 소프트웨어 컨테이너들을 제공한다. 하나 이상의 실시 예의 X-컨테이너 아키텍처에서, X-컨테이너는 실례로 가상 기계 하이퍼바이저 및 호스트 운영 체제 중 하나를 사용하여 구현되는, X-커널 상의 라이브러리 OS로서 전용 리눅스 커널과 실행된다. X-커널은 여기서 보다 일반적으로 "커널 기반 격리 층(kernel-based isolation layer)"으로 지칭되는 것의 일례이다. 결과적인 X-컨테이너 배열들은 실례로 수정되지 않은 다중 처리 애플리케이션을 지원하고 애플리케이션 바이너리 교체를 즉시 자동으로 최적화한다. 이러한 유형의 일부 실시 예에서 X-컨테이너들은 수정되지 않은 리눅스에 비해 시스템 호출 오버헤드를 상당히 감소시키는 동시에, 웹 벤치마크들 상의 유니커널(Unikernel) 및 그래핀(Graphene)과 같은 라이브러리 OS들을 크게 능가한다.

일 실시 예에서, 방법은 커널 기반 격리 층을 구현하는 단계, 전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하는 단계, 및 상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하는 단계를 포함한다. 상기 방법은 각각 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 클라우드 기반 처리 플랫폼, 엔터프라이즈 처리 플랫폼 또는 다른 유형의 처리 플랫폼에 의해 수행된다.

상기 라이브러리 운영 체제는 실례로 상기 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 권한 수준과 동일한 권한 수준으로 상기 소프트웨어 컨테이너에서 실행된다.

일부 실시 예에서, 상기 라이브러리 운영 체제는 실례로 시스템 호출들을 대응하는 함수 호출들로 변환하는 것과 관련하여 상기 하나 이상의 사용자 프로세스의 바이너리들의 자동 변환을 지원하도록 구성된다.

본 발명의 이러한 및 다른 예시적인 실시 예들은 시스템들, 방법들, 장치들, 처리 디바이스들, 집적 회로들, 및 소프트웨어 프로그램 코드가 내장된 프로세서-판독 가능 저장 매체를 포함하는 컴퓨터 프로그램 제품들을 포함하지만, 이에 제한되지는 않는다.

도 1은 예시적인 실시 예에서 X-컨테이너들을 구현하는 클라우드 기반 처리 플랫폼을 포함하는 정보 처리 시스템을 도시한다.
도 2는 예시적인 실시 예에서 X-컨테이너들을 구현하는 엔터프라이즈 처리 플랫폼을 포함하는 정보 처리 시스템을 도시한다.
도 3은 예시적인 실시 예에서 X-컨테이너들의 예시적인 배열을 도시한다.
도 4는 여기에 개시된 바에 따라 X-컨테이너들을 이용하는 아키텍처를 포함하는 다양한 아키텍처의 격리 경계들을 도시한다.
도 5는 예시적인 실시 예들에서 상이한 수의 X-컨테이너를 사용하는 두 애플리케이션의 대안적인 구성들을 도시한다.
도 6은 예시적인 실시 예에서 하나 이상의 X-컨테이너에 구현되는 바이너리 교체의 예들을 도시한다.
도 7은 예시적인 실시 예들의 평가에 이용되는 소프트웨어 스택들의 예들을 도시한다.
도 8 내지 도 12는 예시적인 실시 예들에 관해 수행되는 평가들의 결과들을 도시하는 플롯들이다.

본 발명의 실시 예들은 예를 들어, 컴퓨터 네트워크들 또는 네트워크들, 클라이언트들, 서버들, 처리 디바이스들 및 기타 구성요소들의 다른 배열들을 포함하는 정보 처리 시스템들의 형태로 구현될 수 있다. 그러한 시스템들의 예시적인 실시 예들이 여기서 상세하게 설명될 것이다. 그러나, 본 발명의 실시 예들은 광범위한 기타 유형의 정보 처리 시스템들 및 관련 네트워크들, 클라이언트들, 서버들, 처리 디바이스들 또는 기타 구성요소들에 보다 일반적으로 적용 가능하다는 것을 이해해야 한다. 따라서, 용어 "정보 처리 시스템"은 여기서 사용될 때 이러한 그리고 다른 배열들을 포함하도록 광범위하게 해석되도록 의도된다.

도 1은 예시적인 실시 예에서 X-컨테이너들을 구현하는 정보 처리 시스템(100)을 도시한다. 시스템(100)은 복수의 사용자 디바이스(102-1, 102-2, . . . 102-N)를 포함한다. 사용자 디바이스들(102)은 네트워크(105)를 통해 클라우드 기반 처리 플랫폼(104)과 통신하도록 구성된다.

사용자 디바이스들(102) 중 하나 이상은 각각 예를 들어, 랩톱 컴퓨터, 태블릿 컴퓨터 또는 데스크톱 개인용 컴퓨터, 모바일 전화 또는 다른 유형의 컴퓨터 또는 통신 디바이스, 뿐만 아니라 그러한 다수의 디바이스의 조합들을 포함할 수 있다. 일부 실시 예에서, 사용자 디바이스들(102) 중 하나 이상은 클라우드 기반 처리 플랫폼(104)을 포함할 수 있는, 실례로 하나 이상의 처리 플랫폼 상에 구현되는, 각각의 컴퓨팅 노드들을 포함할 수 있다.

시스템(100)의 다양한 요소 간 통신은 도면에서 네트워크(105)로 총괄하여 표현된 하나 이상의 네트워크를 통해 발생하는 것으로 가정된다. 네트워크(105)는 실례로 예를 들어, 글로벌 컴퓨터 네트워크 이를테면 인터넷, 광역 네트워크(WAN), 근거리 네트워크(LAN), 위성 네트워크, 전화 또는 케이블 네트워크, 셀룰러 네트워크, WiFi 또는 WiMAX와 같은 무선 프로토콜을 사용하여 구현되는 무선 네트워크, 또는 이러한 그리고 기타 유형들의 통신 네트워크들의 다양한 부분 또는 조합을 포함할 수 있다.

클라우드 기반 처리 플랫폼(104)은 각각 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 "처리 플랫폼"으로 여기서 보다 일반적으로 지칭되는 것의 일례이다. 처리 디바이스들 중 하나 이상은 각각 다수의 프로세서 및/또는 다수의 메모리를 포함할 수 있다.

처리 플랫폼의 소정의 그러한 처리 디바이스의 프로세서는 예를 들어, 마이크로 프로세서, 주문형 반도체(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 중앙 처리 장치(CPU), 산술 논리 장치(ALU), 그래픽 처리 장치(GPU), 디지털 신호 프로세서(DSP) 또는 기타 유사한 처리 디바이스 구성요소, 뿐만 아니라 처리 회로의 기타 유형들 및 배열들을, 임의의 조합으로 포함할 수 있다.

처리 플랫폼의 소정의 그러한 처리 디바이스의 메모리는 예를 들어, 전자 메모리 이를테면 정적 랜덤 액세스 메모리(SRAM), 동적 랜덤 액세스 메모리(DRAM) 또는 기타 유형들의 RAM, 판독 전용 메모리(ROM), 플래시 메모리 또는 기타 유형들의 비휘발성 메모리, 자기 메모리, 광학 메모리 또는 기타 유형들의 저장 디바이스들을, 조합하여 포함할 수 있다.

메모리는 실례로 프로세스에 의한 실행을 위한 프로그램 코드를 저장한다. 그러한 메모리는 프로그램 코드가 내장된 "프로세서-판독 가능 저장 매체"로 여기서 보다 일반적으로 지칭되는 것의 일례이다.

그러한 프로세서-판독 가능 저장 매체를 포함하는 제조품들이 본 발명의 실시 예들로 고려된다. 용어 "제조품"은 여기서 사용될 때 일시적인 전파 신호들을 배제하는 것으로 이해되어야 한다.

프로세서-판독 가능 저장 매체를 포함하는 기타 유형들의 컴퓨터 프로그램 제품들은 다른 실시 예들에서 구현될 수 있다.

또한, 본 발명의 실시 예들은 여기에 개시된 바와 같이 X-컨테이너들을 구현하는 것과 연관된 처리 동작들을 구현하도록 구성된 처리 회로를 포함하는 집적 회로들의 형태로 구현될 수 있다.

클라우드 기반 처리 플랫폼(104) 또는 여기에 개시된 기타 처리 플랫폼의 소정의 처리 디바이스는 통상적으로 위에서 언급한 프로세서 및 메모리에 더하여 기타 구성요소들을 포함할 것이다. 예를 들어, 소정의 처리 디바이스는 실례로 처리 디바이스가 다른 시스템 요소들과 네트워크(105)를 통해 통신할 수 있게 하도록 구성된 네트워크 인터페이스를 포함한다. 그러한 네트워크 인터페이스는 실례로 하나 이상의 종래의 트랜시버를 포함한다.

본 실시 예의 클라우드 기반 처리 플랫폼(104)은 보다 구체적으로 물리적 인프라스트럭처(114) 상에서 실행되는 가상화 인프라스트럭처(112)를 이용하는 복수의 X-컨테이너(110)를 구현한다. 물리적 인프라스트럭처(114)는 실례로 각각 적어도 하나의 프로세서 및 적어도 하나의 메모리를 포함하는, 상술한 유형의 복수의 처리 디바이스를 포함한다. 예를 들어, 일부 실시 예에서, 물리적 인프라스트럭처는 베어-메탈 호스트들 또는 기타 유형들의 컴퓨터들 또는 서버들을 포함한다. 일부 실시 예에서, 가상화 인프라스트럭처(112)는 가상 기계 하이퍼바이저들을 포함하지만, 하이퍼바이저들은 X-컨테이너들(110)은 구현하는 데 필요하진 않다. 그에 따라, 가상화 인프라스트럭처(112)는 다른 실시 예들에서 제거될 수 있다.

도 2의 정보 처리 시스템(200)은 가상화 인프라스트럭처(112)와 같은 가상화 인프라스트럭처를 포함하지 않는 하나의 가능한 대안적인 실시 예를 나타낸다. 시스템(200)에서, 엔터프라이즈 처리 플랫폼(204)은 물리적 인프라스트럭처(214) 상에 직접 복수의 X-컨테이너(210)를 구현하여, X-컨테이너들(210)과 기본 물리적 인프라스트럭처(214) 사이의 임의의 하이퍼바이저들 또는 기타 가상화 인프라스트럭처를 제거하며, 후자는 실례로 베어-메탈 호스트들 또는 기타 유형들의 컴퓨터들 또는 서버들로서 구현된다. 시스템(200)의 다른 요소들은 일반적으로 도 1의 시스템(100)과 관련하여 이전에 설명된 것들과 동일하다.

각각 도 1 및 도 2에 도시된 바와 같은 시스템들(100 및 200)의 특정 배열들은 단지 예시적인 예로서 제시되고, 많은 다른 배열이 가능한 것으로 이해되어야 한다.

예를 들어, 이러한 실시 예들은 각각의 클라우드 기반 및 엔터프라이즈 처리 플랫폼들에 X-컨테이너들을 구현하지만, 사물 인터넷(IoT) 플랫폼들 및 네트워크 기능 가상화(NFV, Network Function Virtualization) 플랫폼들과 같은 다양한 추가적인 또는 대안적인 처리 플랫폼들이 사용될 수 있다.

기타 예들로는 PaaS(Platform-as-a-Service) 모델, SaaS(Software-as-a-Service) 모델, IaaS(Infrastructure-as-a-Service) 모델 및/또는 Faas(Function-as-a-Service) 모델, 뿐만 아니라 엔터프라이즈 애플리케이션 컨테이너 플랫폼, 서버리스 컴퓨팅 플랫폼, 마이크로 서비스 플랫폼, 클라우드 기반 기본 애플리케이션 플랫폼, 뿐만 아니라 기타 일반 클라우드 컴퓨팅 또는 엔터프라이즈 컴퓨팅 인프라스트럭처에 따라 구현되는 플랫폼들을 포함한다. 보다 일반적으로, X-컨테이너들은 보안 및 성능 이점들을 활용할 수 있는 임의의 플랫폼 상에 구현될 수 있다.

X-컨테이너들(110 또는 210)을 구현할 때, 시스템들(100 또는 200)은 실례로 여기서 "커널 기반 격리 층"으로 지칭되는 것을 구현하도록 구성된다. X-컨테이너들(110 또는 210) 중 소정의 하나는 실례로 커널 기반 격리 층 상에 소프트웨어 컨테이너로서 구성된다. 소정의 X-컨테이너는 전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하고, 하나 이상의 사용자 프로세스가 소정의 X-컨테이너에서 실행된다. 일부 실시 예에서, 커널 기반 격리 층은 보다 구체적으로 X-컨테이너의 전용 운영 체제 커널에 관해 X-커널 형태로 구현된다. X-커널은 보다 구체적으로 가상 기계 하이퍼바이저 또는 호스트 운영 체제의 적어도 일부를 포함할 수 있다. 다른 실시 예들에서는 커널 기반 격리 층의 기타 유형들이 사용될 수도 있다.

도 3은 예시적인 실시 예에서 X-컨테이너들(310)의 예시적인 배열을 포함하는 정보 처리 시스템(300)의 일부를 도시한다. 이 예에서 X-컨테이너들(310)은 보다 구체적으로 모두 X-커널(312) 상에 구현되는 제1, 제2 및 제3 X-컨테이너들(310-1, 310-2 및 310-3)을 포함한다.

상술한 바와 같이, 일부 실시 예에서, X-커널은 가상 기계 하이퍼바이저(예를 들어, Xen)를 포함할 수 있다. 예를 들어, 이러한 유형의 소정의 실시 예에서 X-커널(312)은 도 1의 가상화 인프라스트럭처(112)의 하나 이상의 가상 기계 하이퍼바이저를 사용하여 구현될 수 있다. 여기서 가상 기계들은 각각의 VM들이라고도 한다.

다른 실시 예들에서, X-커널(312)은 호스트 운영 체제의 적어도 일부를 포함할 수 있다. 예를 들어, 이러한 유형의 실시 예에서, X-커널을 구현하는 데 리눅스 커널 또는 윈도우 OS 커널이 사용될 수 있다. 그러한 실시 예는 실례로 도 2의 물리적 인프라스트럭처(214) 상에서 직접 실행된다.

단지 예로서, 제1 X-컨테이너(310-1)는 단일 사용자 프로세스를 포함하고, 제2 X-컨테이너(310-2)는 두 개의 사용자 프로세스를 포함하며, 제3 X-컨테이너(310-3)는 세 개의 사용자 프로세스를 포함한다. X-컨테이너들 및 그 각각의 관련 프로세스 또는 프로세스들의 상이한 수 및 배열들도 사용될 수 있다.

도 3 실시 예에서, X-컨테이너들(310) 각각은 도면에서 X-LibOS로 표기된 라이브러리 운영 체제로서 대응하는 전용 운영 체제 커널을 포함한다. X-LibOS는 실례로 지정된 유형의 모놀리식 운영 체제 커널로부터 변환된다. X-LibOS X-컨테이너에서 실행되는 하나 이상의 사용자 프로세스의 권한 수준과 동일한 권한 수준으로 X-컨테이너에서 실행된다. X-LibOS는 여기서의 다른 곳에서 더 상세히 설명될 바와 같이, 실례로 시스템 호출들을 대응하는 함수 호출들로 변환하는 것과 관련하여 상기 하나 이상의 사용자 프로세스의 바이너리들의 자동 변환을 지원하도록 구성된다.

위에서 언급한 바와 같이, X-커널(312) 상의 X-컨테이너들(310) 각각은 그것의 대응하는 X-LibOS 인스턴스로서 별도의 전용 운영 체제 커널을 포함한다. 하나 이상의 사용자 프로세스의 상이한 세트들은 각각의 X-LibOS 인스턴스들을 사용하여 X-컨테이너들(310) 각각에서 실행된다. 그에 따라, X-컨테이너들(310)의 어느 하나에서 실행되는 사용자 프로세스들은 X-컨테이너들(310)의 다른 것들에서 실행되는 사용자 프로세스들과 안전하게 격리된다.

X-커널(312) 및 각각의 X-컨테이너들(310)의 X-LibOS 인스턴스들이 모두 동일한 유형의 운영 체제를 사용할 필요는 없다. 예를 들어, X-커널(312) 및 X-LibOS 인스턴스들 중 소정의 하나는 상이한 유형들의 각각의 제1 및 제2 운영 체제들을 사용하여 구현될 수 있다.

일부 실시 예에서, 전용 운영 체제 커널을 그것의 X-LibOS 인스턴스로서 포함하도록 X-커널(312) 상에 X-컨테이너들(310) 중 소정의 하나를 구성하는 것은 기존 소프트웨어 컨테이너의 컨테이너 이미지를 추출하고, X-커널(312) 상에 X-컨테이너를 구성할 때 추출된 컨테이너를 가상 기계 이미지로서 이용하는 것을 더 포함한다. 이러한 유형의 배열에서, X-커널(312) 상의 X-컨테이너는 기존 소프트웨어 컨테이너의 래핑된 버전을 포함할 수 있다. 기존 소프트웨어 컨테이너의 하나 이상의 사용자 프로세스는 실례로 그러한 하나 이상의 사용자 프로세스의 임의의 수정을 필요로 하지 않고 X-커널(312) 상의 소정의 X-컨테이너에 하나 이상의 사용자 프로세스로서 실행하도록 허용된다.

상이한 실시 예들에서는 X-컨테이너들(310)의 상이한 유형들이 구현될 수 있다. 예를 들어, 일부 실시 예에서, X-컨테이너들(310)은 여기서 의사-가상화된(para-virtualized) X-컨테이너들 또는 PV X-컨테이너들로 지칭되는 것으로 구현되며, 여기서 라이브러리 운영 체제 및 하나 이상의 사용자 프로세스는 사용자 모드로 실행된다. 이러한 유형의 일부 실시 예는 실례로 X-커널(312)을 다른 표준 가상 기계 하이퍼바이저 또는 운영 체제 커널의 수정된 버전으로 구현한다.

다른 예로, 다른 실시 예들에서, X-컨테이너들은 여기서 하드웨어-지원(hardware-assisted) X-컨테이너들 또는 HV X-컨테이너들로 지칭되는 것으로 구현되며, 여기서 라이브러리 운영 체제 및 하나 이상의 사용자 프로세스는 하드웨어-지원 가상 기계 내에서 커널 모드로 실행된다. 이러한 유형의 일부 실시 예는 X-커널(312)을 표준 가상 기계 하이퍼바이저 또는 운영 체제 커널로서 구현한다. 이러한 유형의 다른 실시 예들에서는 가상 기계 하이퍼바이저 또는 운영 체제에 대해 일부 수정이 이루어질 수도 있다는 것이 또한 가능하다.

도 3에 도시된 예시적인 X-컨테이너 아키텍처는 소프트웨어 컨테이너들에 대한 개선된 성능 및 격리를 제공한다. 일부 실시 예에서, X-컨테이너 아키텍처는 리눅스 커널과 같은 전통적인 모놀리식 운영 체제 커널을 X-컨테이너에서 하나 이상의 사용자 프로세스와 동일한 권한 수준으로 실행되는 X-LibOS 인스턴스로 전환한다. 상이한 X-컨테이너들의 격리는 최소한의 신뢰 컴퓨팅 기반(trusted computing base) 및 커널 공격 대상 영역(attack surface)으로 보호된다.

전통적인 컨테이너 구현들과 달리, X-컨테이너 격리는 지난 20년 동안 만들어진 대부분의 Intel 프로세서에 영향을 미치는 최근 발견된 Meltdown CPU 버그에 민감하지 않다. 예시적인 실시 예들은 이러한 취약성 및 기타 보안 문제로 인한 컨테이너 격리 문제를 완화하기 위해 사용될 수 있다.

일부 실시 예에서, X-컨테이너들은 실례로 시스템 호출 명령들을 함수 호출들로 자동 변환하도록 구성되며, 이는 기존 컨테이너들이 일부 실시 예에서 어떠한 수정 없이 X-컨테이너들에서 실행될 수 있다는 점에서 완전한 바이너리 호환성의 지원을 가능하게 한다.

X-컨테이너들은 기존 접근 방식들에 비해 향상된 격리를 보인다. 예를 들어, 개시된 배열들은 소정의 호스트 상의 손상된 컨테이너가 동일한 호스트 상의 다른 컨테이너들을 위험에 빠뜨리는 것을 방지한다. X-컨테이너들은 기존 애플리케이션들에 안전한 컨테이너 격리를 제공할 뿐만 아니라, 위에서 언급한 Meltdown 취약성과 같은 긴급한 컨테이너 보안 문제들에 대한 솔루션을 제공한다.

위에서 언급한 바와 같이, 예시적인 실시 예들에서 X-컨테이너들은 가상 기계 하이퍼바이저 또는 X-커널을 위한 운영 체제 커널(예를 들어, 소위 "엑소커널(exokernel)"로서의 역할을 하는)을 사용하여 이러한 문제들 및 기타 문제들을 해결한다. 리눅스 커널과 같은 전통적인 모놀리식 운영 체제 커널은 실례로 라이브러리 OS로 변환되고, 동일한 권한 수준의 하나 이상의 사용자 프로세스와 함께 실행된다.

사용자 프로세스들의 바이너리는 최적화된 성능과 완전한 바이너리 호환성을 위해 시스템 호출들을 함수 호출들로 변환하기 위해 즉시 패치될 수 있다.

기존 리눅스 컨테이너들(예를 들어, 도커(Docker), LXC)는 컨테이너 디스크 이미지를 추출하고 이를 가상 기계 이미지로 사용하여 X-컨테이너들로 자동 래핑할 수 있다.

X-컨테이너 아키텍처는 서로 신뢰할 수 없는 사용자들의 안전한 격리 및 효율적인 프로그램 실행을 지원하는 공용 컨테이너 클라우드들 또는 서버리스 컴퓨팅 플랫폼들은 물론, 기타 다양한 클라우드 기반 또는 엔터프라이즈 처리 플랫폼에서 사용될 수 있다.

앞서 언급한 바와 같이, 일부 실시 예에서 X-커널 및 X-LibOS 인스턴스들은 상이한 운영 체제 유형들을 기반으로 구현될 수 있다. 예를 들어, X-커널은 Xen 기반으로 구현될 수 있고, X-LibOS는 리눅스 커널 기반으로 구현될 수 있다.

일부 실시 예에서, X-컨테이너 아키텍처는 기존 애플리케이션들 및 커널 모듈들에 대한 완전한 호환성을 제공하기 위해 고효율 LibOS로서 작동하도록 수정된 리눅스 커널을 이용하는 한편, 하이퍼바이저 또는 운영 체제 커널들은 X-컨테이너들의 실행 및 격리를위한 엑소커널들로 사용될 수 있다.

각 X-컨테이너는 실례로 리눅스 커널을 기반으로 사용자 정의될 수 있는 전용 LibOS를 갖는 애플리케이션을 호스팅한다. X-컨테이너는 동일한 권한 수준에서 LibOS와 함께 실행되는 하나 이상의 사용자 프로세스를 지원할 수 있다. 상이한 프로세스들에는 리소스 관리 및 호환성을 위한 자체 주소 공간들이 있지만, 프로세스들이 병행하여 사용되는 한편, X-컨테이너들은 격리된다는 점에서, 더 이상 서로 안전한 격리를 제공하지 않는다.

X-컨테이너 아키텍처는 비용이 많이 드는 시스템 호출들을 훨씬 더 저렴한 LibOS 함수 호출들로 다시 작성하여 성능을 개선하기 위해 런타임 동안 애플리케이션의 바이너리를 자동으로 최적화한다. X-컨테이너들은 기본 도커 컨테이너들에 비해 훨씬 더 높은 원시 시스템 호출 스루풋을 가지며 다른 벤치마크들에 대해 기본 컨테이너들과 경쟁하거나 능가한다.

X-컨테이너 아키텍처는 또한 컨테이너들 및 서버리스 서비스들에 특화된 아키텍처들을 능가한다. 예를 들어 X-컨테이너, 유니커널 및 그래핀 상에서 NGINX로 wrk 웹 벤치 마크를 실행했다. 이러한 벤치마크에서, X-컨테이너 아키텍처는 유니커널과 필적할 만한 성능과 그래핀 스루풋의 약 2배를 갖는다. 그러나, PHP 및 MySQL을 실행할 때, X-컨테이너 아키텍처는 유니커널보다 훨씬 더 우수한 성능을 보인다.

일부 실시 예에서 X-컨테이너 아키텍처는 리눅스의 소프트웨어 기반을 많이 이용하지만, 설계 및 구현은 다양한 문제를 해결해야 한다. 예시적인 실시 예들은 다수의 별개의 예시적인 설계를 포함한다. 첫 번째 예시적인 설계에서는, Xen 위에서 사용자 프로세스와 함께 사용자 모드로 리눅스 커널을 실행했다. 이를 위해서는 Xen 하이퍼바이저에 대한 광범위한 수정이 필요하지만 특별한 하드웨어 지원은 필요하지 않다. 실제로, 이러한 설계는 베어-메탈 상 그리고 공용 클라우드의 가상 기계들 내부 모두에서 실행될 수 있다. 두 번째 예시적인 설계에서는, 하드웨어 가상화 지원을 활용하는 리눅스 커널과 함께 커널 모드로 사용자 프로세스들을 실행했다. 이러한 설계는 임의의 하이퍼바이저 상에서 실행될 수 있고 상이한 컨테이너들을 여전히 안전하게 격리한다. 두 경우 모두 리눅스의 아키텍처 종속 부분만 수정하면 된다.

일부 실시 예에서 X-컨테이너 아키텍처는 리눅스 컨테이너들과 호환 가능하고 기본 도커 컨테이너들뿐만 아니라 기타 LibOS 설계들에 대한 경쟁력 또는 우수한 성능과 격리를 제공하는 엑소커널 기반 컨테이너 아키텍처를 포함하다. 또한, 이러한 아키텍처는 호환성, 이식성 또는 성능을 저하시키지 않으면서 컨테이너들의 안전한 격리를 지원한다.

여기에 개시된 바와 같은 X-컨테이너들은 소프트웨어 구성요소들을 패키징하고 배포하는 데 사용될 수 있고, 개발자들이 하나의 컨테이너에 모든 종속성을 갖는 애플리케이션을 제공하며, 이는 그 다음 공용뿐만 아니라 전용 클라우드들 어디에서나 실행될 수 있다는 점에서, 이식성, 그리고 컨테이너가 가상 기계들에 비해 무시할 수 있는 오버헤드로 밀리초 내에 부트 스트랩될 수 있다는 점에서, 성능과 같은 이점들을 제공하는 서버리스 및 마이크로 서비스 아키텍처들의 기본 빌딩 블록으로서 사용될 수 있다. 다른 실시 예들에서는 X-컨테이너에 의해 다양한 다른 용례가 지원된다.

예시적인 실시 예들에서 X-컨테이너들이 종래의 접근 방식들에 비해 상당한 이점들을 제공한다는 것은 전술한 내용으로부터 명백하다. 예를 들어, X-컨테이너들은 기존 접근 방식들에 비해 성능 및 격리가 크게 개선된 라이브러리 OS를 기반으로하는 새로운 보안 모델을 제공한다. 대규모 컨테이너 클래스에 중요한 기능인 동일한 라이브러리 OS를 공유하는 다수의 프로세스를 지원한다. 본 접근 방식을 이용하면, 리눅스 커널 자체를 라이브러리 OS로 전환하여 100% 호환성을 제공한다. 예시적인 실시 예들은 시스템 호출들을 처음 볼 때만 리디렉션한 다음 자동으로 함수 호출들로 변환하여 후속 실행을 최적화한다. 예시적인 실시 예들은 기존의 수정되지 않은 컨테이너들을 실행하는 동시에, 성능을 위해 바이너리를 자동으로 최적화할 수 있다. 또한, 그러한 실시 예들은 상당히 감소된 공격 대상 영역 및 TCB를 가지며, 그에 따라 훨씬 더 안전하다. 하드웨어 가상화 지원이 없는 실시 예들을 포함하여 매우 다양한 상이한 구현이 가능하다.

여기에 개시된 이러한 그리고 다른 예시적인 실시 예들의 상술한 양태들은 단지 예로서 제시된 것이며, 어떠한 방식으로도 제한적인 것으로 해석되어서는 안 된다.

이제 예시적인 실시 예들의 동작에 관한 추가 세부 사항들이 도 4 내지 도 12를 참조하여 설명될 것이다.

최신 OS들은 다수의 사용자를 지원하고 프로세스들은 커널 격리(이는 프로세스가 커널의 무결성을 손상시키지 않고 커널에 유지되는 기밀 정보를 판독할 수 없도록 보장한다) 및 프로세스 격리(이는 하나의 프로세스가 쉽게 액세스하거나 다른 것을 손상시킬 수 없음을 보장한다)를 포함하여 다양한 유형의 격리를 지원한다.

커널 격리 보안 비용은 상당할 수 있다. 커널 코드에 액세스하기 위한 시스템 호출들은 라이브러리에 대한 함수 호출들보다 훨씬 더 느리다. 또한, 커널과 사용자 모드 코드 간의 데이터 종속성을 제거하기 위해 보통 데이터 복사가 입-출력(I/O) 스택에서 수행된다. 한편, OS 커널에 점점 더 많은 기능을 적용하는 추세가 있으며, 커널에 대한 공격을 방어하는 것은 점점 더 어려워지고 있다. 리눅스와 같은 최신 모놀리식 OS 커널들은 복잡해진 서비스들, 디바이스 드라이버들 및 시스템 호출 인터페이스들로 거대한 코드 기반이 되었다. 그러한 복잡한 시스템의 보안을 검증하는 것은 비실용적이며, 새로운 취약점들이 계속해서 발견되고 있다.

프로세스 격리도 유사한 문제가 있다. 하나는, 이러한 유형의 격리가 통상적으로 구현 및 시행 방식으로 인해 커널 격리에 의존한다. 하지만 더 중요한 것은 프로세스들이 보안 격리만을 위한 것이 아니라는 것이다. 그것들은 주로 리소스 공유 및 병행 지원에 사용되며, 이러한 최신 OS들을 지원하기 위해 공유 메모리, 공유 파일 시스템, 시그널링, 사용자 그룹들 및 디버깅 후크들을 포함하여 격리를 초월하는 인터페이스들을 제공한다. 이러한 메커니즘들은 보안 격리를 위해 프로세스에 의존하는 애플리케이션들에 많은 취약성을 유발하는 큰 공격 대상 영역을 노출시킨다.

예를 들어, Apache 웹 서버들은 동일한 사용자 ID로 하위 프로세스들을 생성한다. 손상된 프로세스는 디버깅 인터페이스(이를테면 ptrace) 또는 proc 파일 시스템을 활용하여 다른 프로세스의 메모리에 쉽게 액세스할 수 있다. 주의 깊게 구성하지 않으면, 손상된 프로세스가 공유 파일 시스템에 액세스하고 구성 파일들 또는 데이터베이스들에서도 정보를 훔칠 수 있다. 마지막으로, 해커가 커널을 손상시키지 않고 대부분의 프로세스 격리 메커니즘을 무력화하기 위해 루트 권한을 획득할 수 있는 권한 상승 공격이 있다.

실제로, 기존의 다중 클라이언트 애플리케이션은 상호 신뢰할 수 없는 클라이언트들을 격리하기 위해 프로세스들에 의존하고 있으며, 특히 각 클라이언트에 전용 프로세스를 할당하지 않는다. 많은 경우 프로세스들을 전혀 사용하지 않기도 한다. 예를 들어, NGINX 웹 서버, Apache Tomcat, MySQL 및 MongoDB와 같은 널리 사용되는 프로덕션 시스템들은 다중 처리 대신 이벤트 중심 모델 또는 다중 스레딩을 사용한다. Apache 웹 서버와 같은 다중 프로세스 애플리케이션은 보안 대신 병행을 위해 프로세스 풀을 사용하므로, 각 프로세스는 다중 스레드를 가지며 상이한 클라이언트들을 서빙하기 위해 재사용될 수 있다. 이러한 애플리케이션들은 역할 기반 액세스 제어, 인증 및 암호화와 같은 메커니즘들을 활용하여 애플리케이션 로직에서 클라이언트 격리를 구현한다.

그러나, 예외들이 있다. SSH 데몬은 프로세스 격리에 의존하여 상이한 사용자들을 격리한다. 또한, 동일한 커널 상에서 동일한 MySQL 데몬을 사용하는 다수의 애플리케이션이 있는 경우, MySQL에 내장된 프로세스 격리 및 클라이언트 격리의 조합은 일부 애플리케이션이 손상될 경우, 각 애플리케이션이 MySQL에 상이한 클라이언트로 가장한다는 점에서, 애플리케이션들에 보안을 제공한다.

이제 도 4를 참조하여 설명될 바와 같이, 여기에 개시된 예시적인 실시 예들은 격리 경계를 재고하는 것을 수반한다.

프로세스들은 리소스 관리 및 병행에 유용하지만, 이상적으로는 보안 격리를 프로세스 모델과 분리해야 한다. 실제로, 다른 격리 메커니즘들이 도입되었다.

도 4는 다양한 대체 아키텍처에서의 격리 경계들을 도시한다. 컨테이너 격리는 각 컨테이너가 커널의 자체 인스턴스화인 것처럼 보이도록 해당 커널 위에 명칭 공간들을 분리한다. 그러나, 사용되는 기술은 컨테이너들로 실현될 수 있는 임의의 격리가 그것들 없이 실현될 수 있다는 점에서, 기본적으로 프로세스 격리와 동일하다. 그것은 이용 가능한 많은 시스템 호출로 인해 공격 대상 영역이 큰 커널이 크고 취약한 TCB라는 문제를 해결하지 못한다.

보안 관점에서 볼 때, 각각 고유한 전용 커널이 있는 개별 가상 기계들(VM들)에서 컨테이너들을 실행하는 것이 가능한 솔루션이다. 이제 TCB는 공격 대상 영역이 훨씬 더 작은 비교적 작은 하이퍼바이저로 구성된다. 안타깝게도, 중복 리소스 소비와 격리 경계들로 인해 오버헤드는 높다. 그럼에도 불구하고, 이는 이제 다중 테넌트 컨테이너 클라우드들에 대한 사실상의 솔루션이다. 이러한 솔루션의 높은 비용을 처리하기 위해, 유니커널, EbbRT, OSv 및 듄(Dune)과 같은 보다 실험적인 시스템들은 VM들의 내부에서 실행되도록 설계된 경량 OS 커널 대안들이다. 안타깝게도, 바이너리 수준 호환성이 없기 때문에 애플리케이션들은 잘 지원하지 않는다. 또한, 통상적으로 단일 프로세스 애플리케이션들만 지원할 수 있다.

마이크로커널 아키텍처에서, 대부분의 전통적인 OS 서비스는 별도의 사용자 프로세스들로 애플리케이션 프로세스들과 함께 실행된다. 그러한 아키텍처들은 바이너리 호환성을 제공할 수 있다. 그러나, 상이한 애플리케이션들이 그러한 OS 서비스들을 공유하기 때문에, 손상된 OS 서비스는 애플리케이션들 간의 격리를 해제하여, TCB 및 공격 영역 대상이 감소되지 않게 된다. 또한, 시스템 호출 오버헤드가 큰 경향이 있다.

여기서의 예시적인 실시 예들에서 X-컨테이너 아키텍처는 애플리케이션들 간의 보안 격리를 위해 개선된 패러다임을 제공한다. 예를 들어, 일부 실시 예에서 아키텍처는 엑소커넬 아키텍처에 기반하여,작은 커널 공격 대상 영역 및 낮은 시스템 호출 오버헤드를 갖는다. 개별 X-컨테이너는 예를 들어, 리소스 관리 및 병행을 위해 다수의 프로세스를 가질 수 있지만, 개별 X-컨테이너 내의 그러한 프로세스들은 서로 격리되지 않는다. 대신, 사용자들 및/또는 애플리케이션들은 상이한 사용자들 및/또는 애플리케이션들에 대해 별도의 X-컨테이너를 생성하여 서로 격리된다. X-컨테이너 내에서 격리를 제거하면 시스템 호출 오버헤드를 함수 호출의 오버헤드로 감소시킬 수 있다.

위에서 지적한 바와 같이, 예시적인 실시 예들에서 X-컨테이너들은 완전한 바이너리 호환성을 가진 표준 OS 커널에 기반한 X-LibOS를 사용한다. 일부 구현에서, X-LibOS는 리눅스에서 파생되고, 리눅스의 아키텍처 의존 부분에 대한 변경만 필요하다. 표준 커널 사용의 이점들은 많다. 예를 들어, 리눅스는 고도로 최적화되고 성숙하며, 능동적인 커뮤니티에 의해 개발되고 있다. X-컨테이너들은 그러한 이점들을 완전히 활용하지만, 격리에 대해 훨씬 더 작은 X-커널에 의존한다. 일부 구현에서, X-커널은 Xen에서 파생된다.

앞서 언급했듯이, 상이한 애플리케이션들은 상이한 X-컨테이너들에 배치되어야 한다. 도 5는 각각 MySQL 데이터베이스를 사용하는 두 개의 애플리케이션을 수반하는 예시적인 실시 예의 컨텍스트에서 이를 도시한다. 도 5는 도 5(a), 도 5(b) 및 도 5(c)로 표기된 세 개의 부분을 포함한다.

한 가지 옵션은 도 5(a)에 도시된 바와 같이, 각 애플리케이션에 대한 X-컨테이너들과 MySQL 전용의 제3 X-컨테이너를 생성하는 것이다. 즉, 이 옵션은 MySQL을 자체 격리된 애플리케이션으로 취급한다. MySQL은 내부적으로 두 애플리케이션의 테이블들을 안전하게 분리하는 액세스 제어 로직을 포함한다.

보다 안전한 구성은 도 5(b)에 도시된 바와 같이, 각 애플리케이션에 대해 하나씩, 각각이 자체 X-컨테이너에서 실행되는 두 개의 MySQL 인스턴스를 생성하여, 총 네 개의 X-컨테이너가 생성될 수 잇다. 이렇게 하면 MySQL 구현 내에서 액세스 제어 로직에 대한 의존성이 제거되므로 구성 보안이 절대적으로 증가된다. 또한, 이 옵션은 MySQL 서버들과 이들을 지원하는 운영 체제 커널들 모두에서 더 나은 사용자 정의 기능을 제공한다.

그러나, 도 5(b)의 각 애플리케이션가 자체 MySQL 인스턴스를 갖는 것에 유의한다. 각 애플리케이션은 그것의 데이터를 지속적으로 저장하고 쿼리들에 올바르게 응답하기 위해 그것의 MySQL 인스턴스에 의존하는 한편, 반대로 각 MySQL 인스턴스는 전용이며 자체 애플리케이션에 의해 손상되어 잃을 것이 없다. 따라서, 우리는 도 5(c)에 도시된 바와 같이, 각각이 전용 MySQL 인스턴스와 함께 애플리케이션 로직을 포함하는 단지 두 개의 X-컨테이너만 안전하게 전개할 수 있다. 이 옵션은 각각 도 5(a) 및 도 5(b)에 도시된 세 개 또는 네 개의 X-컨테이너 구성보다 훨씬 더 나은 성능을 제공한다.

X-컨테이너들 또는 일반적으로 컨테이너들 상에서 실행되는 애플리케이션들의 경우, 외부 및 내부 위협의 두 가지 종류를 고려할 수 있으며, 이러한 위협들은 공모하는 것이 가능하다. 외부 위협 유형 중 하나는 애플리케이션 로직을 손상시키도록 설계된 메시지에 의한다. 이러한 위협은 애플리케이션 및 운영 체제 로직으로 대항되며 표준 컨테이너들 및 X-컨테이너들에 대해 동일하다. 또 다른 유형의 외부 위협은 컨테이너의 격리 장벽을 돌파하려고 할 수 있다. 표준 컨테이너들의 경우, 이러한 격리 장벽은 기본 범용 운영 체제 커널에 의해 제공되며, 이는 큰 TCB를 가지며 많은 수의 시스템 호출로 인해 큰 공격 대상 영역을 갖는다. 반대로, X-컨테이너들은 예시적인 실시 예들에서 격리에 대해 격리를 제공하는 데 전용되는 비교적 작은 X-커널에 의존한다. 그것은 TCB가 작고 비교적 보안이 쉬운 하이퍼바이저 호출 수가 적다. 우리는 X-컨테이너들이 표준 컨테이너들보다 외부 위협들에 대해 절대적으로 더 나은 보호를 제공한다고 믿는다.

내부 위협들은 서드 파티 라이브러리들에 의존하는 애플리케이션에 의해 생성되거나, 위의 MySQL 예에 의해 설명한 바와 같이, 동일한 컨테이너 내에서 전개되는 서드 파티 서비스들에 의해 생성된다. 리눅스 컨테이너에서, 애플리케이션들은 리눅스를 신뢰하여 상이한 사용자 계정들이 소유한 프로세스들 간에 격리를 구현한다. X-컨테이너들은 동일한 컨테이너의 프로세스들 간에 보안 격리를 명시 적으로 제공하지 않는다. 프로세스들 간 보안 격리 장벽들에 의존하는 애플리케이션들은 표준 VM 및 리눅스 솔루션 중 어느 하나를 사용하거나 충돌하는 프로세스들이 상이한 X-컨테이너들에서 실행되도록 애플리케이션을 재구성해야 한다. 후자는 더 나은 보안을 제공하지만 더 많은 구현 노력이 필요하다.

이제 X-컨테이너들의 예시적인 실시 예들의 추가 설계 및 구현 세부 사항들이 설명될 것이다.

이상적으로, 컨테이너들은 애플리케이션들의 실행을 위해 안전하고 독립적인 환경을 제공해야 한다. 다음은 애플리케이션 컨테이너들을 안전하게 실행하기 위한 아키텍처를 설계하기 위한 핵심 원리들이다:

1. 자급 및 사용자 지정 가능성: 컨테이너는 애플리케이션의 모든 종속성을 포함해야 한다. 이는 OS 커널뿐만 아니라, 라이브러리들, 파일 시스템 레이아웃 및 서드 파티 도구들도 포함한다. 컨테이너는 사용자 정의된 OS 커널을 사용하고 자체 커널 모듈들을 로딩할 수 있어야 한다.

2. 호환성: 이상적으로 컨테이너 플랫폼은 애플리케이션들을 변경할 필요가 없어야 한다. 바이너리 수준 호환성을 통해 사용자들은 애플리케이션들을 다시 작성하거나 다시 컴파일하지 않고도 컨테이너들을 즉시 전개할 수 있다.

3. TCB가 작은 격리: 컨테이너들은 서로 안전하게 격리되어야 한다. 공유된 물리적 리소스들에 액세스하기 위해 권한 있는 소프트웨어를 공유해야 하지만, 그러한 소프트웨어는 신뢰할 수 있고 크기가 작아야 한다.

4. 이식성: 컨테이너들의 주요 이점은 그것들이 한 번 패키징된 다음 베어-메탈 기계뜰 및 가상화된 클라우드 환경들을 포함한 모든 곳에서 실행될 수 있다는 점이다.

5. 확장성 및 효율성: 애플리케이션 컨테이너들은 가볍고 적은 오버헤드로 실행되어야 한다.

여기에 개시된 X-컨테이너들의 일부 구현에서는 하이퍼바이저를 X-커널 역할을 하도록 사용하고, 리눅스 커널 배포를 애플리케이션들과 동일한 권한 모드에서 실행될 수 있도록 X-LibOS 인스턴스로 수정한다. 다음 두 가지 구현 예를 보다 구체적으로 설명한다:

1. 사용자 모드에서 X-LibOS 및 애플리케이션을 실행하는 의사-가상화된(PV) X-컨테이너들. 그러한 구현은 실례로 하이퍼바이저(커널 모드로 실행되는)의 수정이 필요하지만, 특별한 하드웨어 지원이 필요하지 않으며 베어-메탈 기계들 뿐만 아니라 공용 클라우드의 VM들에서 전개될 수 있다.

2. 커널 모드에서 X-LibOS 및 애플리케이션들을 실행하는 하드웨어-지원 가상화된(HV) X-컨테이너들. 그러한 구현에는 실례로 하드웨어 가상화 지원이 필요하지만, 수정되지 않은 하이퍼바이저들과 함께 작동된다.

위의 첫 번째 구현 예에서는, Xen 상의 X-커널 구현을 기반으로 했다. Xen은 오픈 소스이며 리눅스에서 의사-가상화된 인터페이스에 대한 지원이 완성된다. 두 번째 구현 예에서는 하드웨어 가상화로 수정되지 않은 Xen을 X-커널로서 사용하지만, 다른 하이퍼바이저들도 사용될 수 있다. 예를 들어, Google Compute Engine의 KVM 상에서 HV X-컨테이너들을 실행했다.

두 구현 예는 모두 바람직한 기능들을 제공한다. 첫 번째 구현에서는 X-컨테이너들을 관리하는 방법을 더 잘 제어할 수 있다. 예를 들어, 동일한 VM에서 서로 안전하게 격리된 다수의 X-컨테이너를 실행할 수 있다. 단일 고성능 VM 상에서 다수의 X-컨테이너를 실행하면 각 X-컨테이너를 더 작은 자체 VM에서 실행하는 것보다 성능이 우수하고 보다 비용 효율적이다. 또한, 실시간 마이그레이션, 통합 및 메모리 벌루닝과 같은 Xen VM 관리 기능들이 PV X-컨테이너들에 대해 추가 보너스로 지원된다; 이것들은 기존 리눅스 컨테이너들에서는 잘 지원되지 않는 기능들이다.

하드웨어 가상화가 이용 가능할 때, 두 번째 구현이 더 나은 성능을 갖는 경향이 있다. 그러나, 가상화된 환경들에서 HV X-컨테이너는 중첩된 하드웨어 가상화가 지원되지 않는 한 전체 VM을 인수해야 한다. 공용클라우드들의 VM들은 일반적으로 중첩된 하드웨어 가상화를 노출시키지 않는다.

여기에 설명된 실험들에 대해, 리눅스 커널 4.4.44에서 두 버전의 X-LibOS를 파생시켰다. 커널에 대한 수정 사항들은 아키텍처 종속 층에 있으며 커널의 다른 층들이 알기 쉽다. 본원은 x86-64 롱 모드에서 실행되는 애플리케이션들에 중점을 두었다.

리눅스를 사용하면 본원에 바이너리 호환성이 제공되지만, 리눅스 커널도 사용자 정의가 가능하다. 그것은 수백 개의 부팅 파라미터, 수천 개의 컴파일 구성 및 많은 세분화된 런타임 튜닝 노브를 가진다. 대부분의 커널 기능을 커널 모듈들로 구성하고 런타임 동안 로딩될 수 있기 때문에, 사용자 정의된 리눅스 커널이 고도로 최적화될 수 있다. 예를 들어, 많은 이벤트 기반 애플리케이션과 같이 단일 스레드를 실행하는 애플리케이션들의 경우, 멀티 코어 및 대칭적 다중 처리(SMP, Symmetric Multiprocessing) 지원을 비활성화하면 불필요한 잠금 및 변환 색인 버퍼(TLB, translation lookaside buffer) 중단을 제거하여 성능을 크게 향상시킬 수 있다. 작업 부하에 따라, 애플리케이션들은 리눅스 스케줄러를 상이한 스케줄링 정책들로 구성할 수 있다. 많은 애플리케이션에서, 리눅스 커널의 잠재력은 커널 구성들을 제어할 수 없거나 다른 애플리케이션들과 커널을 공유해야 하기 때문에 완전히 악용되지 않았다. 리눅스 커널을 LibOS로 전환하고 그것은 단일 애플리케이션에 전용하면 이러한 모든 잠재력을 발산할 수 있다.

이제 위에서 언급된 PV X-컨테이너들의 예시적인 실시 예들이 더 상세히 설명될 것이다. 본원은 Xen 의사-가상화(PV) 아키텍처를 기반으로 PV X-컨테이너들을 구현했다. PV 아키텍처를 사용하면 하드웨어 지원 가상화를 지원하지 않고 동일한 물리적 기계 상에서 다수의 병행 리눅스 VM(예를 들어, PV 게스트 또는 Domain-U)을 실행할 수 있지만, 게스트 커널들은 기본 하이퍼바이저와 함께 작동하려면 약간의 변경이 필요하다. 다음에서는 Xen의 PV 아키텍처의 핵심 기술들 및 그것의 x86-64 플랫폼들에서의 제한 사항들을 검토한다.

PV 아키텍처에서, Xen은 가장 권한이 높은 모드(커널 모드)에서 실행되며 게스트 커널들 및 사용자 프로세스들은 모두 보다 적은 권한들로 실행된다. 새 페이지 테이블 설치 및 세그먼트 선택기 변경과 같이 보안 격리에 영향을 미칠 수 있는 모든 민감한 시스템 명령은 Xen에 의해 실행된다. 게스트 커널들은 서빙되기 전에 Xen에 의해 유효성이 검사되는 hypercalls들을 수행하여 그러한 서비스들은 요청한다. 예외들 및 인터럽트들은 효율적인 이벤트 채널들을 통해 가상화된다.

디바이스 I/O의 경우, 하드웨어를 에뮬레이션하는 대신, Xen은 보다 간단한 분할 드라이버 모델을 정의한다. 하드웨어 디바이스들에 액세스하고 다른 Domain-U에 의해 공유될 수 있도록 디바이스를 멀티플렉싱하는 권한이 있는 도메인(일반적으로 Domain-0, 부팅 동안 Xen에 의해 생성되는 호스트 도메인)이 있다. Domain-U는 Xen의 이벤트 채널들을 통해 Domain-0의 대응하는 백-엔드 드라이버에 연결되는 프런트-엔드 드라이버를 설치하고, 공유 메모리(비동기 버퍼 설명자 링들)를 사용하여 데이터가 전달된다.

Xen의 PV 인터페이스는 x86-32 플랫폼들 상에서 가장 효율적인 가상화 기술들 중 하나였기 때문에, 메인라인 리눅스 커널들에 의해 널리 지원되었다. 메모리 세그먼트화 보호를 위한 상이한 네 개의 권한 수준(링-0 내지 링-3)이 있기 때문에, 본원은 격리를 위해 상이한 권한 수준들에서 Xen, 게스트 커널들 및 사용자 프로세스들을 실행할 수 있다. Xen의 개입 없이 시스템 호출들이 수행될 수 있다. 그러나, PV 아키텍처는 x86-64 플랫폼들 상에서 근본적인 문제에 직면 해 있다. x86-64 롱 모드에서 세그먼트 보호가 제거되었기 때문에, 본원은 게스트 커널 및 사용자 프로세스를 모두 사용자 모드에서만 실행할 수 있다. 사용자 프로세스들로부터 게스트 커널을 보호하려면, 게스트 커널을 다른 주소 공간에 격리해야 한다. 각 시스템 호출은 가상 예외로서 Xen 하이퍼바이저에 의해 포워딩되어야하며, 페이지 테이블 및 TLB 플러시 전환이 발생한다. 이는 상당한 오버헤드를 수반하며 64 비트 리눅스 VM들이 오늘날 의사-가상화 대신 하드웨어 가상화에서 완전히 가상화된 상태로 실행하는 것을 선호하는 주된 이유들 중 하나이다.

이제 PV X-컨테이너들에서 커널 격리 제거와 관련된 양태들이 설명될 것이다.

PV X-컨테이너 아키텍처는 Xen PV 아키텍처와 유사하지만, 한 가지 중요한 차이점은 게스트 커널(즉, X-LibOS)이 사용자 프로세스들과 격리되지 않는다는 점이다. 대신, 그것들은 동일한 세그먼트 선택기들 및 페이지 테이블 권한 수준을 사용하므로 커널 액세스에 더 이상 (게스트) 사용자 모드와 (게스트) 커널 모드 간의 전환이 필요하지 않으며, 시스템 호출들을 함수 호출들로 수행할 수 있다.

이로 인해 다음과 같이 복잡해진다: Xen은 올바른 syscall 포워딩 및 인터럽트 전달을 위해 CPU가 게스트 사용자 모드인지 게스트 커널 모드인지 알아야 한다. Xen은 모든 사용자 커널 모드 전환이 Xen에 의해 해?fㄹ링되기 때문에 유지할 수 있는 플래그를 사용하여 이를 수행한다. 그러나, X-LibOS에서, 여기에 설명된 대로 경량 시스템 호출들 및 인터럽트 핸들링을 이용하면, 게스트 사용자-커널 모드 전환들이 더 이상 X- 커널을 수반하지 않는다. 대신, X-Kernel은 현재 스택 포인터의 위치를 확인하여 CPU가 커널 코드를 시행 중인지 또는 프로세스 코드를 실행 중인지를 결정한다. 일반적인 Linux 메모리 레이아웃에서와 같이, X-LibOS는 가상 메모리 주소 공간의 상단 절반에 매핑되며 모든 프로세스에 의해 공유된다. 사용자 프로세스 메모리는 주소 공간의 하단 절반에 매핑된다. 그에 따라, 스택 포인터의 최상위 비트는 게스트 커널 모드인지 게스트 사용자 모드인지를 나타낸다.

의사-가상화 Linux에서는, 페이지 테이블의 "전역" 비트가 비활성화되어 상이한 주소 공간들 간 전환이 전체 TLB 플러시를 야기하게 된다. 이는 X-LibOS에는 필요하지 않으므로, X-LibOS 및 X-커널에 대한 매핑들은 모두 페이지 테이블에 전역 비트가 설정되어 있다. 동일한 X-LibOS 상에서 실행되는 상이한 프로세스들 간 전환은 전체 TLB 플러시를 필요로 하지 않으므로, 주소 변환 성능이 크게 향상된다. 상이한 X-Container들 간의 컨텍스트 전환은 전체 TLB 플러시를 트리거한다.

커널 코드가 더 이상 보호되지 않기 때문에, 프로세스가 하나뿐이라면 커널 루틴들에 전용 스택이 필요하지 않을 것이다. 그러나, X-LibOS는 다수의 프로세스를 지원한다. 그에 따라, 본원은 여전히 커널 컨텍스트에서 전용 커널 스택들이 필요하며, 시스템 호출을 수행할 때, 사용자 스택에서 커널 스택으로의 전환이 필요하다.

이제 PV X-컨테이너들에서 경량 인터럽트 핸들링과 관련된 양태들이 설명될 것이다.

Xen PV 아키텍처에서, 인터럽트들은 비동기 이벤트들로서 전달된다. 보류 중인 이벤트가 있는지 여부를 나타내는 Xen 및 게스트 커널에 의해 공유되는 변수가 있다. 그렇다면, 게스트 커널은 그러한 이벤트들이 전달되게 하기 위해 Xen에 hypercall을 발행한다. X-컨테이너 아키텍처에서, X-LibOS는 임의의 보류 중인 이벤트들을 볼 때 인터럽트 스택 프레임을 에뮬레이션하고 먼저 X-커널로 트래핑하지 않고 인터럽트 핸들러들로 바로 점프할 수 있다.

인터럽트 핸들러에서 복귀하기 위해, iret 명령을 사용하여 코드 및 스택 세그먼트들, 스택 포인터, 플래그 및 명령어 포인터를 함께 재설정한다. 인터럽트들은 또한 원자적으로 활성화되어야 한다. 그러나 Xen PV 아키텍처에서 가상 인터럽트들은 메모리 위치에 기록을 통해서만 활성화될 수 있으며, 이는 다른 동작들과 함께 원자적으로 수행될 수 없다. 권한 수준들을 전환할 때 원자성 및 보안을 보장하기 위해, Xen은 iret 구현을 위한 hypercall을 제공한다. X-컨테이너 아키텍처에서는 사용자 모드에서 iret을 완전히 구현할 수 있다.

사용자 모드에서 iret을 구현할 때 두 가지 문제가 있다: 첫째, 반환 주소로 다시 점프하기 전에 모든 일반 레지스터가 복원되어야 하므로, 스택 및 명령 포인터들과 같은 임시 값들이 레지스터들 대신 메모리에만 저장될 수 있다. 둘째, hypercall들을 발행하지 않으면, 가상 인터럽트들이 다른 동작들과 함께 원자적으로 활성화될 수 없다. 따라서 메모리에 저장된 임시 값들을 조작하는 코드가 재진입을 지원해야 한다.

고려해야 할 두 가지 사례가 있다. 커널 모드 스택 상에서 실행되는 위치로 돌아갈 때, X-LibOS는 반환 주소를 포함하여 대상 스택 상에 임시 레지스터들을 푸시하고 인터럽트들을 활성화하기 전에 스택 포인터를 전환하여 선점이 안전함을 보장한다. 그 다음 코드는 간단한 ret 명령을 사용하여 반환 주소로 점프한다. 사용자 모드 스택으로 돌아갈 때, 사용자 모드 스택 포인터가 유효하지 않을 수 있으므로, X-LibOS는 시스템 호출 핸들링을 위해 커널 스택에 임시 값들을 저장하고 인터럽트들을 활성화한 다음 iret 명령을 실행한다. iret과 유사하게, 시스템 호출 핸들러로부터 반환하는 데 사용되는 sysret 명령은 커널 모드로 트래핑되지 않고 최적화된다. 특정 임시 레지스터들을 활용할 수 있으므로 sysret을 구현하는 것이 더 쉽다.

이제 위에서 언급된 HV X-컨테이너들의 예시적인 실시 예들이 더 상세히 설명될 것이다. 위에서 설명한 PV X-컨테이너들의 일반성은 페이지 테이블 조작 및 컨텍스트 전환을 포함하여 hypercall들을 통해 모든 민감한 시스템 명령을 수행하는 비용과 함께 발생한다. HV X-컨테이너들은 하드웨어 가상화 지원이 이용 가능한 경우 이러한 비용을 제거한다.

하드웨어 가상화 지원을 이용하면, X-LibOS는 커널 모드에서 실행되고 대부분의 권한 명령을 직접 실행할 수 있으므로 페이지 테이블 관리 및 컨텍스트 전환의 성능이 크게 향상된다. 주요 문제는 커널 모드에서 사용자 프로세스들을 실행하는 것에서도 비롯된다. 사용자 프로세스들이 커널 모드에서 실행될 수 있도록 리눅스 커널의 메모리 및 CPU 관리 구성요소들을 수정하는 것 외에도, 인터럽트들 및 예외들의 핸들링 방법도 변경되어야 한다. CPU가 HV X-컨테이너들에서 직접 인터럽트들 및 예외들을 전달하기 때문에, X-커널은 그것들의 핸들링 방법을 제어할 수 없다. x86 플랫폼들 상의 기본 거동은 커널 모드에서 인터럽트 또는 예외가 있을 때 스택 전환이 발생하지 않는다는 것이다. 이는 인터럽트 핸들러가 사용자 스택 상에서 직접 실행될 수 있음을 의미하며, 이는 사용자 코드 및 커널 코드의 기본 가정을 깨뜨린다: 사용자 스택 상의 데이터가 손상될 수 있으며 그러한 상황을 올바르게 핸들링하기 위해 리눅스 커널의 많은 코드가 변경되어야 한다.

다행히, x86-64는 인터럽트 및 예외 시 스택 전환을 강제하기 위해, 인터럽트 스택 테이블(IST, Interrupt Stack Table)이라고 하는 새로운 인터럽트 스택 스위치 메커니즘을 도입한다. 인터럽트 기술자 테이블(IDT, Interrupt Descriptor Table)에 태그를 지정하면, 권한 수준이 변경되지 않더라도 CPU가 새로운 스택 포인터로 전환될 것이다. 그러나, 중첩된 인터럽트들은 동일한 스택 포인터가 재사용되는 경우 문제가 된다. 본원은 IST에 임시 스택 포인터를 지정하여 이러한 문제를 해결했다. 인터럽트 핸들러를 입력한 직후, 중첩된 인터럽트들에 동일한 스택 포인터가 사용될 수 있도록 스택 프레임을 일반 커널 스택에 복사한다.

이제 PV 및 HV X-컨테이너들 모두에서 경량 시스템 호출들과 관련된 양태들이 설명될 것이다.

x86-64 아키텍처에서, 사용자 모드 프로그램들은 커널 모드의 루틴으로 제어를 전달하는 syscall 명령을 사용하여 시스템 호출들을 수행한다. X-커널은 즉시 X-LibOS로 제어를 전달하여, 바이너리 수준 호환성을 보장하므로 기존 애플리케이션들이 수정 없이 X-LibOS 상에서 실행될 수 있게 된다.

X-LibOS 및 프로세스는 모두 동일한 권한 수준에서 실행되므로, 시스템 호출 핸들러들을 직접 호출하는 것이 보다 효율적이다. 그러나, GS 세그먼트 설정에서 문제가 발생한다. 리눅스 커널은 GS 세그먼트에 CPU마다 변수들을 저장한다. 이러한 세그먼트는 모든 시스템 호출에 대해 커널에 들어가는 swapgs 명령에 의해 설정되며, 사용자 프로그램으로 되돌아가기 전에 리셋된다. 불행히도, swapgs 명령은 커널 모드에서만 유효하다. 세그먼트화 사용을 피하여 CPU별 변수 배치를 변경하는 것이 가능하다. 그러나 리눅스 커널에 대한 변경을 최소화하기 위해, 대신 X-LibOS에 들어가거나 나갈 때 GS 세그먼트 전환을 비활성화하여, GS 세그먼트를 항상 유효한 상태로 유지한다. x86-64 애플리케이션들은 스레드 로컬 스토리지에 FS 세그먼트를 사용할 수 있지만, GS 세그먼트는 통상적으로 건드려지지 않는다. 맞춤형 GS 세그먼트가 필요한 애플리케이션은 아직 보지 못했다.

또 다른 문제는 경량 시스템 호출들을 활성화하는 메커니즘에서 비롯된다. X-LibOS는 모든 프로세스의 고정 가상 메모리 주소에 매핑되는 vsyscall 페이지에 시스템 호출 항목 테이블을 저장한다. X-LibOS를 업데이트해도 시스템 호출 항목 테이블의 위치에는 영향을 주지 않을 것이다. 이러한 항목 테이블을 사용하여 애플리케이션들은 대부분의 기존 LibOS와 마찬가지로 소스 코드를 패치하여 시스템 호출들을 함수 호출들로 변경함으로써 X-컨테이너들에 대한 라이브러리들 및 바이너리들을 최적화할 수 있다. 그러나 그것은 전개 복잡성이 크게 증가하고, 이용 가능한 소스 코드가 없는 서드 파티 도구들 및 라이브러리들을 핸들링할 수 없다. 애플리케이션 재작성 또는 재컴파일을 방지하기 위해, PV X-컨테이너용 X-커널과 HV X-컨테이너용 X-LibOS에 온라인 자동 바이너리 최적화 모듈(ABOM, Automatic Binary Optimization Module)을 구현했다. syscall 명령들은 즉시 자동으로 함수 호출들로 대체한다. 제자리 바이너리 교체에는 많은 문제가 있다:

1. 바이너리 수준 동등성: 패치된 명령들의 전체 길이는 변경될 수 없으며, 프로그램은 애플리케이션 코드가 패치된 블록의 중간으로 점프할 때에도 정확히 동일한 기능들을 수행해야 한다.

2. 위치 독립성: glibc와 같은 라이브러리들이 상이한 프로세스들에 대해 상이한 위치들에 로딩되기 때문에, 상대 주소 변위 대신, 메모리 또는 레지스터에 저장된 절대 주소만 호출할 수 있다.

3. 성능에 미치는 영향 최소화: 애플리케이션을 로딩할 때 또는 런타임 동안 전체 바이너리를 스캔하는 것이 비현실적이다.

4. 판독 전용 페이지들의 핸들링: 대부분의 바이너리 코드는 메모리에서 판독 전용으로 매핑된다. 바이너리 교체는 X-LibOS에서 기록시 복사 메커니즘을 트리거할 수 없으며, 그렇지 않으면 잠재적으로 상이한 프로세스들에 대해 동일한 메모리 페이지의 다수의 복사본이 생성될 수 있다.

5. 병행 안전성: 상이한 스레드들 또는 프로세스들을 실행하는 다수의 CPU에 의해 동일한 코드가 공유될 수 있다. 교체는 다른 CPU들에 영향을 주거나 중지하지 않고 원자적으로 수행되어야 한다.

6. 교체 안전성: 교체 동안 메모리 스와핑이 발생할 수 있다. 시스템은 메모리를 손상시키거나 높은 성능 오버헤드를 일으키지 않고 그것을 올바르게 검출하고 핸들링할 수 있어야 한다.

ABOM은 사용자 프로세스들로부터 syscall 요청을 수신할 때 즉시 바이너리 교체를 수행하여 전체 바이너리 파일을 스캔하지 않는다. syscall 요청을 포워딩하기 전에, ABOM은 syscall 명령 주변의 바이너리를 확인하여 그것이 인식하는 임의의 패턴과 일치하는지 확인한다. 만약 그렇다면, ABOM은 CR-0 레지스터에서 기록 방지 비트를 일시적으로 비활성화하여, 커널 모드에서 실행되는 코드가 페이지 테이블에서 판독 전용으로 매핑된 경우에도 임의의 메모리 페이지를 변경할 수 있게 된다. 그 다음 ABOM은 원자적 cmpxchg 명령들을 이용하여 바이너리 패치를 수행한다. 각 cmpxchg 명령은 최대 8 바이트를 핸들링할 수 있으므로, 8 바이트를 초과하여 수정해야 하는 경우, 병행 안전성을 위해 바이너리의 임의의 중간 상태가 여전히 유효한지 확인해야 한다. 패치는 페이지 테이블 더티 비트가 판독 전용 페이지들로 설정될 것이라는 점을 제외하면, 대부분 X-LibOS가 알기 쉽다. X-LibOS는 그러한 더티 페이지들을 무시하거나 나중에 동일한 패치가 요구되지 않도록 그것들을 디스크로 플러싱하는 것을 선택할 수 있다.

더 큰 문제는 스와핑 안전성을 핸들링하는 것이다. 특히 PV X-컨테이너들에서, 메모리 스와핑의 결정은 X-LibOS에 의해 이루어지지만, 모든 페이지 테이블 조작은 X-커널의 hypercall들을 통해 수행된다. X-커널은 바이너리 교체 동안 스와핑을 방지하기 위해 페이지 테이블을 잠글 수 있지만, 이로 인해 성능 오버헤드가 높아질 수 있다. 최종적으로 바이너리 교체를 다음과 같이 구현했다: 바이너리 교체는 시스템 호출들의 컨텍스트에서 실행되므로, 교체 직전에 대상 페이지가 스와핑 아웃되면, 페이지에 기록하는 것이 페이지 결함을 트리거할 것이다. ABOM은 이러한 페이지 결함을 캡처하고 그것을 X-LibOS의 페이지 결함 핸들러로 전파하지 않고 시스템 호출을 계속 포워딩한다. ABOM은 다음에 그것이 실행될 때 동일한 위치에 패치를 시도한다.

도 6은 ABOM이 인식하는 세 가지 패턴의 바이너리 코드를 도시한다. 시스템 호출을 수행하기 위해, 프로그램들은 통상적으로 mov 명령을 이용하여 rax 또는 eax 레지스터에 시스템 호출 번호를 설정한 다음, syscall 명령을 실행한다. syscall 명령은 2 바이트이고, mov 명령은 피연산자들의 크기에 따라 5 바이트 또는 7 바이트이다. 이러한 두 명령을 메모리에 저장된 절대 주소를 갖는 단일 호출 명령으로 대체하며, 이는 7 바이트로 구현될 수 있다. 진입점들의 메모리 주소는 vsyscall 페이지에 저장된 시스템 호출 항목 테이블에서 검색된다. 바이너리 교체는 각 장소에 대해 한 번만 수행하면 된다.

7-바이트 교체를 통해, 두 개의 명령어를 하나로 병합한다. rax 레지스터를 다른 곳에 설정한 후 또는 인터럽트 후에 프로그램이 원래 syscall 명령의 위치로 직접 점프하는 드문 경우가 있다. 교체 후, 이는 항상 "0x60 0xff"인 호출 명령의 마지막 2 바이트로 점프할 것이다. 이러한 2 바이트는 X-커널(PV) 또는 X-LibOS(HV)에 잘못된 opcode 트랩을 발생시킨다. 바이너리 레벨 동등성을 제공하기 위해, X-커널(PV의 경우에만 해당) 및 X-LibOS에 특수 트랩 핸들러를 추가하여 명령 포인터를 호출 명령의 시작 부분으로 뒤로 이동시킴으로써 트랩을 수정한다. 일부 운영 체제의 부팅 시간 동안에만 이러한 트리거가 발생하는 것을 확인했다.

도 6에 도시된 바와 같이, 9-바이트 교체는 두 단계로 수행되며, 각 단계는 원래 바이너리와 동일한 결과들을 생성한다. mov 명령은 7 바이트를 가지므로, 그것을 syscall 핸들러에 대한 호출로 직접 대체한다. 프로그램이 직접 점프하는 경우를 대비하여, 원래 syscall 명령을 변경하지 않고 그대로 둘 수 있다. 그러나 본원은 이전 호출 명령으로 점프하여 그것을 더 최적화한다. X-LibOS의 syscall 핸들러는 반환 주소 상의 명령이 syscall인지 아니면 호출 명령에 대한 특정 jmp인지 다시 확인할 것이다. 만약 그렇다면, syscall 핸들러는 이러한 명령을 건너 뛰도록 반환 주소를 수정한다.

본원의 온라인 바이너리 교체 솔루션은 syscall 명령이 mov 명령 바로 뒤에 오는 경우에만 핸들링된다. 더 복잡한 경우에는, 일부 코드를 바이너리에 삽입하고 더 큰 코드 청크를 리디렉션할 수 있다. 또한 오프라인으로 수행할 수 있는 도구도 제공한다. glibc와 같은 대부분의 표준 라이브러리의 경우, 디폴트 시스템 호출 래퍼들은 ??ㅇ상적으로 도 6에 예시된 패턴을 사용한다. 따라서 본 실시 예는 임계 경로 상에서 대부분의 시스템 호출 래퍼들을 최적화하기에 충분하다.

이제 PV 및 HV X-컨테이너들 모두에서 도커 이미지들의 경량 부트 스트래핑과 관련된 양태들이 설명될 것이다.

X-컨테이너들은 VM 디스크 이미지를 갖지 않고 VM이 그러한 것과 동일한 부트스트래핑 단계를 거치지 않는다. X-컨테이너를 부트스트래핑하기 위해, X-커널은 특수 부트 로더가 있는 X-LibOS를 메모리에 로딩하고 X-LibOS의 진입점으로 바로 점프한다. 부트로더는 IP 주소들의 설정을 포함하여 가상 디바이스들을 초기화한 다음, 임의의 불필요한 서비스들을 실행하지 않고 컨테이너에서 프로세스를 생성한다. 컨테이너의 첫 번째 프로세스는 필요한 경우 추가 프로세스들을 포킹(forking)할 수 있다. 또한, HV X-LibOS는 기본 하이퍼바이저들의 도움 없이 특수 부트로더를 이용하여 GNU GRand 통합 부트로더(GRUB)에 의해 로딩될 수도 있다. 이 접근 방식을 사용하면 X-컨테이너들이 통상적인 VM보다 작고 부팅 속도가 빨라진다. 예를 들어, 단일 bash 프로세스로 3초 이내에 메모리 크기가 64MB인 새로운 Ubuntu-16 X-컨테이너를 생성할 수 있다.

X-컨테이너들은 바이너리 수준 호환성을 지원하기 때문에, 수정 없이 임의의 기존 도커 이미지를 실행할 수 있다. 도커 래퍼를 이용하여 X-컨테이너 아키텍처를 도커 플랫폼에 연결한다. 호스트 X-컨테이너에서 실행되는 수정되지 않은 도커 엔진은 도커 이미지들을 가져와 구축하는 데 사용된다. 디바이스매버를 스토리지 드라이버로 사용하여, 도커 이미지들의 상이한 층들을 씬-프로비저닝된 기록시 복사 스냅샷 디바이스들로서 저장한다. 그 다음 도커 래퍼는 도커에서 메타 데이터를 검색하고 씬 블록 디바이스를 생성하며 그것을 새 X-컨테이너에 연결한다. 그 다음 컨테이너의 프로세스들이 전용 X-LibOS로 생성된다.

위에서 설명된 특정 예시적인 실시 예들의 예시적인 구현들을 이러한 예시적인 실시 예들의 다양한 이점을 실증하기 위해 종래의 배열들과 비교해 평가했다.

도 7은 예시적인 실시 예들의 이러한 평가에 이용되는 소프트웨어 스택들의 예들을 도시한다. 이 도면에서, 파선 상자는 도커 컨테이너 또는 X-컨테이너를 나타낸다. 실선은 권한 수준들 간의 격리 경계를 나타낸다. 점선은 라이브러리 인터페이스를 나타낸다.

평가의 일환으로, 베어-메탈 기계들과 공용 클라우드들의 VM들 모두에서 실험들을 수행했다. 베어-메탈 실험들을 위해, 하나의 10Gbit 스위치에 연결된 네 개의 Dell PowerEdge R720 서버(두 개의 2.9GHz Intel Xeon E5-2690 CPU, 16개의 코어, 32개의 스레드, 96GB 메모리, 4TB 디스크)를 사용했다. 클라우드 환경의 경우, 아마존 EC2 North Virginia 영역의 네 개의 VM(m3.xlarge 인스턴스, 2개의 CPU 코어, 4개의 스레드, 15GB 메모리, 및 2개의 40GB SSD 스토리지)에서 실험들을 행했다.

베이스라인으로서 베어-메탈과 아마존 HV 기계 모두에서 도커 컨테이너 플랫폼을 실행했다. 이러한 두 구성을 각각 도커/기본/베어 및 도커/기본/클라우드라고 한다. 개별 Xen HV 및 PV Domain-U VM들에서 실행되는 도커 컨테이너들 및 X-컨테이너들과의 성능을 대조했다. 이는 다음 여섯 개의 추가 구성을 초래한다:도커/HV/베어, 도커/PV/베어, X-컨테이너/HV/베어, X-컨테이너/PV/베어, X-컨테이너/HV/클라우드 및 X-컨테이너/PV/클라우드. 도 7은 이러한 구성들의 다양한 소프트웨어 스택을 도시한다. 이러한 여덟 개의 구성 중, 세 개는 클라우드에서 실행되고 다섯 개는 베어-메탈에서 실행된다.

기본 도커를 실행하는 호스트(물리적 기계 또는 아마존 EC2 인스턴스 중 어느 하나)는 도커 엔진 17.03.0-ce 및 리눅스 커널 4.4.44와 설치된 Ubuntu 16.04-LTS를 가졌다. Xen VM들을 실행하는 호스트에는 Domain-0에 CentOS-6이 설치되어 있고 Domain-U에 Ubuntu 16.04-LTS를 가지며 도커 엔진 17.03.0-ce, 리눅스 커널 4.4.44 및 Xen 4.2를 갖는다. X-컨테이너들을 실행하는 호스트는 리눅스 커널 4.4.44 기반의 X-LibOS및 CentOS-6을 호스트 X-컨테이너로서 사용했다. 도커 컨테이너들은 IRQ 균형 서비스가 켜져 있는 디폴트 NUMA-인식 리눅스 스케줄러를 사용했다. Domain-0 및 Host X-컨테이너는 전용 CPU 코어들로 구성되었으며, IRQ를 다른 코어들에 수동으로 균형을 맞췄다. 다른 VM들 또는 X-컨테이너들은 NUMA 배치에 따라 다른 CPU 코어들에 균등하게 분포되었다.

각 실험 세트에 대해, 동일한 도커 이미지가 사용되었다. 도커 엔진들은 모두 디바이스-매퍼 스토리지 드라이버들로 구성되었다. 클라이언트 또는 서버와 관련된 네트워크 벤치마크들을 실행할 때, 별도의 기계 또는 VM이 사용되었다.

X-컨테이너들에서 실행되는 애플리케이션들은 X-LibOS를 완전히 제어할 수 있기 때문에, 그것들은 단일 스레드만 사용 중일 때 대칭적 다중 처리(SMP) 및 다중 코어 지원을 비활성화할 수 있다. 이러한 최적화는 많은 경우 성능을 크게 향상시켜 변행 관리 및 TLB 중단을 제거한다. 도커 컨테이너들에서 실행되는 애플리케이션들은 루트 권한이 필요하기 때문에 이러한 종류의 최적화를 수행할 수 없다. 이어지는 마이크로 벤치마크들 및 매크로 벤치마크들에서는, 단일 프로세스 및 다중 프로세스 테스트들을 모두 수행했다. 단일 프로세스의 경우 X-LibOS에서 SMP 지원을 비활성화했다.

여기에 설명된 대부분의 실험에서, 5회 실행의 평균을 보고하고 표준 편차를 또한 제시한다.

마이크로 벤치마크 세트로 X-컨테이너들의 성능을 평가했다. Ubuntu16 도커 이미지로 시작하여 그것에서 UnixBench 및 iperf를 실행했다. 엑셀 벤치마크는 현재 프로세스상에 새 바이너리를 오버레이하는 exec 시스템 호출의 속도를 측정한다. 파일 복사 벤치마크들은 버퍼 크기들이 상이한 파일 복사 스루풋을 테스트한다. 파이프 스루풋 벤치마크는 파이프의 판독 및 기록 스루풋을 측정한다. 파이프 기반 컨텍스트 전환 벤치마크는 파이프와 통신하는 두 프로세스의 속도를 테스트한다. 프로세스 생성 벤치마크는 포크 시스템 호출로 새 프로세스 생성 성능을 측정한다. 시스템 호출 벤치마크는 dup, close, getpid, getuid 및 umask를 포함한 일련의 시스템 호출을 발행하는 속도를 테스트한다. 마지막으로, iperf 벤치마크는 TCP 전달 성능을 테스트한다. 병행 테스트들의 경우, EC2 인스턴스에 CPU 코어가 두 개뿐이므로 베어-메탈 실험들에서 4개의 복사본을 실행하고 아마존 EC2 실험에서 2개의 복사본을 실행했다.

도 8은 위에서 설명한 마이크로 벤치마크들에 대한 다양한 도 7의 구성의 상대적인 성능을 도시한다. 도 8은 도 8(a), 도 8(b), 도 8(c) 및 도 8(d)로 표기된 네 개의 부분을 포함한다.

일반적으로 X-컨테이너들은 시스템 호출들을 경량 함수 호출들로 전환했기 때문에 시스템 호출 스루풋이 훨씬 더 높은 것으로 나타났다. 단일 프로세스 벤치마크들의 경우 SMP 지원을 비활성화하여 X-LibOS를 최적화했으며 그 결과 X-컨테이너들이 도커보다 훨씬 뛰어난 성능을 보였다. X-컨테이너/PV는 특히 아마존 EC2와 같은 가상화된 환경들에서 프로세스 생성 및 컨텍스트 전환에서 도커/기본에 비해 상당한 오버헤드가 있었다. 이는 프로세스 생성 및 컨텍스트 전환들에는 X-커널에서 수행되어야 하는 많은 페이지 테이블 동작이 수반되기 때문이다. X-컨테이너/HV는 이러한 오버헤드를 제거하고 도커/기본 및 도커/HV/베어보다 더 나은 성능을 달성했다. 도커/HV/베어는 디스크 캐싱의 추가 층이 있기 때문에 파일 복사 벤치마크들에서 도커/기본/베어보다 더 나은 성능을 달성한다.

우리는 또한 두 개의 매크로 벤치마크를 이용하여 X-컨테이너들의 성능을 평가했으며, 평가 결과들은 도 9에 도시되어 있다. 도 9는 도 9(a), 도 9(b), 도 9(c) 및 도 9(d)로 표기된 네 개의 부분을 포함한다. NGINX 웹 서버 스루풋에 대한 평가 결과들은 도 도 9(a) 및 도 9(b)에 도시되고, 커널 컴파일 시간에 대한 평가 결과들은 도 9(c) 및 도 9(d)에 도시된다.

NGINX 서버의 경우, 모든 플랫폼 상에서 도커 이미지 NGINX:1.11을 실행했다. wrk 벤치마크를 사용하여 단일 및 다중 작업자 프로세스 모두에서 NGINX 서버의 스루풋을 테스트했다. wrk 클라이언트는 NGINX 서버의 각 작업자 프로세스에 대해 10개의 스레드 및 100개의 연결을 시작했다. 베어-메탈 기계들 상에서, 도커 컨테이너들 및 X-컨테이너들은 브리지 네트워크를 사용했으며 클라이언트들에 직접 연결될 수 있다. 아마존 EC2 상에서, 그것들은 포트 포워딩 기능이 있는 전용 네트워크를 사용했다. X-컨테이너/HV/클라우드가 EC2의 전체 HVM을 인수했으므로, 그것은 포트 포워딩 없이 네트워크에 액세스했다. 커널 컴파일 테스트들을 위해, Ubuntu-16.04 도커 이미지를 사용하고 그 안에 컴파일 도구들을 설치했다. 최신 4.10 리눅스 커널을 “타이니(tiny)” 구성으로 컴파일했다. 병행 테스트들은 베어-메탈 실험들에서 4개의 병렬 작업에 의해 수행하고 아마존 EC2 실험들에서는 2개의 병렬 작업에 의해 수행한다.

도 9(a) 및 9(b)는 베어-메탈 기계들 및 아마존 EC2 상에서 측정된 NGINX 웹 서버 스루풋을 도시한다. X-컨테이너들은 커널 사용자 지정 및 감소된 시스템 호출 오버헤드로 인해 Xen VM들 내부의 도커 컨테이너들보다 지속적으로 성능이 뛰어났다. 단일 작업자 프로세스를 실행할 때, X-컨테이너/PV/베어 및 X-컨테이너/HV/베어는 SMP 지원을 비활성화하여 더욱 최적화되었으며 도커/네이티브/베어 컨테이너들보다 각각 5% 및 23% 높은 스루풋을 달성했다. 베어-메탈 상에서 병행 작업자 프로세스들을 실행할 때, X-컨테이너들의 성능은 도커/네이티브/베어 컨테이너들과 필적할 만 했다. 아마존 EC2에서, X-컨테이너들/HV/클라우드는 그것이 전체 HVM을 인수하고 포트 포워딩없이 실행되었기 때문에 도커/네이티브/클라우드보다 69% 내지 78% 더 높은 스루풋을 달성했다. 컨텍스트 전환 오버헤드로 인해, X-컨테이너들/PV/클라우드는 병행 테스트들에서 도커/네이티브/클라우드에 비해 20%의 성능 손실을 보였다. 이러한 결과는 네트워크 I/O 집약적 작업 부하들의 경우, X-컨테이너들이 VM들보다 성능이 더 우수하고 많은 경우 기본 도커 컨테이너들보다 성능이 훨씬 더 우수하다는 것을 보여준다.

도 9(c) 및 도 9(d)는 베어-메탈 기계들 및 아마존 EC2 인스턴스들 상의 커널 컴파일 시간을 도시하며, 커널 컴파일 시간이 긴 것보다 커널 컴파일 시간이 짧을수록 좋다. NGINX 실험들과 유사하게, 베어-메탈 기계들 상의 단일 프로세스 X-컨테이너들은 기본적으로 또는 VM들에서 실행되는 도커 컨테이너들보다 훨씬 더 나은 성능을 발휘했다. 아마존 EC2에서 유사한 개선을 보지 못했는데, 이는 다른 I/O 스케줄링 층 때문이라고 생각된다. PV X-컨테이너들의 성능은 의사-가상화된 환경들에서 페이지 테이블 관리의 높은 오버헤드로 인해 약간 저하되어, fork 및 exec와 같은 동작들이 느려졌다. 이러한 결과는 CPU 집약적인 작업 부하들의 경우, 경량 시스템 호출들에서 얻을 수 있는 성능 이점이 제한적이지만, 커널 사용자 정의에 의해 성능 향상이 여전히 가능함을 보여준다.

X-컨테이너들의 예시적인 실시 예들은 그래핀 및 유니커널과도 비교되었으며, 그 결과들이 도 10에 도시되어 있다. 도 10은 도 10(a), 도 10(b) 및 도 10(c)로 표기된 세 개의 부분을 포함한다.

이러한 비교들을 위해, 베어-메탈 기계들 상에서 NGINX 웹 서버, PHP 및 MySQL 데이터베이스로 wrk 벤치마크를 실행했다. 그래핀은 Ubuntu-16.04가 설치된 리눅스 상에서 실행되었고, 보안 격리 모듈(그것의 성능을 향상시켜야 하는) 없이 컴파일되었다. 유니커널의 경우, Rumprun을 사용했는데 이는 그것이 마이너 패치들로 그러한 애플리케이션들을 실행할 수 있기 때문이다(MirageOS로 실행하려면 OCaml로 전체 애플리케이션을 다시 작성해야 한다). 유니커널은 Xen HV에서의 실행을 지원하지 않으므로, PV 모드로만 테스트했다.

도 10(a)는 정적 웹 페이지들을 서빙하는 NGINX 웹 서버의 스루풋을 단일 작업자 프로세스와 비교한다. 실행 중인 NGINX 서버 프로세스가 하나뿐이므로, SMP를 비활성화하여 X-컨테이너들을 최적화했다. X-컨테이너들은 유니커널에 필적할 만하고, 그래핀의 두 배 이상의 스루풋을 달성했다.

도 10(b)는 단일 NGINX 웹 서버의 4개의 작업자 프로세스를 실행하는 경우를 도시한다. 이는 유니커널에서 지원하지 않으므로, 그래핀과만 비교했다. 이 경우, X-컨테이너들은 그래핀을 50% 이상 능가했다. 그래핀의 성능은 그래핀에서 다수의 프로세스가 IPC 호출을 사용하여 공유된 POSIX 라이브러리에 대한 액세스를 조정하기 때문에 제한되어 상당한 오버헤드가 발생했다.

앞에서 설명한 시나리오를 두 개의 PHP CGI 서버가 MySQL 데이터베이스들에 연결되는 도 5와 관련하여 평가했다. PHP의 내장 웹 서버를 활성화했고, wrk 클라이언트를 사용하여 데이터베이스에 대한 요청들을 발행한 페이지에 액세스했다(판독 및 기록에 대해 동일한 확률로). 도 5에 도시된 바와 같이, PHP 서버들은 데이터베이스를 공유하거나 별도로 가질 수 있다. 그래핀은 PHP CGI 서버를 지원하지 않으므로, 유니커널과만 비교했다. 두 PHP 서버의 총 스루풋은 상이한 구성으로 측정되었으며, 그 결과들은 도 10(c)에 도시되어 있다. 모든 VM은 하나의 CPU 코어로 단일 프로세스를 실행했다. 3-VM 및 4-VM 구성들에서, X-컨테이너들은 유니커널을 40% 이상 능가했다. 리눅스 커널이 Rumprun 커널보다 더 양호하게 최적화되었기 때문이라고 생각된다. 또한, X-컨테이너들은 단일 컨테이너에서 PHP 및 MySQL 실행을 지원하지만, 유니커널에서는 불가능하다. 이러한 편리함은 성능에도 크게 도움이 된다: X-컨테이너 스루풋은 유니커널 설정의 약 3배였다.

또한 예시적인 실시 예들의 확장성 평가를 수행했으며, 그 결과는도 11에 도시되어 있다.

하나의 물리적 기계 상에서 최대 400개의 컨테이너를 실행하여 X-컨테이너 아키텍처의 확장성을 평가했다. 이러한 실험을 위해 우리는 PHP-FPM 엔진이 있는 NGINX 서버를 사용했다. webdevops/PHP-NGINX 도커 이미지를 사용하고 NGINX 및 PHP-FPM을 단일 작업자 프로세스로 구성했다. wrk 벤치마크를 실행하여 모든 컨테이너의 총 스루풋을 측정했다. 각 컨테이너에는 5개의 병행 연결이 있는 전용 wrk 스레드가 있으므로, 총 wrk 스레드 및 병행 연결 수는 컨테이너 수에 따라 선형 적으로 증가한다.

각 X-컨테이너는 단일 가상 CPU와 128MB 메모리로 구성하였으며 X-LibOS는 SMP 지원을 비활성화하여 최적화하였다. X-컨테이너들은 보다 적은 양의 메모리(예를 들어, 64MB 메모리)로 작동할 수 있지만, 128MB 메모리 크기는 400개의 X-컨테이너를 부팅하기에 충분히 작다. 도커/HV/베어 및 도커/PV/베어의 경우, 각 Xen VM에 하나의 가상 CPU 및 512MB 메모리가 할당되었다(512MB는 Ubuntu-16 OS에 권장되는 최소 크기이다). 그러나, 물리적 기계는 96GB 메모리만 갖기 때문에, 200개보다 많은 VM을 시작할 때 VM들의 메모리 크기를 256MB로 변경해야 했다. VM들은 여전히 부팅할 수 있지만 네트워크 스택이 패킷들을 드롭하기 시작했음을 발견했다. Xen 상에서 250개보다 많은 PV 인스턴스 또는 200개보다 많은 HV 인스턴스를 올바르게 부팅할 수 없었다.

도 11은 모든 베어-메탈 구성의 집계된 스루풋을 도시한다. 도커/네이티브/베어 컨테이너들이 적은 수의 컨테이너에 대해 더 높은 스루풋을 달성했음을 알 수 있다. 이는 도커 컨테이너들 간 컨텍스트 전환이 X-컨테이너들 간 그리고 Xen VM들 간보다 저렴하기 때문이다. 그러나, 컨테이너 수가 증가함에 따라, 도커 컨테이너들의 성능은 더 빠르게 떨어졌다. 이는 각 NGINX + PHP 컨테이너가 4개의 프로세스를 실행했기 때문이다: N개의 컨테이너를 이용하여 도커 컨테이너들은 실행하는 리눅스 커널은 4N개의 프로세스를 스케줄링한 한편, X-커널은 각각 4개의 프로세스를 실행하는 N개의 가상 CPU를 스케줄링했다. 이러한 계층적 스케줄링은 많은 컨테이너를 함께 스케줄링하는 보다 확장 가능한 방법으로 밝혀졌으며, N = 400 X-컨테이너/PV/베어가 도커/기본/베어보다 18% 더 뛰어난 것으로 나타났다.

이제 도 12를 참조하여 설명될 바와 같이, 평가들은 커널 사용자 정의의 추가적인 성능 이점들을 추가로 입증했다. X-컨테이너들의 예시적인 실시 예들은 사용자 정의된 커널 모듈들을 필요로하는 애플리케이션 컨테이너들을 활성화한다. 예를 들어, X-컨테이너들은 소프트웨어 RDMA(Soft-iwarp 및 Soft-ROCE 양자) 애플리케이션들을 사용할 수 있다. 도커 환경들에서, 그러한 모듈들은 루트 권한을 필요로 하고 호스트 네트워크를 컨테이너에 직접 노출시켜, 보안 문제들을 제기한다.

세 개의 NGINX 웹 서버와 부하 밸런서를 이용하여 시나리오를 테스트했다. NGINX 웹 서버들은 각각 하나의 작업자 프로세스를 사용하도록 구성된다. 도커 플랫폼들은 통상적으로 HAProxy와 같은 사용자 수준 부하 밸런서를 사용한다. HAProxy는 프로덕션 시스템들에 폭넓게 전개된 단일 스레드 이벤트-드라이버 프록시 서버이다. X-컨테이너들은 HAProxy를 지원하지만, IPVS(IP Virtual Server)와 같은 커널 수준 부하 분산 솔루션을 사용할 수도 있다. IPVS는 새로운 커널 모듈들의 삽입 및 iptable 및 ARP 테이블 규칙들의 변경을 필요로 하며, 이는 루트 권한이 없고 호스트 네트워크에 대한 액세스 권한이 없는 도커 컨테이너들에서는 불가능하다.

이러한 실험에서는 HAProxy:1.7.5 도커 이미지를 사용했다. 부하 밸런서 및 NGINX 서버들은 동일한 물리적 기계 상에서 실행되었다. 최적화된 성능을 위해 X-LibOS에서 SMP 지원을 끄고 단일 가상 CPU로 각 X-컨테이너를 구성했다. wrk 작업 부하 생성기를 사용하고 총 스루풋을 측정했다.

도 12는 다양한 구성을 비교한다. HAProxy를 이용하는 X-컨테이너 플랫폼은 도커 컨테이너 플랫폼의 스루풋의 두 배를 달성했다. NAT 모드를 사용하는 IPVS 커널 수준 부하 밸런싱은 X-컨테이너들의 스루풋을 12% 더 향상시킨다. 이 경우 부하 밸런서는 웹 프런트엔드 및 NAT 서버 양자의 역할을 했기 때문에 병목 현상이 발생했다. IPVS는 "직접 라우팅"이라는 또 다른 부하 밸런싱 모드를 지원한다. 직접 라우팅을 이용하면, 부하 밸런서는 요청들을 백엔드 서버들로 포워딩하기만 하면 되는 한편, 백엔드 서버들로부터의 응답들은 클라이언트들로 직접 라우팅된다. 이를 위해서는 iptable 규칙들을 변경하고 부하 밸런서 및 NGINX 서버들 양자에 커널 모듈들을 삽입해야 한다. 직접 라우팅 모드를 이용하여 병목 현상이 NGINX 서버들로 이동했으며, 총 스루풋은 또 1.5배 향상되었다.

상기한 평가들과 관련하여 설명된 특정 X-컨테이너 실시 예들은 단지 예들일뿐, 예시적인 실시 예들의 이점들을 입증하기 위한 것이며, 어떤 식으로도 제한하는 것으로 간주되어서는 안 된다는 것이 이해되어야 한다.

도 1 내지 도 12와 관련하여 도시되고 설명된 특정 배열들은 단지 예시적인 예로서만 제시되고, 많은 대안적인 실시 예가 가능한 것으로 이해되어야 한다. 따라서 여기에 개시된 다양한 실시 예는 어떤 식으로도 제한하는 것으로 해석되어서는 안 된다. 다른 실시 예들에서 소프트웨어 컨테이너들을 구현하기 위한 많은 대안 적인 배열이 이용될 수 있다. 예를 들어, 특정 예시적인 실시 예들과 관련하여 설명된 특정 X-커널 배열 대신에 다른 유형들의 커널 기반 격리 층들이 사용될 수 있다. 해당 기술분야의 통상의 기술자들은 또한 다른 실시 예들에서 대안적인 처리 동작들 및 관련 시스템 엔티티 구성들이 사용될 수 있음을 인식할 것이다.

따라서 다른 실시 예들은 예시적인 실시 예들의 엔티티들에 비해, 추가적인 또는 대안적인 시스템 요소들을 포함할 수 있다. 따라서, 특정 시스템 구성들 및 관련 소프트웨어 컨테이너 및 커널 기반 격리 층 구현은 다른 실시 예들에서 달라질 수 있다.

여기에 설명된 바와 같은 정보 처리 시스템의 소정의 처리 디바이스 또는 다른 구성요소는 실례로 메모리에 연결되는 프로세서를 포함하는 대응하는 처리 디바이스를 이용하여 구성된다. 프로세서는 처리 동작들 및 기타 기능의 성능을 제어하기 위해 메모리에 저장된 소프트웨어 프로그램 코드를 실행한다. 처리 디바이스는 또한 하나 이상의 네트워크를 통한 통신을 지원하는 네트워크 인터페이스를 포함한다.

프로세서는 예를 들어, 마이크로 프로세서, ASIC, FPGA, CPU, ALU, GPU, DSP 또는 기타 유사한 처리 디바이스 구성요소, 뿐만 아니라 기타 유형들 및 배열들의 처리 회로를, 임의의 조합으로 포함할 수 있다. 예를 들어, 여기에 개시된 바와 같은 소정의 처리 디바이스는 그러한 회로를 사용하여 구현될 수 있다.

메모리는 처리 디바이스의 기능의 부분들을 구현할 때 프로세서에 의해 실행되는 소프트웨어 프로그램 코드를 저장한다. 대응하는 프로세서에 의한 실행을 위해 그러한 프로그램 코드를 저장하는 상기한 소정의 메모리는 프로그램 코드가 내장된 프로세서-판독 가능 저장 매체로서 여기서 보다 일반적으로 지칭되는 것의 일례이고, 예를 들어, 전자 메모리 이를테면 SRAM, DRAM 또는 기타 유형들의 랜덤 액세스 메모리, ROM, 플래시 메모리, 자기 메모리, 광학 메모리 또는 기타 유형들의 저장 디바이스들을 임의의 조합으로 포함할 수 있다.

전술한 바와 같이, 그러한 프로세서-판독 가능 저장 매체를 포함하는 제조품들이 본 발명의 실시 예들로 고려된다. 용어 "제조품"은 여기서 사용될 때 일시적인 전파 신호들을 배제하는 것으로 이해되어야 한다. 프로세서-판독 가능 저장 매체를 포함하는 기타 유형들의 컴퓨터 프로그램 제품들은 다른 실시 예들에서 구현될 수 있다.

또한, 본 발명의 실시 예들은 커널 기반 격리 층 상에 소프트웨어 컨테이너들을 제공하는 것과 연관된 처리 동작들을 구현하도록 구성된 처리 회로를 포함하는 집적 회로들의 형태로 구현될 수 있다.

여기에 개시된 정보 처리 시스템은 하나 이상의 처리 플랫폼 또는 이들의 부분들을 사용하여 구현될 수 있다.

예를 들어, 정보 처리 시스템의 적어도 일부를 구현하는 데 사용될 수 있는 처리 플랫폼의 하나의 예시적인 실시 예는 물리적 인프라스트럭처 상에서 실행되는 하이퍼바이저를 사용하여 구현된 가상 기계들을 포함하는 클라우드 인프라를 포함한다. 그러한 가상 기계들은 하나 이상의 네트워크를 통해 서로 통신하는 각각의 처리 디바이스들을 포함할 수 있다.

그러한 실시 예의 클라우드 인프라스트럭처는 하이퍼바이저의 제어하에 가상 기계들 각각에서 실행되는 하나 이상의 애플리케이션 세트를 더 포함할 수 있다. 또한 적어도 하나의 기본 물리적 기계를 사용하여 각각 가상 기계 세트를 제공하는 다수의 하이퍼바이저를 사용할 수도 있다. 정보 처리 시스템의 다양한 구성요소의 다수의 인스턴스를 구성하는 데에는 하나 이상의 하이퍼바이저에 의해 제공되는 다양한 가상 기계 세트가 이용될 수 있다.

여기에 개시된 바와 같은 정보 처리 시스템의 적어도 일부를 구현하는 데 사용될 수 있는 처리 플랫폼의 다른 예시적인 실시 예는 적어도 하나의 네트워크를 통해 서로 통신하는 복수의 처리 디바이스를 포함한다. 처리 플랫폼의 각 처리 디바이스는 메모리에 연결된 프로세서를 포함하는 것으로 가정된다.

다시, 이러한 특정 처리 플랫폼들은 예로서만 제시되며, 정보 처리 시스템은 추가적인 또는 대안적인 처리 플랫폼들, 뿐만 아니라 다수의 별개의 처리 플랫폼을 임의의 좋바으로 포함할 수 있으며, 그러한 각 플랫폼은 하나 이상의 컴퓨터, 서버, 저장 디바이스 또는 기타 처리 디바이스를 포함한다.

예를 들어, 본 발명의 실시 예들을 구현하는 데 사용되는 다른 처리 플랫폼들은 가상 기계들을 포함하는 가상화 인프라 대신에 또는 추가로 상이한 유형들의 가상화 인프라스트럭처를 포함할 수 있다. 그에 따라, 일부 실시 예에서 시스템 구성요소들이 클라우드 인프라스트럭처 또는 기타 유형들의 가상화 인프라스트럭처에서 적어도 부분적으로 실행될 수 있는 것이 가능하다.

따라서 다른 실시 예들에서 추가적인 또는 대안적인 요소들의 상이한 배열들이 사용될 수 있음을 이해해야 한다. 이러한 요소들의 적어도 서브 세트는 공통 처리 플랫폼 상에서 총괄하여 구현될 수 있거나, 각각의 그러한 요소가 별도의 처리 플랫폼 상에서 구현될 수 있다.

또한, 정보 처리 시스템에서 컴퓨터들, 서버들, 저장 디바이스들 또는 기타 구성요소들의 다양한 배열이 가능하다. 그러한 구성요소들은 임의의 유형의 네트워크 또는 기타 통신 매체를 통해 정보 처리 시스템의 다른 요소와 통신할 수 있다.

전술한 바와 같이, 여기에 개시된 바와 같은 시스템의 구성요소들은 메모리에 저장되고 처리 디바이스의 프로세서에 의해 실행되는 하나 이상의 소프트웨어 프로그램의 형태로 적어도 부분적으로 구현될 수 있다. 예를 들어, 여기에 개시된 특정 기능은 소프트웨어의 형태로 적어도 부분적으로 구현될 수 있다.

여기에 설명된 정보 처리 시스템들의 특정 구성들은 단지 예시일 뿐이며, 다른 실시 예들에서 그러한 소정의 시스템은 그러한 시스템의 종래의 구현에서 공통적으로 발견되는 유형의 하나 이상의 요소를 포함하여 구체적으로 도시된 것들에 추가하여 또는 대신 기타 요소들을 포함할 수 있다.

예를 들어, 일부 실시 예에서, 정보 처리 시스템은 개시된 기술들을 이용하여 다른 맥락들에서 추가 또는 대안적인 기능을 제공하도록 구성될 수 있다.

여기서 설명된 바와 같은 본 발명의 실시 예들은 단지 예시를 위한 것이라는 점이 다시 강조되어야 한다. 본 발명의 다른 실시 예들은 여기에 설명된 특정 예시적인 실시 예들에서 이용되는 것들과 상이한 다양한 유형 및 배열의 정보 처리 시스템들, 네트워크들 및 디바이스들을 이용하여 그리고 많은 대안적인 처리 맥락들에서 구현될 수 있다. 또한, 특정 실시 예들을 설명하는 맥락에서 여기서 이루어진 특정 가정들은 다른 실시 예들에 적용될 필요는 없다. 이러한 그리고 많은 기타 대안적인 실시 예가 해당 기술분야의 통상의 기술자들에게 쉽게 명백할 것이다.

Claims

방법으로서,
커널 기반 격리 층을 구현하는 단계;
전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하는 단계; 및
상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하는 단계를 포함하며;
상기 방법은 각각 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 처리 플랫폼에 의해 수행되는, 방법.
제1항에 있어서,
상기 커널 기반 격리 층은 상기 소프트웨어 컨테이너의 상기 전용 운영 체제 커널에 관해 X-커널 형태로 구현되는, 방법.
제1항에 있어서,
상기 커널 기반 격리 층은 가상 기계 하이퍼바이저 및 호스트 운영 체제 중 하나를 포함하는, 방법.
제1항에 있어서,
상기 라이브러리 운영 체제는 지정된 유형의 모놀리식 운영 체제 커널로부터 변환되는, 방법.
제1항에 있어서,
상기 라이브러리 운영 체제는 상기 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 권한 수준과 동일한 권한 수준으로 상기 소프트웨어 컨테이너에서 실행되는, 방법.
제1항에 있어서,
상기 라이브러리 운영 체제는 시스템 호출들을 대응하는 함수 호출들로 변환하는 것과 관련하여 상기 하나 이상의 사용자 프로세스의 바이너리들의 자동 변환을 지원하도록 구성되는, 방법.
제1항에 있어서,
전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하는 단계는:
기존 소프트웨어 컨테이너의 컨테이너 이미지를 추출하는 단계; 및
상기 커널 기반 격리 층 상에 상기 소프트웨어 컨테이너를 구성할 때 추출된 상기 컨테이너 이미지를 가상 기계 기미지로서 이용하는 단계를 더 포함하며;
상기 커널 기반 격리 층 상의 상기 소프트웨어 컨테이너는 상기 기존 소프트웨어 컨테이너의 래핑된 버전을 포함하는, 방법.
제7항에 있어서,
상기 기존 소프트웨어 컨테이너의 하나 이상의 사용자 프로세스는 그러한 하나 이상의 사용자 프로세스의 임의의 수정을 필요로 하지 않고 상기 커널 기반 격리 층 상의 상기 소프트웨어 컨테이너에 상기 하나 이상의 사용자 프로세스로서 실행하도록 허용되는, 방법.
제1항에 있어서,
전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하는 단계는 각각이 별도의 전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하는 상기 복수의 소프트웨어 컨테이너를 상기 커널 기반 격리 층 상에 구성하는 단계를 더 포함하는, 방법.
제9항에 있어서,
상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하는 단계는 상기 복수의 소프트웨어 컨테이너의 각각의 소프트웨어 컨테이너들에서 하나 이상의 사용자 프로세스의 별개의 세트들을 실행하는 단계를 더 포함하고, 상기 별개의 세트들 중 적어도 하나는 복수의 상이한 사용자 프로세스를 포함하는, 방법.
제10항에 있어서,
상기 복수의 소프트웨어 컨테이너의 제1 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 별개의 세트들의 제1 세트는 상기 복수의 소프트웨어 컨테이너의 제2 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 별개의 세트들의 제2 세트와 격리되는, 방법.
제1항에 있어서,
상기 소프트웨어 컨테이너를 구성하는 단계는 상기 라이브러리 운영 체제 및 상기 하나 이상의 사용자 프로세스가 사용자 모드로 실행되는 의사-가상화된 소프트웨어 컨테이너로서 상기 소프트웨어 컨테이너를 구성하는 단계를 포함하는, 방법.
제12항에 있어서,
상기 의사-가상화된 소프트웨어 컨테이너가 실행되는 상기 커널 기반 격리 층을 구현하는 단계는 상기 커널 기반 격리 층을 다른 표준 가상 기계 하이퍼바이저 또는 운영 체제 커널의 수정된 버전으로서 구현하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 소프트웨어 컨테이너를 구성하는 단계는 상기 라이브러리 운영 체제 및 상기 하나 이상의 사용자 프로세스가 하드웨어-지원 가상 기계 내에서 커널 모드로 실행되는 하드웨어-지원 가상화된 소프트웨어 컨테이너로서 상기 소프트웨어 컨테이너를 구성하는 단계를 포함하는, 방법.
제14항에 있어서,
상기 하드웨어-지원 가상화된 소프트웨어 컨테이너가 실행되는 상기 커널 기반 격리 층을 구현하는 단계는 상기 커널 기반 격리 층을 표준 가상 기계 하이퍼바이저 또는 운영 체제 커널로서 구현하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 커널 기반 격리 층은 및 상기 소프트웨어 컨테이너의 상기 라이브러리 운영 체제는 상이한 유형들의 각각의 제1 및 제2 운영 체제들을 사용하여 구현되는, 방법.
시스템으로서,
각각 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 처리 플랫폼을 포함하며;
상기 처리 플랫폼은:
커널 기반 격리 층을 구현하도록;
전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하도록; 그리고
상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하도록 구성되는, 시스템.
제17항에 있어서,
상기 처리 플랫폼은 각각의 상이한 테넌트에 상기 커널 기반 격리 층 상의 하나 이상의 소프트웨어 컨테이너의 상이한 세트들을 제공하도록 구성되며, 그러한 소프트웨어 컨테이너 각각은 전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하는, 시스템.
제17항에 있어서,
상기 처리 플랫폼은:
클라우드 기반 처리 플랫폼;
엔터프라이즈 처리 플랫폼;
사물 인터넷(IoT) 플랫폼; 및
네트워크 기능 가상화(NFV, Network Function Virtualization) 플랫폼
중 적어도 하나를 포함하는, 시스템.
하나 이상의 소프트웨어 프로그램의 프로그램 코드가 저장되어 있는 비일시적 프로세서-판독 가능 저장 매체를 포함하는 컴퓨터 프로그램 제품으로서, 상기 프로그램 코드는 각 처리 디바이스가 메모리에 연결되는 프로세서를 포함하는 복수의 처리 디바이스를 포함하는 처리 플랫폼에 의해 실행될 때, 상기 처리 플랫폼으로 하여금:
커널 기반 격리 층을 구현하게 하고;
전용 운영 체제 커널을 라이브러리 운영 체제로서 포함하도록 상기 커널 기반 격리 층 상에 소프트웨어 컨테이너를 구성하게 하며;
상기 소프트웨어 컨테이너에서 하나 이상의 사용자 프로세스를 실행하게 하는, 컴퓨터 프로그램 제품.
제20항에 있어서,
상기 라이브러리 운영 체제는 상기 소프트웨어 컨테이너에서 실행되는 상기 하나 이상의 사용자 프로세스의 권한 수준과 동일한 권한 수준으로 상기 소프트웨어 컨테이너에서 실행되는, 컴퓨터 프로그램 제품.
제20항에 있어서,
상기 라이브러리 운영 체제는 시스템 호출들을 대응하는 함수 호출들로 변환하는 것과 관련하여 상기 하나 이상의 사용자 프로세스의 바이너리들의 자동 변환을 지원하도록 구성되는, 컴퓨터 프로그램 제품.