Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

Daghang mga startup ang nakaagi niini: daghang mga bag-ong tiggamit ang nagparehistro kada adlaw, ug ang development team nanlimbasug sa pagpadayon sa serbisyo.

Nindot kini nga problema, apan adunay gamay nga klaro nga kasayuran sa web kung giunsa pag-ayo ang pagsukod sa usa ka aplikasyon sa web gikan sa wala hangtod sa gatusan ka libo nga mga tiggamit. Kasagaran adunay mga solusyon sa sunog o mga solusyon sa bottleneck (ug kasagaran pareho). Busa, ang mga tawo naggamit ug medyo cliched nga mga teknik aron mapadako ang ilang amateur nga proyekto sa usa ka butang nga seryoso kaayo.

Atong sulayan ang pagsala sa impormasyon ug isulat ang batakang pormula. Atong usbon ang atong bag-ong photo sharing site Graminsta sa lakang gikan sa 1 ngadto sa 100 ka tiggamit.

Atong isulat kung unsa nga mga piho nga aksyon ang kinahanglan buhaton kung ang mamiminaw mosaka sa 10, 100, 1000, 10 ug 000 ka mga tawo.

1 user: 1 makina

Halos matag aplikasyon, bisan kini usa ka website o usa ka mobile application, adunay tulo nga hinungdanon nga sangkap:

  • API
  • database
  • kliyente (mobile application mismo o website)

Ang database nagtipig kanunay nga datos. Ang API nag-alagad sa mga hangyo sa ug sa palibot niini nga datos. Ang kliyente nagpadala sa datos ngadto sa tiggamit.

Nakahukom ko nga mas sayon ​​​​ang paghisgot mahitungod sa pag-scale sa usa ka aplikasyon kung, gikan sa punto sa arkitektura, ang kliyente ug mga entidad sa API hingpit nga nabulag.

Sa una namong pagsugod sa pagtukod sa usa ka aplikasyon, ang tanan nga tulo nga mga sangkap mahimo’g ipadagan sa parehas nga server. Sa pipila ka mga paagi, kini susama sa atong development environment: usa ka engineer ang nagpadagan sa database, API, ug kliyente sa samang makina.

Sa teoriya, mahimo natong i-deploy kini sa cloud sa usa ka DigitalOcean Droplet o AWS EC2 nga pananglitan, sama sa gipakita sa ubos:
Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit
Sa ingon niana, kung adunay labaw pa sa usa ka tiggamit sa usa ka site, hapit kanunay nga makatarunganon ang pagpahinungod sa usa ka layer sa database.

10 ka tiggamit: pagbalhin sa database ngadto sa lain nga lebel

Ang pagbahin sa database ngadto sa gidumala nga mga serbisyo sama sa Amazon RDS o Digital Ocean Managed Database magsilbi kanato og maayo sa taas nga panahon. Mas mahal kini kaysa pag-host sa kaugalingon sa usa ka makina o EC2 nga pananglitan, apan sa kini nga mga serbisyo nakakuha ka daghang mapuslanon nga mga extension gikan sa kahon nga magamit sa umaabot: backup sa multi-rehiyon, pagbasa sa mga replika, awtomatiko backups, ug uban pa.

Mao kini ang hitsura sa sistema karon:
Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

100 ka tiggamit: pagbalhin sa kliyente ngadto sa lain nga lebel

Maayo na lang, ang among unang mga tiggamit ganahan kaayo sa among aplikasyon. Ang trapiko nahimong mas lig-on, mao nga panahon na nga ibalhin ang kliyente sa usa ka lahi nga lebel. Kini kinahanglan nga timan-an nga panagbulag Ang mga entidad usa ka hinungdanon nga aspeto sa paghimo og usa ka scalable nga aplikasyon. Ingon nga ang usa ka bahin sa sistema makadawat og dugang nga trapiko, mahimo natong bahinon kini aron makontrol kung giunsa ang pagtimbang sa serbisyo base sa piho nga mga sumbanan sa trapiko.

Mao kini ang hinungdan nga gusto nako nga hunahunaon ang kliyente nga lahi sa API. Kini nakapasayon ​​kaayo sa paghunahuna mahitungod sa pagpalambo alang sa daghang mga plataporma: web, mobile web, iOS, Android, desktop applications, third-party services, ug uban pa. Silang tanan mga kliyente lang nga naggamit sa samang API.

Pananglitan, karon ang among mga tiggamit kanunay nga naghangyo nga buhian ang usa ka mobile application. Kung gibulag nimo ang kliyente ug mga entidad sa API, kini mahimong labi kadali.

Mao kini ang hitsura sa ingon nga sistema:

Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

1000 ka tiggamit: idugang ang load balancer

Ang mga butang nagtan-aw. Ang mga tiggamit sa Graminsta nag-upload ug daghang mga litrato. Ang gidaghanon sa mga rehistro nagkadaghan usab. Ang among nag-inusarang API server naglisud sa pagpadayon sa tanan nga trapiko. Nagkinahanglan ug dugang nga puthaw!

Ang load balancer kay gamhanan kaayo nga konsepto. Ang yawe nga ideya mao nga magbutang kami ug load balancer sa atubangan sa API, ug kini nag-apod-apod sa trapiko sa indibidwal nga mga higayon sa serbisyo. Ingon niini kung giunsa namon ang pag-scale sa pahalang, nagpasabut nga nagdugang kami daghang mga server nga adunay parehas nga code, nagdugang ang gidaghanon sa mga hangyo nga mahimo namon maproseso.

Magbutang kami og bulag nga mga balanse sa pagkarga sa atubangan sa kliyente sa web ug sa atubangan sa API. Nagpasabot kini nga mahimo nimong ipadagan ang daghang mga higayon nga nagpadagan sa API code ug code sa web client. Ang load balancer modirekta sa mga hangyo ngadto sa server nga dili kaayo load.

Dinhi atong makuha ang laing importante nga bentaha - redundancy. Kung mapakyas ang usa ka higayon (tingali na-overload o na-crash), nahabilin kami sa uban nga nagpadayon sa pagtubag sa umaabot nga mga hangyo. Kung adunay usa ra ka higayon nga nagtrabaho, kung adunay kapakyasan ang tibuuk nga sistema ma-crash.

Ang load balancer naghatag usab ug awtomatikong pag-scale. Mahimo namon nga i-configure kini aron madugangan ang gidaghanon sa mga higayon sa wala pa ang peak load, ug pakunhuran kini kung natulog ang tanan nga tiggamit.

Uban sa usa ka load balancer, ang lebel sa API mahimong ma-scale hapit sa walay katapusan, sa pagdugang sa bag-ong mga higayon samtang ang gidaghanon sa mga hangyo nagdugang.

Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

Nota. Karon ang among sistema parehas kaayo sa kung unsa ang mga kompanya sa PaaS sama sa Heroku o Elastic Beanstalk sa AWS nga gitanyag sa gawas sa kahon (mao nga hinungdan nga sila sikat kaayo). Gibutang ni Heroku ang database sa usa ka bulag nga host, nagdumala sa usa ka balanse sa load sa auto-scaling, ug gitugotan ka nga mag-host sa kliyente sa web nga gilain gikan sa API. Kini usa ka maayong rason nga gamiton ang Heroku alang sa mga proyekto sa sayo nga yugto o pagsugod - makuha nimo ang tanan nga mga batakang serbisyo gikan sa kahon.

10 ka tiggamit: CDN

Tingali ato na unta kining buhaton sukad pa sa sinugdan. Ang pagproseso sa mga hangyo ug pagdawat sa bag-ong mga litrato nagsugod sa pagbutang sa sobra nga gibug-aton sa among mga server.

Sa kini nga yugto, kinahanglan nimo nga mogamit usa ka serbisyo sa panganod alang sa pagtipig sa static nga sulud - mga imahe, video ug daghan pa (AWS S3 o Digital Ocean Spaces). Sa kinatibuk-an, kinahanglan nga likayan sa among API ang pagdumala sa mga butang sama sa pag-alagad sa mga imahe ug pag-upload sa mga imahe sa server.

Ang laing bentaha sa cloud hosting mao ang CDN (AWS nagtawag niini nga add-on Cloudfront, apan daghang mga cloud storage providers ang nagtanyag niini gikan sa kahon). Awtomatiko nga gi-cache sa CDN ang among mga imahe sa lainlaing mga sentro sa datos sa tibuuk kalibutan.

Bisan kung ang among panguna nga sentro sa datos mahimong nahimutang sa Ohio, kung adunay mangayo usa ka imahe gikan sa Japan, ang taghatag sa panganod maghimo usa ka kopya ug itago kini sa ilang sentro sa datos sa Japan. Ang sunod nga tawo nga mohangyo niini nga imahe sa Japan makadawat niini nga mas paspas. Mahinungdanon kini kung nagtrabaho kami sa dagkong mga file, sama sa mga litrato o video, nga dugay nga ma-download ug ipadala sa tibuuk nga planeta.

Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

100 ka tiggamit: scaling sa data layer

Daghan kaayog natabang ang CDN: kusog kaayo ang pag-uswag sa trapiko. Ang sikat nga video blogger nga si Mavid Mobrick nagparehistro lang kanamo ug nag-post sa iyang "istorya", ingon nila. Salamat sa load balancer, ang paggamit sa CPU ug memorya sa mga API server gipabiling ubos (napulo ka mga higayon sa API nga nagdagan), apan nagsugod kami sa pagkuha og daghang mga timeout sa mga hangyo... diin gikan kini nga mga paglangan?

Ang pagkalot og gamay sa mga sukatan, atong makita nga ang CPU sa database server kay 80-90% load. Naa na ta sa limitasyon.

Ang pag-scale sa layer sa datos mao tingali ang pinakalisud nga bahin sa equation. Ang mga server sa API nagsilbi nga walay estado nga mga hangyo, mao nga magdugang lang kami og daghang mga higayon sa API. Ilong ang kadaghanan ang mga database dili makahimo niini. Maghisgot kami bahin sa mga sikat nga relational database management system (PostgreSQL, MySQL, ug uban pa).

pag-cache

Usa sa pinakasayon ​​nga paagi aron madugangan ang performance sa among database mao ang pagpaila sa bag-ong component: ang cache layer. Ang labing komon nga paagi sa pag-cache mao ang in-memory key-value record store, sama sa Redis o Memcached. Kadaghanan sa mga panganod adunay gidumala nga bersyon sa kini nga mga serbisyo: Elasticache sa AWS ug Memorystore sa Google Cloud.

Ang usa ka cache mapuslanon kung ang usa ka serbisyo naghimo sa daghang gibalikbalik nga mga tawag sa database aron makuha ang parehas nga kasayuran. Sa tinuud, maka-access lang kami sa database, gitipigan ang kasayuran sa cache, ug dili na kini hikapa pag-usab.

Pananglitan, sa among serbisyo sa Graminsta, sa matag higayon nga adunay moadto sa profile page sa bituon nga Mobrik, ang API server mangutana sa database alang sa impormasyon gikan sa iyang profile. Kini mahitabo balik-balik. Tungod kay ang impormasyon sa profile ni Mobrik dili mausab sa matag hangyo, kini maayo kaayo alang sa caching.

Atong i-cache ang mga resulta gikan sa database sa Redis pinaagi sa yawe user:id nga may validity period nga 30 segundos. Karon, kung adunay moadto sa profile ni Mobrik, susihon una namon ang Redis, ug kung naa ang data, gibalhin lang namon kini direkta gikan sa Redis. Karon ang mga hangyo sa labing inila nga profile sa site halos wala mag-load sa among database.

Ang laing bentaha sa kadaghanan sa mga serbisyo sa caching mao nga kini mas sayon ​​​​sa pag-scale kay sa mga database server. Ang Redis adunay built-in nga Redis Cluster mode. Sama sa usa ka load balancer1, kini nagtugot kanimo sa pag-apod-apod sa imong Redis cache sa daghang mga makina (sa liboan ka mga server kung gikinahanglan).

Hapit tanan nga dagkong mga aplikasyon naggamit sa caching; kini usa ka hingpit nga bahin sa usa ka paspas nga API. Ang mas paspas nga pagproseso sa pangutana ug mas produktibo nga code kay importante, pero kung walay cache halos imposible ang pag-scale sa usa ka serbisyo ngadto sa milyon-milyong tiggamit.

Basaha ang mga Replika

Kung ang gidaghanon sa mga pangutana sa database midaghan pag-ayo, usa pa ka butang nga mahimo naton mao ang pagdugang mga replika sa pagbasa sa sistema sa pagdumala sa database. Uban sa gidumala nga mga serbisyo nga gihulagway sa ibabaw, mahimo kini sa usa ka pag-klik. Ang gibasa nga replika magpabilin nga bag-o sa panguna nga database ug magamit alang sa PILI nga mga pahayag.

Ania ang among sistema karon:

Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

Dugang nga mga aksyon

Samtang ang aplikasyon nagpadayon sa pag-scale, magpadayon kami sa pagbulag sa mga serbisyo aron sukdon kini nga independente. Pananglitan, kung magsugod kita sa paggamit sa Websockets, nan makatarunganon nga ibira ang code sa pagproseso sa Websockets ngadto sa lain nga serbisyo. Mahimo namo kining ibutang sa bag-ong mga higayon luyo sa among kaugalingong load balancer, nga mahimong motaas ug mopaubos base sa bukas nga mga koneksyon sa Websockets ug bisan unsa pa ang gidaghanon sa mga hangyo sa HTTP.

Magpadayon usab kami sa pagpakig-away sa mga pagdili sa lebel sa database. Niini nga yugto nga panahon na sa pagtuon sa database partitioning ug sharding. Ang duha nga mga pamaagi nanginahanglan dugang nga overhead, apan gitugotan ka sa pag-scale sa database hapit hangtod sa hangtod.

Gusto usab namon nga mag-install usa ka serbisyo sa pag-monitor ug analytics sama sa New Relic o Datadog. Makatabang kini kanimo nga mahibal-an ang hinay nga mga pangutana ug masabtan kung diin kinahanglan ang pag-uswag. Sa among pag-scale, gusto namo nga ipunting ang pagpangita sa mga bottleneck ug pagwagtang niini-kasagaran gamit ang pipila ka mga ideya gikan sa miaging mga seksyon.

Mga tinubdan

Kini nga post giinspirar sa usa sa akong paborito nga mga post bahin sa taas nga scalability. Gusto nakong himoong mas espesipiko ang artikulo alang sa unang mga yugto sa mga proyekto ug hubaron kini gikan sa usa ka vendor. Siguruha nga basahon kung interesado ka niini nga hilisgutan.

Mga Footnote

  1. Bisan kung parehas sa termino sa pag-apod-apod sa load sa daghang mga higayon, ang nagpahiping pagpatuman sa usa ka cluster sa Redis lahi kaayo sa usa ka balanse sa pagkarga. [balik]

Giunsa ang pag-scale gikan sa 1 hangtod 100 nga tiggamit

Source: www.habr.com

Idugang sa usa ka comment