Badoo가 초당 200k 사진을 렌더링하는 능력을 달성한 방법

현대 웹은 미디어 콘텐츠 없이는 거의 상상할 수 없습니다. 거의 모든 할머니가 스마트폰을 가지고 있고 모든 사람이 소셜 네트워크에 있으며 서비스 중단 시간은 회사에 비용이 많이 듭니다. 관심을 끌기 위해 회사 이야기의 대본 Badoo 그녀가 하드웨어 솔루션을 사용하여 사진 전달을 구성한 방법, 그 과정에서 어떤 성능 문제가 발생했는지, 그 원인은 무엇인지, 모든 수준에서 내결함성을 보장하면서 Nginx 기반 소프트웨어 솔루션을 사용하여 이러한 문제를 해결한 방법(비디오). Oleg 이야기의 저자에게 감사드립니다. 사니스 컨퍼런스에서 경험을 공유한 Efimova와 Alexandra Dymova 가동 시간 4일.

사진을 저장하고 캐시하는 방법에 대한 간단한 소개부터 시작하겠습니다. 사진을 저장하는 레이어와 사진을 캐시하는 레이어가 있습니다. 동시에 큰 트릭을 달성하고 저장소의 부하를 줄이려면 개별 사용자의 각 사진이 하나의 캐싱 서버에 있는 것이 중요합니다. 그렇지 않으면 더 많은 서버 수만큼 디스크를 설치해야 합니다. 우리의 적중률은 약 99%입니다. 즉, 스토리지의 부하를 100배로 줄입니다. 이를 위해 이 모든 것이 구축되던 10년 전에는 50개의 서버가 있었습니다. 따라서 이러한 사진을 제공하기 위해 실제로 이러한 서버가 제공하는 외부 도메인이 50개 필요했습니다.

당연히 질문이 즉시 제기되었습니다. 서버 중 하나가 다운되어 사용할 수 없게 되면 트래픽의 어느 부분이 손실됩니까? 우리는 시장에 나와 있는 것을 살펴보고 모든 문제를 해결할 수 있도록 철 조각을 구입하기로 결정했습니다. 선택은 F5 네트워크 회사(그런데 얼마 전에 NGINX, Inc를 인수함)의 솔루션인 BIG-IP Local Traffic Manager에 떨어졌습니다.

이 철 조각(LTM)이 하는 일은 외부 포트의 철 이중화를 만들고 일부 설정에서 네트워크 토폴로지를 기반으로 트래픽을 라우팅할 수 있게 하고 상태 확인을 수행하는 철 라우터입니다. 이 철 조각을 프로그래밍할 수 있다는 것이 우리에게 중요했습니다. 따라서 특정 사용자의 사진이 특정 캐시에서 반환되는 방식의 논리를 설명할 수 있습니다. 어떻게 생겼나요? 하나의 도메인, 하나의 IP에 대해 인터넷을 살펴보고, SSL 오프로드를 수행하고, http 요청을 구문 분석하고, IRule에서 캐시 번호를 선택하고, 어디로 가야 하는지, 트래픽을 그곳으로 보내도록 하는 하드웨어가 있습니다. 동시에 상태 확인을 하고, 머신을 사용할 수 없는 경우 트래픽이 그때 하나의 백업 서버로 이동하도록 만들었습니다. 물론 구성의 관점에서 약간의 뉘앙스가 있지만 일반적으로 모든 것이 매우 간단합니다. 맵을 지정하고 특정 숫자는 네트워크의 IP에 해당하며 포트 80에서 수신 대기한다고 말합니다. 그리고 443, 우리는 서버를 사용할 수 없는 경우 트래픽을 백업(이 경우 35번째)으로 보내야 한다고 말하고 이 아키텍처를 분해하는 방법에 대한 많은 논리를 설명합니다. 유일한 문제는 철 조각이 프로그래밍되는 언어가 Tcl 언어라는 것입니다. 누군가 이것을 기억한다면 ... 이 언어는 프로그래밍에 편리한 언어보다 쓰기 전용입니다.

우리는 무엇을 얻었습니까? 우리는 인프라의 고가용성을 보장하고 모든 트래픽을 라우팅하며 상태 확인을 제공하고 제대로 작동하는 하드웨어를 얻었습니다. 더욱이 그것은 꽤 오랫동안 작동해 왔습니다. 지난 10년 동안 그것에 대한 불만은 없었습니다. 2018년 초에 우리는 이미 초당 약 80만 장의 사진을 렌더링하고 있었습니다. 이것은 두 데이터 센터 모두에서 약 80기가비트의 트래픽입니다.

그러나 ...

2018년 초에 우리는 차트에서 추악한 그림을 보았습니다. 사진 반환 시간이 분명히 증가했습니다. 그리고 그것은 우리에게 적합하지 않았습니다. 문제는 이 동작이 트래픽이 가장 많을 때만 볼 수 있다는 것입니다. 우리 회사의 경우 이것은 일요일부터 월요일까지의 밤입니다. 그러나 나머지 시간 동안 시스템은 평소와 같이 작동했으며 파손의 징후는 없었습니다.

그러나 문제는 해결되어야 했습니다. 가능한 병목 현상을 식별하고 제거하기 시작했습니다. 우선, 물론 외부 업링크를 확장하고 내부 업링크를 전면 수정했으며 가능한 모든 병목 현상을 발견했습니다. 그러나이 모든 것이 분명한 결과를주지는 않았지만 문제는 사라지지 않았습니다.

또 다른 가능한 병목 현상은 사진 캐시 자체의 성능이었습니다. 그리고 우리는 아마도 문제가 그들에게 있다고 결정했습니다. 글쎄, 우리는 성능을 확장했습니다. 기본적으로 사진 캐시의 네트워크 포트입니다. 그러나 다시 한 번 명확한 개선이 보이지 않았습니다. 결국 우리는 LTM 자체의 성능에 세심한 주의를 기울였고 그래프에서 슬픈 그림을 보았습니다. 동시에 LTM은 상태 확인 및 업링크에 적절하게 응답하지 않고 무작위로 끄기 시작하여 심각한 성능 저하를 초래합니다.

즉, 문제의 원인을 식별하고 병목 현상을 식별했습니다. 우리가 무엇을 할 것인지 결정하는 것이 남아 있습니다.

우리가 할 수 있는 첫 번째 분명한 일은 어떻게든 LTM 자체를 현대화하는 것입니다. 그러나 여기에는 약간의 뉘앙스가 있습니다. 이 다리미는 매우 독특하기 때문에 가장 가까운 슈퍼마켓에 가서 사지 않을 것입니다. 별도의 계약, 별도의 라이센스 계약이며 많은 시간이 소요됩니다. 두 번째 옵션은 스스로 생각하기 시작하고 가능한 한 오픈 소스 프로그램을 사용하여 자신의 구성 요소에 대한 자신의 솔루션을 생각해내는 것입니다. 사용자가 사진을받지 못했기 때문에 정확히 무엇을 선택할 것인지,이 문제를 해결하는 데 얼마나 많은 시간을 할애할지 결정하는 것만 남아 있습니다. 따라서이 모든 작업을 매우 신속하게 수행해야합니다. 어제라고 말할 수 있습니다.

작업이 "가지고 있는 하드웨어를 사용하여 가능한 한 빨리 무언가를 수행하는 것"처럼 들렸기 때문에 가장 먼저 생각한 것은 전면에서 가장 강력하지 않은 기계를 제거하고 Nginx를 거기에 두는 것이었습니다. 작동하고 철 조각이 사용했던 것과 동일한 논리를 모두 구현하려고 노력하십시오. 즉, 실제로 우리는 하드웨어를 남겨두고 구성해야 할 서버를 4대 더 설치하고 10년 전과 유사하게 외부 도메인을 만들었습니다. 이 기계가 떨어지면 가용성이 약간 손실되었습니다. , 그러나 그럼에도 불구하고 사용자의 문제를 로컬에서 해결했습니다.

따라서 논리는 동일하게 유지됩니다. Nginx를 설치하고 SSL 오프로드를 수행할 수 있으며 어떻게든 라우팅 논리를 프로그래밍하고 구성에서 상태 확인을 수행하고 이전에 가지고 있던 논리를 복제할 수 있습니다.

우리는 구성을 작성하기 위해 앉아 있습니다. 처음에는 모든 것이 매우 간단 해 보였지만 불행히도 각 작업에 대한 매뉴얼을 찾는 것은 매우 어렵습니다. 따라서 단순히 "사진을 위해 Nginx를 구성하는 방법"을 Google에 검색하는 것은 권장하지 않습니다. 어떤 설정을 터치해야 하는지를 보여주는 공식 문서를 참조하는 것이 좋습니다. 그러나 특정 매개 변수를 직접 선택하는 것이 좋습니다. 그렇다면 모든 것이 간단합니다. 우리가 보유한 서버를 설명하고 인증서를 설명합니다 ... 그러나 가장 흥미로운 것은 사실 라우팅 논리 자체입니다.

처음에는 우리가 단순히 우리 위치를 설명하고, 사진 캐시 번호를 일치시키고, 손이나 생성기로 필요한 업스트림 수를 설명하고, 각 업스트림에서 트래픽이 이동해야 하는 서버를 표시하는 것처럼 보였습니다. 백업 서버 - 메인 서버를 사용할 수 없는 경우:

그러나 아마도 모든 것이 그렇게 단순하다면 우리는 집에 가서 아무 말도하지 않을 것입니다. 안타깝게도 Nginx의 기본 설정은 일반적으로 수년에 걸쳐 개발되었으며 이 경우에는 적합하지 않습니다. 구성은 다음과 같습니다. 일부 업스트림 서버에 요청 오류 또는 시간 초과가 있는 경우 Nginx는 항상 트래픽을 다음 트래픽으로 전환합니다. 동시에 첫 번째 실패 후 실수와 시간 초과로 인해 서버도 10초 이내에 꺼집니다. 이것은 어떤 식으로도 구성할 수 없습니다. 즉, 업스트림 지시문에서 시간 초과 옵션을 제거하거나 재설정하면 Nginx가 이 요청을 처리하지 않고 좋지 않은 오류로 응답하더라도 서버가 꺼집니다.

이를 방지하기 위해 다음 두 가지 작업을 수행했습니다.

a) 그들은 Nginx가 이 작업을 수동으로 수행하는 것을 금지했습니다. 불행히도 이를 수행하는 유일한 방법은 단순히 최대 실패 설정을 지정하는 것입니다.

b) 우리는 다른 프로젝트에서 백그라운드 상태 확인을 수행할 수 있는 모듈을 사용한다는 것을 기억했습니다. 따라서 사고 발생 시 다운타임을 최소화하기 위해 상태 확인을 자주 수행했습니다.

불행하게도 이것이 전부는 아닙니다. 문자 그대로 이 계획의 첫 200주 동안 TCP 상태 검사도 신뢰할 수 없는 것으로 나타났기 때문입니다. Nginx가 아니거나 D-상태의 Nginx는 업스트림 서버에서 시작할 수 있습니다. 이 경우 커널은 연결을 수락하고 상태 확인을 통과하지만 작동하지 않습니다. 따라서 즉시 http의 상태 확인으로 교체하고 특정 항목을 만들었습니다. 이미 XNUMX을 제공하면이 스크립트에서 모든 것이 작동합니다. 추가 논리를 수행할 수 있습니다. 예를 들어 캐싱 서버의 경우 파일 시스템이 올바르게 마운트되었는지 확인합니다.

그리고 그것은 우리에게 적합할 것입니다. 그 순간에 회로가 ​​철 조각이 했던 것을 완전히 반복한다는 점을 제외하면 말입니다. 하지만 우리는 더 잘하고 싶었습니다. 이전에는 하나의 백업 서버가 있었는데 이것은 그다지 좋지 않을 것입니다. 서버가 XNUMX 대이면 한 번에 여러 대가 떨어지면 하나의 백업 서버가 부하에 대처할 수 없기 때문입니다. 따라서 우리는 모든 서버에 예약을 분배하기로 결정했습니다. 우리는 단순히 또 다른 별도의 업스트림을 만들고 서버가 제공할 수 있는 로드에 따라 특정 매개 변수로 모든 서버를 기록하고 이전과 동일한 상태 확인을 추가했습니다.

하나의 업스트림 내에서 다른 업스트림으로 이동할 수 없기 때문에 단순히 정확하고 필요한 사진 캐시를 작성한 기본 업스트림을 사용할 수 없는 경우 단순히 error_page를 통해 폴백으로 이동했는지 확인해야 했습니다. 백업 업스트림으로 이동했습니다.

그리고 문자 그대로 40대의 서버를 추가하여 다음과 같은 결과를 얻었습니다. 로드의 일부를 교체했습니다. LTM에서 이 서버로 제거하고 표준 하드웨어 및 소프트웨어를 사용하여 동일한 로직을 구현했으며 이러한 서버를 확장할 수 있다는 보너스를 즉시 받았습니다. 필요한 만큼만 넣으세요. 유일한 단점은 외부 사용자에 대한 고가용성을 상실했다는 것입니다. 하지만 그 당시에는 문제를 즉시 해결해야 했기 때문에 이것을 희생해야 했습니다. 그래서 우리는 로드의 일부를 제거했고 그 당시에는 약 45%였고 LTM은 더 좋아졌고 문자 그대로 문제가 시작된 지 55주 후에 초당 20k 요청이 아닌 XNUMXk 요청을 제공하기 시작했습니다. 실제로 우리는 XNUMX% 성장했습니다. 이것은 분명히 사용자에게 제공하지 않은 트래픽입니다. 그 후 그들은 높은 외부 가용성을 보장하기 위해 남은 문제를 해결하는 방법에 대해 생각하기 시작했습니다.

우리는 이를 위해 어떤 솔루션을 사용할지 논의하는 동안 약간의 시간을 멈췄습니다. 자체 작성 스크립트, 동적 라우팅 프로토콜의 도움으로 DNS를 사용하여 안정성을 보장하기 위한 제안이 있었습니다. 많은 옵션이 있었지만 진정으로 신뢰할 수 있는 사진 반환을 위해서는 다른 레이어를 도입해야 한다는 것이 이미 분명해졌습니다. 이것은 이것을 감시할 것입니다. 우리는 이 기계들을 포토디렉터라고 불렀습니다. 우리가 의존한 소프트웨어는 Keepalived였습니다.

우선 Keepalived는 무엇으로 구성되어 있습니까? 첫 번째는 클라이언트가 연결하는 외부 IP 주소에 대한 내결함성을 제공하는 네트워크 장비에 있는 네트워커에게 널리 알려진 VRRP 프로토콜입니다. 두 번째 부분은 IP 가상 서버인 IPVS로 포토 라우터 간의 균형을 맞추고 이 수준에서 내결함성을 제공합니다. 세 번째는 건강검진입니다.

첫 번째 부분부터 시작하겠습니다. VRRP - 어떻게 생겼나요? 클라이언트가 연결되는 dns badoocdn.com에 항목이 있는 특정 가상 IP가 있습니다. 어느 시점에서 우리는 하나의 서버에 IP 주소를 가지고 있습니다. Keepalived 패킷은 VRRP 프로토콜을 사용하여 서버 간에 실행되며 마스터가 레이더에서 사라지면(서버가 재부팅되었거나 다른 경우) 백업 서버가 자동으로 이 IP 주소를 올립니다. 수동 작업이 필요하지 않습니다. 마스터와 백업은 주로 우선 순위가 다릅니다. 높을수록 시스템이 마스터가 될 가능성이 높아집니다. 매우 큰 장점은 서버 자체에서 IP 주소를 구성할 필요가 없다는 것입니다. 구성에서 설명하는 것으로 충분하며 IP 주소에 일부 사용자 정의 라우팅 규칙이 필요한 경우 이는 구성에서 직접 설명됩니다. VRRP 패키지에 설명된 것과 동일한 구문입니다. 낯선 일을 만나지 않을 것입니다.

실제로 어떻게 생겼습니까? 서버 중 하나가 다운되면 어떻게 됩니까? 마스터가 사라지는 즉시 우리 백업은 프로모션 수신을 중단하고 자동으로 마스터가 됩니다. 잠시 후 마스터를 복구하고 재부팅하고 Keepalived를 올렸습니다. 백업보다 우선 순위가 높은 광고가 도착하고 백업이 자동으로 돌아가 IP 주소를 자체에서 제거하므로 수동 작업이 필요하지 않습니다.

따라서 외부 IP 주소의 내결함성을 보장했습니다. 다음 부분은 외부 IP 주소에서 이미 종료된 사진 라우터로 트래픽의 균형을 맞추는 것입니다. 밸런싱 프로토콜을 사용하면 모든 것이 충분히 명확해집니다. 이것은 단순한 라운드 로빈이거나 조금 더 복잡한 것, wrr, 목록 연결 등입니다. 이것은 기본적으로 문서에 설명되어 있으며 특별한 것은 없습니다. 그러나 배송 방법 ... 여기서 우리는 그 중 하나를 선택한 이유에 대해 자세히 설명합니다. NAT, 직접 라우팅 및 TUN입니다. 사실 우리는 사이트에서 100기가비트의 트래픽 반환을 즉시 결정했습니다. 이렇게 알아내면 10기가 카드가 필요하죠? 하나의 서버에 10기가비트 카드 - 이것은 적어도 "표준 장비"라는 우리의 개념을 넘어선 것입니다. 그리고 나서 우리는 약간의 트래픽을 제공하는 것이 아니라 사진을 제공한다는 사실을 기억했습니다.

기능은 무엇입니까? - 들어오는 트래픽과 나가는 트래픽의 큰 차이. 들어오는 트래픽은 매우 적고 나가는 트래픽은 매우 큽니다.

이 그래프를 보면 현재 초당 약 200Mb가 감독에게 전송되고 있음을 알 수 있습니다. 이 날이 가장 일반적인 날입니다. 우리는 초당 4,500MB를 반환하며 비율은 약 1/22입니다. 우리가 22개의 작업 서버로 나가는 트래픽을 완전히 제공하려면 이 연결을 허용하는 서버 하나로 충분하다는 것이 이미 분명합니다. 여기에서 라우팅 알고리즘인 직접 라우팅 알고리즘이 도움이 됩니다.

어떻게 생겼나요? 그의 테이블에 따르면 우리 사진 감독은 연결을 사진 라우터로 전송합니다. 그러나 포토 라우터는 역방향 트래픽을 인터넷으로 직접 전송하고 클라이언트로 전송하며 포토 디렉터를 통해 되돌아가지 않으므로 최소한의 시스템으로 전체 내결함성과 모든 트래픽의 펌핑을 제공합니다. 구성에서 다음과 같이 보입니다. 알고리즘을 지정하고, 우리의 경우 간단한 rr이고, 직접 라우팅 방법을 제공한 다음 모든 실제 서버를 나열하기 시작합니다. 이 트래픽을 결정합니다. 하나 또는 두 개의 서버가 더 있는 경우 여러 서버가 나타나면 이러한 요구가 발생합니다. 이 섹션을 구성에 추가하고 너무 걱정하지 마십시오. 실제 서버 측에서, 포토 라우터 측에서 이 방법은 가장 최소한의 구성이 필요하고 문서에 완벽하게 설명되어 있으며 함정이 없습니다.

특히 즐거운 점은 그러한 솔루션이 로컬 네트워크의 급격한 변경을 의미하지 않는다는 것입니다. 이것은 우리에게 중요했으며 최소한의 비용으로 해결해야 했습니다. 보면 IPVS 관리 명령 출력그러면 우리는 그것이 어떻게 생겼는지 볼 것입니다. 여기에 포트 443에 있는 특정 가상 서버가 수신 대기하고 연결을 수락하며 모든 작업 서버가 나열되며 연결이 플러스 또는 마이너스로 동일한 것을 볼 수 있습니다. 동일한 가상 서버에 대한 통계를 보면 들어오는 패킷과 들어오는 연결이 있지만 나가는 패킷은 전혀 없습니다. 발신 연결은 클라이언트로 직접 이동합니다. 글쎄, 우리는 균형을 잃었습니다. 이제 포토 라우터 중 하나에 장애가 발생하면 어떻게 됩니까? 결국 철은 철입니다. 커널 패닉에 빠질 수 있고, 파손될 수 있으며, 전원 공급 장치가 소진될 수 있습니다. 아무것. 이것이 건강검진의 목적입니다. 포트가 어떻게 열려 있는지 확인하는 것처럼 간단할 수도 있고 비즈니스 논리를 확인하는 자체 작성 스크립트에 이르기까지 좀 더 복잡할 수도 있습니다.

우리는 중간 어딘가에서 멈췄습니다. 특정 위치에 대한 https 요청이 있고 200 번째 응답으로 응답하면 스크립트가 호출되며이 서버의 모든 것이 정상이며 살아 있고 아주 쉽게 켤 수 있다고 믿습니다. .

이것은 실제로 어떻게 보입니까? 유지 관리가 가능한 서버를 껐습니다. 예를 들어 BIOS를 플래싱합니다. 로그에서 즉시 시간 초과가 발생하고 첫 번째 줄이 표시된 다음 세 번 시도한 후 "실패"로 표시되고 목록에서 간단히 제거됩니다.

VS가 단순히 XNUMX으로 설정되었을 때 두 번째 동작도 가능하지만 사진을 반환하는 경우 제대로 작동하지 않습니다. 서버가 올라가고 Nginx가 시작되며 즉시 상태 확인에서 연결이 진행되고 있고 모든 것이 정상이며 서버가 목록에 나타나고 부하가 즉시 자동으로 적용되기 시작합니다. 의무 관리자의 수동 조치가 필요하지 않습니다. 밤에 서버가 재부팅되었습니다. 모니터링 부서는 밤에 이에 대해 전화하지 않습니다. 그들은 당신에게 무슨 일이 있었는지 알려줍니다. 모든 것이 괜찮습니다.

따라서 매우 간단한 방법으로 적은 수의 서버를 사용하여 외부 내결함성 문제를 해결했습니다.

물론 이 모든 것을 모니터링해야 합니다. 이와는 별도로 Keepalivede는 매우 오래 전에 작성된 소프트웨어로서 DBus, SMTP, SNMP 및 표준 Zabbix를 통한 확인을 사용하여 이를 모니터링하는 여러 가지 방법을 가지고 있습니다. 또한 그는 거의 모든 재채기에 편지를 쓰는 방법을 알고 있으며 솔직히 말해서 모든 트래픽 스위치, 포함, 모든 IP-shnik 및 등등. 물론 서버가 많으면 이러한 문자로 자신을 넘칠 수 있습니다. 표준 방법을 사용하여 포토 라우터에서 nginx를 모니터링하고 하드웨어 모니터링은 사라지지 않았습니다. 물론, 우리는 두 가지를 더 조언할 것입니다. 첫째, 외부 상태 확인 및 접근성입니다. 왜냐하면 모든 것이 작동하더라도 실제로 외부 공급자의 문제 또는 더 복잡한 문제로 인해 사용자가 사진을 받지 못할 수 있기 때문입니다. 외부에서 서버를 핑할 수 있는 별도의 기계를 다른 네트워크, 아마존 또는 다른 곳에 보관하는 것은 항상 가치가 있으며, 까다로운 기계 학습에 능숙한 사람들을 위해 이상 탐지를 사용하거나 단순한 적어도 요청이 급격히 떨어졌는지 또는 그 반대인지 추적하기 위해 모니터링합니다. 또한 유용합니다.

요약하자면, 실제로 어느 시점에서 우리에게 적합하지 않은 철 솔루션을 모든 것을 동일하게 수행하는 상당히 간단한 시스템으로 교체했습니다. 즉, HTTPS 트래픽을 종료하고 필요한 상태로 추가 스마트 라우팅을 제공합니다. -체크 무늬. 우리는 이 시스템의 안정성을 높였습니다. 즉, 여전히 각 계층에 대한 고가용성을 유지하고 있으며, 표준 소프트웨어가 포함된 표준 하드웨어이기 때문에 각 계층에서 모두 확장하기가 매우 쉽다는 보너스를 받았습니다. , 그렇게 함으로써 가능한 문제를 진단하는 과정을 단순화했습니다.

우리는 무엇으로 끝났습니까? 2018년 40월 연휴에 문제가 생겼습니다. 처음 60개월 동안 우리는 이 계획을 실행하고 모든 트래픽으로 확장하면서 LTM에서 모든 트래픽을 제거하기 위해 한 데이터 센터의 트래픽만 2018기가비트에서 XNUMX기가비트로 증가시켰고 동시에 XNUMX년 전체 시간 동안 초당 거의 XNUMX배 더 많은 사진을 제공할 수 있었습니다.

출처 : habr.com