Menyulap ratusan dan ribuan database MySQL? Lempar mereka ke awan

Fitur Bersponsor Sejak debutnya hampir 30 tahun yang lalu, MySQL telah mengukir posisi yang patut ditiru di dunia database relasional. Proposisi open-source terus berjalan hampir sejajar dengan Oracle di pangsa pasar, sementara bisa dibilang memiliki keunggulan dalam popularitas dengan pengembang.

Namun, popularitas itu dapat menghadirkan tantangan, paling tidak adalah bahwa organisasi dapat menemukan diri mereka dengan database MySQL yang sangat luas. Ini bisa rumit untuk ditangani, baik dari segi teknis maupun manajemen, dan tidak selalu jelas bahwa “masyarakat” dapat memenuhi permintaan yang terus meningkat akan perkakas baru.

Pada saat yang sama, organisasi semakin mencari layanan cloud terkelola untuk mendukung infrastruktur data mereka, mengelola biaya, dan membebaskan spesialis database mereka untuk berkonsentrasi pada penambahan nilai daripada menghabiskan waktu mereka untuk tugas admin yang penting namun pada dasarnya rutin.

Jadi, mungkin tidak mengejutkan untuk mengetahui bahwa layanan dengan pertumbuhan tercepat dalam sejarah Amazon Web Services (AWS) adalah basis data relasionalnya, Amazon Aurora, yang sepenuhnya kompatibel dengan MySQL, kata Chayan Biswas, Manajer Senior Manajemen Produk untuk Amazon Aurora. Dan itu tidak sedikit karena keinginan pelanggan untuk mengkonsolidasikan beban kerja MySQL mereka yang luas dan meningkatkan efisiensi biaya dan operasional.

Aurora adalah database relasional yang sepenuhnya kompatibel dengan MySQL dan PostgreSQL, dibangun untuk cloud, dan dirancang untuk performa dan ketersediaan dalam skala global. Arsitektur dasarnya juga, kata Biswas, dibuat khusus untuk database relasional, memungkinkan AWS menawarkan “peningkatan ketersediaan, daya tahan, dan juga pengoptimalan.”

Komputasi dan penyimpanan dipisahkan, dan data disimpan di tiga Availability Zone, dengan masing-masing zona membawa dua salinan data. “Jadi, Anda mendapatkan enam eksemplar dengan harga satu,” katanya. “Dan itu juga memberi Anda daya tahan yang lebih baik. Data Anda didistribusikan, dalam lapisan penyimpanan yang dibuat khusus ini, ke dalam ratusan atau bahkan 1.000 node penyimpanan, bergantung pada ukuran database Anda.”

Dan ukuran database tersebut bisa sangat besar, dengan AWS mendukung penskalaan otomatis hingga 128 terabyte.

Tetapi memiliki skala besar di ujung jari Anda hanya berguna jika Anda dapat mengakses data Anda dengan cepat dan mengelolanya dengan mudah. Di sisi komputasi Aurora, kata Biswas, “Anda memiliki satu instans penulis utama, yang melakukan operasi baca dan tulis, dan hingga 15 replika baca latensi rendah dengan jeda biasanya kurang dari 30 milidetik. Jadi, Anda dapat menggunakan 15 ini replika baca untuk menskalakan beban kerja hanya-baca Anda.”

Membuat database Anda benar-benar global

Selanjutnya, AWS Basis Data Global Amazon Aurora teknologi menggunakan kemampuan lapisan penyimpanan yang sama dengan yang digunakan Aurora di suatu wilayah untuk mendistribusikan data hingga ke lima Wilayah AWS tambahan. Replikasi dilakukan melalui infrastruktur khusus di lapisan penyimpanan dengan kecepatan biasanya kurang dari satu detik, kata Biswas “Jadi, jika menyangkut pemulihan bencana, tujuan titik pemulihan, jumlah data yang berpotensi hilang adalah satu detik.” Dan waktu pemulihan, tambahnya, “kurang dari satu menit”.

Ini menawarkan dorongan besar atas replikasi asli MySQL, yang jauh lebih sulit untuk diskalakan pada tingkat yang sama. “Apa yang kami lihat adalah basis data Anda kehilangan hampir 50 persen throughput jika Anda mengaktifkan replikasi asli,” kata Biswas.

Aurora Global Database juga mendukung kemampuan pelanggan untuk menskalakan aplikasi mereka di seluruh wilayah. “Kami mendukung database global hingga di lima wilayah terpisah tanpa peningkatan overhead ke wilayah utama Anda. Jika Anda menerapkan aplikasi secara global, Anda dapat menjalankan beban kerja hanya baca di beberapa lokasi ini.”

Fitur lainnya adalah dukungan untuk penerusan tulis, yang memungkinkan pelanggan menerapkan aplikasi yang agnostik mengenai lokasinya, “Mereka juga dapat menerbitkan penulisan dari wilayah sekunder, dan ini diteruskan ke satu wilayah tempat Anda memiliki instans baca/tulis. “

Namun meskipun pengguna mungkin terkesan dengan tingkat skalabilitas dan volume penyimpanan mentah yang tersedia dengan Aurora, mereka mungkin juga mewaspadai manajemen kapasitas. Untuk mengurangi kekhawatiran, mereka memiliki opsi untuk memanfaatkan kemampuan Tanpa Server Aurora untuk Amazon Aurora Edisi yang Kompatibel dengan MySQL dan menyerahkan manajemen kapasitas komputasi ke Aurora, atau memilih untuk menyediakan instans reguler.

Pilihan itu bermuara pada keseimbangan biaya dan efisiensi operasional, kata Biswas. “Karena Anda tidak perlu lagi menyediakan beban kerja puncak Anda. Anda hanya membayar apa yang Anda gunakan.” Alternatifnya, “Jika Anda memiliki beban kerja yang stabil, tidak ada variabilitas … Anda akan mempertimbangkan untuk menggunakan instans yang disediakan, dan bahkan menggunakan instans cadangan untuk penghematan yang lebih besar.”

Amazon Aurora Tanpa Server membuat Aurora MySQL cocok untuk menangani sejumlah besar beban kerja dan basis data, yang telah menyebabkan lembaga keuangan besar dan vendor SaaS untuk menerapkannya,” kata Biswas. “Organisasi dengan sejumlah besar beban kerja basis data dapat menemukan keseimbangan yang tepat antara biaya dan operasional kompleksitas menggunakan Aurora Tanpa Server. Mereka dapat mengkonsolidasikan jumlah database yang tepat untuk efisiensi biaya sekaligus mengurangi biaya operasional yang diperlukan untuk pemantauan dan penyeimbangan ulang kapasitas untuk setiap database individu.”

Fitur utama lainnya untuk jenis organisasi ini, yang mungkin mendukung ribuan database, adalah Kloning Basis Data Cepat. Hal ini memungkinkan admin untuk dengan cepat membuat tiruan dari database, sesuatu yang akan merepotkan dengan perkakas MySQL asli, dan berpotensi melibatkan waktu henti selama berjam-jam.

Seperti yang dijelaskan Biswas, “Mungkin saja, dalam kelompok pelanggan yang Anda konsolidasi, beberapa menjadi lebih aktif, dan mulai lebih sering menggunakan layanan Anda.”

Masuk akal untuk “memisahkan” pelanggan ini, katanya, memberi mereka database mereka sendiri. Ini biasanya memakan waktu sekitar lima menit, kata Biswas, menggunakan salinan pada protokol tulis. “Artinya Anda tidak membayar untuk dua salinan database Anda. Sebaliknya, Anda hanya dikenai biaya untuk perubahan yang dilakukan pada klon.”

Ribuan dan ribuan?

AWS mengatakan bahwa Aurora Tanpa Server juga berguna untuk perusahaan besar dengan ribuan aplikasi yang menghasilkan lebih banyak penggunaan pada waktu tertentu, misalnya selama operasi akuntansi tertentu atau pada waktu penggajian menjelang akhir bulan.

Jika kedengarannya seperti memperluas batasan dari apa yang mungkin ingin dilakukan oleh suatu organisasi, pertimbangkan saja contoh vendor SaaS Acquia yang baru-baru ini memigrasikan platform Open Digital Experience ke Aurora. Ini melibatkan pemindahan 140.000 database MySQL yang mendukung 30.000 situs pelanggan. Perusahaan sebelumnya harus menyediakan database secara berlebihan hanya untuk memastikannya memenuhi perjanjian tingkat layanan (SLA) waktu aktif 99,95 persen. Namun beralih ke Aurora berarti dapat mengurangi biaya dan waktu henti, serta menugaskan kembali teknisi dari sekadar mengawasi dan mengelola platform.

Skalabilitas lebih lanjut dapat diperoleh melalui Proksi Amazon RDSyang tersedia untuk Amazon Aurora MySQL-Compatible Edition, dan dijelaskan oleh Biswas sebagai “proxy database sadar SQL yang terkelola sepenuhnya”.

RDS Proxy mengumpulkan dan berbagi koneksi database untuk meningkatkan skalabilitas aplikasi. Dengan pelanggan yang menjalankan puluhan ribu aplikasi yang terhubung ke beberapa database MySQL terkonsolidasi secara bersamaan, membuat setiap aplikasi membuka banyak koneksi database dapat menjadi hambatan.

“Jika Anda memiliki terlalu banyak koneksi dengan MySQL, komputasi, memori, jaringan, semua sumber daya tersebut digunakan hanya untuk mengelola koneksi ini,” jelas Biswas. RDS Proxy menanggung beban mengelola koneksi dari aplikasi, katanya, saat menggunakan kumpulan koneksi database untuk menangani kueri.

Failover yang lebih cepat meningkatkan ketersediaan

RDS Proxy juga semakin meningkatkan ketersediaan aplikasi, tambah Biswas. “Jika instance baca-tulis utama Anda gagal atau menjadi tidak tersedia, Aurora akan mendeteksinya dan secara otomatis melakukan failover ke salah satu dari 15 replika baca yang telah kita bicarakan.”

Jika failover terjadi, proxy akan mempertahankan koneksi yang dimilikinya, dan mengantri setiap permintaan yang dikirim selama failover terjadi. Dan setelah database aktif kembali, itu akan terhubung kembali dan melanjutkan. Selain meningkatkan ketersediaan, ini juga meniadakan efek penundaan propagasi Domain Name System (DNS) dan membuat failover hingga 66 persen lebih cepat, menurunkannya hingga 10 detik atau kurang, kata Biswas.

Hal ini membuat RDS Proxy cocok untuk aplikasi yang sangat skalabel yang dibangun menggunakan teknologi tanpa server modern seperti AWS Lambda, kata Biswas, sementara AWS juga menawarkan Driver AWS Java Database Connectivity (JDBC) untuk MySQL yang dapat digunakan oleh aplikasi stateful untuk penggabungan koneksi dan failover yang lebih cepat.

Sementara Aurora MySQL menawarkan fitur yang lebih baik dibandingkan MySQL komunitas, itu juga sepenuhnya kompatibel dengan alat pihak ketiga dan MySQL asli. Itu berarti pelanggan dapat menggunakan alat yang sudah dikenal seperti MySQL Dump atau Pencadangan XtraDB Percona untuk memulai migrasi mereka ke Aurora dengan membuang data mereka ke bucket S3. Atau mereka hanya bisa menggunakan Layanan Migrasi Database AWS (DMS)untuk memigrasikan database dan kemudian terus merekam perubahan yang terjadi di database sumber.

Tentu saja, pengembangan aplikasi modern semakin berpusat pada layanan mikro dan penerapan berbasis kontainer. Jadi AWS menawarkan ekstensi perangkat lunak operator Kubernetes open source untuk mendukung alat asli untuk membuat database Aurora di lingkungan Kubernetes. “Kamu dapat memakai Pengontrol AWS untuk Kubernetes (ACK) untuk menyediakan dan terhubung ke database Aurora. Anda tidak harus keluar dari perkakas Kubernetes asli Anda, dan, faktanya, Anda dapat menggunakan jaringan pipa DevOps Anda untuk terus menerapkan lingkungan kontainer serta database Anda atau menyiapkan konektivitas,” jelas Biswas.

Kompatibilitas dengan alat pihak ketiga adalah salah satu faktor yang membuat MySQL begitu populer di kalangan pengembang. Dan fleksibilitas serta kemudahan penggunaan juga merupakan fitur yang ingin ditingkatkan oleh AWS dengan Aurora.

“Jika Anda memiliki aplikasi yang dibuat untuk MySQL atau PostgreSQL, Anda seharusnya dapat menggunakan Aurora dengan sedikit atau tanpa perubahan,” simpul Biswas.

Disponsori oleh AWS.

Leave a Comment