Најчесто поставувани прашања за архитектурата и работата на VKontakte

Историјата на создавањето на VKontakte е на Википедија; ја кажа самиот Павел. Се чини дека сите веќе ја знаат. За внатрешните работи, архитектурата и структурата на страницата на HighLoad++ Павел ми кажа уште во 2010 година. Оттогаш протекоа многу сервери, па ќе ги ажурираме информациите: ќе ги расечеме, ќе ги извадиме внатрешноста, ќе го измериме и ќе го погледнеме уредот VK од техничка гледна точка.

Алексеј Акулович (AterCattus) развивач на задниот дел во тимот на VKontakte. Транскриптот на овој извештај е колективен одговор на често поставуваните прашања за работата на платформата, инфраструктурата, серверите и интеракцијата меѓу нив, но не и за развојот, имено за железото. Посебно, за базите на податоци и што има VK наместо тоа, за собирање дневници и следење на целиот проект како целина. Детали под сечењето.

Повеќе од четири години се занимавам со секакви задачи поврзани со backend.

• Поставување, складирање, обработка, дистрибуција на медиуми: видео, пренос во живо, аудио, фотографии, документи.
• Инфраструктура, платформа, мониторинг на програмери, дневници, регионални кешови, CDN, комерцијален RPC протокол.
• Интеграција со надворешни услуги: притисни известувања, парсирање на надворешни врски, RSS feed.
• Помагање на колегите со различни прашања, чии одговори бараат нуркање во непознат код.

За тоа време, имав рака во многу компоненти на страницата. Сакам да го споделам ова искуство.

Општа архитектура

Сè, како и обично, започнува со сервер или група сервери кои прифаќаат барања.

Преден сервер

Предниот сервер прифаќа барања преку HTTPS, RTMP и WSS.

HTTPS - ова се барања за главните и мобилните веб-верзии на страницата: vk.com и m.vk.com и други официјални и неофицијални клиенти на нашиот API: мобилни клиенти, гласници. Имаме прием RTMP-сообраќај за преноси во живо со посебни предни сервери и WSS-врски за Streaming API.

За HTTPS и WSS на серверите вреди nginx. За емитувањата на RTMP, неодамна се префрливме на нашето сопствено решение киве, но тоа е надвор од опсегот на извештајот. За толеранција на грешки, овие сервери рекламираат вообичаени IP адреси и дејствуваат во групи така што ако има проблем на еден од серверите, барањата на корисниците да не се изгубат. За HTTPS и WSS, истите овие сервери го шифрираат сообраќајот со цел да преземат дел од оптоварувањето на процесорот врз себе.

Нема да зборуваме понатаму за WSS и RTMP, туку само за стандардните HTTPS барања, кои обично се поврзуваат со веб-проект.

Заднинската

Зад предната страна обично има задни сервери. Тие ги обработуваат барањата што предниот сервер ги добива од клиентите.

Тоа kPHP сервери, на кој работи HTTP демонот, бидејќи HTTPS е веќе дешифриран. kPHP е сервер кој работи на prefork модели: започнува главен процес, еден куп детски процеси, им дава приклучоци за слушање и тие ги обработуваат нивните барања. Во овој случај, процесите не се рестартираат помеѓу секое барање од корисникот, туку едноставно ја ресетираат нивната состојба на првобитната состојба со нулта вредност - барање по барање, наместо да се рестартира.

Дистрибуција на оптоварување

Сите наши позадини не се огромен базен на машини што можат да обработат секое барање. Ние тие поделени во посебни групи: општо, мобилен, api, видео, инсценирање... Проблемот на посебна група машини нема да влијае на сите други. Во случај на проблеми со видеото, корисникот кој слуша музика нема ни да знае за проблемите. На кој бекенд да се испрати барањето одлучува nginx на предната страна според конфигурацијата.

Метричко собирање и ребалансирање

За да разбереме колку автомобили треба да имаме во секоја група, ние не се потпирајте на QPS. Позадините се различни, имаат различни барања, секое барање има различна комплексност на пресметување на QPS. Затоа ние работиме со концептот на оптоварување на серверот како целина - на процесорот и перф.

Имаме илјадници такви сервери. Секој физички сервер води kPHP група за да ги рециклира сите јадра (бидејќи kPHP е со една нишка).

Сервер за содржина

CS или Content Server е складиште. CS е сервер кој складира датотеки, а исто така ги обработува поставените датотеки и сите видови синхрони задачи во заднина што му ги доделува главниот веб-фронт.

Имаме десетици илјади физички сервери кои складираат датотеки. Корисниците сакаат да поставуваат датотеки, а ние сакаме да ги складираме и споделуваме. Некои од овие сервери се затворени со специјални pu/pp сервери.

pu/pp

Ако го отворивте јазичето мрежа во VK, видовте pu/pp.

Што е pu/pp? Ако затвораме еден сервер по друг, тогаш постојат две опции за поставување и преземање датотека на серверот што бил затворен: директно преку http://cs100500.userapi.com/path или преку среден сервер - http://pu.vk.com/c100500/path.

Пу е историско име за поставување фотографии, а pp е прокси за фотографии. Односно, еден сервер е за прикачување фотографии, а друг е за прикачување. Сега не се вчитуваат само фотографии, туку и името е зачувано.

Овие сервери прекинете ги сесиите на HTTPSда го отстраните оптоварувањето на процесорот од складиштето. Исто така, бидејќи корисничките датотеки се обработуваат на овие сервери, колку помалку чувствителни информации се складирани на овие машини, толку подобро. На пример, клучеви за шифрирање HTTPS.

Бидејќи машините се затворени од нашите други машини, можеме да си дозволиме да не им даваме „бели“ надворешни IP-адреси, и дај „сиво“. На овој начин заштедивме на IP базенот и гарантиравме дека ќе ги заштитиме машините од надворешен пристап - едноставно нема IP за да влеземе во него.

Отпорност на споделени IP адреси. Во однос на толеранцијата на грешки, шемата функционира исто - неколку физички сервери имаат заедничка физичка IP адреса, а хардверот пред нив избира каде да го испрати барањето. Подоцна ќе зборувам за други опции.

Контроверзната поента е дека во овој случај клиентот одржува помалку врски. Ако има иста IP адреса за неколку машини - со ист хост: pu.vk.com или pp.vk.com, клиентскиот прелистувач има ограничување на бројот на истовремени барања до еден хост. Но, во времето на сеприсутниот HTTP/2, верувам дека ова веќе не е толку релевантно.

Очигледниот недостаток на шемата е тоа што мора пумпа целиот сообраќај, кој оди во складиштето, преку друг сервер. Бидејќи го пумпаме сообраќајот преку машини, сè уште не можеме да пумпаме густ сообраќај, на пример, видео, користејќи ја истата шема. Го пренесуваме директно - посебна директна врска за посебни складишта специјално за видео. Пренесуваме полесна содржина преку прокси.

Не така одамна добивме подобрена верзија на прокси. Сега ќе ви кажам како тие се разликуваат од обичните и зошто е тоа неопходно.

Сонцето

Во септември 2017 година, Oracle, која претходно ја купи Sun, отпушти огромен број вработени во Sun. Можеме да кажеме дека во овој момент компанијата престана да постои. При изборот на име за новиот систем, нашите администратори решија да му оддадат почит на споменот на оваа компанија и го нарекоа новиот систем Сонце. Помеѓу себе едноставно ја нарекуваме „сонца“.

пп имаше неколку проблеми. Една IP по група - неефикасен кеш. Неколку физички сервери споделуваат заедничка IP адреса и не постои начин да се контролира на кој сервер ќе оди барањето. Затоа, ако различни корисници доаѓаат за иста датотека, тогаш ако има кеш на овие сервери, датотеката завршува во кешот на секој сервер. Ова е многу неефикасна шема, но ништо не можеше да се направи.

Следствено - не можеме да ја разделиме содржината, бидејќи не можеме да избереме одреден сервер за оваа група - тие имаат заедничка IP адреса. Исто така од некои внатрешни причини имаме не беше можно да се инсталираат такви сервери во региони. Застанаа само во Санкт Петербург.

Со сонцата го сменивме системот на селекција. Сега имаме anycast рутирање: динамично рутирање, билокаст, демон за самопроверка. Секој сервер има своја индивидуална IP адреса, но заедничка подмрежа. Сè е конфигурирано на таков начин што ако еден сервер не успее, сообраќајот автоматски се шири низ другите сервери од истата група. Сега е можно да се избере одреден сервер, нема излишно кеширање, а сигурноста не беше засегната.

Поддршка за тежина. Сега можеме да си дозволиме да инсталираме машини со различна моќност по потреба, а исто така, во случај на привремени проблеми, да ги менуваме тежините на работните „сонца“ за да го намалиме оптоварувањето на нив, за тие да се „одморат“ и повторно да почнат да работат.

Споделување по ID на содржина. Смешна работа во врска со споделувањето: ние обично ја делиме содржината така што различни корисници одат до истата датотека преку истото „сонце“ за да имаат заеднички кеш.

Неодамна ја лансиравме апликацијата „Детелина“. Ова е онлајн квиз во директен пренос, каде водителот поставува прашања, а корисниците одговараат во реално време, избирајќи опции. Апликацијата има разговор каде што корисниците можат да разговараат. Може истовремено да се поврзе со емитувањето повеќе од 100 илјади луѓе. Сите тие пишуваат пораки кои се испраќаат до сите учесници, а заедно со пораката доаѓа и аватар. Ако 100 илјади луѓе дојдат по еден аватар на едно „сонце“, тогаш тој понекогаш може да се тркала зад облак.

За да ги издржиме напливот на барања за иста датотека, токму за одреден тип на содржина вклучуваме глупава шема која шири датотеки низ сите достапни „сонца“ во регионот.

Сонце од внатре

Обратен прокси на nginx, кеш или во RAM или на брзи Optane/NVMe дискови. Пример: http://sun4-2.userapi.com/c100500/path — линк до „сонцето“, кое се наоѓа во четвртиот регион, втората серверска група. Ја затвора датотеката за патека, која физички лежи на серверот 100500.

Кеш

Додаваме уште еден јазол на нашата архитектонска шема - околината за кеширање.

Подолу е дијаграмот за распоред регионални кешови, ги има околу 20. Ова се местата каде што се наоѓаат кешовите и „сонцата“, кои можат да го кешираат сообраќајот преку себе.

Ова е кеширање на мултимедијални содржини; овде не се зачувуваат кориснички податоци - само музика, видео, фотографии.

За да го одредиме регионот на корисникот, ние собираме BGP мрежни префикси објавени во регионите. Во случај на резервна копија, ние исто така треба да ја анализираме базата на податоци geoip ако не можеме да ја најдеме IP-а по префикси. Регионот го одредуваме според IP на корисникот. Во кодот, можеме да погледнеме еден или повеќе региони на корисникот - оние точки до кои тој е најблиску географски.

Како тоа функционира?

Ја броиме популарноста на датотеките по регион. Има голем број од регионалниот кеш каде што се наоѓа корисникот и идентификатор на датотека - го земаме овој пар и ја зголемуваме оцената со секое преземање.

Во исто време, демоните - услуги во региони - од време на време доаѓаат на API и велат: „Јас сум таков и таков кеш, дајте ми список со најпопуларните датотеки во мојот регион што сè уште не се на мене. ” API испорачува куп датотеки подредени по рејтинг, демонот ги презема, ги носи во регионите и ги доставува датотеките од таму. Ова е основната разлика помеѓу pu/pp и Sun од кешот: тие веднаш ја даваат датотеката преку себе, дури и ако оваа датотека не е во кешот, а кешот прво ја презема датотеката во себе, а потоа почнува да ја враќа назад.

Во овој случај добиваме содржина поблиска до корисниците и ширење на оптоварувањето на мрежата. На пример, само од кешот на Москва дистрибуираме повеќе од 1 Tbit/s за време на шпицот.

Но, има проблеми - кеш серверите не се гумени. За супер популарна содржина, понекогаш нема доволно мрежа за посебен сервер. Нашите кеш сервери се 40-50 Gbit/s, но има содржина што целосно го затнува таков канал. Се движиме кон имплементирање на складирање на повеќе од една копија на популарни датотеки во регионот. Се надевам дека ќе го спроведеме до крајот на годината.

Ја разгледавме општата архитектура.

• Предни сервери кои прифаќаат барања.
• Бекандови кои обработуваат барања.
• Складирање кои се затворени од два вида прокси.
• Регионални кешови.

Што недостасува на овој дијаграм? Се разбира, базите на податоци во кои складираме податоци.

Бази на податоци или мотори

Ние ги нарекуваме не бази на податоци, туку мотори - Мотори, бидејќи практично немаме бази на податоци во општо прифатена смисла.

Ова е неопходна мерка. Ова се случи затоа што во 2008-2009 година, кога VK имаше експлозивен раст на популарноста, проектот работеше целосно на MySQL и Memcache и имаше проблеми. MySQL сакаше да паѓа и корумпира датотеки, по што немаше да се опорави, а Memcache постепено се деградираше во перформансите и мораше да се рестартира.

Излегува дека сè попопуларниот проект имал постојано складирање, кое ги корумпира податоците и кеш, што забавува. Во такви услови, тешко е да се развие проект кој расте. Беше решено да се обидеме да ги преработиме критичните работи на кои беше фокусиран проектот на нашите сопствени велосипеди.

Решението беше успешно. Имаше можност да се направи ова, како и крајна неопходност, бидејќи во тоа време не постоеја други начини на скалирање. Немаше куп бази на податоци, NoSQL сè уште не постоеше, имаше само MySQL, Memcache, PostrgreSQL - и тоа е тоа.

Универзална работа. Развојот беше предводен од нашиот тим на C програмери и сè беше направено на доследен начин. Без разлика на моторот, сите тие имаа приближно ист формат на датотека запишан на дискот, исти параметри за лансирање, ги обработуваа сигналите на ист начин и се однесуваа приближно исто во случај на ситуации и проблеми на работ. Со растот на моторите, на администраторите им е погодно да управуваат со системот - нема зоолошка градина што треба да се одржува и тие мора повторно да научат како да управуваат со секоја нова база на податоци од трети страни, што овозможи брзо и погодно зголемете го нивниот број.

Видови мотори

Тимот напиша доста мотори. Еве само некои од нив: пријател, совети, слика, ipdb, букви, списоци, дневници, мемкеширани, meowdb, вести, нострадамус, фотографија, плејлисти, pmemcached, песок, пребарување, складирање, допаѓања, задачи,…

За секоја задача која бара специфична структура на податоци или обработува нетипични барања, тимот C пишува нов мотор. Зошто да не.

Имаме посебен мотор мемориран, кој е сличен на обичен, но со еден куп добрите, и кој не успорува. Не ClickHouse, но исто така работи. Достапно посебно pmemcached - Дали упорен мемкеширан, кој исто така може да складира податоци на дискот, згора на тоа, отколку што се вклопува во RAM меморијата, за да не се губат податоците при рестартирање. Постојат различни мотори за поединечни задачи: редици, списоци, сетови - сè што бара нашиот проект.

Кластери

Од гледна точка на код, нема потреба да се размислува за мотори или бази на податоци како процеси, ентитети или примери. Кодот работи специјално со кластери, со групи мотори - еден тип по кластер. Да речеме дека постои мемкеширан кластер - тоа е само група машини.

Кодот воопшто не треба да ја знае физичката локација, големината или бројот на сервери. Тој оди во кластерот користејќи одреден идентификатор.

За да функционира ова, треба да додадете уште еден ентитет кој се наоѓа помеѓу кодот и моторите - прокси.

RPC прокси

Прокси поврзување автобус, на кој работи речиси целиот сајт. Во исто време имаме нема откритие за услуга — наместо тоа, постои конфигурација за овој прокси, кој ја знае локацијата на сите кластери и сите делови од овој кластер. Ова е она што го прават администраторите.

На програмерите воопшто не им е грижа колку, каде и што чини - тие само одат во кластерот. Ова ни дозволува многу. Кога прима барање, полномошникот го пренасочува барањето, знаејќи каде - тоа сам го одредува.

Во овој случај, прокси е точка на заштита од откажување на услугата. Ако некој мотор успори или падне, тогаш проксито го разбира ова и соодветно реагира на страната на клиентот. Ова ви овозможува да го отстраните истекот на времето - кодот не чека моторот да одговори, туку разбира дека не работи и треба да се однесува некако поинаку. Кодот мора да биде подготвен за фактот дека базите на податоци не секогаш работат.

Специфични имплементации

Понекогаш навистина сакаме да имаме некакво нестандардно решение како мотор. Во исто време, беше одлучено да не го користиме нашиот готов rpc-прокси, создаден специјално за нашите мотори, туку да направиме посебен прокси за задачата.

За 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;

Ова е бинарен протокол, чиј најблизок аналог е протобуф. Шемата предопишува изборни полиња, сложени типови - екстензии на вградени скалари и прашања. Сè работи според овој протокол.

RPC преку TL преку TCP/UDP… UDP?

Имаме протокол RPC за извршување на барања за мотор кој работи на врвот на шемата TL. Сето ова работи преку TCP/UDP конекција. TCP е разбирлив, но зошто често ни треба UDP?

UDP помага избегнувајте го проблемот со огромен број врски помеѓу серверите. Ако секој сервер има RPC прокси и, генерално, може да оди на кој било мотор, тогаш има десетици илјади TCP конекции по сервер. Има товар, но е бескорисен. Во случај на UDP овој проблем не постои.

Нема излишно TCP ракување. Ова е типичен проблем: кога се стартува нов мотор или нов сервер, многу TCP конекции се воспоставуваат одеднаш. За мали лесни барања, на пример, UDP носивост, целата комуникација помеѓу кодот и моторот е два UDP пакети: едниот лета во еден правец, вториот во другиот. Едно кружно патување - и кодот доби одговор од моторот без ракување.

Да, сето тоа само функционира со многу мал процент на загуба на пакети. Протоколот има поддршка за реемитувања и тајмаути, но ако изгубиме многу, ќе добиеме скоро TCP, што не е профитабилно. Ние не возиме UDP низ океаните.

Имаме илјадници такви сервери, а шемата е иста: на секој физички сервер е инсталиран пакет мотори. Тие се претежно со една нишка за да работат што е можно побрзо без блокирање, и се делат како решенија со една нишка. Во исто време, немаме ништо посигурно од овие мотори, а многу внимание се посветува на постојаното складирање на податоци.

Постојано складирање на податоци

Моторите пишуваат бинлогови. Бинлог е датотека на крајот на која се додава настан за промена на состојбата или податоците. Во различни решенија тоа се нарекува поинаку: бинарен дневник, Вол, АОФ, но принципот е ист.

За да се спречи моторот да го препрочитува целиот бинлог многу години при рестартирање, пишуваат моторите снимки - моментална состојба. Ако треба, прво читаат од него, а потоа завршуваат со читање од бинлог. Сите бинлогови се напишани во ист бинарен формат - според шемата TL, така што администраторите можат подеднакво да ги администрираат користејќи ги нивните алатки. Нема таква потреба од снимки. Постои општо заглавие што покажува чија слика е int, магија на моторот и кое тело не е важно за никого. Ова е проблем со моторот што ја снимил снимката.

Јас брзо ќе го опишам принципот на работа. Има сервер на кој работи моторот. Отвора нов празен бинлог за пишување и пишува настан за промена на него.

Во одреден момент, тој или решава самиот да направи снимка, или добива сигнал. Серверот создава нова датотека, ја запишува целата нејзина состојба во неа, ја додава тековната големина на бинлог - офсет - на крајот на датотеката и продолжува понатаму да пишува. Нов бинлог не е создаден.

Во одреден момент, кога моторот ќе се рестартира, ќе има и бинлог и слика на дискот. Моторот ја чита целата слика и ја подигнува неговата состојба во одредена точка.

Ја чита позицијата што била во моментот кога била креирана снимката и големината на бинлогот.

Го чита крајот на бинлогот за да ја добие моменталната состојба и продолжува да пишува понатамошни настани. Ова е едноставна шема; сите наши мотори работат според неа.

Репликација на податоци

Како резултат на тоа, репликација на податоците во нашата заснована на изјави — во бинлогот не пишуваме никакви промени на страницата, туку имено барања за промена. Многу слично на она што доаѓа преку мрежата, само малку изменето.

Истата шема се користи не само за репликација, туку и да креирате резервни копии. Имаме мотор - мајстор за пишување што пишува во бинлог. На кое било друго место каде што го поставиле администраторите, овој бинлог се копира и тоа е тоа - имаме резервна копија.

Ако е потребно читање репликаЗа да се намали оптоварувањето за читање на процесорот, едноставно се активира моторот за читање, кој го чита крајот на бинлогот и ги извршува овие команди локално.

Заостанувањето овде е многу мало и можно е да се открие колку репликата заостанува зад мајсторот.

Споделување податоци во RPC прокси

Како функционира делењето? Како проксито разбира до кој фрагмент од кластер да испрати? Кодот не вели: „Испрати за 15 парчиња!“ - не, ова го прави полномошникот.

Наједноставната шема е firstint — првиот број во барањето.

get(photo100_500) => 100 % N.

Ова е пример за едноставен мемкеширан текстуален протокол, но, се разбира, барањата можат да бидат сложени и структурирани. Примерот го зема првиот број во барањето, а остатокот кога се дели со големината на кластерот.

Ова е корисно кога сакаме да имаме локалитет на податоци на еден ентитет. Да речеме дека 100 е кориснички или групен ID и сакаме сите податоци на еден ентитет да бидат на еден фрагмент за сложени прашања.

Ако не ни е грижа како барањата се шират низ кластерот, постои друга опција - хеширање на целиот фрагмент.

hash(photo100_500) => 3539886280 % N

Го добиваме и хашот, остатокот од поделбата и бројот на фрагментот.

И двете од овие опции функционираат само ако сме подготвени за фактот дека кога ќе ја зголемиме големината на кластерот, ќе го поделиме или ќе го зголемиме за повеќекратно. На пример, имавме 16 парчиња, немаме доволно, сакаме повеќе - можеме безбедно да добиеме 32 без застој. Ако сакаме да не зголемиме повеќекратно, ќе има прекини, бидејќи нема да можеме точно да поделиме сè без загуби. Овие опции се корисни, но не секогаш.

Ако треба да додадеме или отстраниме произволен број на сервери, ние користиме Доследно хаширање на прстенот а ла Кетама. Но, во исто време, целосно ја губиме локалитетот на податоците; мораме да го споиме барањето во кластерот така што секое парче враќа свој мал одговор, а потоа да ги споиме одговорите со прокси.

Има супер-специфични барања. Изгледа вака: RPC прокси го прима барањето, одредува во кој кластер да оди и го одредува делот. Потоа, има или мајстори за пишување, или, ако кластерот има поддршка за реплика, тој испраќа до реплика на барање. Сето ова го прави прокси.

Дневници

Ние пишуваме дневници на неколку начини. Најочигледниот и наједноставниот е пишувајте дневници во мемкешот.

ring-buffer: prefix.idx = line

Постои клучен префикс - името на дневникот, линија, а има и големината на овој дневник - бројот на линии. Земаме случаен број од 0 до бројот на линии минус 1. Клучот во мемкешот е префикс споен со овој случаен број. Ја зачувуваме линијата за дневник и тековното време на вредноста.

Кога е неопходно да се прочитаат дневници, ние извршуваме Multi Get сите клучеви, подредени по време, и на тој начин добивате дневник за производство во реално време. Шемата се користи кога треба да дебагирате нешто во производството во реално време, без да прекршите ништо, без да застанете или да дозволите сообраќај кон други машини, но овој дневник не трае долго.

За сигурно складирање на трупци имаме мотор трупци-мотор. Токму затоа е создаден и широко се користи во огромен број кластери. Најголемиот кластер што го знам за складирање на 600 ТБ спакувани трупци.

Моторот е многу стар, има кластери кои се веќе 6-7 години. Има проблеми со него што се обидуваме да ги решиме, на пример, почнавме активно да го користиме ClickHouse за складирање на дневници.

Собирање логови во ClickHouse

Овој дијаграм покажува како влегуваме во нашите мотори.

Има код што оди локално преку RPC до RPC-прокси-прокси, и разбира каде да оди до моторот. Ако сакаме да пишуваме дневници во ClickHouse, треба да смениме два дела во оваа шема:

• замени некој мотор со ClickHouse;
• заменете го проксито RPC, кое не може да пристапи до ClickHouse, со некое решение што може, и преку RPC.

Моторот е едноставен - го заменуваме со сервер или кластер сервери со ClickHouse.

И да одиме во ClickHouse, го направивме тоа Куќа за мачиња. Ако одиме директно од KittenHouse во ClickHouse, тоа нема да се справи. Дури и без барања, се собира од HTTP конекции на огромен број машини. За шемата да работи, на сервер со ClickHouse локалниот обратен прокси е подигнат, кој е напишан на таков начин што може да ги издржи потребните волумени на врски. Исто така, може релативно сигурно да ги тампонира податоците во себе.

Понекогаш не сакаме да ја имплементираме шемата RPC во нестандардни решенија, на пример, во nginx. Затоа, KittenHouse има можност да прима логови преку UDP.

Ако испраќачот и примачот на дневниците работат на иста машина, тогаш веројатноста за губење на UDP пакет во локалниот хост е прилично мала. Како компромис помеѓу потребата да се имплементира RPC во решение од трета страна и доверливоста, ние едноставно користиме испраќање UDP. Подоцна ќе се вратиме на оваа шема.

Мониторинг

Имаме два вида дневници: оние што ги собираат администраторите на нивните сервери и оние напишани од програмерите од код. Тие одговараат на два вида метрика: систем и производ.

Системска метрика

Работи на сите наши сервери Нет-податоци, кој собира статистика и ги испраќа до Графит јаглерод. Затоа, ClickHouse се користи како систем за складирање, а не Whisper, на пример. Доколку е потребно, можете директно да читате од 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)

Последователно, можеме да користиме филтри за сортирање и групирање и да правиме сè што сакаме од статистиката - да градиме графикони, да ги конфигурираме Watchdogs.

Многу пишуваме многу метрики бројот на настани е од 600 милијарди до 1 трилион дневно. Сепак, сакаме да ги задржиме барем неколку годинида ги разбере трендовите во метриката. Соединувањето на сето тоа е голем проблем што сè уште не сме го решиле. Ќе ви кажам како функционира во последните неколку години.

Имаме функции кои ги пишуваат овие метрики до локалната мемкешда се намали бројот на записи. Еднаш во краток временски период локално лансиран статистика-демон ги собира сите записи. Следно, демонот ги спојува метриките во два слоја на сервери трупци-собирачи, кој собира статистика од еден куп наши машини за да не изумре слојот зад нив.

Доколку е потребно, можеме директно да пишуваме до собирачите на дневници.

Но, пишувањето од код директно до колектори, заобиколувајќи го stas-daemom, е слабо скалабилно решение бидејќи го зголемува оптоварувањето на колекторот. Решението е погодно само ако поради некоја причина не можеме да ја подигнеме статистиката-демонот на мемкешот на машината, или таа се урна и отидовме директно.

Следно, логовите-собирачи ја спојуваат статистиката во meowDB - ова е нашата база на податоци, која исто така може да складира метрика.

Потоа можеме да направиме бинарни избори „близу SQL“ од кодот.

Експеримент

Во летото 2018 година имавме внатрешен хакатон и дојде идејата да се обидеме да го замениме црвениот дел од дијаграмот со нешто што може да складира метрика во ClickHouse. Имаме дневници на ClickHouse - зошто да не го пробате?

Имавме шема која пишуваше дневници преку KittenHouse.

Ние одлучивме додадете уште една „*Куќа“ на дијаграмот, кои ќе ги добијат точно метриките во формат како што нашиот код ги запишува преку UDP. Потоа оваа *Куќа ги претвора во инсерти, како трупци, кои KittenHouse ги разбира. Тој може совршено да ги достави овие логови до ClickHouse, кој треба да може да ги чита.

Шемата со база на податоци за мемкеш, stats-daemon и logs-collectors е заменета со оваа.

Шемата со база на податоци за мемкеш, stats-daemon и logs-collectors е заменета со оваа.

• Овде има испраќање од код, кој е напишан локално во StatsHouse.
• StatsHouse пишува UDP метрика, веќе конвертирани во SQL инсерти, во KittenHouse во серии.
• KittenHouse ги испраќа до ClickHouse.
• Ако сакаме да ги читаме, тогаш ги читаме заобиколувајќи го StatsHouse - директно од ClickHouse користејќи обичен SQL.

Дали е сеуште експеримент, но ни се допаѓа како излегува. Ако ги поправиме проблемите со шемата, тогаш можеби целосно ќе се префрлиме на неа. Лично, се надевам дека е така.

Шемата не штеди железо. Потребни се помалку сервери, не се потребни локални статистики-демони и логови-собирачи, но ClickHouse бара поголем сервер од оние во тековната шема. Потребни се помалку сервери, но тие мора да бидат поскапи и помоќни.

Распоредување

Прво, да го погледнеме распоредувањето на PHP. Ние се развиваме во оди: употреба GitLab и Тимски тим за распоредување. Развојните гранки се спојуваат во главната гранка, од мајсторот за тестирање се спојуваат во постановка, а од постановката во производството.

Пред распоредувањето, се земаат тековната производствена гранка и претходната, а во нив се разгледуваат различни датотеки - промени: креирани, избришани, изменети. Оваа промена е снимена во бинлогот на специјален copyfast мотор, кој може брзо да ги повтори промените на целата наша флота на сервери. Она што се користи овде не е директно копирање, туку репликација на озборувања, кога еден сервер испраќа промени до своите најблиски соседи, оние до нивните соседи итн. Ова ви овозможува да го ажурирате кодот во десетици и единици од секунди низ целата флота. Кога промената ќе стигне до локалната реплика, таа ги применува овие закрпи на нејзината локален датотечен систем. Враќањето исто така се врши според истата шема.

Ние, исто така, распоредуваме многу kPHP и исто така има свој сопствен развој оди според дијаграмот погоре. Од ова Бинарен HTTP сервер, тогаш не можеме да произведеме разлика - бинарното издание тежи стотици MB. Затоа, тука има уште една опција - верзијата е напишана на бинлог copyfast. Со секое градење се зголемува, а при враќање исто така се зголемува. Верзија се реплицира на серверите. Локалните копифаст гледаат дека нова верзија е влезена во бинлогот, и со истата репликација на озборувања ја земаат за себе најновата верзија на бинарникот, без да го заморат нашиот главен сервер, туку внимателно да го шират товарот низ мрежата. Што следи грациозно повторно стартување за новата верзија.

За нашите мотори, кои исто така се во суштина бинарни, шемата е многу слична:

• git master гранка;
• бинарни во .deb;
• верзијата е напишана во binlog copyfast;
• реплицирано на сервери;
• серверот вади свеж .dep;
• дпкг -и;
• грациозно повторно стартување на новата верзија.

Разликата е во тоа што нашиот бинар е спакуван во архиви .deb, и при испумпување тие дпкг -и се поставени на системот. Зошто kPHP е распореден како бинарен, а моторите се распоредени како dpkg? Така се случи. Работи - не го допирајте.

Корисни врски:

• Извештај на Антон Кирјушкин „Системски администратор Vkontakte. Како?" со детали за copyfast и озборувања.
• Извештај на Јуриј Насретдинов „Како VK вметнува податоци во CLickHouse од десетици илјади сервери“.
• Мојот извештај „Архитектура на растечки проект користејќи го примерот на VKontakte“, но од развојна гледна точка, не хардвер.

Алексеј Акулович е еден од оние кои како дел од Програмскиот комитет помага PHP Русија на 17-ти мај ќе стане најголемиот настан за програмерите на PHP во последно време. Погледнете каков кул компјутер имаме, што звучници (двајца од нив развиваат PHP јадро!) - изгледа како нешто што не можете да го пропуштите ако напишете PHP.

Извор: www.habr.com