요약

  • PlanetLab의 슬라이스(slice)는 수많은 노드의 자원 일부를 조합해 만든 네트워크 전역 컨테이너였다. 이는 서비스에 일관된 운영상의 정체성을 부여하면서도 어떤 물리적 기계의 소유권도 주지 않았다.
  • 제어는 계층화되어 있었다. 글로벌 서비스가 슬라이스를 요청하고 조합할 수 있었지만, 실제로 무엇이 실행되는지는 노드 관리자, 스케줄러, 호스트 정책과 로컬 승인 결정이 좌우했다.
  • 실험의 자유는 격리, 자원 회계, 책임 사슬과 결합되어 있었다. 글로벌 추상화는 외부 패킷이나 로컬 자원 비용이 여전히 특정 주체로 추적될 수 있을 때만 신뢰할 수 있었다.

하나의 계정은 여러 기계를 넘었지만, 소유권은 그렇지 않았다

2000년대 초반 인터넷 규모로 서비스를 테스트하려는 네트워크 연구자는 기술적 문제 이전에 사회적 문제에 직면했다. 동료들에게 계정을 빌려야 했고, 기계들은 서로 다른 기관에 흩어져 있었다. 세 대의 친절한 서버에서 잘 동작하던 프로그램도 긴 경로, 불균일한 부하, 자신의 저자를 전혀 모르는 호스트의 정책 앞에서 실패할 수 있었다.

PlanetLab은 이 비공식적 부탁 네트워크를 공유 인프라로 전환했다. 연구 그룹은 여러 사이트에 걸친 계정을 얻어 하나의 서비스를 그 위에 배포할 수 있었다. 프로젝트는 그 결과물을 슬라이스(slice)라고 불렀다.

이 단어는 정확했다. 2004년 운영체제 논문에서 서비스는 참여 노드 각각의 자원 중 일정 비율을 가상 머신 형태로 받았다. 이 로컬 가상 머신들이 하나의 복합 엔티티를 이루었다. 서비스의 관점에서 슬라이스는 분산된 사설 기계 집합처럼 보였다. 그러나 저자들은 그 '사적(私的)성'이 격리로 유지되는 일종의 환상이라고 명시했다. 어떤 기계도 소유자가 바뀌지 않았고, 어떤 캠퍼스도 자기 네트워크를 내놓지 않았으며, 어떤 글로벌 이름도 로컬 기여를 글로벌 재산으로 바꾸지 않았다.

이 구분은 추상화가 유용했기 때문에 쉽게 사라질 수 있다. 서비스 관리자는 슬라이스를 하나의 대상으로 다루고, 여기에 소프트웨어를 설치하고, 흩어진 구성 요소들을 하나의 배포로 취급할 수 있었다. 그러나 슬라이스는 숨겨진 슈퍼컴퓨터가 아니었다. 그것은 경계가 정해진 로컬 할당들의 조합이었다.

슬라이버(sliver)는 슬라이스 아래의 사실이었다

PlanetLab의 설계 어휘는 이 조합을 가시화했다. 가상 머신은 하나의 노드가 가진 CPU, 메모리, 저장소, 네트워크 용량의 일부를 소비했다. 이 로컬 부분이 슬라이버(sliver)였다. 슬라이스는 참여 노드들에 걸친 이 가상 머신들과 슬라이버들의 네트워크였다.

서비스의 상당 부분은 의도적으로 규정하지 않고 남겨 두었다. PlanetLab은 단일 오버레이 토폴로지를 강제하지 않았고, 모든 슬라이스에 하나의 언어나 런타임을 요구하지도 않았다. 연구자들이 평범한 인터넷 위에 자신만의 분산 서비스를 만들 수 있을 만큼의 로컬 메커니즘만 노출했다.

이는 단단한 하한선을 가진 자율성이었다. 슬라이스는 자신의 구성 요소들이 서로 통신하는 방식을 선택할 수 있었지만, 부하가 걸린 호스트에 새 CPU 사이클을 만들어 낼 수는 없었다. 자기 소프트웨어를 고를 수는 있었지만, 공유 기계에 대한 루트 권한을 스스로 부여할 수는 없었다. 여러 장소의 노드를 요청할 수는 있었지만, 오프라인 노드가 응답하게 만들 수는 없었다.

초기 설계 노트는 티켓(ticket)과 임대(lease)를 통해 이 구분을 표현했다. 티켓은 노드, 자원 양, 시간 창을 기술했다. 이를 제출하면 임대가 발생할 수 있었지만, 그것은 노드의 승인 정책에 따랐다. 이 노트는 완성된 문서가 아니라 계속 작성 중인 초안이었으며, 모든 PlanetLab 릴리스를 대표하는 시대를 초월한 설명은 아니었다. 그럼에도 그 헌법적 통찰은 명확하다. 글로벌 할당자는 청구권을 문 앞까지 가져갈 수 있지만, 마지막 운영 결정은 로컬 노드가 보유했다.

중앙은 조합했고, 노드들이 결정했다

PlanetLab은 완전한 분산화의 동화가 아니었다. 초기 아키텍처에는 PlanetLab Central이 포함되어 있었는데, 이는 선택된 각 기계의 노드 관리자에게 접촉하는 프런트 엔드였다. 노드 관리자가 로컬 가상 머신을 생성하고 제어했다. 특권 코드는 여전히 존재했고, 부트스트래핑은 교체 가능한 서비스들의 무한 회귀로 구현될 수 없었다.

동시에 노드들은 대학, 연구소, 기타 자율 조직에 속해 있었다. 2006년 경험 보고서는 이를 설계 요구 사항으로 만들었다. 각 조직은 자기 자원이 어떻게 사용되는지에 대한 일정 통제를 유지해야 했고, 플랫폼은 참여가 늘어나기를 원한다면 중앙 통제를 최소화해야 했다.

따라서 슬라이스는 모든 노드에서 권한 경계를 넘었다. 글로벌 뷰는 서비스가 프린스턴, 버클리 또는 그 밖의 장소에 구성 요소를 가져야 한다고 말할 수 있었다. 실제 실행은 해당 로컬 관리자, 자원 상태, 스케줄러, 호스트 한도에 달려 있었다. 낡은 글로벌 뷰가 용량이 없는 기계를 강제로 움직일 수는 없었다. 기록은 의도된 슬라이스를 기술했고, 실행 중인 코드가 실시간 상태를 드러냈다.

격리는 하나 이상의 역할을 했다

슬라이스를 '격리된' 것이라고 부르는 것은 여러 가지 다른 약속을 가릴 수 있었다. 자원 격리는 한 서비스의 CPU, 메모리, 디스크 또는 대역폭 사용이 다른 서비스에 과도한 피해를 주지 않도록 하려 했다. 보안 격리는 네임스페이스 간 간섭이나 슬라이스를 넘는 접근을 막으려 했다. 안정적인 프로그래밍 기반은 권한 없는 서비스가 이웃의 기반 기계 장치를 바꾸지 못하게 하려 했다.

이들은 서로 교환 가능하지 않았다. 서비스는 보안상 분리되어 있으면서도 혼잡한 노드에서 지연 시간이 요동칠 수 있었다. 예약 없이 공정한 CPU 몫만 받을 수도 있었다. 자기 VM 안에서는 정확하게 동작하면서도 호스트 대역폭 상한이 관측되는 처리량을 바꿔 놓을 수도 있었다.

운영 논문들은 이 격차에 대해 이례적으로 솔직했다. 처음에는 최선형(best effort)으로 충분하다고 여겨졌지만, 무거운 부하와 요동치는 성능은 그 가정을 비싸게 만들었다. PlanetLab은 공정 공유, 명시적 예약, 토큰 기반 스케줄링을 사용했다. 메모리 압박은 감시 프로그램이 큰 소비자를 재설정하는 원인이 될 수 있었다. 호스트 사이트는 아웃바운드 트래픽에 상한을 둘 수 있었다. 2006년의 한 실험에서는 74밀리초의 하위 경로가 특별한 CPU 조치 이전에는 76~135밀리초의 오버레이 왕복 시간으로 나타났다. 예약과 실시간 스케줄링이 격차 대부분을 좁혔지만, 커널 활동이나 모든 지터의 원인을 없애지는 못했다.

이 측정치는 플랫폼 전체에 대한 판정이 아니다. 그것은 슬라이스가 그 자체로 결코 약속하지 않은 것이 무엇인지 보여주는 근거다. 세계를 아우르는 네임스페이스가 세계 전용 자원을 만들어 주지는 않았다.

책임성은 실험 허가의 일부였다

PlanetLab의 사용자들은 자신이 속하지 않은 기관 내부의 기계에서, 실험에 자발적으로 동의하지 않은 네트워크를 향해 트래픽을 내보낼 수 있었다. 인터넷 매핑은 침입 경보를 촉발할 수 있었다. 처리량 테스트는 캠퍼스 게이트웨이의 용량을 소비할 수 있었다. 합법적인 연구조차 낯선 이들에게 비용을 물릴 수 있었다.

설계상의 대응은 단순히 더 많은 트래픽을 걸러내는 것이 아니었다. 2004년 논문은 자원 회계와 사후 행위 귀속을, 양만이 아니라 행위까지, 슬라이스 단위로 요구했다. 이후의 설계 원칙 논문은 책임 사슬을 기술했다. 외부에서 보이는 모든 활동은 슬라이스를 거쳐 책임 있는 사용자로 역추적되어야 했다.

이 사슬이 넓은 위임을 견딜 수 있게 만들었다. 호스트는 모든 연구자와 별도의 신뢰 관계를 맺을 필요가 없었다. 필요한 것은 강제 가능한 한도, 행동 뒤에 있는 주체를 식별하는 방법, 그리고 응답할 수 있는 당사자였다. 따라서 슬라이스는 자유의 경계이면서 동시에 증거의 경계였다.

사슬이 끊기면 글로벌 추상화는 위험해진다. 패킷은 여전히 노드를 떠나지만, 불만을 접수하는 기관은 어느 서비스가 보냈는지, 누구의 권한으로, 어떤 자원 할당 하에, 어떤 제어 경로를 통해 그랬는지 더 이상 말할 수 없다. 귀속 없는 격리는 프로세스를 보호하면서 책임을 버린다.

관리의 분리로 관리자는 교체 가능해졌다 — 어느 정도까지

PlanetLab의 두 번째 중요한 조치는 저수준 노드 메커니즘을 네트워크 전역 관리 서비스로부터 분리한 것이었다. 슬라이스 생성, 자원 발견, 모니터링, 소프트웨어 배포는 로컬 운영 기반 위에서 실행되는 서비스로 구현될 수 있었다. 하나의 영구적 특권 왕좌를 주는 대신, 여러 대안이 병행해서 진화할 수 있었다.

설계 원칙은 노드 운영체제에는 로컬 추상화만 남기고, 글로벌 추상화는 서비스를 통해 만들자는 것이었다. 특권 기반이 내보내는 인터페이스는 명시적이고 공유 가능해야 했다. 그것은 유일한 것으로 신뢰해야 하는 함수의 수를 줄였다.

그러나 이는 유일무이한 코어를 없애지는 못했다. 여전히 누군가는 로컬 VM을 만들고, 한도를 강제하고, 첫 서비스를 부트스트랩해야 했다. 저자들도 이를 인정했다. 의미 있는 성과는 권한 없는 인프라가 아니라, 더 작고 더 검사 가능한 권한 경계였다.

바로 여기에서 PlanetLab이 Lu Heng의 최소 초기 명세(Minimum Initial Specification)와 실행 코드 우선 원칙(Running-Code Primacy)에서 얻는 오늘날의 교훈과 만난다. 공통 계층은 안전한 조합에 필요한 로컬 불변 조건만 정의할 때 가장 건강하다. 더 넓은 서비스들은 경쟁하고, 바뀌고, 사라질 수 있다. 그들의 기록은 로컬 용량을 만들어 내는 권한을 획득하지 못하고, 그들의 글로벌 이름은 아래 기계들에 대한 소유권이 되지 못한다.

이것은 편집적 비교이며, PlanetLab 저자들이 Lu Heng의 후대 교리를 적용했다는 주장이 아니다. 역사적 기록은 그 자체로 서 있다.

PlanetLab은 클라우드를 예견했지만 미래를 소유하지는 않았다

프린스턴의 2026년 회고에 따르면 PlanetLab은 최종적으로 48개국 717개 사이트의 1,353개 노드에 이르렀고 2020년에 공식 종료되었다. Peterson 자신의 절제된 표현이 유용한 것이다. PlanetLab은 클라우드를 만들지는 않았지만, 클라우드를 예견했다.

그것은 사용자가 추상적 자원을 요청하고, 소프트웨어가 원격 기계들에 배포되며, 여러 테넌트가 물리적 용량을 공유하고, 서비스 아래의 운영체제보다 그 위에 노출되는 계약이 더 중요해지는 세상을 예견했다. 동시에 잘 닦인 클라우드 인터페이스가 감출 수 있는 질문들도 노출했다. 어느 로컬 기계가 자원을 부여했는가, 어느 정책이 거부할 수 있는가, 실제로 어떤 성능 등급이 할당되었는가, 누가 재설정할 수 있는가, 그리고 그 트래픽이 타인에게 해를 끼쳤을 때 누가 책임지는가?

PlanetLab을 가상 머신, 컨테이너, 콘텐츠 전송, 클라우드 오케스트레이션의 유일한 조상으로 만들어서는 안 된다. 그 역사들은 더 넓다. 이 프로젝트의 고유한 기여는 글로벌 자원 추상화를, 불균일한 부하 아래에서, 자율적인 소유자들 사이에서, 결과에 실제 외부인이 영향을 받는 가운데 공개적으로 작동하게 만든 것이다.

프로젝트는 끝났다. 그것이 명확히 한 문제는 끝나지 않았다. 타인의 인프라 위에 글로벌 객체를 제공하는 모든 플랫폼은 여전히 그 객체가 유효한 로컬 할당으로 구성되어 있음을, 로컬 거부가 여전히 가시적임을, 책임이 추상화 너머까지 살아 있음을 증명해야 한다.

Peterson의 역할은 협력적 시스템 안에 있다

Larry Peterson은 PlanetLab의 핵심 조직자, 설계자이자 운영자였으며, 프린스턴은 현재 그를 Robert E. Kahn 교수(Emeritus) 겸 선임 연구 학자로 명시하고 있다. 그러나 이 작업은 결코 그 혼자의 것이 아니었다.

2002년 청사진은 Tom Anderson, David Culler, Timothy Roscoe와 함께 쓰였다. 2004년 운영체제 논문에는 Andy Bavier, Mic Bowman, Brent Chun, David Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink, Mike Wawrzoniak이 이름을 올리고 있다. 2006년 경험 논문은 Peterson, Bavier, Marc E. Fiuczynski, Muir의 작품이다. 동적 슬라이스 노트는 Peterson과 Amin Vahdat이 편집하고 추가 기명 기여자가 있는 아키텍처 팀 문서였다.

이 집단적 기여 표기는 의례적이지 않다. PlanetLab의 주제 자체가 독립적인 사람들과 기관들이 한 명의 소유자가 되는 척하지 않고 시스템을 공유할 수 있는지였다. 그 저작 표기도 같은 사실을 보존해야 한다.

출처