Josh Evans berbicara tentang dunia layanan mikro Netflix yang kacau dan penuh warna, dimulai dari hal paling mendasar - anatomi layanan mikro, tantangan yang terkait dengan sistem terdistribusi, dan manfaatnya. Berdasarkan landasan ini, ia mengeksplorasi praktik budaya, arsitektur, dan operasional yang mengarah pada penguasaan layanan mikro.
Berbeda dengan penyimpangan operasional, pengenalan bahasa baru untuk internasionalisasi layanan dan teknologi baru seperti kontainer merupakan keputusan sadar untuk menambah kompleksitas baru pada lingkungan. Tim operasi saya membuat standar peta jalan teknologi terbaik untuk Netflix, yang dimasukkan ke dalam praktik terbaik yang telah ditentukan berdasarkan Java dan EC2, namun seiring pertumbuhan bisnis, pengembang mulai menambahkan komponen baru seperti Python, Ruby, Node-JS, dan Docker.
Saya sangat bangga bahwa kami adalah orang pertama yang mengadvokasi agar produk kami berfungsi dengan baik tanpa menunggu keluhan pelanggan. Semuanya dimulai dengan cukup sederhana - kami memiliki program operasi dengan Python dan beberapa aplikasi back-office di Ruby, namun segalanya menjadi jauh lebih menarik ketika pengembang web kami mengumumkan bahwa mereka akan meninggalkan JVM dan akan memindahkan web aplikasi ke platform perangkat lunak Node.js. Setelah diperkenalkannya Docker, segalanya menjadi lebih kompleks. Kami mengikuti logika dan teknologi yang kami hasilkan menjadi kenyataan ketika kami menerapkannya kepada pelanggan karena teknologi tersebut sangat masuk akal. Saya akan memberi tahu Anda mengapa demikian.
API Gateway sebenarnya memiliki kemampuan untuk mengintegrasikan skrip hebat yang dapat bertindak sebagai titik akhir bagi pengembang UI. Mereka mengonversi setiap skrip ini sedemikian rupa sehingga setelah melakukan perubahan, mereka dapat menerapkannya ke produksi dan kemudian ke perangkat pengguna, dan semua perubahan ini disinkronkan dengan titik akhir yang berjalan di gateway API.
Namun, hal ini mengulangi masalah pembuatan monolit baru di mana layanan API kelebihan beban dengan kode sedemikian rupa sehingga terjadi berbagai skenario kegagalan. Misalnya, beberapa titik akhir telah dihapus, atau skrip secara acak menghasilkan begitu banyak versi dari sesuatu sehingga versi tersebut menghabiskan semua memori yang tersedia dari layanan API.
Adalah logis untuk mengambil titik akhir ini dan mengeluarkannya dari layanan API. Untuk melakukan ini, kami membuat komponen Node.js yang dijalankan sebagai aplikasi kecil di container Docker. Hal ini memungkinkan kami mengisolasi masalah dan kerusakan apa pun yang disebabkan oleh aplikasi node ini.
Biaya perubahan ini cukup besar dan terdiri dari faktor-faktor berikut:
- Alat produktivitas. Mengelola teknologi baru memerlukan alat baru karena tim UI, yang menggunakan skrip yang sangat bagus untuk membuat model yang efisien, tidak perlu menghabiskan banyak waktu untuk mengelola infrastruktur, mereka hanya perlu menulis skrip dan memeriksa fungsinya.
Wawasan dan Penyortiran Peluang - Contoh utamanya adalah alat baru yang diperlukan untuk mengungkap informasi pendorong kinerja. Penting untuk mengetahui seberapa banyak prosesor yang digunakan, bagaimana memori digunakan, dan pengumpulan informasi ini memerlukan alat yang berbeda. - Fragmentasi gambar dasar - AMI dasar sederhana menjadi lebih terfragmentasi dan terspesialisasi.
- Manajemen simpul. Tidak ada arsitektur atau teknologi siap pakai yang memungkinkan Anda mengelola node di cloud, jadi kami membangun Titus, platform manajemen kontainer yang menyediakan penerapan kontainer dan integrasi cloud yang skalabel dan andal dengan Amazon AWS.
- Duplikasi perpustakaan atau platform. Menyediakan teknologi baru dengan fungsionalitas inti yang sama dengan platform memerlukan duplikasi ke dalam alat pengembang Node.js berbasis cloud.
- Kurva pembelajaran dan pengalaman industri. Pengenalan teknologi baru pasti menciptakan tantangan baru yang harus diatasi dan dipelajari.
Oleh karena itu, kita tidak dapat membatasi diri pada satu “jalan beraspal” dan harus terus-menerus membangun cara-cara baru untuk memajukan teknologi kita. Untuk menekan biaya, kami membatasi dukungan terpusat dan fokus pada JVM, node baru, dan Docker. Kami memprioritaskan dampak yang efektif, memberikan informasi kepada tim mengenai dampak yang ditimbulkan dari keputusan mereka, dan mendorong mereka untuk mencari cara untuk menggunakan kembali solusi berdampak tinggi yang telah mereka kembangkan. Kami menggunakan pendekatan ini ketika menerjemahkan layanan ke bahasa asing untuk mengirimkan produk ke klien internasional. Contohnya termasuk pustaka klien yang relatif sederhana yang dapat dibuat secara otomatis, sehingga cukup mudah untuk membuat versi Python, versi Ruby, versi Java, dll.
Kami terus mencari peluang untuk menggunakan teknologi yang telah terbukti dan telah terbukti baik di satu tempat dan dalam situasi serupa lainnya.
Mari kita bicara tentang elemen terakhir - perubahan atau variasi. Lihatlah bagaimana konsumsi produk kita bervariasi secara tidak merata berdasarkan hari dalam seminggu dan berdasarkan jam sepanjang hari. Bisa dibilang jam 9 pagi adalah waktu tersulit bagi Netflix, saat beban sistem mencapai maksimal.
Bagaimana kita dapat mencapai implementasi inovasi perangkat lunak dengan kecepatan tinggi, yaitu terus-menerus membuat perubahan baru pada sistem, tanpa menyebabkan gangguan dalam pemberian layanan dan tanpa menimbulkan ketidaknyamanan bagi pelanggan kita? Netflix mencapai hal ini melalui penggunaan Spinnaker, platform manajemen dan pengiriman berkelanjutan (CD) berbasis cloud global baru.
Yang terpenting, Spinnaker dirancang untuk mengintegrasikan praktik terbaik kami sehingga saat kami menerapkan komponen ke dalam produksi, kami dapat mengintegrasikan hasilnya langsung ke dalam teknologi pengiriman media kami.
Kami mampu menggabungkan dua teknologi ke dalam jalur pengiriman yang sangat kami hargai: analisis canary otomatis dan penerapan bertahap. Analisis Canary berarti kita mengarahkan sedikit lalu lintas ke versi kode yang baru, dan meneruskan sisa lalu lintas produksi melalui versi lama. Kemudian kami memeriksa bagaimana kode baru mengatasi tugas tersebut - lebih baik atau lebih buruk daripada yang sudah ada.
Peluncuran bertahap berarti jika peluncuran di satu wilayah mengalami masalah, kami akan beralih ke peluncuran di wilayah lain. Dalam hal ini, daftar periksa yang disebutkan di atas harus disertakan dalam jalur produksi. Saya akan menghemat waktu Anda dan menyarankan Anda membaca ceramah saya sebelumnya, Rekayasa Operasi Netflix Global di Cloud, jika Anda tertarik untuk mendalami topik ini lebih dalam. Rekaman video pidato tersebut dapat dilihat dengan mengikuti link di bagian bawah slide.
Di akhir pembicaraan, saya akan membahas secara singkat tentang organisasi dan arsitektur Netflix. Pada awalnya kami memiliki skema yang disebut Pengiriman Elektronik, yang merupakan versi pertama dari media streaming NRDP 1.x. Istilah "backstream" dapat digunakan di sini karena pada awalnya pengguna hanya dapat mengunduh konten untuk diputar nanti di perangkat. Platform pengiriman digital pertama Netflix, pada tahun 2009, terlihat seperti ini.
Perangkat pengguna berisi aplikasi Netflix, yang terdiri dari antarmuka UI, modul keamanan, aktivasi dan pemutaran layanan, berdasarkan platform NRDP - Netflix Ready Device Platform.
Saat itu antarmuka penggunanya sangat sederhana. Itu berisi apa yang disebut Queque Reader, dan pengguna akan membuka situs untuk menambahkan sesuatu ke Queque dan kemudian melihat konten yang ditambahkan di perangkat mereka. Hal positifnya adalah tim front end dan tim back end tergabung dalam organisasi Pengiriman Elektronik yang sama dan memiliki hubungan kerja yang erat. Payload dibuat berdasarkan XML. Pada saat yang sama, API Netflix untuk bisnis DVD dibuat, yang mendorong aplikasi pihak ketiga untuk mengarahkan lalu lintas ke layanan kami.
Namun, API Netflix telah dipersiapkan dengan baik untuk membantu kami dengan antarmuka pengguna yang inovatif, berisi metadata semua konten, informasi tentang film apa yang tersedia, yang menciptakan kemampuan untuk menghasilkan daftar tontonan. Itu memiliki REST API generik berdasarkan skema JSON, Kode Respons HTTP, yang sama yang digunakan dalam arsitektur modern, dan model keamanan OAuth, yang diperlukan pada saat itu untuk aplikasi front-end. Hal ini memungkinkan peralihan dari model pengiriman konten streaming publik ke model pribadi.
Masalah dengan transisi ini adalah fragmentasi, karena sekarang sistem kami mengoperasikan dua layanan berdasarkan prinsip operasi yang sangat berbeda - satu pada Rest, JSON dan OAuth, yang lain pada RPC, XML dan mekanisme keamanan pengguna berdasarkan sistem token NTBA. Ini adalah arsitektur hybrid pertama.
Pada dasarnya terdapat firewall di antara kedua tim kami karena pada awalnya API tidak dapat diskalakan dengan baik dengan NCCP dan hal ini menyebabkan perselisihan antar tim. Perbedaannya terletak pada layanan, protokol, sirkuit, modul keamanan, dan pengembang sering kali harus beralih di antara konteks yang sangat berbeda.
Dalam hal ini, saya berbincang dengan salah satu insinyur senior perusahaan, yang saya ajukan pertanyaan: “Apa yang seharusnya menjadi arsitektur jangka panjang yang tepat?” dan dia mengajukan pertanyaan balasan: “Anda mungkin lebih khawatir tentang konsekuensi organisasional - apa yang terjadi jika kita mengintegrasikan hal-hal ini, dan hal-hal tersebut melanggar apa yang telah kita pelajari untuk dilakukan dengan baik? Pendekatan ini sangat relevan dengan Hukum Conway: "Organisasi yang merancang sistem dibatasi oleh desain yang mereplikasi struktur komunikasi organisasi tersebut." Ini adalah definisi yang sangat abstrak, jadi saya lebih memilih definisi yang lebih spesifik: “Perangkat lunak apa pun mencerminkan struktur organisasi yang menciptakannya.” Berikut kutipan favorit saya dari Eric Raymond: "Jika Anda memiliki empat tim pengembang yang mengerjakan sebuah kompiler, Anda akan mendapatkan kompiler empat jalur." Netflix memiliki kompiler empat jalur, dan begitulah cara kami bekerja.
Kita dapat mengatakan bahwa dalam hal ini ekornya mengibaskan anjing. Prioritas pertama kami bukanlah solusinya, namun organisasinya; organisasilah yang menggerakkan arsitektur yang kami miliki. Secara bertahap, dari layanan campur aduk, kami beralih ke arsitektur yang kami sebut Blade Runner, karena di sini kita berbicara tentang layanan edge dan kemampuan NCCP untuk dipisahkan dan diintegrasikan langsung ke proxy Zuul, gateway API, dan fungsi terkait. “Potongan” telah diubah menjadi layanan mikro baru dengan fitur keamanan, pemutaran ulang, penyortiran data, dll. yang lebih canggih.
Dengan demikian, dapat dikatakan bahwa struktur departemen dan dinamika perusahaan memainkan peran penting dalam membentuk desain sistem dan merupakan faktor yang mendorong atau menghambat perubahan. Arsitektur layanan mikro bersifat kompleks dan organik, dan kesehatannya didasarkan pada disiplin dan menimbulkan kekacauan.
Beberapa iklan
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com