VKontakte의 아키텍처 및 작업에 대한 FAQ

VKontakte 생성의 역사는 Wikipedia에 있으며 Pavel이 직접 말했습니다. 이미 모두가 그녀를 알고 있는 것 같습니다. HighLoad++ Pavel 사이트의 내부, 아키텍처 및 구조 정보 2010년에 나한테 말했어. 그 이후로 많은 서버가 유출되었으므로 정보를 업데이트할 것입니다. 이를 해부하고 내부를 꺼내 무게를 측정한 후 기술적인 관점에서 VK 장치를 살펴볼 것입니다.

알렉세이 아쿨로비치 (AterCattus) VKontakte 팀의 백엔드 개발자입니다. 이 보고서의 기록은 플랫폼, 인프라, 서버 및 이들 간의 상호 작용에 대해 자주 묻는 질문에 대한 종합적인 답변이지만 개발에 관한 내용은 아닙니다. 철에 대해서. 별도로 데이터베이스와 VK가 보유한 기능에 대해 로그 수집 및 전체 프로젝트 모니터링에 대해 설명합니다. 컷 아래의 세부 사항.

XNUMX년 넘게 백엔드와 관련된 온갖 업무를 맡아왔습니다.

• 미디어 업로드, 저장, 처리, 배포: 비디오, 라이브 스트리밍, 오디오, 사진, 문서.
• 인프라, 플랫폼, 개발자 모니터링, 로그, 지역 캐시, CDN, 독점 RPC 프로토콜.
• 외부 서비스와의 통합: 푸시 알림, 외부 링크 구문 분석, RSS 피드.
• 알 수 없는 코드를 탐구해야 하는 다양한 질문과 답변으로 동료를 돕습니다.

이 기간 동안 나는 사이트의 많은 구성 요소를 손에 넣었습니다. 나는 이 경험을 공유하고 싶다.

일반 아키텍처

평소와 같이 모든 것은 요청을 수락하는 서버 또는 서버 그룹에서 시작됩니다.

프론트 서버

전면 서버는 HTTPS, RTMP 및 WSS를 통해 요청을 수락합니다.

HTTPS - 사이트의 기본 및 모바일 웹 버전(vk.com 및 m.vk.com)과 당사 API의 기타 공식 및 비공식 클라이언트(모바일 클라이언트, 메신저)에 대한 요청입니다. 리셉션이 있어요 RTMP- 별도의 프론트 서버를 갖춘 라이브 방송을 위한 트래픽 및 WSS- 스트리밍 API에 대한 연결입니다.

서버의 HTTPS 및 WSS의 경우 가치가 있습니다. Nginx에. RTMP 방송의 경우 최근 자체 솔루션으로 전환했습니다. 키브그러나 이는 보고서의 범위를 벗어납니다. 내결함성을 위해 이러한 서버는 공통 IP 주소를 알리고 그룹으로 작동하므로 서버 중 하나에 문제가 있어도 사용자 요청이 손실되지 않습니다. HTTPS 및 WSS의 경우 이러한 동일한 서버는 CPU 부하를 자체적으로 처리하기 위해 트래픽을 암호화합니다.

WSS 및 RTMP에 대해서는 더 이상 설명하지 않고 일반적으로 웹 프로젝트와 관련된 표준 HTTPS 요청에 대해서만 설명합니다.

백엔드

전면 뒤에는 일반적으로 백엔드 서버가 있습니다. 프런트 서버가 클라이언트로부터 받는 요청을 처리합니다.

그것 kPHP 서버, HTTPS가 이미 해독되었기 때문에 HTTP 데몬이 실행되고 있습니다. kPHP는 다음에서 실행되는 서버입니다. 프리포크 모델: 여러 하위 프로세스인 마스터 프로세스를 시작하고 청취 소켓을 전달하여 요청을 처리합니다. 이 경우 사용자의 각 요청 사이에 프로세스가 다시 시작되지 않고 단순히 상태를 원래의 XNUMX 값 상태(다시 시작하는 대신 요청 후 요청)로 재설정합니다.

부하 분배

우리의 모든 백엔드는 모든 요청을 처리할 수 있는 거대한 머신 풀이 아닙니다. 우리는 그들 별도의 그룹으로 나누어져 있음: 일반, 모바일, API, 비디오, 스테이징... 별도의 머신 그룹의 문제는 다른 모든 머신에 영향을 미치지 않습니다. 영상에 문제가 발생할 경우 음악을 듣는 사용자는 문제가 있는지조차 알 수 없습니다. 요청을 보낼 백엔드는 구성에 따라 전면의 nginx에 의해 결정됩니다.

지표 수집 및 재조정

각 그룹에 몇 대의 자동차가 필요한지 이해하려면 QPS에 의존하지 마십시오. 백엔드가 다르고 요청이 다르며 각 요청은 QPS 계산의 복잡성이 다릅니다. 그렇기 때문에 우리는 우리는 서버 전체, 즉 CPU 및 성능에 대한 부하 개념을 가지고 운영합니다..

우리는 수천 개의 그러한 서버를 보유하고 있습니다. 각 물리적 서버는 kPHP 그룹을 실행하여 모든 코어를 재활용합니다(kPHP는 단일 스레드이므로).

콘텐츠 서버

CS 또는 Content Server는 스토리지입니다.. CS는 파일을 저장하고 업로드된 파일과 기본 웹 프런트엔드가 할당하는 모든 종류의 백그라운드 동기 작업을 처리하는 서버입니다.

우리는 파일을 저장하는 수만 개의 물리적 서버를 보유하고 있습니다. 사용자는 파일 업로드를 좋아하며 우리는 파일을 저장하고 공유하는 것을 좋아합니다. 이러한 서버 중 일부는 특수 pu/pp 서버에 의해 폐쇄됩니다.

푸/pp

VK에서 네트워크 탭을 열면 pu/pp가 보입니다.

pu/pp란 무엇입니까? 서버를 차례로 닫는 경우 닫힌 서버에 파일을 업로드하고 다운로드하는 두 가지 옵션이 있습니다. 직접 를 통해 http://cs100500.userapi.com/path 또는 중간 서버를 통해 - http://pu.vk.com/c100500/path.

Pu는 사진 업로드의 역사적 이름이고 pp는 사진 프록시입니다.. 즉, 한 서버는 사진 업로드용이고 다른 서버는 업로드용입니다. 이제 사진이 로드될 뿐만 아니라 이름도 그대로 유지됩니다.

이들 서버 HTTPS 세션 종료스토리지에서 프로세서 로드를 제거합니다. 또한 사용자 파일은 이러한 서버에서 처리되므로 이러한 시스템에 저장된 정보는 덜 중요할수록 좋습니다. 예를 들어 HTTPS 암호화 키입니다.

해당 머신은 다른 머신에 의해 닫혀 있으므로 해당 머신에 "화이트" 외부 IP를 제공하지 않을 여유가 있습니다. "회색"을 줘. 이런 방식으로 우리는 IP 풀을 절약하고 외부 액세스로부터 시스템을 보호할 수 있도록 보장했습니다. 여기에 들어갈 IP가 전혀 없습니다.

공유 IP에 대한 복원력. 내결함성 측면에서 이 체계는 동일하게 작동합니다. 즉, 여러 물리적 서버가 공통 물리적 IP를 가지며 그 앞에 있는 하드웨어가 요청을 보낼 위치를 선택합니다. 다른 옵션에 대해서는 나중에 이야기하겠습니다.

논란의 여지가 있는 점은 이 경우이다. 클라이언트는 더 적은 수의 연결을 유지합니다.. 동일한 호스트(pu.vk.com 또는 pp.vk.com)를 사용하는 여러 시스템에 동일한 IP가 있는 경우 클라이언트 브라우저는 하나의 호스트에 대한 동시 요청 수에 제한이 있습니다. 그러나 HTTP/2가 널리 보급된 시대에는 이것이 더 이상 중요하지 않다고 생각합니다.

이 계획의 명백한 단점은 모든 트래픽을 펌핑, 다른 서버를 통해 스토리지로 이동합니다. 우리는 머신을 통해 트래픽을 펌핑하기 때문에 동일한 구성표를 사용하여 비디오와 같은 과도한 트래픽을 아직 펌핑할 수 없습니다. 우리는 이를 직접 전송합니다. 특히 비디오용으로 별도의 저장소를 위한 별도의 직접 연결입니다. 우리는 프록시를 통해 더 가벼운 콘텐츠를 전송합니다.

얼마 전 우리는 향상된 버전의 프록시를 얻었습니다. 이제 일반 제품과 어떻게 다른지, 그리고 이것이 필요한 이유를 알려 드리겠습니다.

태양

2017년 XNUMX월, 이전에 Sun을 인수했던 Oracle은 수많은 Sun 직원을 해고했습니다.. 이 순간 회사는 더 이상 존재하지 않는다고 말할 수 있습니다. 새 시스템의 이름을 선택할 때 관리자는 이 회사를 기념하기로 결정하고 새 시스템의 이름을 Sun으로 지정했습니다. 우리 사이에서는 단순히 그녀를 "태양"이라고 부릅니다.

pp에는 몇 가지 문제가 있었습니다. 그룹당 하나의 IP - 비효율적인 캐시. 여러 물리적 서버가 공통 IP 주소를 공유하므로 요청이 어느 서버로 전달되는지 제어할 수 있는 방법이 없습니다. 따라서 서로 다른 사용자가 동일한 파일을 찾으러 오면 해당 서버에 캐시가 있으면 파일은 각 서버의 캐시에 남게 됩니다. 이것은 매우 비효율적인 계획이지만 아무것도 할 수 없습니다.

결과적으로 - 콘텐츠를 샤딩할 수 없습니다., 이 그룹에 대해 특정 서버를 선택할 수 없기 때문에 공통 IP를 가지고 있습니다. 또한 몇 가지 내부적인 이유로 인해 지역에 이러한 서버를 설치할 수 없었습니다.. 그들은 상트페테르부르크에만 서 있었습니다.

태양과 함께 우리는 선택 시스템을 변경했습니다. 이제 우리는 애니캐스트 라우팅: 동적 라우팅, 애니캐스트, 자체 검사 데몬. 각 서버에는 고유한 개별 IP가 있지만 공통 서브넷이 있습니다. 한 서버에 장애가 발생하면 트래픽이 자동으로 동일한 그룹의 다른 서버로 분산되는 방식으로 모든 것이 구성됩니다. 이제 특정 서버를 선택할 수 있습니다. 중복 캐싱 없음, 신뢰성에는 영향을 미치지 않았습니다.

무게 지원. 이제 우리는 필요에 따라 다양한 출력의 기계를 설치할 여유가 있으며, 일시적인 문제가 발생할 경우 작동하는 "태양"의 무게를 변경하여 부하를 줄여 "휴식"하고 다시 작업을 시작할 수 있습니다.

콘텐츠 ID별 샤딩. 샤딩에 대한 재미있는 점은 일반적으로 서로 다른 사용자가 동일한 "태양"을 통해 동일한 파일로 이동하여 공통 캐시를 갖도록 콘텐츠를 샤딩한다는 것입니다.

최근 'Clover' 애플리케이션을 출시했습니다. 진행자가 질문하고 사용자가 옵션을 선택하여 실시간으로 답변하는 라이브 방송의 온라인 퀴즈입니다. 앱에는 사용자가 채팅할 수 있는 채팅 기능이 있습니다. 방송에 동시에 연결할 수 있습니다 100만명 이상. 그들은 모두 모든 참가자에게 전송되는 메시지를 작성하고 아바타가 메시지와 함께 제공됩니다. 하나의 "태양"에서 하나의 아바타를 위해 100만 명이 오면 때로는 구름 뒤에 굴러갈 수도 있습니다.

동일한 파일에 대한 급증하는 요청을 견디기 위해 특정 유형의 콘텐츠에 대해 해당 지역의 사용 가능한 모든 "태양"에 파일을 분산시키는 어리석은 계획을 사용합니다.

내부에서 태양

nginx의 리버스 프록시, RAM 또는 빠른 Optane/NVMe 디스크에 캐시합니다. 예: http://sun4-2.userapi.com/c100500/path — 두 번째 서버 그룹인 네 번째 지역에 위치한 "sun"에 대한 링크입니다. 서버 100500에 물리적으로 있는 경로 파일을 닫습니다.

캐시

우리의 아키텍처 체계에 캐싱 환경이라는 노드를 하나 더 추가합니다.

아래는 레이아웃 다이어그램입니다. 지역 캐시, 약 20 개가 있습니다. 이곳에는 스스로 트래픽을 캐시할 수 있는 캐시와 "태양"이 있는 장소입니다.

이는 멀티미디어 콘텐츠의 캐싱이며 사용자 데이터는 여기에 저장되지 않으며 음악, 비디오, 사진만 저장됩니다.

사용자의 지역을 확인하기 위해 당사는 지역에서 발표된 BGP 네트워크 접두사를 수집합니다.. 폴백의 경우 접두사로 IP를 찾을 수 없으면 geoip 데이터베이스도 구문 분석해야 합니다. 사용자의 IP를 기준으로 지역을 결정합니다.. 코드에서 사용자의 하나 이상의 지역, 즉 지리적으로 가장 가까운 지점을 볼 수 있습니다.

어떻게 작동합니까?

지역별 파일 인기도를 계산합니다.. 사용자가 위치한 여러 지역 캐시와 파일 식별자가 있습니다. 우리는 이 쌍을 가져와 다운로드할 때마다 등급을 높입니다.

동시에 악마(지역 서비스)는 때때로 API에 와서 다음과 같이 말합니다. “나는 그런 캐시입니다. 아직 나에게 없는 내 지역에서 가장 인기 있는 파일 목록을 알려주세요. ” API는 등급별로 정렬된 여러 파일을 전달하고, 데몬은 이를 다운로드하여 해당 지역으로 가져간 후 거기에서 파일을 전달합니다. 이것이 캐시에서 pu/pp와 Sun의 근본적인 차이점입니다. 이 파일이 캐시에 없더라도 즉시 파일을 자체적으로 제공하고 캐시는 먼저 파일을 자체적으로 다운로드한 다음 다시 제공하기 시작합니다.

이 경우 우리는 얻는다 사용자에게 더 가까운 콘텐츠 그리고 네트워크 부하를 분산시킵니다. 예를 들어, 모스크바 캐시에서만 피크 시간 동안 1Tbit/s 이상을 배포합니다.

하지만 문제가 있습니다 - 캐시 서버는 고무가 아닙니다. 인기가 매우 높은 콘텐츠의 경우 별도의 서버를 구축할 네트워크가 부족한 경우도 있습니다. 우리의 캐시 서버는 40-50 Gbit/s이지만 이러한 채널을 완전히 막는 콘텐츠가 있습니다. 우리는 해당 지역에서 인기 있는 파일의 복사본을 두 개 이상 저장하는 방향으로 나아가고 있습니다. 올해 말까지 시행되길 바랍니다.

우리는 일반적인 아키텍처를 살펴보았습니다.

• 요청을 수락하는 프런트 서버.
• 요청을 처리하는 백엔드.
• 두 가지 유형의 프록시로 닫혀 있는 저장소입니다.
• 지역 캐시.

이 다이어그램에서 무엇이 빠졌나요? 물론, 우리가 데이터를 저장하는 데이터베이스입니다.

데이터베이스 또는 엔진

우리는 그것을 데이터베이스가 아니라 엔진이라고 부릅니다. 일반적으로 받아 들여지는 의미의 데이터베이스가 실제로 없기 때문입니다.

이것은 필요한 조치입니다.. 이는 VK가 폭발적으로 인기를 얻었던 2008~2009년에 프로젝트가 전적으로 MySQL과 Memcache에서 작동했는데 문제가 있었기 때문에 발생했습니다. MySQL은 파일을 충돌시키고 손상시키는 것을 좋아했으며 그 후에는 복구할 수 없었으며 Memcache는 점차 성능이 저하되어 다시 시작해야 했습니다.

점점 더 인기를 얻고 있는 프로젝트에는 데이터를 손상시키는 영구 스토리지와 속도를 저하시키는 캐시가 있는 것으로 나타났습니다. 이러한 상황에서는 성장하는 프로젝트를 개발하기가 어렵습니다. 프로젝트가 초점을 맞춘 중요한 사항을 우리 자전거에 다시 작성하기로 결정했습니다.

솔루션은 성공적이었습니다. 당시에는 다른 확장 방법이 존재하지 않았기 때문에 이를 수행할 수 있는 기회와 절실한 필요성이 있었습니다. 데이터베이스도 많지 않았고 NoSQL도 아직 존재하지 않았으며 MySQL, Memcache, PostrgreSQL만 있었습니다. 그게 전부였습니다.

범용 작동. 개발은 C 개발자 팀이 주도했으며 모든 것이 일관된 방식으로 수행되었습니다. 엔진에 관계없이 모두 거의 동일한 파일 형식을 디스크에 기록했고, 동일한 시작 매개변수를 사용했으며, 동일한 방식으로 신호를 처리했으며, 엣지 상황 및 문제 발생 시 거의 동일하게 작동했습니다. 엔진의 성장으로 관리자가 시스템을 운영하는 것이 편리합니다. 유지 관리해야 할 동물원이 없으며 새로운 타사 데이터베이스를 각각 작동하는 방법을 다시 배워야 하므로 빠르고 편리하게 증가할 수 있습니다. 그들의 번호.

엔진의 종류

팀은 꽤 많은 엔진을 작성했습니다. 다음은 그 중 일부입니다: 친구, 힌트, 이미지, ipdb, 편지, 목록, 로그, memcached, meowdb, 뉴스, 노스트라다무스, 사진, 재생 목록, pmemcached, 샌드박스, 검색, 저장, 좋아요, 작업 등

특정 데이터 구조가 필요하거나 비정형 요청을 처리하는 각 작업에 대해 C 팀은 새로운 엔진을 작성합니다. 왜 안 돼.

엔진이 따로 있어요 memcached, 일반 것과 유사하지만 많은 장점이 있고 속도가 느려지지 않습니다. ClickHouse는 아니지만 작동합니다. 별도로 구매 가능 pmemcached -가요 지속적인 memcached, 또한 다시 시작할 때 데이터가 손실되지 않도록 RAM에 맞는 것보다 디스크에 데이터를 저장할 수도 있습니다. 개별 작업을 위한 다양한 엔진(큐, 목록, 세트 등 프로젝트에 필요한 모든 것)이 있습니다.

클러스터

코드 관점에서는 엔진이나 데이터베이스를 프로세스, 엔터티 또는 인스턴스로 생각할 필요가 없습니다. 이 코드는 특히 엔진 그룹이 있는 클러스터에서 작동합니다. 클러스터당 하나의 유형. memcached 클러스터가 있다고 가정해 보겠습니다. 이는 단지 시스템 그룹일 뿐입니다.

코드는 물리적 위치, 크기 또는 서버 수를 전혀 알 필요가 없습니다. 그는 특정 식별자를 사용하여 클러스터로 이동합니다.

이것이 작동하려면 코드와 엔진 사이에 있는 엔터티를 하나 더 추가해야 합니다. 대리.

RPC 프록시

대리 연결버스, 거의 전체 사이트가 실행됩니다. 동시에 우리는 서비스 검색 없음 — 대신 이 클러스터의 모든 클러스터와 모든 샤드의 위치를 ​​아는 이 프록시에 대한 구성이 있습니다. 이것이 관리자가 하는 일입니다.

프로그래머는 비용이 얼마나, 어디서, 얼마인지 전혀 신경 쓰지 않고 클러스터로 이동합니다. 이것은 우리에게 많은 것을 허용합니다. 요청을 받으면 프록시는 위치를 알고 요청을 리디렉션합니다. 이를 스스로 결정합니다.

이 경우 프록시는 서비스 장애에 대한 보호 지점입니다. 일부 엔진이 느려지거나 충돌하는 경우 프록시는 이를 이해하고 그에 따라 클라이언트 측에 응답합니다. 이를 통해 시간 초과를 제거할 수 있습니다. 코드는 엔진이 응답할 때까지 기다리지 않지만 엔진이 작동하지 않으며 어떻게든 다르게 작동해야 한다는 것을 이해합니다. 데이터베이스가 항상 작동하지 않는다는 사실에 대비하여 코드를 준비해야 합니다.

특정 구현

때때로 우리는 여전히 일종의 비표준 솔루션을 엔진으로 갖고 싶어합니다. 동시에, 우리 엔진용으로 특별히 제작된 기성 rpc-proxy를 사용하지 않고 작업을 위한 별도의 프록시를 만들기로 결정했습니다.

아직 여기저기에 있는 MySQL의 경우 db-proxy를 사용하고 ClickHouse의 경우 - 새끼 고양이 집.

일반적으로 다음과 같이 작동합니다. kPHP, Go, Python 등 일반적으로 RPC 프로토콜을 사용할 수 있는 모든 코드를 실행하는 특정 서버가 있습니다. 코드는 RPC 프록시에서 로컬로 실행됩니다. 코드가 있는 각 서버는 자체 로컬 프록시를 실행합니다. 요청 시 프록시는 어디로 가야 할지 이해합니다.

한 엔진이 다른 엔진으로 이동하려는 경우 이웃이라 할지라도 이웃이 다른 데이터 센터에 있을 수 있으므로 프록시를 통과합니다. 엔진은 자신 이외의 위치를 ​​아는 데 의존해서는 안 됩니다. 이것이 우리의 표준 솔루션입니다. 하지만 물론 예외도 있습니다 :)

모든 엔진이 작동하는 TL 방식의 예입니다.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

이것은 바이너리 프로토콜이며 가장 가까운 아날로그는 다음과 같습니다. protobuf. 스키마는 선택적 필드, 복합 유형(내장 스칼라 확장) 및 쿼리를 미리 설명합니다. 모든 것이 이 프로토콜에 따라 작동합니다.

TCP/UDP를 통한 TL을 통한 RPC… UDP?

우리는 TL 체계 위에서 실행되는 엔진 요청을 실행하기 위한 RPC 프로토콜을 가지고 있습니다. 이 모든 것은 TCP/UDP 연결을 통해 작동합니다. TCP는 이해할 수 있지만 UDP가 자주 필요한 이유는 무엇입니까?

UDP 도움 서버 간의 엄청난 수의 연결 문제를 피하십시오. 각 서버에 RPC 프록시가 있고 일반적으로 모든 엔진으로 이동할 수 있는 경우 서버당 수만 개의 TCP 연결이 있습니다. 부하가 있지만 쓸모가 없습니다. UDP의 경우에는 이 문제가 존재하지 않습니다.

중복 TCP 핸드셰이크 없음. 이는 일반적인 문제입니다. 새 엔진이나 새 서버가 시작되면 한 번에 많은 TCP 연결이 설정됩니다. UDP 페이로드와 같은 작고 가벼운 요청의 경우 코드와 엔진 간의 모든 통신은 두 개의 UDP 패킷: 하나는 한 방향으로 날아가고, 두 번째는 다른 방향으로 날아갑니다. 한 번의 왕복 - 코드는 핸드셰이크 없이 엔진으로부터 응답을 받았습니다.

예, 모두 작동합니다 매우 적은 비율의 패킷 손실로. 프로토콜은 재전송 및 시간 초과를 지원하지만 손실이 많으면 거의 TCP를 얻게 되며 이는 수익성이 없습니다. 우리는 바다를 건너 UDP를 운전하지 않습니다.

우리는 수천 개의 그러한 서버를 보유하고 있으며 구성은 동일합니다. 즉, 각 물리적 서버에 엔진 팩이 설치됩니다. 차단 없이 최대한 빠르게 실행하기 위해 대부분 단일 스레드로 구성되며 단일 스레드 솔루션으로 분할됩니다. 동시에 우리는 이러한 엔진보다 더 안정적인 것은 없으며 지속적인 데이터 저장에 많은 관심을 기울이고 있습니다.

지속적인 데이터 저장

엔진은 binlog를 작성합니다.. binlog는 상태나 데이터 변경에 대한 이벤트가 추가되는 파일입니다. 다른 솔루션에서는 다르게 호출됩니다. 바이너리 로그, WAL, AOF, 그러나 원칙은 동일합니다.

엔진이 다시 시작할 때 수년 동안 전체 binlog를 다시 읽는 것을 방지하기 위해 엔진은 다음을 작성합니다. 스냅샷 - 현재 상태. 필요한 경우 먼저 binlog에서 읽은 다음 binlog에서 읽기를 마칩니다. 모든 binlog는 TL 체계에 따라 동일한 바이너리 형식으로 작성되므로 관리자는 도구를 사용하여 동일하게 관리할 수 있습니다. 스냅샷은 그런 필요가 없습니다. 누구의 스냅샷이 int인지, 엔진의 마법인지, 누구에게도 중요하지 않은 바디인지를 나타내는 일반 헤더가 있습니다. 이는 스냅샷을 기록한 엔진의 문제입니다.

작동 원리를 빠르게 설명하겠습니다. 엔진이 실행되는 서버가 있습니다. 그는 쓰기를 위해 새로운 빈 로그를 열고 이를 변경하기 위한 이벤트를 작성합니다.

어느 시점에서 그는 스스로 스냅샷을 찍기로 결정하거나 신호를 받습니다. 서버는 새 파일을 생성하고 파일의 전체 상태를 기록하며 현재 binlog 크기(오프셋)를 파일 끝에 추가하고 계속해서 기록합니다. 새로운 binlog가 생성되지 않습니다.

어느 시점에서 엔진이 다시 시작되면 디스크에 binlog와 스냅샷이 모두 남게 됩니다. 엔진은 전체 스냅샷을 읽고 특정 지점에서 상태를 높입니다.

스냅샷이 생성된 시점의 위치와 binlog의 크기를 읽습니다.

현재 상태를 가져오기 위해 binlog의 끝을 읽고 계속해서 추가 이벤트를 기록합니다. 이것은 간단한 계획이며, 우리의 모든 엔진은 이에 따라 작동합니다.

데이터 복제

결과적으로 우리의 데이터 복제는 명령문 기반 — 우리는 페이지 변경 사항을 binlog에 기록하지 않습니다. 변경 요청. 네트워크를 통해 제공되는 것과 매우 유사하며 약간만 수정되었습니다.

동일한 방식이 복제에만 사용되는 것이 아니라 백업을 생성하려면. 우리는 binlog에 쓰는 쓰기 마스터인 엔진을 가지고 있습니다. 관리자가 설정한 다른 위치에는 이 binlog가 복사되며 그게 전부입니다. 백업이 있습니다.

필요한 경우 복제본 읽기CPU 읽기 부하를 줄이기 위해 읽기 엔진이 시작되어 binlog의 끝을 읽고 로컬에서 이러한 명령을 실행합니다.

여기서의 지연은 매우 작으며 복제본이 마스터보다 얼마나 지연되는지 확인할 수 있습니다.

RPC 프록시의 데이터 샤딩

샤딩은 어떻게 작동하나요? 프록시는 어떤 클러스터 샤드로 보낼지 어떻게 이해합니까? 코드에는 "샤드 15개를 보내세요!"라고 나와 있지 않습니다. - 아니요, 이는 프록시에 의해 수행됩니다.

가장 간단한 방식은 firstint입니다. — 요청의 첫 번째 숫자입니다.

get(photo100_500) => 100 % N.

이는 간단한 memcached 텍스트 프로토콜의 예이지만 쿼리는 복잡하고 구조화될 수 있습니다. 이 예에서는 쿼리의 첫 번째 숫자를 사용하고 클러스터 크기로 나눈 나머지를 사용합니다.

이는 단일 엔터티의 데이터 지역성을 원할 때 유용합니다. 100이 사용자 또는 그룹 ID이고 복잡한 쿼리를 위해 한 엔터티의 모든 데이터가 하나의 샤드에 있기를 원한다고 가정해 보겠습니다.

요청이 클러스터 전체에 어떻게 분산되는지 신경 쓰지 않는다면 또 다른 옵션이 있습니다. 전체 샤드를 해싱.

hash(photo100_500) => 3539886280 % N

우리는 또한 해시, 분할의 나머지 부분 및 샤드 번호를 얻습니다.

이 두 옵션 모두 클러스터 크기를 늘릴 때 클러스터를 분할하거나 여러 배로 늘릴 것이라는 사실에 대비한 경우에만 작동합니다. 예를 들어, 샤드가 16개 있는데 충분하지 않아 더 많은 샤드를 원합니다. 다운타임 없이 안전하게 32개를 얻을 수 있습니다. 배수가 아닌 증가를 원할 경우 손실 없이 모든 것을 정확하게 분할할 수 없기 때문에 가동 중지 시간이 발생합니다. 이러한 옵션은 유용하지만 항상 그런 것은 아닙니다.

임의의 수의 서버를 추가하거나 제거해야 하는 경우 다음을 사용합니다. Ketama 링에 대한 일관된 해싱. 그러나 동시에 데이터의 지역성을 완전히 잃게 되므로 각 조각이 자체의 작은 응답을 반환하도록 요청을 클러스터에 병합한 다음 응답을 프록시에 병합해야 합니다.

매우 구체적인 요청이 있습니다. 이는 다음과 같습니다. RPC 프록시가 요청을 수신하고 어느 클러스터로 이동할지 결정하고 샤드를 결정합니다. 그런 다음 쓰기 마스터가 있거나 클러스터에 복제본 지원이 있는 경우 요청 시 복제본으로 보냅니다. 프록시가 이 모든 작업을 수행합니다.

로그

우리는 여러 가지 방법으로 로그를 작성합니다. 가장 분명하고 간단한 것은 Memcache에 로그 쓰기.

ring-buffer: prefix.idx = line

키 접두어(로그 이름, 줄)가 있고 이 로그의 크기(줄 수)가 있습니다. 0부터 행 수에서 1을 뺀 값까지 난수를 취합니다. Memcache의 키는 이 난수와 연결된 접두사입니다. 로그 라인과 현재 시간을 값에 저장합니다.

로그를 읽어야 하는 경우 멀티겟 모든 키를 시간별로 정렬하여 실시간으로 생산 로그를 얻을 수 있습니다. 이 구성표는 프로덕션에서 아무것도 중단하지 않고 다른 시스템에 대한 트래픽을 중지하거나 허용하지 않고 실시간으로 디버깅해야 할 때 사용되지만 이 로그는 오래 가지 않습니다.

안정적인 로그 저장을 위해 엔진이 있습니다. 로그 엔진. 이것이 바로 이것이 생성되어 수많은 클러스터에서 널리 사용되는 이유입니다. 제가 아는 가장 큰 클러스터는 600TB의 압축된 로그를 저장합니다.

엔진은 매우 오래되었으며 이미 6~7년이 된 클러스터도 있습니다. 예를 들어, ClickHouse를 적극적으로 사용하여 로그를 저장하기 시작했습니다.

ClickHouse에서 로그 수집

이 다이어그램은 우리가 엔진에 들어가는 방법을 보여줍니다.

RPC를 통해 RPC 프록시로 로컬로 이동하는 코드가 있으며 엔진으로 이동할 위치를 이해합니다. ClickHouse에 로그를 작성하려면 이 체계에서 두 부분을 변경해야 합니다.

• 일부 엔진을 ClickHouse로 교체하세요.
• ClickHouse에 액세스할 수 없는 RPC 프록시를 RPC를 통해 액세스할 수 있는 일부 솔루션으로 교체하십시오.

엔진은 간단합니다. ClickHouse를 사용하여 서버 또는 서버 클러스터로 교체합니다.

그리고 ClickHouse에 가기 위해 우리는 그렇게 했습니다. 새끼 고양이집. KittenHouse에서 ClickHouse로 직접 이동하면 대처할 수 없습니다. 요청이 없더라도 엄청난 수의 시스템에 대한 HTTP 연결이 추가됩니다. 계획이 작동하려면 ClickHouse가 있는 서버에서 로컬 역방향 프록시가 발생합니다., 이는 필요한 연결량을 견딜 수 있도록 작성되었습니다. 또한 비교적 안정적으로 자체적으로 데이터를 버퍼링할 수 있습니다.

때때로 우리는 nginx와 같은 비표준 솔루션에서 RPC 체계를 구현하고 싶지 않습니다. 따라서 KittenHouse는 UDP를 통해 로그를 수신할 수 있는 기능을 갖추고 있습니다.

로그의 발신자와 수신자가 동일한 시스템에서 작업하는 경우 로컬 호스트 내에서 UDP 패킷이 손실될 확률은 매우 낮습니다. 타사 솔루션에서 RPC를 구현해야 하는 필요성과 안정성 사이의 절충안으로 우리는 간단히 UDP 전송을 사용합니다. 우리는 나중에 이 계획으로 돌아올 것입니다.

모니터링

로그에는 두 가지 유형이 있습니다. 관리자가 서버에서 수집한 로그와 개발자가 코드에서 작성한 로그입니다. 이는 두 가지 유형의 측정항목에 해당합니다. 시스템과 제품.

시스템 측정항목

우리의 모든 서버에서 작동합니다 넷 데이터, 통계를 수집하여 다음으로 보냅니다. 흑연 탄소. 따라서 예를 들어 Whisper가 아닌 ClickHouse가 저장 시스템으로 사용됩니다. 필요한 경우 ClickHouse에서 직접 읽거나 다음을 사용할 수 있습니다. 그라 파나 측정항목, 그래프 및 보고서용. 개발자로서 우리는 Netdata 및 Grafana에 대한 충분한 액세스 권한을 가지고 있습니다.

제품 지표

편의상 많은 내용을 작성했습니다. 예를 들어, Counts, UniqueCounts 값을 통계에 기록하여 더 멀리 보낼 수 있는 일련의 일반 함수가 있습니다.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

그런 다음 정렬 및 그룹화 필터를 사용하고 그래프 작성, Watchdog 구성 등 통계에서 원하는 모든 작업을 수행할 수 있습니다.

우리는 아주 글을 쓴다 많은 지표 이벤트 수는 하루에 600억에서 1조 건에 이릅니다. 그러나 우리는 그것들을 유지하고 싶습니다. 적어도 몇 년측정항목의 추세를 이해합니다. 이 모든 것을 하나로 묶는 것은 우리가 아직 해결하지 못한 큰 문제입니다. 지난 몇 년 동안 어떻게 작동했는지 말씀드리겠습니다.

이러한 측정항목을 작성하는 기능이 있습니다. 로컬 memcache로항목 수를 줄이기 위해. 단기간만에 국내 출시 통계 데몬 모든 기록을 수집합니다. 다음으로 악마는 측정항목을 서버의 두 계층으로 병합합니다. 로그 수집기, 이는 여러 머신의 통계를 집계하여 그 뒤에 있는 레이어가 죽지 않도록 합니다.

필요한 경우 로그 수집기에 직접 쓸 수 있습니다.

그러나 stas-daemom을 우회하여 코드에서 수집기로 직접 작성하는 것은 수집기에 대한 로드를 증가시키므로 확장성이 떨어지는 솔루션입니다. 이 솔루션은 어떤 이유로 인해 머신에서 memcache stats-daemon을 실행할 수 없거나 머신이 충돌하여 직접 진행한 경우에만 적합합니다.

다음으로, 로그 수집기는 통계를 다음과 같이 병합합니다. 야옹DB - 이는 측정항목을 저장할 수도 있는 데이터베이스입니다.

그런 다음 코드에서 이진 "SQL에 가까운" 선택을 수행할 수 있습니다.

실험

2018년 여름, 내부 해커톤이 있었는데 다이어그램의 빨간색 부분을 ClickHouse에 메트릭을 저장할 수 있는 것으로 대체하려는 아이디어가 나왔습니다. ClickHouse에 대한 로그가 있습니다. 시도해 보는 것은 어떨까요?

KittenHouse를 통해 로그를 작성하는 방식이 있었습니다.

우리는 결정했다 다이어그램에 또 다른 "*House"를 추가하십시오., 이는 코드가 UDP를 통해 기록하는 형식으로 정확하게 측정항목을 수신합니다. 그런 다음 이 *House는 이를 KittenHouse가 이해하는 통나무와 같은 삽입물로 변환합니다. 그는 이러한 로그를 읽을 수 있는 ClickHouse에 완벽하게 전달할 수 있습니다.

Memcache, stats-daemon 및 로그 수집기 데이터베이스 구성표가 이 구성표로 대체되었습니다.

Memcache, stats-daemon 및 로그 수집기 데이터베이스 구성표가 이 구성표로 대체되었습니다.

• 여기에는 StatsHouse에 로컬로 작성된 코드의 디스패치가 있습니다.
• StatsHouse는 이미 SQL 삽입으로 변환된 UDP 측정항목을 KittenHouse에 일괄적으로 기록합니다.
• KittenHouse는 이를 ClickHouse로 보냅니다.
• 읽고 싶다면 StatsHouse를 우회하고 일반 SQL을 사용하여 ClickHouse에서 직접 읽습니다.

아직인가 실험, 그러나 우리는 그 결과가 마음에 듭니다. 계획의 문제를 해결하면 아마도 완전히 전환하게 될 것입니다. 개인적으로는 그러기를 바랍니다.

계획 철분을 아끼지 않는다. 더 적은 수의 서버가 필요하고 로컬 통계 데몬 및 로그 수집기가 필요하지 않지만 ClickHouse에는 현재 구성표보다 더 큰 서버가 필요합니다. 더 적은 수의 서버가 필요하지만 더 비싸고 더 강력해야 합니다..

배포

먼저 PHP 배포를 살펴보겠습니다. 우리는 개발 중입니다 자식: 사용 GitLab и TeamCity 배포용. 개발 브랜치는 마스터 브랜치로 병합되고, 테스트용 마스터 브랜치는 스테이징으로 병합되고, 스테이징에서 프로덕션으로 병합됩니다.

배포하기 전에 현재 프로덕션 브랜치와 이전 브랜치를 가져와 diff 파일을 고려합니다. 변경 사항: 생성, 삭제, 변경. 이 변경 사항은 전체 서버 제품군에 변경 사항을 신속하게 복제할 수 있는 특수 Copyfast 엔진의 binlog에 기록됩니다. 여기서 사용하는 것은 직접 복사하는 것이 아니라, 가십 복제, 한 서버가 가장 가까운 이웃, 이웃 등으로 변경 사항을 보낼 때. 이를 통해 전체 차량에서 수십 및 초 단위로 코드를 업데이트할 수 있습니다. 변경 사항이 로컬 복제본에 도달하면 이러한 패치를 해당 복제본에 적용합니다. 로컬 파일 시스템. 롤백도 동일한 방식으로 수행됩니다.

우리는 또한 kPHP를 많이 배포하고 있으며 자체 개발도 진행하고 있습니다. 자식 위의 다이어그램에 따르면. 이 이후로 HTTP 서버 바이너리, 그러면 diff를 생성할 수 없습니다. 릴리스 바이너리의 무게는 수백 MB입니다. 따라서 여기에는 또 다른 옵션이 있습니다. 버전은 다음에 기록됩니다. binlog 카피패스트. 빌드할 때마다 증가하고 롤백 중에도 증가합니다. 버전 서버에 복제됨. 로컬 copyfast는 새 버전이 binlog에 입력되었음을 확인하고 동일한 가십 복제를 통해 마스터 서버를 지치지 않고 조심스럽게 네트워크 전체에 로드를 분산시키면서 최신 버전의 바이너리를 가져옵니다. 다음 내용 우아한 재개 새 버전의 경우.

본질적으로 바이너리인 우리 엔진의 경우 구성표는 매우 유사합니다.

• git 마스터 브랜치;
• 바이너리 입력 뎁;
• 버전은 binlog copyfast에 기록됩니다.
• 서버에 복제됩니다.
• 서버는 새로운 .dep을 가져옵니다.
• dpkg -i;
• 새 버전으로 정상적으로 다시 시작됩니다.

차이점은 바이너리가 아카이브에 패키지되어 있다는 것입니다. 뎁, 그리고 펌핑할 때 그들은 dpkg -i 시스템에 배치됩니다. kPHP는 바이너리로 배포되고 엔진은 dpkg로 배포되는 이유는 무엇입니까? 그런 일이 일어났습니다. 작동합니다. 만지지 마세요.

유용한 링크 :

• Anton Kiryushkin의 보고서 “Vkontakte 시스템 관리자. 어떻게?" copyfast 및 gossip에 대한 세부 정보가 포함되어 있습니다.
• Yuri Nasretdinov의 보고서 “VK가 수만 대의 서버에서 ClickHouse에 데이터를 삽입하는 방법”.
• 내 보고서 "VKontakte의 예를 사용하여 성장하는 프로젝트의 아키텍처", 하지만 개발 관점에서는 하드웨어가 아닙니다.

Alexey Akulovich는 프로그램 위원회의 일원으로서 다음을 돕는 사람들 중 한 명입니다. PHP 러시아 17월 XNUMX일은 최근 PHP 개발자들에게 가장 큰 행사가 될 것입니다. 우리가 가진 멋진 PC를 보세요. 스피커 (그 중 XNUMX명은 PHP 코어를 개발하고 있습니다!) - PHP를 작성한다면 빼놓을 수 없는 부분인 것 같습니다.

출처 : habr.com