FastComments је спреман за свемир!

! Овај чланак садржи технички жаргон

Шта је ново

Сваки FastComments point-of-presence сада локално прихвата уписе и асинхроно их реплицира на све друге чворове. Ово ће обезбедити већу издржљивост у односу на претходни систем, као и учинити алате за модерацију бржим за кориснике у неким регионима, уз одређене компромисе.

„Ready for Space“ је мало оптимистичко, али идеја је да можемо да распоредимо FastComments на различите планете и на крају систем буде у синхронизацији. Корисници на Плутону, међутим, морали би да чекају око један дан да виде промене на својој предстојећој страници фактуре, јер само један мастер по региону тренутно може да агрегира податке о наплати.

Нека историја, зашто промена

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

На крају смо преместили реплике базе у све зоне где се налази већина наших корисника и такође распоредили апликацију тамо, и створили наш сопствени DNS и систем проксија (описан у каснијем блогу) за рутирање захтева ка најближем чвору апликације. Ово чини читање брзим, али уписе споријим, јер сада уместо да чекате један HTTP round‑trip до бекенда, чекате HTTP round‑trip до блиског чвора, а тај чвор може да направи више уписа у базу према примарном. Није добро!

Зато смо реорганизовали многе делове апликације да прихватају readPreference у аргументима функција, тако да позивачи могу да одлуче колико су спремни да њихови читања буду застарела, а уз то смо више уписа (као што је упис статистика модератора на акције модератора) учинили fire‑and‑forget. Није идеално, али је значајно убрзало ствари.

Један проблем са глобалним Mongo‑ом су мрежни раздвајања. Ако се довољно чворова одсече, читања престају јер сваки чвор постаје несигуран да ли је у реду да служи читања. Постоје нека решења, али гранични случајеви постају компликовани. Ово није теоријски проблем – догодило се довољно пута да смо имали 3‑утарне странице, па смо се уморили, чак и покушавајући да подесимо Mongo да буде у реду са несигурношћу избора реплике до минуту разлике. На жалост, мреже из Сао Паулу у Фалкенштајн, на пример, нису биле довољно стабилне код неких наших добављача хостинга. Подешавање контроле конгестије помогло је, али није решило проблем.

Свештенско решење, под условом да прихватате одређене компромисе, је могућност да се уписи прихвате локално на том чвору (који има добар хардвер, RAID, итд., и који је мало вероватно да ће се срушити) и да се кориснику каже да су подаци сачувани. У том point‑of‑presence‑у можете имати и други чвор као врућу реплику за издржљивост.

То је где смо се нашли. Орегон, Вирџинија, Фалкенштајн, Сао Паулу, Сингапур, сви су своји репликасети и прихватају уписе. EU распоред (иако само три PoP‑а) има исто понашање.

Како ради

Део овога је објашњен у претходном одељку, али TL;DR је да је то CRDT‑lite. Направили смо прокси (у Rust‑у, јер наравно) који стоји између апликације и Mongo‑а и чини га мулти‑мастером. Прокси је свестан партнера, управља тачкама контроле, репликацијом, надгледањем и иницијалном синхронизацијом. То је мулти‑мастер замена за Mongo‑ов систем репликације, укључујући неке DDL команде.

Разлика у односу на друге алате је да ово не прати oplog. Пратиње oplog‑а, или коришћење change streams, не би радило, јер они приказују само крајње стање објекта након уписа, што онемогућава руковање конфликтима. Треба да ухватите сваку $set, $inc операцију и реплицирате саму операцију.

Ово је решење специфично за домен. Не би радило за све производе. Можете рећи да је у питању domain‑driven design :). Ради за нас јер смо од почетка врло пажљиво само $set поља која мењамо у документима – никада не користимо Mongo‑ов replaceOne, на пример. Исто важи за бројаче. Никада не радите SET VOTES = 5. Уместо тога, пишете INCREMENT VOTES BY 5, што омогућава коначну конзистентност. Дистрибуиране закључавања решава не. Само један чвор по кластеру има заставицу постављену за покретање cron‑ова. Иако ово делује ограничено, можемо купити сервере са терабајтима RAM‑а, па можемо прихватити овај компромис ради нижег ризика и комплексности.

Читање сопствених уписа

За програмере који користе API, требало би да можете читати сопствене уписе као и раније (направите API позив за креирање коментара, затим листајте коментаре и видите нови унос у листи). Услов је да то не можете радити преко региона. Ако ваш бекенд ради само у једном региону, као што је us‑west, онда би требало да можете читати сопствене уписе осим у случају да између вашег уписа и читања тај чвор падне и ваш DNS кеш се ажурира да показује на следећи најближи чвор. Под условом да се ово не деси, читање сопствених уписа је поуздано.

Можете такође фиксирати који point‑of‑presence ћете погодити. Више информација овде.

Тестирање и миграција

Око половине кода у систему је тестни оквир, оквир за тестирање и тестови. Ипак, издање је било мало бучно, тражећи дуже време за зауставу (1 сат за EU и 20 минута за глобални us) него што је било жељено, али нам је драго што смо прошли овај камен темељац и захваљујемо вам на стрпљењу!

У закључку и шта ово значи за вас

FastComments би сада требао бити бржи и издржљивији него икада, и сада можемо да се вратимо на рад на новим функцијама :)

Cheers!