Үхсэн холболтгүйгээр өгөгдлийн сангуудыг сэрээх нь

Mythex дээрх нийтлэгдсэн апп болон тэдгээрийн өгөгдлийн сан, хэн ч ашиглаагүй үед унтдаг. Апп сэрэхдээ эхний хүсэлтээ 10–12 секунд барьж болдог байсан, учир нь унтсан хугацаанд үхсэн өгөгдлийн сангийн холболтуудыг дахин ашиглах гэж оролддог байв. Одоо бид Spring Boot аппуудад унтаж сэрэхэд аюулгүй өгөгдлийн сангийн тохиргоо өгч, агентад бүх stack-ийн аппуудыг адилаар бүтээхийг заадаг. Платформ дээр, сэрээд эхний хүсэлт 12.7 секундээс 2.3 секунд болсон.

Апп ба өгөгдлийн сан яагаад унтдаг вэ

Mythex-ийн нийтлэгдсэн апп хэдэн идэвхгүй минутын дараа унтдаг машин дээр ажилладаг, мөн түүний өгөгдлийн сан хэдэн минутын идэвхгүй байсны дараа унтаж, дараагийн query-д сэрдэг serverless Postgres. Энэ нь тайван апп хямд байлгадаг: өгөгдлийн сан жинхэнэ ашигласан-ийнхээ төлбөрийг төлдөг, мөн унтсан апп compute дээр юу ч зардаггүй. Биллингийн талаар өгөгдлийн сангуудыг жинхэнэ ашигласнаар нь төлбөр тооцох нь нийтлэлд бичсэн.

Гэхдээ хоёр нь тусдаа унтдаг, мөн холболт гэж юу болох талаар санал нийлдэггүй.

Шинж тэмдэг: эхний зочны удаан ачаалал

Ихэнх серверийн апп connection pool хадгалдаг: хэдэн нээлттэй өгөгдлийн сангийн холболтыг бэлэн байлгадаг, ингэснээр хүсэлт бүр шинэ холболт нээх зардал төлөхгүй. Энэ нь байнга ажилладаг аппад зөв загвар.

Унтах үед юу болдог вэ:

1. Апп ажиллаж байна, pool дээр хэдэн идэвхгүй холболт байна.
2. Хэн ч зочлохгүй. Аппын машин түдгэлзэж, хөлдсөн — pool нь бүрэн.
3. Өгөгдлийн сан унтаж, холболт бүрийн өөрийн талыг унагадаг.
4. Зочин ирнэ. Апп яг хэвээрээ сэрдэг, гэхдээ өгөгдлийн сан мэдэхгүй болсон холболтуудыг барьсаар байна.
5. Pool тэдгээрийн нэгийг өгнө. Тэр нь үхсэн гэдгийг тэр оролдож, хүлээж байж мэдэх ёстой.

Spring Boot аппад эдгээр үхсэн холболтыг шалгах нь эхний хүсэлтийг ойролцоогоор 10 секунд зогсоож, дараа нь «Connection is not available» гэж бүтэлгүйтдэг байв. Зочинд сайт зүгээр л хүлээгдэж, дараа нь алдаа харуулдаг байв.

Spring апп яагаад хамгийн их хохирсон бэ

Spring Boot бол алдартай Java фреймворк, мөн анхдагчаар HikariCP гэдэг connection pool ашигладаг. Spring тэр pool-ийг тохиргооноос, түүний дотор хэдэн idle холболт хадгалахыг тохируулж болно.

Гэвч Mythex апп бүрт өгөгдлийн сангийн холболтыг postgresql://user:pass@host/db хэлбэрийн нэг DATABASE_URL гэж өгдөг. Spring энэ форматыг шууд уншиж чаддаггүй. Тиймээс Mythex дээр ажилладаг Spring аппууд тэр URL-ийг задлан кодоор өөрсдөө pool барьдаг байсан — гар аргаар бүтээсэн pool нь Spring-ийн spring.datasource.* тохиргоог бүгдийг үл тоомсордог. Хэн нэгэн зөв pool тохиргоог мэдсэн ч тэдгээр нь ажиллах газаргүй байв.

Засвар, хэсэг 1: Spring ашиглаж чадах тохиргоо

Төсөлд өгөгдлийн сан байвал одоо Spring-ийн уншдаг орчны хувьсагчдыг мөн өгдөг:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME ба SPRING_DATASOURCE_PASSWORD, DATABASE_URL-аас хөрвүүлсэн (URL өөрөөр заагаагүй бол SSL шаардлагатай).
• Унтсаны дараа амьд үлддэг pool тохиргоонууд:

Idle холболт хадгалахгүй байвал сэрсэн апп үхсэн олон холболтыг давахын оронд нэг шинэ холболт нээнэ.

Эдгээр хувьсагчид байвал Spring pool-ийг өөрөө тохируулж, тохиргоо хэрэгжинэ. Төсөл өөрөө тохируулсан зүйл үргэлж давамгайлна; бид зөвхөн дутуу байгааг нөхдөг. Spring биш апп эдгээр хувьсагчийг үл тоомсорлодог.

Бараг ямар ч үр дүнгүй болгох нарийн зүйл

Spring орчны хувьсагчдыг тохиргоонд зураглах дүрэм нь буруу хийхэд хялбар. minimum-idle тохиргоо SPRING_DATASOURCE_HIKARI_MINIMUMIDLE гэж бичигдэх ёстой — зураасууд хасагдаж, үгнүүд залгагдана. SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE гэж бичвэл, энэ нь илүү байгалийн мэт харагдах ч, өөр, байхгүй тохиргоо (minimum.idle) руу зурагдаж, чимээгүйхэн үл тоомсорлогддог.

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

Засвар, хэсэг 2: бусад бүх stack

Spring цорын ганц pool-тэй фреймворк биш, мөн бид бүх хэлний бүх сангийн тохиргоог урьдчилан тохируулж чадахгүй. Тиймээс Mythex-ийн агент — таны аппыг бичдэг AI — одоо аливаа stack-ийн стандарт зааварт: нийтлэгдсэн апп болон тэдгээрийн өгөгдлийн сан унтдаг тул нээлттэй үлдсэн холболт дараагийн хүсэлтэд үхсэн байж болно. Тэрээр:

• ашиглахаас өмнө idle өгөгдлийн сангийн холболтыг нээлттэй байлгахгүй, эсвэл бүрийг шалгана,
• холболтын алдаанд нэг удаа дахин оролдоно, мөн
• DATABASE_URL-ийг задлан өөрийн pool барихын оронд орчинд платформын өгсөн өгөгдлийн сангийн тохиргоог ашиглана.

Сүүлийн цэг нь хэсэг 1-тэй холбоо үүсгэдэг: тохиргоо унтаж сэрэхэд аюулгүй байхаар бүтээсэн апп автоматаар тэр тохиргоог авна.

Үр дүн

Бид нийтлэгдсэн аппуудаа ажиллуулдаг платформ дээр хэмжсэнээр, сэрсний дараах эхний хүсэлт 12.7 секундээс 2.3 секунд болсон.

Бидний авсан дүгнэлт

• Унтдаг давхарга бүр юу үлдэхийг тохиролцох ёстой. Хөлдсөн апп болон унтсан өгөгдлийн сан бүр боломжийн сонголт хийсэн. Хамтдаа апп үнэн биш төлөвтэй сэрсэн.
• Байнгын серверт зориулсан анхдагч утгууд тэг хүртэл масштабладаг аппд тохирохгүй. Холболтуудыг дулаан байлгах нь сайн санаа, гэхдээ тэдний эргэн тойрон бүх зүйл хүйтэрэх хүртэл.
• Фреймворкт өгөгдлөө өөрийн форматаар өг. Нэг URL бидэнд энгийн байсан ч Spring апп бүрийг өөрийн тохиргоог үл тоомсордог pool гараар бичихэд хүргэсэн.
• Тохиргоо фреймворкийн уншдаг зөв бичгээр бичигдсэнийг шалга. Буруу нэрний дор зөв утга ямар ч үр дүнгүй, чимээгүйхэн.

Mythex дээр өгөгдлийн сан хэрхэн ажилладагийг хүсвэл өгөгдлийн сангийн баримт болон Postgres гэж юу вэ гарын авлагыг үзнэ үү.