Entah bagaimana itu terjadi secara historis bahwa industri TI dengan alasan apa pun dibagi menjadi dua kubu bersyarat: yang untuk dan yang menentang. Selain itu, subjek kontroversi dapat benar-benar sewenang-wenang. OS mana yang lebih baik: Menang atau Linux? Di smartphone Android atau iOS? Simpan semuanya di awan atau unggah ke penyimpanan RAID yang dingin dan simpan sekrup di brankas? Apakah PHP schnicks berhak disebut pemrogram? Perselisihan ini, kadang-kadang, secara eksklusif eksistensial dan tidak memiliki dasar lain selain kepentingan olahraga.
Kebetulan dengan munculnya kontainer dan semua dapur tercinta ini dengan buruh pelabuhan dan kondisional K8, perselisihan "untuk" dan "menentang" penggunaan peluang baru di berbagai bidang backend dimulai. (Kami akan membuat reservasi terlebih dahulu bahwa meskipun Kubernetes yang paling sering akan diindikasikan sebagai orkestra dalam diskusi ini, pilihan instrumen ini tidak masalah. Sebaliknya, Anda dapat mengganti yang lain yang tampaknya paling nyaman dan akrab bagi Anda.)
Dan, tampaknya, itu akan menjadi argumen sederhana tentang dua sisi mata uang yang sama. Tidak masuk akal dan tanpa belas kasihan seperti konfrontasi abadi Menang vs Linux, di mana orang-orang yang cukup cukup ada untuk diri mereka sendiri di antara keduanya. Itu hanya dalam kasus kontainerisasi tidak begitu sederhana. Biasanya dalam perselisihan seperti itu tidak ada sisi kanan, tetapi dalam kasus "berlaku" atau "tidak berlaku" wadah untuk menyimpan database semuanya terbalik. Karena dalam arti tertentu, baik pendukung maupun penentang pendekatan semacam itu benar.
Sisi Cerah
Anda dapat secara singkat menjelaskan argumen dari Sisi Terang dengan satu kalimat: "Halo, 2k19 di luar jendela!" Kedengarannya seperti populisme, tentu saja, tetapi jika Anda mempelajari situasinya secara terperinci, ia memiliki kelebihan. Kami akan menganalisisnya sekarang.
Misalkan Anda memiliki proyek web besar. Awalnya dapat dibangun atas dasar pendekatan layanan-mikro, atau pada titik tertentu ia datang dengan cara evolusi - ini sebenarnya tidak terlalu penting. Anda menyebarkan proyek kami pada layanan microser terpisah, mengatur orkestrasi, load balancing, scaling. Dan sekarang, dengan hati nurani yang jelas, minum mojito di tempat tidur gantung selama efek habr, alih-alih membesarkan server yang jatuh. Tetapi semua tindakan harus konsisten. Sangat sering hanya aplikasi itu sendiri yang ditampung - kode. Apa lagi yang kita miliki selain kode?
Benar, data. Inti dari setiap proyek adalah datanya: itu bisa berupa DBMS yang khas - MySQL, Postgre, MongoDB, atau penyimpanan yang digunakan untuk pencarian (ElasticSearch), penyimpanan nilai kunci untuk caching - misalnya, redis, dll. Sekarang kami tidak kita akan berbicara tentang opsi implementasi backend yang bengkok ketika database macet karena permintaan yang ditulis dengan buruk, dan sebagai gantinya kita akan berbicara tentang memberikan toleransi kesalahan untuk basis data ini di bawah beban klien. Memang, ketika kita membuat kontainer aplikasi kita dan memungkinkannya untuk skala bebas untuk menangani sejumlah permintaan yang masuk, ini secara alami meningkatkan beban pada database.
Bahkan, saluran untuk mengakses basis data dan server tempat ia berputar menjadi mata jarum di backend kemas indah kami. Pada saat yang sama, motif utama untuk virtualisasi kontainer adalah mobilitas dan plastisitas struktur, yang memungkinkan untuk mengatur distribusi beban puncak di seluruh infrastruktur yang tersedia untuk kami seefisien mungkin. Yaitu, jika kita tidak mengemas dan menggulung semua elemen sistem yang tersedia ke dalam sebuah cluster, kita membuat kesalahan yang sangat serius.
Jauh lebih logis untuk mengelompokkan tidak hanya aplikasi itu sendiri, tetapi juga layanan yang bertanggung jawab untuk penyimpanan data. Ketika mengelompokkan dan menggunakan secara independen bekerja dan mendistribusikan beban server web di k8s, kami sudah menyelesaikan masalah sinkronisasi data - komentar yang sama untuk posting, jika Anda mengambil semacam media atau platform blog sebagai contoh. Dalam hal apa pun, kami memulai representasi intracluster, bahkan virtual, dari basis data sebagai ExternalService. Pertanyaannya adalah bahwa database itu sendiri belum dikelompokkan - server web yang digunakan dalam kubus mengambil informasi tentang perubahan dari pangkalan tempur statis kami, yang berputar secara terpisah.
Rasakan tangkapannya? Kami menggunakan k8s atau Swarm untuk mendistribusikan beban dan menghindari jatuhnya server web utama, tetapi kami tidak melakukan ini untuk database. Tetapi bagaimanapun juga, jika database lumpuh, maka di seluruh infrastruktur cluster kami tidak ada gunanya - apa gunanya halaman web kosong yang mengembalikan kesalahan akses database?
Itu sebabnya tidak hanya server web yang perlu dikelompokkan, seperti yang biasanya dilakukan, tetapi juga infrastruktur basis data. Hanya dengan cara ini kita dapat memastikan bahwa elemen-elemen dari struktur yang sama yang beroperasi penuh dalam satu tim, tetapi pada saat yang sama, independen satu sama lain. Pada saat yang sama, bahkan jika setengah dari backend kami di bawah beban "runtuh", sisanya akan bertahan, dan sistem sinkronisasi basis data satu sama lain di dalam kluster dan kemungkinan penskalaan tak terbatas dan penyebaran kluster baru akan membantu untuk dengan cepat mencapai kapasitas yang diperlukan - akan ada rak di pusat data .
Selain itu, model basis data yang didistribusikan dalam kelompok memungkinkan Anda untuk membawa basis data yang sama ke tempat yang dibutuhkan; jika kita berbicara tentang layanan global, agak tidak masuk akal untuk memutar cluster web di suatu tempat di wilayah San Francisco dan pada saat yang sama mendorong paket ketika mengakses database di Wilayah Moskow dan sebaliknya.
Juga, kontainerisasi basis data memungkinkan Anda membangun semua elemen sistem pada tingkat abstraksi yang sama. Yang, pada gilirannya, memungkinkan untuk mengelola sistem ini langsung dari kode, oleh pengembang, tanpa keterlibatan aktif dari admin. Diperkirakan oleh para pengembang bahwa mereka membutuhkan DBMS yang terpisah untuk sub proyek baru - mudah! menulis file yaml, diunggah ke cluster dan selesai.
Yah, tentu saja, operasi internal sangat disederhanakan. Katakan padaku, sudah berapa kali kamu menyipit pada saat-saat ketika anggota baru tim mendorong tangannya ke dalam database pertempuran untuk bekerja? Yang mana sebenarnya yang berputar sekarang? Tentu saja, kita semua di sini adalah orang dewasa, dan di suatu tempat kita memiliki cadangan baru, dan bahkan lebih jauh - di belakang rak dengan mentimun nenek dan ski tua - cadangan lain, mungkin bahkan dalam penyimpanan dingin, karena begitu kantor Anda terbakar. Tapi tetap saja, setiap pengenalan anggota baru tim dengan akses ke infrastruktur tempur dan, tentu saja, ke database pertempuran adalah seember validol untuk semua orang di sekitar. Nah, siapa, seorang pemula, tahu, mungkin dia menyipit? Menakutkan, setuju.
Kontainerisasi dan, pada kenyataannya, topologi database fisik terdistribusi dari proyek Anda membantu menghindari momen yang valid tersebut. Jangan percaya pada pemula? Baiklah Mari kita tingkatkan klusternya sendiri untuk bekerja dan putuskan sambungan dari sisa kluster basis data - sinkronisasi hanya dengan dorongan manual dan rotasi sinkron dari dua tombol (satu tim memimpin, admin kedua). Dan semua orang bahagia.
Dan sekarang saatnya untuk mengganti sepatu di penentang penumpukan basis data.
Sisi gelap
Berdebat mengapa tidak perlu membuat kontainer basis data dan terus memutarnya pada satu server pusat, kami tidak akan membungkuk ke retorika ortodoksi dan pernyataan seperti "kakek mengubah database pada perangkat keras, dan kami akan!" Sebagai gantinya, mari kita coba untuk menemukan situasi di mana kontainerisasi akan benar-benar membawa dividen nyata.
Anda harus mengakui bahwa proyek yang benar-benar membutuhkan pangkalan di dalam wadah dapat dihitung dengan jari satu tangan sebagai bukan operator mesin penggilingan terbaik. Untuk sebagian besar, bahkan penggunaan k8 atau Docker Swarm sangat berlebihan - cukup sering mereka menggunakan alat-alat ini karena sifat sensasi umum dari teknologi dan yang “paling kuat”, dalam hal jenis kelamin, untuk mengarahkan segala sesuatu ke dalam awan dan wadah. Ya, karena sekarang modis dan semua orang melakukannya.
Setidaknya dalam setengah kasus, menggunakan kubernetis atau hanya buruh pelabuhan pada suatu proyek adalah berlebihan. Pertanyaannya adalah bahwa tidak semua tim atau perusahaan outsourcing yang disewa untuk melayani infrastruktur klien mengetahui hal ini. Lebih buruk - ketika kontainer dikenakan, karena naik dalam jumlah tertentu koin kepada klien.
Secara umum, ada pendapat bahwa buruh pelabuhan / mafia kubus dengan bodohnya menghancurkan klien yang mengalihdayakan masalah infrastruktur ini. Memang, untuk bekerja dengan kluster, Anda membutuhkan insinyur yang mampu melakukan ini dan memahami arsitektur solusi yang diterapkan secara umum. Entah bagaimana kami sudah menggambarkan kasus kami dengan edisi Republic - di sana kami melatih tim klien untuk bekerja dalam realitas kubernetis, dan semua orang puas. Dan itu layak. Seringkali "pelaksana" K8 mengambil sandera infrastruktur klien - sekarang mereka hanya mengerti bagaimana semuanya bekerja di sana, tidak ada spesialis di sisi klien.
Sekarang bayangkan bahwa dengan cara ini kami memberikan tidak hanya bagian server web untuk outsourcing, tetapi juga pemeliharaan basis data. Kami mengatakan bahwa DB adalah jantung, dan kehilangan jantung adalah fatal bagi semua organisme hidup. Singkatnya, prospek bukanlah yang terbaik. Jadi, alih-alih hype kubernetis, banyak proyek seharusnya tidak menjadi gila dengan tarif AWS normal, yang akan menyelesaikan semua masalah dengan beban di situs web / proyek mereka. Tetapi AWS tidak lagi fashionable, dan pamer lebih mahal daripada uang - sayangnya, di lingkungan TI juga.
Baiklah Mungkin proyek ini benar-benar membutuhkan pengelompokan, tetapi jika semuanya jelas dengan aplikasi tanpa kewarganegaraan, lalu bagaimana kita dapat mengatur penyediaan konektivitas jaringan yang layak untuk basis data berkerumun?
Jika kita berbicara tentang solusi rekayasa yang mulus, yang tampaknya merupakan transisi ke k8, maka sakit kepala utama kita adalah replikasi data dalam database berkerumun. Beberapa DBMS awalnya cukup loyal terhadap distribusi data di antara instans masing-masing. Banyak orang lain tidak begitu ramah. Dan cukup sering, argumen utama dalam memilih DBMS untuk proyek kami bukanlah kemampuan untuk mereplikasi dengan sumber daya minimal dan biaya teknik. Terutama jika proyek ini awalnya tidak direncanakan sebagai layanan mikro, tetapi hanya berkembang ke arah ini.
Kami tidak perlu berbicara tentang kecepatan drive jaringan - mereka lambat. Yaitu kami masih belum memiliki kemungkinan nyata, dalam hal ini, untuk memutakhirkan instance DBMS di suatu tempat, di mana ada lebih banyak, misalnya, kapasitas prosesor atau RAM bebas. Kami sangat cepat mengalami kinerja subsistem disk tervirtualisasi. Dengan demikian, DBMS harus dipaku ke perangkat mesin pribadinya sendiri dalam jarak dekat. Atau, perlu untuk entah bagaimana memisahkan sinkronisasi sinkronisasi data yang cukup cepat dengan perkiraan cadangan.
Melanjutkan tema FS virtual: Volume Docker, sayangnya, tidak bebas masalah. Secara umum, dalam kasus seperti penyimpanan data jangka panjang yang dapat diandalkan, saya ingin mengelola dengan skema teknis yang paling sederhana. Dan menambahkan lapisan abstraksi baru dari wadah FS ke induk host FS adalah risiko itu sendiri. Tetapi ketika ada juga kesulitan dalam mentransmisikan data di antara lapisan-lapisan ini dalam pengoperasian sistem pendukung wadah, maka itu benar-benar bencana. Pada saat ini, sebagian besar masalah yang diketahui oleh umat manusia progresif tampaknya telah diberantas. Tapi Anda sendiri mengerti, semakin kompleks mekanismenya, semakin mudah rusak.
Mengingat semua "petualangan" ini, akan jauh lebih menguntungkan dan lebih mudah untuk menyimpan basis data di satu tempat, dan bahkan jika Anda membutuhkan pengemasan aplikasi, biarkan ia berputar sendiri dan melalui gateway distribusi menerima komunikasi simultan dengan basis data, yang akan dibaca dan ditulis hanya sekali dan di satu tempat. Pendekatan ini mengurangi kemungkinan kesalahan dan kesalahan sinkronisasi ke nilai minimum.
Apa yang kita tuju? Selain itu, kontainerisasi basis data sesuai jika ada kebutuhan nyata untuknya. Anda tidak dapat menjejalkan basis aplikasi lengkap dan memutarnya seolah-olah Anda memiliki dua lusin layanan mikro - ini tidak berfungsi. Dan ini harus dipahami dengan jelas.
Alih-alih output
Jika Anda menunggu kesimpulan yang masuk akal “virtualisasikan atau tidak databasenya”, maka kami kecewa: itu tidak akan ada di sini. Karena ketika menciptakan solusi infrastruktur apa pun, seseorang tidak boleh dibimbing oleh mode dan kemajuan, tetapi, pertama-tama, dengan akal sehat.
Ada proyek di mana prinsip-prinsip dan alat-alat yang datang dengan kubernet sangat cocok, dan dalam proyek-proyek tersebut, perdamaian datang setidaknya di daerah backend. Dan ada proyek-proyek yang tidak memerlukan containerisasi, tetapi infrastruktur server normal, karena mereka pada dasarnya tidak dapat diubah menjadi model cluster microservice, karena mereka akan jatuh.