Pertemuan kami bulan Juni dalam Test in Production didedikasikan untuk kekacauan rekayasa. Insinyur perangkat lunak utama Norah Jones mulai dengan bagaimana Netflix melakukan tes dalam produksi.
“Rekayasa kekacauan ... ini adalah eksperimen dalam produksi untuk menemukan kerentanan dalam suatu sistem sebelum mereka membuat layanan tidak cocok untuk pelanggan. Di Netflix, kami menjalankannya menggunakan alat yang disebut ChAP ... [itu] menangkap kerentanan dan memungkinkan kami menerapkan kegagalan dalam layanan dan produksi. Kegagalan ini mengkonfirmasi asumsi tentang layanan ini sebelum menyebabkan pemadaman penuh. "
Tonton presentasi (atau baca transkrip) tentang bagaimana timnya membantu pengguna - insinyur Netflix - dengan aman menguji produksi dan secara aktif mengidentifikasi kerentanan dalam sistem mereka.
Dekripsi
Saya sangat senang berada di sini hari ini.
Netflix aktif menggunakan tes dalam produksi. Kami melakukannya melalui chaos engineering, dan kami baru-baru ini mengganti nama tim kami Resiliance Engineering [pembangunan berkelanjutan] karena chaos engineering adalah salah satu cara untuk mencapai keberlanjutan secara keseluruhan. Saya akan membicarakan hal ini hari ini.
Tujuan kami adalah meningkatkan waktu kerja dengan secara proaktif mencari kerentanan dalam layanan. Kami melakukan ini melalui percobaan dalam produksi. Tim yakin bahwa kelas kerentanan dan masalah tertentu hanya dapat dideteksi pada lalu lintas nyata.
Pertama-tama, Anda harus menjaga keamanan dan pemantauan, jika tidak, Anda tidak akan dapat menggunakan tes normal dalam produksi. Tes semacam itu bisa menakutkan: jika mereka menakut-nakuti, Anda harus mendengarkan suara ini dan mencari tahu mengapa. Mungkin karena Anda tidak memiliki sistem keamanan yang baik. Atau karena tidak ada pemantauan yang baik. Dalam alat kami, kami sangat peduli tentang hal-hal ini.
Jika kita merumuskan teknik kekacauan dalam satu kalimat, maka ini adalah disiplin percobaan dalam produksi untuk menemukan kerentanan dalam sistem sebelum mereka membuat layanan tidak cocok untuk pelanggan. Di Netflix, kami menjalankannya menggunakan alat yang disebut ChAP, yang berarti Chaos Automation Platform (Chaos Automation Platform). ChAP menangkap kerentanan dan memungkinkan pengguna untuk mengimplementasikan kegagalan dalam layanan dan produksi. Kegagalan ini mengkonfirmasi asumsi pengguna tentang layanan ini sebelum menyebabkan pemadaman skala penuh.
Saya akan memberi tahu Anda bagaimana platform bekerja di level tinggi. Ini adalah set hipotesa dependensi layanan-mikro. Ada proxy tertentu. Ini mengirimkan permintaan ke layanan A, yang kemudian menyimpang tanpa kipas untuk layanan B, C dan D, dan masih ada tingkat kegigihan. Layanan D mengakses Cassandra, dan kemudian Layanan B mengakses cache.
Saya bergegas ke depan dan merangkum semuanya, karena esensi dimulai lebih jauh. Kami ingin memastikan bahwa layanan D kuat terhadap kegagalan cache. Pengguna memasuki antarmuka ChAP dan memilih layanan D sebagai layanan yang mengamati kegagalan cache dan layanan untuk kegagalan. ChAP sebenarnya mengkloning layanan B menjadi dua salinan. Kami menggunakannya untuk kontrol dalam kelompok eksperimen: dalam beberapa cara mereka bekerja seperti tes A / B atau tes kenari. Replika ini jauh lebih kecil daripada layanan B. Kami hanya mengirim persentase pelanggan yang sangat, sangat kecil ke kluster ini karena, jelas, kami tidak ingin kegagalan total. Kami menghitung persentase ini berdasarkan jumlah pengguna saat ini yang menggunakan layanan saat ini.
ChAP kemudian menginstruksikan sistem failover untuk menandai permintaan yang sesuai dengan kriteria kami. Ini dilakukan dengan menambahkan informasi ke header permintaan. Dua set tag dibuat. Di set pertama instruksi untuk kegagalan dan routing ke canary-replica, dan di kedua - hanya instruksi untuk routing ke elemen pemantauan.
Ketika klien RPC dan layanan A menerima instruksi yang diperlukan untuk merutekan permintaan, mereka sebenarnya mengarahkan lalu lintas ke cluster pemantauan atau cluster eksperimental. Kemudian, sistem implementasi kegagalan pada tingkat RPC dari gugus eksperimental melihat bahwa permintaan ditandai untuk kegagalan, dan mengembalikan respons yang gagal. Seperti sebelumnya, gugus eksperimental akan mengeksekusi kode untuk menangani kegagalan sebagai respons yang gagal dari cache. Kami melakukan ini dengan asumsi bahwa itu toleran terhadap kesalahan, bukan? Tetapi terkadang kita melihat bahwa ini tidak benar. Dari sudut pandang layanan A, semuanya tampak seperti perilaku normal.
Kami dengan hati-hati mengendalikan rekayasa kekacauan, yang bisa sangat buruk. Ketika Netflix pertama kali memulai eksperimen seperti itu, kami tidak memiliki sistem kontrol yang baik. Kami meluncurkan kesalahan artifisial dan duduk di ruangan itu, jari-jari menyilang dan memeriksa apakah semuanya bekerja dengan baik. Sekarang kami memiliki lebih banyak perhatian pada keamanan.
Kami melihat metrik bisnis utama. Salah satunya disebut SPS (streaming mulai per detik), yaitu mulai streaming video per detik. Jika Anda memikirkan apa yang paling penting untuk bisnis Netflix, itu adalah agar pengguna dapat menjalankan seri apa pun kapan pun mereka mau.
Dalam grafik, Anda melihat eksperimen nyata. Ini menunjukkan perbedaan dalam SPS antara kelompok eksperimen dan kontrol selama tes. Anda dapat melihat bahwa grafik sangat menyimpang dari satu sama lain, yang seharusnya tidak, karena persentase lalu lintas yang sama dikirim ke kedua cluster.
Untuk alasan ini, tes menggunakan analisis kenari otomatis. Ini memberi sinyal bahwa grafik sangat menyimpang satu sama lain. Dalam hal ini, tes segera terganggu sehingga orang dapat bekerja secara normal dengan situs tersebut. Dari sudut pandang pengguna, ini lebih seperti kesalahan jangka pendek ketika ini terjadi.
Kami memiliki banyak solusi lain. Kami membatasi volume lalu lintas pengujian di setiap wilayah, jadi kami tidak melakukan eksperimen hanya di zona US West 2. Kami melakukannya di mana-mana dan membatasi jumlah percobaan yang dapat dilakukan di kawasan itu sekaligus. Tes lulus hanya selama jam kerja, jadi kami tidak akan membangunkan insinyur jika terjadi kesalahan. Jika tes gagal, itu tidak dapat secara otomatis dimulai lagi sampai seseorang secara eksplisit memperbaikinya secara manual dan mengkonfirmasi: "Hei, saya tahu bahwa tes tidak lulus, tetapi saya memperbaiki semua yang diperlukan."
Dimungkinkan untuk menerapkan properti khusus ke kluster. Ini berguna jika layanan ini dibagi menjadi pecahan, seperti banyak layanan Netflix. Selain itu, Anda dapat menerapkan kegagalan berdasarkan jenis perangkat. Jika kami menganggap ada masalah pada perangkat Apple atau jenis TV tertentu, kami dapat melakukan tes khusus untuk mereka.
ChAP menemukan banyak bug. Ini salah satu favorit saya. Kami melakukan percobaan untuk memeriksa jalur cadangan layanan, yang sangat penting untuk ketersediaannya, dan mengidentifikasi bug di sana. Masalah ini dipecahkan sebelum menyebabkan insiden ketersediaan layanan. Ini adalah kasus yang sangat menarik, karena jalur cadangan ini tidak sering dilakukan. Karenanya, pengguna tidak benar-benar tahu apakah itu berfungsi dengan benar, dan kami dapat menirunya. Kami benar-benar menyebabkan kegagalan layanan dan memeriksa untuk melihat apakah itu berpihak dan apakah itu berfungsi dengan baik. Dalam hal ini, pengguna berpikir bahwa layanannya tidak kritis atau sekunder, tetapi sebenarnya itu adalah layanan kritis.
Ini adalah contoh lain. Kami melakukan percobaan untuk mereproduksi masalah selama proses pendaftaran, yang muncul pada malam hari di beberapa server. Sesuatu yang aneh sedang terjadi dengan layanan. Masalahnya direproduksi setelah memperkenalkan penundaan 500 milidetik. Selama pengujian, masalah ditemukan dalam log yang diunggah ke Portal Data Besar. Ini membantu untuk memahami mengapa dalam beberapa kasus pendaftaran tidak berfungsi. Hanya berkat eksperimen ChAP kami berhasil melihat apa yang terjadi dan mengapa.
Mengkonfigurasi tes CHAP memerlukan banyak informasi. Kami perlu mengetahui poin yang tepat untuk memperkenalkan bug. Tim harus menentukan apakah mereka ingin crash atau menunda. Itu semua tergantung pada titik injeksi. Anda dapat membuat crash Cassandra, Hystrix (sistem cadangan kami), layanan RPC, klien RPC, S3, SQS atau cache kami, atau menambahkan penundaan dari mereka. Atau lakukan keduanya. Anda juga dapat membuat kombinasi eksperimen yang berbeda.
Yang perlu Anda lakukan adalah berkumpul dengan tim layanan dan membuat tes yang bagus. Itu akan memakan banyak waktu. Saat menyiapkan percobaan, Anda juga harus menentukan konfigurasi ACA (Analisis Canary Otomatis) atau konfigurasi kenari otomatis.
Kami memiliki beberapa konfigurasi ACA yang sudah jadi. Ada satu konfigurasi ChAP untuk SPS. Ada satu dengan indikator sistem pemantauan. Satu lagi yang memeriksa crash RPS. Yang lain memastikan bahwa layanan kami benar-benar berfungsi dengan baik dan mengimplementasikan bug dengan benar. Kami menyadari bahwa merancang tes bisa sangat memakan waktu, dan itulah yang terjadi. Tidak banyak tes yang dibuat. Sulit bagi seseorang untuk mengingat semua yang diperlukan untuk percobaan yang baik. Kami memutuskan untuk mengotomatisasi sesuatu dengan CHAP. Kami melihat indikator: ke mana dan dari siapa panggilan pergi, file dengan timeout, panggilan berulang. Menjadi jelas bahwa semua informasi berasal dari tempat yang berbeda. Itu perlu untuk mengumpulkannya.
Kami meningkatkan analisis ke tingkat ChAP, di mana jauh lebih nyaman untuk bekerja dengan informasi dan Anda dapat menggunakan Monocle. Sekarang semua informasi tentang aplikasi dan cluster dapat dipelajari di satu tempat. Di sini, setiap baris mewakili ketergantungan, dan dependensi ini mewakili tempat berkembang biak untuk eksperimen rekayasa kekacauan.
Kami mengumpulkan semua informasi di satu tempat untuk pengembangan percobaan, tetapi tidak memahami bahwa agregasi seperti itu sangat berguna dalam dirinya sendiri, jadi ini adalah efek samping yang menarik. Anda dapat pergi di sini dan benar-benar melihat anti-pola yang terkait dengan layanan tertentu. Misalnya, ketergantungan terdeteksi yang tidak dianggap kritis, tetapi tidak memiliki rute mundur. Jelas, sekarang dia menjadi kritis. Orang bisa melihat ketidakcocokan batas waktu, ketidakcocokan panggilan balik. Kami menggunakan informasi ini untuk mengevaluasi kekritisan percobaan jenis tertentu dan memasukkannya ke dalam algoritma yang menentukan prioritas.
Setiap baris mewakili ketergantungan, dan garis-garis ini dapat diperluas. Ini adalah contoh yang menarik.
Di sini, garis biru di bagian atas menunjukkan batas waktu seseorang, dan garis ungu di bagian bawah menunjukkan runtime yang biasa. Seperti yang Anda lihat, ini sangat, sangat jauh dari batas waktu. Tetapi sebagian besar informasi ini tidak tersedia. Apa yang terjadi jika kita menjalankan tes tepat di bawah batas waktu? Apa yang kamu pikirkan Apakah dia akan lulus? Ini pertanyaan yang menarik. Kami berusaha memberikan tingkat detail ini kepada pengguna sebelum menjalankan tes sehingga mereka dapat menarik kesimpulan dan mengubah pengaturan.
Saya ingin memainkan permainan kecil. Ada kerentanan dalam layanan Netflix ini, cobalah untuk mendeteksinya. Tunggu sebentar dan lihat.
Untuk memberi Anda beberapa konteks, perintah Hystrix jauh berisi sampel-rest-client dan sample-rest-client.GET. Batas waktu Hystrix diatur ke 500 milidetik. Sample-rest-client.GET memiliki batas waktu 200 ms dengan satu coba lagi, yang bagus, karena totalnya adalah 400 milidetik, yang sesuai dengan batas Hystrix. Klien kedua memiliki batas waktu 100 dan 600 dengan satu coba lagi.
Dalam hal ini, coba lagi tidak dapat diselesaikan dengan mempertimbangkan batas waktu dari shell Hystrix, yaitu, Hystrix menolak permintaan sebelum klien dapat menerima tanggapan. Di sinilah letak kerentanannya. Kami memberikan informasi ini kepada pengguna. Menariknya, sebagian besar logika dalam implementasi fungsi-fungsi ini ada di tempat yang berbeda, dan sebelum mereka tidak dapat membandingkan hal-hal ini. Mereka pikir semuanya bekerja dengan baik, tapi ini bug.
Mengapa ini terjadi? Tentu saja, mudah bagi pengembang untuk melihat konflik dan mengubah batas waktu, kan? Tapi kami ingin mencari tahu alasannya. Kita dapat mengubah batas waktu, tetapi bagaimana kita dapat menjamin bahwa ini tidak akan terjadi lagi? Kami juga membantu mencari tahu alasannya.
Saat membuat tes otomatis, kami juga menggunakan Monocle. Pengguna membuat percobaan pada berbagai jenis data input. Kami mengambil semua ini dan mengotomatiskan pembuatan tes tersebut sehingga pengguna tidak repot. Kami secara otomatis membuat dan memprioritaskan eksperimen Hystrix dan percobaan RPC dengan penundaan dan kegagalan karena penundaan. Konfigurasi ACA ditambahkan secara default. Kami memiliki SPC, metrik sistem, statistik kueri, dan eksperimen berjalan secara otomatis. Prioritas untuk eksperimen juga dibuat. Algoritma tingkat tinggi bekerja untuk mereka. Kami menggunakan ember dengan statistik RPS. Kami menggunakan beberapa percobaan ulang dan perintah Hystrix terkait. Seluruh set ditimbang dengan tepat.
Selain itu, jumlah tim tanpa jalur eksekusi cadangan dan dampak eksternal apa pun (dampak yang dikuratori) yang ditambahkan oleh klien pada ketergantungan mereka diperhitungkan. Pengaruh eksternal sangat memengaruhi prosedur otorisasi, pendaftaran, dan SPS. Dan kami benar-benar mengukur efeknya dan tidak melakukan eksperimen jika hasilnya negatif. Kemudian tes diurutkan dan dijalankan dalam urutan kritikalitas menurun. Semakin tinggi skor kritikalitas, semakin awal dan semakin sering tes dimulai.
Ironisnya, Monocle memberi kami umpan balik yang memungkinkan kami menjalankan lebih sedikit tes dalam produksi. Kami melakukan begitu banyak tes sehingga sebagai hasilnya loop umpan balik terbentuk: kami melihat hubungan antara tes. Sekarang Anda dapat melihat file konfigurasi tertentu dan melihat pola anti-spesifik. Bahkan tanpa tes untuk informasi ini, dimungkinkan untuk memahami apa yang sebenarnya akan menyebabkan kegagalan, pada saat itu kami tidak memahami ini sebelumnya.
Ini telah menyebabkan tingkat keamanan baru. Sebelumnya, percobaan yang gagal ditandai sebagai terselesaikan. Sekarang ditandai sebagai diselesaikan sebelum meluncurkan kembali. Tetapi sekarang kita dapat secara eksplisit menambahkan pengaruh eksternal (kuratorial) pada kecanduan. Pengguna memasukkan Monocle-nya dan menunjukkan: faktor ini secara tepat memengaruhi prosedur otorisasi. Yang ini di SPC. Dan kami sedang mengerjakan siklus umpan balik, sehingga jika gagal, efek kuratorial seperti itu juga ditambahkan.
Dengan demikian, Monocle dalam ChAP adalah alat penting di mana semua informasi dikumpulkan, secara otomatis menghasilkan eksperimen, secara otomatis memprioritaskan dan mencari kerentanan sebelum mengarah ke penghentian skala penuh. Sebagai rangkuman, penting untuk mengingat mengapa kita terlibat dalam rekayasa kekacauan dan melakukan semua percobaan ini dalam produksi. Hal ini dilakukan untuk memahami bagaimana pelanggan menggunakan layanan ini, dan tidak melupakan mereka. Anda ingin memberi orang layanan yang paling nyaman. Jadi pemantauan dan keamanan adalah yang terpenting. Netflix harus selalu menampilkan video.
Terima kasih