- Halo! Saya akan memberi tahu Anda masalah apa yang harus Anda selesaikan ketika Anda perlu menyiapkan layanan Anda untuk beban beberapa ratus gigabit, atau bahkan terabit per detik. Kami pertama kali mengalami masalah seperti itu pada tahun 2018 ketika kami sedang mempersiapkan siaran Piala Dunia FIFA.
Mari kita mulai dengan apa itu protokol streaming dan bagaimana cara kerjanya - opsi gambaran umum paling dangkal.
Protokol streaming apa pun didasarkan pada manifes atau playlist. Ini adalah file teks kecil yang berisi informasi meta tentang konten. Ini menjelaskan jenis konten - siaran langsung atau siaran VoD (video on demand). Misalnya, dalam kasus siaran langsung itu adalah pertandingan sepak bola atau konferensi online, seperti yang kami lakukan sekarang dengan Anda, dan dalam kasus VoD, konten Anda disiapkan sebelumnya dan ada di server Anda, siap untuk didistribusikan ke pengguna. File yang sama menjelaskan durasi konten, informasi tentang DRM.
Ini juga menjelaskan variasi konten - trek video, trek audio, subtitle. Trek video dapat direpresentasikan dalam codec yang berbeda. Misalnya, universal H.264 didukung di perangkat apa pun. Dengan itu, Anda dapat memutar video di setrika apa pun di rumah Anda. Atau ada codec HEVC dan VP9 yang lebih modern dan lebih efisien yang memungkinkan Anda mentransfer 4K dengan dukungan HDR.
Trek audio juga dapat disajikan dalam codec berbeda dengan bitrate berbeda. Dan mungkin juga ada beberapa di antaranya - trek audio asli film dalam bahasa Inggris, terjemahan ke dalam bahasa Rusia, intershum, atau, misalnya, rekaman acara olahraga langsung dari stadion tanpa komentator.
Apa yang pemain lakukan dengan semua ini? Tugas pemain adalah, pertama-tama, memilih variasi konten yang dapat dimainkannya, karena tidak semua codec bersifat universal, tidak semua dapat dimainkan di perangkat tertentu.
Setelah itu, dia perlu memilih kualitas video dan audio yang akan dia putar. Dia dapat melakukan ini berdasarkan kondisi jaringan, jika dia mengetahuinya, atau berdasarkan beberapa heuristik yang sangat sederhana. Misalnya, mulai bermain dengan kualitas rendah dan, jika jaringan memungkinkan, tingkatkan resolusi secara perlahan.
Juga pada tahap ini, dia memilih trek audio yang akan dia mainkan. Misalkan Anda memiliki bahasa Inggris di sistem operasi Anda. Kemudian dia dapat memilih trek audio bahasa Inggris default. Mungkin akan lebih nyaman bagi Anda.
Setelah itu, ia mulai menghasilkan tautan ke segmen video dan audio. Faktanya, ini adalah tautan HTTP biasa, sama seperti di semua skenario lain di Internet. Dan dia mulai mengunduh segmen video dan audio, menempatkannya ke dalam buffer satu demi satu dan bermain dengan mulus. Segmen video seperti itu biasanya berdurasi 2, 4, 6 detik, mungkin 10 detik tergantung pada layanan Anda.
Apa poin penting di sini yang perlu kita pikirkan ketika kita mendesain CDN kita? Pertama-tama, kami memiliki sesi pengguna.
Kami tidak bisa begitu saja memberikan file kepada pengguna dan melupakan pengguna itu. Dia terus-menerus kembali dan mengunduh segmen baru dan baru ke buffernya.
Penting untuk dipahami di sini bahwa waktu respons server juga penting. Jika kami menayangkan siaran langsung dalam waktu nyata, maka kami tidak dapat membuat buffer yang besar hanya karena pengguna ingin menonton video sedekat mungkin dengan waktu nyata. Pada prinsipnya, buffer Anda tidak boleh besar. Karenanya, jika server tidak memiliki waktu untuk merespons sementara pengguna memiliki waktu untuk melihat konten, video akan berhenti di beberapa titik. Plus, kontennya cukup kelas berat. Bitrate standar untuk Full HD 1080p adalah 3-5 Mbps. Karenanya, di satu server gigabit, Anda tidak dapat melayani lebih dari 200 pengguna pada waktu yang sama. Dan ini adalah gambaran yang ideal, karena, sebagai aturan, pengguna tidak mengikuti permintaan mereka secara merata dari waktu ke waktu.
Pada titik manakah pengguna benar-benar berinteraksi dengan CDN Anda? Interaksi terjadi terutama di dua tempat: saat pemain mendownload manifes (playlist), dan saat mendownload segmen.
Kami telah berbicara tentang manifes, ini adalah file teks kecil. Tidak ada masalah khusus dengan distribusi file semacam itu. Jika Anda ingin, distribusikan dari setidaknya satu server. Dan jika itu adalah segmen, maka mereka menjadi mayoritas lalu lintas Anda. Kami akan membicarakannya.
Tugas seluruh sistem kami direduksi menjadi fakta bahwa kami ingin membentuk tautan yang benar ke segmen ini dan mengganti domain yang benar dari beberapa host CDN kami di sana. Pada titik ini, kami menggunakan strategi berikut: segera di daftar putar kami memberikan host CDN yang diinginkan, ke mana pengguna akan pergi. Pendekatan ini tanpa banyak kekurangan, tetapi memiliki satu nuansa penting. Anda perlu memastikan bahwa Anda memiliki mekanisme untuk mengalihkan pengguna dari satu host ke host lain dengan lancar selama pemutaran tanpa mengganggu pemutaran. Faktanya, semua protokol streaming modern memiliki kemampuan ini, baik HLS maupun DASH mendukungnya. Nuansa: cukup sering, bahkan di perpustakaan open source yang sangat populer, kemungkinan seperti itu tidak diterapkan, meskipun ada menurut standar. Kami sendiri harus mengirim bundel ke perpustakaan sumber terbuka Shaka,itu adalah javascript, digunakan untuk pemutar web, untuk memainkan DASH.
Ada satu skema lagi - skema anycast, saat Anda menggunakan satu domain dan memberikannya di semua tautan. Dalam hal ini, Anda tidak perlu memikirkan nuansa apa pun - Anda memberikan satu domain, dan semua orang senang. (...)
Sekarang mari kita bicara tentang bagaimana kita akan membentuk tautan kita.
Dari sudut pandang jaringan, setiap perusahaan besar diatur sebagai sistem otonom, dan seringkali bahkan bukan satu. Faktanya, sistem otonom adalah sistem jaringan IP dan router yang dikendalikan oleh satu operator dan menyediakan kebijakan perutean tunggal dengan jaringan eksternal, dengan Internet. Yandex tidak terkecuali. Jaringan Yandex juga merupakan sistem otonom, dan komunikasi dengan sistem otonom lainnya dilakukan di luar pusat data Yandex pada titik kehadiran. Kabel fisik dari Yandex, kabel fisik dari operator lain sampai ke titik-titik keberadaan ini, dan mereka dinyalakan di lokasi, pada peralatan besi. Pada titik inilah kami memiliki kesempatan untuk meletakkan beberapa server, hard drive, SSD kami. Di sinilah kami akan mengarahkan lalu lintas pengguna.
Kami akan menyebut kumpulan server ini sebagai lokasi. Dan di setiap lokasi tersebut, kami memiliki pengenal unik. Kami akan menggunakannya sebagai bagian dari nama domain host di situs ini dan hanya untuk mengidentifikasinya secara unik.
Ada beberapa lusin situs seperti itu di Yandex, ada beberapa ratus server di dalamnya, dan tautan dari beberapa operator datang ke setiap lokasi, jadi kami juga memiliki sekitar beberapa ratus tautan.
Bagaimana kita memilih lokasi mana untuk mengirim pengguna tertentu?
Tidak banyak pilihan pada tahap ini. Kami hanya dapat menggunakan alamat IP untuk membuat keputusan. Tim Lalu Lintas Yandex yang terpisah membantu kami dalam hal ini, yang mengetahui segalanya tentang cara kerja lalu lintas dan jaringan di perusahaan, dan dialah yang mengumpulkan rute operator lain sehingga kami dapat menggunakan pengetahuan ini dalam proses menyeimbangkan pengguna.
Ini mengumpulkan satu set rute menggunakan BGP. Kami tidak akan membicarakan BGP secara rinci, ini adalah protokol yang memungkinkan peserta jaringan di perbatasan sistem otonom mereka untuk mengumumkan rute apa yang dapat dilayani oleh sistem otonom mereka. Tim Lalu Lintas mengumpulkan semua informasi ini, mengumpulkan, menganalisis, dan membuat peta lengkap dari seluruh jaringan, yang kami gunakan untuk menyeimbangkan.
Kami menerima dari Tim Lalu Lintas satu set jaringan IP dan tautan yang melaluinya kami dapat melayani klien. Selanjutnya, kita perlu memahami subnet IP mana yang cocok untuk pengguna tertentu.
Kami melakukan ini dengan cara yang cukup sederhana - kami membangun pohon awalan. Dan kemudian tugas kita adalah menggunakan alamat IP pengguna sebagai kunci untuk menemukan subnet mana yang paling cocok dengan alamat IP ini.
Ketika kami menemukannya, kami memiliki daftar tautan, bobotnya, dan berdasarkan tautan kami dapat secara unik menentukan lokasi di mana kami akan mengirim pengguna.
Berapakah beban di tempat ini? Ini adalah metrik yang memungkinkan Anda mengelola distribusi pengguna di berbagai lokasi. Kita dapat memiliki tautan, misalnya, dengan kapasitas berbeda. Kami dapat memiliki tautan 100 Gigabit dan tautan 10 Gigabit di situs yang sama. Tentunya, kami ingin mengirim lebih banyak pengguna ke tautan pertama, karena lebih luas. Bobot ini memperhitungkan topologi jaringan, karena Internet adalah grafik kompleks dari peralatan jaringan yang saling berhubungan, lalu lintas Anda dapat melalui jalur yang berbeda, dan topologi ini juga harus diperhitungkan.
Pastikan untuk memperhatikan bagaimana pengguna sebenarnya mengunduh data. Ini dapat dilakukan di sisi server dan klien. Di server, kami secara aktif mengumpulkan koneksi pengguna di log info TCP, melihat waktu bolak-balik. Dari sisi pengguna, kami secara aktif mengumpulkan log kinerja browser dan pemain. Log kinerja ini berisi informasi rinci tentang bagaimana file diunduh dari CDN kami.
Jika kita menganalisis semua ini, agregat, maka dengan bantuan data ini kita dapat meningkatkan bobot yang dipilih pada tahap pertama oleh Tim Lalu Lintas.
Katakanlah kami telah memilih tautan. Bisakah kami mengirim pengguna ke sana tepat pada tahap ini? Kami tidak dapat melakukannya, karena beratnya cukup statis dalam jangka waktu yang lama, dan tidak memperhitungkan dinamika nyata dari beban tersebut. Kami ingin menentukan secara real time apakah kami sekarang dapat menggunakan tautan yang, katakanlah, 80% dimuat, ketika ada tautan prioritas yang sedikit lebih rendah di dekatnya yang hanya dimuat 10%. Kemungkinan besar, dalam hal ini, kami hanya ingin menggunakan yang kedua.
Apa lagi yang perlu diperhatikan di tempat ini? Kita harus memperhitungkan bandwidth tautan, memahami statusnya saat ini. Ini mungkin berfungsi atau rusak secara teknis. Atau mungkin kita ingin membawanya ke layanan agar tidak membiarkan pengguna pergi ke sana dan melayaninya, mengembangkannya, misalnya. Kami harus selalu memperhitungkan beban tautan ini saat ini.
Ada beberapa nuansa menarik disini. Anda dapat mengumpulkan informasi tentang pemuatan tautan di beberapa titik - misalnya, tentang peralatan jaringan. Ini adalah cara yang paling akurat, tetapi masalahnya adalah pada peralatan jaringan Anda tidak bisa mendapatkan periode pembaruan yang cepat untuk unduhan ini. Misalnya, di Yandex, peralatan jaringan cukup bervariasi, dan kami tidak dapat mengumpulkan data ini lebih dari sekali dalam satu menit. Jika sistem cukup stabil dalam hal beban, hal ini tidak menjadi masalah sama sekali. Semuanya akan bekerja dengan baik. Tetapi begitu Anda tiba-tiba masuk beban, Anda tidak punya waktu untuk bereaksi, dan ini mengarah, misalnya, untuk mengemas penurunan.
Di sisi lain, Anda tahu berapa banyak byte yang dikirim ke pengguna. Anda dapat mengumpulkan informasi ini di mesin pendistribusi itu sendiri, membuat penghitung byte secara langsung. Tapi itu tidak akan akurat. Mengapa?
Ada pengguna lain di CDN kami. Kami bukan satu-satunya layanan yang menggunakan mesin dispensing ini. Dan dengan latar belakang beban kami, beban layanan lain tidak begitu signifikan. Tetapi bahkan dengan latar belakang kita, itu bisa sangat terlihat. Distribusi mereka tidak melalui sirkuit kami, jadi kami tidak dapat mengontrol lalu lintas ini.
Poin lain: bahkan jika Anda berpikir di mesin pengirim bahwa Anda telah mengirim lalu lintas ke satu tautan tertentu, ini jauh dari fakta, karena BGP sebagai protokol tidak memberi Anda jaminan seperti itu. Dan ada cara untuk meningkatkan kemungkinan Anda akan menebak, tapi itu adalah topik untuk diskusi lain.
Katakanlah kita menghitung metrik, mengumpulkan semuanya. Sekarang kita membutuhkan algoritma untuk membuat keputusan saat menyeimbangkan. Ini harus memiliki empat properti penting:
- Sediakan bandwidth tautan.
- Cegah link overload, hanya karena jika Anda telah memuat link pada 95% atau 98%, maka buffer pada peralatan jaringan mulai meluap, paket turun, transmisi ulang dimulai, dan pengguna tidak mendapatkan hasil yang baik dari ini.
- Untuk memperingatkan beban "minum", kita akan membicarakannya nanti.
“Di dunia yang ideal, akan sangat bagus jika kita bisa belajar mendaur ulang tautan ke tingkat tertentu yang menurut kami benar. Misalnya, 85% mengunduh.
Kami mengambil ide berikut sebagai dasar. Kami memiliki dua kelas sesi pengguna yang berbeda. Kelas pertama adalah sesi baru, ketika pengguna baru saja membuka film, belum menonton apa pun, dan kami mencoba mencari tahu ke mana harus mengirimkannya. Atau kelas kedua, ketika kita memiliki sesi saat ini, pengguna sudah dilayani di link, menempati bagian tertentu dari bandwidth, dilayani di server tertentu.
Apa yang akan kita lakukan dengan mereka? Kami memperkenalkan satu nilai probabilistik untuk setiap kelas sesi tersebut. Kami akan memiliki nilai yang disebut Perlambatan, yang menentukan persentase sesi baru yang tidak akan kami izinkan di tautan ini. Jika Perlambatan nol, maka kami menerima semua sesi baru, dan jika 50%, maka setiap, secara kasar, sesi kedua kami menolak untuk ditayangkan di tautan ini. Pada saat yang sama, algoritme penyeimbangan kami di tingkat yang lebih tinggi akan memeriksa alternatif untuk pengguna ini. Jatuhkan - sama, hanya untuk sesi saat ini. Kami dapat mengambil beberapa sesi pengguna dari situs di tempat lain.
Bagaimana kita memilih berapa nilai metrik probabilistik kita nantinya? Kami akan mengambil persentase pemuatan tautan sebagai dasar, dan kemudian ide pertama kami adalah ini: mari gunakan interpolasi linier sedikit demi sedikit.
Kami mengambil fungsi seperti itu, yang memiliki beberapa titik refraksi, dan kami melihat nilai koefisien kami menggunakannya. Jika tingkat unduhan tautan minimal, maka semuanya baik-baik saja, Perlambatan dan Penurunan sama dengan nol, kami membiarkan semua pengguna baru masuk. Segera setelah tingkat pemuatan melampaui ambang tertentu, kami mulai menolak layanan untuk beberapa pengguna di tautan ini. Di beberapa titik, jika beban terus bertambah, kami berhenti meluncurkan sesi baru.
Ada nuansa menarik di sini: sesi saat ini mendapat prioritas dalam skema ini. Saya pikir sudah jelas mengapa hal ini terjadi: jika pengguna Anda sudah memberi Anda pola beban yang stabil, Anda tidak ingin membawanya kemana-mana, karena dengan cara ini Anda meningkatkan dinamika sistem, dan semakin stabil sistem, semakin mudah bagi kami untuk mengontrolnya.
Namun, unduhan mungkin terus bertambah. Pada titik tertentu, kami dapat mulai menghapus beberapa sesi atau bahkan menghapus sepenuhnya beban dari tautan ini.
Dalam bentuk inilah kami meluncurkan algoritme ini di pertandingan pertama Piala Dunia FIFA. Mungkin menarik untuk melihat gambar apa yang kami lihat. Dia tentang berikut ini.
Bahkan dengan mata telanjang, pengamat luar dapat memahami bahwa mungkin ada sesuatu yang salah di sini dan bertanya kepada saya: "Andrey, apakah kamu baik-baik saja?" Dan jika Anda adalah bos saya, Anda akan berlarian ke sekeliling ruangan dan berteriak: “Andrey, my God! Gulung semuanya kembali! Kembalikan semuanya apa adanya! " Mari beri tahu Anda apa yang terjadi di sini.
Pada sumbu X waktu, pada sumbu Y kami mengamati tingkat beban tautan. Ada dua tautan yang melayani situs yang sama. Penting untuk dipahami bahwa saat ini kami hanya menggunakan skema pemantauan beban tautan yang dikeluarkan dari peralatan jaringan, dan oleh karena itu tidak dapat dengan cepat merespons dinamika beban.
Saat kami mengirim pengguna ke salah satu tautan, ada peningkatan tajam dalam lalu lintas di tautan itu. Tautan kelebihan beban. Kami melepas beban dan menemukan diri kami berada di sisi kanan fungsi yang kami lihat di grafik sebelumnya. Dan kami mulai menghapus pengguna lama dan berhenti mengizinkan pengguna baru. Mereka harus pergi ke suatu tempat, dan mereka, tentu saja, ke tautan berikutnya. Terakhir kali ini mungkin menjadi prioritas yang lebih rendah, tetapi sekarang mereka memiliki prioritas.
Tautan kedua mengulangi gambar yang sama. Kami secara tajam meningkatkan beban, perhatikan bahwa tautan kelebihan beban, menghapus beban, dan kedua tautan ini berada di antiphase dalam hal tingkat beban.
Apa yang bisa dilakukan? Kita dapat menganalisis dinamika sistem, perhatikan ini dengan peningkatan beban yang besar dan sedikit meredamnya. Inilah yang kami lakukan. Kami mengambil momen saat ini, mengambil jendela observasi ke masa lalu selama beberapa menit, misalnya 2-3 menit, dan melihat seberapa besar perubahan beban tautan dalam interval ini. Perbedaan antara nilai minimum dan maksimum akan disebut interval osilasi tautan ini. Dan jika interval osilasi ini besar, kami akan menambahkan redaman, sehingga meningkatkan Perlambatan kami dan mulai menjalankan lebih sedikit sesi.
Fungsi ini terlihat hampir sama dengan fungsi sebelumnya, dengan fraktur yang sedikit lebih sedikit. Jika kami memiliki interval kecil untuk mengunduh osilasi, maka kami tidak akan menambahkan extra_slowdown. Dan jika interval osilasi mulai bertambah, maka extra_slowdown mengambil nilai bukan nol, nanti kita akan menambahkannya ke Slowdown utama.
Logika yang sama bekerja pada nilai rendah dari interval osilasi. Jika Anda memiliki sedikit keraguan pada tautan, maka, sebaliknya, Anda ingin membiarkan lebih banyak pengguna di sana, turunkan Perlambatan dan dengan demikian lebih baik gunakan tautan Anda.
Kami juga telah menerapkan bagian ini. Rumus akhirnya terlihat seperti ini. Pada saat yang sama, kami menjamin bahwa kedua nilai ini - extra_slowdown dan reduce_slowdown - tidak pernah memiliki nilai selain nol pada saat yang sama, jadi hanya satu yang berfungsi secara efektif. Dalam bentuk inilah formula penyeimbang ini bertahan di semua pertandingan teratas Piala Dunia FIFA. Bahkan di pertandingan paling populer, dia bekerja dengan cukup baik: ini adalah "Rusia - Kroasia", "Rusia - Spanyol". Selama pertandingan ini, kami mendistribusikan catatan untuk volume lalu lintas Yandex - 1,5 terabit per detik. Kami melewatinya dengan tenang. Sejak itu, formula tidak berubah sama sekali, karena tidak ada lalu lintas seperti itu di layanan kami sejak saat itu - hingga saat tertentu.
Kemudian pandemi datang kepada kami. Orang-orang disuruh duduk di rumah, dan di rumah ada internet yang bagus, TV, tablet, dan banyak waktu luang. Lalu lintas ke layanan kami mulai tumbuh secara organik, agak cepat dan signifikan. Sekarang beban seperti ini, seperti yang terjadi selama Piala Dunia, adalah rutinitas harian kami. Sejak saat itu kami telah sedikit memperluas saluran kami dengan operator, namun demikian, kami mulai memikirkan tentang pengulangan berikutnya dari algoritme kami, apa yang seharusnya dan bagaimana kami dapat memanfaatkan jaringan kami dengan lebih baik.
Apa kerugian dari algoritma kami sebelumnya? Kami belum memecahkan dua masalah. Kami belum sepenuhnya menyingkirkan beban "gergaji". Kami telah meningkatkan gambar secara signifikan dan amplitudo fluktuasi ini minimal, periode telah meningkat pesat, yang juga memungkinkan pemanfaatan jaringan yang lebih baik. Tapi tetap saja mereka muncul dari waktu ke waktu. Kami belum belajar bagaimana memanfaatkan jaringan ke tingkat yang kami inginkan. Misalnya, kami tidak dapat menggunakan konfigurasi untuk menyetel tingkat beban tautan maksimum yang diinginkan sebesar 80-85%.
Pemikiran apa yang kita miliki untuk iterasi algoritme berikutnya? Bagaimana kita membayangkan pemanfaatan jaringan yang ideal? Tampaknya, salah satu bidang yang menjanjikan adalah opsi bila Anda memiliki satu tempat untuk membuat keputusan tentang lalu lintas. Anda mengumpulkan semua metrik di satu tempat, permintaan pengguna untuk mengunduh segmen datang ke sana, dan setiap saat Anda memiliki sistem yang lengkap, sangat mudah bagi Anda untuk membuat keputusan.
Namun ada dua nuansa di sini. Pertama, di Yandex tidak lazim untuk menulis "poin pengambilan keputusan umum", hanya karena dengan tingkat pemuatan kami, dengan lalu lintas kami, tempat seperti itu dengan cepat menjadi penghambat.
Ada satu nuansa lagi - di Yandex, penting juga untuk menulis sistem yang toleran terhadap kesalahan. Kami sering kali menutup pusat data sepenuhnya, sementara komponen Anda harus terus berfungsi tanpa kesalahan, tanpa gangguan. Dan dalam bentuk ini, tempat tunggal ini menjadi, pada kenyataannya, sistem terdistribusi yang perlu Anda kendalikan, dan ini adalah tugas yang sedikit lebih sulit daripada yang ingin kami selesaikan di tempat ini.
Kami pasti membutuhkan metrik cepat. Tanpa mereka, satu-satunya hal yang dapat Anda lakukan untuk menghindari penderitaan pengguna adalah dengan kurang memanfaatkan jaringan. Tapi itu juga tidak cocok untuk kita.
Jika Anda melihat sistem kami pada tingkat tinggi, jelaslah bahwa sistem kami adalah sistem dinamis dengan umpan balik. Kami memiliki beban khusus, yang merupakan sinyal input. Orang datang dan pergi. Kami memiliki sinyal kontrol - dua nilai yang dapat kami ubah secara real time. Untuk sistem dinamis dengan umpan balik seperti itu, teori kendali otomatis telah dikembangkan untuk waktu yang lama, beberapa dekade. Dan komponennya itulah yang ingin kami gunakan untuk menstabilkan sistem kami.
Kami melihat filter Kalman. Ini adalah hal yang sangat keren yang memungkinkan Anda untuk membangun model matematika dari sistem dan, dengan metrik yang berisik atau dengan tidak adanya beberapa kelas metrik, tingkatkan model tersebut menggunakan sistem Anda yang sebenarnya. Dan kemudian membuat keputusan tentang sistem nyata berdasarkan model matematika. Sayangnya, ternyata kami tidak memiliki banyak kelas metrik yang dapat kami gunakan, dan algoritme ini tidak dapat diterapkan.
Kami mendekati dari sisi lain, kami mengambil sebagai dasar komponen lain dari teori ini - pengontrol PID. Dia tidak tahu apa-apa tentang sistem Anda. Tugasnya adalah untuk mengetahui keadaan ideal sistem, yaitu tingkat beban yang kita inginkan, dan keadaan sistem saat ini, misalnya, tingkat beban. Dia menganggap perbedaan antara kedua kondisi ini sebagai kesalahan dan, menggunakan algoritme internalnya, mengelola sinyal kontrol, yaitu nilai Perlambatan dan Penurunan kami. Tujuannya untuk meminimalkan kesalahan pada sistem.
Kami akan mencoba pengontrol PID ini dalam produksi dari hari ke hari. Mungkin dalam beberapa bulan lagi kami bisa memberi tahu Anda tentang hasilnya.
Dalam hal ini kita mungkin akan menyelesaikan tentang jaringan. Saya sangat ingin memberi tahu Anda tentang bagaimana kami mendistribusikan lalu lintas di dalam lokasi itu sendiri, ketika kami telah memilihnya di antara host. Tapi tidak ada waktu untuk itu. Ini mungkin topik untuk laporan besar yang terpisah.
Oleh karena itu, di seri berikutnya, Anda akan belajar bagaimana memanfaatkan cache pada host secara optimal, apa yang harus dilakukan dengan lalu lintas panas dan dingin, serta dari mana lalu lintas hangat berasal, bagaimana jenis konten memengaruhi algoritme untuk distribusinya dan video mana yang memberikan cache tertinggi pada layanan, dan siapa siapa yang menyanyikan sebuah lagu.
Saya punya cerita menarik lainnya. Di musim semi, seperti yang Anda ketahui, karantina dimulai. Yandex telah lama memiliki platform pendidikan bernama Yandex.Tutorial, yang memungkinkan guru mengunggah video dan pelajaran. Siswa datang ke sana dan menonton isinya. Selama pandemi, Yandex mulai mendukung sekolah, secara aktif mengundang mereka ke platformnya sehingga siswa dapat belajar dari jarak jauh. Dan di beberapa titik kami melihat pertumbuhan lalu lintas yang cukup baik, gambaran yang cukup stabil. Tetapi pada salah satu malam di bulan April, kami melihat sesuatu seperti berikut ini di tangga lagu.
Di bawah ini adalah gambar traffic pada konten pendidikan. Kami melihat bahwa dia jatuh tajam di beberapa titik. Kami mulai panik, mencari tahu apa yang terjadi secara umum, apa yang rusak. Kemudian kami melihat bahwa lalu lintas total ke layanan mulai meningkat. Jelas, sesuatu yang menarik telah terjadi.
Padahal, pada saat itulah hal-hal berikut terjadi.
Ini adalah seberapa cepat pria itu menari.
Konser Little Big dimulai, dan semua siswa pergi untuk menontonnya. Namun setelah konser berakhir, mereka kembali dan berhasil melanjutkan studi lebih lanjut. Kami cukup sering melihat gambar seperti itu di layanan kami. Oleh karena itu, menurut saya pekerjaan kami cukup menarik. Terimakasih untuk semua! Saya mungkin akan mengakhiri dengan ini tentang CDN.