Entah bagaimana, secara historis, industri TI terbagi menjadi dua kubu bersyarat karena alasan apa pun: mereka yang “mendukung” dan mereka yang “menentang”. Selain itu, subjek perselisihan bisa jadi sepenuhnya sewenang-wenang. OS mana yang lebih baik: Win atau Linux? Di ponsel pintar Android atau iOS? Haruskah Anda menyimpan semuanya di awan atau menyimpannya di penyimpanan RAID dingin dan menyimpan sekrupnya di brankas? Apakah orang PHP berhak disebut programmer? Perselisihan ini, kadang-kadang, hanya bersifat eksistensial dan tidak mempunyai dasar selain kepentingan olahraga.
Kebetulan dengan munculnya container dan semua masakan favorit ini dengan buruh pelabuhan dan k8 bersyarat, perdebatan “mendukung” dan “menentang” penggunaan kemampuan baru di berbagai area backend dimulai. (Mari kita buat reservasi sebelumnya bahwa meskipun Kubernetes paling sering diindikasikan sebagai orkestrator dalam diskusi ini, pilihan alat khusus ini tidak terlalu penting. Sebaliknya, Anda dapat mengganti alat lain yang menurut Anda paling nyaman dan familier. .)
Dan, tampaknya, ini hanyalah perselisihan sederhana antara dua sisi mata uang yang sama. Sama tidak masuk akal dan tanpa ampunnya dengan konfrontasi abadi antara Win vs Linux, di mana terdapat cukup banyak orang di tengah-tengahnya. Namun dalam kasus containerisasi, tidak semuanya sesederhana itu. Biasanya dalam perselisihan seperti itu tidak ada pihak yang benar, tetapi dalam kasus “menggunakan” atau “tidak menggunakan” wadah untuk menyimpan database, semuanya menjadi terbalik. Karena dalam arti tertentu, baik pendukung maupun penentang pendekatan ini benar.
Sisi terang
Argumen Sisi Terang dapat dijelaskan secara singkat dalam satu kalimat: “Halo, 2k19 ada di luar jendela!” Kedengarannya seperti populisme, tentu saja, tetapi jika Anda mempelajari situasinya secara mendetail, hal ini memiliki kelebihan. Mari kita selesaikan sekarang.
Katakanlah Anda memiliki proyek web yang besar. Ini bisa saja awalnya dibangun berdasarkan pendekatan layanan mikro, atau pada titik tertentu dicapai melalui jalur evolusi - sebenarnya ini tidak terlalu penting. Anda menyebarkan proyek kami ke dalam layanan mikro terpisah, menyiapkan orkestrasi, penyeimbangan beban, dan penskalaan. Dan sekarang, dengan hati nurani yang bersih, Anda menyesap mojito di tempat tidur gantung selama efek habra alih-alih menaikkan server yang rusak. Namun dalam segala tindakan Anda harus konsisten. Seringkali, hanya aplikasi itu sendiri—kodenya—yang dimasukkan ke dalam container. Apa lagi yang kita punya selain kode?
Itu benar, datanya. Inti dari setiap proyek adalah datanya: ini bisa berupa DBMS biasa - MySQL, Postgre, MongoDB, atau penyimpanan yang digunakan untuk pencarian (ElasticSearch), penyimpanan nilai kunci untuk cache - misalnya, redis, dll. Saat ini kami tidak kita akan berbicara tentang opsi implementasi backend yang bengkok ketika database mogok karena permintaan yang ditulis dengan buruk, dan sebagai gantinya kita akan berbicara tentang memastikan toleransi kesalahan dari database ini di bawah beban klien. Lagi pula, ketika kita memasukkan aplikasi kita ke dalam container dan membiarkannya melakukan penskalaan secara bebas untuk memproses sejumlah permintaan masuk, hal ini secara alami meningkatkan beban pada database.
Faktanya, saluran untuk mengakses database dan server yang menjalankannya menjadi ujung tombak di backend container kami yang indah. Pada saat yang sama, motif utama virtualisasi kontainer adalah mobilitas dan fleksibilitas struktur, yang memungkinkan kami mengatur distribusi beban puncak di seluruh infrastruktur yang tersedia bagi kami seefisien mungkin. Artinya, jika kita tidak memasukkan dan meluncurkan semua elemen sistem yang ada ke seluruh cluster, kita membuat kesalahan yang sangat serius.
Jauh lebih logis untuk mengelompokkan tidak hanya aplikasi itu sendiri, tetapi juga layanan yang bertanggung jawab untuk menyimpan data. Dengan mengelompokkan dan menerapkan server web yang bekerja secara independen dan mendistribusikan beban di antara mereka sendiri di k8s, kami telah memecahkan masalah sinkronisasi data - komentar yang sama pada postingan, jika kita mengambil beberapa media atau platform blog sebagai contoh. Bagaimanapun, kami memiliki representasi database intra-cluster, bahkan virtual, sebagai Layanan Eksternal. Pertanyaannya adalah bahwa database itu sendiri belum dikelompokkan - server web yang ditempatkan di kubus mengambil informasi tentang perubahan dari database pertempuran statis kami, yang berputar secara terpisah.
Apakah Anda merasakan adanya tangkapan? Kami menggunakan k8s atau Swarm untuk mendistribusikan beban dan menghindari crash pada server web utama, tetapi kami tidak melakukan ini untuk database. Namun jika database mogok, maka seluruh infrastruktur cluster kita tidak masuk akal - apa gunanya halaman web kosong yang mengembalikan kesalahan akses database?
Oleh karena itu, penting untuk mengelompokkan tidak hanya server web, seperti yang biasa dilakukan, tetapi juga infrastruktur database. Hanya dengan cara ini kita dapat memastikan struktur yang bekerja sepenuhnya dalam satu tim, namun pada saat yang sama independen satu sama lain. Selain itu, bahkan jika setengah dari backend kami “runtuh” saat dimuat, sisanya akan bertahan, dan sistem sinkronisasi database satu sama lain dalam cluster dan kemampuan untuk menskalakan dan menyebarkan cluster baru tanpa henti akan membantu mencapai kapasitas yang dibutuhkan dengan cepat - andai saja ada rak di pusat data.
Selain itu, model database yang didistribusikan dalam cluster memungkinkan Anda membawa database ini ke tempat yang diperlukan; Jika kita berbicara tentang layanan global, maka sangat tidak logis untuk membuat cluster web di suatu tempat di wilayah San Francisco dan pada saat yang sama mengirim paket ketika mengakses database di wilayah Moskow dan sebaliknya.
Selain itu, containerisasi database 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 administrator. Para pengembang berpikir bahwa DBMS terpisah diperlukan untuk subproyek baru - mudah! menulis file yaml, mengunggahnya ke cluster dan selesai.
Dan tentu saja, pengoperasian internal menjadi sangat disederhanakan. Katakan padaku, berapa kali kamu menutup mata ketika ada anggota tim baru yang memasukkan tangannya ke dalam database pertarungan untuk bekerja? Faktanya, manakah satu-satunya yang Anda miliki dan sedang berputar saat ini? Tentu saja, kita semua adalah orang dewasa di sini, dan di suatu tempat kita memiliki cadangan baru, dan bahkan lebih jauh lagi - di belakang rak dengan mentimun nenek dan alat ski tua - cadangan lain, bahkan mungkin di penyimpanan dingin, karena kantor Anda pernah terbakar sekali. Namun tetap saja, setiap pengenalan anggota tim baru dengan akses ke infrastruktur tempur dan, tentu saja, ke database pertempuran adalah sebuah validol untuk semua orang di sekitarnya. Nah, siapa yang kenal dia, seorang newbie, mungkin dia juling? Ini menakutkan, Anda pasti setuju.
Kontainerisasi dan, pada kenyataannya, topologi fisik terdistribusi dari database proyek Anda membantu menghindari momen validasi tersebut. Tidak percaya pada seorang pemula? OKE! Mari kita berikan klusternya sendiri untuk digunakan dan putuskan sambungan database dari kluster lain - sinkronisasi hanya dengan menekan secara manual dan memutar dua kunci secara sinkron (satu untuk pimpinan tim, satu lagi untuk admin). Dan semua orang senang.
Dan sekarang saatnya untuk berubah menjadi penentang pengelompokan basis data.
Sisi gelap
Dengan memperdebatkan mengapa tidak ada gunanya memasukkan database ke dalam container dan terus menjalankannya di satu server pusat, kami tidak akan menyerah pada retorika ortodoksi dan pernyataan seperti “kakek menjalankan database pada perangkat keras, dan kami juga!” Sebaliknya, mari kita coba memikirkan situasi di mana containerisasi akan benar-benar memberikan keuntungan nyata.
Setuju, proyek-proyek yang sangat membutuhkan alas dalam sebuah container bisa dihitung dengan jari satu tangan bukan oleh operator mesin milling terbaik. Untuk sebagian besar, bahkan penggunaan k8s atau Docker Swarm itu sendiri adalah mubazir - cukup sering alat-alat ini digunakan karena hype umum teknologi dan sikap “yang maha kuasa” dalam pribadi gender untuk mendorong segalanya ke dalam awan dan kontainer. Ya, karena sekarang sedang modis dan semua orang melakukannya.
Setidaknya dalam setengah kasus, menggunakan Kubernetis atau hanya Docker pada sebuah proyek adalah hal yang mubazir. Masalahnya adalah tidak semua tim atau perusahaan outsourcing yang dipekerjakan untuk memelihara infrastruktur klien menyadari hal ini. Lebih buruk lagi ketika kontainer dikenakan, karena klien dikenakan biaya sejumlah koin.
Secara umum, ada pendapat bahwa mafia buruh pelabuhan/kubus dengan bodohnya menghancurkan klien yang melakukan outsourcing untuk masalah infrastruktur ini. Lagi pula, untuk bekerja dengan cluster, kita memerlukan insinyur yang mampu melakukan hal ini dan secara umum memahami arsitektur solusi yang diterapkan. Kami telah menjelaskan kasus kami dengan publikasi Republik - di sana kami melatih tim klien untuk bekerja dalam realitas Kubernetis, dan semua orang merasa puas. Dan itu lumayan. Seringkali, “implementer” k8 menyandera infrastruktur klien - karena sekarang hanya mereka yang memahami cara kerja semuanya di sana; tidak ada spesialis di pihak klien.
Sekarang bayangkan dengan cara ini kita melakukan outsourcing tidak hanya bagian server web, tetapi juga pemeliharaan database. Kami mengatakan bahwa BD adalah jantung, dan hilangnya jantung berakibat fatal bagi organisme hidup mana pun. Singkatnya, prospeknya bukanlah yang terbaik. Jadi, alih-alih menggunakan Kubernetis yang berlebihan, banyak proyek tidak perlu repot dengan tarif normal untuk AWS, yang akan menyelesaikan semua masalah beban di situs/proyek mereka. Namun AWS sudah tidak lagi populer, dan pamer lebih bernilai daripada uang - sayangnya, di lingkungan TI juga demikian.
OKE. Mungkin proyek tersebut benar-benar memerlukan pengelompokan, tetapi jika semuanya jelas dengan aplikasi tanpa kewarganegaraan, lalu bagaimana kita dapat mengatur konektivitas jaringan yang layak untuk database yang berkerumun?
Jika kita berbicara tentang solusi rekayasa yang mulus, seperti transisi ke k8s, maka masalah utama kita adalah replikasi data dalam database yang terklaster. Beberapa DBMS pada awalnya cukup loyal terhadap distribusi data antar masing-masing instance. Banyak orang lain yang tidak begitu ramah. Dan sering kali argumen utama dalam memilih DBMS untuk proyek kita bukanlah kemampuan untuk mereplikasi dengan sumber daya dan biaya teknis yang minimal. Terutama jika proyek tersebut pada awalnya tidak direncanakan sebagai layanan mikro, namun hanya berkembang ke arah ini.
Kami pikir tidak perlu membicarakan kecepatan drive jaringan - mereka lambat. Itu. Kami masih belum memiliki peluang nyata, jika terjadi sesuatu, untuk memulai ulang instans DBMS di suatu tempat yang memiliki lebih banyak, misalnya, daya prosesor atau RAM kosong. Kami akan segera mengetahui kinerja subsistem disk tervirtualisasi. Oleh karena itu, DBMS harus dipaku pada perangkat mesin pribadinya yang terletak berdekatan. Atau perlu untuk mendinginkan sinkronisasi data yang cukup cepat secara terpisah untuk cadangan yang diharapkan.
Melanjutkan topik sistem file virtual: Sayangnya, Volume Docker tidak bebas masalah. Secara umum, dalam hal penyimpanan data jangka panjang yang andal, saya ingin puas dengan skema yang paling sederhana secara teknis. Dan menambahkan lapisan abstraksi baru dari FS container ke FS host induk merupakan risiko tersendiri. Namun ketika pengoperasian sistem pendukung containerisasi juga mengalami kesulitan dalam transmisi data antar lapisan tersebut, maka hal tersebut benar-benar menjadi bencana. Saat ini, sebagian besar permasalahan yang diketahui umat manusia progresif tampaknya telah teratasi. Tapi tahukah Anda, semakin rumit mekanismenya, semakin mudah rusak.
Mengingat semua “petualangan” ini, akan jauh lebih menguntungkan dan lebih mudah untuk menyimpan database di satu tempat, dan bahkan jika Anda perlu memasukkan aplikasi ke dalam container, biarkan aplikasi berjalan sendiri dan melalui gateway distribusi menerima komunikasi simultan dengan database, yang akan dibaca dan ditulis hanya sekali dan di satu tempat. Pendekatan ini meminimalkan kemungkinan kesalahan dan desinkronisasi.
Apa yang kita tuju? Selain itu, kontainerisasi basis data cocok dilakukan jika memang benar-benar diperlukan. Anda tidak dapat memasukkan database aplikasi lengkap dan memutarnya seolah-olah Anda memiliki dua lusin layanan mikro - cara kerjanya tidak seperti itu. Dan ini harus dipahami dengan jelas.
Alih-alih output
Jika Anda menunggu kesimpulan yang jelas “untuk memvirtualisasikan database atau tidak”, maka kami akan mengecewakan Anda: kesimpulan tersebut tidak akan ada di sini. Karena ketika menciptakan solusi infrastruktur apa pun, seseorang tidak boleh berpedoman pada mode dan kemajuan, tetapi pertama-tama, pada akal sehat.
Ada beberapa proyek yang prinsip dan alat yang disertakan dengan Kubernetis sangat cocok, dan dalam proyek semacam itu terdapat kedamaian setidaknya di area backend. Dan ada proyek yang tidak memerlukan containerisasi, tetapi infrastruktur server normal, karena proyek tersebut pada dasarnya tidak dapat diubah skalanya ke model cluster layanan mikro, karena proyek tersebut akan gagal.
Sumber: www.habr.com