Tupperware: Facebook의 Kubernetes 킬러?

Tupperware를 통해 모든 규모의 클러스터를 효율적이고 안정적으로 관리

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

Tupperware는 다양한 작업을 수행합니다. 애플리케이션 개발자는 이를 사용하여 애플리케이션을 제공하고 관리합니다. 애플리케이션 코드와 종속성을 이미지로 패키징하여 서버에 컨테이너로 전달합니다. 컨테이너는 동일한 서버에 있는 애플리케이션 간의 격리를 제공하므로 개발자는 애플리케이션 로직을 처리하고 서버를 찾거나 업데이트를 관리하는 것에 대해 걱정할 필요가 없습니다. 타파웨어는 서버 성능도 모니터링해 장애가 발견되면 문제가 있는 서버에서 컨테이너를 전송한다.

용량 계획 엔지니어는 Tupperware를 사용하여 예산 및 제약 조건에 따라 팀에 서버 용량을 할당합니다. 또한 이를 사용하여 서버 활용도를 향상시킵니다. 데이터 센터 운영자는 Tupperware를 사용하여 데이터 센터 전체에 컨테이너를 적절하게 배포하고 유지 관리 중에 컨테이너를 중지하거나 이동합니다. 덕분에 서버, 네트워크 및 장비를 유지 관리하려면 최소한의 인력 개입이 필요합니다.

타파웨어 아키텍처

Tupperware PRN 아키텍처는 데이터 센터의 영역 중 하나입니다. 이 지역은 근처에 위치한 여러 데이터 센터 건물(PRN1 및 PRN2)로 구성됩니다. 우리는 한 지역의 모든 서버를 관리하는 하나의 제어판을 만들 계획입니다.

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

Tupperware는 컨테이너 프로비저닝과 수명주기 관리를 담당합니다. 이는 여러 구성 요소로 구성됩니다.

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

타파웨어의 특징

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

• 상태 저장 서비스에 대한 기본 지원이 제공됩니다.
• 다양한 데이터 센터의 서버를 위한 단일 제어판으로 의도에 따라 컨테이너 제공, 클러스터 폐기 및 유지 관리를 자동화합니다.
• 확대/축소를 위한 제어판 분할이 명확합니다.
• 탄력적 컴퓨팅을 사용하면 실시간으로 서비스 간에 전력을 분배할 수 있습니다.

우리는 거대한 글로벌 공유 서버 전체에서 다양한 상태 비저장 및 상태 저장 애플리케이션을 지원하기 위해 이러한 멋진 기능을 개발했습니다.

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

Tupperware는 Facebook, Instagram, Messenger 및 WhatsApp에 대한 지속적인 제품 데이터를 저장하는 다양하고 중요한 상태 저장 서비스를 운영합니다. 이는 키-값 쌍의 대규모 저장소일 수 있습니다(예: ZippyDB) 및 모니터링 데이터 저장소(예: ODS 고릴라 и 자 급식 수중 호흡 장치). 상태 저장 서비스를 유지하는 것은 쉽지 않습니다. 시스템은 컨테이너 공급이 네트워크 중단이나 정전을 포함한 대규모 중단을 견딜 수 있도록 보장해야 하기 때문입니다. 장애 도메인 전체에 컨테이너를 배포하는 것과 같은 기존 기술은 상태 비저장 서비스에 적합하지만 상태 저장 서비스에는 추가 지원이 필요합니다.

예를 들어, 서버 오류로 인해 하나의 데이터베이스 복제본을 사용할 수 없는 경우 50개 풀에서 10개 서버의 코어를 업데이트하는 자동 유지 관리를 활성화해야 합니까? 상황에 따라 다릅니다. 50개 서버 중 하나에 동일한 데이터베이스의 또 다른 복제본이 있는 경우 한 번에 2개의 복제본을 잃지 않고 기다리는 것이 좋습니다. 시스템 유지 관리 및 성능에 대한 결정을 동적으로 내리려면 내부 데이터 복제 및 각 상태 저장 서비스의 배치 논리에 대한 정보가 필요합니다.

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

Tupperware의 많은 상태 저장 서비스는 TaskControl을 직접 사용하지 않고 Facebook에서 상태 저장 서비스를 생성하기 위한 공통 플랫폼인 ShardManager를 통해 사용합니다. Tupperware를 사용하면 개발자는 컨테이너를 데이터 센터 전체에 배포하는 방법에 대한 의도를 정확하게 지정할 수 있습니다. ShardManager를 사용하여 개발자는 데이터 샤드를 컨테이너 전체에 배포하는 방법에 대한 의도를 지정합니다. ShardManager는 애플리케이션의 데이터 배치 및 복제를 인식하고 TaskControl 인터페이스를 통해 Tupperware와 통신하여 애플리케이션의 직접적인 개입 없이 컨테이너 작업을 예약합니다. 이러한 통합으로 상태 저장 서비스 관리가 크게 단순화되지만 TaskControl은 그 이상을 수행할 수 있습니다. 예를 들어 광범위한 웹 계층은 상태 비저장이며 TaskControl을 사용하여 컨테이너 업데이트 속도를 동적으로 조정합니다. 결국 웹 계층은 여러 소프트웨어 릴리스를 신속하게 완료할 수 있습니다. 가용성을 저하시키지 않고 매일.

데이터 센터의 서버 관리

2011년 Tupperware가 처음 출시되었을 때 각 서버 클러스터는 별도의 스케줄러로 관리되었습니다. 당시 Facebook 클러스터는 하나의 네트워크 스위치에 연결된 서버 랙 그룹이었으며 데이터 센터에는 여러 클러스터가 있었습니다. 스케줄러는 하나의 클러스터에 있는 서버만 관리할 수 있습니다. 즉, 작업이 여러 클러스터에 분산될 수 없습니다. 인프라가 성장하고 클러스터가 점점 더 많이 삭제되었습니다. Tupperware는 변경 없이는 폐기된 클러스터에서 다른 클러스터로 작업을 이동할 수 없었기 때문에 애플리케이션 개발자와 데이터 센터 운영자 간의 많은 노력과 세심한 조정이 필요했습니다. 이 프로세스로 인해 폐기 절차로 인해 서버가 몇 달 동안 유휴 상태였을 때 리소스가 낭비되었습니다.

클러스터 폐기 문제를 해결하고 다른 유형의 유지 관리 작업을 조정하기 위해 리소스 브로커를 만들었습니다. 리소스 브로커는 서버와 관련된 모든 물리적 정보를 추적하고 각 서버를 제어하는 ​​스케줄러를 동적으로 결정합니다. 서버를 스케줄러에 동적으로 연결하면 스케줄러가 다른 데이터 센터의 서버를 관리할 수 있습니다. Tupperware 작업은 더 이상 단일 클러스터로 제한되지 않으므로 Tupperware 사용자는 컨테이너를 장애 도메인에 배포하는 방법을 지정할 수 있습니다. 예를 들어 개발자는 특정 가용성 영역을 지정하지 않고도 자신의 의도를 선언할 수 있습니다(예: "PRN 지역의 2개 장애 도메인에서 내 작업 실행"). Tupperware 자체는 클러스터나 서비스가 폐기되더라도 이러한 의도를 구현하는 데 적합한 서버를 찾습니다.

전체 글로벌 시스템을 지원하도록 확장 가능

역사적으로 우리 인프라는 개별 팀을 위한 수백 개의 전용 서버 풀로 나누어졌습니다. 단편화와 표준 부족으로 인해 운영 비용이 높았고 유휴 서버를 다시 사용하기가 더 어려웠습니다. 작년 컨퍼런스에서 시스템 @Scale 우리는 제시 서비스형 인프라(IaaS), 이는 우리의 인프라를 대규모 단일 서버 파크로 통합해야 합니다. 그러나 단일 서버 파크에는 고유한 어려움이 있습니다. 특정 요구 사항을 충족해야 합니다.

• 확장성. 각 지역에 데이터 센터를 추가하면서 인프라가 성장했습니다. 서버가 더 작아지고 에너지 효율성이 높아짐에 따라 각 지역에 더 많은 서버가 있습니다. 결과적으로 지역당 단일 스케줄러는 각 지역의 수십만 대 서버에서 실행될 수 있는 컨테이너 수를 처리할 수 없습니다.
• 신뢰성. 스케줄러를 그만큼 확장할 수 있더라도 스케줄러의 범위가 크다는 것은 오류 위험이 더 높고 전체 컨테이너 영역을 관리할 수 없게 될 수 있음을 의미합니다.
• 결함 허용. 대규모 인프라 오류(예: 네트워크 오류 또는 정전으로 인해 스케줄러를 실행하는 서버 오류)가 발생하는 경우 부정적인 결과는 해당 지역의 일부 서버에만 영향을 미칩니다.
• 사용 편의성. 한 지역에 대해 여러 개의 독립적인 스케줄러를 실행해야 하는 것처럼 보일 수 있습니다. 그러나 편의성 측면에서 볼 때 지역의 공유 풀에 대한 단일 진입점이 있으면 용량과 작업을 더 쉽게 관리할 수 있습니다.

대규모 공유 풀을 유지하는 문제를 해결하기 위해 스케줄러를 샤드로 나누었습니다. 각 스케줄러 샤드는 해당 지역의 자체 작업 세트를 관리하므로 스케줄러와 관련된 위험이 줄어듭니다. 공유 풀이 커지면 더 많은 스케줄러 샤드를 추가할 수 있습니다. Tupperware 사용자의 경우 샤드와 스케줄러 프록시는 하나의 제어판처럼 보입니다. 작업을 조정하는 여러 개의 샤드를 사용하여 작업할 필요가 없습니다. 스케줄러 샤드는 네트워크 토폴로지에 따라 서버의 공유 풀을 정적으로 나누지 않고 제어판을 분할했던 이전에 사용했던 클러스터 스케줄러와 근본적으로 다릅니다.

탄력적 컴퓨팅으로 사용 효율성 향상

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

• 탄력적 컴퓨팅 - 조용한 시간 동안 온라인 서비스를 축소하고 기계 학습 및 MapReduce 작업과 같은 오프라인 작업을 위해 여유 서버를 사용합니다.
• 오버로드 - 일괄 작업 부하가 낮은 우선 순위로 실행되도록 온라인 서비스와 일괄 작업 부하를 동일한 서버에 배치합니다.

데이터 센터의 병목 현상은 다음과 같습니다. 에너지 소비. 따라서 우리는 더 많은 처리 능력을 제공하는 작고 에너지 효율적인 서버를 선호합니다. 불행하게도 CPU와 메모리가 거의 없는 소규모 서버에서는 오버로드가 덜 효과적입니다. 물론 프로세서 리소스와 메모리를 거의 소비하지 않는 에너지 효율적인 소형 서버 하나에 소규모 서비스 컨테이너 여러 개를 배치할 수 있지만, 이 상황에서는 대규모 서비스의 성능이 저하됩니다. 따라서 우리는 대규모 서비스 개발자에게 전체 서버를 사용할 수 있도록 최적화할 것을 권장합니다.


기본적으로 탄력적 컴퓨팅을 활용하여 사용 효율성을 향상시킵니다. 뉴스피드, 메시징 기능, 프런트엔드 웹 계층 등 당사의 주요 서비스 중 다수는 시간대에 따라 다릅니다. 우리는 조용한 시간 동안 의도적으로 온라인 서비스를 축소하고 기계 학습 및 MapReduce 작업과 같은 오프라인 작업을 위해 확보된 서버를 사용합니다.

대규모 서비스는 탄력적 용량의 주요 제공자이자 주요 소비자이며 전체 서버를 사용하도록 최적화되어 있기 때문에 전체 서버를 탄력적 용량 단위로 프로비저닝하는 것이 가장 좋다는 것을 경험을 통해 알고 있습니다. 서버가 조용한 시간 동안 온라인 서비스에서 해제되면 리소스 브로커는 서버를 스케줄러에 임대하여 오프라인 작업을 실행합니다. 온라인 서비스에 최대 부하가 발생하면 리소스 브로커는 빌린 서버를 신속하게 회수하고 스케줄러와 함께 이를 온라인 서비스로 반환합니다.

교훈과 앞으로의 계획

지난 8년간 우리는 페이스북의 급속한 성장에 발맞추기 위해 Tupperware를 개발해왔습니다. 우리는 우리가 배운 내용을 공유하고 이것이 빠르게 성장하는 인프라를 다른 사람들이 관리하는 데 도움이 되기를 바랍니다.

• 제어판과 제어판이 관리하는 서버 사이에 유연한 연결을 설정하세요. 이러한 유연성을 통해 제어판은 다양한 데이터 센터의 서버를 관리할 수 있고, 클러스터의 폐기 및 유지 관리를 자동화하는 데 도움이 되며, 탄력적인 컴퓨팅을 사용하여 동적 용량 할당이 가능해집니다.
• 해당 지역에 단일 제어판을 사용하면 작업 작업이 더욱 편리해지고 대규모 공유 서버군을 관리하기가 더 쉬워집니다. 규모나 내결함성 문제로 인해 내부 구조가 분리되어 있어도 제어판은 단일 진입점을 유지합니다.
• 플러그인 모델을 사용하면 제어판에서 향후 컨테이너 작업을 외부 애플리케이션에 알릴 수 있습니다. 또한 상태 저장 서비스는 플러그인 인터페이스를 사용하여 컨테이너 관리를 맞춤화할 수 있습니다. 이 플러그인 모델을 사용하면 제어판이 단순성을 제공하는 동시에 다양한 상태 저장 서비스를 효율적으로 제공합니다.
• 우리는 일괄 작업, 기계 학습 및 기타 긴급하지 않은 서비스를 위해 제공자 서비스에서 전체 서버를 가져오는 탄력적 컴퓨팅이 작고 에너지 효율적인 서버의 효율성을 향상시키는 최적의 방법이라고 믿습니다.

우리는 이제 막 구현을 시작했습니다. 단일 글로벌 공유 서버 함대. 현재 우리 서버의 약 20%가 공유 풀에 있습니다. 100%를 달성하려면 공유 스토리지 풀 유지 관리, 유지 관리 자동화, 테넌트 간 요구 사항 관리, 서버 활용도 향상, 기계 학습 워크로드 지원 개선 등 많은 문제를 해결해야 합니다. 우리는 이러한 도전을 받아들이고 성공을 공유하고 싶습니다.

출처 : habr.com