터퍼웨어: 페이스북의 쿠버네티스 '킬러'?

Tupperware를 사용하면 어떤 규모에서든 효율적이고 안정적인 클러스터 관리가 가능합니다.

오늘에 시스템 @Scale 컨퍼런스 저희는 거의 모든 서비스를 구동하는 수백만 대의 서버에 걸쳐 컨테이너를 관리하는 클러스터 관리 시스템인 Tupperware를 도입했습니다. 2011년에 Tupperware를 처음 도입한 이후, 저희 인프라는 꾸준히 성장해 왔습니다. 1개의 데이터 센터 전체까지 15개의 지리적으로 분산된 데이터 센터. 이 모든 시간 동안 Tupperware는 가만히 있지 않고 우리와 함께 발전해 왔습니다. Tupperware가 어떤 상황에서 최상의 클러스터 관리 기능을 제공하는지 알려드리겠습니다. 여기에는 편리한 상태 저장 서비스 지원, 모든 데이터 센터를 위한 단일 제어판, 그리고 서비스 간 실시간 용량 분배 기능이 포함됩니다. 또한 인프라가 발전하면서 얻은 교훈도 공유하겠습니다.

터퍼웨어는 다양한 기능을 제공합니다. 애플리케이션 개발자가 애플리케이션을 배포하고 관리하는 데 사용됩니다. 애플리케이션 코드와 종속성을 이미지로 패키징하여 컨테이너 형태로 서버에 배포합니다. 컨테이너는 단일 서버에서 애플리케이션 간 격리를 제공하여 개발자가 서버 검색이나 업데이트 관리에 신경 쓰지 않고 애플리케이션 로직에 집중할 수 있도록 합니다. 또한 터퍼웨어는 서버 상태를 모니터링하고, 장애가 감지되면 문제가 있는 서버에서 컨테이너를 마이그레이션합니다.

용량 계획자는 Tupperware를 사용하여 예산 및 제약 조건에 따라 팀에 서버 용량을 할당합니다. 또한 서버 활용도를 높이는 데에도 Tupperware를 사용합니다. 데이터 센터 운영자는 Tupperware를 사용하여 데이터 센터에 컨테이너를 적절하게 분배하고 유지 관리 중에 컨테이너를 중지하거나 이동합니다. 이를 통해 서버, 네트워크 및 하드웨어 유지 관리에 필요한 인력을 최소화할 수 있습니다.

터퍼웨어 아키텍처

Tupperware Architecture PRN은 저희 데이터 센터 지역 ​​중 하나입니다. 이 지역은 인근에 위치한 여러 데이터 센터 건물(PRN1과 PRN2)로 구성되어 있습니다. 저희는 한 지역의 모든 서버를 관리하는 단일 제어판을 구축할 계획입니다.

애플리케이션 개발자는 터퍼웨어(Tupperware) 작업 형태로 서비스를 제공합니다. 작업은 여러 컨테이너로 구성되며, 일반적으로 모든 컨테이너는 동일한 애플리케이션 코드를 실행합니다.

터퍼웨어는 용기를 할당하고 수명 주기를 관리하는 역할을 합니다. 터퍼웨어는 다음과 같은 여러 구성 요소로 이루어져 있습니다.

• Tupperware 프런트엔드는 Tupperware와 상호 작용할 수 있는 UI, CLI 및 기타 자동화 도구에 대한 API를 제공합니다. Tupperware 작업의 소유자에게는 모든 내부 구조가 숨겨집니다.
• 터퍼웨어 스케줄러는 컨테이너와 작업의 수명 주기를 관리하는 제어 평면입니다. 지역 및 글로벌 단위로 배포되며, 지역 스케줄러는 단일 지역의 서버를 관리하고 글로벌 스케줄러는 여러 지역의 서버를 관리합니다. 스케줄러는 샤드(shard)로 나뉘며, 각 샤드는 일련의 작업을 관리합니다.
• Tupperware의 스케줄러 프록시는 내부 분할을 숨기고 Tupperware 사용자에게 편리한 단일 제어판을 제공합니다.
• Tupperware 할당자는 컨테이너를 서버에 할당합니다. 스케줄러는 컨테이너 중지, 시작, 업데이트 및 장애 조치를 처리합니다. 현재 단일 할당자는 샤딩 없이 전체 리전을 관리할 수 있습니다. (용어의 차이에 유의하세요. 예를 들어, Tupperware의 스케줄러는 Kubernetes그리고 Tupperware 배포자는 Kubernetes에서 스케줄러라고 불립니다.)
• 리소스 브로커는 서버 및 서비스 이벤트의 진실 출처를 보유합니다. 데이터 센터당 하나의 리소스 브로커를 운영하며, 해당 데이터 센터 내 서버에 대한 모든 정보를 보유합니다. 리소스 브로커와 용량 관리 시스템(또는 리소스 할당 시스템)은 어떤 스케줄러가 어떤 서버를 관리할지 동적으로 결정합니다. 상태 점검 서비스는 서버를 모니터링하고 리소스 브로커에 상태 데이터를 보관합니다. 서버에 문제가 발생하거나 유지 관리가 필요한 경우, 리소스 브로커는 할당자와 스케줄러에게 컨테이너를 중지하거나 다른 서버로 마이그레이션하도록 지시합니다.
• 터퍼웨어 에이전트는 각 서버에서 실행되는 데몬으로, 컨테이너의 프로비저닝 및 삭제를 처리합니다. 애플리케이션은 컨테이너 내부에서 실행되므로 격리성과 재현성이 더욱 향상됩니다. 작년의 Systems @Scale 컨퍼런스 우리는 이미 이미지, btrfs, cgroupv2 및 systemd를 사용하여 개별 Tupperware 컨테이너를 만드는 방법을 설명했습니다.

터퍼웨어의 특징

Tupperware는 Kubernetes와 같은 다른 클러스터 관리 시스템과 여러 면에서 유사합니다. 메 소스하지만 차이점도 있습니다.

• 상태 저장 서비스에 대한 기본 제공 지원.
• 데이터 센터 전반의 서버를 위한 단일 제어판을 통해 의도 기반 컨테이너 전달, 클러스터 해체 및 유지 관리를 자동화합니다.
• 확장성을 높이기 위해 제어판을 명확하게 분리했습니다.
• 탄력적 컴퓨팅을 사용하면 실시간으로 여러 서비스에 걸쳐 용량을 분산할 수 있습니다.

우리는 전 세계적으로 공유되는 방대한 서버군에서 다양한 상태 저장 및 비상태 저장 애플리케이션을 지원하기 위해 이러한 멋진 기능을 구축했습니다.

상태 저장 서비스에 대한 기본 제공 지원.

터퍼웨어는 Facebook, Instagram, Messenger, WhatsApp의 지속적인 제품 데이터를 저장하는 다양한 중요 상태 저장 서비스를 실행합니다. 이러한 서비스는 키-값 쌍(예: 지피DB) 및 모니터링 데이터 저장소(예: ODS 고릴라 и 자 급식 수중 호흡 장치). 상태 저장 서비스를 지원하는 것은 어려운 일입니다. 시스템은 네트워크 중단이나 정전을 포함한 대규모 장애 발생 시에도 컨테이너 공급이 안정적으로 유지될 수 있도록 보장해야 하기 때문입니다. 장애 도메인에 컨테이너를 분산하는 것과 같은 일반적인 기법은 상태 비저장 서비스에 적합하지만, 상태 저장 서비스에는 추가적인 지원이 필요합니다.

예를 들어, 서버 장애로 데이터베이스 복제본 하나를 사용할 수 없게 된 경우, 50개의 서버 풀에서 10대의 서버에 커널을 업데이트하는 자동 유지 관리를 활성화해야 할까요? 상황에 따라 다릅니다. 50대의 서버 중 하나에 동일한 데이터베이스의 복제본이 하나 더 있는 경우, 두 개의 복제본을 동시에 잃지 않도록 기다리는 것이 좋습니다. 유지 관리 및 시스템 상태에 대한 동적 결정을 내리려면 각 상태 저장 서비스의 내부 데이터 복제 및 배치 로직을 알아야 합니다.

TaskControl 인터페이스는 상태 저장 서비스가 데이터 가용성에 영향을 미치는 결정에 영향을 미칠 수 있도록 합니다. 스케줄러는 이 인터페이스를 사용하여 외부 애플리케이션에 컨테이너 작업(재시작, 업그레이드, 마이그레이션, 유지 관리)에 대한 알림을 보냅니다. 상태 저장 서비스는 Tupperware에 각 작업을 수행하기에 안전한 시점을 알려주는 컨트롤러를 구현하며, 이러한 작업은 교체되거나 일시적으로 연기될 수 있습니다. 위 예에서 데이터베이스 컨트롤러는 Tupperware에 49대의 서버 중 50대를 업그레이드하도록 지시하지만, 특정 서버(X)에는 현재로서는 접근하지 않도록 지시할 수 있습니다. 따라서 커널 업그레이드 기한이 지났는데도 데이터베이스가 문제가 있는 복제본을 복원할 수 없는 경우, Tupperware는 서버 X를 업그레이드합니다.

Tupperware의 많은 상태 저장 서비스는 TaskControl을 간접적으로 사용하지만, Facebook에서 상태 저장 서비스를 구축하는 데 공통으로 사용되는 플랫폼인 ShardManager를 통해 사용합니다. Tupperware를 사용하면 개발자는 컨테이너를 데이터 센터에 어떻게 분산할지에 대한 의도를 지정할 수 있습니다. ShardManager를 사용하면 개발자는 데이터 샤드를 컨테이너에 어떻게 분산할지에 대한 의도를 지정할 수 있습니다. ShardManager는 애플리케이션의 데이터 배치 및 복제를 인식하고 TaskControl 인터페이스를 통해 Tupperware와 통신하여 애플리케이션에 직접 관여하지 않고도 컨테이너 작업을 예약합니다. 이러한 통합은 상태 저장 서비스 관리를 크게 간소화하지만, TaskControl은 더 많은 작업을 수행할 수 있습니다. 예를 들어, 광범위한 웹 계층은 상태 비저장이며 TaskControl을 사용하여 컨테이너의 업데이트 속도를 동적으로 조정합니다. 요약하자면 웹 계층은 여러 소프트웨어 릴리스를 빠르게 실행할 수 있습니다. 가용성에 영향을 주지 않고 하루에 한 번씩.

데이터 센터의 서버 관리

2011년 Tupperware가 처음 출시되었을 당시 각 서버 클러스터는 별도의 스케줄러로 관리되었습니다. 당시 Facebook 클러스터는 단일 네트워크 스위치에 연결된 서버 랙 그룹이었고, 데이터 센터는 여러 클러스터를 수용했습니다. 스케줄러는 단일 클러스터의 서버만 관리할 수 있었기 때문에 하나의 작업이 여러 클러스터에 걸쳐 분산될 수 없었습니다. 인프라가 확장됨에 따라 클러스터를 점점 더 자주 해체했습니다. Tupperware는 해체된 클러스터의 작업을 수정 없이 다른 클러스터로 옮길 수 없었기 때문에 애플리케이션 개발자와 데이터 센터 운영자 간의 많은 노력과 신중한 협력이 필요했습니다. 해체 절차로 인해 서버가 수개월 동안 유휴 상태로 유지되면서 리소스 낭비가 발생했습니다.

클러스터 해체 문제를 해결하고 다른 유형의 유지 관리 작업을 조정하기 위해 리소스 브로커를 개발했습니다. 리소스 브로커는 서버와 관련된 모든 물리적 정보를 추적하고 각 서버를 관리할 스케줄러를 동적으로 결정합니다. 서버를 스케줄러에 동적으로 연결하면 스케줄러가 여러 데이터 센터에 있는 서버를 관리할 수 있습니다. 터퍼웨어 작업이 더 이상 단일 클러스터에 국한되지 않으므로, 터퍼웨어 사용자는 컨테이너를 장애 도메인에 어떻게 분산할지 지정할 수 있습니다. 예를 들어, 개발자는 특정 가용 영역을 지정하지 않고도 인텐트(예: "PRN 지역의 두 장애 도메인에서 작업 실행")를 선언할 수 있습니다. 터퍼웨어는 클러스터 해체 또는 유지 관리가 발생하는 경우에도 이 인텐트를 충족하는 데 적합한 서버를 자동으로 찾습니다.

전체 글로벌 시스템을 지원하기 위한 확장

전통적으로 저희 인프라는 개별 팀을 위한 수백 개의 전용 서버 풀로 분산되어 왔습니다. 이러한 분산화와 표준 부재로 인해 높은 운영 비용이 발생했고, 유휴 서버를 다시 가동하는 데 어려움을 겪었습니다. 작년 컨퍼런스에서 시스템 @Scale 우리는 제시 서비스로서의 인프라(IaaS), 이는 우리 인프라를 대규모 단일 서버 파크로 통합해야 합니다. 하지만 단일 서버 파크는 그 자체로 복잡한 구조를 가지고 있습니다. 다음과 같은 특정 요구 사항을 충족해야 합니다.

• 확장성. 각 지역에 데이터 센터를 추가하면서 인프라가 확장되었습니다. 서버는 더 작아지고 에너지 효율이 높아져 각 지역에 훨씬 더 많은 서버가 배치되었습니다. 결과적으로, 각 지역당 하나의 스케줄러로는 각 지역의 수십만 대 서버에서 실행할 수 있는 컨테이너 수를 감당할 수 없게 되었습니다.
• 신뢰성. 스케줄러의 규모를 이 정도까지 늘릴 수 있다 하더라도 스케줄러의 범위가 넓어서 오류가 발생할 가능성이 더 높고 컨테이너의 전체 영역을 관리할 수 없게 될 수도 있습니다.
• 결함 허용. 대규모 인프라에 장애가 발생하는 경우(예: 네트워크 고장이나 정전, 스케줄러가 실행되는 서버에 장애가 발생하는 경우) 부정적인 결과는 해당 지역의 일부 서버에만 영향을 미칩니다.
• 사용 편의성. 지역별로 여러 개의 독립적인 스케줄러를 실행해야 할 것처럼 보일 수 있습니다. 하지만 편의성 측면에서 볼 때, 지역 내 공통 풀에 대한 단일 진입점은 용량 및 작업 관리를 간소화합니다.

대규모 공유 풀을 유지하는 데 따르는 어려움을 해결하기 위해 스케줄러를 샤드로 분할했습니다. 각 스케줄러 샤드는 리전에서 자체 작업 세트를 관리하여 스케줄러 관련 위험을 줄이는 데 도움이 됩니다. 공유 풀이 커짐에 따라 스케줄러 샤드를 더 추가할 수 있습니다. 터퍼웨어 사용자에게 스케줄러 샤드와 프록시는 단일 제어판처럼 보입니다. 작업을 조정하는 여러 샤드를 관리할 필요가 없습니다. 스케줄러 샤드는 이전에 사용했던 클러스터 스케줄러와 근본적으로 다릅니다. 이전에는 제어판이 분할되었지만, 네트워크 토폴로지에 따라 서버 공유 풀을 정적으로 분할하지 않았습니다.

탄력적 컴퓨팅을 통한 활용 효율성 향상

인프라 규모가 클수록 인프라 비용을 최적화하고 부하를 줄이기 위해 서버를 효율적으로 사용하는 것이 더욱 중요합니다. 서버 효율성을 높이는 두 가지 방법이 있습니다.

• 탄력적 컴퓨팅 - 조용한 시간에는 온라인 서비스를 축소하고, 여유로운 서버를 머신 러닝 및 MapReduce 작업과 같은 오프라인 작업에 활용합니다.
• 오버로딩 - 온라인 서비스와 배치 워크로드를 동일한 서버에 배치하여 배치 워크로드가 낮은 우선순위로 실행되도록 합니다.

우리 데이터 센터의 병목 현상은 다음과 같습니다. 에너지 소비. 그렇기 때문에 저희는 더 높은 컴퓨팅 성능을 제공하는 작고 에너지 효율적인 서버를 선호합니다. 하지만 CPU와 메모리가 부족한 소형 서버에서는 오버로딩이 효과적이지 않습니다. 물론 CPU와 메모리를 적게 사용하는 작고 에너지 효율적인 서버 하나에 여러 개의 작은 서비스 컨테이너를 호스팅할 수도 있지만, 이 경우 대규모 서비스의 성능은 저하됩니다. 따라서 저희는 대규모 서비스 개발자에게 전체 서버를 활용할 수 있도록 최적화할 것을 권장합니다.


저희는 주로 탄력적 컴퓨팅을 통해 활용도를 향상시킵니다. 뉴스 피드, 메시징, 프런트엔드 웹 티어와 같은 대규모 서비스의 경우, 시간대에 따라 사용률이 달라집니다. 한산한 시간에는 온라인 서비스 규모를 의도적으로 축소하고, 여유 공간을 확보한 서버를 머신 러닝 및 맵리듀스 작업과 같은 오프라인 워크로드에 활용합니다.

경험상, 대규모 서비스는 탄력적 용량의 가장 큰 기부자이자 소비자이며, 전체 서버를 사용하도록 최적화되어 있기 때문에 전체 서버를 탄력적 용량 단위로 프로비저닝하는 것이 가장 효과적입니다. 서버가 한산한 시간에 온라인 서비스에서 해제되면 리소스 브로커는 해당 서버를 스케줄러에 대여하여 오프라인 워크로드를 실행합니다. 온라인 서비스에 최대 사용량이 발생하면 리소스 브로커는 대여된 서버를 신속하게 회수하여 스케줄러와 함께 온라인 서비스로 반환합니다.

얻은 교훈과 미래를 위한 계획

지난 8년 동안 저희는 페이스북의 급속한 성장에 발맞춰 터퍼웨어를 발전시켜 왔습니다. 빠르게 성장하는 인프라를 관리하는 데 도움이 되기를 바라며, 저희가 얻은 지식을 공유하고자 합니다.

• 제어판과 관리하는 서버 간의 유연한 통신을 구성합니다. 이러한 유연성을 통해 제어판은 여러 데이터 센터의 서버를 관리하고, 클러스터의 해체 및 유지 관리를 자동화하며, 탄력적 컴퓨팅을 통해 동적 용량 할당을 구현할 수 있습니다.
• 지역에 단일 제어판이 있으면 작업 처리가 더 쉬워지고 대규모 공유 서버 파크를 관리하기가 더 쉬워집니다. 확장성이나 장애 허용을 위해 내부 구조가 분리되어 있더라도 제어판은 단일 진입점을 지원합니다.
• 플러그인 모델을 사용하여 제어판은 컨테이너에서 예정된 작업을 외부 애플리케이션에 알릴 수 있습니다. 또한, 상태 저장 서비스는 플러그인 인터페이스를 사용하여 컨테이너 관리를 사용자 지정할 수 있습니다. 이 플러그인 모델을 통해 제어판은 다양한 상태 저장 서비스를 효율적으로 제공하는 동시에 간소화된 환경을 제공합니다.
• 우리는 일괄 작업, 머신 러닝 및 기타 긴급하지 않은 서비스를 위해 도너 서비스에서 전체 서버를 떼어내는 탄력적 컴퓨팅이 작고 에너지 효율적인 서버를 보다 효과적으로 활용하는 최적의 방법이라고 믿습니다.

우리는 이제 막 그것을 구현하기 시작했습니다. 단일 글로벌 공유 서버 파크현재 저희 서버의 약 20%가 공유 풀에 있습니다. 100%에 도달하려면 스토리지 시스템 공유 풀 지원, 유지 관리 자동화, 멀티 테넌트 요구 사항 관리, 서버 활용도 향상, 머신 러닝 워크로드 지원 개선 등 해결해야 할 과제가 많습니다. 이러한 과제를 해결하고 진행 상황을 공유하게 되어 기쁩니다.

출처 : habr.com