Ինչպես է AWS-ն պատրաստում իր առաձգական ծառայությունները: Ցանցի մասշտաբավորում

Amazon Web Services ցանցի մասշտաբը կազմում է 69 գոտի ամբողջ աշխարհում՝ 22 տարածաշրջաններում՝ ԱՄՆ, Եվրոպա, Ասիա, Աֆրիկա և Ավստրալիա։ Յուրաքանչյուր գոտի պարունակում է մինչև 8 տվյալների կենտրոններ՝ Տվյալների մշակման կենտրոններ: Յուրաքանչյուր տվյալների կենտրոն ունի հազարավոր կամ հարյուր հազարավոր սերվերներ: Ցանցը նախագծված է այնպես, որ հաշվի առնվեն անջատման բոլոր անհավանական սցենարները: Օրինակ, բոլոր շրջանները մեկուսացված են միմյանցից, իսկ հասանելիության գոտիները բաժանված են մի քանի կիլոմետր հեռավորությունների վրա։ Նույնիսկ եթե դուք կտրեք մալուխը, համակարգը կանցնի պահուստային ալիքների, և տեղեկատվության կորուստը կկազմի մի քանի տվյալների փաթեթ: Վասիլի Պանտյուխինը կխոսի այն մասին, թե այլ ինչ սկզբունքներով է կառուցված ցանցը և ինչպես է այն կառուցված։

Վասիլի Պանտյուխին սկսել է որպես Unix-ի ադմինիստրատոր .ru ընկերություններում, 6 տարի աշխատել է Sun Microsystem-ի խոշոր սարքավորումների վրա և 11 տարի EMC-ում քարոզել է տվյալների վրա հիմնված աշխարհ: Այն, բնականաբար, վերածվեց մասնավոր ամպերի, այնուհետև տեղափոխվեց հանրային: Այժմ, որպես Amazon Web Services-ի ճարտարապետ, նա տրամադրում է տեխնիկական խորհրդատվություն՝ օգնելու ապրել և զարգանալ AWS ամպում:

AWS եռագրության նախորդ մասում Վասիլին խորացավ ֆիզիկական սերվերների նախագծման և տվյալների բազայի մասշտաբավորման մեջ: Նիտրո քարտեր, հատուկ KVM-ի վրա հիմնված հիպերվիզոր, Amazon Aurora տվյալների բազա՝ այս ամենի մասին նյութում »:Ինչպես է AWS-ն պատրաստում իր առաձգական ծառայությունները: Սերվերների և տվյալների բազայի մասշտաբավորում« Կարդացեք համատեքստի համար կամ դիտեք տեսագրություններ ելույթներ։

Այս մասը կկենտրոնանա ցանցի մասշտաբավորման վրա՝ AWS-ի ամենաբարդ համակարգերից մեկը: Էվոլյուցիան հարթ ցանցից դեպի վիրտուալ մասնավոր ամպ և դրա դիզայնը, Blackfoot-ի և HyperPlane-ի ներքին ծառայությունները, աղմկոտ հարևանի խնդիրը, իսկ վերջում՝ ցանցի մասշտաբները, ողնաշարը և ֆիզիկական մալուխները: Այս ամենի մասին կտրվածքի տակ։

Հրաժարում. ստորև բերված ամեն ինչ Վասիլի անձնական կարծիքն է և կարող է չհամընկնել Amazon Web Services-ի դիրքորոշման հետ:

Ցանցի մասշտաբավորում

AWS ամպը գործարկվել է 2006 թվականին: Նրա ցանցը բավականին պարզունակ էր՝ հարթ կառուցվածքով։ Անձնական հասցեների շրջանակը ընդհանուր էր ամպի բոլոր վարձակալների համար: Նոր վիրտուալ մեքենա գործարկելիս դուք պատահաբար ստացել եք հասանելի IP հասցե այս տիրույթից:

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

Վիրտուալ մասնավոր ամպ

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

Ո՞րն է առաջին բանը, որ գալիս է ձեր մտքին, երբ մտածում եք ցանցի մեկուսացման մասին: Անշուշտ ՎԼԱՆ и VRF - Վիրտուալ երթուղում և վերահասցեավորում.

Ցավոք, չստացվեց: VLAN ID-ն ընդամենը 12 բիթ է, ինչը մեզ տալիս է ընդամենը 4096 մեկուսացված հատված: Նույնիսկ ամենամեծ անջատիչները կարող են օգտագործել առավելագույնը 1-2 հազար VRF: VRF-ի և VLAN-ի համատեղ օգտագործումը մեզ տալիս է ընդամենը մի քանի միլիոն ենթացանց: Սա միանշանակ բավարար չէ տասնյակ միլիոնավոր վարձակալների համար, որոնցից յուրաքանչյուրը պետք է կարողանա օգտագործել բազմաթիվ ենթացանցեր:

Մենք նաև պարզապես չենք կարող մեզ թույլ տալ գնել անհրաժեշտ քանակությամբ մեծ տուփեր, օրինակ՝ Cisco-ից կամ Juniper-ից։ Երկու պատճառ կա. դա խելահեղ թանկ է, և մենք չենք ցանկանում ողորմած լինել նրանց զարգացման ու կարկատելու քաղաքականությանը:

Եզրակացությունը մեկն է՝ ստեղծեք ձեր լուծումը:

2009-ին մենք հայտարարեցինք VPC - Վիրտուալ մասնավոր ամպ. Անունը մնաց, և այժմ շատ ամպային մատակարարներ նույնպես օգտագործում են այն:

VPC-ն վիրտուալ ցանց է SDN (Software Defined Network): Մենք որոշեցինք L2 և L3 մակարդակներում հատուկ արձանագրություններ չհորինել։ Ցանցն աշխատում է ստանդարտ Ethernet-ով և IP-ով: Ցանցով փոխանցման համար վիրտուալ մեքենայի տրաֆիկը պարփակված է մեր սեփական արձանագրության փաթաթում: Այն ցույց է տալիս ID-ն, որը պատկանում է վարձակալի VPC-ին:

Պարզ է հնչում: Այնուամենայնիվ, կան մի քանի լուրջ տեխնիկական մարտահրավերներ, որոնք պետք է հաղթահարվեն: Օրինակ, որտեղ և ինչպես պահել տվյալները վիրտուալ MAC/IP հասցեների, VPC ID-ի և համապատասխան ֆիզիկական MAC/IP-ի քարտեզագրման վերաբերյալ: AWS մասշտաբով սա հսկայական աղյուսակ է, որը պետք է աշխատի նվազագույն մուտքի ուշացումներով: Սրա համար պատասխանատու քարտեզագրման ծառայություն, որը բարակ շերտով փռված է ողջ ցանցով։

Նոր սերնդի մեքենաներում ինկապսուլյացիան կատարվում է Nitro քարտերի միջոցով՝ ապարատային մակարդակում: Ավելի հին դեպքերում, encapsulation-ը և decapsulation-ը հիմնված են ծրագրային ապահովման վրա: 

Եկեք պարզենք, թե ինչպես է այն աշխատում ընդհանուր առմամբ: Սկսենք L2 մակարդակից: Ենթադրենք, որ մենք ունենք IP 10.0.0.2 վիրտուալ մեքենա 192.168.0.3 ֆիզիկական սերվերի վրա: Այն ուղարկում է տվյալներ 10.0.0.3 վիրտուալ մեքենային, որն ապրում է 192.168.1.4-ում: ARP հարցումը ստեղծվում և ուղարկվում է ցանցի Nitro քարտ: Պարզության համար մենք ենթադրում ենք, որ երկու վիրտուալ մեքենաներն էլ ապրում են նույն «կապույտ» VPC-ում:

Քարտեզը փոխարինում է սկզբնաղբյուրի հասցեն իր հասցեով և ARP շրջանակը փոխանցում քարտեզագրման ծառայությանը:

Քարտեզագրման ծառայությունը վերադարձնում է տեղեկատվություն, որն անհրաժեշտ է L2 ֆիզիկական ցանցով փոխանցման համար:

ARP պատասխանում Nitro քարտը փոխարինում է MAC-ին ֆիզիկական ցանցում VPC-ում հասցեով:

Տվյալներ փոխանցելիս մենք տրամաբանական MAC-ն ու IP-ն փաթաթում ենք VPC փաթաթանով: Մենք այս ամենը փոխանցում ենք ֆիզիկական ցանցով՝ օգտագործելով համապատասխան աղբյուրի և նպատակակետ IP Nitro քարտերը:

Ֆիզիկական մեքենան, որի համար նախատեսված է փաթեթը, կատարում է ստուգումը: Սա անհրաժեշտ է հասցեների կեղծման հնարավորությունը կանխելու համար: Մեքենան հատուկ հարցում է ուղարկում քարտեզագրման ծառայությանը և հարցնում. «192.168.0.3 ֆիզիկական մեքենայից ես ստացել եմ մի փաթեթ, որը նախատեսված է 10.0.0.3-ի համար կապույտ VPC-ում: Նա լեգիտի՞մ է: 

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

Հաջորդը, տվյալները ուղարկվում են վիրտուալ մեքենա, որի համար նախատեսված է: 

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

Ստացվում է, որ յուրաքանչյուր փաթեթ փոխանցելիս սերվերները դիմում են քարտեզագրման ծառայությանը։ Ինչպե՞ս վարվել անխուսափելի ուշացումների հետ: Քեշավորում, իհարկե.

Գեղեցկությունն այն է, որ ձեզ հարկավոր չէ ամբողջ հսկայական սեղանը քեշ պահել: Ֆիզիկական սերվերը հյուրընկալում է վիրտուալ մեքենաներ համեմատաբար փոքր թվով VPC-ներից: Դուք միայն պետք է պահեք տեղեկատվությունը այս VPC-ների մասին: Տվյալների փոխանցումը այլ VPC-ներին «կանխադրված» կազմաձևում դեռևս օրինական չէ: Եթե ​​օգտագործվում է այնպիսի գործառույթ, ինչպիսին է VPC-peering-ը, ապա համապատասխան VPC-ների մասին տեղեկատվությունը լրացուցիչ բեռնվում է քեշում: 

Մենք դասավորեցինք տվյալների փոխանցումը VPC-ին:

Blackfoot

Ի՞նչ անել այն դեպքերում, երբ երթևեկությունը պետք է փոխանցվի դրսում, օրինակ՝ ինտերնետ կամ VPN-ի միջոցով գետնին: Օգնում է մեզ այստեղ Blackfoot - ներքին AWS ծառայություն: Այն մշակվել է մեր հարավաֆրիկյան թիմի կողմից: Այդ իսկ պատճառով ծառայությունն անվանվել է Հարավային Աֆրիկայում ապրող պինգվինի անունով։

Blackfoot-ը ապակապսուլացնում է երթևեկությունը և անում է այն, ինչ անհրաժեշտ է դրա հետ: Տվյալներն ուղարկվում են ինտերնետին այնպես, ինչպես կա:

VPN-ն օգտագործելիս տվյալները ապակապսուլացված են և նորից փաթաթվում IPsec-ով:

Direct Connect-ից օգտվելիս երթևեկությունը պիտակվում և ուղարկվում է համապատասխան VLAN-ին:

Հիպերինքնաթիռ

Սա ներքին հոսքի վերահսկման ծառայություն է: Շատ ցանցային ծառայություններ պահանջում են մոնիտորինգ տվյալների հոսքի վիճակները. Օրինակ՝ NAT-ն օգտագործելիս հոսքի վերահսկումը պետք է ապահովի, որ յուրաքանչյուր IP:destination port զույգ ունենա եզակի ելքային նավահանգիստ: Հավասարակշռողի դեպքում NLB - Ցանցի բեռի հավասարակշռող, տվյալների հոսքը միշտ պետք է ուղղված լինի նույն թիրախային վիրտուալ մեքենային: Security Groups-ը պետական ​​firewall է: Այն վերահսկում է մուտքային տրաֆիկը և անուղղակիորեն բացում է նավահանգիստները ելքային փաթեթների հոսքի համար:

AWS ամպում փոխանցման հետաձգման պահանջները չափազանց բարձր են: Ահա թե ինչու Հիպերինքնաթիռ կարևոր է ամբողջ ցանցի աշխատանքի համար:

Hyperplane-ը կառուցված է EC2 վիրտուալ մեքենաների վրա: Այստեղ ոչ մի կախարդանք չկա, այլ միայն խորամանկություն: Խաբեությունն այն է, որ դրանք մեծ օպերատիվ հիշողությամբ վիրտուալ մեքենաներ են: Գործողությունները գործարքային են և կատարվում են բացառապես հիշողության մեջ: Սա թույլ է տալիս հասնել ընդամենը տասնյակ միկրովայրկյանների ուշացումների: Սկավառակի հետ աշխատելը կսպաներ ամբողջ արտադրողականությունը: 

Hyperplane-ը նման EC2 մեքենաների հսկայական քանակի բաշխված համակարգ է: Յուրաքանչյուր վիրտուալ մեքենա ունի 5 ԳԲ/վ թողունակություն: Ամբողջ տարածաշրջանային ցանցում սա ապահովում է թողունակության անհավանական տերաբիթներ և թույլ է տալիս մշակել միլիոնավոր կապեր վայրկյանում.

HyperPlane-ն աշխատում է միայն հոսքերի հետ: VPC փաթեթների ինկապսուլյացիան դրա համար լիովին թափանցիկ է: Այս ներքին ծառայության հնարավոր խոցելիությունը դեռ կկանխի VPC-ի մեկուսացման խախտումը: Ստորև բերված մակարդակները պատասխանատու են անվտանգության համար:

Աղմկոտ հարեւան

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

Բայց մենք մեր ճարտարապետությունը կառուցում ենք նույնիսկ անհավանական սցենարների հիման վրա: 

Ցածր հավանականությունը չի նշանակում անհնարին:

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

Ինչպե՞ս լուծել աղմկոտ հարևանի խնդիրը: Առաջին բանը, որ գալիս է մտքին, դա բեկորն է: Մեր 8 հանգույցները տրամաբանորեն բաժանված են 4-ական հանգույցների 2 բեկորների: Այժմ աղմկոտ հարևանը կխանգարի բոլոր օգտագործողների միայն մեկ քառորդին, բայց դա նրանց մեծապես կխանգարի:

Եկեք ամեն ինչ այլ կերպ անենք: Յուրաքանչյուր օգտագործողին մենք կհատկացնենք ընդամենը 3 հանգույց։ 

Խնդիրն այն է, որ պատահականորեն հանգույցներ հատկացվեն տարբեր օգտվողներին: Ստորև նկարում կապույտ օգտատերը հատում է հանգույցները մյուս երկու օգտագործողներից մեկի հետ՝ կանաչ և նարնջագույն:

8 հանգույցների և 3 օգտագործողների դեպքում աղմկոտ հարևանի կողմից օգտագործողներից մեկի հետ հատվելու հավանականությունը 54% է: Հենց այս հավանականությամբ կապույտ օգտատերը կազդի այլ վարձակալների վրա: Ընդ որում, իր ծանրաբեռնվածության միայն մի մասը։ Մեր օրինակում այս ազդեցությունը գոնե ինչ-որ կերպ նկատելի կլինի ոչ բոլորի, այլ բոլոր օգտագործողների միայն մեկ երրորդի համար: Սա արդեն լավ արդյունք է։

Օգտագործողների թիվը, ովքեր կհատվեն

Հավանականությունը տոկոսներով

0

18%

1

54%

2

26%

3

2%

Իրավիճակը մոտեցնենք իրականությանը` վերցնենք 100 հանգույց և 5 օգտատեր 5 հանգույցի վրա: Այս դեպքում հանգույցներից ոչ մեկը չի հատվի 77% հավանականությամբ: 

Օգտագործողների թիվը, ովքեր կհատվեն

Հավանականությունը տոկոսներով

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

Իրական իրավիճակում, հսկայական թվով HyperPlane հանգույցների և օգտագործողների դեպքում, աղմկոտ հարևանի հնարավոր ազդեցությունը այլ օգտվողների վրա նվազագույն է: Այս մեթոդը կոչվում է mixing shading - shuffle shading. Այն նվազագույնի է հասցնում հանգույցի ձախողման բացասական ազդեցությունը:

Շատ ծառայություններ կառուցված են HyperPlane-ի հիման վրա՝ Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway:

Ցանցի սանդղակ

Հիմա խոսենք բուն ցանցի մասշտաբի մասին։ 2019 թվականի հոկտեմբերի համար AWS-ն առաջարկում է իր ծառայությունները 22 մարզ, և նախատեսվում է ևս 9-ը։

• Յուրաքանչյուր տարածաշրջան պարունակում է մի քանի մատչելիության գոտիներ: Ամբողջ աշխարհում դրանք 69-ն են:
• Յուրաքանչյուր AZ բաղկացած է տվյալների մշակման կենտրոններից: Ընդհանուր առմամբ դրանք 8-ից ավելի չեն։
• Տվյալների կենտրոնում տեղակայված են հսկայական քանակությամբ սերվերներ, որոնցից ոմանք մինչև 300:

Հիմա եկեք այս ամենը միջինացնենք, բազմապատկենք և ստանանք տպավորիչ ցուցանիշ, որն արտացոլում է Ամազոնի ամպի սանդղակ.

Հասանելիության գոտիների և տվյալների կենտրոնի միջև կան բազմաթիվ օպտիկական կապեր: Մեր ամենամեծ մարզերից մեկում 388 ալիք է անցկացվել միայն միմյանց և այլ տարածաշրջանների հետ կապի կենտրոնների (Տրանզիտ կենտրոնների) միջև կապի համար: Ընդհանուր առմամբ սա խելագարություն է տալիս 5000 Tbit.

Backbone AWS-ը կառուցված է հատուկ և օպտիմիզացված ամպի համար: Մենք այն կառուցում ենք ալիքների վրա 100 ԳԲ / վ. Մենք ամբողջությամբ վերահսկում ենք դրանք, բացառությամբ Չինաստանի շրջանների։ Երթևեկությունը չի կիսվում այլ ընկերությունների բեռների հետ:

Իհարկե, մենք միակ ամպային մատակարարը չենք, որն ունի մասնավոր հիմնական ցանց: Ավելի ու ավելի շատ խոշոր ընկերություններ են գնում այս ճանապարհով: Սա հաստատում են անկախ հետազոտողները, օրինակ Հեռաաշխարհագրություն.

Գրաֆիկը ցույց է տալիս, որ բովանդակության մատակարարների և ամպային մատակարարների մասնաբաժինը աճում է: Այդ իսկ պատճառով հիմնական պրովայդերների ինտերնետ տրաֆիկի տեսակարար կշիռը անընդհատ նվազում է։

Ես կբացատրեմ, թե ինչու է դա տեղի ունենում: Նախկինում վեբ ծառայությունների մեծ մասը հասանելի և սպառվում էր անմիջապես ինտերնետից: Մեր օրերում ավելի ու ավելի շատ սերվերներ են տեղակայված ամպի մեջ և հասանելի են միջոցով CDN - Բովանդակության բաշխման ցանց. Ռեսուրս մուտք գործելու համար օգտվողը ինտերնետի միջոցով անցնում է միայն մոտակա CDN PoP-ին. Ներկայության կետ. Ամենից հաճախ այն գտնվում է մոտակայքում: Այնուհետև այն թողնում է հանրային ինտերնետը և թռչում մասնավոր ողնաշարի միջով, օրինակ, Ատլանտյան օվկիանոսով և անմիջապես հասնում է ռեսուրսին:

Հետաքրքիր է, ինչպե՞ս կփոխվի ինտերնետը 10 տարի հետո, եթե այս միտումը շարունակվի:

Ֆիզիկական ալիքներ

Գիտնականները դեռ չեն պարզել, թե ինչպես կարելի է մեծացնել լույսի արագությունը Տիեզերքում, սակայն նրանք մեծ առաջընթաց են գրանցել այն օպտիկական մանրաթելի միջոցով փոխանցելու մեթոդներում: Ներկայումս մենք օգտագործում ենք 6912 մանրաթելային մալուխներ: Սա օգնում է զգալիորեն օպտիմալացնել դրանց տեղադրման արժեքը:

Որոշ շրջաններում մենք ստիպված ենք օգտագործել հատուկ մալուխներ։ Օրինակ՝ Սիդնեյի տարածաշրջանում տերմիտների դեմ հատուկ ծածկույթով մալուխներ ենք օգտագործում։ 

Ոչ ոք անձեռնմխելի չէ անախորժություններից, և երբեմն մեր ալիքները վնասվում են: Աջ կողմի լուսանկարում երևում են օպտիկական մալուխներ ամերիկյան շրջաններից մեկում, որոնք պատռվել են շինարարների կողմից։ Վթարի արդյունքում կորել է ընդամենը 13 տվյալների փաթեթ, ինչը զարմանալի է։ Եվս մեկ անգամ՝ ընդամենը 13: Համակարգը բառացիորեն ակնթարթորեն անցավ պահուստային ալիքների. սանդղակն աշխատում է:

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

Սա Վասիլի Պանտյուխինի եռերգության վերջին մասն է AWS սարքի մասին: IN առաջինը մասերը նկարագրում են սերվերի օպտիմիզացումը և տվյալների բազայի մասշտաբը, և երկրորդ — առանց սերվերի գործառույթներ և Firecracker:

On Բարձր բեռնում ++ նոյեմբերին Վասիլի Պանտյուխինը կկիսվի Amazon սարքի նոր մանրամասներով։ Նա կասի խափանումների պատճառների և Amazon-ում բաշխված համակարգերի նախագծման մասին: Հոկտեմբերի 24-ը դեռ հնարավոր է գիրք տոմս լավ գնով, իսկ ավելի ուշ վճարեք: Մենք սպասում ենք ձեզ HighLoad++-ում, եկեք զրուցենք։

Source: www.habr.com