Bagaimana e-commerce bertahan dalam promosi skala besar. Bersiap-siap untuk beban puncak di web [Bagian 1]

Halo semuanya, saya berhubungan dengan Alexey Pristavko, direktur proyek web DataLine.
Black Friday, acara e-commerce terbesar di dunia, berlangsung setiap tahun di hari-hari terakhir bulan November. Ini adalah waktu untuk diskon rekor, toko buka hampir di tengah malam, dan situs yang berpartisipasi dalam aksi jatuh, tidak tahan terhadap peningkatan tajam dalam arus lalu lintas.

Karena itu, dengan menggunakan contohnya, kami akan menganalisis cara mempersiapkan peningkatan beban yang serius di situs web atau aplikasi web.
Di bawah kucing, kita akan berbicara secara rinci tentang bagaimana manajer, pengembang, dan administrator toko online IT dapat bertahan dari peristiwa berskala besar.

Apa yang mengancam Black Friday

Seperti yang saya tulis di atas, Black Friday adalah hari yang menyebabkan banyak masalah bagi semua orang yang terlibat dalam pemeliharaan situs e-commerce.

Untuk merasakannya, perhatikan grafik di bawah ini. Ini mencerminkan peningkatan jumlah permintaan di situs selama Black Friday.



Dibandingkan dengan puncak harian normal, ketika tidak ada saham yang ditahan, lalu lintas Black Friday tumbuh 100-200%, dan ini bukan batasnya.

Jika situs besar sudah memiliki banyak lalu lintas sendiri, maka toko online sederhana selama periode kampanye akan dengan mudah menerima banyak pengunjung dan tersedak. Mengutip lelucon lama: "bisnis membuat semua toko berbeda, dan Black Friday online menyamakan kedudukan semua orang."

Dihasilkan dari Black Friday "memberi makan" penjual sepanjang tahun berikutnya. Bisnis ini sangat tertarik untuk menarik jumlah maksimum pelanggan baru yang akan kembali ke situs untuk membeli lagi dan lagi. Tetapi untuk ini, pengalaman pertama mereka dengan situs harus berjalan dengan lancar, dan untuk memastikan ini adalah tugas para spesialis TI.

Semakin banyak pelanggan secara bersamaan di situs, semakin tinggi persyaratan untuk stabilitas dan kecepatan responsnya. Tentunya Anda memperhatikan bahwa situs web toko, tempat Anda beralih dari halaman arahan blackfridaysales, bekerja sangat lambat atau tidak berfungsi sama sekali. Saya ragu Anda sudah menunggu untuk mengunduh, tetapi tidak pergi setelah beberapa detik.

Kami akan berbicara tentang cara melindungi pelanggan dari pengalaman negatif, dan situs dari kerusakan karena kelebihan, di bawah. Namun, tips lebih lanjut berlaku untuk setiap beban puncak yang diharapkan.

Secara umum, ada dua tahap mempersiapkan situs untuk peningkatan lalu lintas: teknis dan organisasi. Pada artikel ini kita akan membahas tahap teknis, dan saya akan menjelaskan detail organisasi secara rinci di bagian kedua, yang akan dirilis dalam seminggu.

Persiapan teknis situs

Penafian kecil: jangan berharap menemukan di sini petunjuk terperinci tentang apa, di mana dan bagaimana mengencangkannya sehingga “kebahagiaan bagi semua sia-sia, dan tidak ada yang tersinggung”. Pertama-tama, situs dan proyek berbeda untuk semua orang. Kedua, saran teknis khusus pada perangkat lunak tertentu lebih dari cukup. Termasuk di Habré. Pertama-tama, saya ingin menyampaikan kepada para pembaca prinsip dasar bekerja dengan proyek web dan menunjukkan titik awal, memperkenalkan teknik dasar dan nuansa yang bebas platform.

Mari kita mulai dengan aksioma: pengguna tidak suka menunggu, jadi sangat penting untuk bekerja dengan timing dan kecepatan respons. Pada Black Friday, akan ada lebih banyak permintaan ke situs daripada biasanya, dan Anda mungkin tidak hanya menemukan setetes konversi karena beban yang panjang, tetapi juga kelebihan waktu tunggu HTTP (situs tidak merespons).

Paling sering, situs jatuh di bawah beban bukan karena kerusakan fisik, tetapi karena waktu respons mulai melebihi batas waktu karena kelebihan pada beberapa node. Ini mirip dengan kemacetan lalu lintas, dan untuk sementara waktu Anda harus mengambil kendali ke tangan Anda sendiri: memperluas peralatan (skala), menyesuaikan, memutus, dan mengonfigurasi (batas waktu), mengoptimalkan beban pada kendaraan (paket dan permintaan), dan bekerja dengan pengecualian.

Karena dalam konteks kinerja situs memiliki dua aspek - kecepatan respons dan jumlah permintaan yang diproses secara bersamaan, kami akan meningkatkan parameter ini.

Paling sering, bisnis mewakili kecepatan respons sebagai kecepatan situs menurut Google Analytics, dan jumlah permintaan simultan sebagai jumlah pengguna secara bersamaan di situs.

Dalam pekerjaan teknis, sangat tidak nyaman untuk beroperasi dengan parameter-parameter ini.
Selanjutnya, saya akan mengusulkan metrik yang lebih cocok untuk perhitungan.

Kami mengoptimalkan kecepatan respons

Saat mengoptimalkan kecepatan respons, kami tertarik pada dua indikator: kecepatan respons server dan waktu muat halaman.

Waktu Muat Halaman terdiri dari tautan berikut:

• Waktu pembuatan halaman server;
• Waktu transfer halaman dari server ke klien;
• Waktu pemrosesan halaman di browser klien.

Ketika semuanya berjalan seperti biasa, faktor penentu untuk Waktu Muat Halaman bukanlah waktu halaman dihasilkan oleh server dan waktu halaman dikirim melalui jaringan, tetapi kualitas ujung depan dan kecepatan situs di browser. Karena yang terakhir sepenuhnya berada di pihak pengguna, Anda tidak bisa takut terhadap rem pada Black Friday. Namun, masalah dapat muncul karena kelebihan pada saluran Internet Anda atau pada pengiriman komponen eksternal (penghitung afiliasi, obrolan online, plugin CRM, dll.).
Bagaimana cara mengatasinya? Berikut ini beberapa kiat kerja:

1. Periksa beban saluran Internet. Hitung estimasi pertumbuhan. Jika ragu, perluas saluran. Beberapa penyedia, selain ekstensi mahal secara berkelanjutan, mungkin menawarkan ekstensi sementara untuk periode puncak (jauh lebih murah) atau bahkan memungkinkan Anda untuk secara singkat melebihi kecepatan maksimum.
2. Menggunakan CDN? Hubungi dukungan teknis dan beri peringatan tentang pertumbuhan lalu lintas yang direncanakan. Mereka juga bersiap untuk puncak umum, dan perkiraan Anda akan berguna. Jika CDN berjanji bahwa semuanya akan baik-baik saja, tetapi, terlepas dari segalanya, akan "berbaring", kehadiran korespondensi akan membantu mengajukan klaim kompensasi.
3. Di muka, buat skrip untuk menonaktifkan sementara komponen eksternal jika ada masalah. Sejajarkan skenario dengan bisnis. Tidak akan berlebihan untuk berkomunikasi dengan dukungan teknis dari layanan yang digunakan, lagi pula biasanya tidak mungkin untuk mempengaruhi mereka sebaliknya.
4. Di banyak situs, statis diberikan menggunakan server aplikasi. Di bawah beban tinggi, jumlah permintaan statika meningkat berkali-kali, dan mereka mulai bersaing untuk sumber daya dengan aplikasi itu sendiri. Pastikan untuk mengkonfigurasi statika pengembalian langsung dari Nginx. Pertama, ini akan mengatasi jauh lebih baik dengan ini, dan kedua, akan ada pekerjaan yang jauh lebih berguna untuk Apache, Tomcat atau thread Jetty Anda.

Meningkatkan kecepatan respons

Optimalisasi kecepatan respons per se mengacu pada peningkatan keseluruhan dalam kinerja situs. Secara teoritis, ini membantu mengurangi jumlah pekerjaan yang dilakukan oleh aplikasi, dan karena ini meningkatkan penskalaan - karena jika setiap permintaan menjadi "lebih murah", Anda dapat memproses lebih banyak permintaan dengan sumber daya yang sama.

Namun dalam praktiknya, mengoptimalkan kecepatan respons membutuhkan kerja mandiri yang besar. Tidak mungkin mengoptimalkan semuanya sekaligus, tetapi memecahkan sesuatu dalam proses itu mudah.

Kiat: pikirkan secara sistematis. Katakanlah kinerja kode telah meningkat, dan aplikasi telah mulai membuat kueri basis data yang lebih simultan. Tapi inilah masalahnya: kinerja basis data tidak memungkinkan untuk memproses sejumlah permintaan, dan situs secara keseluruhan menjadi lebih buruk, dan waktu yang berharga dihabiskan sebelum dimulainya tindakan.

Jadi lebih baik untuk fokus pada penskalaan dan skalabilitas, dan melakukan optimasi umum secara terpisah dari persiapan untuk Black Friday, agar tidak berantakan karena tenggat waktu yang sulit. Ingat, sekarang tugas kami adalah memastikan bahwa pada puncak beban situs berfungsi tidak lebih buruk daripada di luar.

Kecepatan pembuatan halaman hanya akan menarik bagi kami jika dikaitkan dengan indikator lain - jumlah beban yang masuk.

Harap dicatat: untuk situs, hanya jumlah permintaan simultan yang dibuat oleh pengguna yang penting, dan bukan jumlah pengguna online di situs. Dan untuk menghitung dengan akurasi yang dapat diterima jumlah permintaan per detik dengan jumlah pengunjung cukup sulit (saya menulis tentang ini di atas). Lebih baik meminta metrik bisnis lainnya - tampilan halaman per jam dan waktu server.

Sebagai hasilnya, kami mendapatkan tujuan yang dapat dipahami: untuk memastikan pembuatan halaman untuk waktu X dengan jumlah permintaan per detik Y. Memiliki metrik numerik khusus, jauh lebih mudah untuk mengevaluasi tingkat kesiapan dan hasil saat ini.

Berikut ini adalah rencana pelatihan teknis umum:

1. Cari tahu indikator saat ini (lakukan pengujian beban versi situs saat ini);
2. Untuk memahami apa yang sebenarnya hilang dan berapa banyak sumber daya yang dibutuhkan untuk memesan;
3. Tambahkan sumber daya;
4. Ulangi pengujian stres dan lihat apakah itu membantu.

Terlihat terlalu mudah? Anda benar, setiap poin penuh dengan banyak kejutan.

Sangat sering, menambahkan sumber daya secara parsial memperbaiki situasi, tetapi tidak menyelamatkan semuanya. Atau di lingkungan uji, situs berfungsi seperti jam, dan pada rem lagi.

Selanjutnya, saya akan menunjukkan kepada Anda bagaimana mengidentifikasi masalah potensial dan memperbaiki kelemahan. Mari kita mulai dengan bagaimana melakukan stress testing dan mendapatkan hasil yang realistis.

Kami melakukan pengujian beban dengan benar

Di mana untuk menguji?

Seringkali, tes stres dilakukan pada sistem yang produktif. Ini mungkin baik untuk mengendalikan situasi secara keseluruhan, tetapi tidak untuk menyelesaikan masalah spesifik secara berulang. Ingat, biasanya setelah masalah yang baru ditemukan setelah dieliminasi, yang baru mungkin muncul. Peluru perak jarang mengenai sasaran.

Tes beban yang gagal dapat menyebabkan ketidaknyamanan bagi pengguna situs atau bahkan "mematahkannya" untuk sementara waktu. Yang terbaik adalah menggunakan area khusus sebagai kelinci percobaan.

Itu harus memenuhi persyaratan berikut:

• Area khusus harus sepenuhnya independen dan terisolasi dari yang produktif;
  
• Idealnya, area khusus harus konsisten dengan ukuran produk. Model skala besar juga cocok, tetapi akan mengurangi kualitas dan signifikansi pengujian. Jika beban pada sumber daya tumbuh non-linear (seperti biasanya terjadi), model Anda tidak akan menunjukkan bahwa di bawah beban penuh, sumber daya sudah habis sebelumnya;
  
• Yang terbaik adalah menggunakan peralatan yang persis sama (tapi tidak sama!) Untuk pengujian seperti pada prod. Jika tidak, bahkan jika nilai-nilai kuantitatif dari sumber daya diamati, tidak akan mungkin untuk memberikan kualitas. Itu bisa memainkan lelucon kejam pada saat genting. Jika ini tidak memungkinkan, uji kinerja peralatan di bawah beban Anda dan tentukan koefisien untuk penyesuaian.
  

Sekarang mari kita bicara tentang cara menghasilkan beban uji. Saya akan memberikan beberapa teknik dasar, yang masing-masing memiliki pro dan kontra.

Bagaimana cara menghasilkan suatu beban?

1. Menguji permintaan dari log

Dimungkinkan untuk meniru arus lalu lintas melalui log server pertempuran. Nilai tambah yang jelas dari pendekatan ini adalah Anda tidak perlu repot dengan analitik, pemodelan statistik, dan profil lalu lintas sintetis.

Tetapi Anda masih harus membersihkan log dari permintaan yang tidak dapat dilakukan atau tidak diperlukan.
Misalnya, Anda tidak perlu "membeli" barang di tempat yang produktif, ini akan menyebabkan masalah dengan konten produk dari basis data.

Akan sulit untuk mereproduksi penundaan yang realistis di antara permintaan.
Meniru sesi pengguna juga sangat sulit, metode ini sangat dekat dengan pengujian berbasis hit.

2. Menggunakan Yandex.Tank dan Phantom

Tangki bersama dengan Phantom adalah alat yang sangat nyaman dan populer untuk pengujian berbasis hit. Ini memiliki antarmuka yang bijaksana dan memungkinkan Anda untuk mengelola beban. Untuk mulai menembaki dari tangki, Anda harus menyiapkan "kartrid" - file khusus yang berisi permintaan generator.

Namun, terlepas dari semua kemudahannya, Tank memiliki kelemahan utama: Tank tidak tahu cara menggunakan sesi pengguna.

Anda bisa melupakan otorisasi, tentang pekerjaan penuh dengan cookie, dan tentang penundaan variabel. Tank hanya dapat "mematuk" permintaan dari satu alamat.

Ini cocok untuk Anda jika:

• Tidak ada perbedaan dalam waktu respons server untuk pengguna yang berwenang dan tidak sah, atau dapat diabaikan;
• Menguji API tanpa sesi HTTP secara eksplisit;
• Pendekatan ini umumnya konsisten dengan logika situs Anda (biasanya tidak cocok untuk toko online).

3. Menggunakan Apache JMeter

Ini adalah alat paling fleksibel yang memungkinkan Anda untuk meniru sesi pengguna secara detail. Jadi, dengan bantuannya, Anda masih bisa menjawab pertanyaan bisnis "berapa banyak pengguna yang bertahan di situs?" Selain itu, JMeter dapat bekerja bersama-sama dengan Yandex.Tank.
Kunci minusnya adalah konsumsi sumber daya dan kompleksitas persiapan tes.

Saran utama langsung pada JMeter: cobalah untuk menghindari penguraian badan halaman dengan kekuatannya, lebih baik menggunakan dataset yang sudah disiapkan sebelumnya untuk mereproduksi logika sesi. Pada prinsipnya, lebih baik meminimalkan pekerjaan yang dilakukan oleh JMeter secara umum. Seperti halnya Tank, dimungkinkan untuk memasang "cartridge" yang sudah dibuat sebelumnya. Di sinilah mereka perlu mempertimbangkan distribusi halaman tertentu dalam satu jenis, variabilitas permintaan, dan sebagainya.

Di JMeter sendiri, model perilaku pengguna perlu diprogram. Jika tugasnya adalah menguji tidak hanya bagian server, tetapi juga mengembalikan konten statis, jalankan pengujian ini secara terpisah menggunakan Phantom, jika perlu secara bersamaan dengan uji JMeter. Ini akan membantu secara signifikan mengurangi konsumsi sumber daya generator beban dan meningkatkan reproduktifitas pengujian.

Rekomendasi Pengujian Stres

Pengujian beban yang baik didasarkan pada analisis lalu lintas yang kompeten dan persiapan berkualitas tinggi dari model statistik dan profil untuk persaingan.

Sorot 5-7 jenis halaman utama (jangan lupa juga tentang halaman pendaratan untuk stok), hitung persentase total lalu lintas yang didistribusikan di antara mereka. Ingatlah bahwa mungkin ada beberapa permintaan konten dinamis per halaman. Bagi Anda, halaman tersebut adalah seluruh grup permintaan tersebut. Analisis berapa banyak waktu yang dihabiskan pengguna untuk setiap jenis halaman: rata-rata, minimum rata-rata, maksimum rata-rata.

Jika halaman dibuat berdasarkan beberapa permintaan, pertimbangkan penundaan di antaranya. Lihat berapa banyak halaman yang biasanya dikunjungi pengguna per sesi, berapa distribusi angka ini. Sorot 5-10 jalur pengguna yang paling umum berdasarkan jenis halaman.

Menggunakan data yang diperoleh, buat skenario sedemikian rupa untuk mereproduksi semua parameter statistik yang dijelaskan dengan sangat akurat. Jangan lupa tentang variabilitas skenario, skenario harus bervariasi dalam jumlah dan komposisi klik.

Dalam setiap jenis halaman, sorot setiap alamat. Semakin banyak, semakin baik, tetapi beberapa dari ribuan alamat yang paling populer sudah terlewatkan. Anda dapat menyiapkan daftar permintaan dari mereka dengan menambahkan setiap alamat ke daftar sebanyak yang Anda butuhkan.

Jika ada terlalu banyak halaman, bagilah menjadi beberapa kelompok sesuai dengan persentase lalu lintas.

Profil hanya berperan untuk JMeter, tetapi dengan membuat daftar permintaan, Anda dapat melengkapi kartrid "tangki".

Dan lagi: ketika menggunakan JMeter dalam mode emulasi pengguna, jangan lupa tentang keterlambatan antara permintaan. Jika Anda tidak menambahkannya, beban yang Anda hasilkan akan berkali-kali lebih tinggi dari yang direncanakan!

Setelah uji coba, pastikan untuk memeriksa log server web untuk melihat apakah lalu lintas yang ditiru produktif.

Aerobatik akan menyiapkan skrip terlebih dahulu untuk membawa database situs ke kondisi yang Anda butuhkan. Biasanya, data yang disiapkan dengan cara yang dijelaskan di atas hanya berfungsi dengan keadaan basis data di mana informasi tentang barang dikumpulkan. Mungkin sangat lama untuk memuat ulang dump SQL setiap waktu. Selain itu, sangat diinginkan untuk mempelajari cara mengelola saham yang sedang berjalan menggunakan skrip di area pengujian. Seringkali mereka penting untuk pengoperasian sistem, dan Anda perlu memahami dengan set apa dan bagaimana tepatnya stock yang bekerja diuji.

Apakah semuanya sudah siap? Bagus, silakan!

Kami menggunakan pemantauan dalam tes

Jadi, kami melakukan pengujian yang kompeten dan mendapatkan hasilnya. Jika semuanya baik-baik saja, dan situs Anda menghadapi beban yang tinggi, maka Black Friday tidak menakutkan untuk Anda. Tetapi artikel ini tidak akan lengkap jika kita tidak mempertimbangkan skenario realistis yang menyedihkan .

Bayangkan sebuah situs dapat bertahan dalam kecepatan yang dapat diterima ... yah, meskipun hanya seperlima dari apa yang ingin diperoleh bisnis. Apakah benar-benar perlu untuk memanggil hoster dalam kepanikan dan memesan kapasitas lima kali lebih banyak?

Pada prinsipnya, tuan rumah akan menyukai pendekatan ini. Anda bahkan mungkin mendapatkan status pelanggan emas.

Tapi sebelum bertindak gegabah, mari kita coba mencari tahu apa yang sebenarnya salah.

Pelampung hidup Anda di lautan kemungkinan penyebab adalah sistem pemantauan.



Oleh karena itu, kami mengambil langkah mundur dan memasang sampel sebanyak mungkin sebelum pengujian. Idealnya, semua sumber daya yang habis harus dipantau.

Di bawah ini adalah daftar untuk membantu Anda memulai:

• Beban CPU (Penggunaan CPU, Beban CPU);
• Memuat RAM;
• Pemuatan disk (IOPS, Latency);
• Jumlah koneksi jaringan (Waktu tunggu, Sirip tunggu, Tutup tunggu, Didirikan);
• Jumlah soket terbuka;
• Jumlah proses pengguna;
• Jumlah file yang terbuka;
• Lalu lintas jaringan (dalam megabit dan paket, plus kesalahan dan penurunan).

Dan juga:

• Jumlah pertanyaan, tanggapan, dan koneksi ke database dan komponen lainnya;
• Kecepatan respons komponen (database, server pencarian, cache, dll.);
• Semua log tersedia untuk kesalahan.

. , « ». , «» , .

, , .

- , : , HDD SSD. -, .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .