Banyak pemula telah melalui perkara ini: ramai pengguna baharu mendaftar setiap hari, dan pasukan pembangunan bergelut untuk memastikan perkhidmatan berjalan.

Ia adalah masalah yang bagus untuk dimiliki, tetapi terdapat sedikit maklumat yang jelas di web tentang cara berhati-hati menskala aplikasi web daripada tiada kepada ratusan ribu pengguna. Biasanya terdapat sama ada penyelesaian kebakaran atau penyelesaian kesesakan (dan selalunya kedua-duanya). Oleh itu, orang menggunakan teknik yang agak klise untuk menskalakan projek amatur mereka menjadi sesuatu yang sangat serius.

Mari cuba tapis maklumat dan tuliskan formula asas. Kami akan meningkatkan tapak perkongsian foto baharu kami Graminsta langkah demi langkah daripada 1 kepada 100 pengguna.

Mari tuliskan tindakan khusus yang perlu diambil apabila penonton meningkat kepada 10, 100, 1000, 10 dan 000 orang.

1 pengguna: 1 mesin

Hampir setiap aplikasi, sama ada laman web atau aplikasi mudah alih, mempunyai tiga komponen utama:

• API
• pangkalan data
• klien (aplikasi mudah alih itu sendiri atau tapak web)

Pangkalan data menyimpan data berterusan. API menyediakan permintaan kepada dan sekitar data ini. Pelanggan menghantar data kepada pengguna.

Saya sampai pada kesimpulan bahawa adalah lebih mudah untuk bercakap tentang penskalaan aplikasi jika, dari sudut pandangan seni bina, pelanggan dan entiti API dipisahkan sepenuhnya.

Apabila kita mula membina aplikasi, ketiga-tiga komponen boleh dijalankan pada pelayan yang sama. Dalam beberapa cara, ini serupa dengan persekitaran pembangunan kami: seorang jurutera menjalankan pangkalan data, API dan klien pada mesin yang sama.

Secara teori, kami boleh menggunakan ia dalam awan pada satu contoh DigitalOcean Droplet atau AWS EC2, seperti yang ditunjukkan di bawah:

Dengan itu, jika terdapat lebih daripada satu pengguna di tapak, hampir selalu masuk akal untuk mendedikasikan lapisan pangkalan data.

10 pengguna: memindahkan pangkalan data ke tahap yang berasingan

Membahagikan pangkalan data kepada perkhidmatan terurus seperti Amazon RDS atau Pangkalan Data Terurus Lautan Digital akan memberi perkhidmatan yang baik kepada kami untuk masa yang lama. Ia lebih mahal sedikit daripada pengehosan sendiri pada mesin tunggal atau contoh EC2, tetapi dengan perkhidmatan ini anda mendapat banyak sambungan berguna daripada kotak yang akan berguna pada masa hadapan: sandaran berbilang wilayah, baca replika, automatik sandaran, dan banyak lagi.

Inilah rupa sistem sekarang:

100 pengguna: memindahkan pelanggan ke tahap yang berasingan

Nasib baik, pengguna pertama kami sangat menyukai aplikasi kami. Trafik menjadi lebih stabil, jadi sudah tiba masanya untuk memindahkan pelanggan ke tahap yang berasingan. Perlu diingatkan bahawa pemisahan entiti ialah aspek utama dalam membina aplikasi berskala. Memandangkan satu bahagian sistem menerima lebih banyak trafik, kami boleh membahagikannya untuk mengawal cara skala perkhidmatan berdasarkan corak trafik tertentu.

Inilah sebabnya saya suka menganggap klien sebagai berasingan daripada API. Ini menjadikannya sangat mudah untuk memikirkan tentang pembangunan untuk berbilang platform: web, web mudah alih, iOS, Android, aplikasi desktop, perkhidmatan pihak ketiga, dll. Mereka semua hanyalah pelanggan yang menggunakan API yang sama.

Sebagai contoh, kini pengguna kami paling kerap meminta untuk mengeluarkan aplikasi mudah alih. Jika anda memisahkan klien dan entiti API, ini menjadi lebih mudah.

Inilah rupa sistem sedemikian:

1000 pengguna: tambah pengimbang beban

Perkara sedang mencari. Pengguna Graminsta semakin banyak memuat naik foto. Jumlah pendaftaran juga semakin meningkat. Pelayan API tunggal kami mengalami kesukaran untuk mengikuti semua trafik. Perlu lebih banyak besi!

Pengimbang beban adalah konsep yang sangat berkuasa. Idea utama ialah kami meletakkan pengimbang beban di hadapan API dan ia mengedarkan trafik kepada kejadian perkhidmatan individu. Beginilah cara kami menskalakan secara mendatar, bermakna kami menambah lebih banyak pelayan dengan kod yang sama, meningkatkan bilangan permintaan yang boleh kami proses.

Kami akan meletakkan pengimbang beban berasingan di hadapan klien web dan di hadapan API. Ini bermakna anda boleh menjalankan berbilang kejadian yang menjalankan kod API dan kod klien web. Pengimbang beban akan mengarahkan permintaan ke pelayan yang kurang dimuatkan.

Di sini kita mendapat satu lagi kelebihan penting - redundansi. Apabila satu contoh gagal (mungkin terlebih muatan atau ranap), kita ditinggalkan dengan orang lain yang terus membalas permintaan masuk. Sekiranya terdapat hanya satu contoh yang berfungsi, maka sekiranya berlaku kegagalan keseluruhan sistem akan ranap.

Pengimbang beban juga menyediakan penskalaan automatik. Kami boleh mengkonfigurasinya untuk meningkatkan bilangan kejadian sebelum beban puncak, dan mengurangkannya apabila semua pengguna sedang tidur.

Dengan pengimbang beban, tahap API boleh diskalakan hampir tanpa had, hanya menambah kejadian baharu apabila bilangan permintaan meningkat.

Catatan. Pada masa ini sistem kami sangat serupa dengan apa yang ditawarkan oleh syarikat PaaS seperti Heroku atau Elastic Beanstalk pada AWS di luar kotak (itulah sebabnya mereka begitu popular). Heroku meletakkan pangkalan data pada hos yang berasingan, mengurus pengimbang beban penskalaan automatik dan membolehkan anda mengehos klien web secara berasingan daripada API. Ini adalah sebab yang bagus untuk menggunakan Heroku untuk projek peringkat awal atau permulaan - anda mendapat semua perkhidmatan asas di luar kotak.

10 pengguna: CDN

Mungkin kita sepatutnya melakukan ini dari awal lagi. Memproses permintaan dan menerima foto baharu mula memberi tekanan kepada pelayan kami.

Pada peringkat ini, anda perlu menggunakan perkhidmatan awan untuk menyimpan kandungan statik - imej, video dan banyak lagi (AWS S3 atau Digital Ocean Spaces). Secara umum, API kami harus mengelak daripada mengendalikan perkara seperti menyajikan imej dan memuat naik imej ke pelayan.

Satu lagi kelebihan pengehosan awan ialah CDN (AWS memanggil add-on Cloudfront ini, tetapi banyak penyedia storan awan menawarkannya di luar kotak). CDN secara automatik menyimpan imej kami dalam pelbagai pusat data di seluruh dunia.

Walaupun pusat data utama kami mungkin terletak di Ohio, jika seseorang meminta imej dari Jepun, pembekal awan akan membuat salinan dan menyimpannya dalam pusat data Jepun mereka. Orang seterusnya yang meminta imej ini di Jepun akan menerimanya dengan lebih cepat. Ini penting apabila kami bekerja dengan fail besar, seperti foto atau video, yang mengambil masa yang lama untuk memuat turun dan menghantar ke seluruh planet.

100 pengguna: menskala lapisan data

CDN telah banyak membantu: trafik berkembang pada kelajuan penuh. Blogger video terkenal Mavid Mobrick baru sahaja mendaftar dengan kami dan menyiarkan "cerita"nya, seperti yang mereka katakan. Terima kasih kepada pengimbang beban, penggunaan CPU dan memori pada pelayan API dikekalkan rendah (sepuluh tika API berjalan), tetapi kami mula mendapat banyak tamat masa atas permintaan... dari manakah kelewatan ini datang?

Menggali sedikit metrik, kita melihat bahawa CPU pada pelayan pangkalan data adalah 80-90% dimuatkan. Kami berada pada had.

Menskala lapisan data mungkin merupakan bahagian yang paling sukar dalam persamaan. Pelayan API menyediakan permintaan tanpa kewarganegaraan, jadi kami hanya menambah lebih banyak tika API. Hidung majoriti pangkalan data tidak boleh melakukan ini. Kami akan bercakap tentang sistem pengurusan pangkalan data hubungan yang popular (PostgreSQL, MySQL, dll.).

Caching

Salah satu cara paling mudah untuk meningkatkan prestasi pangkalan data kami ialah memperkenalkan komponen baharu: lapisan cache. Kaedah caching yang paling biasa ialah stor rekod nilai kunci dalam memori, seperti Redis atau Memcached. Kebanyakan awan mempunyai versi terurus perkhidmatan ini: Elasticache pada AWS dan Memorystore di Google Cloud.

Cache berguna apabila perkhidmatan membuat banyak panggilan berulang ke pangkalan data untuk mendapatkan maklumat yang sama. Pada asasnya, kami mengakses pangkalan data sekali sahaja, menyimpan maklumat dalam cache dan tidak menyentuhnya lagi.

Contohnya, dalam perkhidmatan Graminsta kami, setiap kali seseorang pergi ke halaman profil bintang Mobrik, pelayan API menanyakan pangkalan data untuk mendapatkan maklumat daripada profilnya. Ini berlaku lagi dan lagi. Memandangkan maklumat profil Mobrik tidak berubah dengan setiap permintaan, ia sangat baik untuk caching.

Kami akan cache hasil daripada pangkalan data dalam Redis dengan kunci user:id dengan tempoh sah selama 30 saat. Sekarang, apabila seseorang pergi ke profil Mobrik, kami mula-mula menyemak Redis, dan jika data itu ada, kami hanya memindahkannya terus daripada Redis. Sekarang permintaan ke profil yang paling popular di tapak praktikal tidak memuatkan pangkalan data kami.

Satu lagi kelebihan kebanyakan perkhidmatan caching ialah ia lebih mudah untuk skala daripada pelayan pangkalan data. Redis mempunyai mod Kluster Redis terbina dalam. Sama seperti pengimbang beban1, ia membolehkan anda mengedarkan cache Redis anda merentasi berbilang mesin (merentasi ribuan pelayan jika perlu).

Hampir semua aplikasi berskala besar menggunakan caching; ia adalah bahagian yang sangat penting dalam API pantas. Pemprosesan pertanyaan yang lebih pantas dan kod yang lebih produktif semuanya penting, tetapi tanpa cache adalah hampir mustahil untuk menskalakan perkhidmatan kepada berjuta-juta pengguna.

Baca Replika

Apabila bilangan pertanyaan kepada pangkalan data telah meningkat dengan banyak, satu lagi perkara yang boleh kita lakukan ialah menambah replika baca dalam sistem pengurusan pangkalan data. Dengan perkhidmatan terurus yang diterangkan di atas, ini boleh dilakukan dalam satu klik. Replika baca akan kekal terkini dalam pangkalan data utama dan tersedia untuk pernyataan SELECT.

Inilah sistem kami sekarang:

Langkah seterusnya

Memandangkan aplikasi terus meningkat, kami akan terus memisahkan perkhidmatan untuk menskalakannya secara bebas. Sebagai contoh, jika kita mula menggunakan Websockets, maka masuk akal untuk menarik kod pemprosesan Websockets ke dalam perkhidmatan yang berasingan. Kami boleh meletakkannya pada kejadian baharu di belakang pengimbang beban kami sendiri, yang boleh menaikkan dan menurunkan skala berdasarkan sambungan Websockets terbuka dan tanpa mengira bilangan permintaan HTTP.

Kami juga akan terus memerangi sekatan di peringkat pangkalan data. Pada peringkat ini sudah tiba masanya untuk mengkaji pembahagian pangkalan data dan pembahagian. Kedua-dua pendekatan memerlukan overhed tambahan, tetapi membolehkan anda menskala pangkalan data hampir selama-lamanya.

Kami juga ingin memasang perkhidmatan pemantauan dan analitik seperti New Relic atau Datadog. Ini akan membantu anda mengenal pasti pertanyaan perlahan dan memahami di mana penambahbaikan diperlukan. Semasa kami membuat skala, kami ingin menumpukan pada mencari kesesakan dan menghapuskannya—selalunya menggunakan beberapa idea daripada bahagian sebelumnya.

sumber

Jawatan ini diilhamkan oleh salah satu daripada siaran kegemaran saya tentang kebolehskalaan tinggi. Saya ingin menjadikan artikel itu lebih spesifik untuk peringkat awal projek dan membukanya daripada satu vendor. Pastikan anda membaca jika anda berminat dengan topik ini.

Nota kaki

1. Walaupun serupa dari segi pengagihan beban merentas berbilang kejadian, pelaksanaan asas gugusan Redis sangat berbeza daripada pengimbang beban. [kembali]

Sumber: www.habr.com