Թինդերի տեղափոխումը «Կուբեռնետես»

Գրել է ՝ Chris O'Brien, Engineering Manager | Chris Thomas, Engineering Manager | Jinyong Lee, ավագ ծրագրակազմի ինժեներ | Խմբագրեց ՝ Կուպեր acksեքսոն, Ծրագրային ապահովման ինժեներ

Ինչու

Գրեթե երկու տարի առաջ Tinder- ը որոշեց իր պլատֆորմը տեղափոխել Kubernetes: «Կուբեռնետեսը» մեզ հնարավորություն տվեց Tinder Engineering- ին ուղղորդել կոնտեյներազերծում և ցածր հպման գործողություն `անփոխարինելի տեղակայման միջոցով: Դիմումի կառուցումը, տեղակայումը և ենթակառուցվածքը սահմանվելու են որպես ծածկագիր:

Մենք նաև փորձում էինք անդրադառնալ մասշտաբի և կայունության մարտահրավերներին: Երբ մասշտաբը դարձավ կրիտիկական, մենք հաճախ էինք տառապում մի քանի րոպեի ընթացքում `սպասելով նոր EC2 դեպքերի առցանց: Մեզ համար գրավիչ էր տարաների մտադրությունը, որոնք նախատեսված էին երթևեկությունը պլանավորելու և սպասարկելու վայրկյանների ընթացքում վայրկյանների ընթացքում:

Դա հեշտ չէր: 2019-ի սկզբին մեր գաղթի ընթացքում մենք հասանք կրիտիկական զանգված մեր Kubernetes կլաստերի ներսում և սկսեցինք հանդիպել տարբեր մարտահրավերների `երթևեկի ծավալի, կլաստերի չափի և DNS- ի պատճառով: Մենք լուծեցինք հետաքրքիր մարտահրավերներ `200 ծառայություն տեղափոխելու և« Կուբեռնեց »կլաստեր գործարկելիս, ընդհանուր ծավալով` 1000 հանգույց, 15,000 պատիճ և 48,000 հոսող տարան:

Ինչպես

2018-ի հունվարից սկսած մենք մեր ճանապարհը գործեցինք միգրացիոն ջանքերի տարբեր փուլերով: Մենք սկսեցինք կոնտեյնացնել մեր բոլոր ծառայությունները և դրանք տեղակայել մի շարք Կուբեռնետների հյուրընկալված բեմական միջավայրեր: Հոկտեմբերից սկսած ՝ մենք սկսեցինք մեթոդականորեն տեղափոխել մեր բոլոր ժառանգական ծառայությունները դեպի «Կուբեռնետ»: Հաջորդ տարվա մարտին մենք վերջացրեցինք մեր գաղթը և Tinder պլատֆորմն այժմ գործում է բացառապես Կուբեռնետեսի վրա:

Պատկերների կառուցում Կուբեռնետեսի համար

Կուբեռնետների կլաստերում աշխատող միկրոկառավարման համար կան ավելի քան 30 աղբյուր կոդերի պահոցներ: Այս պահոցներում ծածկագիրը գրված է տարբեր լեզուներով (օրինակ ՝ Node.js, Java, Scala, Go) ՝ միևնույն լեզվով բազմակի գործարկման միջավայրերով:

Կառուցման համակարգը նախագծված է գործելու համար յուրաքանչյուր միկրովարկիչի համար լիովին հարմարեցված «կառուցապատման ենթատեքստի» վրա, որը սովորաբար բաղկացած է Dockerfile- ից և Shell հրահանգների շարքից: Չնայած դրանց բովանդակությունը լիովին կարգավորելի է, այս կառուցապատման բոլոր համատեքստերը գրված են ստանդարտացված ձևաչափի համաձայն: Կառուցվածքների համատեքստի ստանդարտացումը թույլ է տալիս կառուցել մի միասնական համակարգ `աշխատելու բոլոր միկրովարկեր:

Գծապատկեր 1–1. Ստանդարտացված կառուցապատման գործընթաց Շենքերի կոնտեյներով

Որպեսզի վազքի շրջակա միջավայրերի միջև առավելագույն հետևողականություն ապահովվի, մշակման և փորձարկման փուլում օգտագործվում է նույն կառուցման գործընթացը: Սա յուրահատուկ մարտահրավեր էր ենթադրում այն ​​ժամանակ, երբ մենք պետք է միջոց ստեղծեինք ՝ ապահովելու համար կայուն հարթակ ամբողջ հարթակում: Արդյունքում, շինարարության բոլոր գործընթացներն իրականացվում են հատուկ «Builder» բեռնարկղի ներսում:

Builder բեռնարկղի իրականացումը պահանջում էր մի շարք առաջադեմ Docker տեխնիկա: Այս Builder բեռնարկղը ժառանգում է տեղական օգտվողի նույնականացումը և գաղտնիքները (օրինակ ՝ SSH ստեղնը, AWS հավատարմագրերը և այլն), ինչպես պահանջվում է մուտք գործել Tinder մասնավոր պահոցներ: Այն տեղադրում է տեղական գրացուցակները, որոնք պարունակում են աղբյուրի կոդ, որպեսզի կառուցվեն արտեֆակտները պահելու բնական միջոց: Այս մոտեցումը բարելավում է կատարումը, քանի որ այն վերացնում է Builder բեռնարկղի և հյուրընկալող մեքենայի միջև կառուցված արտեֆակտերը պատճենելը: Պահված շինանյութերը պահեստավորվում են հաջորդ անգամ ՝ առանց լրացուցիչ կազմաձևման:

Որոշ ծառայությունների համար մենք պետք է ստեղծենք մեկ այլ կոնտեյներ Շենքի ներսում, որպեսզի համատեղի ժամանակային միջավայրը գործադրվող միջավայրի հետ (օր. ՝ Node.js bcrypt գրադարանը տեղադրելը ստեղծում է պլատֆորմի հատուկ երկուական արտեֆակտներ): Կազմի ժամանակի պահանջները կարող են տարբեր լինել ծառայություններից, իսկ վերջին Dockerfile- ը կազմված է թռիչքի ժամանակ:

Կուբեռնետեսի կլաստերի ճարտարապետությունը և միգրացիան

Կլաստերի չափսերը

Մենք որոշեցինք օգտագործել kube-aws- ը `Amazon EC2- ի օրինակներով ավտոմատացված կլաստերի տրամադրման համար: Սկզբից մենք ամեն ինչ վազում էինք մեկ ընդհանուր հանգույցի լողավազանում: Մենք արագորեն պարզեցինք աշխատանքային ծանրաբեռնվածությունը տարբեր չափերի և տեսակների տարանջատելու անհրաժեշտությունը, ռեսուրսներն ավելի լավ օգտագործելու համար: Պատճառաբանությունն այն էր, որ ավելի քիչ ծայրահեղ թելերով պատիճներ վարելը միասին մեզ համար բերեցին ավելի կանխատեսելի կատարողականի արդյունքներ, քան թույլ տվեցին նրանց գոյակցել ավելի մեծ թվով մեկ թելերով պատիճներով:

Մենք հաստատեցինք.

  • m5.4x մեծացնել մոնիտորինգի համար (Պրոմեթևս)
  • c5.4x խոշորացնել Node.js- ի ծանրաբեռնվածության համար (միանվագ ծանրաբեռնվածություն)
  • c5.2xlarge Java- ի և Go- ի համար (բազմաշերտ աշխատանքային ծանրաբեռնվածություն)
  • c5.4x խոշորացնել կառավարման ինքնաթիռի համար (3 հանգույց)

Արտագաղթ

Մեր ժառանգության ենթակառուցվածքից Կուբեռնետներ տեղափոխվելու համար նախապատրաստման քայլերից մեկը եղած ծառայություն-ծառայություն հաղորդակցությունը փոխելն էր `մատնանշելով նոր Elastic Load Balancers (ELBs), որոնք ստեղծվել են Virtual Private Cloud (VPC) հատուկ ենթահամակարգում: Այս ենթահողն ընկած էր Kubernetes VPC- ին: Սա մեզ թույլ տվեց հատիկորեն արտագաղթել մոդուլներ `հաշվի առնելով ծառայության կախվածության հատուկ պատվերը:

Այս վերջնակետերը ստեղծվել են կշռված DNS գրառումների հավաքածուների միջոցով, որոնք ունեն CNAME, որոնք ցույց են տալիս յուրաքանչյուր նոր ELB: Կտրելու համար մենք ավելացրեցինք նոր ռեկորդ ՝ մատնանշելով նոր Kubernetes ծառայությունը ELB ՝ 0. քաշով: Մենք այն ժամանակ դրեցինք ռեկորդի ժամանակը ՝ ապրելու համար: 0. Հին և նոր կշիռները դանդաղորեն ճշգրտվում էին ի վերջո 100% -ով ավարտվի նոր սերվերի վրա: Վերջնաժամկետի ավարտից հետո TTL- ն դրվեց ավելի խելամիտ բանի:

Մեր Java մոդուլները բարձր գնահատեցին ցածր DNS TTL- ը, բայց մեր հանգույցի ծրագրերը չհաշվեցին: Մեր ինժեներներից մեկը վերաշարադրում է կապի լողավազանային ծածկագրի մի մասը ՝ այն ղեկավարելու համար, որը թարմացնում է լողավազանները յուրաքանչյուր 60-ականներին: Սա շատ լավ աշխատեց մեզ համար, առանց նշանակալի կատարողականի հիթի:

Ուսուցում

Անցի գործվածքների սահմանները

2019 թվականի հունվարի 8-ի վաղ առավոտյան ժամերին Թինդերի պլատֆորմը համառորեն դադարեցրեց: Ի պատասխան վաղ առավոտյան պլատֆորմի լատենտայնության հետ կապ չունեցող բարձրացմանը, պատիճի և հանգույցների հաշվարկները կլաստարկվեցին կլաստերի վրա: Սա հանգեցրեց ARP- ի քեշի սպառմանը մեր բոլոր հանգույցների վրա:

ARP- ի պահոցին առնչվող երեք Linux արժեք կա.

Վարկ

gc_thresh3- ը կոշտ գլխարկ է: Եթե ​​դուք ստանում եք «հարևան սեղանի լցոնում» մատյանների մուտքեր, ապա դա ցույց է տալիս, որ նույնիսկ ARP- ի պահոցների համաժամանակյա աղբի հավաքումից հետո, հարևանի մուտքը պահելու համար բավարար տեղ չկար: Այս դեպքում միջուկը պարզապես փաթեթավորում է ամբողջովին:

Մենք օգտագործում ենք Flannel- ը որպես մեր ցանցային գործվածք Kubernetes- ում: Փաթեթները փոխանցվում են VXLAN- ի միջոցով: VXLAN- ը Layer 2 ծածկույթի սխեմա է Layer 3 ցանցի միջոցով: Այն օգտագործում է MAC հասցեներ օգտագործողի տվյալների շտեմարանային պրոտոկոլում (MAC-in-UDP) ծածկագրում, որպեսզի ապահովի Layer 2 ցանցային հատվածների ընդլայնման միջոց: Ֆիզիկական տվյալների կենտրոնի ցանցի փոխադրման արձանագրությունը IP plus UDP է:

Նկար 2–1 ֆլանելային դիագրամ (վարկ)

Գծապատկեր 2–2 VXLAN փաթեթ (վարկ)

Kubernetes- ի յուրաքանչյուր աշխատանքային հանգույց իր ավելի մեծ / 9 բլոկից առանձնացնում է իր վիրտուալ հասցեների տարածքը / 24-ը: Յուրաքանչյուր հանգույցի համար սա հանգեցնում է 1 երթուղու աղյուսակի մուտքի, 1 ARP աղյուսակի մուտքի (flannel.1 ինտերֆեյսի վրա) և 1 փոխանցման տվյալների բազայի (FDB) մուտքի: Դրանք ավելացվում են, երբ աշխատող հանգույցն առաջին անգամ գործարկվում է կամ յուրաքանչյուր նոր հանգույց հայտնաբերվելիս:

Բացի այդ, հանգույցից դեպի պատիճ (կամ պատիճից դեպի պատիճ) հաղորդակցությունն, ի վերջո, հոսում է eth0 ինտերֆեյսի վրա (պատկերված է վերը նշված Flannel դիագրամում): Դա կհանգեցնի լրացուցիչ մուտքի ARP աղյուսակում յուրաքանչյուր համապատասխան հանգույցի աղբյուրի և հանգույցի նպատակակետին:

Մեր միջավայրում հաղորդակցման այս տեսակը շատ տարածված է: Մեր Kubernetes ծառայության օբյեկտների համար ստեղծվում է ELB, և Kubernetes- ը գրանցում է ELB- ի յուրաքանչյուր հանգույց: ELB- ը տեղյակ չէ, և ընտրված հանգույցը չի կարող լինել փաթեթի վերջնական նպատակակետը: Դա այն է, որ երբ հանգույցը ստանում է փաթեթը ELB- ից, այն գնահատում է ծառայության համար իր iptables կանոնները և պատահականորեն ընտրում է պատիճ այլ հանգույցի վրա:

Դադարման պահին կլաստերում առկա էր 605 ընդհանուր հանգույց: Վերոնշյալ պատճառներով սա բավարար էր լռելյայն gc_thresh3 արժեքը խավարելու համար: Երբ դա տեղի ունենա, ոչ միայն փաթեթները չեն գցվում, այլ ARP աղյուսակից բացակայում են վիրտուալ հասցեների ամբողջ Flannel / 24-երը: Հոդի պատիճ կապի և DNS որոնումները ձախողվում են: (DNS- ը հյուրընկալվում է կլաստերի ներսում, ինչպես ավելի մանրամասն կներկայացվի այս հոդվածում ավելի ուշ):

Լուծելու համար բարձրացվում են gc_thresh1- ի, gc_thresh2- ի և gc_thresh3- ի արժեքները, և Flannel- ը պետք է նորից վերագործարկվի ՝ բացակայող ցանցերը վերագրանցելու համար:

Անսպասելիորեն վազում է DNS- ն մասշտաբով

Մեր միգրացիան տեղավորելու համար մենք մեծ օգուտ ենք տվել DNS- ին `մեր ծառայությունների համար խթանելու երթևեկության ձևավորումը և ժառանգությունից դեպի Կուբեռնետես` հավելյալ կտրումը: Մենք տեղադրեցինք համեմատաբար ցածր TTL արժեքները կապված Route53 RecordSets- ի վրա: Երբ մենք մեր ժառանգության ենթակառուցվածքը գործեցինք EC2- ի օրինակներով, մեր վճռական կազմաձևով նշվեց Amazon- ի DNS- ն: Մենք դա ընդունեցինք որպես ընդունված և մեր ծառայությունների և Amazon- ի ծառայությունների համար (համեմատաբար DynamoDB) համեմատաբար ցածր TTL- ի արժեքը հիմնականում աննկատ մնաց:

Երբ մենք ավելի ու ավելի շատ ծառայություններ էինք սպասարկում «Կուբեռնետես» -ին, մենք հայտնվեցինք, որ գործում ենք DNS ծառայություն, որը պատասխանում էր 250,000 խնդրի վայրկյանին: Մենք մեր դիմումներում հանդիպում էինք ընդհատվող և ազդեցիկ DNS որոնման ժամանակաշրջանների: Դա տեղի է ունեցել չնայած սպառիչ թյունինգի ջանքերին և DNS մատակարարին անցել է CoreDNS տեղակայման, որը մի ժամանակ հասնում էր 1000 պատիճի վրա, որոնք սպառում էին 120 միջուկ:

Ուսումնասիրելով այլ հնարավոր պատճառներն ու լուծումները ՝ մենք գտանք հոդված, որը նկարագրում էր մրցավազքի պայմանը, որն ազդում էր Linux փաթեթի ֆիլտրման ցանցի զտիչի վրա: Մենք տեսնում էինք DNS ժամացույցները, ինչպես նաև Flannel ինտերֆեյսի հավելյալ insert_failed հաշվիչը, որը համահունչ էր հոդվածի բացահայտումներին:

Խնդիրը տեղի է ունենում Աղբյուրի և նպատակակետի ցանցի հասցեների թարգմանության (SNAT և DNAT) ընթացքում և դրան հաջորդող ժամանակ `ներմուծվող բեռնաթափման աղյուսակում: Ներքին ներսում քննարկված և համայնքի կողմից առաջարկված մի ելք այն էր, որ DNS- ն ինքնին տեղափոխի աշխատանքային հանգույցը: Այս դեպքում:

  • SNAT- ը անհրաժեշտ չէ, քանի որ երթևեկությունը տեղում է մնում հանգույցի վրա: Անհրաժեշտ չէ այն փոխանցել eth0 միջերեսի միջոցով:
  • DNAT- ը անհրաժեշտ չէ, քանի որ նպատակակետ IP- ն տեղական է հանգույցի համար և ոչ թե պատահականորեն ընտրված պատիճը iptables- ի կանոնների համաձայն:

Մենք որոշեցինք առաջ շարժվել այս մոտեցմամբ: CoreDNS- ը տեղադրվեց որպես DaemonSet- ը Kubernetes- ում, և մենք ներարկեցինք հանգույցի տեղական DNS սերվերը յուրաքանչյուր պատիճ լուծման.conf- ում `կազմաձևելով kubelet - cluster-dns հրամանի դրոշը: Ուղղաթիռը արդյունավետ էր DNS timeout- ի համար:

Այնուամենայնիվ, մենք դեռ տեսնում ենք ընկած փաթեթները և Flannel ինտերֆեյսի insert_failed հաշվիչի հավելումը: Սա կշարունակվի նույնիսկ վերը նշված լուծումից հետո, քանի որ մենք միայն խուսափեցինք SNAT- ից և / կամ DNAT- ից DNS երթևեկության համար: Մրցավազքի պայմանը դեռ տեղի կունենա երթևեկության այլ տեսակների համար: Բարեբախտաբար, մեր փաթեթների մեծ մասը TCP է, և երբ պայմանը տեղի է ունենում, փաթեթները հաջողությամբ կփոխանցվեն: Բոլոր տեսակի երթևեկության համար երկարաժամկետ շտկումը մի բան է, որը մենք դեռ քննարկում ենք:

Օգտագործելով դեսպանորդ ՝ բեռի ավելի լավ հավասարակշռության հասնելու համար

Երբ մենք տեղափոխեցինք մեր կադրային ծառայությունները «Կուբեռնետես», մենք սկսեցինք տառապել պատիճներով անհավասարակշիռ բեռից: Մենք հայտնաբերեցինք, որ HTTP Keepalive- ի շնորհիվ, ELB կապերը խրված են յուրաքանչյուր շարժակազմի տեղակայման առաջին պատրաստ պատիճներին, ուստի երթևեկության մեծ մասը հոսում էր առկա պատիճների մի փոքր տոկոսով: Մեր փորձած առաջին մեղմացումներից մեկն այն էր, որ օգտագործենք 100% MaxSurge- ը նոր տեղակայման համար ամենավատ հանցագործների համար: Ավելի մեծ տեղակայված որոշ մասերով սա մարգինալ արդյունավետ և ոչ կայուն երկարաժամկետ հեռանկարում էր:

Մեկ այլ մեղմացում, որը մենք օգտագործում էինք ՝ արհեստականորեն բորբոքել ռեսուրսների պահանջները կրիտիկական ծառայություններից, որպեսզի գունավոր պատիճները այլ ծանր պատիճների կողքին ունենան ավելի շատ ականջակալներ: Սա նաև երկարաժամկետ հեռանկարում չէր կարող լինել ուժի մեջ մնալ ռեսուրսների թափոնների պատճառով, և մեր հանգույցի դիմումները մեկ թելերով էին, ուստի արդյունավետորեն փակվեցին 1 հիմքում: Միակ պարզ լուծումը բեռի ավելի լավ հավասարակշռությունն օգտագործելն էր:

Ներքին փորձեր էինք անում գնահատել Դեսպանին: Սա մեզ հնարավորություն տվեց տեղակայել այն շատ սահմանափակ ձևով և անմիջապես օգուտ քաղել: Դեսպանը բաց աղբյուր, բարձրորակ Layer 7 վստահված անձ է, որը նախատեսված է մեծ սպասարկման վրա հիմնված ճարտարապետությունների համար: Այն ի վիճակի է իրականացնել բեռի հավասարակշռման առաջադեմ տեխնիկա, ներառյալ ավտոմատ փորձերը, միացման կոտրումը և գլոբալ փոխարժեքի սահմանափակումը:

Կազմաձևը, որը մենք հասանք, այն էր, որ յուրաքանչյուր պատիճի կողքին պետք է ունենանք Դեսպանորդի կողքին, որն ուներ մեկ երթուղի և կլաստեր `խցանելու համար տեղական բեռնարկղային նավահանգիստը: Պոտենցիալ կասկադացումը նվազագույնի հասցնելու և փոքր պայթյունի շառավղը պահելու համար մենք օգտագործեցինք առջևի վստահված անձի Դեսպան պատիճի մի նավատորմի, յուրաքանչյուր ծառայության համար մատչելիության գոտում մեկ տեղակայումը: Դրանք հարվածեցին ծառայության մեր հայտնաբերման փոքր մեխանիզմին, որը մեր ինժեներներից մեկն էր, որը պարզապես վերադարձնում էր յուրաքանչյուր ԱՀ-ում պատիճների ցուցակը տվյալ ծառայության համար:

Ծառայության առջևի բանագնացներն այնուհետև օգտագործում էին ծառայության հայտնաբերման այս մեխանիզմը ՝ մեկ վերևում գտնվող կլաստերով և երթուղով: Մենք կազմաձևեցինք ողջամիտ ժամկետներ, խթանեցինք միացման անջատիչի բոլոր պարամետրերը, այնուհետև տեղադրեցինք նվազագույն փորձարկման կազմաձևեր `օգնելու համար անցումային անհաջողություններին և սահուն տեղակայմանը: Մենք դիմակայեցինք այս առջևի Դեսպանի յուրաքանչյուր ծառայությունից ՝ TCP ELB: Նույնիսկ եթե մեր հիմնական առջևի վստահված անձի պահոցը ամրացված էր ինչ-որ բանագնաց պատիճների վրա, ապա նրանք ավելի լավ կկարողանային կարգավորել բեռը և կազմաձևված էին հավասարակշռելու հետին պլանի առնվազն_ խնդրանքով:

Տեղակայման համար մենք գործածեցինք preStop կարթ ՝ ինչպես դիմումի, այնպես էլ կողային պատուհանի վրա: Այս կարթը, որը կոչվում է շրջիկ առողջության ստուգում, չի հաջողվում ղեկավարության վերջնական կետում, փոքր քնի հետ միասին, որոշակի ժամանակ տրամադրել, որպեսզի լուսավորության միացումներն ավարտվեն և չորանան:

Պատճառներից մեկը, որ մենք կարողացանք այդքան արագ շարժվել, պայմանավորված էր այն հարուստ չափանիշների շնորհիվ, որ կարողացանք հեշտությամբ ինտեգրվել Պրոմեթևսի բնականոն կայացմանը: Սա մեզ թույլ տվեց պարզել, թե ինչ էր կատարվում, երբ մենք կրկնեցինք կազմաձևման պարամետրերը և կտրեցինք երթևեկությունը:

Արդյունքները անհապաղ և ակնհայտ էին: Մենք սկսեցինք առավել անհավասարակշիռ ծառայություններն ու այս պահին այն գործում է մեր կլաստերի ամենակարևոր ծառայությունների տասներկուսի առջև: Այս տարի մենք նախատեսում ենք տեղափոխվել լիարժեք սպասարկման ցանց ՝ ավելի առաջադեմ ծառայության հայտնաբերման, միացման կոտրման, հեռավորության հայտնաբերման, փոխարժեքի սահմանափակման և հետագծման:

Գծապատկեր 3–1 պրոցեսորների կոնվերգենցիան մեկ ծառայության ընթացքում դեսպանորդին անցնելու ընթացքում

Վերջնական արդյունքը

Այս սովորությունների և լրացուցիչ հետազոտությունների միջոցով մենք մշակել ենք ներքին ենթակառուցվածքների ուժեղ թիմ `մեծ ծանոթությամբ, թե ինչպես ձևավորել, տեղակայել և շահագործել մեծ Կուբեռնետների կլաստերներ: Տինդերի ամբողջ ինժեներական կազմակերպությունն այժմ ունի գիտելիք և փորձ այն մասին, թե ինչպես կարելի է կոնտեյնավորել և տեղակայել իրենց դիմումները «Կուբեռնետ» -ում:

Մեր ժառանգության ենթակառուցվածքում, երբ պահանջվում էր լրացուցիչ մասշտաբներ, մենք հաճախ էինք տառապում մի քանի րոպեի ընթացքում `սպասելով, որ կկայանան նոր EC2 դեպքեր առցանց: Տարաները այժմ նախատեսված են և սպասարկում են երթևեկությունը վայրկյանների ընթացքում, ի տարբերություն րոպեների: Մի քանի տարաներ EC2- ի մեկ օրինակով պլանավորելը նաև բարելավում է հորիզոնական խտությունը: Արդյունքում, մենք նախագծում ենք էական ծախսերի խնայողություն EC2- ում 2019 թվականին ՝ նախորդ տարվա համեմատ:

Անցավ մոտ երկու տարի, բայց մենք վերջացրեցինք մեր միգրացիան 2019-ի մարտին: Tinder պլատֆորմը գործում է բացառապես Kubernetes կլաստերի վրա, որը բաղկացած է 200 ծառայությունից, 1000 հանգույցից, 15,000 պատիճից և 48,000 հոսող բեռնարկղերից: Ենթակառուցվածքն այլևս մեր գործող թիմերի համար վերապահված խնդիր է: Փոխարենը, ամբողջ կազմակերպության ինժեներները մասնակցում են այդ պատասխանատվությանը և վերահսկում են, թե ինչպես են իրենց դիմումները կառուցվում և տեղակայվում ամեն ինչով ՝ որպես ծածկագիր:

Տես նաեւ

Ինչպե՞ս եք խանգարում ինչ-որ մեկին ձեզ Instagram- ում նշել:Ընկերուհին իր Snapchat- ում մի տղայի է հարվածում: Նա չհեռացավ նրան կամ ասաց, որ իմ խնդրանքով հետ կանչի, որպեսզի ես իմ անձնական հաղորդագրությունը ուղարկեմ Instagram- ում և ասեմ, որ դադարեցնի բոլոր կապերը նրանից: Այժմ նա խելագարվել է և ինձ խենթ է անվանում: Ո՞վ է ճիշտ:Դուք շեշտվա՞ծ եք SnapChat- ի ձեր ժապավեններից: Ինչո՞ւ եք ուզում դրանք շարունակել:Ինչպե՞ս կարող եմ օգտվել Instagram BioLink- ից ՝ գումար վաստակելու համար:Ինչու կարող եմ \ u2019t փակցնում եմ \ u201cswip up up \ u201d Instagram- ի պատմությունները:Ինչ-որ ելք կա `ձայնային հաղորդագրությունները անջատելու համար WhatsApp- ում ինքնաբերաբար ներբեռնելու համար: Եթե ​​այո, ապա ո՞րն է գործընթացը կատարելու համար:Պետք է Instagram- ից հեռացնեմ իմ նախկինին որպես հետևորդ: Ես պարզապես հայտնաբերեցի, որ դա հնարավոր էր: Երկար պատմություն կարճ. Դա ցրտահարություն էր, և մենք դեռևս խոսելու իրավունք չունեինք (գրեթե 3 տարի): Ո՞րն է ավելի շատ վնասելու. Նա թարմացվում է իմ կյանքի վրա կամ կտրվում է:Ինչպե՞ս կարող եմ լռել ինչ-որ մեկին Instagram- ի գրառումները Android- ում: