🥇Честа питања о архитектури и раду на ВКонтактеу

Историја стварања ВКонтактеа је на Википедији, испричао ју је сам Павел. Чини се да је сви већ знају. О унутрашњости, архитектури и структури сајта на ХигхЛоад++ Павел рекао ми је још 2010. Многи сервери су од тада процурили, па ћемо ажурирати информације: сецираћемо их, извадити унутрашњост, измерити и погледати ВК уређај са техничке тачке гледишта.

Алексеј Акулович (АтерЦаттус) бацкенд програмер у тиму ВКонтакте. Транскрипт овог извештаја је збирни одговор на често постављана питања о раду платформе, инфраструктури, серверима и интеракцији између њих, али не и о развоју, тј. о гвожђу. Одвојено, о базама података и ономе што ВК има уместо тога, о прикупљању логова и праћењу целог пројекта у целини. Детаљи испод реза.

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

Отпремање, складиштење, обрада, дистрибуција медија: видео, ливе стреаминг, аудио, фотографије, документи.
Инфраструктура, платформа, надгледање програмера, логови, регионални кешови, ЦДН, власнички РПЦ протокол.
Интеграција са спољним сервисима: пусх обавештења, рашчлањивање екстерних линкова, РСС феед.
Помагање колегама у разним питањима, чији одговори захтевају зарон у непознати код.

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

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

Све, као и обично, почиње са сервером или групом сервера који прихватају захтеве.

Предњи сервер

Предњи сервер прихвата захтеве преко ХТТПС, РТМП и ВСС.

ХТТПС - ово су захтеви за главну и мобилну веб верзију сајта: вк.цом и м.вк.цом и друге званичне и незваничне клијенте нашег АПИ-ја: мобилне клијенте, месинџере. Имамо пријем РТМП-саобраћај за преносе уживо са одвојеним предњим серверима и ВСС- везе за Стреаминг АПИ.

За ХТТПС и ВСС на серверима вреди Апацхе. За РТМП емитовање, недавно смо прешли на сопствено решење киве, али то је ван оквира извештаја. Ради толеранције грешака, ови сервери оглашавају заједничке ИП адресе и делују у групама, тако да ако дође до проблема на једном од сервера, захтеви корисника се не изгубе. За ХТТПС и ВСС, ови исти сервери шифрују саобраћај како би преузели део оптерећења ЦПУ-а на себе.

Нећемо даље говорити о ВСС и РТМП-у, већ само о стандардним ХТТПС захтевима, који су обично повезани са веб пројектом.

Бацкенд

Иза фронта се обично налазе бацкенд сервери. Они обрађују захтеве које предњи сервер прима од клијената.

Она кПХП сервери, на којој је покренут ХТТП демон, јер је ХТТПС већ дешифрован. кПХП је сервер који ради на модели предвила: покреће главни процес, гомилу подређених процеса, прослеђује им слушалице и они обрађују њихове захтеве. У овом случају, процеси се не покрећу поново између сваког захтева од корисника, већ једноставно ресетују своје стање на првобитно стање нулте вредности – захтев за захтевом, уместо поновног покретања.

Расподела оптерећења

Сви наши бацкендови нису огромна група машина која може да обради било који захтев. Ми њих подељени у посебне групе: генерал, мобиле, апи, видео, стагинг... Проблем на посебној групи машина неће утицати на све остале. У случају проблема са видеом, корисник који слуша музику неће ни знати за проблеме. Кому позадину послати захтев одлучује нгинк на предњој страни према конфигурацији.

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

Да бисмо разумели колико аутомобила треба да имамо у свакој групи, ми не ослањајте се на КПС. Позадине су различите, имају различите захтеве, сваки захтев има различиту сложеност израчунавања КПС-а. Зато ми радимо са концептом оптерећења на серверу у целини – на ЦПУ-у и перф.

Имамо хиљаде таквих сервера. Сваки физички сервер покреће кПХП групу да рециклира сва језгра (јер је кПХП једнонитни).

Цонтент Сервер

ЦС или Цонтент Сервер је складиште. ЦС је сервер који складишти датотеке и такође обрађује отпремљене датотеке и све врсте позадинских синхроних задатака које му додељује главни веб фронтенд.

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

пу/пп

Ако сте отворили картицу мреже у ВК, видели сте пу/пп.

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

Пу је историјски назив за отпремање фотографија, а пп је прокси за фотографије. То јест, један сервер је за отпремање фотографија, а други за постављање. Сада се не само учитавају фотографије, већ је и име сачувано.

Ови сервери прекинути ХТТПС сесиједа бисте уклонили оптерећење процесора из складишта. Такође, пошто се корисничке датотеке обрађују на овим серверима, што су мање осетљиве информације ускладиштене на овим машинама, то боље. На пример, ХТТПС кључеви за шифровање.

Пошто су машине затворене од стране наших других машина, можемо себи приуштити да им не дамо „беле“ екстерне ИП адресе, и дати "сиво". На овај начин смо уштедели на ИП групи и гарантовали да заштитимо машине од спољног приступа - једноставно не постоји ИП да се у њега уђе.

Отпорност на дељене ИП адресе. Што се тиче толеранције грешака, шема функционише исто – неколико физичких сервера има заједничку физичку ИП адресу, а хардвер испред њих бира где ће послати захтев. О другим опцијама ћу касније.

Контроверзна ствар је да у овом случају клијент задржава мање веза. Ако постоји исти ИП за више машина - са истим хостом: пу.вк.цом или пп.вк.цом, претраживач клијента има ограничење на број истовремених захтева ка једном хосту. Али у време свеприсутног ХТТП/2, верујем да то више није толико релевантно.

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

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

Ned

У септембру 2017. Орацле, који је претходно купио Сун, отпустио огроман број запослених у Суну. Можемо рећи да је у овом тренутку компанија престала да постоји. Приликом избора имена за нови систем наши администратори су одлучили да одају почаст сећању на ову компанију и нови систем назвали Сунце. Међу собом је једноставно називамо „сунцима“.

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

Стога - не можемо делити садржај, јер не можемо да изаберемо одређени сервер за ову групу - они имају заједнички ИП. Такође из неких унутрашњих разлога имамо није било могуће инсталирати такве сервере у регионима. Стајали су само у Санкт Петербургу.

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

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

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

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

Да бисмо издржали рафале захтева за исту датотеку, за одређену врсту садржаја укључујемо глупу шему која шири датотеке по свим доступним „сунцима“ у региону.

Сунце изнутра

Обрнути прокси на нгинк-у, кеш или у РАМ-у или на брзим Оптане/НВМе дисковима. Пример: http://sun4-2.userapi.com/c100500/path — веза ка „сунцу“, које се налази у четвртом региону, другој групи сервера. Затвара датотеку путање која се физички налази на серверу 100500.

Цацхе

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

Испод је дијаграм распореда регионалне кеш меморије, има их око 20. То су места на којима се налазе кешови и „сунца“, који могу да кеширају саобраћај кроз себе.

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

Да бисмо одредили регион корисника, ми прикупљамо БГП мрежне префиксе најављене у регионима. У случају резервног, такође морамо да анализирамо геоип базу података ако не можемо да пронађемо ИП по префиксима. Одређујемо регион према ИП-у корисника. У коду можемо погледати један или више региона корисника – оних тачака којима је географски најближи.

Како то функционише?

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

Истовремено, демони - сервиси у регионима - с времена на време долазе у АПИ и кажу: „Ја сам такав и такав кеш, дајте ми листу најпопуларнијих фајлова у мом региону који још нису код мене. ” АПИ испоручује гомилу фајлова сортираних по рејтингу, демон их преузима, преноси у регионе и испоручује датотеке одатле. Ово је фундаментална разлика између пу/пп и Сун од кеша: они одмах дају датотеку кроз себе, чак и ако ова датотека није у кешу, а кеш прво преузима датотеку на себе, а затим почиње да је враћа.

У овом случају добијамо садржај ближи корисницима и ширење оптерећења мреже. На пример, само из московске кеш меморије дистрибуирамо више од 1 Тбит/с током вршних сати.

Али постоје проблеми - кеш сервери нису гумени. За супер популаран садржај, понекад нема довољно мреже за посебан сервер. Наши кеш сервери су 40-50 Гбит/с, али постоји садржај који потпуно запуши такав канал. Идемо ка имплементацији складиштења више од једне копије популарних датотека у региону. Надам се да ћемо то спровести до краја године.

Погледали смо општу архитектуру.

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

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

Базе података или машине

Називамо их не базама података, већ машинама – Машинама, јер базе података у општеприхваћеном смислу практично немамо.

Ово је неопходна мера.. Ово се десило зато што је 2008-2009, када је ВК имао експлозиван раст популарности, пројекат је у потпуности радио на МиСКЛ и Мемцацхе-у и било је проблема. МиСКЛ је волео да руши и квари датотеке, након чега се не би опоравио, а Мемцацхе је постепено деградирао у перформансама и морао је да се поново покрене.

Испоставило се да је све популарнији пројекат имао упорну меморију која квари податке и кеш меморију која успорава. У таквим условима тешко је развити пројекат који расте. Одлучено је да покушамо да препишемо критичне ствари на које је пројекат био фокусиран на сопствене бицикле.

Решење је било успешно. Постојала је прилика да се то уради, али и крајња потреба, јер други начини скалирања у то време нису постојали. Није било гомиле база података, НоСКЛ још није постојао, постојали су само МиСКЛ, Мемцацхе, ПостргреСКЛ - и то је то.

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

Врсте мотора

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

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

Имамо посебан мотор мемцацхед, који је сличан обичном, али са гомилом доброта, и који не успорава. Није ЦлицкХоусе, али такође ради. Доступан одвојено пмемцацхед - Је персистент мемцацхед, који такође може да чува податке на диску, штавише, него што се уклапа у РАМ, како не би изгубио податке приликом поновног покретања. Постоје различити мотори за појединачне задатке: редови, листе, сетови - све што наш пројекат захтева.

Кластери

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

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

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

РПЦ проки

Заступник спојни аутобус, на којој ради скоро цео сајт. У исто време имамо нема откривања услуге — уместо тога, постоји конфигурација за овај прокси, која зна локацију свих кластера и свих делова овог кластера. Ово раде администратори.

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

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

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

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

За МиСКЛ, који још увек имамо ту и тамо, користимо дб-проки, а за ЦлицкХоусе - Киттенхоусе.

Уопштено ради овако. Постоји одређени сервер, он покреће кПХП, Го, Питхон - уопште, било који код који може да користи наш РПЦ протокол. Код се покреће локално на РПЦ проксију - сваки сервер на коме се налази код покреће свој локални прокси. На захтев, пуномоћник разуме где да иде.

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

Пример ТЛ-шеме према којој сви мотори раде.

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;

Ово је бинарни протокол, чији је најближи аналог протобуф. Шема унапред описује опциона поља, сложене типове – проширења уграђених скалара и упите. Све ради по овом протоколу.

РПЦ преко ТЛ преко ТЦП/УДП... УДП?

Имамо РПЦ протокол за извршавање захтева мотора који ради на врху ТЛ шеме. Све ово ради преко ТЦП/УДП везе. ТЦП је разумљив, али зашто нам је често потребан УДП?

УДП помаже избегавајте проблем великог броја веза између сервера. Ако сваки сервер има РПЦ проки и, генерално, може да иде на било који мотор, онда постоје десетине хиљада ТЦП веза по серверу. Постоји оптерећење, али је бескорисно. У случају УДП-а овај проблем не постоји.

Нема сувишног ТЦП руковања. Ово је типичан проблем: када се покрене нови мотор или нови сервер, много ТЦП веза се успоставља одједном. За мале лаке захтеве, на пример, УДП носивост, сва комуникација између кода и машине је два УДП пакета: један лети у једном правцу, други у другом. Једно кружно путовање - и код је добио одговор од мотора без руковања.

Да, све то ради са веома малим процентом губитка пакета. Протокол има подршку за ретрансмите и тајм-ауте, али ако изгубимо много, добићемо скоро ТЦП, што није исплативо. Не возимо УДП преко океана.

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

Трајно складиштење података

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

Да би спречили да мотор поново чита цео бинлог дуги низ година приликом поновног покретања, пишу мотори снимци - тренутно стање. Ако је потребно, прво читају из њега, а затим завршавају читање из бинлога. Сви бинлогови су написани у истом бинарном формату - према ТЛ шеми, тако да администратори могу једнако да их администрирају користећи своје алате. Нема такве потребе за снимцима. Постоји опште заглавље које показује чији је снимак инт, магија мотора и које тело никоме није важно. Ово је проблем са мотором који је снимио снимак.

Брзо ћу описати принцип рада. Постоји сервер на коме ради мотор. Он отвара нови празан бинлог за писање и уписује догађај за промену у њему.

У неком тренутку, он или одлучује да сам направи снимак, или добија сигнал. Сервер креира нову датотеку, уписује њено цело стање у њу, додаје тренутну величину бинлог-а - офсет - на крај датотеке и наставља даље писање. Нови бинлог није креиран.

У неком тренутку, када се мотор поново покрене, на диску ће бити и бинлог и снимак. Мотор чита цео снимак и подиже своје стање у одређеном тренутку.

Чита позицију која је била у време када је снимак направљен и величину бинлог-а.

Чита крај бинлог-а да добије тренутно стање и наставља да пише даље догађаје. Ово је једноставна шема; сви наши мотори раде по њој.

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

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

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

Ако је потребно читање репликеДа би се смањило оптерећење ЦПУ-а читањем, мотор за читање се једноставно покреће, који чита крај бинлог-а и извршава ове команде локално.

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

Дељење података у РПЦ проксију

Како функционише шардирање? Како прокси разуме који део кластера да пошаље? Код не каже: „Пошаљи по 15 комада!“ - не, ово ради пуномоћник.

Најједноставнија шема је фирстинт — први број у захтеву.

get(photo100_500) => 100 % N.

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

Ово је корисно када желимо да имамо локалитет података једног ентитета. Рецимо да је 100 ИД корисника или групе и желимо да сви подаци једног ентитета буду на једном шарду за сложене упите.

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

hash(photo100_500) => 3539886280 % N

Такође добијамо хеш, остатак дељења и број шарда.

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

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

Постоје супер-специфични захтеви. То изгледа овако: РПЦ прокси прима захтев, одређује на који кластер да иде и одређује шард. Затим постоје или мастери писања, или, ако кластер има подршку за реплику, шаље реплици на захтев. Прокси ради све ово.

Дневници

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

ring-buffer: prefix.idx = line

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

Када је потребно прочитати дневнике, вршимо Мулти Гет све кључеве, поређане по времену, и на тај начин добијају евиденцију производње у реалном времену. Шема се користи када треба да отклоните грешке у нечему у продукцији у реалном времену, без прекидања било чега, без заустављања или дозвољавања саобраћаја другим машинама, али овај дневник не траје дуго.

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

Мотор је веома стар, има кластера који су стари већ 6-7 година. Постоје проблеми са тим које покушавамо да решимо, на пример, почели смо да активно користимо ЦлицкХоусе за складиштење дневника.

Прикупљање дневника у ЦлицкХоусе-у

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

Постоји код који иде локално преко РПЦ-а до РПЦ-проксија, и разуме где да иде до мотора. Ако желимо да пишемо дневнике у ЦлицкХоусе, морамо да променимо два дела у овој шеми:

заменити неки мотор са ЦлицкХоусе;
замените РПЦ прокси, који не може да приступи ЦлицкХоусе-у, неким решењем које може и преко РПЦ-а.

Мотор је једноставан - замењујемо га сервером или кластером сервера са ЦлицкХоусе-ом.

И да одемо на ЦлицкХоусе, јесмо КиттенХоусе. Ако пређемо директно из КиттенХоусе у ЦлицкХоусе, неће се носити. Чак и без захтева, додаје се из ХТТП веза огромног броја машина. Да би шема функционисала, на серверу са ЦлицкХоусе локални обрнути прокси се подиже, који је написан тако да може да издржи потребне запремине прикључака. Такође може релативно поуздано баферовати податке унутар себе.

Понекад не желимо да имплементирамо РПЦ шему у нестандардна решења, на пример, у нгинк. Стога, КиттенХоусе има могућност да прима евиденције путем УДП-а.

Ако пошиљалац и прималац евиденције раде на истој машини, онда је вероватноћа губитка УДП пакета унутар локалног хоста прилично мала. Као компромис између потребе за имплементацијом РПЦ-а у решење треће стране и поузданости, једноставно користимо УДП слање. Касније ћемо се вратити на ову шему.

Праћење

Имамо две врсте евиденције: оне које прикупљају администратори на својим серверима и оне које пишу програмери из кода. Они одговарају двема врстама показатеља: систем и производ.

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

Ради на свим нашим серверима Нетдата, који прикупља статистичке податке и шаље их на Грапхите Царбон. Стога се ЦлицкХоусе користи као систем за складиштење, а не Вхиспер, на пример. Ако је потребно, можете директно читати из ЦлицкХоусе-а или користити Графана за метрике, графиконе и извештаје. Као програмери, имамо довољно приступа Нетдата и Графани.

метрика производа

Ради погодности, написали смо много ствари. На пример, постоји скуп обичних функција које вам омогућавају да упишете вредности Цоунтс, УникуеЦоунтс у статистику, које се шаљу негде даље.

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

$stats = statlogsStatData($params)

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

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

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

Ако је потребно, можемо писати директно сакупљачима дневника.

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

Затим, сакупљачи дневника спајају статистику меовДБ - ово је наша база података, која такође може да чува метрику.

Тада можемо направити бинарне селекције „неар-СКЛ“ из кода.

Експеримент

У лето 2018. имали смо интерни хакатон и дошла је идеја да покушамо да заменимо црвени део дијаграма нечим што би могло да чува метрику у ЦлицкХоусе-у. Имамо евиденције на ЦлицкХоусе - зашто не пробати?

Имали смо шему која је писала дневнике кроз КиттенХоусе.

Одлучили смо додајте још једну „*Кућу“ на дијаграм, који ће примити тачно метрику у формату како их наш код пише преко УДП-а. Онда их ова *Кућа претвара у уметке, попут трупаца, што КиттенХоусе разуме. Он може савршено да испоручи ове дневнике ЦлицкХоусе-у, који би требало да може да их чита.

Шема са базом података мемцацхе, статс-даемон и логс-цолецторс је замењена овом.

Овде постоји депеша из кода, која је написана локално у СтатсХоусе-у.
СтатсХоусе записује УДП метрике, већ конвертоване у СКЛ уметке, у КиттенХоусе у серијама.
КиттенХоусе их шаље у ЦлицкХоусе.
Ако желимо да их прочитамо, онда их читамо заобилазећи СтатсХоусе - директно из ЦлицкХоусе-а користећи обичан СКЛ.

Да ли је још увек мирно експеримент, али нам се свиђа како испада. Ако решимо проблеме са шемом, онда ћемо можда у потпуности прећи на њу. Лично се надам.

Схема не штеди гвожђе. Потребно је мање сервера, локални демони статистике и сакупљачи евиденције нису потребни, али ЦлицкХоусе захтева већи сервер од оних у тренутној шеми. Потребно је мање сервера, али морају бити скупљи и моћнији.

Развити

Прво, погледајмо примену ПХП-а. Развијамо се у git: употреба ГитЛаб и ТеамЦити за распоређивање. Развојне гране се спајају у мастер грану, из мастера за тестирање се спајају у сценску, а из фазе у производњу.

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

Такође много примењујемо кПХП и он такође има сопствени развој git према дијаграму изнад. Јер ово ХТТП сервер бинарни, онда не можемо да произведемо дифф - бинарно издање тежи стотинама МБ. Дакле, овде постоји још једна опција - верзија је написана бинлог цопифаст. Са сваком градњом се повећава, а током враћања се такође повећава. Версион реплицирати на сервере. Локални копифасти виде да је нова верзија ушла у бинлог и истом репликацијом трачева узимају за себе најновију верзију бинарне датотеке, не умарајући наш главни сервер, али пажљиво ширећи оптерећење широм мреже. Оно што следи грациозно поновно покретање за нову верзију.

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

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

Разлика је у томе што је наш бинарни програм упакован у архиве дебитант, а приликом испумпавања они дпкг -и стављају се у систем. Зашто је кПХП распоређен као бинарни, а мотори су распоређени као дпкг? Тако се десило. Ради - не дирај га.

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

Извештај Антона Кирјушкина „Администратор система Вконтакте. Како?" са детаљима о копирању и трачевима.
Извештај Јурија Насретдинова „Како ВК убацује податке у ЦЛицкХоусе са десетина хиљада сервера“.
Мој извештај „Архитектура растућег пројекта на примеру ВКонтактеа“, али са развојне тачке гледишта, а не хардвера.

Алексеј Акулович је један од оних који, као део Програмског одбора, помаже ПХП Русија 17. маја постаће највећи догађај за ПХП програмере у последње време. Погледај какав кул рачунар имамо, шта звучнике (двоје од њих развијају ПХП језгро!) - изгледа као нешто што не можете пропустити ако пишете ПХП.

Извор: ввв.хабр.цом

Често постављана питања о архитектури и раду ВКонтакте