본 논문은 쿠버네티스의 전신인 Borg System 논문이다.

오늘의 요약

• 즉 구글은 수 십만 개의 잡을 돌리는 클러스터 매니저인 Borg를 개발했다.
• 해당 잡 들은 수 천개의 서로 다른 애플리케이션에서 발생하는데
  • 이들이 어떻게 관리되는지 시스템 유저(서비스 개발자)는 알 필요 없이 Borg System을 만들었다.
    • 자원 관리에 대한 세부 사항 (CPU, Memory, Disk, Network 할당 등)
    • 어느 컴퓨터에서 개발된 서비스가 동작할지
    • 실패되어도 다시 살아난다. (Self Healing)
    • 실패 처리를 유저가 직접하지 않아도 된다.
• 구글은 이러한 시스템을 만들기 위해 구글이 실행하는 서비스를 두 가지로 분류했다.
  • Long Running Services
    • End User에게 제공되는 Production
      • GMail, Google Search, Google Docs, 그리고 구글 내부의 BigTable 등
    • 즉 절대 죽어서는 안되는, 수 µs ~ 몇백 ms 라는 짧은 latency를 가져 사용자에게 불편함을 주면 안되는 서비스
    • 매우 많은 리소스를 사용한다.
    • 쉽게 말해 Production Level
  • Batch Jobs
    • 짧게는 수 초, 길게는 수 일 동안 작업되는 서비스
    • 단기적 성능 변동에 훨씬 덜 민감하다.
    • 쉽게 말해 Non-Production Level
• 해당 작업을 수행하는 머신들은 Cell이라 불리는 곳에 저장된다.
  • 셀 안에 많은 머신이 포함되며, 해당 머신들은 고성능 데이터 센터 규모로 정의된 단일 클러스터에 포함된다.
    • 단일 클러스터에 속하는 머신들은
      • High Performance, Datacenter Scale Network 구조로 정의
      • 해당 클러스터는 단일 데이터센터 빌딩에 존재하고, 이러한 빌딩들의 집합이 site를 만든다.
      • 클러스터는 일반적으로 하나의 거대한 셀의 주인이고(hosts)
        • 몇 개의
          • 작은 스케일의 테스트를 갖거나
          • 특수 목적 셀을 가진다.
      • Single Point of Failure를 피한다.
    • 중간 사이즈의 셀들은
      • 테스트 셀을 제외하고 대략 1만대 이상의 머신을 가지는데, 몇 몇은 더 큰 규모를 가진다.
      • 해당 머신들은 서로 이질적인 많은 디멘션을 가지는데,
        • CPU, RAM, Network, Disk 등
        • Processor Type, Performance, 외부 IP 주소 등
  • 놀랍게도 Borg System은 이러한 차이점 및 특징을 시스템 사용자(개발자 등)에게 철저히 숨겨 개발자들이 본연의 업무(개발)에만 집중할 수 있도록 한다.

Abstract

• 구글의 Borg 시스템은 수 십만 개의 잡을 돌리는 클러스터 매니저다.
  • 해당 잡 들은 수 천 개의 서로 다른 애플리케이션으로 부터 발생하는데
  • 해당 애플리케이션은 수 만 개의 머신에서 동작한다.
• Borg 시스템은 High Utilization을 달성하는데
  • 제어 허용(admission control), 효율적인 작업 패킹, 과다 할당(over commitment to machine), 그리고 프로세스 레벨의 성능 격리를 통한 머신 공유(자원 공유)
  • 를 조합하여 사용함으로써
• Bog 시스템은 고가용성 runtime 애플리케이션을 지원한다.
  • Fault Recovery 시간을 최소화하고
  • 관련있는 실패할 가능성을 줄이는 스케줄링 정책을 수립함으로써
• Borg 시스템은 사용자의 삶을 단순화한다.
  • Declarative Job Specification Language, Name Service 통합, 실시간 작업 모니터링 및 시스템 동작을 분석하고 시뮬레이션하는 도구를 제공하여
• 우리는 Borg System의 아키텍처와 Features, 중요한 디자인 결정, Borg System의 몇몇 정책 결정에 대한 질적인 분석, 10년간의 운영 경험에서 얻은 교훈에 대한 질적 교훈을 제시한다.

1. Introduction

• Borg System이라 부르는 클러스터 관리 시스템은
  • 관리하고, 스케줄하고, 시작하고, 재시작하고, 그리고 모니터링한다.
  • 구글이 실행하는 모든 애플리케이션의 Full Range로부터
• 해당 본문은 이것이 어떻게 되는지 설명한다.
• Borg는 세 가지 주요 장점을 제공한다.
  • 자원 관리에 대한 세부 사항과 실패 처리와 관련된 세부 사항을 숨김으로써, 유저는 애플리케이션 개발에 집중할 수 있다.
  • 매우 높은 신뢰성과 가용성을 바탕으로 동작하며, Borg에서 관리되는 애플리케이션 또한 이를 제공받는다.
  • 수만 대의 시스템에서 워크로드를 효율적으로 실행할 수 있도록 한다.
• Borg는 이러한 이슈를 제기한 첫 번째 시스템이 아니다.
  • 하지만 Borg와 같이 큰 스케일, 탄력성과 완전성,에서 실행되는 것은 몇 없다.
• 해당 논문은 이러한 주제를 중심으로 구성되어 있으며
• 10년 이상 프로덕션 환경에서 Borg를 운영하면서 얻은 일련의 정성적 관찰로 결론을 내린다.

2. The User Perspective

• Borg 시스템의 유저는 구글의 개발자와 시스템 관리자(Site Reliability Engineers)다.
  • 구글의 애플리케이션과 서비스들을 실행하는
• 사용자들은 그들의 일을 Borg의 jobs 폼에 맞춰 제출한다.
  • jobs: 하나 이상의 tasks로 구성
  • tasks: 모두 동일한 바이너리 프로그램을 실행
• 각각의 job은 Borg Cell에서 실행되는데
  • Borg Cell은 하나의 유닛처럼 관리되는 머신의 집합이다.
• 본 단락에서 중요한 것은 Borg가 유저에게 어떻게 노출되느냐다.
  • 유저 관점에서 Borg를 어떻게 사용하는지

2.1 The Workload

• Borg Cells는 두 개의 이질적인 주요 파트에서 실행된다.
• 첫 번 째는, “절대로” 죽어서는 안되고, 수 µs ~ 몇백 ms 라는 짧은 latency를 가지는, Long Running Services다.
  • Gmail, Google Docs, Web Search와 같이 End User에게 제공되는 Product들, 그리고 구글 내부의 인프라 서비스(Big Table) 등이 그 예다.
• 두 번 째는, 수 초 ~ 수 일 안에 완료되는 batch jobs다.
  • 이러한 작업은 단기적인 성능 변동에 훨씬 덜 민감하다.
• 워크로드 혼합은 Borg Cell 마다 다르며
  • Borg Cell은 다양한 애플리케이션의 혼합을 실행하는데
    • 애플리케이션은 작업에 따라 다르다. (주요 테넌트에 따라 다양한 애플리케이션 혼합을 실행)
      • 예: 일부 셀은 배치 집약적임
    • 또한 실행 시간에 따라 다르다.
    • 예를 들어
      • 배치 작업은 빠른 시간 안에 실행 되었다가 종료되고
      • End User Facing(Proudcts)는 주간 사용 패턴을 보인다. (오래 사용)
• Borg 시스템은 이들 케이스 모두를 동일하게 잘 처리할 필요가 있다.
• 대표적인 Borg workload는 2011년 5월부터 월 단위 추적이 가능한데, 이는 매우 잘 광범위하게 분석되었다.
• 많은 애플리케이션 프레임워크는 Borg의 Top에서 만들어졌다.
  • Internal Map Reducing System, Flume Java, Millwhell, Pregel 등
• 이들 대부분은 컨트롤러를 가지고 있는데
  • master job 과 하나 이상의 워커 잡을 제출한다.
  • 이들은 YARN의 어플리케이션 매니저와 비슷하다.
    • https://blog.cloudera.com/apache-hadoop-yarn-concepts-and-applications/
    • https://sungsoo.github.io/2014/02/28/yarn-concepts-and-applications.html
• 구글의 분산 저장소 시스템, GFS, CFS, Bigtable, Megastore 모두 Borg에서 동작한다.
• 본 문단에서 명시하는 것은
  • workload를 두 가지로 분류 가능한데
  • production 레벨
    • Long Running Services
  • non-production 레벨
    • Batch Jobs
• 대표적인 셀에
  • production 레벨의 잡은 70% 정도의 CPU, 55%의 메모리를 할당받았으며
    • 이 중 60%, 85% 를 사용중이다.
  • 나머지를 non-production이 할당 및 사용
  • 이 실제 할당량과 사용량의 불일치는 5.5단락에서 자세하게 설명된다.

2.2 Clusters and Cells

셀의 머신은 이를 연결하는 고성능 데이터 센터 규모의 네트워크 패브릭으로 정의된 단일 클러스터에 속한다.

• 단일 클러스터에 속하는 셀의 머신들은
  • High Performance, Datacenter Scale Network 구조로 정의되는데
  • 해당 클러스터는 단일 데이터센터 빌딩에 존재하고, 이러한 빌딩들의 집합이 site를 만든다.
  • 클러스터는 일반적으로 하나의 거대한 셀의 주인이고(hosts)
    • 몇 개의
      • 작은 스케일의 테스트를 갖거나
      • 특수 목적 셀을 가진다.
  • 우리는 몇 개의 단일 실패 지점을 피한다.
• 우리의 중간 셀의 사이즈는 테스트 셀을 제외하여 대략 1만대의 머신의 크기인데
  • 몇 몇은 훨씬 더 크다.
  • 해당 머신들은 이질적인, 많은 디멘션에 속하는데
    • CPU, RAM, Disk, Network의 크기가 다르거나
    • processor type이 다르거나
    • performance가 다르거나
    • Flash Storage 혹은 외부 IP 주소 등 능력이 다르거나
• Borg 시스템은 이러한 차이점 대부분으로부터 사용자를 격리한다.(사용자는 신경쓸 필요 없다.)
  • 셀에서 작업을 실행할 위치를 결정하고
  • 리소스를 할당하고
  • 프로그램 및 기타 종속성을 설치하고
  • 상태를 모니터링하고
  • 실패할 경우 다시 시작하는 등