1 миллиардтан астам ChatGPT пайдаланушысы үшін онлайн қойманы жедел кеңейту (II бөлім)

Барлық OpenAI өнімдеріне деректерге жылдам әрі сенімді қол жеткізу қажет. Мұны Habitat сақтау платформамыз қамтамасыз етеді. Ол 40 географиялық аймақтағы 1 миллиардтан астам пайдаланушының сұрауларына миллисекундтар ішінде жауап беруі тиіс. Инфрақұрылымымыздың алдында айрықша күрделі міндет тұрды: қарқынды өсім мен жаңа қолдану сценарийлерін қолдай отырып, сенімділікті, өнімділікті және өнім әзірлеу жылдамдығын үздіксіз арттыру. Бұл міндетті шешу үшін онлайн сақтау платформасының архитектурасы мен жұмыс істеу тәсілдерін қайта қарастыру қажет болды. Біз әр шешімнің артықшылықтары мен кемшіліктерін үнемі саралап, мынадай ретпен әрекет еттік: алдымен аса маңызды өнім трафигі үшін жеткілікті сенімділікті қамтамасыз ету, содан кейін әлемнің әртүрлі аймағындағы пайдаланушылар үшін қажетті жылдамдыққа қол жеткізу және соңында орасан ауқымдағы жүйенің жұмысын тиімді басқару.

Екі бөлімнен тұратын бұл топтамада 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-ке өсуі тек ішкі сынақтан туындайтын бастапқы жүктемеден 1000 есе артық болуы мүмкін.

Жеке контейнерлерге көшкен соң командалар іске қосар алдында контейнерлерге күтілетін өткізу қабілетін бөлуді ұмытпауы керек болды. Өнім командалары функцияларын жұмыс ортасына жиі шығарып, ресурсты алдын ала ұлғайтуды ұмытып кететін. Сөйтіп іске қосу күні біз SEV жедел әрекет ету бөлмелерінде контейнерлерді соңғы сәтте ұлғайтуға тырысатынбыз.

Әртүрлі жүктемені біріктіру — көп жалға алушы жүйелердің негізгі артықшылығы. Контейнерлерді осылай бөлу стратегиясында жақсырақ оқшаулау үшін осы артықшылықтан айырылдық.

Уақыт өте жеке контейнерлердің пайдаланылуын бақылау үшін трафиктің қашан өзгеретінін не өсетінін, яғни өнім ерекшеліктерін терең білу қажет болды.

Өсу үрдістеріне сүйене отырып, әр контейнерге бөлінген өткізу қабілетін арттыруға арналған қарапайым басқару қабатының скриптін қолдана аламыз. Алайда жиынтық өсім тұрақсыз болғандықтан, контейнерлердің ауқымын дұрыс кеңейту 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 Cosmos DB тіркелгілеріміздің бірінің негізгі Azure аймағында электр қуаты өшті. Резервке ауысу барысында ең ірі тіркелгілерімізді қосалқы аймаққа көшіруге бірнеше сағат кететінін анықтадық. Мұны біздің команда да, 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 жылы бұған ерекше көңіл бөліп, Habitat сұрауларының 90%-дан астамын құрайтын оқу операцияларын оңтайландырудың көпқабатты стратегиясын әзірледік:

Деректердің орналасу аймағына талап қоятын пайдаланушылар үшін әлемнің әртүрлі Azure аймақтарында бірнеше Azure Cosmos DB тіркелгісін ұстаймыз. Деректердің орналасу аймағына қатаң талап қоймайтын пайдаланушылар үшін де деректерді жақын орналастыру кідірісті азайтып, пайдалану тәжірибесін жақсартады.

Іс жүзінде, деректердің орналасу аймағына қатысты жағдайлардан тыс бұл тәсілді кең қолдана алмаймыз, өйткені орналастыру бұлттың физикалық ресурстарына тәуелді. Деректер жиынтығымыздың көлемі соншалықты үлкен: көптеген аймақтар өздеріне тиесілі пайдаланушы трафигінің үлесіне қажетті орасан сақтау орнын қамтамасыз ете алмайды.

Деректер орталығының ресурстары, электрмен жабдықтау немесе салқындату мүмкіндіктері шектеулі аймақтарда кейде екі нұсқаның бірін таңдауға тура келеді: ресурстарды жақын орналасқан сақтау жүйелеріне бөліп, Habitat кідірісін азайту немесе сол ресурстарды сұрауларға қызмет көрсететін қосымша есептеу жүйелеріне бағыттап, деректерді сақтау жүйесіне арналған сұрауларды алысырақ аймақтарға жіберу.

Сондықтан орналастыру шешімдері көбіне өнімге қатысты екі факторды теңгеруді талап етеді: A) түрлі өнімдер мен пайдаланушы топтарының кідірісін оңтайландыру және B) қолда бар сақтау мен есептеу ресурстары.

Әр сұрауға қажет аутентификация метадеректері сияқты кідіріске аса сезімтал жүктемелер үшін көптеген қосалқы аймаққа репликацияланған Azure Cosmos DB тіркелгілерін қолданамыз. Бұл есептеу жүйелері мен Habitat арасындағы барып-қайту уақытын (RTT) қысқартады. Кей тіркелгілер трафикке қызмет көрсететін барлық 40 Azure аймағына, ал басқалары әр құрлықтағы кемінде бір аймаққа репликацияланады.

Деректер жиынтықтарын репликация топологиялары әртүрлі тіркелгілер арасында тасымалдау үшін Habitat жүйесіне деректерді пайдаланушыға байқатпай тасымалдау және бағыттау қабатын жоспарлағанымыздан ертерек енгізуге тура келді.

Дегенмен бұл тәсіл де түптеп келгенде ресурстарға тәуелді, сондықтан тек арнайы таңдалған бірнеше деректер жиынтығына қолданылады.

Habitat жүктемелерінде оқу операциялары басым: қолданбалар баптауларды, күйді және өзге қасиеттерді үнемі сұрайды. Трафиктің салыстырмалы түрде үлкен үлесі жиі сұралатын дерек түрлерінің шағын ғана жұмыс жиынтығына тиесілі. Сондықтан бұл жүйеге таратылған кэштеу өте қолайлы. Кэштеу бір аймақтағы инфрақұрылымның өнімділігін арттырады, ал бірнеше аймақта жұмыс істегенде пайдасы еселенеді: ол аймақаралық кідірісті «жасыра» алады.

Habitat-қа дерекқорға жүгінер алдында тексерілетін таратылған кэш қабатын кіріктірдік. Ол жақында сұралған нысандар мен байланыстардың көшірмесін инфрақұрылымымыздағы пайдаланушы сұраулары өңделетін жерге жақын Valkey серверлерінде сақтайды. Әдетте мұндай кэштерде кэштен табылу жиілігі мен деректің ескіруін теңгеретін сақтау мерзімі (TTL) қолданылады. Қысқа TTL деректің ескіруін азайтады, бірақ кэштеудің пайдасын кемітеді: элементтер кэштен тез жойылып, оларды жиірек қайта алу керек болады. Ұзақ TTL кэштен табылу жиілігін арттырады, бірақ ескірген деректі ұзақ уақыт береді. Бұл пайдаланушы тәжірибесін нашарлатып, өнімнің әрекетін болжауды қиындатады.

Басқа тәсіл — қолданба негізгі деректерге жазу операциясын орындаған кезде кэштегі тиісті деректерді арнайы жарамсыз ету. Бұл кэштегі деректердің өзектілігін айтарлықтай арттырады, бірақ оны дұрыс іске асыру күрделі болуы мүмкін. Сонымен қатар ішінара ақаулар сияқты ерекше жағдайларда кэште ескірген деректер қалып қоюы ықтимал. Жүйе бірнеше аймақта орналастырылғанда бұл мәселелер одан әрі күрделенеді: аймақаралық желілердің сенімділігі төменірек болады, ал кэштің күйі мен негізгі қоймадағы деректердің репликациясы уақыт жағынан сәйкес келмей қалуы мүмкін. TTL қолдану деректердің ескіруінің ең ұзақ мерзімін шектейді, бірақ жоғарыда сипатталған сақтау мерзіміне байланысты негізгі ымыраны жоймайды.

Біз Meta-ның TAO жүйесі сияқты шешімдерге сүйеніп, кэшті жарамсыз етудің озық тәсілін таңдадық. Habitat-тың кіріктірілген кэші Azure Cosmos DB өзгерістер арнасы арқылы деректер өзгерісін тіркеуге (CDC) сүйенеді. Ол жарамсыз ету хабарларын әлемге бірнеше секундта таратып, кэштен табылу жиілігін жоғары, ескіру деңгейін төмен ұстайды. Инфрақұрылымымыздағы бір қызмет осы өзгерістер арнасын оқып, негізгі деректер жаңарғанда жергілікті кэштердегі тиісті жазбаларды жарамсыз етеді. Келесі оқуда дерек кэштен табылмайды да, кэш деректің ең жаңа нұсқасымен толтырылады.

Сонымен қатар Habitat қызметінің кодын бастапқы Python нұсқасына қарағанда өнімдірек Rust тілінде қайта жазып, қызметтің өзіндегі қосымша өңдеу шығындарын жойдық. Соның нәтижесінде кідіріс айтарлықтай қысқарды.

Осы өзгерістердің нәтижесінде әлем бойынша деректерді оқудың p50 кідірісі шамамен 120 мс-тан 10 мс-қа дейін қысқарды. Биыл өнімділікті жақсартуға ден қоя бастағаннан бері бұл көрсеткіш 12 есе жақсарды.

Кэштеу медианалық кідірісті күрт азайтқанымен, ең баяу сұраулар кэштелмеген деректерді негізгі қоймадан, көбіне алыс аймақтардан алуды әлі де талап етеді. Жаңа ресурстар қосылып, сақтау тиімділігі артқан сайын іргелі міндетке кірісуді жоспарлап отырмыз: деректерді әуел бастан олар сұралатын жерге жақын орналастыру.

Дерекқордағы өзгерістерді кейінгі жүйелерге тарататын сенімді әрі масштабталатын CDC тек Habitat кэштеу стратегиясы үшін ғана маңызды емес. Мыңдаған контейнер мен миллиондаған контейнер бөлімінен секундына миллиондаған өзгеріс тіркеліп, жүзден астам Kafka тақырыбы арқылы өтеді. Олар уақыт өте келісімді күйге келетін қосалқы индекстердің, деректерді тасымалдау конвейерлерінің, офлайн аналитиканың және нақты уақытта жұмыс істейтін басқа да өнім функцияларының жұмысын қамтамасыз етеді. Негізгі инфрақұрылымымыз жаһандық деңгейде кеңейген сайын дерекқор жолдарындағы өзгерістерді бақылау барған сайын күрделене түсті. Клиент өзіне тиесілі дерек түрінің жолдары өзгерген сайын шақырылатын функцияны тіркегісі келсе, алдымен деректерінің қай Cosmos тіркелгілері мен контейнерлерінде орналасқанын анықтауы керек. Сондай-ақ тиісті аймақтарда сол контейнерлердегі өзгерістерді бақылайтын CDC қызметінің қай орналастырылған данасы жұмыс істейтінін анықтап, CDC қызметінің орындаушы процестерін, Kafka жүйесін және өз деректерін тұтынушы компонентін дұрыс масштабтауы қажет. CDC платформамыз осы күрделі инфрақұрылымдық процестерді өнім әзірлеушілерінен абстракциялап, олардың орнына қарапайым интерфейс ұсынуды көздейді. Клиенттер өзгертілген жолдар үшін шақырылатын функцияны тіркейді, ал барлық ішкі байланыстыру, деректерді жеткізу және масштабтау жұмыстарын біз атқарамыз.

Ішкі басқару қабаты барлық қажетті контейнерлердегі өзгерістердің тіркелуін үздіксіз қадағалайды, деректер оқылатын Cosmos аймақтарын таңдайды және жұмысты бірнеше географиялық аймақтағы мыңдаған орындаушы процесс арасында тиімді бөледі. Реплика аймақтарын пайдалану және өзгерістер арнасын төмен басымдықпен оқу кідіріске сезімтал Habitat трафигін фондық өзгерістерді тіркеу жүктемесінен қорғайды. Осындай ауқымды инфрақұрылымда орындаушы процестердің істен шығуы, контейнерлерге қатысты мәселелер, ресурстарды уақытша иелену туралы жазбалар сақталатын қоймадағы қателер, жарамсыз конфигурациялар және деректерді қабылдайтын жүйелердің ақаулары үнемі кездеседі. Біз CDC орындаушы процестерінің өмірлік циклін басқару мен ресурстарды уақытша иелену тетіктерінің сенімділігін арттырдық, әртүрлі деректер ағындарындағы ақауларды бір-бірінен оқшауладық және конфигурация өзгерістері мен жаңа нұсқаларды енгізуге арналған қорғаныс тетіктерін жасадық. Хабарларды жеткізудегі тұрақты ақаулар кезектің басындағы хабардың кейінгі хабарларды өңдеуге кедергі келтіруіне жол бермеуі үшін жеткізілмеген хабарлар кезегін қолданамыз. Аймақтық іркілістер кезінде деректерді оқитын процестерді балама Cosmos аймақтарына ауыстыру арқылы жүйенің жұмысын жалғастырамыз. Инфрақұрылымымыздың ауқымы соншалық, Azure-дың CDC SDK жиынтығына да өзгерістер енгізуге тура келді. Бақылау нүктелерін алдымен жедел жадта топтап, кейін белгілі бір уақыт аралығында ғана тұрақты сақтау жүйесіне жазу арқылы оларды тіркеу процесінің тиімділігін арттырдық.

Habitat ішінде Azure Cosmos DB-ны пайдалану күрделі болғанымен, Habitat-тың негізгі құндылығы әрқашан өнім әзірлеушілерін инфрақұрылымның техникалық егжей-тегжейімен жұмыс істеу қажеттілігінен босатып, өнім әзірлеуді жеделдету болды. CDC платформамыз да осы қағиданы ұстанады.

Шағын команда сақтау API мүмкіндіктерін әдейі шектеулі ұстап, Python қызметінің ауқымын кеңейтуді жалғастырып, ең шұғыл инженерлік міндеттерге басымдық беру арқылы қарқынды өсіп жатқан сақтау платформасын қолдай алды. Алдымен аса маңызды өнім трафигінің сенімділігіне, кейін жаһандық пайдаланушылар үшін оқу өнімділігіне, соңында үлкен ауқымдағы операциялық тиімділікке назар аудардық. Бұл тәсіл сенімділікті, өнімділікті және өнім әзірлеу қарқынын арттыра отырып, жедел өсім мен жаңа сценарийлерді қолдауға мүмкіндік берді.

Habitat пен әңгімелерді сақтау жүйесін келесі миллиард пайдаланушыға қызмет көрсете алатындай кеңейту үшін деректерді инфрақұрылымымыздың әртүрлі бөліктері арасында бұдан да үлкен ауқымда репликациялауға байланысты қиындықтарды шешуіміз қажет. Осы мәселеге алдын ала дайындалу мақсатында Habitat-тың көлемді дерек түрлеріне оңтайландырылған, эксабайт ауқымындағы жеке онлайн сақтау жүйемізді әзірлеп жатырмыз. Әзірлену үстіндегі бұл жүйе Rockset компаниясының RocksDB Cloud өзегін Raft негізіндегі репликациямен біріктіреді. Ол Azure Cosmos DB жүйесіндегідей құжат үлгісін қолданады, бірақ қажетті флеш-жад көлемін азайту үшін сақтау ресурстары бөлек ұйымдастырылған архитектура мен физикалық репликацияны пайдаланады. Алайда соның есесіне жүйенің ең жоғары QPS көрсеткіші төменірек болады.

Деректер инфрақұрылымына қатысты осындай аса ауқымды, озық жобаларда жұмыс істеуге қызықсаңыз, бос орындарымызды қараңыз⁠.