Tupperware. Facebook-ի Kubernetes մարդասպան.

Ցանկացած մասշտաբով կլաստերների արդյունավետ և հուսալի կառավարում Tupperware-ի միջոցով

Այսօր շարունակվում է Systems @Scale կոնֆերանս մենք ներկայացրեցինք Tupperware-ը՝ մեր կլաստերի կառավարման համակարգը, որը կազմակերպում է կոնտեյներներ միլիոնավոր սերվերներում, որոնք աշխատում են մեր գրեթե բոլոր ծառայությունները: Մենք առաջին անգամ տեղակայեցինք Tupperware-ը 2011 թվականին, և այդ ժամանակից ի վեր մեր ենթակառուցվածքն աճել է 1 տվյալների կենտրոն մինչև ամբողջ 15 աշխարհաբաշխված տվյալների կենտրոններ. Այս ամբողջ ընթացքում Tupperware-ը տեղում չի կանգնել և զարգացել է մեզ հետ։ Մենք ձեզ ցույց կտանք, թե ինչպես է Tupperware-ն ապահովում առաջին կարգի կլաստերների կառավարում, ներառյալ հարմարավետ աջակցություն պետական ​​ծառայությունների համար, մեկ կառավարման վահանակ բոլոր տվյալների կենտրոնների համար և իրական ժամանակում ծառայությունների միջև հզորությունը բաշխելու հնարավորությունը: Մենք նաև կկիսվենք այն դասերով, որոնք քաղել ենք մեր ենթակառուցվածքի զարգացման ընթացքում:

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

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

Tupperware ճարտարապետություն

Tupperware PRN ճարտարապետությունը մեր տվյալների կենտրոնների տարածաշրջաններից մեկն է: Տարածաշրջանը բաղկացած է տվյալների կենտրոնի մի քանի շենքերից (PRN1 և PRN2), որոնք գտնվում են մոտակայքում: Մենք նախատեսում ենք ստեղծել մեկ կառավարման վահանակ, որը կկառավարի բոլոր սերվերները մեկ տարածաշրջանում:

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

Tupperware-ը պատասխանատու է բեռնարկղերի մատակարարման և դրանց կյանքի ցիկլը կառավարելու համար: Այն բաղկացած է մի քանի բաղադրիչներից.

• Tupperware frontend-ը տրամադրում է API-ներ օգտատիրոջ միջերեսի, CLI-ի և այլ ավտոմատացման գործիքների համար, որոնց միջոցով դուք կարող եք փոխազդել Tupperware-ի հետ: Նրանք թաքցնում են ամբողջ ներքին կառուցվածքը Tupperware աշխատատեղերի սեփականատերերից:
• Tupperware Scheduler-ը կառավարման վահանակ է, որը պատասխանատու է կոնտեյների և աշխատանքի կյանքի ցիկլը կառավարելու համար: Այն տեղակայված է տարածաշրջանային և գլոբալ մակարդակներում, որտեղ տարածաշրջանային ժամանակացույցը կառավարում է սերվերները մեկ տարածաշրջանում, իսկ գլոբալ ժամանակացույցը կառավարում է տարբեր տարածաշրջանների սերվերները: Ժամանակացույցը բաժանված է բեկորների, և յուրաքանչյուր բեկոր կառավարում է մի շարք աշխատանքներ:
• Tupperware's Scheduler Proxy-ը թաքցնում է ներքին բեկորը և ապահովում է հարմար մեկ ապակի Tupperware-ի օգտագործողների համար:
• Tupperware բաշխիչը կոնտեյներներ է հատկացնում սերվերներին: Ժամանակացույցը կարգավորում է բեռնարկղերի դադարեցումը, գործարկումը, թարմացումը և ձախողումը: Ներկայումս մեկ հատկացնողը կարող է կառավարել ամբողջ տարածաշրջանը՝ առանց բեկորների բաժանվելու: (Նշեք տերմինաբանության տարբերությունը: Օրինակ, Tupperware-ի ժամանակացույցը համապատասխանում է կառավարման վահանակին Կուբերնետես, իսկ Tupperware հատկացուցիչը Kubernetes-ում կոչվում է ժամանակացույց:)
• Ռեսուրսների բրոքերը պահպանում է ճշմարտության աղբյուրը սերվերի և սպասարկման իրադարձությունների համար: Մենք աշխատում ենք մեկ ռեսուրսային բրոքեր յուրաքանչյուր տվյալների կենտրոնի համար, և այն պահպանում է այդ տվյալների կենտրոնի սերվերների մասին ամբողջ տեղեկատվությունը: Ռեսուրսների բրոքերը և կարողությունների կառավարման համակարգը կամ ռեսուրսների տրամադրման համակարգը դինամիկորեն որոշում են, թե որ ժամանակացույցի առաքումը վերահսկում է սերվերը: Առողջության ստուգման ծառայությունը վերահսկում է սերվերները և պահում է նրանց առողջության մասին տվյալները ռեսուրսների բրոքերում: Եթե ​​սերվերը խնդիրներ ունի կամ տեխնիկական սպասարկման կարիք ունի, ռեսուրսների բրոքերն ասում է հատկացնողին և ժամանակացույցին դադարեցնել բեռնարկղերը կամ տեղափոխել դրանք այլ սերվերներ:
• Tupperware Agent-ը յուրաքանչյուր սերվերի վրա աշխատող դեյմոն է, որը զբաղվում է բեռնարկղերի մատակարարմամբ և հեռացմամբ: Հավելվածները աշխատում են կոնտեյների ներսում, ինչը նրանց ավելի շատ մեկուսացում և վերարտադրելիություն է տալիս: Վրա անցյալ տարվա Systems @Scale համաժողովը Մենք արդեն նկարագրել ենք, թե ինչպես են անհատական ​​Tupperware կոնտեյներները ստեղծվում՝ օգտագործելով պատկերներ, btrfs, cgroupv2 և systemd:

Tupperware-ի տարբերակիչ առանձնահատկությունները

Tupperware-ը շատ առումներով նման է կլաստերի կառավարման այլ համակարգերին, ինչպիսիք են Kubernetes-ը և Մեսոս, բայց կան նաև տարբերություններ.

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

Մենք մշակել ենք այս հիանալի հնարավորությունները՝ աջակցելու համար քաղաքացիություն չունեցող և պետական ​​կարգավիճակ չունեցող մի շարք հավելվածների հսկայական գլոբալ համօգտագործվող սերվերների նավատորմում:

Ներկառուցված աջակցություն պետական ​​ծառայությունների համար:

Tupperware-ը գործում է մի շարք կարևոր պետական ​​ծառայություններ, որոնք պահպանում են արտադրանքի մշտական ​​տվյալները Facebook-ի, Instagram-ի, Messenger-ի և WhatsApp-ի համար: Սրանք կարող են լինել բանալի-արժեք զույգերի մեծ պահեստներ (օրինակ. ZippyDB) և տվյալների շտեմարանների մոնիտորինգ (օրինակ, ODS Gorilla и Scuba) Պետական ​​ծառայությունների պահպանումը հեշտ չէ, քանի որ համակարգը պետք է ապահովի, որ բեռնարկղերի մատակարարումը կարող է դիմակայել լայնածավալ խափանումներին, ներառյալ ցանցի կամ էլեկտրաէներգիայի անջատումները: Եվ մինչ սովորական մեթոդները, ինչպիսիք են բեռնարկղերի բաշխումը սխալ տիրույթներում, լավ են աշխատում քաղաքացիություն չունեցող ծառայությունների համար, պետական ​​ծառայությունները լրացուցիչ աջակցության կարիք ունեն:

Օրինակ, եթե սերվերի ձախողումը անհասանելի է դարձնում տվյալների բազայի մեկ կրկնօրինակը, պե՞տք է միացնեք ավտոմատ սպասարկումը, որը կթարմացնի միջուկները 50 սերվերների վրա՝ 10 միավորից: Կախված իրավիճակից։ Եթե ​​այս 50 սերվերներից մեկն ունի նույն տվյալների բազայի մեկ այլ կրկնօրինակ, ապա ավելի լավ է սպասել և չկորցնել միանգամից 2 կրկնօրինակ։ Համակարգի պահպանման և աշխատանքի վերաբերյալ դինամիկ որոշումներ կայացնելու համար մեզ անհրաժեշտ է տեղեկատվություն ներքին տվյալների կրկնօրինակման և յուրաքանչյուր պետական ​​ծառայության տեղաբաշխման տրամաբանության մասին:

TaskControl ինտերֆեյսը թույլ է տալիս պետական ​​ծառայություններին ազդել որոշումների վրա, որոնք ազդում են տվյալների հասանելիության վրա: Օգտագործելով այս ինտերֆեյսը, ժամանակացույցը արտաքին հավելվածներին ծանուցում է կոնտեյների գործառնությունների մասին (վերագործարկում, թարմացում, միգրացիա, սպասարկում): Պետական ​​ծառայությունն իրականացնում է վերահսկիչ, որը տեղեկացնում է Tupperware-ին, երբ անվտանգ է կատարել յուրաքանչյուր գործողություն, և այդ գործողությունները կարող են փոխարինվել կամ ժամանակավորապես հետաձգվել: Վերոնշյալ օրինակում տվյալների բազայի վերահսկիչը կարող է ասել Tupperware-ին թարմացնել 49 սերվերներից 50-ը, բայց առայժմ հանգիստ թողնել կոնկրետ սերվերը (X): Արդյունքում, եթե միջուկի թարմացման ժամանակաշրջանն անցնի, և տվյալների բազան դեռ չկարողանա վերականգնել խնդրահարույց կրկնօրինակը, Tupperware-ը դեռ կթարմացնի X սերվերը։

Շատ պետական ​​ծառայություններ Tupperware-ում օգտագործում են TaskControl-ը ոչ թե ուղղակիորեն, այլ ShardManager-ի միջոցով՝ Facebook-ում պետական ​​ծառայություններ ստեղծելու ընդհանուր հարթակ: Tupperware-ի միջոցով ծրագրավորողները կարող են նշել իրենց մտադրությունը, թե կոնկրետ ինչպես պետք է բեռնարկղերը բաշխվեն տվյալների կենտրոններում: ShardManager-ի միջոցով մշակողները նշում են իրենց մտադրությունը, թե ինչպես պետք է տվյալների բեկորները բաշխվեն բեռնարկղերի միջև: ShardManager-ը տեղյակ է իր հավելվածների տվյալների տեղաբաշխման և կրկնօրինակման մասին և հաղորդակցվում է Tupperware-ի հետ TaskControl ինտերֆեյսի միջոցով՝ բեռնարկղերի գործողությունները պլանավորելու համար՝ առանց հավելվածի անմիջական մասնակցության: Այս ինտեգրումը մեծապես հեշտացնում է պետական ​​ծառայությունների կառավարումը, սակայն TaskControl-ն ունակ է ավելիին: Օրինակ՝ մեր լայնածավալ վեբ մակարդակը քաղաքացիություն չունի և օգտագործում է TaskControl՝ կոնտեյներների թարմացումների արագությունը դինամիկ կերպով հարմարեցնելու համար: Ի վերջո վեբ մակարդակն ի վիճակի է արագորեն լրացնել ծրագրային ապահովման բազմաթիվ թողարկումներ օրական՝ առանց խախտելու հասանելիությունը:

Սերվերների կառավարում տվյալների կենտրոններում

Երբ Tupperware-ն առաջին անգամ գործարկվեց 2011 թվականին, յուրաքանչյուր սերվերի կլաստեր կառավարվում էր առանձին ժամանակացույցով: Այն ժամանակ Facebook-ի կլաստերը սերվերի դարակաշարերի խումբ էր, որը միացված էր մեկ ցանցի փոխարկիչին, և տվյալների կենտրոնում տեղավորված էին մի քանի կլաստերներ: Ժամանակացույցը կարող էր կառավարել սերվերները միայն մեկ կլաստերում, ինչը նշանակում է, որ աշխատանքը չէր կարող տարածվել մի քանի կլաստերների վրա: Մեր ենթակառուցվածքն աճեց, մենք ավելի ու ավելի շատ դուրս գրեցինք կլաստերները: Քանի որ Tupperware-ը չէր կարող աշխատանքը հանված կլաստերից տեղափոխել այլ կլաստերներ առանց փոփոխությունների, այն պահանջում էր մեծ ջանքեր և մանրակրկիտ համակարգում հավելված մշակողների և տվյալների կենտրոնների օպերատորների միջև: Այս գործընթացը հանգեցրեց ռեսուրսների վատնմանը, երբ սերվերները ամիսներ շարունակ անգործության էին մատնված՝ շահագործումից հանելու ընթացակարգերի պատճառով:

Մենք ստեղծել ենք ռեսուրսների բրոքեր՝ կլաստերի ապամոնտաժման խնդիրը լուծելու և սպասարկման այլ տեսակի խնդիրները համակարգելու համար: Ռեսուրսների բրոքերը հետևում է սերվերի հետ կապված բոլոր ֆիզիկական տեղեկատվությանը և դինամիկ կերպով որոշում է, թե որ ժամանակացույցն է վերահսկում յուրաքանչյուր սերվեր: Սերվերների ժամանակացույցներին դինամիկ կապելը թույլ է տալիս ժամանակացույցին կառավարել սերվերները տարբեր տվյալների կենտրոններում: Քանի որ Tupperware-ի աշխատանքն այլևս չի սահմանափակվում մեկ կլաստերով, Tupperware-ի օգտվողները կարող են նշել, թե ինչպես պետք է բեռնարկղերը բաշխվեն անսարքության տիրույթներում: Օրինակ՝ ծրագրավորողը կարող է հայտարարել իր մտադրության մասին (ասենք՝ «գործարկել իմ աշխատանքը PRN տարածաշրջանի 2 անսարք տիրույթներում»)՝ առանց հատուկ հասանելիության գոտիներ նշելու։ Tupperware-ն ինքը կգտնի համապատասխան սերվերներ այս մտադրությունն իրականացնելու համար, նույնիսկ եթե կլաստերը կամ ծառայությունը ապամոնտաժված է:

Սանդղելի՝ ամբողջ գլոբալ համակարգը աջակցելու համար

Պատմականորեն, մեր ենթակառուցվածքը բաժանված է հարյուրավոր հատուկ սերվերների լողավազանների առանձին թիմերի համար: Կտրվածության և ստանդարտների բացակայության պատճառով մենք ունեինք բարձր գործառնական ծախսեր, և չաշխատող սերվերները նորից ավելի դժվար էին օգտագործել: Անցյալ տարվա համաժողովում Համակարգեր @Scale ներկայացրել ենք ենթակառուցվածքը որպես ծառայություն (IaaS), որը պետք է միավորի մեր ենթակառուցվածքը մեծ մեկ սերվերի պարկի մեջ: Բայց մեկ սերվերի պարկը ունի իր դժվարությունները: Այն պետք է համապատասխանի որոշակի պահանջներին.

• Մասշտաբայնություն. Մեր ենթակառուցվածքն աճեց, երբ մենք ավելացրինք տվյալների կենտրոններ յուրաքանչյուր տարածաշրջանում: Սերվերները դարձել են ավելի փոքր և ավելի էներգաարդյունավետ, ուստի դրանք շատ ավելի շատ են յուրաքանչյուր տարածաշրջանում: Արդյունքում, յուրաքանչյուր տարածաշրջանի մեկ ժամանակացույցը չի կարող կարգավորել կոնտեյներների քանակը, որոնք կարող են գործարկվել յուրաքանչյուր տարածաշրջանի հարյուր հազարավոր սերվերների վրա:
• Վստահելիություն: Նույնիսկ եթե ժամանակացույցը կարող է այդքան մեծանալ, ժամանակացույցի մեծ շրջանակը նշանակում է, որ սխալների ավելի մեծ ռիսկ կա, և բեռնարկղերի մի ամբողջ տարածք կարող է դառնալ անկառավարելի:
• Սխալների հանդուրժողականություն. Ենթակառուցվածքի հսկայական խափանումների դեպքում (օրինակ՝ ժամանակացույցը աշխատող սերվերները ձախողվում են ցանցի խափանման կամ էլեկտրաէներգիայի անջատման պատճառով), բացասական հետևանքները պետք է ազդեն տարածաշրջանի սերվերների միայն մի մասի վրա:
• Օգտագործման հեշտությունը. Կարող է թվալ, որ դուք պետք է գործարկեք մի քանի անկախ ժամանակացույց մեկ տարածաշրջանի համար: Սակայն հարմարության տեսանկյունից՝ տարածաշրջանի ընդհանուր լողավազան մուտքի մեկ կետը հեշտացնում է կարողությունների և աշխատատեղերի կառավարումը:

Մենք ժամանակացույցը բաժանեցինք բեկորների՝ մեծ ընդհանուր լողավազանի պահպանման խնդիրները լուծելու համար: Յուրաքանչյուր ժամանակացույցի բեկոր կառավարում է իր աշխատատեղերը տարածաշրջանում, և դա նվազեցնում է ժամանակացույցի հետ կապված ռիսկը: Քանի որ ընդհանուր լողավազանը մեծանում է, մենք կարող ենք ավելացնել ավելի շատ ժամանակացույցի բեկորներ: Tupperware-ի օգտատերերի համար բեկորները և ժամանակացույցի վստահված անձինք նման են մեկ կառավարման վահանակի: Նրանք ստիպված չեն աշխատել բեկորների հետ, որոնք կազմակերպում են առաջադրանքներ: Ժամանակացույցի բեկորները սկզբունքորեն տարբերվում են կլաստերի ժամանակացույցներից, որոնք մենք օգտագործում էինք նախկինում, երբ կառավարման վահանակը բաժանված էր առանց սերվերների ընդհանուր լողավազանի ստատիկ բաժանման՝ ըստ ցանցի տոպոլոգիայի:

Բարելավեք օգտագործման արդյունավետությունը առաձգական հաշվարկով

Որքան մեծ է մեր ենթակառուցվածքը, այնքան ավելի կարևոր է մեր սերվերների արդյունավետ օգտագործումը ենթակառուցվածքի ծախսերը օպտիմալացնելու և բեռը նվազեցնելու համար: Սերվերի օգտագործման արդյունավետությունը բարձրացնելու երկու եղանակ կա.

• Էլաստիկ հաշվողականություն. կրճատեք առցանց ծառայությունները հանգիստ ժամերին և օգտագործեք ազատված սերվերներ անցանց աշխատանքային ծանրաբեռնվածության համար, ինչպիսիք են մեքենայական ուսուցումը և MapReduce աշխատանքները:
• Ծանրաբեռնվածություն - Տեղադրեք առցանց ծառայությունները և խմբաքանակի աշխատանքային բեռները նույն սերվերների վրա, որպեսզի խմբաքանակի ծանրաբեռնվածությունը աշխատի ցածր առաջնահերթությամբ:

Մեր տվյալների կենտրոնների խցանումն է Էներգիայի սպառում. Հետևաբար, մենք նախընտրում ենք փոքր, էներգաարդյունավետ սերվերներ, որոնք միասին ապահովում են ավելի շատ մշակման հզորություն: Ցավոք սրտի, փոքր պրոցեսորներով և հիշողությամբ փոքր սերվերների վրա գերբեռնումն ավելի քիչ արդյունավետ է: Իհարկե, մենք կարող ենք փոքր ծառայությունների մի քանի կոնտեյներ տեղադրել մեկ փոքր էներգաարդյունավետ սերվերի վրա, որոնք սպառում են քիչ պրոցեսորային ռեսուրսներ և հիշողություն, բայց մեծ ծառայություններն այս իրավիճակում կունենան ցածր արդյունավետություն: Հետևաբար, մենք խորհուրդ ենք տալիս մեր խոշոր ծառայությունների մշակողներին օպտիմալացնել դրանք, որպեսզի նրանք օգտագործեն ամբողջ սերվերները:


Հիմնականում մենք բարելավում ենք օգտագործման արդյունավետությունը՝ օգտագործելով առաձգական հաշվարկներ: Մեր հիմնական ծառայություններից շատերը, ինչպիսիք են News Feed-ը, Messaging-ի գործառույթը և առջևի վեբ մակարդակը, տարբերվում են կախված օրվա ժամից: Մենք միտումնավոր նվազեցնում ենք առցանց ծառայությունները հանգիստ ժամերին և օգտագործում ազատված սերվերներ անցանց աշխատանքային ծանրաբեռնվածության համար, ինչպիսիք են մեքենայական ուսուցումը և MapReduce աշխատանքները:

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

Քաղած դասեր և ապագայի պլաններ

Վերջին 8 տարիների ընթացքում մենք մշակում ենք Tupperware-ը Facebook-ի արագ աճին հետևելու համար: Մենք կիսվում ենք մեր սովորածով և հուսով ենք, որ դա կօգնի մյուսներին կառավարել արագ աճող ենթակառուցվածքները.

• Ստեղծեք ճկուն կապ կառավարման վահանակի և այն կառավարվող սերվերների միջև: Այս ճկունությունը թույլ է տալիս կառավարման վահանակին կառավարել սերվերները տարբեր տվյալների կենտրոններում, օգնում է ավտոմատացնել կլաստերների ապամոնտաժումն ու սպասարկումը և հնարավորություն է տալիս դինամիկ հզորությունների բաշխումը՝ օգտագործելով առաձգական հաշվարկներ:
• Տարածաշրջանում մեկ կառավարման վահանակի առկայության դեպքում ավելի հարմար է դառնում առաջադրանքների հետ աշխատելը և ավելի հեշտ է կառավարել մեծ ընդհանուր սերվերների նավատորմը: Նկատի ունեցեք, որ կառավարման վահանակը պահպանում է մուտքի մեկ կետ, նույնիսկ եթե դրա ներքին կառուցվածքը առանձնացված է մասշտաբի կամ սխալների հանդուրժողականության պատճառով:
• Օգտագործելով plugin մոդելը, կառավարման վահանակը կարող է ծանուցել արտաքին հավելվածներին գալիք կոնտեյների գործողությունների մասին: Ավելին, պետական ​​ծառայությունները կարող են օգտագործել plugin ինտերֆեյսը կոնտեյների կառավարումը հարմարեցնելու համար: Այս plugin մոդելի միջոցով կառավարման վահանակն ապահովում է պարզություն՝ միաժամանակ արդյունավետ սպասարկելով բազմաթիվ տարբեր պետական ​​ծառայություններ:
• Մենք հավատում ենք, որ էլաստիկ հաշվարկը, որտեղ մենք ամբողջ սերվերները վերցնում ենք դոնորների ծառայություններից խմբաքանակային աշխատանքների, մեքենայական ուսուցման և այլ ոչ հրատապ ծառայությունների համար, փոքր, էներգաարդյունավետ սերվերների արդյունավետությունը բարելավելու օպտիմալ միջոցն է:

Մենք նոր ենք սկսում իրականացնել միասնական գլոբալ համօգտագործվող սերվերի նավատորմ. Ներկայումս մեր սերվերների մոտ 20%-ը գտնվում է ընդհանուր լողավազանում: 100%-ին հասնելու համար շատ խնդիրներ պետք է լուծվեն, այդ թվում՝ պահպանելով ընդհանուր պահեստային լողավազան, սպասարկման ավտոմատացում, կառավարել խաչաձև վարձակալների պահանջները, բարելավել սերվերի օգտագործումը և բարելավել մեքենայական ուսուցման աշխատանքային ծանրաբեռնվածությունը: Մենք անհամբերությամբ սպասում ենք այս մարտահրավերներին և կիսվելու մեր հաջողություններով:

Source: www.habr.com