Բազաները արթնացնելը՝ առանց մեռած կապերի

Mythex-ում հրապարակված հավելվածները և դրանց տվյալների բազաները քնում են, երբ ոչ ոք չի օգտագործում դրանք։ Երբ հավելվածը արթնանում էր, այն կարող էր իր առաջին հարցումը 10–12 վայրկյան պահել, քանի որ փորձում էր վերօգտագործել տվյալների բազայի կապեր, որոնք մեռել էին ամբողջի քնած ժամանակ։ Այժմ Spring Boot հավելվածներին տալիս ենք տվյալների բազայի կարգավորումներ, որոնք ապահով են քնի հետո, և ասում ենք agent-ին, որ ցանկացած stack-ի հավելվածներ կառուցի նույն կերպ։ Հարթակում առաջին հարցումը արթնանալուց հետո 12.7 վայրկյանից իջավ 2.3 վայրկյանի։

Ինչու հավելվածները և բազաները քնում են

Մեկ Mythex հրապարակված հավելված աշխատում է մեքենայի վրա, որը մի քանի պարապ րոպեից հետո կասեցվում է, և նրա տվյալների բազան serverless Postgres է, որը քնում է հինգ պարապ րոպեից հետո և արթնանում հաջորդ հարցումով։ Դա է պահում հանգիստ հավելվածը էժան․ վճարում եք այն համար, ինչ բազան իրականում օգտագործել է, և քնած հավելվածը ոչինչ չի ծախսում հաշվողական ռեսուրսի վրա։ Մենք գրել ենք billing կողմի մասին բազաները վճարում ենք ըստ իրական օգտագործման հոդվածում։

Բայց կա մի բան․ երկուսը քնում են առանձին և համաձայն չեն, թե ինչ է կապը։

Սիմպտոմը՝ դանդաղ առաջին այց

Ի սերվերային հավելվածների մեծ մասը պահում է 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-ը կարգավորումներից, ներառյալ թե քանի պարապ կապ պահել։

Բայց Mythex-ը յուրաքանչյուր հավելվածին տալիս է իր տվյալների բազան որպես մեկ DATABASE_URL՝ postgresql://user:pass@host/db ձևով։ Spring-ը այդ ձևաչափը ուղիղ չի կարդում։ Ուստի Mythex-ի վրա կառուցված Spring հավելվածները pool-ը կառուցում էին կոդով՝ այդ URL-ը վերլուծելով, իսկ ձեռքով կառուցված pool-ը անտեսում է Spring-ի բոլոր spring.datasource.* կարգավորումները։ Նույնիսկ եթե ինչ-որ մեկը գիտեր ճիշտ pool կարգավորումները, դրանք ոչ մի տեղ չէին գործի։

Շտկումը, մաս 1՝ կարգավորումներ, որոնք Spring-ը կարող է օգտագործել

Երբ նախագիծն ունի տվյալների բազա, այժմ նաև տալիս ենք միջավայրի փոփոխականներ, որ Spring-ը կարդում է բնականաբար․

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME և SPRING_DATASOURCE_PASSWORD, փոխարկված DATABASE_URL-ից (SSL-ը պահանջվում է, եթե URL-ը այլ բան չի ասում)։
• Pool կարգավորումներ, որոնք դիմանում են քնին․

Քանի որ պարապ կապեր չեն պահվում, արթնացած հավելվածը բացում է մեկ նոր կապ՝ մեռածների միջով անցնելու փոխարեն։

Երբ այս փոփոխականները առկա են, Spring-ը ինքն է կարգավորում pool-ը, և կարգավորումները գործում են։ Նախագծի սեփական սահմանած ցանկացած բան միշտ գերազանցում է, մենք լրացնում ենք միայն բացակայողը։ Spring-ը չլինող հավելվածները այս փոփոխականները անտեսում են։

Մանրամասնը, որ գրեթե ոչինչ չէր անի

Spring-ը միջավայրի փոփոխականները իր կարգավորումների վրա քարտեզագրում է կանոնով, որը հեշտ է սխալվել։ minimum-idle կարգավորումը պետք է գրվի որպես SPRING_DATASOURCE_HIKARI_MINIMUMIDLE — գծիկները հանված, բառերը միացված։ Գրելով SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, ինչը ավելի բնական է թվում, քարտեզագրվում է այլ, գոյություն չունեցող կարգավորման (minimum.idle) վրա և լուռ անտեսվում է։

Այդ տեսակի սխալը անցնում է յուրաքանչյուր վերանայում և արտադրության մեջ ոչինչ չի անում։ Ուստի թեստը ստուգում է երկուսը՝ որ արժեքները սահմանված են և որ ոչ մի փոփոխական չի օգտագործում ներքևի գծիկով բաժանված ձևը։

Շտկումը, մաս 2՝ մյուս բոլոր stack-երը

Spring-ը միակ շրջանակը չէ, որ ունի pool, և մենք չենք կարող նախապես կարգավորել յուրաքանչյուր գրադարան յուրաքանչյուր լեզվով։ Ուստի Mythex agent-ը՝ AI, որ գրում է ձեր հավելվածը, այժմ ստանում է մշտական հրահանգ ցանկացած stack-ի համար։ Հրապարակված հավելվածները և դրանց տվյալների բազաները քնում են, երբ պարապ են, ուստի կապը, որ բաց է պահվել, կարող է մեռած լինել հաջորդ հարցման ժամանակ։ Այն պետք է․

• պարապ տվյալների բազայի կապեր բաց չպահի, կամ յուրաքանչյուրը ստուգի օգտագործումից առաջ,
• կապի սխալի դեպքում մեկ անգամ նորից փորձի, և
• օգտագործի հարթակի տրամադրած տվյալների բազայի կարգավորումները միջավայրից, ոչ թե իր սեփական pool-ը կառուցի՝ DATABASE_URL-ը վերլուծելով։

Վերջին կետը փակում է շրջանը առաջին մասի հետ․ հավելվածը, որը կառուցված է տրամադրված կարգավորումներով, ավտոմատ ստանում է քնի համար անվտանգ կոնֆիգուրացիան։

Արդյունքը

Չափված հարթակում, որտեղ մենք գործարկում ենք հրապարակված հավելվածները, առաջին հարցումը արթնանալուց հետո գնաց 12.7 վայրկյանից մինչև 2.3 վայրկյան։

Ինչ սովորեցինք

• Յուրաքանչյուր շերտ, որ քնում է, պետք է համաձայն լինի, թե ինչը է գոյատևում։ Սառած հավելվածն ու քնած բազան յուրաքանչյուրը ողջամիտ ընտրություն արեցին։ Միասին՝ հավելվածը արթնացավ՝ պահելով վիճակ, որը այլևս ճիշտ չէր։
• Միշտ միացված սերվերների համար նախագծված լռելյայն արժեքները չեն համապատասխանում հավելվածներին, որոնք մասշտաբավորվում են մինչև զրո։ Կապերը տաք պահելը լավ գաղափար է, մինչև ամբողջ շրջապատը սառի։
• Տվյալները շրջանակին տվեք նրա սեփական ձևաչափով։ Մեկ URL-ը մեզ համար պարզ էր, բայց ստիպեց յուրաքանչյուր Spring հավելվածին ձեռքով կառուցել pool, որն անտեսում էր իր սեփական կոնֆիգուրացիան։
• Թեստավորեք, որ կարգավորումը գրված է այնպես, ինչպես շրջանակն է կարդում։ Ճիշտ արժեքը սխալ անունով ոչինչ չի անում, լուռ։

Եթե նոր եք Mythex-ում տվյալների բազաների աշխատանքի հետ, տե՛ս տվյալների բազայի փաստաթղթերը և մեր բացատրությունը՝ ինչ է Postgres-ը։