URUS ընկերությունը փորձեց Kubernetes-ը տարբեր ձևերով՝ անկախ տեղակայում մերկ մետաղի վրա, Google Cloud-ում, այնուհետև իր հարթակը տեղափոխեց Mail.ru Cloud Solutions (MCS) ամպ: Իգոր Շիշկինը պատմում է, թե ինչպես են ընտրել նոր ամպային մատակարար և ինչպես են նրանց հաջողվել գաղթել այնտեղ ռեկորդային երկու ժամում (), համակարգի ավագ ադմինիստրատոր URUS-ում:
Ի՞նչ է անում URUS-ը:
Քաղաքային միջավայրի որակը բարելավելու բազմաթիվ եղանակներ կան, և դրանցից մեկն այն էկոլոգիապես մաքուր դարձնելն է: Սա հենց այն է, ինչի վրա աշխատում է URUS - Smart Digital Services ընկերությունը: Այստեղ նրանք իրականացնում են լուծումներ, որոնք օգնում են ձեռնարկություններին վերահսկել բնապահպանական կարևոր ցուցանիշները և նվազեցնել դրանց բացասական ազդեցությունը շրջակա միջավայրի վրա: Սենսորները հավաքում են տվյալներ օդի կազմի, աղմուկի մակարդակի և այլ պարամետրերի վերաբերյալ, այնուհետև դրանք ուղարկում են միասնական URUS-Ekomon հարթակ՝ վերլուծության և առաջարկություններ տալու համար:
Ինչպես է URUS-ը աշխատում ներսից
URUS-ի տիպիկ հաճախորդը այն ընկերությունն է, որը գտնվում է բնակելի տարածքում կամ մոտակայքում: Սա կարող է լինել գործարան, նավահանգիստ, երկաթուղային պահեստ կամ որևէ այլ օբյեկտ: Եթե մեր հաճախորդն արդեն նախազգուշացում է ստացել, տուգանվել է շրջակա միջավայրի աղտոտման համար, կամ ցանկանում է ավելի քիչ աղմուկ բարձրացնել, նվազեցնել վնասակար արտանետումների քանակը, նա գալիս է մեզ մոտ, և մենք նրան արդեն առաջարկում ենք շրջակա միջավայրի մոնիտորինգի պատրաստի լուծում։
H2S-ի կոնցենտրացիայի մոնիտորինգի գրաֆիկը ցույց է տալիս մոտակա գործարանից գիշերային արտանետումները
Սարքերը, որոնք մենք օգտագործում ենք URUS-ում, պարունակում են մի քանի սենսորներ, որոնք տեղեկատվություն են հավաքում որոշակի գազերի պարունակության, աղմուկի մակարդակի և այլ տվյալների մասին՝ բնապահպանական իրավիճակը գնահատելու համար: Սենսորների ճշգրիտ թիվը միշտ որոշվում է կոնկրետ առաջադրանքով:
Կախված չափումների առանձնահատկություններից՝ սենսորներով սարքերը կարող են տեղակայվել շենքերի, սյուների և այլ կամայական վայրերի պատերին։ Յուրաքանչյուր նման սարք հավաքում է տեղեկատվություն, համախմբում և ուղարկում տվյալների ընդունման դարպաս: Այնտեղ մենք տվյալները պահպանում ենք երկարաժամկետ պահպանման համար և նախապես մշակում դրանք հետագա վերլուծության համար: Ամենապարզ օրինակը, թե ինչ ենք ստանում վերլուծության արդյունքում, օդի որակի ինդեքսն է, որը հայտնի է նաև որպես AQI:
Զուգահեռաբար մեր հարթակում գործում են բազմաթիվ այլ ծառայություններ, սակայն դրանք հիմնականում ծառայողական բնույթ են կրում։ Օրինակ, ծանուցման ծառայությունը ծանուցումներ է ուղարկում հաճախորդներին, եթե վերահսկվող պարամետրերից որևէ մեկը (օրինակ՝ CO2 պարունակությունը) գերազանցում է թույլատրելի արժեքը:
Ինչպես ենք մենք պահպանում տվյալները: Kubernetes-ի պատմությունը մերկ մետաղի վրա
URUS-ի շրջակա միջավայրի մոնիտորինգի նախագիծն ունի տվյալների մի քանի պահեստ: Մեկում մենք պահում ենք «հում» տվյալներ՝ այն, ինչ ստացել ենք անմիջապես սարքերից: Այս պահեստը «մագնիսական» ժապավեն է, ինչպես հին ձայներիզների վրա, բոլոր ցուցանիշների պատմությունով: Պահպանման երկրորդ տեսակն օգտագործվում է նախապես մշակված տվյալների համար՝ սարքերից ստացված տվյալներ, որոնք հարստացված են մետատվյալներով՝ կապված սենսորների և սարքերի ընթերցումների միջև կապերի, կազմակերպությունների, գտնվելու վայրի հետ փոխկապակցվածության, գտնվելու վայրի հետ և այլն: Այս տեղեկատվությունը թույլ է տալիս դինամիկ կերպով գնահատել, թե ինչպես է որոշակի ցուցանիշը: փոխվել է որոշակի ժամանակահատվածում: Մենք օգտագործում ենք «հում» տվյալների պահեստը, ի թիվս այլ բաների, որպես կրկնօրինակ և նախապես մշակված տվյալները վերականգնելու համար, եթե նման անհրաժեշտություն առաջանա:
Երբ մենք մի քանի տարի առաջ փորձում էինք լուծել մեր պահեստավորման խնդիրը, մենք ունեինք հարթակի երկու ընտրություն՝ Kubernetes և OpenStack: Բայց քանի որ վերջինս բավականին հրեշավոր տեսք ունի (ուղղակի նայեք նրա ճարտարապետությանը, որպեսզի համոզվեք դրանում), մենք տեղավորվեցինք Կուբերնետեսում։ Նրա օգտին մեկ այլ փաստարկ էր համեմատաբար պարզ ծրագրային կառավարումը, նույնիսկ ապարատային հանգույցները ըստ ռեսուրսների ավելի ճկուն կտրելու հնարավորությունը:
Ինքը՝ Kubernetes-ի յուրացմանը զուգահեռ, մենք նաև ուսումնասիրեցինք տվյալների պահպանման ուղիները, մինչդեռ Kubernetes-ում մեր ամբողջ պահեստը պահեցինք մեր սեփական սարքաշարի վրա, ստացանք գերազանց փորձ: Այն ամենը, ինչ մենք այն ժամանակ ապրում էինք Kubernetes-ում. պետական պահեստավորում, մոնիտորինգի համակարգ, CI/CD: Kubernetes-ը մեզ համար դարձել է բոլորը մեկում հարթակ:
Բայց մենք ուզում էինք աշխատել Kubernetes-ի հետ որպես ծառայություն, այլ ոչ թե զբաղվել դրա աջակցությամբ և զարգացմամբ: Բացի այդ, մեզ դուր չեկավ, թե որքան արժեր այն մերկ մետաղի վրա պահելը, և մենք անընդհատ զարգացման կարիք ունեինք: Օրինակ, առաջին խնդիրներից մեկը Kubernetes Ingress կարգավարների ինտեգրումն էր մեր կազմակերպության ցանցային ենթակառուցվածքում: Սա ծանր խնդիր է, հատկապես հաշվի առնելով, որ այն ժամանակ ոչինչ պատրաստ չէր ծրագրային ռեսուրսների կառավարման համար, ինչպիսիք են DNS գրառումները կամ IP հասցեների բաշխումը: Ավելի ուշ մենք սկսեցինք փորձեր կատարել արտաքին տվյալների պահպանման հետ: Մենք երբեք չհասանք PVC կարգավորիչի ներդրմանը, բայց նույնիսկ այն ժամանակ պարզ դարձավ, որ սա աշխատանքի մեծ տարածք է, որը պահանջում է նվիրված մասնագետներ:
Google Cloud Platform-ին անցնելը ժամանակավոր լուծում է
Մենք հասկացանք, որ դա չի կարող շարունակվել, և մեր տվյալները մերկ մետաղից տեղափոխեցինք Google Cloud Platform: Իրականում, այն ժամանակ ռուսական ընկերության համար շատ հետաքրքիր տարբերակներ չկային. բացի Google Cloud Platform-ից, միայն Amazon-ն էր առաջարկում նմանատիպ ծառայություն, բայց մենք դեռ լուծում էինք Google-ից։ Հետո մեզ թվում էր տնտեսապես ավելի շահավետ, ավելի մոտ Upstream-ին, էլ չասած այն փաստի մասին, որ Google-ն ինքնին մի տեսակ PoC Kubernetes է արտադրության մեջ։
Առաջին հիմնական խնդիրը հորիզոնում հայտնվեց, երբ մեր հաճախորդների բազան աճեց: Երբ անձնական տվյալները պահելու կարիք ունեինք, ընտրության առաջ կանգնեցինք՝ կամ աշխատում ենք Google-ի հետ և խախտում ռուսական օրենքները, կամ այլընտրանք ենք փնտրում Ռուսաստանի Դաշնությունում։ Ընտրությունը, ընդհանուր առմամբ, կանխատեսելի էր. 🙂
Ինչպես մենք տեսանք իդեալական ամպային ծառայություն
Որոնման սկզբում մենք արդեն գիտեինք, թե ինչ ենք ուզում ստանալ ապագա ամպային մատակարարից: Ինչ ծառայություն էինք փնտրում.
- Արագ և ճկուն. Այնպիսին, որ մենք ցանկացած պահի կարող ենք արագ ավելացնել նոր հանգույց կամ ինչ-որ բան տեղակայել:
- Էժան. Մեզ խիստ մտահոգում էր ֆինանսական հարցը, քանի որ ռեսուրսները սահմանափակ էին։ Մենք արդեն գիտեինք, որ ցանկանում ենք աշխատել Kubernetes-ի հետ, և այժմ խնդիրն այն էր, որ նվազագույնի հասցնենք դրա արժեքը, որպեսզի բարձրացնենք կամ գոնե պահպանենք այս լուծումն օգտագործելու արդյունավետությունը:
- Ավտոմատացված. Մենք նախատեսում էինք ծառայության հետ աշխատել API-ի միջոցով՝ առանց մենեջերների և հեռախոսազանգերի կամ այնպիսի իրավիճակների, երբ մեզ անհրաժեշտ է ձեռքով բարձրացնել մի քանի տասնյակ հանգույց արտակարգ ռեժիմում: Քանի որ մեր գործընթացների մեծ մասը ավտոմատացված է, մենք նույնն էինք սպասում ամպային ծառայությունից:
- Սերվերներով Ռուսաստանի Դաշնությունում. Իհարկե, մենք նախատեսում էինք համապատասխանել ռուսական օրենսդրությանը և նույն 152-FZ-ին:
Այն ժամանակ Ռուսաստանում քիչ էին Kubernetes aaS պրովայդերները, և պրովայդեր ընտրելիս մեզ համար կարևոր էր չզիջել մեր առաջնահերթությունները։ Mail.ru Cloud Solutions թիմը, որի հետ մենք սկսել ենք աշխատել և դեռ համագործակցում ենք, մեզ տրամադրել է լիովին ավտոմատացված ծառայություն, API-ի աջակցությամբ և հարմար կառավարման վահանակ, որը ներառում է Horizon-ը, որի միջոցով մենք կարող ենք արագ բարձրացնել կամայական թվով հանգույցներ:
Ինչպես մեզ հաջողվեց երկու ժամում գաղթել MCS
Նման քայլերի ժամանակ շատ ընկերություններ բախվում են դժվարությունների ու անհաջողությունների, իսկ մեր դեպքում չկար: Մեր բախտը բերեց. քանի որ մենք արդեն աշխատում էինք Kubernetes-ի վրա մինչև միգրացիան, մենք պարզապես ուղղեցինք երեք ֆայլ և գործարկեցինք մեր ծառայությունները նոր ամպային հարթակում՝ MCS-ում: Հիշեցնեմ, որ այդ ժամանակ մենք վերջնականապես թողել էինք մերկ մետաղը և ապրում էինք Google Cloud Platform-ում։ Հետևաբար, քայլն ինքնին տևեց ոչ ավելի, քան երկու ժամ, գումարած մի փոքր ավելի շատ ժամանակ (մոտ մեկ ժամ) ծախսվեց մեր սարքերից տվյալների պատճենման վրա: Այն ժամանակ մենք արդեն օգտագործում էինք Spinnaker-ը (բազմամպային CD ծառայություն՝ շարունակական առաքում ապահովելու համար): Մենք նաև արագ ավելացրինք այն նոր կլաստերին և շարունակեցինք աշխատել սովորականի պես:
Մշակման գործընթացների ավտոմատացման և CI/CD-ի շնորհիվ Kubernetes-ը URUS-ում ղեկավարվում է մեկ մասնագետի կողմից (և դա ես եմ): Ինչ-որ փուլում ինձ հետ մեկ այլ համակարգի ադմինիստրատոր աշխատեց, բայց հետո պարզվեց, որ մենք արդեն ավտոմատացրել ենք բոլոր հիմնական առօրյան, և մեր հիմնական արտադրանքի կողմից ավելի ու ավելի շատ առաջադրանքներ կան, և իմաստալից էր ռեսուրսներ ուղղել դրան:
Մենք ստացանք այն, ինչ ակնկալում էինք ամպային մատակարարից, քանի որ սկսեցինք համագործակցել առանց պատրանքների: Եթե եղել են միջադեպեր, ապա դրանք հիմնականում տեխնիկական են եղել և այնպիսիք, որոնք հեշտությամբ կարելի է բացատրել ծառայության հարաբերական թարմությամբ։ Հիմնական բանը այն է, որ MCS թիմը արագորեն վերացնում է թերությունները և արագ արձագանքում մեսենջերների հարցերին:
Եթե ես համեմատեմ իմ փորձը Google Cloud Platform-ի հետ, նրանց դեպքում ես նույնիսկ չգիտեի, թե որտեղ է հետադարձ կապի կոճակը, քանի որ դրա կարիքը պարզապես չկար։ Եվ եթե ինչ-որ խնդիր առաջացավ, Google-ն ինքը միակողմանի ծանուցումներ ուղարկեց: Բայց MCS-ի դեպքում, կարծում եմ, մեծ առավելությունն այն է, որ նրանք հնարավորինս մոտ են ռուս հաճախորդներին՝ և՛ աշխարհագրորեն, և՛ մտավոր:
Ինչպես ենք մենք տեսնում ապագայում ամպերի հետ աշխատելը
Այժմ մեր աշխատանքը սերտորեն կապված է Kubernetes-ի հետ, և այն լիովին համապատասխանում է մեզ ենթակառուցվածքային խնդիրների տեսանկյունից։ Հետևաբար, մենք չենք նախատեսում որևէ տեղ գաղթել դրանից, թեև անընդհատ ներդնում ենք նոր պրակտիկա և ծառայություններ՝ սովորական առաջադրանքները պարզեցնելու և նորերը ավտոմատացնելու, ծառայությունների կայունությունն ու հուսալիությունը բարձրացնելու համար... Այժմ մենք գործարկում ենք Chaos Monkey ծառայությունը (մասնավորապես. , մենք օգտագործում ենք chaoskube, բայց դա չի փոխում հայեցակարգը՝ ), որն ի սկզբանե ստեղծվել է Netflix-ի կողմից։ Chaos Monkey-ն անում է մի պարզ բան՝ պատահական ժամանակ ջնջում է պատահական Kubernetes pod-ը: Սա անհրաժեշտ է, որպեսզի մեր ծառայությունը նորմալ ապրի n–1 դեպքերի քանակով, այնպես որ մենք ինքներս մեզ պատրաստում ենք պատրաստ լինել ցանկացած խնդրի:
Այժմ ես տեսնում եմ երրորդ կողմի լուծումների օգտագործումը՝ նույն ամպային հարթակները, որպես միակ ճիշտ բան երիտասարդ ընկերությունների համար: Սովորաբար, իրենց ճանապարհորդության սկզբում նրանք սահմանափակ են ռեսուրսներով՝ և՛ մարդկային, և՛ ֆինանսական, և սեփական ամպի կամ տվյալների կենտրոնի կառուցումն ու պահպանումը չափազանց թանկ և աշխատատար է: Ամպային պրովայդերները թույլ են տալիս նվազագույնի հասցնել այդ ծախսերը, դուք կարող եք արագորեն նրանցից ստանալ ծառայությունների շահագործման համար անհրաժեշտ ռեսուրսները այստեղ և հիմա, և այդ ռեսուրսների համար վճարել փաստից հետո: Ինչ վերաբերում է URUS ընկերությանը, մենք առայժմ հավատարիմ ենք մնալու Kubernetes-ին ամպի մեջ։ Բայց ով գիտի, գուցե ստիպված լինենք աշխարհագրորեն ընդլայնել, կամ ինչ-որ կոնկրետ սարքավորումների հիման վրա լուծումներ իրականացնել: Կամ գուցե սպառված ռեսուրսների քանակն արդարացնի սեփական Kubernetes-ը մերկ մետաղի վրա, ինչպես հին լավ ժամանակներում: 🙂
Այն, ինչ մենք սովորեցինք ամպային ծառայությունների հետ աշխատելուց
Մենք սկսեցինք օգտագործել Kubernetes-ը մերկ մետաղի վրա, և նույնիսկ այնտեղ այն յուրովի լավ էր: Բայց դրա ուժեղ կողմերը բացահայտվեցին հենց որպես aaS բաղադրիչ ամպի մեջ: Եթե դուք նպատակ եք դնում և հնարավորինս ավտոմատացնում եք ամեն ինչ, դուք կկարողանաք խուսափել վաճառողի արգելափակումից, և ամպային մատակարարների միջև տեղաշարժը կպահանջի մի քանի ժամ, իսկ նյարդային բջիջները կմնան մեզ հետ: Մենք կարող ենք խորհուրդ տալ այլ ընկերությունների. եթե ցանկանում եք գործարկել ձեր սեփական (ամպային) ծառայությունը, ունենալով սահմանափակ ռեսուրսներ և զարգացման առավելագույն արագություն, սկսեք հենց հիմա վարձակալել ամպային ռեսուրսները և կառուցեք ձեր տվյալների կենտրոնը այն բանից հետո, երբ Forbes-ը գրի ձեր մասին:
Source: www.habr.com