Նշում. թարգմ.Աշխարհահռչակ Tinder ծառայության աշխատակիցները վերջերս կիսվել են իրենց ենթակառուցվածքները Kubernetes տեղափոխելու որոշ տեխնիկական մանրամասներով: Գործընթացը տևեց գրեթե երկու տարի և հանգեցրեց շատ լայնածավալ հարթակի գործարկմանը K8-ների վրա, որը բաղկացած է 200 ծառայություններից, որոնք տեղակայված են 48 հազար կոնտեյներների վրա: Ի՞նչ հետաքրքիր դժվարությունների հանդիպեցին Tinder-ի ինժեներները և ի՞նչ արդյունքների եկան, կարդացեք այս թարգմանությունը։
Ինչու?
Գրեթե երկու տարի առաջ Tinder-ը որոշեց իր հարթակը տեղափոխել Kubernetes: Kubernetes-ը թույլ կտա Tinder թիմին բեռնարկղեր տեղափոխել և տեղափոխել արտադրություն՝ նվազագույն ջանքերով անփոփոխ տեղակայման միջոցով: (անփոփոխ տեղակայում). Այս դեպքում հավելվածների հավաքումը, դրանց տեղակայումը և բուն ենթակառուցվածքը եզակի կերպով կսահմանվեն ծածկագրով:
Մենք նաև լուծում էինք փնտրում մասշտաբայնության և կայունության խնդրին։ Երբ մասշտաբը դառնում էր կրիտիկական, մենք հաճախ ստիպված էինք սպասել մի քանի րոպե, մինչև EC2 նոր օրինակները պտտվեն: Մեզ համար շատ գրավիչ դարձավ կոնտեյներներ գործարկելու և երթևեկության սպասարկումը րոպեների փոխարեն վայրկյանների ընթացքում սկսելու գաղափարը։
Գործընթացը բարդ ստացվեց. 2019 թվականի սկզբին մեր միգրացիայի ընթացքում Kubernetes կլաստերը հասավ կրիտիկական զանգվածի, և մենք սկսեցինք հանդիպել տարբեր խնդիրների՝ կապված երթևեկության ծավալի, կլաստերի չափի և DNS-ի հետ: Ճանապարհին մենք լուծեցինք բազմաթիվ հետաքրքիր խնդիրներ՝ կապված 200 ծառայությունների միգրացիայի և Kubernetes կլաստերի պահպանման հետ, որը բաղկացած է 1000 հանգույցներից, 15000 պատիճներից և 48000 գործող կոնտեյներներից:
Ինչպես?
2018 թվականի հունվարից մենք անցել ենք միգրացիայի տարբեր փուլեր։ Մենք սկսեցինք կոնտեյներավորելով մեր բոլոր ծառայությունները և դրանք տեղակայելով Kubernetes-ի փորձնական ամպային միջավայրերում: Հոկտեմբերից սկսած՝ մենք սկսեցինք մեթոդաբար տեղափոխել բոլոր առկա ծառայությունները Kubernetes: Հաջորդ տարվա մարտ ամսին մենք ավարտեցինք միգրացիան, և այժմ Tinder հարթակն աշխատում է բացառապես Kubernetes-ով։
Պատկերների կառուցում Kubernetes-ի համար
Մենք ունենք ավելի քան 30 ելակետային կոդի պահոց միկրոծառայությունների համար, որոնք աշխատում են Kubernetes կլաստերի վրա: Այս շտեմարանների կոդը գրված է տարբեր լեզուներով (օրինակ՝ Node.js, Java, Scala, Go) միևնույն լեզվի համար մի քանի գործարկման միջավայրերով:
Կառուցման համակարգը նախատեսված է յուրաքանչյուր միկրոծառայության համար լիովին կարգավորելի «կառուցման համատեքստ» ապահովելու համար: Այն սովորաբար բաղկացած է Dockerfile-ից և կեղևի հրամանների ցանկից: Նրանց բովանդակությունը լիովին հարմարեցված է, և միևնույն ժամանակ, այս բոլոր կառուցապատման համատեքստերը գրված են ստանդարտացված ձևաչափով: Կառուցման համատեքստերի ստանդարտացումը թույլ է տալիս մեկ կառուցման համակարգին կառավարել բոլոր միկրոծառայությունները:
Նկար 1-1. Ստանդարտացված կառուցման գործընթաց Builder կոնտեյների միջոցով
Գործարկման ժամանակների միջև առավելագույն հետևողականության հասնելու համար (գործողության միջավայրեր) նույն կառուցման գործընթացը օգտագործվում է մշակման և փորձարկման ժամանակ: Մենք բախվեցինք մի շատ հետաքրքիր մարտահրավերի՝ մենք պետք է մշակեինք միջոց՝ ապահովելու կառուցապատման միջավայրի հետևողականությունը ամբողջ հարթակում: Դրան հասնելու համար հավաքման բոլոր գործընթացներն իրականացվում են հատուկ կոնտեյների ներսում: Շինարար.
Նրա կոնտեյների իրականացումը պահանջում էր Docker-ի առաջադեմ տեխնիկա: Builder-ը ժառանգում է տեղական օգտատիրոջ ID-ն և գաղտնիքները (օրինակ՝ SSH ստեղնը, AWS հավատարմագրերը և այլն), որոնք անհրաժեշտ են անձնական Tinder պահոցներ մուտք գործելու համար: Այն տեղադրում է տեղական դիրեկտորիաներ, որոնք պարունակում են աղբյուրներ՝ բնական կառուցված արտեֆակտները պահելու համար: Այս մոտեցումը բարելավում է կատարումը, քանի որ այն վերացնում է Builder կոնտեյների և հյուրընկալողի միջև կառուցվող արտեֆակտները պատճենելու անհրաժեշտությունը: Պահված շինարարական արտեֆակտները կարող են կրկին օգտագործվել առանց լրացուցիչ կազմաձևման:
Որոշ ծառայությունների համար մենք պետք է մեկ այլ կոնտեյներ ստեղծեինք՝ կոմպիլացիոն միջավայրը գործարկման ժամանակի միջավայրին քարտեզագրելու համար (օրինակ՝ Node.js bcrypt գրադարանը տեղադրման ժամանակ ստեղծում է հարթակին հատուկ երկուական արտեֆակտներ)։ Կազմման գործընթացում պահանջները կարող են տարբեր լինել ծառայությունների միջև, և վերջնական Dockerfile-ը կազմվում է անմիջապես:
Kubernetes կլաստերի ճարտարապետություն և միգրացիա
Կլաստերների չափի կառավարում
Մենք որոշեցինք օգտագործել kube-aws Amazon EC2 օրինակներում ավտոմատացված կլաստերի տեղակայման համար: Հենց սկզբում ամեն ինչ աշխատում էր հանգույցների մեկ ընդհանուր լողավազանում: Մենք արագ հասկացանք, որ անհրաժեշտ է առանձնացնել ծանրաբեռնվածությունը ըստ չափի և օրինակի տեսակի՝ ռեսուրսներն ավելի արդյունավետ օգտագործելու համար: Տրամաբանությունը կայանում էր նրանում, որ մի քանի բեռնված բազմաշերտ պատիճներ գործարկելն ավելի կանխատեսելի էր կատարողականի տեսանկյունից, քան դրանց համակեցությունը մեծ թվով մեկ թելերով պատիճների հետ:
Ի վերջո, մենք որոշեցինք.
- m5.4x մեծ - մոնիտորինգի համար (Պրոմեթևս);
- c5.4x մեծ - Node.js ծանրաբեռնվածության համար (մեկ թելերով ծանրաբեռնվածություն);
- c5.2x մեծ - Java-ի և Go-ի համար (բազմաթելային ծանրաբեռնվածություն);
- c5.4x մեծ — կառավարման վահանակի համար (3 հանգույց):
Միգրացիա
Հին ենթակառուցվածքից Կուբերնետես տեղափոխելու նախապատրաստական քայլերից մեկը ծառայությունների միջև առկա ուղղակի հաղորդակցությունը վերահղելն էր դեպի նոր բեռի հավասարակշռիչներ (Elastic Load Balancer (ELB): Դրանք ստեղծվել են վիրտուալ մասնավոր ամպի (VPC) հատուկ ենթացանցում: Այս ենթացանցը միացված էր Kubernetes VPC-ին: Սա մեզ թույլ տվեց աստիճանաբար տեղափոխել մոդուլները՝ առանց հաշվի առնելու ծառայության կախվածության հատուկ կարգը:
Այս վերջնակետերը ստեղծվել են՝ օգտագործելով DNS գրառումների կշռված հավաքածուներ, որոնք ունեին CNAME-ներ՝ ուղղված յուրաքանչյուր նոր ELB-ին: Փոխարկելու համար մենք ավելացրինք նոր մուտք, որը մատնանշում է Kubernetes ծառայության նոր ELB-ը 0 կշիռով: Այնուհետև մենք սահմանեցինք 0-ի մուտքի համար ապրելու ժամանակը (TTL): Դրանից հետո հին և նոր կշիռները դարձան: դանդաղորեն ճշգրտվում է, և ի վերջո բեռի 100%-ն ուղարկվում է նոր սերվեր: Անցման ավարտից հետո TTL արժեքը վերադարձավ ավելի համարժեք մակարդակի:
Java մոդուլները, որոնք մենք ունեինք, կարող էին հաղթահարել ցածր TTL DNS, բայց Node հավելվածները՝ ոչ: Ինժեներներից մեկը վերաշարադրեց կապի լողավազանի կոդի մի մասը և այն փաթաթեց մենեջերի մեջ, որը թարմացնում էր լողավազանները յուրաքանչյուր 60 վայրկյանը մեկ: Ընտրված մոտեցումը շատ լավ աշխատեց և առանց կատարողականության նկատելի անկման:
Դասերը
Ցանցի գործվածքի սահմանները
8 թվականի հունվարի 2019-ի վաղ առավոտյան Tinder հարթակն անսպասելիորեն վթարի է ենթարկվել։ Ի պատասխան այդ առավոտ վաղ պլատֆորմի հետաձգման անկապ աճի, կլաստերում ավելացել է պատիճների և հանգույցների թիվը: Սա պատճառ դարձավ, որ ARP քեշը սպառվի մեր բոլոր հանգույցների վրա:
ARP քեշի հետ կապված Linux-ի երեք տարբերակ կա.
()
gc_thresh3 - սա դժվար սահման է: Մատյանում «հարևանների աղյուսակի վարարման» գրառումների հայտնվելը նշանակում էր, որ նույնիսկ համաժամանակյա աղբահանությունից (GC) հետո, ARP քեշում բավարար տարածք չկար՝ հարևան մուտքը պահելու համար: Այս դեպքում միջուկը պարզապես ամբողջությամբ դեն նետեց փաթեթը:
Մենք օգտագործում ենք որպես ցանցային հյուսվածք Kubernetes-ում: Փաթեթները փոխանցվում են VXLAN-ի միջոցով: VXLAN-ը L2 թունել է, որը բարձրացված է L3 ցանցի վերևում: Տեխնոլոգիան օգտագործում է MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation և թույլ է տալիս ընդլայնել Layer 2 ցանցի հատվածները: Ֆիզիկական տվյալների կենտրոնի ցանցի փոխադրման արձանագրությունը IP գումարած UDP է:
Նկար 2–1. Ֆլանելի դիագրամ ()
Նկար 2–2. VXLAN փաթեթ ()
Kubernetes-ի յուրաքանչյուր աշխատող հանգույց հատկացնում է վիրտուալ հասցեների տարածություն /24 դիմակով ավելի մեծ /9 բլոկի վրա: Յուրաքանչյուր հանգույցի համար սա է մեկ մուտք դեպի երթուղային աղյուսակ, մեկ մուտք՝ ARP աղյուսակում (ֆլանել.1 ինտերֆեյսի վրա) և մեկ մուտք՝ փոխարկման աղյուսակում (FDB): Դրանք ավելացվում են առաջին անգամ, երբ աշխատող հանգույցը սկսվում է կամ ամեն անգամ, երբ հայտնաբերվում է նոր հանգույց:
Բացի այդ, հանգույց-pod (կամ pod-pod) հաղորդակցությունը, ի վերջո, անցնում է ինտերֆեյսի միջոցով eth0 (ինչպես ցույց է տրված վերևում գտնվող Ֆլանելի դիագրամում): Սա հանգեցնում է ARP աղյուսակի լրացուցիչ մուտքի յուրաքանչյուր համապատասխան աղբյուրի և նպատակակետի հյուրընկալողի համար:
Մեր միջավայրում հաղորդակցության այս տեսակը շատ տարածված է: Kubernetes-ում սպասարկման օբյեկտների համար ստեղծվում է ELB, և Kubernetes-ը գրանցում է յուրաքանչյուր հանգույց ELB-ում: ELB-ը ոչինչ չգիտի pods-ի մասին, և ընտրված հանգույցը կարող է փաթեթի վերջնական նպատակակետը չլինել: Բանն այն է, որ երբ հանգույցը փաթեթ է ստանում ELB-ից, այն հաշվի է առնում կանոնները. iptables կոնկրետ ծառայության համար և պատահականորեն ընտրում է պատիճ մեկ այլ հանգույցի վրա:
Խափանման պահին կլաստերում կար 605 հանգույց: Վերը նշված պատճառներով սա բավարար էր նշանակությունը հաղթահարելու համար gc_thresh3, որը լռելյայն է: Երբ դա տեղի է ունենում, ոչ միայն փաթեթները սկսում են բաց թողնել, այլև /24 դիմակով Flannel-ի ողջ վիրտուալ հասցեների տարածությունը անհետանում է ARP աղյուսակից: Node-pod հաղորդակցությունը և DNS հարցումները ընդհատվում են (DNS-ը տեղակայված է կլաստերում, մանրամասների համար կարդացեք այս հոդվածում ավելի ուշ):
Այս խնդիրը լուծելու համար անհրաժեշտ է մեծացնել արժեքները gc_thresh1, gc_thresh2 и gc_thresh3 և վերագործարկեք Flannel-ը՝ բացակայող ցանցերը վերագրանցելու համար:
DNS-ի անսպասելի մասշտաբավորում
Միգրացիայի գործընթացում մենք ակտիվորեն օգտագործում էինք DNS՝ երթևեկությունը կառավարելու և հին ենթակառուցվածքից ծառայությունները աստիճանաբար Kubernetes փոխանցելու համար: Մենք սահմանել ենք համեմատաբար ցածր TTL արժեքներ կապված RecordSets-ի համար Route53-ում: Երբ հին ենթակառուցվածքն աշխատում էր EC2 օրինակների վրա, մեր լուծիչի կոնֆիգուրացիան մատնանշեց Amazon DNS-ը: Մենք դա ընդունում էինք որպես տրված, և ցածր TTL-ի ազդեցությունը մեր ծառայությունների և Amazon ծառայությունների վրա (օրինակ՝ DynamoDB) հիմնականում աննկատ մնաց:
Երբ մենք ծառայություններ տեղափոխեցինք Kubernetes, մենք պարզեցինք, որ DNS-ը մշակում է վայրկյանում 250 հազար հարցում: Արդյունքում, հավելվածները սկսեցին մշտական և լուրջ ժամկետներ զգալ DNS հարցումների համար: Դա տեղի ունեցավ՝ չնայած DNS մատակարարի օպտիմիզացման և CoreDNS-ին փոխելու անհավատալի ջանքերին (որը գագաթնակետային ծանրաբեռնվածության ժամանակ հասնում էր 1000 միջուկի վրա աշխատող 120 փոդերի):
Այլ հնարավոր պատճառներ և լուծումներ ուսումնասիրելիս մենք հայտնաբերեցինք , նկարագրելով ռասայական պայմանները, որոնք ազդում են փաթեթների զտման շրջանակի վրա ցանցաֆիլտր Linux-ում։ Մեր նկատած թայմաութները՝ զուգորդված աճող հաշվիչով insert_failed Flannel ինտերֆեյսում համահունչ էին հոդվածի բացահայտումներին:
Խնդիրն առաջանում է աղբյուրի և նպատակակետի ցանցի հասցեների թարգմանության (SNAT և DNAT) և աղյուսակում հետագա մուտքագրման փուլում: contrack. Ներքին քննարկված և համայնքի կողմից առաջարկված լուծումներից մեկը DNS-ը հենց աշխատող հանգույց տեղափոխելն էր: Այս դեպքում:
- SNAT-ն անհրաժեշտ չէ, քանի որ երթևեկությունը մնում է հանգույցի ներսում: Այն պետք չէ ուղղորդել միջերեսի միջոցով eth0.
- DNAT-ն անհրաժեշտ չէ, քանի որ նպատակակետ IP-ն լոկալ է հանգույցի համար, և ոչ պատահականորեն ընտրված պատիճ՝ ըստ կանոնների: iptables.
Մենք որոշեցինք հավատարիմ մնալ այս մոտեցմանը: CoreDNS-ը տեղակայվել է որպես DaemonSet Kubernetes-ում, և մենք ներդրել ենք տեղական DNS սերվեր resolutionv.conf յուրաքանչյուր պատիճ դնելով դրոշակ --կլաստեր-dns թիմերը կուբելետ . Այս լուծումը պարզվեց, որ արդյունավետ է DNS-ի ժամանակի դադարեցման համար:
Այնուամենայնիվ, մենք դեռ տեսանք փաթեթների կորուստ և հաշվիչի աճ insert_failed Flannel ինտերֆեյսում: Սա շարունակվեց այն բանից հետո, երբ լուծումն իրականացվեց, քանի որ մենք կարողացանք վերացնել SNAT-ը և/կամ DNAT-ը միայն DNS տրաֆիկի համար: Երթևեկության այլ տեսակների համար պահպանվել են մրցավազքի պայմանները։ Բարեբախտաբար, մեր փաթեթների մեծ մասը TCP են, և եթե խնդիր է առաջանում, դրանք պարզապես վերահաղորդվում են: Մենք դեռ փորձում ենք հարմար լուծում գտնել բոլոր տեսակի երթևեկության համար։
Օգտագործելով բանագնացը ավելի լավ բեռի հավասարակշռման համար
Երբ մենք տեղափոխեցինք հետնամասային ծառայությունները Kubernetes, մենք սկսեցինք տառապել բլոկների միջև անհավասարակշիռ բեռից: Մենք պարզեցինք, որ HTTP Keepalive-ի պատճառով ELB կապերը կախված են յուրաքանչյուր տեղաբաշխման առաջին պատրաստի բլոկների վրա: Այսպիսով, երթևեկության մեծ մասն անցավ հասանելի պատիճների փոքր տոկոսով: Առաջին լուծումը, որը մենք փորձարկեցինք, MaxSurge-ի 100% սահմանումն էր նոր տեղակայումների դեպքում՝ վատագույն սցենարների համար: Էֆեկտը պարզվեց աննշան և անհեռանկարային ավելի մեծ տեղակայումների առումով:
Մեկ այլ լուծում, որը մենք օգտագործեցինք, կարևոր ծառայությունների համար ռեսուրսների հարցումների արհեստական մեծացումն էր: Այս դեպքում մոտակայքում տեղադրված պատյանները մանևրելու ավելի շատ տեղ կունենան՝ համեմատած այլ ծանր պատիճների հետ: Դա երկարաժամկետ հեռանկարում նույնպես չի աշխատի, քանի որ դա կլինի ռեսուրսների վատնում: Բացի այդ, մեր Node հավելվածները միահյուսված էին և, համապատասխանաբար, կարող էին օգտագործել միայն մեկ միջուկ: Միակ իրական լուծումը ավելի լավ բեռի հավասարակշռման օգտագործումն էր:
Մենք վաղուց էինք ուզում լիովին գնահատել . Ստեղծված իրավիճակը մեզ թույլ տվեց այն շատ սահմանափակ կերպով տեղակայել և անմիջապես արդյունքներ ստանալ։ Envoy-ը բարձր արդյունավետությամբ, բաց կոդով, layer-XNUMX պրոքսի է, որը նախատեսված է մեծ SOA հավելվածների համար: Այն կարող է կիրառել ծանրաբեռնվածության հավասարակշռման առաջադեմ տեխնիկա, ներառյալ ավտոմատ կրկնությունները, անջատիչները և գլոբալ արագության սահմանափակումը: (Նշում. թարգմ.Այս մասին ավելին կարող եք կարդալ այստեղ Istio-ի մասին, որը հիմնված է Envoy-ի վրա):
Մենք ստեղծեցինք հետևյալ կոնֆիգուրացիան. ունեն Envoy sidecar յուրաքանչյուր պատի և մեկ երթուղու համար, և միացրե՛ք կլաստերը կոնտեյների հետ տեղական նավահանգստի միջոցով: Պոտենցիալ կասկադը նվազագույնի հասցնելու և հարվածի փոքր շառավիղը պահպանելու համար մենք օգտագործեցինք Envoy-ի առջևի վստահված ապարատների նավատորմ, մեկը՝ յուրաքանչյուր Հասանելիության գոտու (AZ) յուրաքանչյուր ծառայության համար: Նրանք հիմնվում էին ծառայության հայտնաբերման պարզ շարժիչի վրա, որը գրվել էր մեր ինժեներներից մեկի կողմից, որը պարզապես վերադարձնում էր յուրաքանչյուր AZ-ի պատյանների ցանկը տվյալ ծառայության համար:
Ծառայության front-Envoys-ն այնուհետև օգտագործեց ծառայության հայտնաբերման այս մեխանիզմը մեկ հոսանքին հակառակ մեկ կլաստերի և երթուղու հետ: Մենք սահմանել ենք համապատասխան ժամանակի ընդհատումներ, ավելացրել ենք անջատիչի բոլոր կարգավորումները և ավելացրել ենք նվազագույն կրկնակի կազմաձևում՝ օգնելու միայնակ խափանումներին և ապահովելու սահուն տեղակայումը: Մենք տեղադրեցինք TCP ELB-ն այս ծառայության առջևից յուրաքանչյուրի առջև: Նույնիսկ եթե մեր հիմնական պրոքսի շերտի keepalive-ը խրված էր որոշ Envoy պատիճների վրա, նրանք դեռ կարող էին շատ ավելի լավ կարգավորել բեռը և կազմաձևված էին, որպեսզի հավասարակշռեն minimum_request-ի հետին մասում:
Տեղակայման համար մենք օգտագործեցինք preStop կեռը և՛ հավելվածի, և՛ կողային պատյանների վրա: Կեռիկը սխալ առաջացրեց ադմինիստրատորի վերջնակետի կարգավիճակը ստուգելիս, որը գտնվում է կողային մեքենայի կոնտեյների վրա և որոշ ժամանակ քնեց, որպեսզի ակտիվ կապերը դադարեցվեն:
Պատճառներից մեկը, թե ինչու կարողացանք այդքան արագ շարժվել, պայմանավորված է մանրամասն չափորոշիչներով, որոնք մենք կարողացանք հեշտությամբ ինտեգրվել Պրոմեթևսի տիպիկ տեղադրմանը: Սա թույլ տվեց մեզ հստակ տեսնել, թե ինչ է տեղի ունենում, մինչ մենք կարգավորում էինք կազմաձևման պարամետրերը և վերաբաշխում տրաֆիկը:
Արդյունքներն անմիջապես ու ակնհայտ էին։ Մենք սկսել ենք ամենաանհավասարակշռված ծառայություններից, և այս պահին այն գործում է կլաստերի 12 կարևորագույն ծառայությունների դիմաց։ Այս տարի մենք նախատեսում ենք անցում կատարել ամբողջական սպասարկման ցանցին՝ ավելի առաջադեմ ծառայությունների հայտնաբերման, միացումների անջատման, արտանետումների հայտնաբերման, արագության սահմանափակման և հետագծման միջոցով:
Նկար 3–1. Մեկ ծառայության պրոցեսորի կոնվերգենցիան Envoy-ին անցնելու ժամանակ
Վերջնական արդյունք
Այս փորձառության և լրացուցիչ հետազոտությունների միջոցով մենք ստեղծել ենք ուժեղ ենթակառուցվածքային թիմ՝ մեծ Kubernetes կլաստերների նախագծման, տեղակայման և շահագործման հզոր հմտություններով: Tinder-ի բոլոր ինժեներներն այժմ գիտելիք և փորձ ունեն կոնտեյներներ փաթեթավորելու և Kubernetes-ում հավելվածներ տեղակայելու համար:
Երբ հին ենթակառուցվածքի վրա լրացուցիչ հզորության անհրաժեշտություն առաջացավ, մենք ստիպված եղանք մի քանի րոպե սպասել նոր EC2 օրինակների գործարկմանը: Այժմ բեռնարկղերը սկսում են աշխատել և սկսում են մշակել երթևեկությունը րոպեների փոխարեն վայրկյանների ընթացքում: Մի քանի բեռնարկղերի պլանավորումը մեկ EC2 օրինակի վրա նաև ապահովում է հորիզոնական կենտրոնացման բարելավում: Արդյունքում մենք կանխատեսում ենք EC2019 ծախսերի զգալի կրճատում 2 թվականին՝ նախորդ տարվա համեմատ։
Միգրացիան տևեց գրեթե երկու տարի, բայց մենք այն ավարտեցինք 2019 թվականի մարտին։ Ներկայումս Tinder պլատֆորմն աշխատում է բացառապես Kubernetes կլաստերի վրա, որը բաղկացած է 200 ծառայություններից, 1000 հանգույցներից, 15 պատիճներից և 000 գործող կոնտեյներից: Ենթակառուցվածքն այլևս գործառնական թիմերի միակ տիրույթը չէ: Մեր բոլոր ինժեներները կիսում են այս պատասխանատվությունը և վերահսկում են իրենց հավելվածների ստեղծման և տեղակայման գործընթացը միայն կոդով:
PS թարգմանչից
Կարդացեք նաև մի շարք հոդվածներ մեր բլոգում.
- «.
- «.
- «.
- «.
- «.
- «.
- «.
- «.
- «.
- «.
Source: www.habr.com