Diyakini bahwa masa depan adalah untuk DB sebagai Layanan. Apakah layak bagi semua orang untuk menembakkan DBA dan pergi ke cloud publik atau berusaha untuk membuat cloud pribadi di Docker dengan Kubernetes? Tiga ahli dari Data Egret - Alexei Lesovsky, Viktor Yegorov, dan Andrey Salnikov - pada saluran #RuPostgres secara langsung berbagi pandangan tentang jenis proyek apa yang cocok untuk model cloud.
Moderator dan moderator diskusi adalah Nikolay Samokhvalov, pendiri Postgres.ai dan salah satu pendiri komunitas RuPostgres.org.
Di bawah transkrip percakapan.
- Hari ini kita akan berbicara tentang Postgres di awan. Dan saya akan mulai dengan pertanyaan rumit: benarkah Anda sudah memiliki lebih dari separuh klien di awan?Alexei: kurasa tidak. Rasanya kurang dari setengah. Semua orang duduk di pusat data mereka sendiri, atau menyewa besi.
Tetapi sebelum berbicara tentang awan, mari kita tentukan persyaratannya. Apa yang kami maksud dengan "awan": Amazon, Google Cloud, DB sebagai Layanan?
- Saya akan membedakan Postgres di cloud, disiapkan dengan instance Amazon EC2 (atau analog dari Google), di mana Anda dapat, secara kasar berbicara, masuk melalui ssh dan memperbaiki konfigurasi, dan Postgres di bawah kendali (dalam bahasa Inggris "dikelola"), ketika akses langsung di tingkat file atau tidak ada ssh, tetapi hanya ada kemampuan untuk menghubungkan dan menjalankan query SQL. Mereka pada prinsipnya harus dipertimbangkan secara terpisah. Dan pertanyaan pertama saya adalah tentang Postgres yang dikelola.Alexei: Pelanggan seperti itu secara substansial kurang dari setengah.
Victor: Ya, dalam kasus pertama - keuntungan signifikan apa yang kita miliki dari cloud? Apa arti dari cloud?
- Dalam kasus pertama, menggunakan berbagai alat modern, seperti patroni dan kubernetes (kita akan membicarakannya secara terpisah), Anda bisa mendapatkan elastisitas, layanan mikro dan semua itu. Ini tidak sama dengan hanya sepotong besi. Ini seperti "hewan peliharaan vs kawanan" - sikap untuk menyetrika sebagai hewan peliharaan tumbuh menjadi hubungan dengan mesin virtual seperti kawanan. Anda sudah tidak tahu jenis kelenjar apa yang dipasang di sana. Anda tidak memesannya, tidak bekerja dengan pemasok, tidak memikirkan topologi. Anda dapat menghemat waktu.Victor: Ya. Menurut pendapat saya, kasus pertama hanya menyederhanakan proses pembelian besi baru. Anda tahu apa yang Anda butuhkan: berapa banyak core dan RAM, drive apa. Dan Anda memilih mesin virtual dari apa yang mereka tawarkan kepada Anda. Itu cepat. Tetapi sebaliknya, Anda masih harus mengkonfigurasi dan memelihara server ini secara normal.
- Dan bagaimana perasaan Anda tentang overhead yang ditambahkan oleh mesin virtual (untuk proses di dalam mesin virtual yang tidak menggunakan logam kosong, overhead kinerja atau kesulitan administrasi)? Apakah ada di antara Anda yang mengukurnya?Alexei: Overhead dapat diukur jika Anda memiliki kendali atas hypervisor. Dalam layanan publik tidak - apa yang mereka berikan adalah apa yang Anda gunakan.
Overhead dari sistem virtualisasi biasa yang dapat digunakan di rumah (KVM, Xen), saya ukur lima tahun lalu, dan kemudian sekitar 7-8%. Selain itu, itu tergantung pada pengaturan mesin virtual dan beban kerja. Sebagai contoh, ada lebih banyak overhead pada Redis dan Postgres daripada Unicorn, yang melayani backend Rails.
Mungkin sekarang angkanya berbeda.
- Bahkan 5-7% adalah overhead yang dapat diterima dibandingkan dengan plus yang dibicarakan Victor.
Dan bagaimana Anda mengubah komposisi klien: apakah ada gerakan menuju basis yang dikelola?
Alexey: Tidak. Trennya agak sebaliknya. Orang yang bekerja dengan hal-hal seperti RDS tidak memiliki fleksibilitas untuk mengelola dan mengelola. Sebagai hasilnya, kita mendapatkan sikap yang sama "suka binatang peliharaan", tetapi dalam contoh EC2.
Victor: Situasi ini tampak. Ada pelanggan yang basis produksi utamanya sangat sibuk. Tentu, mereka ditempatkan pada potongan besi yang dialokasikan dan di bawah pengawasan konstan. Tetapi ketika perusahaan tumbuh, pengembangan membutuhkan sejumlah besar uji dan contoh pengembangan, dan mereka masuk ke dalam virtualisasi. Artinya, ini adalah kasus hybrid: di bawah pengujian dan lingkungan dev, perangkat keras dapat dibeli atau mesin virtual dapat disewa. Tetapi produksi tetap pada perangkat keras serius normal.
- Apakah Amazon RDS digunakan untuk ini?Alexey: Klien kami, sebaliknya, menolak RDS. Alasannya, seperti yang saya katakan, adalah kurangnya fleksibilitas dalam manajemen.
Mesin virtual crash, dan dalam beberapa kasus masalah tidak diselesaikan hanya dengan menyewa sepotong besi yang lebih kuat.
Anda tidak dapat memecahkan banyak masalah sendiri - hanya dengan bantuan dukungan.
- Apakah mungkin memberi contoh? Tampaknya baru-baru ini Amazon membeli OpenSCG - orang hebat yang seharusnya mengembangkan keahlian internal Postgres. Dan saya tahu dari pengalaman saya sendiri bahwa ada pemeriksaan. Jika Anda membuka tiket dengan dukungan Amazon RDS dan menemukan seseorang yang tidak dapat membantu Anda, tutup saja tiketnya dan buka lagi, dapatkan tiket yang lebih kompeten.Alexey: OpenSCG tentu saja adalah tim profesional. Tetapi membeli tim semacam itu tidak menutup 100% dari situasi yang mungkin. Ada masalah yang mendukung wajah untuk pertama kalinya. Ini juga terjadi pada kita.
Dari yang terakhir, pada salah satu replika PostgreSQL 10.6, rata-rata beban pelanggan pada host tiba-tiba meningkat 30-40 unit, meskipun tidak ada beban. Ketukan bawah tanah yang tidak bisa dipahami. Ini tidak terlalu mempengaruhi, tetapi gambaran dari bouncing rata-rata beban tidak dapat dipahami. Dan dia mengganggu admin pelanggan. Kami memiliki beberapa hipotesis, apa yang menyebabkannya, tetapi sejauh ini kami belum dapat mengujinya, karena sistemnya produktif dan tidak semuanya dapat dengan cepat dilakukan di sana.
Dan "ketukan bawah tanah" seperti itu keluar sekitar setahun sekali, dan Anda mulai secara kreatif mendekati tugas itu. Dan Amazon RDS adalah jumlah instance yang lebih besar, jumlah instalasi dan tiket yang lebih besar, dan semua jenis situasi jauh lebih besar.
Andrew: Saya ingin menambahkan tentang membandingkan contoh RDS dan EC2.
Kami memiliki klien dengan produksi di RDS. Dia mencari nasihat. Dev-circuit berada di Microsoft Azure, rupanya, Azure pada awalnya dianggap sebagai layanan cloud utama.
Saya menyeret basis rangkaian dev dari Azure ke Amazon di EC2 untuk mendekati produksi, dan meramalkan masalah semakin dekat ke basis data produk.
Meskipun server EC2 dua kali lebih sederhana dari pada contoh RDS, dan beban uji lebih tinggi dari produk, di sirkuit dev setelah setup saya hasilnya jauh lebih baik daripada di Amazon pada contoh RDS pada produksi.
Saya curiga bahwa karena kurangnya keahlian PostgreSQL dalam perusahaan pelanggan, RDS digunakan dengan konfigurasi default. Kami memutar semua pengaturan.
Hasilnya, klien sangat terkesan. Saya menoleh ke manajemen dengan proposal alih-alih RDS untuk mengambil dan mengkonfigurasi contoh sederhana.
- Ngomong-ngomong, bagaimana diukur, mana yang lebih baik, mana yang lebih buruk?Andrew: Klien melihat metrik aplikasinya, seberapa cepat data diunduh dan diproses.
- Kami sekarang memarahi RDS, tetapi ia memiliki keuntungan besar - ia menghilangkan banyak sakit kepala yang terkait dengan penyebaran, cadangan, replikasi. Apakah kamu setuju?Andrew: Ya. Dan, kemungkinan besar, alasan utama mengapa klien tetap berada di RDS justru karena kurangnya keahlian PostgreSQL. Mereka mendapatkan semua yang mereka butuhkan dengan RDS, mereka hanya membayar lebih untuk instans.
- Selain Amazon RDS, ada postgres terkelola berbasis cloud lainnya. Pernahkah Anda menemui, misalnya, layanan Yandex?Andrei: Saya menemukan mesin virtual mereka dan saya tidak benar-benar menyukainya - drive NVMe tidak terlalu jujur di sana. Bahkan, ada drive yang terhubung melalui jaringan.
- Jujur NVMe (drive lokal) juga merupakan masalah. Google dan Amazon memiliki NVMe, tetapi drive tersebut fana. Jika Anda me-restart instance, Anda kehilangan semua data karena Anda diberi mesin virtual lain.Andrei: Mereka mengomentari saya di Yandex Cloud bahwa mereka memiliki NVMe jujur di DB sebagai layanan, tetapi saya belum menemukan layanan ini. Rupanya, ada arsitektur yang sedikit berbeda di tingkat penyediaan sumber daya.
Mereka bekerja sangat keras pada DB sebagai layanan, karena mereka menggunakannya untuk layanan mereka. Hanya saja ada titik masuk yang berbeda untuk pelanggan eksternal dan penggunaan internal.
- Dan apa yang Anda pikirkan, apakah ada prospek untuk Postgres Rusia di awan? Akan lepas landas atau tidak lepas landas?Andrew:Yandex memiliki tim yang luar biasa, cukup berpengalaman, dengan keahlian yang baik. Saya pikir mereka akan tinggal landas.
Pertama, mereka sendiri mengoperasikan banyak Postgres (lebih dari 1000 database pada proyek mereka), dan sejak itu mengeksploitasi, semua kerucut dan bintik-bintik sakit akan bekerja dan memperbaiki lebih cepat. Saya pikir klien akan diberikan layanan akhir dengan kualitas yang cukup baik.
Dan ada permintaan untuk solusi semacam itu. Ambillah startup yang pada awalnya tidak dapat memiliki keahlian yang diperlukan dalam Postgres karena berbagai alasan: mahal, mereka tidak mengerti intinya, mencoba berbagai teknologi. Baginya, ini adalah solusi yang baik, karena dalam layanan seperti itu ada "tikungan" terbatas yang tidak boleh diputar, dan jika itu, saya pikir, akan ada dukungan teknis.
Benar, Yandex Cloud masih di awal, dan tidak begitu banyak fungsionalitas yang disajikan saat ini.
- Kami memiliki pertanyaan dari ruang obrolan: apa pendapat Anda tentang fakta bahwa ketika mengeluarkan mesin virtual, seseorang secara fisik dapat duduk di mesin ini (pembatasan, mencuri waktu).
Victor: Ya, ada pengalaman seperti itu. Saya hanya ingin menyebutkannya. Ada klien yang menggunakan sistem virtualisasi sendiri. Dari waktu ke waktu mereka meminta untuk melihat beberapa server non-produk, dan kami melihat situasi yang tidak dapat dipahami: kami tidak memperhatikan alasan mengapa harus rusak di server ini. Kemudian kami mengarahkan pertanyaan ke admin mereka dengan permintaan untuk melihat apa yang terjadi pada tuan rumah.
- Dan apa yang harus dilakukan, apakah ada efek serupa di Amazon? Apakah ada metode untuk menentukan bahwa Anda "diperas"? pgbench untuk mengemudi?Alexei: Saya tidak ingat itu. Tetapi cara yang biasa adalah menentukan melalui mencuri waktu. Pada grafik pemantauan, sebagai aturan, kami tidak melihat nilai besar apa pun.
- Saya merasa Anda tidak terlalu suka Postgres yang dikelola. Apakah karena fakta bahwa RDS mengambil pekerjaan Anda?Alexey: Tidak. Ini lebih mungkin karena fakta bahwa kita tidak memilikinya. Managed Postgres baik karena Anda dapat menggunakan infrastruktur dengan mengklik tombol. Selama Anda adalah startup dan hanya menambah atau membaca data tanpa logika yang kompleks, semuanya baik-baik saja. Dan ketika Anda melewati garis tertentu, misalnya, Anda mulai menjalankan banyak GABUNGAN, melakukan SQL kompleks, tugas muncul untuk mengoptimalkan kueri dan RDS berhenti menjadi cukup. Dibutuhkan lebih banyak kebebasan dan pengaruh, tetapi alat yang tersedia tidak membantu Anda memecahkan masalah mendalam terkait dengan pembuangan sumber daya di dalam Postgres itu sendiri. Hanya ada kesempatan untuk meningkatkan kekuatan potongan besi: membayar lebih banyak uang - diterima.
Andrew: Tidak ada begitu banyak ketidaksukaan terhadap RDS dan ketakutan untuk bekerja. Masalahnya berbeda. Misalkan startup membutuhkan RDS, ia memberi mereka segalanya. Tapi dia tidak menambah keahliannya dalam Postgres. Selanjutnya, katakanlah bidikan startup. Banyak yang tumbuh - menulis dan membaca telah meningkat. Dengan tidak adanya keahliannya, startup harus mencari orang-orang di samping. DBA yang parah datang dan melihat bahwa mereka tidak dapat memeras lebih banyak dari RDS, tetapi dari contoh EC2 biasa sangat mungkin untuk mendapatkan lebih banyak kinerja, seperti dalam contoh yang saya sebutkan sebelumnya. Jika kami diizinkan menggunakan RDS, mungkin kami dapat mengubah dan meningkatkan basis data, tetapi kami tidak melakukannya.
- Masalah dengan akses sedang diselesaikan. Ada Postgres yang dikelola yang menyediakan akses ssh (dan bahkan sepenuhnya root), misalnya, perusahaan kecil Aiven dari Finlandia. Secara default, mereka tidak memberikan akses root, tetapi pendiri (dan saya berbicara dengannya beberapa kali) berbicara tentang kesiapannya untuk memberikan akses berdasarkan permintaan.Andrew: Masalahnya bukan hanya akses. Mengapa kita lebih baik dengan kelenjar murni? Karena kami memiliki banyak pelanggan yang berbeda, dan masing-masing memiliki infrastruktur sendiri. Dan infrastrukturnya sangat berjauhan sehingga metodologi umum yang bekerja sama di mana-mana, kita tidak bisa. Karena ada orang-orang yang memiliki perangkat keras sendiri, dan mereka tidak dapat meng-host di suatu tempat (sesuai dengan beberapa aturan dan batasan mereka sendiri), dan ada orang-orang yang ada di awan.
- Anda ingin mengatakan bahwa definisi indeks yang tidak digunakan tergantung pada potongan besi? Atau beberapa hal biasa lainnya?Andrew: Dari sudut pandang administrasi, skema database dan definisi indeks yang tidak digunakan membuat awan tidak berbeda dari perangkat kerasnya. Semuanya bersatu.
Perbedaan antara cloud dan perangkat keras nyata - di lapisan antara basis dan khususnya perangkat keras yang ada di bawah - adalah sistem operasi dan virtualisasi yang digunakan. Ketika Anda memiliki database besar, penting bagi Anda seberapa cepat drive mengirim dan menerima data, seberapa efisien memori dan prosesor yang digunakan, sehingga sangat penting untuk mengurangi pengaruh lapisan ini sehingga database bekerja paling efisien.
- Pertanyaan lain dari audiens: bagaimana dengan pengaturan kernel?Victor: Dalam EC2, hal-hal seperti itu dapat disesuaikan.
- Ada solusi baru untuk kelas "dikelola Postgres" dari vendor terkenal, selain Amazon dan Google biasa. Sebagai contoh, Nutanix dan SAP mengumumkan pada tahun 2018 penciptaan solusi berbasis Postgres. Tidakkah Anda berpikir bahwa semua orang ini menuntun kita pada munculnya beberapa keputusan yang akan melakukan hal yang sama, tetapi hanya pada besi Anda? Sehingga Anda dapat mengklik tombol dan menggunakan Postgres baru, di mana cadangan dan replikasi sudah dikonfigurasi.Alexei: Sepertinya bagi saya SAP dan yang lainnya tidak sepenuhnya menguntungkan. Ini adalah vendor besar besi dan perangkat lunak. Mereka membuat produk dengan tujuan menghasilkan uang. Jual dukungan setidaknya. Karena itu, kita harus melihat bagaimana mereka akan mendapat untung dari ini. Jika model pengiriman produk seperti itu bermanfaat bagi mereka, lalu mengapa tidak?
- Maksud saya sedikit berbeda. Secara khusus, orang-orang ini tidak akan memposting apa pun di sumber terbuka dan memberikan secara gratis. Tetapi tidakkah Anda berpikir bahwa seseorang dari yang lebih kecil, tetapi lincah akan melakukan sesuatu seperti itu? Mungkin ini akan fokus pada Kubernetes, Operator Framework. Sudah ada beberapa perkembangan yang dilakukan operator - Zalando, misalnya. Dan tidakkah Anda berpikir bahwa RDS berbasis cloud membantu transisi bertahap ke solusi semacam itu? Kami melihat bagaimana Anda bisa hidup tanpa memanjat konfigurasi dengan tangan Anda.Alexey: Ternyata tidak cukup berhasil.
Semua sama, Anda perlu memiliki spesialis yang akan memantau semua ini dan memanjat di bawah tenda jika terjadi kesalahan.
Bahkan Kubernetes adalah mesin yang sangat kompleks, dengan banyak komponen di bawah kapnya. Secara formal, ini hanya lima binari. Tetapi interaksi mereka satu sama lain dijelaskan oleh volume dokumentasi dan banyak informasi di ruang obrolan, buletin dan Grup Google. Yaitu Anda masih membutuhkan spesialis yang akan mengikuti dapur ini.
Plus, semua ini berkembang sangat dinamis. Kompatibilitas mundur istirahat dari rilis ke rilis. Yaitu semuanya sangat tidak stabil dan tidak stabil. Ketika semuanya beres, mungkin kita akan mendapatkan produk yang cocok, stabil dan dapat diandalkan. Namun sejauh ini, semuanya tidak terlalu.
Victor: Kami mulai membicarakan fakta bahwa kami memiliki lapisan infrastruktur tambahan yang perlu dikelola - untuk mengatur Kubernetes ini.
Saya tidak setuju bahwa dia akan selalu bekerja secara ajaib dengan mengklik tombol seperti yang kita inginkan. Penting untuk mempertahankan spesialis yang relevan.
Dan yang kedua - pelanggan kami terus beradaptasi dengan perubahan bisnis. Dengan demikian, beban dalam basis data terus berubah. Dan jika kita menjilat semuanya tiga bulan lalu, sebagai hasilnya semua permintaan berfungsi seperti yang diharapkan, dan semuanya baik-baik saja, maka permintaan baru mungkin datang hari ini atau besok, atau karena perubahan data, permintaan yang ada akan berhenti berfungsi sebagaimana mestinya. Dan kita perlu menganalisis situasi dan masuk ke pengaturan sistem. Dan ini adalah otomatisasi itu, yang menurut saya, membuat contoh yang dikelola sangat sulit. Ketika awan mencapai kondisi sedemikian rupa sehingga mereka juga akan beradaptasi dengan situasi seperti itu, saya tidak tahu. Tetapi sementara ini adalah bagian penting dari pekerjaan yang perlu dilakukan, perlu untuk menyesuaikan pengaturan database dengan perubahan dalam pola permintaan yang masuk.
Dan karena cloud itu sendiri adalah beban administrasi tambahan, lebih mudah bagi kita ketika lapisan ini tidak ada di sana, karena kita dapat berkonsentrasi pada masalah basis data.
Jika klien ingin tinggal di cloud dan memiliki keahlian, kami tidak menentangnya. Hal utama adalah bahwa kita memiliki kesempatan, ketika database menjadi tidak terlalu bagus, naik (sebaiknya dengan ssh), periksa semuanya dan dapatkan akses ke semua statistik.
Alexey: Tidak harus dengan ssh. Tetapi bagaimanapun juga, alat diagnostik dibutuhkan. Karena diagnosis melalui email sangat panjang dan melelahkan. Ini menjengkelkan ketika Anda mengirim tautan obrolan ke permintaan untuk dieksekusi, klien, di sisi lain, mengklik tautan ini, menyalin permintaan, lalu menyalin hasilnya kepada Anda atau mengirim tangkapan layar. Ini sepanjang waktu.
Jauh lebih mudah untuk terhubung dan melihat secara langsung, menguji beberapa hipotesis Anda dan bertindak lebih jauh darinya.
- Apakah Anda memiliki contoh aktif di mana Kubernetes sudah digunakan dan Postgres tinggal di dalamnya?Alexei: Sayangnya, saya tidak. Tapi saya sangat ingin. Saya sangat suka Kubernetes, saya dekat dengan konsep dan filosofinya.
Menurut pendapat saya, Kubernetes adalah hal yang mendorong orang untuk lebih banyak memprogram, membuat lebih banyak produk, tanpa memikirkan hal-hal sampingan seperti struktur internal infrastruktur.
Peran serupa digunakan untuk dimainkan oleh OOP. Tampaknya, dan banyak orang menjadi tertarik pada bidang ini, karena pemrograman menjadi agak lebih mudah. Kubernetes juga menutup banyak hal pada dirinya sendiri, menyembunyikannya di bawah tenda dan memungkinkan seseorang untuk lebih fokus pada aspek kreatif dan program.
Kubernet mengimplementasikan dukungan untuk instance, perapian, dan aplikasi berfungsi. Jika tiba-tiba crash - yah, Kubernetes akan meluncurkannya lagi. Yaitu pengembang dan administrator bebas dari sakit kepala dan pelacakan konstan. Saya suka respons ini terhadap situasi. Ketika sesuatu jatuh, itu restart secara otomatis.
, , . — , , . .
– , ?: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .
– - kubernetes_ru. github, Kubernetes: . Postgres, .
, , , . , Kubernetes – , . - IT.
– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .:. .
, . , , . : , . , - . .
– . . , , .: . , . , , – . , , , , .
Yaitu . – , , 70% . . .
, , « », .
– . , , DBA : - , - — , ?: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .
DBA — - «» , .
Kubernetes. , . . , Kubernetes . , volume . Yaitu , . , .
– ?: .
, . , , . , Postgres ( ). Postgres - . Yaitu (, ), .
, .
, , . . . .
– ?: - . , , .
, Cassandra. . Yaitu — , Kubernetes.
, , . , , .
Yaitu . DBA, , – . , , - – .
– ?: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).
: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.
– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .: , , - high availability.
– . — , ?: , - .
Zalando DBA, patroni. Yaitu , Kubernetes , DBA .
– . DBA, DBA «» «».: , . . , , .
– - Kubernetes? ?: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).
- , , - - -.
: ( Kubernetes ), - . , — — . - , , , , , , .
:. Kubernetes , . , . .
, — . , Postgres- , , . .
: …
– .. : - — dev environment, production – Kubernetes. ...: latency , , . .
– , . .
, HighLoad++ .PS .