Брзо скалирање онлајн складишта за више од милијарду корисника услуге ChatGPT (II део)

Свим привредног друштва OpenAI потребан је брз и поуздан приступ подацима, који обезбеђује наша платформа за складиштење Habitat. Она мора да одговара у милисекундама за више од милијарду корисника у 40 географских региона. Наша инфраструктура суочила се с изузетним изазовом: подржати експлозиван раст и нове случајеве употребе уз стално побољшање поузданости, перформанси и брзине рада програмера. Да бисмо решили тај изазов, морали смо да преиспитамо дизајн наше платформе за онлајн складиштење и начин управљања њоме. Стално смо одмеравали компромисе, пратећи овај редослед: прво довољна поузданост за најкритичнији саобраћај производа, затим довољна брзина за кориснике широм света и, на крају, ефикасан рад у огромном обиму.

Ова серија у два дела објашњава како смо Habitat развили од једноставне клијентске библиотеке и базе података у глобално дистрибуирану платформу за складиштење која опслужује више од 500 петабајта података. I део био је посвећен развоју платформе Habitat од Python клијента до сервиса. Обухватио је и технике којима смо сервис заснован на језику Python развили далеко изнад онога што би многи сматрали практичним.

У овом тексту, Део II, објашњавамо како смо скалирали основну компоненту за складиштење: Azure Cosmos DB. Кроз блиску сарадњу с Azure тимом дошли смо до одрживог решења за више закупаца, заснованог на контејнерима којима заједнички управљамо, уз одличне перформансе читања у огромном, глобалном обиму.

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

Насупрот томе, модел са више закупаца препушта управљање централном тиму за базе података, који има више знања и искуства у обезбеђивању ресурса. Али он доноси сопствене проблеме, попут бучних суседа: један закупац троши несразмерно велики део ресурса на штету осталих.

При развоју платформе Habitat морали смо да одмеримо све те компромисе како бисмо осмислили поуздан и ефикасан систем за складиштење у великом обиму. Данас је Habitat слој базе података са више закупаца за многе производе привредног друштва OpenAI. Ипак, прешли смо пун круг: од једног Azure Cosmos DB контејнера са више закупаца, преко засебних позадинских контејнера за појединачне закупце, до повратка на подразумевани контејнер са више закупаца. Још смо на самом почетку подршке за више закупаца у платформи Habitat. Подржавамо велики број случајева употребе, али смо улагања у ову област успели да одложимо користећи уграђене основне механизме Azure Cosmos DB где год је то могуће.

Пре него што опишемо свој пут са Azure Cosmos DB, ево основног контекста:

• Azure Cosmos DB налог дефинише скуп контејнера и политику репликације

• За сваки контејнер резервише се одређена пропусна моћ у јединицама захтева у секунди (RU/s)

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

• Azure Cosmos DB распоређује кључеве логичких партиција на мањи број основних физичких партиција. Њих дели на више физичких партиција када количина података пређе праг или када је контејнеру потребно више партиција да би одржао резервисану пропусну моћ

У почетку смо пропуштали сво клијентско оптерећење, ослањајући се на наведено ограничење од 10.000 RU/s по кључу логичке партиције да успори прилив захтева. На самом почетку смо такође користили само један подразумевани Azure Cosmos DB контејнер у сваком налогу. То је функционисало довољно добро, али се показало проблематичним из неколико разлога:

Због раних одлука о API-ју, избор кључа логичке партиције препустили смо директно клијентима. Зато се често јављају колизије на уобичајеним кључевима партиција, као што су user_id или workspace_id, између различитих случајева употребе производа. Пошто су ти случајеви употребе делили Azure Cosmos DB ограничења за исте кључеве логичких партиција, овај дизајн је ограничавао укупну пропусну моћ за датог корисника.

Пре преласка на Habitat и Azure Cosmos DB, чест проблем при скалирању базе Postgres био је то што је велики број захтева из веома активне организације или за веома тражен кључ – један закупац са несразмерно великим оптерећењем – могао да обори целу базу. Уложили смо велики заједнички труд у кеширање тих кључева и увођење привремених закупа при промашајима кеша, како оптерећење које они стварају не би преоптеретило основну базу.

Иако се документована ограничења величине података и пропусне моћи односе на кључеве логичких партиција, она се заправо спроводе на физичкој партицији. У пракси то значи да логичке партиције не могу да достигну 10.000 RU/s. Уместо тога, ограничења физичке партиције деле са свим осталим кључевима логичких партиција смештеним на њој.

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

Ограничење пропусне моћи физичке партиције такође варира и зависи од укупне пропусне моћи додељене Azure Cosmos DB контејнеру. Резервисана пропусна моћ контејнера распоређује се приближно равномерно на његове физичке партиције.

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

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

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

Почели смо да користимо засебне Azure Cosmos DB контејнере за најкритичније нове случајеве употребе којима је потребна снажна изолација. Уз скрипту која решава проблем слабих партиција усклађивањем укупне резервисане пропусне моћи сваког контејнера с бројем његових физичких партиција, избегли смо већину дотадашњих проблема.

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

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

У старом дељеном подразумеваном контејнеру, раст неког новог случаја употребе са 0 на милион QPS тешко би значајно променио укупно коришћење. У изолованом контејнеру, међутим, раст са 0 на милион QPS могао је да значи 1000 пута веће оптерећење од почетног, насталог само интерним испробавањем производа.

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

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

Временом је и праћење коришћења наменских контејнера захтевало детаљно познавање производа и тога када ће се саобраћај променити или порасти.

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

Овај приступ није могао да прати раст организације, јер се пажња коју су тимови посвећивали обезбеђивању Azure Cosmos DB ресурса за своје сервисе знатно разликовала.

С растом организације, ови оперативни проблеми постајали су све тежи за решавање. Без једног централног тима за планирање, многи тимови су лоше планирали. Зато смо се вратили решењу са више закупаца и тесно сарађивали с Azure тимом да у заједничкој архитектури отклонимо првобитне проблеме:

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

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

Azure Cosmos DB је већ имао режим без управљања серверима који би решио проблем слабих партиција из режима са унапред резервисаним капацитетом. Ипак, имао је велики недостатак: скалирао се само према искоришћеном складишном простору и ограничавао коришћење RU на 5000 RU/s по физичкој партицији. То би решило проблем слабих партиција, али би нас спречило да скалирамо случајеве употребе који троше много RU.

Azure Cosmos DB тим је за нас направио побољшан режим без управљања серверима, у ком свака физичка партиција може да достигне 10.000 RU/s. Уз поделу према заузетом складишту, увео је и поделу према потрошњи RU, па више нисмо морали ручно да пратимо и повећавамо капацитет контејнера.

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

Када предузећа достигну величину привредног друштва OpenAI, управљани сервиси постају мање „управљани”. Многа оптерећења излазе из уобичајених оквира инфраструктуре добављача облака. Како је привредно друштво OpenAI постало један од највећих корисника Azure Cosmos DB, успешан рад захтевао је другачији модел: заједничке тестове и контролне табле, директне канале међу инжењерима и заједничку одговорност за кварове који се јављају само у нашем обиму. Данас наш највећи Azure Cosmos DB налог чува десетине петабајта података и опслужује више од 20 милиона QPS. Колико знамо, једино смо предузеће које користи Azure Cosmos DB у овом обиму.

Крајем 2024. године, регионални прекид рада јасно је показао зашто је ова сарадња неопходна. Тада је нестанак струје погодио примарни Azure регион једног од наших највећих Azure Cosmos DB налога. При преласку на резервни регион открили смо да би нашим највећим налозима за то требало неколико сати. Ни наш ни Azure Cosmos DB тим то нису тестирали у нашем обиму.

Око месец дана касније, при враћању тих налога у првобитни регион, изазвали смо још један озбиљан прекид рада. Нагли талас конекција ка првобитном региону преоптеретио је његов Azure Cosmos DB мрежни пролаз. Специфичност начина на који Azure Cosmos DB клијент у режиму мрежног пролаза обрађује прелазак на резервни регион навела је све клијенте да одмах успоставе конекције и пошаљу захтеве првобитном региону, иако се у њега вратио само део физичких партиција.

При сваком прекиду, OpenAI и Azure спровели су своје процедуре управљања инцидентима, утврдили више основних узрока и применили исправке. Али ови прекиди били су симптоми ширег системског проблема у начину на који су наш тим и Azure Cosmos DB тим радили и тестирали. У почетку су нам управљани сервиси омогућили да брзо напредујемо и усредсредимо се на пословне циљеве. У великом обиму они постају мање управљани и захтевају дубоку интеграцију с добављачем услуге на свим нивоима, од дизајна до оперативног рада.

Данас инжењерски тимови за Habitat и Azure заједнички прате сваки слој платформе Habitat, од наших сервисних слојева до физичких складишних слојева Azure Cosmos DB. Радимо и тестирамо промене на Azure Cosmos DB налогу величине продукционог, али ван продукције. Заједно тестирамо и унапређујемо SDK-ове и утврђујемо најбоље праксе за скалирање и димензионисање наших Azure Cosmos DB налога. Наши инжењери су директно повезани преко апликације Teams, а омогућили смо и директно позивање дежурних колега без проласка кроз нивое подршке.

Током протекле године уложили смо велики заједнички труд у побољшање скалабилности управљачког слоја и мрежног пролаза за Azure Cosmos DB. Додали смо заштиту од оптерећења и кеширање разних метаподатака Azure Cosmos DB у мрежном пролазу како бисмо заштитили партицију метаподатака. Смањили смо притисак који ствара наша флота Python процеса habitat-service удруживањем конекција у пулове и њиховом чешћом поновном употребом, смештали радна оптерећења на исте локације где год је то било могуће и изоловали критична оптерећења од позадинских помоћу засебних виртуелних приватних облака (VPC).

Овакав ниво заједничког инжењерског рада био је пресудан за стабилност нашег Azure Cosmos DB током протекле године. Сваки довољно велики или критичан систем захтева овакав тимски рад: превазилажење подела у надлежностима и сарадњу преко организационих граница.

Као што смо навели у I делу, наша основна филозофија је: нека ради, затим нека ради брзо, па нека буде јефтино. Прво поузданост, затим перформансе, па ефикасност. Habitat је постао критична инфраструктура за привредно друштво OpenAI, па је први приоритет био да га учинимо поузданим. Како се систем стабилизовао 2025. године, а привредно друштво OpenAI се ширило глобално, латенција је постала следеће ограничење за кориснике и тимове за развој производа.

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

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

То нам је један од главних приоритета у 2026. години. Развили смо вишеслојну стратегију оптимизације читања, које чини више од 90% захтева платформи Habitat:

Имамо више Azure Cosmos DB налога у различитим Azure регионима широм света за кориснике са захтевима у погледу резидентности података. Чак и корисницима без строгих захтева за резидентност података, смештање података у њиховој близини побољшава искуство смањењем латенције.

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

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

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

За оптерећења код којих је латенција најважнија, попут метаподатака за потврду идентиета потребних за сваки захтев, смањујемо време повратног путовања (RTT) између рачунарских ресурса и платформе Habitat користећи Azure Cosmos DB налоге реплициране у многе секундарне регионе. Неки налози се реплицирају у свих 40 Azure региона у којима обрађујемо саобраћај, а други у бар један регион на сваком континенту.

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

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

У оптерећењима платформе Habitat убедљиво преовлађује читање: апликације стално преузимају подешавања, стање и друга својства. Несразмерно велики део саобраћаја потиче од релативно малог радног скупа често коришћених типова. Зато је систем нарочито погодан за дистрибуирано кеширање. Кеширање побољшава перформансе у инфраструктури једног региона, а користи су још веће при раду у више региона, где може да „сакрије” међурегионалну латенцију.

У Habitat смо интегрисали дистрибуирани слој кеша који се проверава пре приступа бази. Он чува копије недавно коришћених објеката и веза на Valkey серверима у нашој инфраструктури, близу места обраде корисничких захтева. Такви кешеви обично користе време важења (TTL) које балансира стопу погодака и застарелост података. Кратак TTL смањује застарелост, али и корист од кеширања, јер ставке брзо истичу и морају чешће да се преузимају. Дужи TTL повећава стопу погодака, али дуже враћа застареле податке, што погоршава корисничко искуство и чини понашање производа непредвидљивим.

Други приступ је изричито поништавање ставки кеша када апликација уписује измене у исте основне податке. То знатно побољшава ажурност кешираних података, али је тешко правилно спровести. И даље остају рубни случајеви, попут делимичних кварова, због којих кеш застарева. Рад у више региона додатно отежава ове проблеме због мање поузданих међурегионалних мрежа и трке између ажурирања кеша и репликације основног складишта. Додавање TTL-а ограничава максималну застарелост, али задржава исти основни компромис описан изнад.

Изабрали смо напреднији приступ поништавању, по узору на системе попут TAO предузећа Meta. Интегрисани кеш платформе Habitat користи бележење промена података (CDC) преко тока промена Azure Cosmos DB. Тако се поништавања шире глобално за неколико секунди, уз високу стопу погодака и ниску застарелост. Сервис у нашој инфраструктури чита тај ток промена и поништава ставке локалних кешева када се основни подаци ажурирају. При следећем читању долази до промашаја кеша, који се затим попуњава најновијом верзијом података.

Латенцију смо знатно смањили и уклањањем додатног трошка у самој услузи Habitat: преписали смо код у језику Rust, који је бржи од првобитне Python имплементације.

Ове промене су заједно смањиле наш укупни глобални p50 читања са око 120 ms на око 10 ms – побољшање од 12 пута откако смо се раније ове године усредсредили на перформансе.

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

Поуздан и скалабилан CDC – преношење промена базе у системе који је даље користе – кључан је и изван стратегије кеширања платформе Habitat. Милиони забележених промена у секунди, из хиљада контејнера и милиона њихових партиција, пролазе кроз више од сто Kafka тема. Они покрећу и секундарне индексе с коначном конзистентношћу, токове премештања података, позадинску аналитику и друге функције производа у реалном времену. С глобалним растом наше основне инфраструктуре, праћење промена редова постало је све сложеније. Ако клијент жели да региструје функцију која се позива при свакој промени редова његовог типа, прво мора да утврди који Cosmos налози и контејнери садрже његове податке и која инстанца CDC сервиса у одговарајућим регионима прати те контејнере. Затим мора правилно да скалира флоту радних процеса CDC сервиса, Kafka и свој потрошачки процес. Наша CDC платформа треба да сакрије ту сложеност од програмера и понуди једноставан интерфејс: клијенти региструју функцију за обраду промењених редова, а ми преузимамо повезивање компоненти и скалирање.

Интерни управљачки слој непрекидно обезбеђује бележење промена из свих потребних контејнера, бира Cosmos регионе за читање и ефикасно распоређује посао на хиљаде радних процеса у више географских региона. Коришћење региона с репликама и читање тока промена с нижим приоритетом штити саобраћај са платформе Habitat осетљив на латенцију од позадинског бележења промена. У овако великој флоти стално се јављају падови радних процеса, проблеми с контејнерима, грешке у складишту закупа, неисправне конфигурације и откази одредишта. Ојачали смо управљање животним циклусом CDC радних процеса и закупима, изоловали кварове између токова и уградили заштите за промене конфигурације и увођење нових верзија. Користимо редове за неиспоручене поруке како трајни неуспеси испоруке не би блокирали остатак реда. Регионалне прекиде превазилазимо пребацивањем процеса за читање на друге Cosmos регионе. Због нашег обима, морали смо да изменимо чак и Azure CDC SDK: повећали смо ефикасност контролних тачака тако што их групишемо у меморији и само повремено уписујемо.

Иако Habitat интерно користи Azure Cosmos DB на сложен начин, његова главна вредност одувек је била скривање инфраструктурних детаља од програмера ради бржег развоја производа. Исто важи и за нашу CDC платформу.

Мали тим успео је да подржи брзорастућу платформу за складиштење тако што је API за складиштење намерно задржао узак опсег, наставио да скалира Python сервис и давао предност најхитнијим инжењерским изазовима. Прво смо се усредсредили на поузданост за најкритичнији саобраћај производа, затим на перформансе читања за глобалне кориснике и на крају на оперативну ефикасност у великом обиму. Овај приступ омогућио је брз раст и нове случајеве употребе уз побољшање поузданости, перформанси и брзине развоја производа.

Да бисмо скалирали Habitat и складиштење разговора за следећу милијарду корисника, морамо да решимо тешкоће репликације података широм наше инфраструктуре у још већем обиму. Да бисмо то предупредили, развијамо сопствени прилагођени систем за онлајн складиштење на нивоу ексабајта, оптимизован за обимне типове података платформе Habitat. Овај систем у развоју спаја RocksDB Cloud језгро из система Rockset са репликацијом заснованом на протоколу Raft. Примењује исти модел докумената као Azure Cosmos DB, али користи раздвојено складиште и физичку репликацију да смањи потребан флеш капацитет, по цену нижег максималног броја упита у секунди.

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