Akeh startup sing wis ngalami iki: akeh pangguna anyar sing ndhaptar saben dina, lan tim pangembangan berjuang supaya layanan kasebut tetep mlaku.
Iku masalah becik kanggo duwe, nanging ana sethitik informasi cetha ing web bab carane kasebut kanthi teliti, ukuran aplikasi web saka apa-apa kanggo atusan ewu pangguna. Biasane ana solusi geni utawa solusi bottleneck (lan asring loro-lorone). Mula, wong nggunakake teknik sing rada klise kanggo nggedhekake proyek amatir dadi perkara sing serius.
Ayo nyoba nyaring informasi lan nulis rumus dhasar. Kita bakal nggawe ukuran situs enggo bareng foto anyar Graminsta langkah demi langkah saka 1 nganti 100 pangguna.
Ayo nulis tumindak tartamtu sing kudu ditindakake nalika pamirsa mundhak dadi 10, 100, 1000, 10 lan 000 wong.
1 pangguna: 1 mesin
Meh saben aplikasi, dadi situs web utawa aplikasi seluler, nduweni telung komponen utama:
- API
- database
- klien (aplikasi seluler dhewe utawa situs web)
Database nyimpen data sing terus-terusan. API serves panjalukan kanggo lan watara data iki. Klien ngirim data menyang pangguna.
Aku teka menyang kesimpulan sing luwih gampang kanggo pirembagan babagan skala aplikasi yen, saka sudut pandang arsitektur, klien lan entitas API wis rampung kapisah.
Nalika kita miwiti mbangun aplikasi, kabeh telung komponen bisa mbukak ing server sing padha. Ing sawetara cara, iki padha karo lingkungan pangembangan kita: siji insinyur mbukak database, API, lan klien ing mesin sing padha.
Ing teori, kita bisa nyebarake ing awan ing siji DigitalOcean Droplet utawa AWS EC2, kaya sing ditampilake ing ngisor iki:
Kanthi ngandika, yen bakal ana luwih saka siji pangguna ing situs, meh mesthi nggawe akal kanggo ngaturake lapisan basis data.
10 pangguna: mindhah database menyang tingkat sing kapisah
Pamisahan database dadi layanan sing dikelola kaya Amazon RDS utawa Digital Ocean Managed Database bakal nglayani kita kanthi apik kanggo wektu sing suwe. Iku luwih larang tinimbang hosting dhewe ing mesin siji utawa conto EC2, nanging kanthi layanan kasebut, sampeyan entuk akeh ekstensi migunani saka kothak sing bakal migunani ing mangsa ngarep: serep multi-wilayah, maca replika, otomatis. serep, lan liyane.
Iki minangka sistem saiki:
100 pangguna: mindhah klien menyang level sing kapisah
Untunge, pangguna pisanan kita seneng banget karo aplikasi kita. Lalu lintas dadi luwih stabil, dadi wektune kanggo mindhah klien menyang level sing kapisah. Sampeyan kudu nyatet sing pisah entitas minangka aspek kunci kanggo mbangun aplikasi sing bisa diukur. Minangka salah siji bagΓ©an saka sistem nampa lalu lintas luwih, kita bisa partisi kanggo ngontrol carane layanan timbangan adhedhasar pola lalu lintas tartamtu.
Mulane aku seneng mikirake klien minangka kapisah saka API. Iki nggawe gampang banget kanggo mikir babagan ngembangake macem-macem platform: web, web seluler, iOS, Android, aplikasi desktop, layanan pihak katelu, lan sapiturute. Kabeh iku mung klien nggunakake API sing padha.
Contone, saiki pangguna paling kerep njaluk ngeculake aplikasi seluler. Yen sampeyan misahake klien lan entitas API, iki dadi luwih gampang.
Iki minangka sistem kaya ngono:
1000 pangguna: nambah load balancer
Barang katon munggah. Pangguna Graminsta nambah akeh foto. Jumlah registrasi uga saya akeh. Server API siji-sijine kita angel ngetutake kabeh lalu lintas. Butuh wesi liyane!
Load balancer minangka konsep sing kuat banget. Ide utama yaiku kita nyelehake penyeimbang beban ing ngarep API, lan nyebarake lalu lintas menyang instansi layanan individu. Iki minangka cara skala horisontal, tegese kita nambah server liyane kanthi kode sing padha, nambah jumlah panjaluk sing bisa diproses.
Kita bakal nyelehake penyeimbang beban sing kapisah ing ngarep klien web lan ing ngarep API. Iki tegese sampeyan bisa mbukak sawetara kedadean sing nganggo kode API lan kode klien web. Load balancer bakal ngarahake panjalukan menyang server sing kurang dimuat.
Ing kene kita entuk kauntungan penting liyane - redundansi. Nalika salah siji conto gagal (mbok menawa kakehan utawa tabrakan), kita ditinggalake karo wong liya sing terus nanggapi panjaluk sing mlebu. Yen mung ana siji conto sing bisa digunakake, mula yen gagal, kabeh sistem bakal nabrak.
Penyeimbang beban uga nyedhiyakake skala otomatis. Kita bisa ngatur kanggo nambah jumlah kedadeyan sadurunge mbukak puncak, lan nyuda nalika kabeh pangguna turu.
Kanthi load balancer, level API bisa diskalakake meh tanpa wates, mung nambahake kedadeyan anyar amarga jumlah panjalukan mundhak.
Cathetan. Saiki sistem kita meh padha karo apa sing ditawakake perusahaan PaaS kaya Heroku utawa Elastic Beanstalk ing AWS metu saka kothak (mulane dheweke dadi populer). Heroku nempatake basis data ing host sing kapisah, ngatur imbangan beban skala otomatis, lan ngidini sampeyan dadi tuan rumah klien web kanthi kapisah saka API. Iki minangka alasan sing apik kanggo nggunakake Heroku kanggo proyek tahap awal utawa wiwitan - sampeyan entuk kabeh layanan dhasar saka kothak.
10 pangguna: CDN
Mbok menawa kita kudu nindakake iki wiwit wiwitan. Panjaluk pangolahan lan nampa foto anyar wiwit nggawe beban banget ing server kita.
Ing tahap iki, sampeyan kudu nggunakake layanan maya kanggo nyimpen konten statis - gambar, video lan liya-liyane (AWS S3 utawa Digital Ocean Spaces). UmumΓ©, API kita kudu ngindhari masalah kaya ngladeni gambar lan ngunggah gambar menyang server.
Kauntungan liyane saka hosting awan yaiku CDN (AWS nyebat add-on Cloudfront iki, nanging akeh panyedhiya panyimpenan maya nawakake metu saka kothak). CDN kanthi otomatis nyimpen gambar kita ing macem-macem pusat data ing saindenging jagad.
Sanajan pusat data utama kita bisa uga ana ing Ohio, yen ana sing njaluk gambar saka Jepang, panyedhiya awan bakal nggawe salinan lan nyimpen ing pusat data Jepang. Wong sabanjure sing njaluk gambar iki ing Jepang bakal nampa luwih cepet. Iki penting nalika kita nggarap file gedhe, kayata foto utawa video, sing butuh wektu suwe kanggo didownload lan dikirim ing saindenging planet.
100 pangguna: skala lapisan data
CDN wis mbantu akeh: lalu lintas berkembang kanthi cepet. Blogger video sing misuwur Mavid Mobrick mung ndhaptar karo kita lan ngirim "crita", kaya sing dikandhakake. Thanks kanggo load balancer, panggunaan CPU lan memori ing server API tetep sithik (sepuluh instans API mlaku), nanging kita wiwit entuk akeh wektu entek ing panjalukan ... saka ngendi telat iki teka?
Digging sethitik menyang metrik, kita waca sing CPU ing server database 80-90% dimuat. Kita lagi ing watesan.
Scaling lapisan data mbokmenawa bagean paling angel saka persamaan. Server API nglayani panjalukan tanpa negara, mula kita mung nambahake conto API liyane. irung mayoritas database ora bisa nindakake iki. Kita bakal ngomong babagan sistem manajemen basis data relasional populer (PostgreSQL, MySQL, lsp.).
Caching
Salah sawijining cara paling gampang kanggo nambah kinerja database kita yaiku ngenalake komponen anyar: lapisan cache. Cara caching sing paling umum yaiku nyimpen rekaman nilai kunci ing memori, kayata Redis utawa Memcached. Umume awan duwe versi ngatur layanan kasebut: Elasticache ing AWS lan Memorystore ing Google Cloud.
Cache migunani nalika layanan nggawe akeh telpon bola-bali menyang database kanggo njupuk informasi sing padha. Ateges, kita ngakses database mung sapisan, nyimpen informasi ing cache, lan ora ndemek maneh.
Contone, ing layanan Graminsta kita, saben-saben ana wong menyang kaca profil bintang Mobrik, server API takon database kanggo informasi saka profil. Iki kedadeyan maneh lan maneh. Wiwit informasi profil Mobrik ora ngganti karo saben request, iku apik banget kanggo caching.
Kita bakal cache asil saka database ing Redis dening tombol user:id kanthi wektu validitas 30 detik. Saiki, nalika ana wong menyang profil Mobrik, kita mriksa Redis dhisik, lan yen data ana, kita mung ngirim langsung saka Redis. Saiki panjalukan kanggo profil paling populer ing situs praktis ora mbukak database kita.
Kauntungan liyane saka umume layanan caching yaiku ukurane luwih gampang tinimbang server database. Redis duwe mode Kluster Redis sing dibangun. Mirip karo load balancer, ngidini sampeyan nyebarake cache Redis ing pirang-pirang mesin (ing ewonan server yen perlu).
Meh kabeh aplikasi skala gedhe nggunakake caching; iki minangka bagean integral saka API sing cepet. Pangolahan pitakon sing luwih cepet lan kode sing luwih produktif kabeh penting, nanging tanpa cache, meh ora bisa skala layanan menyang mayuta-yuta pangguna.
Maca Replika
Nalika jumlah pitakon menyang database saya tambah akeh, siji liyane sing bisa kita lakoni yaiku nambah replika maca ing sistem manajemen database. Kanthi layanan sing diatur ing ndhuwur, iki bisa ditindakake kanthi siji klik. Replika sing diwaca bakal tetep ana ing basis data utama lan kasedhiya kanggo pernyataan PILIH.
Mangkene sistem kita saiki:
Tumindak luwih
Nalika aplikasi terus skala, kita bakal terus misahake layanan kanggo skala kasebut kanthi mandiri. Contone, yen kita miwiti nggunakake Websockets, iku ndadekake pangertèn kanggo narik kode pangolahan Websockets menyang layanan kapisah. Kita bisa nyelehake ing kasus anyar ing mburi load balancer dhewe, sing bisa munggah lan mudhun adhedhasar sambungan Websockets sing mbukak lan preduli saka jumlah panjalukan HTTP.
Kita uga bakal terus nglawan watesan ing tingkat database. Ing tahap iki wektune sinau babagan pemisahan database lan sharding. Loro-lorone pendekatan mbutuhake overhead tambahan, nanging ngidini sampeyan nggedhekake database meh tanpa wates.
Kita uga pengin nginstal layanan ngawasi lan analytics kaya New Relic utawa Datadog. Iki bakal mbantu sampeyan ngenali pitakon alon lan ngerti babagan perlu perbaikan. Nalika kita skala, kita pengin fokus ing nemokake bottlenecks lan mbusak - asring nggunakake sawetara gagasan saka bagean sadurunge.
Sumber informasi
Kiriman iki diilhami dening salah sawijining . Aku pengin nggawe artikel luwih spesifik kanggo tahap awal proyek lan ngeculake saka siji vendor. Aja manawa kanggo maca yen sampeyan kasengsem ing topik iki.
Cathetan sikil
- Sanajan padha karo distribusi beban ing pirang-pirang kasus, implementasine kluster Redis beda banget karo penyeimbang beban.
Source: www.habr.com