🥇Kubernetes 모험 Dailymotion: 클라우드 + 온프레미스에서 인프라 구축

메모. 번역: Dailymotion은 세계 최대의 비디오 호스팅 서비스 중 하나이므로 주목할만한 Kubernetes 사용자입니다. 이 자료에서 시스템 설계자 David Donchez는 GKE의 클라우드 설치로 시작하여 응답 시간을 단축하고 인프라 비용을 절감할 수 있는 하이브리드 솔루션으로 끝난 K8s를 기반으로 회사의 프로덕션 플랫폼을 만든 결과를 공유합니다.

핵심 API 재구축 결정 Dailymotion XNUMX년 전, 우리는 애플리케이션을 호스팅하고 더 쉽게 만들 수 있는 보다 효율적인 방법을 개발하고 싶었습니다. 개발 및 생산 과정. 이를 위해 우리는 컨테이너 오케스트레이션 플랫폼을 사용하기로 결정했고 자연스럽게 쿠버네티스를 선택하게 되었습니다.

Kubernetes를 기반으로 자체 플랫폼을 구축하는 것이 왜 가치가 있습니까?

Google Cloud를 사용하여 즉시 프로덕션 수준 API 제공

2016년 여름

XNUMX년 전 데일리모션을 인수한 직후 비벤디, 우리 엔지니어링 팀은 완전히 새로운 Dailymotion 제품을 만드는 하나의 글로벌 목표에 집중하고 있습니다.

컨테이너, 오케스트레이션 솔루션 및 과거 경험에 대한 분석을 바탕으로 우리는 Kubernetes가 올바른 선택이라고 확신합니다. 일부 개발자는 이미 기본 개념을 이해하고 이를 사용하는 방법을 알고 있었는데, 이는 인프라 전환에 큰 이점이었습니다.

인프라 관점에서 새로운 유형의 클라우드 네이티브 애플리케이션을 호스팅하려면 강력하고 유연한 시스템이 필요했습니다. 우리는 마음의 평화를 갖고 가능한 가장 강력한 온프레미스 플랫폼을 구축할 수 있도록 여정 초기에 클라우드를 유지하기로 결정했습니다. 우리는 조만간 자체 데이터 센터로 이동하여 하이브리드 전략을 적용할 것이라는 것을 알고 있었지만 Google Kubernetes Engine을 사용하여 애플리케이션을 배포하기로 결정했습니다.

GKE를 선택한 이유는 무엇인가요?

우리는 주로 기술적인 이유로 이러한 선택을 했습니다. 또한 회사의 비즈니스 요구 사항을 충족하는 인프라를 신속하게 제공해야 했습니다. 지리적 분산, 확장성, 내결함성 등 애플리케이션 호스팅에 대한 몇 가지 요구 사항이 있었습니다.

Dailymotion의 GKE 클러스터

Dailymotion은 전 세계적으로 사용 가능한 비디오 플랫폼이기 때문에 대기 시간을 줄여 서비스 품질을 향상시키고 싶었습니다. (숨어 있음). 이전에 우리의 API 파리에서만 이용할 수 있었는데, 이는 차선책이었습니다. 저는 유럽뿐만 아니라 아시아와 미국에서도 애플리케이션을 호스팅할 수 있기를 원했습니다.

대기 시간에 대한 이러한 민감성은 플랫폼의 네트워크 아키텍처에서 심각한 작업을 수행해야 함을 의미했습니다. 대부분의 클라우드 서비스에서는 각 지역에 자체 네트워크를 만든 다음 VPN이나 일종의 관리형 서비스를 통해 연결해야 했지만, Google Cloud를 사용하면 모든 Google 지역을 포괄하는 완전히 라우팅 가능한 단일 네트워크를 만들 수 있었습니다. 이는 시스템의 운영 및 효율성 측면에서 큰 장점입니다.

또한 Google Cloud의 네트워크 서비스와 부하 분산기도 탁월한 성능을 발휘합니다. 이를 통해 각 지역의 임의 공용 IP 주소를 사용할 수 있으며, 훌륭한 BGP 프로토콜이 나머지 작업을 처리합니다(예: 사용자를 가장 가까운 클러스터로 리디렉션). 분명히 장애가 발생하는 경우 트래픽은 사람의 개입 없이 자동으로 다른 지역으로 이동됩니다.

Google 부하 분산 모니터링

우리 플랫폼은 또한 GPU를 많이 사용합니다. Google Cloud를 사용하면 Kubernetes 클러스터에서 직접 매우 효과적으로 사용할 수 있습니다.

당시 인프라 팀은 주로 물리적 서버에 배포된 레거시 스택에 중점을 두었습니다. 이것이 바로 관리형 서비스(Kubernetes 마스터 포함)를 사용하여 요구 사항을 충족하고 팀이 로컬 클러스터를 사용하도록 교육할 수 있었던 이유입니다.

그 결과, 작업 시작 후 불과 6개월 만에 Google Cloud 인프라에서 프로덕션 트래픽 수신을 시작할 수 있었습니다.

그러나 여러 가지 장점에도 불구하고 클라우드 공급자와 협력하면 특정 비용이 발생하며 이는 로드에 따라 증가할 수 있습니다. 이것이 바로 우리가 사용한 각 관리형 서비스를 주의 깊게 분석하여 향후 온프레미스 구현을 희망하는 이유입니다. 실제로 2016년 말부터 로컬 클러스터 구현이 시작됐고, 동시에 하이브리드 전략도 시작됐다.

로컬 컨테이너 오케스트레이션 플랫폼 Dailymotion 출시

2016년 가을

전체 스택이 프로덕션 준비가 되어 있고 API 작업을 하는 조건에서 계속 갔다, 이제는 지역 클러스터에 집중할 때였습니다.

당시 사용자들은 매달 3억 개 이상의 동영상을 시청하고 있었습니다. 물론 우리는 수년 동안 자체적인 광범위한 콘텐츠 전달 네트워크를 보유해 왔습니다. 우리는 이러한 상황을 활용하고 기존 데이터 센터에 Kubernetes 클러스터를 배포하고 싶었습니다.

Dailymotion의 인프라는 2,5개 데이터 센터에 XNUMX개 이상의 서버로 구성되었습니다. 모두 Saltstack을 사용하여 구성됩니다. 우리는 마스터 및 워커 노드는 물론 etcd 클러스터를 생성하는 데 필요한 모든 레시피를 준비하기 시작했습니다.

네트워크 부분

우리 네트워크는 완전히 라우팅되었습니다. 각 서버는 Exabgp를 사용하여 네트워크에 자신의 IP를 광고합니다. 우리는 여러 네트워크 플러그인을 비교했으며 (사용된 L3 접근 방식으로 인해) 모든 요구 사항을 충족하는 유일한 플러그인은 다음과 같습니다. 옥양목. 이는 기존 네트워크 인프라 모델에 완벽하게 들어맞습니다.

우리는 사용 가능한 모든 인프라 요소를 사용하고 싶었기 때문에 가장 먼저 해야 할 일은 자체 개발한 네트워크 유틸리티(모든 서버에서 사용됨)를 파악하는 것이었습니다. 이를 사용하여 Kubernetes 노드가 있는 네트워크에서 IP 주소 범위를 광고했습니다. Calico가 IP 주소를 포드에 할당하도록 허용했지만 네트워크 장비의 BGP 세션에는 이를 사용하지 않았으며 여전히 사용하지 않습니다. 실제로 라우팅은 Calico에서 사용하는 서브넷을 알리는 Exabgp에 의해 처리됩니다. 이를 통해 내부 네트워크(특히 로드 밸런서)에서 모든 포드에 연결할 수 있습니다.

수신 트래픽을 관리하는 방법

들어오는 요청을 원하는 서비스로 리디렉션하기 위해 Kubernetes 수신 리소스와의 통합으로 인해 Ingress Controller를 사용하기로 결정했습니다.

XNUMX년 전, nginx-ingress-controller는 가장 성숙한 컨트롤러였습니다. Nginx는 오랫동안 사용되어 왔으며 안정성과 성능으로 유명했습니다.

우리 시스템에서는 전용 10기가비트 블레이드 서버에 컨트롤러를 배치하기로 결정했습니다. 각 컨트롤러는 해당 클러스터의 kube-apiserver 엔드포인트에 연결되었습니다. 또한 이 서버는 Exabgp를 사용하여 공용 또는 개인 IP 주소를 광고했습니다. 우리의 네트워크 토폴로지를 사용하면 이러한 컨트롤러의 BGP를 사용하여 NodePort와 같은 서비스를 사용하지 않고도 모든 트래픽을 포드로 직접 라우팅할 수 있습니다. 이 접근 방식은 노드 간의 수평 트래픽을 방지하고 효율성을 높이는 데 도움이 됩니다.

인터넷에서 포드로의 트래픽 이동

이제 하이브리드 플랫폼을 이해했으므로 트래픽 마이그레이션 프로세스 자체에 대해 더 자세히 알아볼 수 있습니다.

Google Cloud에서 Dailymotion 인프라로 트래픽 마이그레이션

2018년 가을

거의 XNUMX년간의 구축, 테스트, 조정 끝에 마침내 일부 트래픽을 수용할 수 있는 전체 Kubernetes 스택이 완성되었습니다.

현재 라우팅 전략은 매우 간단하지만 요구 사항을 충족하기에 충분합니다. 공개 IP(Google Cloud 및 Dailymotion) 외에도 AWS Route 53은 정책을 설정하고 사용자를 선택한 클러스터로 리디렉션하는 데 사용됩니다.

Route 53을 사용한 라우팅 정책 예시

Google Cloud를 사용하면 모든 클러스터에서 단일 IP를 공유하고 사용자가 가장 가까운 GKE 클러스터로 리디렉션되므로 이 작업이 쉽습니다. 클러스터의 경우 IP가 다르기 때문에 기술이 다릅니다.

마이그레이션 중에 지역 요청을 적절한 클러스터로 리디렉션하고 이 접근 방식의 이점을 평가했습니다.

GKE 클러스터는 커스텀 측정항목을 사용하여 자동 확장되도록 구성되어 있으므로 수신 트래픽에 따라 확장/축소됩니다.

일반 모드에서는 모든 지역 트래픽이 로컬 클러스터로 전달되고 GKE는 문제 발생 시 예비 역할을 합니다(상태 확인은 Route 53에서 수행됨).

...

앞으로 우리는 라우팅 정책을 완전히 자동화하여 사용자의 접근성을 지속적으로 향상시키는 자율 하이브리드 전략을 달성하고자 합니다. 긍정적인 측면으로는 클라우드 비용이 크게 감소하고 API 응답 시간도 단축되었습니다. 우리는 결과 클라우드 플랫폼을 신뢰하며 필요한 경우 더 많은 트래픽을 해당 플랫폼으로 리디렉션할 준비가 되어 있습니다.

번역가의 추신

Kubernetes에 관한 또 다른 최근 Dailymotion 게시물에 관심이 있으실 수도 있습니다. 많은 Kubernetes 클러스터에서 Helm을 사용하여 애플리케이션을 배포하는 데 전념하고 있습니다. 게시되었습니다. 약 일 개월 전.

블로그에서도 읽어보세요.

출처 : habr.com

Kubernetes 모험 Dailymotion: 클라우드 + 온프레미스에서 인프라 구축