Artikel ini berisi beberapa pola umum untuk membantu teknisi bekerja dengan layanan berskala besar yang diakses oleh jutaan pengguna.
Berdasarkan pengalaman penulis, daftar ini bukanlah daftar yang lengkap, namun memang demikian efektif saran. Jadi, mari kita mulai.
Diterjemahkan dengan dukungan .
Tingkat pertama
Langkah-langkah yang tercantum di bawah ini relatif sederhana untuk diterapkan namun memiliki dampak yang besar. Jika Anda belum pernah mencobanya, Anda akan terkejut dengan peningkatan yang signifikan.
Infrastruktur sebagai kode
Bagian pertama dari saran tersebut adalah menerapkan infrastruktur sebagai kode. Ini berarti Anda harus memiliki cara terprogram untuk menerapkan seluruh infrastruktur. Kedengarannya rumit, tapi sebenarnya kita sedang membicarakan kode berikut:
Penerapan 100 mesin virtual
- dengan Ubuntu
- masing-masing RAM 2 GB
- mereka akan memiliki kode berikut
- dengan parameter ini
Anda dapat melacak perubahan pada infrastruktur Anda dan dengan cepat mengembalikannya menggunakan kontrol versi.
Modernis dalam diri saya mengatakan Anda dapat menggunakan Kubernetes/Docker untuk melakukan semua hal di atas, dan dia benar.
Selain itu, Anda dapat memberikan otomatisasi menggunakan Chef, Puppet, atau Terraform.
Integrasi dan Pengiriman Berkelanjutan
Untuk membuat layanan yang skalabel, penting untuk memiliki alur build dan pengujian untuk setiap permintaan pull. Meskipun pengujiannya sangat sederhana, setidaknya ini akan memastikan bahwa kode yang Anda terapkan telah dikompilasi.
Setiap kali pada tahap ini Anda menjawab pertanyaan: akankah perakitan saya dikompilasi dan lulus tes, apakah valid? Ini mungkin tampak seperti standar yang rendah, tetapi ini menyelesaikan banyak masalah.
Tidak ada yang lebih indah daripada melihat kutu ini
Untuk teknologi ini Anda dapat mengevaluasi Github, CircleCI atau Jenkins.
Penyeimbang Beban
Jadi, kami ingin menjalankan penyeimbang beban untuk mengalihkan lalu lintas dan memastikan beban yang sama di semua node atau layanan terus berlanjut jika terjadi kegagalan:
Penyeimbang beban biasanya berfungsi dengan baik dalam mendistribusikan lalu lintas. Praktik terbaiknya adalah melakukan keseimbangan secara berlebihan sehingga Anda tidak mengalami satu titik kegagalan pun.
Biasanya, penyeimbang beban dikonfigurasi di cloud yang Anda gunakan.
RayID, ID korelasi atau UUID untuk permintaan
Pernahkah Anda menemui aplikasi error dengan pesan seperti ini: "Ada yang salah. Simpan id ini dan kirimkan ke tim dukungan kami"?
Pengidentifikasi unik, ID korelasi, RayID, atau variasi lainnya, adalah pengidentifikasi unik yang memungkinkan Anda melacak permintaan sepanjang siklus hidupnya. Ini memungkinkan Anda melacak seluruh jalur permintaan di log.
Pengguna membuat permintaan ke sistem A, kemudian A menghubungi B, yang menghubungi C, menyimpannya di X, dan kemudian permintaan tersebut dikembalikan ke A
Jika Anda terhubung dari jarak jauh ke mesin virtual dan mencoba melacak jalur permintaan (dan secara manual mengkorelasikan panggilan mana yang dilakukan), Anda akan menjadi gila. Memiliki pengenal unik membuat hidup lebih mudah. Ini adalah salah satu hal paling sederhana yang dapat Anda lakukan untuk menghemat waktu seiring berkembangnya layanan Anda.
Tingkat menengah
Saran di sini lebih kompleks dibandingkan yang sebelumnya, namun alat yang tepat membuat tugas lebih mudah, memberikan laba atas investasi bahkan untuk perusahaan kecil dan menengah.
Penebangan terpusat
Selamat! Anda telah menyebarkan 100 mesin virtual. Keesokan harinya, CEO datang dan mengeluh tentang kesalahan yang diterimanya saat menguji layanan. Ini melaporkan ID terkait yang kita bicarakan di atas, tetapi Anda harus memeriksa log dari 100 mesin untuk menemukan salah satu yang menyebabkan kerusakan. Dan itu perlu ditemukan sebelum presentasi besok.
Meskipun ini terdengar seperti petualangan yang menyenangkan, yang terbaik adalah memastikan Anda memiliki kemampuan untuk mencari semua majalah di satu tempat. Saya memecahkan masalah sentralisasi log menggunakan fungsionalitas bawaan tumpukan ELK: ini mendukung pengumpulan log yang dapat dicari. Ini akan sangat membantu menyelesaikan masalah pencarian jurnal tertentu. Sebagai bonusnya, Anda dapat membuat grafik dan hal menyenangkan lainnya seperti itu.
Fungsionalitas tumpukan ELK
Agen pemantau
Sekarang setelah layanan Anda aktif dan berjalan, Anda perlu memastikannya berjalan lancar. Cara terbaik untuk melakukan ini adalah dengan menjalankan beberapa agen, yang bekerja secara paralel dan memeriksa apakah berfungsi dan operasi dasar dilakukan.
Pada titik ini Anda memeriksanya build yang berjalan terasa nyaman dan berfungsi dengan baik.
Untuk proyek kecil hingga menengah, saya merekomendasikan Tukang Pos untuk memantau dan mendokumentasikan API. Namun secara umum, Anda hanya ingin memastikan bahwa Anda memiliki cara untuk mengetahui kapan pemadaman telah terjadi dan mendapat pemberitahuan tepat waktu.
Penskalaan otomatis tergantung pada beban
Ini sangat sederhana. Jika Anda memiliki permintaan layanan VM dan penggunaan memorinya mendekati 80%, Anda dapat meningkatkan sumber dayanya atau menambahkan lebih banyak VM ke cluster. Eksekusi otomatis dari operasi ini sangat baik untuk perubahan daya elastis di bawah beban. Namun Anda harus selalu berhati-hati dengan jumlah uang yang Anda keluarkan dan menetapkan batasan yang wajar.
Pada sebagian besar layanan cloud, Anda dapat mengonfigurasinya untuk melakukan penskalaan otomatis menggunakan lebih banyak server atau server yang lebih kuat.
Sistem eksperimen
Cara yang baik untuk meluncurkan pembaruan dengan aman adalah dengan menguji sesuatu untuk 1% pengguna selama satu jam. Anda tentu saja pernah melihat mekanisme seperti itu beraksi. Misalnya, Facebook menampilkan warna berbeda kepada sebagian audiens atau mengubah ukuran font untuk melihat bagaimana pengguna memandang perubahan tersebut. Ini disebut pengujian A/B.
Bahkan merilis sebuah fitur baru bisa dimulai sebagai sebuah eksperimen dan kemudian ditentukan bagaimana cara merilisnya. Anda juga mendapatkan kemampuan untuk "mengingat" atau mengubah konfigurasi dengan cepat berdasarkan fungsi yang menyebabkan penurunan layanan Anda.
tingkat lanjutan
Berikut tips yang cukup sulit untuk diterapkan. Anda mungkin memerlukan lebih banyak sumber daya, sehingga perusahaan kecil atau menengah akan kesulitan mengelolanya.
Penerapan biru-hijau
Inilah yang saya sebut dengan cara pengungkapan "Erlang". Erlang menjadi banyak digunakan ketika perusahaan telepon muncul. Softswitch mulai digunakan untuk merutekan panggilan telepon. Tujuan utama perangkat lunak pada switch ini adalah untuk tidak membatalkan panggilan selama peningkatan sistem. Erlang memiliki cara yang bagus untuk memuat modul baru tanpa merusak modul sebelumnya.
Langkah ini bergantung pada keberadaan load balancer. Bayangkan Anda memiliki perangkat lunak versi N, lalu Anda ingin menerapkan versi N+1.
Anda kita bisa cukup hentikan layanan dan luncurkan versi berikutnya pada waktu yang sesuai untuk pengguna Anda dan dapatkan waktu henti. Tapi misalkan Anda punya benar-benar ketentuan SLA yang ketat. Jadi, SLA 99,99% berarti bisa offline hanya sebesar 52 menit per tahun.
Jika Anda benar-benar ingin mencapai indikator tersebut, Anda memerlukan dua penerapan sekaligus:
- yang sekarang (N);
- versi berikutnya (N+1).
Anda memberi tahu penyeimbang beban untuk mengalihkan persentase lalu lintas ke versi baru (N+1) sementara Anda secara aktif memantau regresi.
Di sini kami memiliki penerapan N hijau yang berfungsi dengan baik. Kami mencoba untuk pindah ke versi berikutnya dari penerapan ini
Pertama, kami mengirimkan tes yang sangat kecil untuk melihat apakah penerapan N+1 kami berfungsi dengan sejumlah kecil lalu lintas:
Terakhir, kami memiliki serangkaian pemeriksaan otomatis yang pada akhirnya kami jalankan hingga penerapan kami selesai. Jika kamu sangat sangat hati-hati, Anda juga dapat menyimpan penerapan N selamanya untuk pengembalian cepat jika terjadi regresi buruk:
Jika Anda ingin melanjutkan ke tingkat lebih lanjut, biarkan semua yang ada dalam penerapan biru-hijau berjalan secara otomatis.
Deteksi anomali dan mitigasi otomatis
Mengingat Anda memiliki logging terpusat dan pengumpulan log yang baik, Anda sudah dapat menetapkan sasaran yang lebih tinggi. Misalnya, secara proaktif memprediksi kegagalan. Fungsi dilacak di monitor dan log dan berbagai diagram dibuat - dan Anda dapat memprediksi sebelumnya apa yang salah:
Setelah anomali terdeteksi, Anda mulai memeriksa beberapa petunjuk yang diberikan layanan. Misalnya, lonjakan beban CPU mungkin menunjukkan bahwa hard drive mengalami kegagalan fungsi, sementara lonjakan permintaan mungkin menunjukkan bahwa Anda perlu meningkatkan skalanya. Data statistik semacam ini memungkinkan Anda membuat layanan menjadi proaktif.
Dengan wawasan ini, Anda dapat melakukan penskalaan dalam dimensi apa pun dan secara proaktif dan reaktif mengubah karakteristik mesin, database, koneksi, dan sumber daya lainnya.
Itu saja!
Daftar prioritas ini akan menyelamatkan Anda dari banyak masalah jika Anda meningkatkan layanan cloud.
Penulis artikel asli mengundang pembaca untuk meninggalkan komentarnya dan melakukan perubahan. Artikel ini didistribusikan sebagai open source, permintaan tarik oleh penulis .
Apa lagi yang perlu dibaca tentang topik ini:
Sumber: www.habr.com