Rate limit-ээс цааш: Codex ба Sora-ийн хандалтыг тэлэх нь

Өнгөрсөн нэг жилийн хугацаанд Codex болон Sora хоёул маш хурдан түгэн хэрэглэгдэж, ашиглалт нь бидний анх төсөөлж байснаас хурдан давсан. Бид нэгэн тогтвортой хэв маягийг харсан: хэрэглэгчид орж ирээд, бодит үнэ цэнэ олж, дараа нь rate limit-д тулдаг.

Rate limit нь эрэлтийг жигдрүүлж, шударга хандалтыг хангахад тусалж чадна; гэхдээ хэрэглэгчид үнэ цэнэ авч байхад хатуу зогсолтод хүрэх нь бухимдал төрүүлдэг. Бид системийн гүйцэтгэл болон хэрэглэгчдийн итгэлийг хамгаалсаар байж, хэрэглэгчдэд үргэлжлүүлэх боломж олгох арга хүссэн.

Үүнийг шийдэхийн тулд бид хэрэглээг тоолдог бодит цагийн хандалтын хөдөлгүүр бүтээсэн. Тэр хөдөлгүүрийн нэг давхарга нь credit худалдан авах боломж юм. Хэрэглэгчид rate limit-ээ давах үед credit нь credit үлдэгдлээ зарцуулан манай бүтээгдэхүүнийг үргэлжлүүлэн ашиглах боломж олгодог.

Үүний цаана limit, бодит цагийн хэрэглээний хяналт, credit үлдэгдлийг нэг хандалтын загварт нэгтгэсэн нарийн төвөгтэй систем бий. Энэ нийтлэлд Codex болон Sora-г тэлэхэд яагаад хандалтын хяналтыг дахин бодох шаардлагатай болсон, нотлогдохуйц зөв бодит цагийн систем хүсэлт бүр дээр rate limit ба credit-ийг хэрхэн нэгтгэдэг, мөн тэр суурь одоо хоёр бүтээгдэхүүнд нэмэлт хандалтыг хэрхэн нээж өгч байгааг авч үзнэ.

Том зургаар нь харвал уламжлалт хандалтын загварууд ихэвчлэн дараах сонголтын аль нэгийг тулгадаг:

• Rate limit эхэндээ тустай байж болох ч дуусах үед хэрэглэгчдэд муу туршлага үлдээдэг: “дараа эргэж ир”
• Хэрэглээнд суурилсан төлбөр уян хатан боловч эхний токен-оос эхлэн төлбөр авч эхэлдэг—эрт үеийн туршилт, судлалтыг дэмжихэд төдийлөн тохиромжтой биш

Codex болон Sora-ийн хувьд эдгээрийн аль нь ч дангаараа хангалттай байгаагүй. Хэрэв бид зүгээр л rate limit-ийг өсгөсөн бол эрэлтийг жигдрүүлэх, шударга байдлыг хангах чухал хяналтуудаа алдаж, хүн бүрт үйлчилгээ үзүүлэх хүчин чадал хүрэхгүй болох байв. Хэрэв бид бүхэлдээ асинхрон хэрэглээний тооцоололд найдах байсан бол саатал, хэтрэлт, эсвэл тулгалтын асуудал үүсэх байлаа—яг хэрэглэгчид хамгийн идэвхтэй үедээ анзаардаг төрлийн асуудлууд.

Бидэнд хэрэгтэй байсан зүйл нь бодит цагийн limit-ийг pay-as-you-go хандалттай хослуулсан нэг гибрид систем байв:

Энэ систем дараахыг хийх ёстой байсан:

• Rate limit-д хүрэх хүртэл түүнийг мөрдүүлэх
• Нэг хүсэлтийн хүрээнд credit рүү саадгүй шилжих
• Тэр шийдвэрийг бодит цагт гаргах
• Credit зарцуулалтыг хянахдаа өндөр нарийвчлалтай, аудит хийх боломжтой байх

Бидний хийсэн гол ойлголтын шилжилтүүдийн нэг нь хандалтыг шийдвэрийн хүрхрээ гэж загварчилсан явдал байв. “Үүнийг зөвшөөрөх үү?” гэж асуухын оронд “хэр хэмжээтэйг зөвшөөрөх вэ, мөн хаанаас вэ?” гэж асуудаг болсон. Хэрэглээг тоолох үед систем дараах дарааллаар явдаг:

Энэ загвар нь хэрэглэгчид бүтээгдэхүүнийг бодитоор хэрхэн мэдэрдгийг тусгадаг. Rate limit, үнэгүй түвшин, credit, урамшуулал, байгууллагын эрхүүд нь бүгд ижил шийдвэрийн стек дэх давхаргууд юм. Хэрэглэгчийн өнцгөөс тэд “систем сольдоггүй”—тэд зүгээр л Codex болон Sora-г үргэлжлүүлэн ашигладаг. Тиймээс credit үл үзэгдэх мэт санагддаг: энэ нь зүгээр л хүрхрээний бас нэг элемент.

Бид credit зарцуулалтыг удирдахын тулд гуравдагч талын хэрэглээний төлбөр тооцоо, хэмжилтийн платформуудыг үнэлсэн. Тэд нэхэмжлэх болон тайлагналд сайн тохирдог ч дараах хоёр чухал шаардлагыг хангаагүй:

Хэрэглэгч limit-д хүрч, credit боломжтой үед систем үүнийг нэн даруй мэдэх ёстой. Боломжоороо эсвэл хоцролттой тоолох нь гэнэтийн блок, үлдэгдлийн зөрүү, буруу төлбөр болон харагддаг. Codex болон Sora шиг интерактив бүтээгдэхүүний хувьд ийм алдаа нь ил тод мэдэгдэж, бухимдал төрүүлдэг.

Бид мөн үр дүн бүрийн талаар ил тод байдал өгөх шаардлагатай байсан:

• Яагаад хүсэлтийг зөвшөөрсөн эсвэл блоклосон бэ
• Энэ нь хэр их хэрэглээ зарцуулсан бэ
• Аль limit эсвэл үлдэгдэл хэрэглэгдсэн бэ

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

Үүнийг дэмжихийн тулд бид синхрон хандалтын шийдвэрт зориулан тусгайлан боловсруулсан тархмал хэрэглээ ба үлдэгдлийн систем бүтээсэн.

Ерөнхий түвшинд энэ систем:

• Хэрэглэгч тус бүр, функц тус бүрийн хэрэглээг хянадаг
• Rate limit-ийн цонхуудыг хадгалдаг
• Бодит цагийн credit үлдэгдлийг хадгалдаг
• Урсгалт асинхрон процессороор үлдэгдлийг идемпотент байдлаар хасдаг

Хүсэлт бүр нэг үнэлгээний замаар дамжин, rate limit-ээс синхроноор зарцуулж, шаардлагатай бол credit хүрэлцээтэй эсэхийг шалгаснаар хэр их хэрэглээг зөвшөөрөхийг бодит цагт шийддэг; дараа нь credit-ийн хасалтыг асинхроноор тулган суулгахын зэрэгцээ нэг тодорхой эцсийн үр дүнг буцаадаг. Ингэснээр бүтээгдэхүүнүүдийн хооронд тогтвортой зан төлөв хангагдаж, багуудын давхардсан логик арилдаг.

Энэ системийн гол загварчлалын зарчмуудын нэг нь манай төлбөр тооцоо зөв гэдгийг нотолж чаддаг байх ёстой явдал юм. Энэ нь анх байгууллагын хэрэглэгчдээс эхэлсэн манай credit дэмжлэгийн уг үндсийг харуулдаг. Дээрх системийн диаграмд хоорондоо холбогдсон гурван тусдаа өгөгдлийн багц бий:

• Бүтээгдэхүүний хэрэглээний үйл явдлууд: Хэрэглэгч бодитоор юу хийсэн бэ
• Орлогожуулалтын үйл явдлууд: Тэр хэрэглээнд нь бид хэрэглэгчээс юунд төлбөр авдаг вэ
• Үлдэгдлийн шинэчлэлтүүд: Хэрэглэгчийн credit үлдэгдлийг хэдээр, яагаад өөрчилсөн бэ

Эдгээр өгөгдлийн багцууд нь зүгээр нэг дагалдах үр дүн биш; үнэндээ системийг хөдөлгөдөг бөгөөд багц бүр дараагийнхаа триггер болдог. Юу болсон, түүнтэй холбоотой ямар төлбөр үүссэн, мөн бид юуг хассан гэдгийг тусгаарласнаар давхарга бүрийг бие даан аудитлах, дахин тоглуулах, тулган шалгах боломжтой болдог. Энэ нь credit үлдэгдлийн шинэчлэлт бага зэрэг саатах өртөгтэй ч нотлогдохуйц зөв байдлыг тэргүүнд тавьж буй зориудын солилцоо юм. Бид үүнийг хэрхэн хийсэн бэ:

• Хэрэглээний үйл явдал credit зарцуулалтыг өдөөсөн эсэхээс үл хамааран хэрэглэгчийн бүх идэвх дээр нийтлэгддэг. Энэ нь хэрэглэгчийн идэвхийн аудитын мөрийг бүрдүүлж, яагаад credit-ээс төлбөр авсан, эсвэл аваагүйг тайлбарлах боломж олгодог.
• Үйл явдал бүр тогтвортой idempotency key-тэй байдаг тул дахин оролдлого, дахин тоглуулалт, эсвэл worker-ийн дахин асаалт нь үлдэгдлээс хэзээ ч давхар хасалт хийхгүй, ингэснээр давхар төлбөрөөс сэргийлдэг. Энэ нь мөн ажлаа офлайнаар баталгаажуулахын тулд багц тулгалтын шалгалт ажиллуулах боломж олгодог.
• Бид аудитын мөр үүсгэхийн тулд синхрон шинэчлэлтийн оронд асинхрон (гэхдээ бараг бодит цагийн) үлдэгдлийн шинэчлэлт хийдэг. Систем зөв ажиллаж буйг нотолж, хэрэглэгчдэдээ буруу тооцоо хийж өгөхгүй гэдгээ баталгаажуулахын тулд хэрэглэгчийн үлдэгдлийг шинэчлэхэд багахан саатлыг зөвшөөрдөг. Тэр богино саатлаас болж хэрэглэгчийн credit үлдэгдлээс хэтрэн зарцуулбал бид автоматаар буцаан олгодог; бид хатуу мөрдөлтөөс илүү нотлогдохуйц зөв байдал болон хэрэглэгчийн итгэлийг сонгодог.
• Бид Credit Balance-ийг бууруулж, Balance Update бичлэгийг нэг атомик өгөгдлийн сангийн гүйлгээнд оруулдаг. Үлдэгдлийн шинэчлэлтүүд данс бүрээр сериалчлагддаг тул зэрэгцээ хүсэлтүүд ижил credit-ийг зарцуулахын төлөө хэзээ ч өрсөлдөхгүй. Balance Update бичлэг нь хассан дүнгээс гадна шинэчлэлтийг өдөөсөн орлогожуулалтын үйл явдал руу буцаан холбох мэдээллийг агуулдаг; үүнийг нэг өгөгдлийн сангийн гүйлгээнд багтааснаар credit үлдэгдэлд хийсэн тохируулга бүрийн аудитын мөр баталгааждаг.

Энэ бүх нягт нямбай байдал нэг зорилгыг дэмждэг: хандалтыг энгийн бөгөөд аюулгүй болгох. Хүмүүс бүтээж эсвэл код бичиж байхдаа хүсэлт нэвтрэх эсэх, өөрсдөөс нь илүү төлбөр авах эсэх, эсвэл үлдэгдэл нь зөв эсэх талаар эргэлзэх ёсгүй. Хэрэглээ, төлбөр тооцоо, үлдэгдлийг нотлогдохуйц зөв болгосноор бид хэрэглэгчдэд туршлагаас нь анхаарал сарниулахгүй систем өгдөг. Энэ нь хатуу зогсолтыг тасралтгүй хандалтаар солих боломж олгодог бөгөөд credit-ийг зөвхөн нэхэмжлэл дээр биш, бодит ажлын дундуур ашиглах боломжтой болгодог.

Манай арга барилын цөм зарчим нь хэрэглэгчийн эрчийг хамгаалах явдал юм. Архитектурын шийдвэр бүр хэрэглэгчид харагдах үр дүнтэй холбогддог: бодит цагийн үлдэгдэл нь хэрэггүй тасалдлыг багасгадаг, атомик зарцуулалт нь давхар төлбөрөөс сэргийлдэг, нэгдмэл хандалтын логик нь урьдчилан таамаглах боломжтой зан төлөвийг хангадаг. Үр дүнд нь хүмүүс илүү удаан ажиллаж, илүү гүн судалж, төслүүдээ цааш ахиулах боломжтой болдог—хатуу зогсолт эсвэл хугацаанаасаа өмнөх төлөвлөгөөний өөрчлөлттэй нүүр тулахгүйгээр.

Хэрэглэгчид идэвхтэй байх үед систем тэднийг үргэлжлүүлэхэд туслах ёстой, замд нь саад болох ёсгүй. Limit болон credit нь ар тал руу уусч алга болдог.

Тийм туршлагыг бүтээхийн тулд хандалт, хэрэглээ, төлбөр тооцоог нэг систем гэж дахин бодож, зөв байдлыг бүтээгдэхүүний нэгдүгээр зэрэглэлийн боломж гэж үздэг дэд бүтэц бүтээх шаардлагатай болсон. Ижил суурь нь цаашдаа илүү олон бүтээгдэхүүн рүү тэлж чадна; Codex болон Sora бол дөнгөж эхлэл.