Брзо скалирање на онлајн складирањето за над 1 милијарда корисници на ChatGPT (Дел II)

На сите производи на OpenAI им треба брз и сигурен пристап до податоци, кој го обезбедува нашата платформа за складирање, Habitat. Таа мора да одговара за милисекунди на над 1 милијарда корисници во 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 илј. 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. Обезбедениот капацитет на контејнерот се распределува приближно рамномерно меѓу неговите физички партиции.

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

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

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

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

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

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

Во стариот заеднички стандарден контејнер, растот на некој нов случај на употреба од 0 на 1 милион QPS тешко дека значително ќе го сменеше вкупното користење. Но во изолиран контејнер, растот од 0 на 1 милион QPS можеше да значи 1.000 пати поголемо оптоварување од почетното ниво создадено само со интерно тестирање.

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

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

Со текот на времето, следењето на користењето на наменските контејнери бараше и длабоко познавање на производот за да се предвиди кога сообраќајот ќе се промени или ќе порасне.

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

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

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

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

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

Azure Cosmos DB веќе имаше режим без управување со сервери што би го решил проблемот со слабите партиции во режимот со однапред обезбеден капацитет. Но имаше голем недостаток: се скалираше само според зафатениот простор и го ограничуваше користењето на RU на 5 илј. RU/s по физичка партиција. Тоа би го решило проблемот со слабите партиции, но би нè спречило да ги скалираме случаите што трошат многу RU.

Тимот на Azure Cosmos DB ни изгради нов, подобрен режим без управување со сервери. Тој овозможи секоја физичка партиција да се скалира до 10 илј. 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 региони. Поради нашиот обем, моравме дури да го измениме CDC SDK на Azure за поефикасно зачувување контролни точки: ги групираме во меморија и само периодично ги запишуваме во трајното складиште.

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

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

За да ги скалираме Habitat и складирањето разговори за следната милијарда корисници, мора да ги надминеме тешкотиите со реплицирањето податоци низ нашата инфраструктура во уште поголем обем. За навреме да го решиме ова, развиваме сопствен систем за онлајн складирање во ексабајтски обем, оптимизиран за обемните типови податоци на Habitat. Овој систем во развој го комбинира јадрото RocksDB Cloud од Rockset со репликација базирана на Raft. Го применува истиот документен модел како Azure Cosmos DB, но користи раздвоено складирање и физичка репликација за да го намали потребниот флеш-капацитет, по цена на понизок максимален QPS.

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