ChatGPT‑ийн 1 тэрбум гаруй хэрэглэгчид үйлчлэх онлайн хадгалалтыг хурдан өргөжүүлэх нь (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 болж өсөх нь зөвхөн дотоод туршилтын хэрэглээнээс үүдсэн суурь ачааллаас 1,000 дахин их ачаалал болж болно.

Тусгай контейнертэй болсноор багууд бүтээгдэхүүнээ гаргах үеийн хүлээгдэж буй нэвтрүүлэх чадамжид тохируулан контейнерээ урьдчилан бэлдэхээ санах шаардлагатай болсон. Бүтээгдэхүүний багууд шинэ боломжоо ашиглалтад оруулахдаа хүчин чадлаа урьдчилан нэмэхээ мартах нь элбэг байв. Ингээд нэвтрүүлэх өдөр бид ноцтой доголдол шийдвэрлэх 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-ийн инженерийн багууд манай үйлчилгээний давхаргаас Azure Cosmos DB-ийн физик хадгалалтын давхарга хүртэл Habitat-ийн бүх түвшнийг хамтран хянадаг. Бид ашиглалтын орчинтой ижил хэмжээтэй боловч бодит хэрэглэгчдэд үйлчилдэггүй 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-ийн саатлыг бууруулах уу, эсвэл тэр нөөцийг хүсэлт боловсруулах нэмэлт тооцоололд ашиглаад хадгалалтын хүсэлтүүдийг илүү хол дамжуулах уу.

Иймээс байршуулах шийдвэр нь ихэвчлэн А) бүтээгдэхүүн, хэрэглэгчийн бүлэг бүрийн саатлыг оновчлох, Б) хадгалалт, тооцооллын бодит хүчин чадлыг харгалзах гэсэн хоёр шаардлагыг тэнцвэржүүлэх сонголт болдог.

Хүсэлт бүрд хэрэгтэй танин баталгаажуулалтын метадата зэрэг сааталд хамгийн мэдрэмтгий ачааллын хувьд бид олон хоёрдогч бүсэд хуулбартай Azure Cosmos DB бүртгэл ашиглан тооцоолол болон Habitat хоорондын хоёр талын дамжуулалтын хугацааг (RTT) бууруулдаг. Зарим бүртгэл хүсэлт боловсруулдаг Azure-ийн бүх 40 бүсэд хуулбараа байршуулдаг бол бусад нь тив бүрийн дор хаяж нэг бүсэд хуулбарладаг.

Хуулбарлалтын өөр өөр бүтэцтэй бүртгэлүүдийн хооронд өгөгдлийн багцыг зөөхийн тулд бид хэрэглэгчид мэдэгдэхгүйгээр өгөгдөл зөөж, хүсэлт чиглүүлэх давхаргыг Habitat-д төлөвлөснөөсөө эрт бүтээх шаардлагатай болсон.

Гэвч энэ арга ч эцэстээ хүчин чадлаар хязгаарлагддаг тул тусгайлан сонгосон цөөн өгөгдлийн багцад л ашиглаж байна.

Habitat-ийн ачааллын дийлэнх нь уншилт байдаг. Аппликейшнүүд тохиргоо, төлөв болон бусад шинжийг байнга татдаг бөгөөд харьцангуй цөөн, байнга ханддаг өгөгдлийн төрлүүд нийт хүсэлтийн үлэмж хувийг эзэлдэг. Тиймээс энэ систем тархмал кэш ашиглахад тун тохиромжтой. Кэш нэг бүсийн дэд бүтцийн гүйцэтгэлийг сайжруулдаг бол олон бүсэд үр өгөөж нь улам нэмэгдэнэ. Учир нь бүс хоорондын саатлыг «далдлах» боломжтой.

Бид Habitat-д эхлээд кэшээс шалгаж, байхгүй бол үндсэн сангаас авах тархмал кэшийн давхарга нэгтгэсэн. Энэ нь саяхан хандсан объект, холбоосуудын хуулбарыг хэрэглэгчийн хүсэлт боловсруулдаг газарт ойр байрлах Valkey серверүүдэд хадгалдаг. Ийм кэшүүд ихэвчлэн кэшээс олдох хувь болон өгөгдлийн хуучралтыг тэнцвэржүүлсэн хадгалах хугацаа (TTL) ашигладаг. Богино TTL хуучралтыг багасгах ч кэш дэх өгөгдлийн хугацаа хурдан дуусаж, дахин дахин татах шаардлагатай болдог тул кэшийн үр өгөөжийг бууруулдаг. Урт TTL кэшээс олдох хувийг өсгөх ч хуучирсан өгөгдлийг удаан ашиглуулж, хэрэглээг муутган, бүтээгдэхүүний ажиллагааг таамаглахад бэрх болгодог.

Өөр нэг арга нь аппликейшн суурь өгөгдөлд бичилт хийх үед тухайн өгөгдлийн кэшийг илт хүчингүй болгох үйлдэл гүйцэтгэх юм. Энэ нь кэшийн өгөгдлийг эрс шинэчилдэг ч зөв хэрэгжүүлэхэд хэцүү байж болно. Мөн хэсэгчилсэн доголдол зэрэг онцгой нөхцөлөөс болж кэш хуучирсан хэвээр үлдэх эрсдэлтэй. Олон бүсэд ажиллуулахад бүс хоорондын сүлжээний найдвартай байдал сулрах, кэшийн шинэчлэлт суурь хадгалалтын хуулбарлалтаас түрүүлж эсвэл хоцорч явагдах зэргээс эдгээр асуудал улам хүндрэнэ. Үүнийг TTL-тэй хослуулбал хуучралтын дээд хугацааг хязгаарлах ч дээр дурдсан TTL-ийн үндсэн зөрчил хэвээр үлдэнэ.

Бид Meta-ийн TAO зэрэг системийн жишгээр кэшийг хүчингүй болгох илүү боловсронгуй арга сонгосон. Habitat-ийн нэгдсэн кэш Azure Cosmos DB-ийн өөрчлөлтийн урсгалаар өгөгдлийн өөрчлөлт барих (CDC) аргыг ашигладаг. Ингэснээр хүчингүй болгох дохиог дэлхий даяар хэдхэн секундэд түгээж, хуучралтыг бага байлгахын зэрэгцээ кэшээс олдох хувийг өндөр байлгадаг. Манай дэд бүтцийн нэг үйлчилгээ энэ урсгалыг хүлээн авч, суурь өгөгдөл шинэчлэгдэхэд тухайн бүсийн кэшүүдийг хүчингүй болгодог. Ингэснээр дараагийн уншилтаар өгөгдөл кэшээс олдохгүй тул хамгийн сүүлийн хувилбарыг нь авч кэшэд хадгална.

Бид мөн анхны Python-оос илүү гүйцэтгэлтэй Rust хэлээр кодыг дахин бичиж, Habitat үйлчилгээний өөрийнх нь нэмэлт зардлыг арилгаснаар саатлыг мэдэгдэхүйц бууруулсан.

Эдгээр өөрчлөлтийн нийлбэр үр дүнд дэлхий даяарх нийт уншилтын p50 саатал ойролцоогоор 120 мс-ээс 10 мс болж буурсан. Энэ оны эхээр гүйцэтгэлд анхаарч эхэлснээс хойш 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-ийн их хэмжээтэй өгөгдлийн төрлүүдэд оновчилсон, эксабайтын хэмжээний онлайн хадгалалтын тусгай системийг дотооддоо бүтээж байна. Хөгжүүлж буй энэ систем Rockset-ийн RocksDB Cloud цөмийг Raft-д суурилсан хуулбарлалттай нэгтгэдэг. Энэ нь Azure Cosmos DB-тэй ижил баримт бичгийн загварыг хэрэгжүүлдэг ч тооцооллоос тусгаарласан хадгалалт, физик хуулбарлалт ашиглан шаардлагатай флаш багтаамжийг багасгадаг. Үүний хариуд оргил qps нь бага байна.

Хэрэв та технологийн өнөөгийн хил хязгаарт хүрсэн хэмжээнд ийм өгөгдлийн дэд бүтэц бүтээх сонирхолтой бол манай нээлттэй ажлын байруудыг үзээрэй⁠.