Prinsip ketidakpastian Heisenberg menyatakan bahwa tidak mungkin secara simultan mengukur posisi suatu objek dan kecepatannya. Jika suatu objek bergerak, maka ia tidak memiliki lokasi. Dan jika lokasinya, berarti ia tidak memiliki kecepatan.
Sedangkan untuk layanan microser pada platform Red Hat OpenShift (dan menjalankan Kubernetes), berkat perangkat lunak open-source yang sesuai, mereka dapat secara bersamaan melaporkan kinerja dan kesehatannya. Tentu saja, ini tidak membantah Heisenberg lama, tetapi menghilangkan ketidakpastian ketika bekerja dengan aplikasi cloud. Istio memudahkan untuk mengatur pelacakan (tracing) dan pemantauan aplikasi semacam itu untuk menjaga semuanya tetap terkendali.
Tentukan terminologi
Yang kami maksud dengan
tracing adalah aktivitas sistem logging. Kedengarannya cukup umum, tetapi sebenarnya salah satu aturan utama di sini adalah untuk membuang data jejak ke penyimpanan yang sesuai tanpa khawatir memformatnya. Dan semua pekerjaan mencari dan menganalisis data dipercayakan kepada konsumen mereka. Istio menggunakan sistem jejak Jaeger, yang mengimplementasikan model data OpenTracing.
Dengan jejak (Jejak, dan kata "jejak" digunakan di sini dalam arti "jejak", seperti, misalnya, dalam pemeriksaan balistik) kami akan berarti data yang sepenuhnya menggambarkan bagian dari permintaan atau unit kerja, seperti yang mereka katakan, "dari dan ke". Sebagai contoh, segala sesuatu yang terjadi dari saat pengguna menekan tombol pada halaman web hingga saat data dikembalikan, termasuk semua layanan microser yang terlibat dalam hal ini. Kita dapat mengatakan bahwa satu jejak sepenuhnya menggambarkan (atau mensimulasikan) bagian dari permintaan bolak-balik. Di antarmuka Jaeger, trek didekomposisi menjadi komponen di sepanjang sumbu waktu, seperti bagaimana rantai dapat didekomposisi menjadi tautan yang terpisah. Hanya alih-alih tautan, trek terdiri dari bentang yang disebut.
Rentang adalah interval dari awal unit kerja hingga penyelesaiannya. Melanjutkan analoginya, kita dapat mengatakan bahwa setiap rentang adalah tautan terpisah dalam rantai. Suatu rentang mungkin atau mungkin tidak memiliki satu atau lebih rentang anak. Akibatnya, rentang tingkat atas (rentang akar) akan memiliki durasi total yang sama dengan jejak yang dimiliki.
Sebenarnya,
pemantauan adalah pengamatan sistem Anda - melalui mata, melalui UI atau melalui otomatisasi. Pemantauan didasarkan pada data jejak. Di Istio, pemantauan dilaksanakan menggunakan alat Prometheus dan memiliki UI yang sesuai. Prometheus mendukung pemantauan otomatis menggunakan Lansiran dan Lansiran Manajer Lansiran.
Tinggalkan goresannya
Agar pelacakan dimungkinkan, aplikasi harus membuat koleksi rentang. Kemudian mereka harus diekspor ke Jaeger sehingga pada gilirannya menciptakan representasi visual dari jejak tersebut. Antara lain, rentang ini menandai nama operasi, serta cap waktu awal dan akhir. Rentang dikirim dengan meneruskan header Jaeger untuk permintaan HTTP dari permintaan masuk ke permintaan keluar. Bergantung pada bahasa pemrograman yang digunakan, ini mungkin memerlukan sedikit modifikasi dari kode sumber aplikasi. Berikut ini adalah contoh kode Java (saat menggunakan kerangka Boot Spring) yang menambahkan header B3 (gaya Zipkin) ke permintaan Anda di kelas konfigurasi Spring:
Pengaturan tajuk berikut digunakan:
Jika Anda menggunakan Java, Anda dapat membiarkan kode tidak tersentuh, cukup tambahkan beberapa baris ke file POM Maven dan tetapkan variabel lingkungan. Berikut adalah baris yang perlu Anda tambahkan ke file POM.XML untuk mengimplementasikan Jaeger Tracer Resolver:
Dan variabel lingkungan yang sesuai diatur di Dockerfile:
Itu saja, sekarang semuanya sudah diatur, dan layanan microser kami akan mulai menghasilkan data jejak.
Kami melihat secara umum
Istio termasuk panel kontrol sederhana berdasarkan Grafana. Ketika semuanya dikonfigurasi dan berjalan pada platform Red Hat OpenShift PaaS (dalam contoh kami, Red Hat OpenShift dan Kubernetes digunakan pada minishift), panel ini diluncurkan dengan perintah berikut:
open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"
Panel Grafana memungkinkan Anda untuk dengan cepat mengevaluasi sistem. Sebuah fragmen dari panel ini ditunjukkan pada gambar di bawah ini:
Di sini Anda dapat melihat bahwa pelanggan microservice memanggil preferensi microservice v1, dan yang pada gilirannya memanggil rekomendasi layanan microser v1 dan v2. Panel Grafana memiliki blok Baris Dasbor untuk metrik tingkat tinggi, seperti jumlah total permintaan (Volume Permintaan Global), persentase permintaan yang berhasil (tingkat keberhasilan), kesalahan 4xx. Selain itu, ada tampilan Server Mesh dengan grafik untuk setiap layanan dan blok Baris Layanan untuk melihat informasi terperinci untuk setiap wadah untuk setiap layanan.
Sekarang gali lebih dalam
Dengan jejak yang dikonfigurasi dengan benar, Istio, seperti yang mereka katakan, langsung dari kotak memungkinkan Anda untuk mempelajari analisis kinerja sistem. Di Jaeger UI, Anda bisa melihat jejak dan melihat seberapa jauh dan dalam mereka pergi, serta secara visual melokalisasi kemacetan kinerja. Saat menggunakan Red Hat OpenShift pada platform minishift, luncurkan Jaeger UI menggunakan perintah berikut:
minishift openshift service jaeger-query --in-browser
Apa yang bisa dikatakan tentang jejak di layar ini:
- Ini dibagi menjadi 7 rentang.
- Total waktu eksekusi adalah 6,99 ms.
- Rekomendasi microservice, yang merupakan yang terakhir dalam rantai, membutuhkan 0,69 ms.
Diagram jenis ini memungkinkan Anda mengetahui dengan cepat situasi di mana kinerja seluruh sistem menderita karena satu layanan yang kurang berfungsi.
Sekarang mari kita mempersulit tugas dan meluncurkan dua contoh dari microservice rekomendasi: v2 dengan skala oc --replicas = 2 deployment / recommendation-v2 command. Berikut adalah pod yang akan kita miliki setelah ini:
Jika sekarang kita beralih kembali ke Jaeger dan menggunakan rentang untuk layanan rekomendasi, kita akan melihat permintaan pod yang dialihkan. Dengan demikian, kami dapat dengan mudah melokalisasi rem pada level pod tertentu. Anda harus melihat bidang node_id:
Kemana dan bagaimana semuanya berjalan
Sekarang kita pergi ke antarmuka Prometheus dan sangat diharapkan kita melihat di sana bahwa permintaan antara versi kedua dan pertama dari layanan rekomendasi dibagi dalam rasio 2: 1, ketat oleh jumlah pod yang berfungsi. Selain itu, grafik ini akan berubah secara dinamis saat menskala pod ke atas dan ke bawah, yang akan sangat berguna dengan Canary Deployment (kami akan memeriksa skema penyebaran ini secara lebih rinci di lain waktu).
Itu baru permulaan
Bahkan, hari ini, seperti yang mereka katakan, kami hanya sedikit menyentuh gudang informasi yang berguna tentang Jaeger, Grafana, dan Prometheus. Secara umum, ini adalah tujuan kami - untuk membimbing Anda ke arah yang benar dan membuka prospek Istio.
Dan ingat, semua ini sudah dibangun ke dalam Istio. Saat menggunakan bahasa pemrograman tertentu (misalnya, Java) dan kerangka kerja (misalnya, Spring Boot) semua ini dapat direalisasikan tanpa sepenuhnya menyentuh kode aplikasi itu sendiri. Ya, kode harus sedikit dimodifikasi jika Anda menggunakan bahasa lain, terutama Nodejs atau C #. Tetapi karena ketertelusuran (baca, “penelusuran”) adalah salah satu prasyarat untuk membuat sistem cloud yang andal, dalam hal apa pun, Anda harus mengedit kode apakah Anda memiliki Istio atau tidak. Jadi mengapa tidak menghabiskan upaya lebih menguntungkan?
Setidaknya agar selalu menjawab pertanyaan "di mana?" Dan "seberapa cepat?" Dengan kepastian 100%.
Rekayasa Kekacauan di Istio: Itu Dikandung
Kemampuan untuk memecahkan barang-barang membantu memastikan bahwa barang-barang itu tidak rusak
Pengujian perangkat lunak bukan hanya hal yang rumit, tetapi juga yang penting. Pada saat yang sama, pengujian untuk kebenaran (misalnya, apakah suatu fungsi mengembalikan hasil yang benar) adalah satu hal, dan pengujian dalam jaringan yang tidak dapat diandalkan adalah tugas yang sama sekali berbeda (sering diyakini bahwa jaringan selalu bekerja tanpa kegagalan, dan ini adalah yang pertama dari delapan kesalahpahaman mengenai distribusi komputasi). Salah satu kesulitan dalam memecahkan masalah ini adalah bagaimana mensimulasikan kegagalan dalam sistem atau mengenalkannya secara sengaja dengan melakukan apa yang disebut injeksi kesalahan. Ini dapat dilakukan dengan memodifikasi kode sumber aplikasi itu sendiri. Tapi kemudian Anda tidak akan menguji kode asli Anda, tetapi versinya, yang secara khusus mensimulasikan kegagalan. Akibatnya, Anda berisiko masuk ke pelukan fatal dari injeksi kesalahan dan bertabrakan dengan tas heisen - kegagalan yang hilang ketika Anda mencoba untuk mendeteksinya.
Dan sekarang kita akan menunjukkan bagaimana Istio membantu mengatasi kesulitan ini satu-dua.
Bagaimana kelihatannya ketika semuanya baik-baik saja
Pertimbangkan skenario berikut: kami memiliki dua pod untuk microservice rekomendasi kami, yang kami ambil dari tutorial Istio. Satu pod ditandai sebagai v1 dan yang lainnya sebagai v2. Seperti yang Anda lihat, sementara semuanya bekerja dengan baik:
(Omong-omong, nomor di sebelah kanan hanyalah penghitung panggilan untuk setiap pod)
Tapi kita tidak butuh ini, kan? Baiklah, mari kita coba hancurkan semuanya tanpa menyentuh kode sumber sama sekali.
Kami mengatur interupsi dalam pekerjaan layanan mikro
Di bawah ini adalah file yaml untuk aturan routing Istio, yang dalam setengah kasus akan gagal (kesalahan server 503):
Harap dicatat bahwa kami secara eksplisit menetapkan bahwa dalam setengah kasus kesalahan 503 harus dikembalikan.
Dan berikut ini adalah tangkapan layar dari perintah curl yang diluncurkan dalam loop setelah kami mengaktifkan aturan ini untuk mensimulasikan kegagalan. Seperti yang Anda lihat, setengah dari permintaan mengembalikan kesalahan 503, dan terlepas dari pod - v1 atau v2 mana - mereka pergi ke:
Untuk memulihkan operasi normal, cukup menghapus aturan ini, dalam kasus kami, perintah istioctl delete routerule Recommendation-503 -n tutorial. Di sini Tutorial adalah nama dari proyek Red Hat OpenShift yang menjalankan tutorial Istio kami.
Membuat Penundaan Buatan
Kesalahan buatan 503 membantu menguji sistem untuk toleransi kesalahan, tetapi kemampuan untuk memprediksi dan menangani penundaan akan membuat Anda lebih terkesan. Dan keterlambatan dalam kehidupan nyata lebih sering terjadi daripada kegagalan. Layanan-mikro yang berjalan lambat adalah racun yang diderita seluruh sistem. Berkat Istio, Anda dapat menguji kode yang terkait dengan keterlambatan pemrosesan tanpa mengubahnya sama sekali. Untuk mulai dengan, kami akan menunjukkan bagaimana melakukan ini dalam kasus keterlambatan jaringan yang diperkenalkan secara buatan.
Harap perhatikan bahwa setelah pengujian seperti itu, Anda mungkin perlu (atau ingin) memperbaiki kode Anda. Berita baiknya adalah, dalam hal ini Anda akan bertindak proaktif, bukan reaktif. Itulah bagaimana siklus pengembangan harus dibangun: coding-testing-feedback-coding-testing ...
Beginilah aturannya terlihat ... Meskipun Anda tahu apa? Istio sangat sederhana, dan file yaml ini sangat jelas sehingga semua yang ada dalam contoh ini berbicara sendiri, lihat saja:
Dalam setengah kasus, kami akan memiliki penundaan 7 detik. Dan ini sama sekali tidak sama seperti jika kita memasukkan perintah sleep pada kode sumber, karena Istio benar-benar menunda permintaan selama 7 detik. Karena Istio mendukung pelacakan Jaeger, penundaan ini sangat baik di UI miring Jaeger, seperti yang ditunjukkan pada tangkapan layar di bawah ini. Perhatikan permintaan panjang di sudut kanan atas diagram - durasinya 7,02 detik:
Skenario ini memungkinkan Anda untuk menguji kode di bawah kondisi latensi jaringan. Dan jelas bahwa dengan menghapus aturan ini, kami akan menghapus penundaan buatan. Kami ulangi, tetapi sekali lagi kami melakukan semua ini tanpa menyentuh kode sumber.
Jangan mundur dan jangan menyerah
Fitur lain dari Istio yang berguna untuk rekayasa kekacauan adalah panggilan berulang ke layanan beberapa kali. Intinya di sini bukan untuk berhenti mencoba, ketika permintaan pertama berakhir dengan kesalahan 503 - dan kemudian, mungkin, untuk kali kesebelas kita beruntung. Mungkin layanan hanya berbaring sebentar karena suatu alasan. Ya, alasan ini harus digali dan dihilangkan. Tapi ini nanti, tapi untuk sekarang mari kita coba untuk membuat sistem terus bekerja.
Jadi, kami ingin layanan untuk memberikan kesalahan 503 dari waktu ke waktu, dan setelah itu Istio akan mencoba menghubunginya lagi. Dan di sini kita jelas membutuhkan cara untuk menghasilkan kesalahan 503, tanpa menyentuh kode itu sendiri ...
Berhenti menunggu! Kami baru saja melakukannya.
File ini akan membuat layanan rekomendasi-v2 menghasilkan kesalahan 503 dalam setengah kasus:
Jelas, sebagian dari permintaan akan gagal:
Dan sekarang kita akan menggunakan fungsi Coba Lagi Istio:
Aturan perutean ini melakukan tiga percobaan ulang dengan interval dua detik dan harus mengurangi (dan idealnya sepenuhnya dihapus dari radar) 503 kesalahan:
Kami meringkas: kami membuatnya sehingga Istio, pertama, menghasilkan 503 kesalahan untuk setengah dari permintaan. Dan kedua, Istio yang sama membuat tiga upaya untuk menyambung kembali ke layanan jika terjadi kesalahan 503. Akibatnya, semuanya bekerja dengan baik. Dengan demikian, menggunakan fungsi Coba Lagi, kami memenuhi janji kami untuk tidak mundur dan tidak menyerah.
Dan ya, kami melakukannya lagi tanpa menyentuh kode sama sekali. Yang kami butuhkan hanyalah dua aturan perutean Istio:
Bagaimana tidak mengecewakan seorang pengguna atau tujuh jangan menunggu
Dan sekarang kita membalikkan situasi dan mempertimbangkan skenario ketika Anda tidak harus mundur dan hanya memberikan waktu yang tetap. Dan kemudian Anda hanya perlu berhenti mencoba memproses permintaan agar tidak memaksa semua orang untuk menunggu satu layanan pengereman. Dengan kata lain, kami tidak akan melindungi posisi yang hilang, tetapi akan pindah ke garis cadangan agar tidak mengecewakan pengguna situs dan tidak memaksanya untuk merana karena ketidaktahuan.
Di Istio, Anda dapat mengatur batas waktu permintaan. Jika layanan melebihi batas waktu ini, kesalahan 504 (Gateway Timeout) dikembalikan - lagi, semua ini dilakukan melalui konfigurasi Istio. Tetapi kita harus menambahkan perintah sleep ke kode sumber layanan (dan kemudian, tentu saja, jalankan rebuild dan redeploy) untuk mensimulasikan operasi layanan yang lambat. Sayangnya, itu tidak akan berhasil jika tidak.
Jadi, kami memasukkan tidur tiga detik ke kode layanan rekomendasi v2, membangun kembali gambar yang sesuai dan membuat mode ulang wadah, dan sekarang kami akan menambahkan batas waktu menggunakan aturan perutean Istio berikut:
Tangkapan layar di atas menunjukkan bahwa kami mencoba menghubungi layanan rekomendasi jika kami tidak menerima respons dalam satu detik, yaitu, sebelum kesalahan 504 terjadi. Setelah menerapkan aturan perutean ini (dan menambahkan tidur tiga detik ke kode layanan rekomendasi) : v2), kami mendapatkan ini:
Kami ulangi lagi, tetapi batas waktu dapat diatur tanpa menyentuh kode sumber. Dan bonus tambahan di sini adalah sekarang Anda dapat memodifikasi kode Anda sehingga merespons timeout, dan mudah untuk menguji peningkatan ini menggunakan Istio.
Dan sekarang semuanya bersama
Membuat sedikit kekacauan dengan Istio adalah cara yang bagus untuk menguji kode Anda dan keandalan sistem Anda secara keseluruhan. Pola fallback, sekat, dan pemutus sirkuit, mekanisme untuk menciptakan kegagalan dan penundaan buatan, dan juga panggilan dan waktu tunggu berulang kali akan sangat berguna saat membuat sistem cloud yang toleran terhadap kesalahan. Dikombinasikan dengan Kubernetes dan Red Hat OpenShift, alat ini membantu Anda dengan percaya diri menghadapi masa depan.