🥇Tinder를 Kubernetes로 전환

메모. 번역: 세계적으로 유명한 Tinder 서비스의 직원은 최근 인프라를 Kubernetes로 마이그레이션하는 데 대한 몇 가지 기술적 세부 사항을 공유했습니다. 이 프로세스는 거의 8년이 걸렸으며 그 결과 200개의 컨테이너에서 호스팅되는 48개의 서비스로 구성된 KXNUMXs에서 매우 대규모 플랫폼이 출시되었습니다. Tinder 엔지니어들은 어떤 흥미로운 어려움에 직면했고 어떤 결과를 얻었습니까? 이 번역을 읽어보세요.

이유는 무엇입니까?

거의 XNUMX년 전 Tinder는 플랫폼을 Kubernetes로 이전하기로 결정했습니다. Kubernetes를 사용하면 Tinder 팀이 불변 배포를 통해 최소한의 노력으로 컨테이너화하고 프로덕션으로 이동할 수 있습니다. (불변 배포). 이 경우 애플리케이션 어셈블리, 배포 및 인프라 자체는 코드로 고유하게 정의됩니다.

확장성과 안정성 문제에 대한 해결책도 찾고 있었습니다. 확장이 중요해졌을 때 새로운 EC2 인스턴스가 가동될 때까지 몇 분 정도 기다려야 하는 경우가 많았습니다. 컨테이너를 시작하고 몇 분이 아닌 몇 초 만에 트래픽 서비스를 시작한다는 아이디어가 우리에게 매우 매력적이었습니다.

그 과정은 어려운 것으로 판명되었습니다. 2019년 초 마이그레이션 중에 Kubernetes 클러스터가 임계 질량에 도달했고 트래픽 볼륨, 클러스터 크기 및 DNS로 인해 다양한 문제가 발생하기 시작했습니다. 그 과정에서 우리는 200개의 서비스를 마이그레이션하고 1000개의 노드, 15000개의 포드 및 48000개의 실행 중인 컨테이너로 구성된 Kubernetes 클러스터를 유지하는 것과 관련된 많은 흥미로운 문제를 해결했습니다.

어떻게해야합니까?

2018년 XNUMX월부터 다양한 마이그레이션 단계를 거쳤습니다. 우리는 모든 서비스를 컨테이너화하고 이를 Kubernetes 테스트 클라우드 환경에 배포하는 것부터 시작했습니다. XNUMX월부터 우리는 모든 기존 서비스를 Kubernetes로 체계적으로 마이그레이션하기 시작했습니다. 다음 해 XNUMX월까지 우리는 마이그레이션을 완료했으며 이제 Tinder 플랫폼은 Kubernetes에서만 실행됩니다.

Kubernetes용 이미지 빌드

우리는 Kubernetes 클러스터에서 실행되는 마이크로서비스를 위한 30개 이상의 소스 코드 저장소를 보유하고 있습니다. 이러한 리포지토리의 코드는 동일한 언어에 대한 여러 런타임 환경을 갖춘 다양한 언어(예: Node.js, Java, Scala, Go)로 작성됩니다.

빌드 시스템은 각 마이크로서비스에 대해 완전히 사용자 정의 가능한 "빌드 컨텍스트"를 제공하도록 설계되었습니다. 일반적으로 Dockerfile과 셸 명령 목록으로 구성됩니다. 해당 콘텐츠는 완전히 사용자 정의 가능하며 동시에 이러한 모든 빌드 컨텍스트는 표준화된 형식에 따라 작성됩니다. 빌드 컨텍스트를 표준화하면 하나의 단일 빌드 시스템이 모든 마이크로서비스를 처리할 수 있습니다.

그림 1-1. Builder 컨테이너를 통한 표준화된 빌드 프로세스

런타임 간 일관성을 최대화하려면 (런타임 환경) 개발 및 테스트 중에 동일한 빌드 프로세스가 사용됩니다. 우리는 매우 흥미로운 과제에 직면했습니다. 전체 플랫폼에서 빌드 환경의 일관성을 보장할 수 있는 방법을 개발해야 했습니다. 이를 달성하기 위해 모든 조립 공정은 특수 컨테이너 내부에서 수행됩니다. 건축업자.

그의 컨테이너 구현에는 고급 Docker 기술이 필요했습니다. Builder는 비공개 Tinder 저장소에 액세스하는 데 필요한 로컬 사용자 ID와 비밀(예: SSH 키, AWS 자격 증명 등)을 상속합니다. 빌드 아티팩트를 자연스럽게 저장하기 위해 소스가 포함된 로컬 디렉터리를 마운트합니다. 이 접근 방식을 사용하면 Builder 컨테이너와 호스트 간에 빌드 아티팩트를 복사할 필요가 없으므로 성능이 향상됩니다. 추가 구성 없이 저장된 빌드 아티팩트를 재사용할 수 있습니다.

일부 서비스의 경우 컴파일 환경을 런타임 환경에 매핑하기 위해 또 다른 컨테이너를 만들어야 했습니다. 예를 들어 Node.js bcrypt 라이브러리는 설치 중에 플랫폼별 바이너리 아티팩트를 생성합니다. 컴파일 프로세스 중에 요구 사항은 서비스마다 다를 수 있으며 최종 Dockerfile은 즉시 컴파일됩니다.

Kubernetes 클러스터 아키텍처 및 마이그레이션

클러스터 크기 관리

우리는 사용하기로 결정했습니다 kube-aws Amazon EC2 인스턴스에 자동화된 클러스터 배포를 위한 것입니다. 처음에는 모든 것이 하나의 공통 노드 풀에서 작동했습니다. 우리는 리소스를 보다 효율적으로 사용하려면 크기와 인스턴스 유형별로 워크로드를 분리해야 한다는 필요성을 빠르게 깨달았습니다. 여러 개의 로드된 멀티 스레드 포드를 실행하는 것이 다수의 단일 스레드 포드와 공존하는 것보다 성능 측면에서 더 예측하기 쉽다는 논리가 있었습니다.

결국 우리는 다음과 같이 결정했습니다.

m5.4x 큰 - 모니터링용(프로메테우스)
c5.4x 큰 - Node.js 워크로드용(단일 스레드 워크로드)
c5.2x 큰 - Java 및 Go(멀티스레드 워크로드)용
c5.4x 큰 — 제어판용(노드 3개).

마이그레이션

기존 인프라에서 Kubernetes로 마이그레이션하기 위한 준비 단계 중 하나는 서비스 간의 기존 직접 통신을 새로운 로드 밸런서(ELB(Elastic Load Balancer))로 리디렉션하는 것이었습니다. Virtual Private Cloud(VPC)의 특정 서브넷에서 생성되었습니다. 이 서브넷은 Kubernetes VPC에 연결되었습니다. 이를 통해 서비스 종속성의 특정 순서를 고려하지 않고 모듈을 점진적으로 마이그레이션할 수 있었습니다.

이러한 엔드포인트는 각각의 새로운 ELB를 가리키는 CNAME이 있는 가중치가 부여된 DNS 레코드 세트를 사용하여 생성되었습니다. 전환하기 위해 가중치가 0인 Kubernetes 서비스의 새 ELB를 가리키는 새 항목을 추가했습니다. 그런 다음 항목의 TTL(Time To Live)을 0으로 설정했습니다. 그 후 이전 및 새 가중치는 다음과 같습니다. 천천히 조정되었고 결국 로드의 100%가 새 서버로 전송되었습니다. 전환이 완료된 후 TTL 값이 보다 적절한 수준으로 돌아왔습니다.

우리가 보유한 Java 모듈은 낮은 TTL DNS에 대처할 수 있었지만 Node 애플리케이션은 그렇지 못했습니다. 엔지니어 중 한 명이 연결 풀 코드의 일부를 다시 작성하여 60초마다 풀을 업데이트하는 관리자에 래핑했습니다. 선택한 접근 방식은 눈에 띄는 성능 저하 없이 매우 잘 작동했습니다.

레슨

네트워크 패브릭의 한계

8년 2019월 XNUMX일 이른 아침, Tinder 플랫폼이 예기치 않게 충돌했습니다. 그날 아침 일찍 플랫폼 지연 시간이 관련 없이 증가함에 따라 클러스터의 포드 및 노드 수가 증가했습니다. 이로 인해 모든 노드에서 ARP 캐시가 소진되었습니다.

ARP 캐시와 관련된 세 가지 Linux 옵션이 있습니다.

(출처)

gc_thresh3 - 이것은 엄격한 제한입니다. 로그에 "이웃 테이블 오버플로" 항목이 나타나는 것은 동기 GC(가비지 수집) 후에도 인접 항목을 저장할 공간이 ARP 캐시에 충분하지 않음을 의미합니다. 이 경우 커널은 단순히 패킷을 완전히 폐기했습니다.

우리는 사용 플란넬 Kubernetes의 네트워크 패브릭으로 사용됩니다. 패킷은 VXLAN을 통해 전송됩니다. VXLAN은 L2 네트워크 위에 올려진 L3 터널입니다. 이 기술은 MAC-in-UDP(MAC Address-in-User Datagram Protocol) 캡슐화를 사용하며 레이어 2 네트워크 세그먼트의 확장을 허용합니다. 실제 데이터 센터 네트워크의 전송 프로토콜은 IP와 UDP입니다.

그림 2-1. 플란넬 다이어그램(출처)

그림 2-2. VXLAN 패키지(출처)

각 Kubernetes 작업자 노드는 더 큰 /24 블록의 /9 마스크를 사용하여 가상 주소 공간을 할당합니다. 각 노드에 대해 이는 방법 라우팅 테이블에 항목 하나, ARP 테이블에 항목 하나(flannel.1 인터페이스), 스위칭 테이블(FDB)에 항목 하나. 작업자 노드가 처음 시작될 때 또는 새 노드가 검색될 때마다 추가됩니다.

추가적으로 node-pod(또는 pod-pod) 통신은 궁극적으로 인터페이스를 통해 이루어집니다. eth0 (위의 플란넬 다이어그램에 표시된 대로) 그러면 각 해당 소스 및 대상 호스트에 대한 ARP 테이블에 추가 항목이 생성됩니다.

우리 환경에서는 이러한 유형의 의사소통이 매우 일반적입니다. Kubernetes의 서비스 객체의 경우 ELB가 생성되고 Kubernetes는 각 노드를 ELB에 등록합니다. ELB는 포드에 대해 아무것도 모르며 선택한 노드가 패킷의 최종 목적지가 아닐 수도 있습니다. 요점은 노드가 ELB로부터 패킷을 수신할 때 규칙을 고려한다는 것입니다. iptables에 특정 서비스에 대해 다른 노드의 포드를 무작위로 선택합니다.

장애 당시 클러스터에는 605개의 노드가 있었습니다. 위에서 언급한 이유로 인해 이 정도면 중요성을 극복하기에 충분했습니다. gc_thresh3, 이는 기본값입니다. 이런 일이 발생하면 패킷이 삭제되기 시작할 뿐만 아니라 /24 마스크가 있는 전체 Flannel 가상 주소 공간이 ARP 테이블에서 사라집니다. 노드-팟 통신 및 DNS 쿼리가 중단됩니다(DNS는 클러스터에서 호스팅됩니다. 자세한 내용은 이 문서의 뒷부분을 참조하세요).

이 문제를 해결하려면 값을 늘려야 합니다. gc_thresh1, gc_thresh2 и gc_thresh3 누락된 네트워크를 다시 등록하려면 Flannel을 다시 시작하세요.

예상치 못한 DNS 확장

마이그레이션 프로세스 중에 DNS를 적극적으로 사용하여 트래픽을 관리하고 서비스를 기존 인프라에서 Kubernetes로 점진적으로 이전했습니다. Route53에서는 관련 RecordSet에 대해 상대적으로 낮은 TTL 값을 설정했습니다. 이전 인프라가 EC2 인스턴스에서 실행 중이었을 때 해석기 구성은 Amazon DNS를 가리켰습니다. 우리는 이를 당연한 것으로 여겼고 낮은 TTL이 우리 서비스와 Amazon 서비스(예: DynamoDB)에 미치는 영향은 거의 눈에 띄지 않았습니다.

서비스를 Kubernetes로 마이그레이션하면서 DNS가 초당 250만 개의 요청을 처리하고 있음을 발견했습니다. 그 결과, 애플리케이션에서 DNS 쿼리에 대한 지속적이고 심각한 시간 초과가 발생하기 시작했습니다. 이는 DNS 공급자를 CoreDNS(최대 로드 시 1000개의 코어에서 실행되는 120개의 포드에 도달)로 최적화하고 전환하려는 엄청난 노력에도 불구하고 발생했습니다.

다른 가능한 원인과 해결책을 조사하던 중 우리는 발견했습니다. статью, 패킷 필터링 프레임워크에 영향을 미치는 경쟁 조건을 설명합니다. 넷 필터 리눅스에서. 우리가 관찰한 시간 초과와 카운터 증가 insert_failed Flannel 인터페이스의 결과는 기사의 결과와 일치했습니다.

이 문제는 소스 및 대상 네트워크 주소 변환(SNAT 및 DNAT) 단계와 후속 테이블 입력 단계에서 발생합니다. 협곡. 내부적으로 논의되고 커뮤니티에서 제안된 해결 방법 중 하나는 DNS를 작업자 노드 자체로 이동하는 것이었습니다. 이 경우:

트래픽이 노드 내부에 유지되므로 SNAT는 필요하지 않습니다. 인터페이스를 통해 라우팅할 필요는 없습니다. eth0.
대상 IP가 노드에 로컬이고 규칙에 따라 무작위로 선택된 포드가 아니기 때문에 DNAT가 필요하지 않습니다. iptables에.

우리는 이 접근 방식을 고수하기로 결정했습니다. CoreDNS는 Kubernetes에서 DaemonSet으로 배포되었으며 우리는 Kubernetes에서 로컬 노드 DNS 서버를 구현했습니다. resolve.conf 플래그를 설정하여 각 포드 --클러스터-DNS 팀 Kubelet . 이 솔루션은 DNS 시간 초과에 효과적인 것으로 나타났습니다.

그러나 여전히 패킷 손실이 발생하고 카운터가 증가했습니다. insert_failed 플란넬 인터페이스에서. DNS 트래픽에 대해서만 SNAT 및/또는 DNAT를 제거할 수 있었기 때문에 해결 방법이 구현된 후에도 이러한 현상이 계속되었습니다. 다른 유형의 트래픽에 대해서는 경쟁 조건이 유지되었습니다. 다행히 대부분의 패킷은 TCP이므로 문제가 발생하면 간단히 재전송됩니다. 우리는 여전히 모든 유형의 트래픽에 적합한 솔루션을 찾으려고 노력하고 있습니다.

더 나은 로드 밸런싱을 위해 Envoy 사용

백엔드 서비스를 Kubernetes로 마이그레이션하면서 Pod 간의 로드 불균형으로 어려움을 겪기 시작했습니다. 우리는 HTTP Keepalive로 인해 각 배포가 출시된 첫 번째 준비된 포드에서 ELB 연결이 중단되는 것을 발견했습니다. 따라서 대부분의 트래픽은 사용 가능한 작은 비율의 포드를 통과했습니다. 우리가 테스트한 첫 번째 솔루션은 최악의 시나리오에 대한 새로운 배포에서 MaxSurge를 100%로 설정하는 것이었습니다. 대규모 배포 측면에서 그 효과는 미미하고 전망이 좋지 않은 것으로 나타났습니다.

우리가 사용한 또 다른 솔루션은 중요한 서비스에 대한 리소스 요청을 인위적으로 늘리는 것이었습니다. 이 경우 근처에 배치된 포드는 다른 무거운 포드에 비해 조종할 공간이 더 많습니다. 자원 낭비가 되기 때문에 장기적으로는 효과가 없을 것입니다. 또한 우리의 Node 애플리케이션은 단일 스레드이므로 하나의 코어만 사용할 수 있었습니다. 유일한 실제 솔루션은 더 나은 로드 밸런싱을 사용하는 것이었습니다.

우리는 오랫동안 완전히 감사하고 싶었습니다. 사절. 현재 상황에서는 매우 제한적인 방식으로 배포하여 즉각적인 결과를 얻을 수 있었습니다. Envoy는 대규모 SOA 애플리케이션용으로 설계된 고성능 오픈 소스 레이어 XNUMX 프록시입니다. 자동 재시도, 회로 차단기, 전역 속도 제한을 포함한 고급 로드 밸런싱 기술을 구현할 수 있습니다. (메모. 번역: 이에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 이 기사 Envoy를 기반으로 하는 Istio에 대해 설명합니다.)

우리는 다음 구성을 생각해 냈습니다. 각 포드와 단일 경로에 대해 Envoy 사이드카를 갖고 포트를 통해 로컬로 클러스터를 컨테이너에 연결합니다. 잠재적인 계단식 연결을 최소화하고 작은 히트 반경을 유지하기 위해 우리는 각 서비스에 대해 가용 영역(AZ)당 하나씩 Envoy 전면 프록시 포드를 사용했습니다. 그들은 특정 서비스에 대해 각 AZ의 포드 목록을 반환하는 엔지니어 중 한 명이 작성한 간단한 서비스 검색 엔진에 의존했습니다.

그런 다음 Service Front-Envoy는 하나의 업스트림 클러스터 및 경로와 함께 이 서비스 검색 메커니즘을 사용했습니다. 단일 오류를 해결하고 원활한 배포를 보장하기 위해 적절한 시간 제한을 설정하고, 모든 회로 차단기 설정을 늘리고, 최소 재시도 구성을 추가했습니다. 우리는 이러한 각 서비스 전면 Envoy 앞에 TCP ELB를 배치했습니다. 기본 프록시 레이어의 Keepalive가 일부 Envoy 포드에 멈췄더라도 여전히 로드를 훨씬 더 잘 처리할 수 있었고 백엔드에서 최소 요청을 통해 균형을 유지하도록 구성되었습니다.

배포를 위해 애플리케이션 포드와 사이드카 포드 모두에 preStop 후크를 사용했습니다. 후크는 사이드카 컨테이너에 있는 관리 엔드포인트의 상태를 확인하는 동안 오류를 유발했으며 활성 연결이 종료될 수 있도록 잠시 동안 절전 모드로 전환되었습니다.

우리가 그토록 빠르게 움직일 수 있었던 이유 중 하나는 일반적인 Prometheus 설치에 쉽게 통합할 수 있었던 상세한 측정 항목 덕분이었습니다. 이를 통해 구성 매개변수를 조정하고 트래픽을 재분배하는 동안 무슨 일이 일어나고 있는지 정확히 확인할 수 있었습니다.

결과는 즉각적이고 명백했습니다. 우리는 가장 불균형한 서비스부터 시작했고 현재는 클러스터에서 가장 중요한 12개의 서비스 앞에서 작동하고 있습니다. 올해 우리는 고급 서비스 검색, 회로 차단, 이상치 감지, 속도 제한 및 추적 기능을 갖춘 전체 서비스 메시로의 전환을 계획하고 있습니다.

그림 3–1. Envoy로 전환하는 동안 한 서비스의 CPU 융합

최종 결과

이러한 경험과 추가 연구를 통해 우리는 대규모 Kubernetes 클러스터를 설계, 배포 및 운영하는 데 강력한 기술을 갖춘 강력한 인프라 팀을 구축했습니다. 이제 모든 Tinder 엔지니어는 컨테이너를 패키징하고 Kubernetes에 애플리케이션을 배포하는 데 필요한 지식과 경험을 보유하고 있습니다.

기존 인프라에 추가 용량이 필요할 때 새로운 EC2 인스턴스가 시작될 때까지 몇 분 정도 기다려야 했습니다. 이제 몇 분이 아닌 몇 초 만에 컨테이너가 실행되고 트래픽 처리가 시작됩니다. 단일 EC2 인스턴스에서 여러 컨테이너를 예약하면 수평 집중도 향상됩니다. 그 결과, 2019년에는 전년 대비 EC2 비용이 크게 감소할 것으로 예상됩니다.

마이그레이션은 거의 2019년이 걸렸지만 200년 1000월에 완료되었습니다. 현재 Tinder 플랫폼은 서비스 15개, 노드 000개, 포드 48개, 실행 중인 컨테이너 000개로 구성된 Kubernetes 클러스터에서만 실행됩니다. 인프라는 더 이상 운영팀만의 영역이 아닙니다. 우리의 모든 엔지니어는 이러한 책임을 공유하고 코드만을 사용하여 애플리케이션을 구축하고 배포하는 프로세스를 제어합니다.

번역가의 추신

또한 당사 블로그에서 일련의 기사를 읽어보세요.

출처 : habr.com

Tinder가 Kubernetes로 전환