Manajemen Skema Dengan Skeema

Catatan: Posting ini berasal dari Tim Teknik SendGrid. Untuk posting teknik teknis lainnya seperti ini, lihat blogroll teknis kami.

Manajemen skema basis data berkisar dari barat yang liar, siapa pun dapat "melakukannya secara langsung" dalam proses produksi hingga proses peninjauan multi-tim multi-langkah seperti air terjun di mana hanya satu individu yang diurapi yang dapat menyentuh basis data produksi.

Karena data yang terkandung dalam basis data relasional menjadi lebih berharga bagi perusahaan dan ketersediaan basis data menjadi lebih penting bagi bisnis, hambatan terhadap perubahan skema pemutusan potensial muncul.

Sejak awal, Database Administrator (DBA) menjadi gatekeeper database untuk melindungi database dari hal-hal buruk yang terjadi. Tetapi memiliki DBA lama yang duduk di antara pengembang dan database aplikasi mereka dapat menyebabkan perlambatan yang signifikan dalam siklus hidup pengembangan aplikasi, menciptakan silo pengembangan dan operasi, dan menghasilkan gesekan antar tim.

Di dunia yang berorientasi pada pengembangan layanan mikro saat ini, pengembang harus dapat mengelola perubahan skema basis data sendiri karena itu adalah data mereka dan mereka pada akhirnya bertanggung jawab atas kinerja dan waktu aktif aplikasi. DBA dan tim Operasi perlu menyediakan alat dan saran yang sesuai untuk membantu tim pengembangan menjadi pemilik database mereka.

Bagaimana kami mengelola skema

Proses manajemen skema kami saat ini menggunakan repositori Git tunggal untuk menyimpan skema awal untuk semua klaster database kami dan berisi semua perubahan lanjutan pada skema tersebut saat perubahan/pembuatan dan penurunan tabel individual diterapkan:

• Pengembang membuat perubahan skema secara lokal dan menghasilkan pernyataan ubah/buat/lepas dan menambahkannya sebagai permintaan tarik ke cabang integrasi.
• Satu set tiket Jira untuk tim Operasi Data dibuat untuk meninjau dan menerapkan perubahan skema ke lingkungan pengujian/pementasan dan produksi kami.
• Seorang anggota tim Operasi Data meninjau perubahan yang diminta dan menerapkan perubahan ke lingkungan pengujian/pementasan dan menggabungkan PR ke cabang integrasi.
• Pengembang yang meminta menguji perubahan di lingkungan pengujian/pementasan kami dan menyetujui perubahan untuk didorong ke produksi.
• Terakhir, Operasi Data menggabungkan cabang integrasi untuk menguasai dan menerapkan perubahan skema ke lingkungan produksi.

Mengingat nilai data yang disimpan dalam basis data kami dan keinginan untuk memiliki basis data tersebut dan berjalan dengan baik sepanjang waktu, kami menetapkan urutan peristiwa Bizantium ini untuk melindungi diri kami dari diri kami sendiri.

Melindungi database adalah satu hal, tetapi proses ini menimbulkan beberapa rintangan untuk membuat perubahan skema dengan cara yang andal dan efisien:

• Meninjau dan membuat perubahan skema terjadi pada irama dua kali seminggu dan dapat dengan mudah tergelincir karena beberapa tim bekerja pada database yang berbeda semua dalam repositori Git yang sama dan setiap orang bergantung pada seseorang di tim Operasi Data untuk meninjau dan membuat perubahan pada berbagai lingkungan.
• Memiliki satu repositori untuk semua skema database relasional dapat menyebabkan proses rilis yang menantang. Perubahan pada satu skema yang siap produksi tidak dapat masuk ke produksi jika ada perubahan skema lain yang tidak siap untuk didorong ke produksi tetapi menunggu di staging menunggu pengujian tambahan.
• Tim Operasi Data, yang merupakan tim kecil, menjadi hambatan saat mencoba mengelola perubahan mana yang bisa dan tidak bisa masuk ke produksi dan kapan. Konflik penjadwalan dan ketersediaan personel benar-benar dapat memperlambat rilis fitur baru atau perbaikan untuk aplikasi saat ini.
• Kami menerapkan perubahan ini secara manual ke sistem produksi menggunakan komentar dalam permintaan tarik dan tiket Jira; terkadang copy paste bisa sangat salah.

Masukkan Skeema (dan beberapa pembantu)

Untuk menghilangkan rintangan proses ini, membuat perubahan skema kurang rentan terhadap kesalahan manusia, memungkinkan pengembang untuk mengelola skema aplikasi mereka sendiri, dan berpotensi meningkatkan kecepatan pengembangan, tim Operasi Data telah berupaya keras untuk mengotomatisasi dan merampingkan pengelolaan skema basis data.

Kami mengotomatiskan penerapan perubahan skema dari pengembangan lokal ke produksi menggunakan alat kami yang ada, Git, Buildkite CI, dan pt-online-schema-change, dengan tambahan satu lagi, Skeema.

Idenya adalah untuk memecah repositori skema DB monolitik kami menjadi repositori skema individu, satu per cluster database, dan memungkinkan pengembang untuk membuat perubahan skema mereka sendiri di lingkungan yang akrab bagi mereka. Kami juga ingin memiliki pagar pembatas yang waras untuk membantu pengembang mencari bantuan tambahan untuk membuat perubahan skema yang besar, kompleks, atau berpotensi merusak.

Skeema adalah alat CLI yang mengelola skema MySQL secara deklaratif menggunakan SQL.

Itu dapat menghasilkan bahasa definisi data (DDL) untuk setiap tabel dalam database dan mengekspor DDL ke sistem file lokal untuk integrasi dengan repositori pelacakan melalui Git. Skeema dapat membandingkan file SQL dalam repositori Git dengan database MySQL langsung dan menampilkan perbedaan tersebut sebagai pernyataan DDL.

Itu juga dapat dikonfigurasi untuk menggunakan alat pt-online-schema-change Percona dan memformat perintah pt-online-schema-change yang diperlukan untuk mencocokkan skema database MySQL yang sedang berjalan dengan skema yang ditentukan dalam repositori Git.

Skeema juga mampu mengelola skema di beberapa lingkungan, seperti lokal, pengujian, dan produksi dengan konfigurasi yang berbeda di masing-masing. Dan akhirnya, ini dapat dengan mudah disesuaikan dengan alur kerja berbasis permintaan tarik.

Membuat repositori skema database MySQL individu akan memecah repositori Git skema db monolitik kami saat ini dan memungkinkan pengembang di tim terpisah untuk mengelola skema MySQL aplikasi mereka di repositori mereka sendiri alih-alih repositori bersama (skema db).

Memiliki repositori terpisah untuk setiap skema database akan memungkinkan otonomi yang lebih besar bagi tim pengembangan aplikasi. Ini menghilangkan kebutuhan untuk mengoordinasikan semua perubahan skema ke jadwal yang kaku dan memungkinkan perubahan dipindahkan ke produksi sesuai keinginan tim aplikasi.

Komponen penting untuk mengotomatisasi proses ini adalah pipeline CI Buildkite. Kami membuat saluran pipa yang:

• Memeriksa kesalahan sintaks SQL
• Membuat server MySQL uji menggunakan cabang master skema database saat ini dan menguji penerapan perubahan dalam permintaan tarik (PR)
• Periksa perbedaan dan terapkan perubahan PR ke lingkungan pengujian MySQL kami
• Periksa perbedaan dan terapkan perubahan PR ke lingkungan pementasan kami dan keluarkan beberapa statistik tabel dari lingkungan produksi

Statistik keluaran produksi adalah ukuran tabel pada disk dan perkiraan jumlah baris. Statistik ini dapat membantu dalam menentukan apakah perubahan skema dapat menyebabkan beberapa tingkat gangguan layanan dan mungkin memerlukan penanganan khusus. Setelah PR digabungkan ke master, pipeline buildkite memeriksa perbedaan antara cabang master dan apa yang sedang berjalan dalam produksi.

Jika perbedaannya adalah perubahan yang diharapkan dari PR, pengembang dapat membuka blokir langkah terakhir ini dan Skeema menerapkan perubahan pada cluster database MySQL produksi. Masing-masing langkah ini merupakan langkah pemblokiran yang memerlukan persetujuan oleh tim teknik yang bertanggung jawab atas perubahan yang diminta sebelum pindah ke langkah berikutnya.

Sejauh menyangkut pagar pembatas, kami telah mengonfigurasi Skeema untuk tidak mengizinkan perubahan skema yang merusak dalam produksi sebagai default.

Perubahan destruktif diperbolehkan di lingkungan pengujian dan staging kami.

Kami juga mengonfigurasi Skeema untuk menggunakan pt-online-schema-change untuk membuat perubahan skema. Ini adalah alat perubahan skema yang sama yang dikenal oleh tim DataOps dan telah digunakan di SendGrid selama bertahun-tahun. Kami telah mengembangkan serangkaian opsi yang masuk akal untuk pt-online-schema-change untuk mengembalikan perubahannya jika replikasi tertinggal atau utas aktif dalam database menjadi berlebihan.

Memiliki Skeema yang dikonfigurasi dengan cara ini menghilangkan potensi kesalahan karena memiliki langkah-langkah manual untuk aplikasi dan pengkodean tangan perintah pt-online-schema-change oleh anggota tim DataOps.

Dengan penambahan pagar pembatas terprogram, masing-masing tim dapat bertanggung jawab atas pengelolaan skema database MySQL mereka dan penerapan perubahan tersebut pada lingkungan pra-produksi dan produksi dengan relatif aman. Jika pagar pembatas terkena, perubahan skema akan gagal dan dibatalkan. Alasan kegagalan perubahan skema adalah output ke log build untuk tinjauan tambahan.

Mengizinkan pengembang untuk mengarahkan perubahan mereka dari pengujian lokal pada laptop ke produksi sangat meningkatkan otonomi pengembang dan kepemilikan database yang mendukung aplikasi mereka. Otomatisasi dan integrasi Skeema ke dalam proses manajemen database MySQL kami dengan mudah mencakup sekitar sembilan puluh persen tugas manajemen perubahan skema umum kami.

Sebagian besar perubahan skema adalah untuk menambahkan kolom, mengubah bidang enum, mengubah default, dan menambahkan indeks. Sisa sepuluh persen dari perubahan skema berhubungan dengan kasus khusus dari tabel besar, database yang sangat aktif, atau tabel yang dipartisi. Pada posting ini, Skeema belum berurusan dengan membuat perubahan skema ke tabel yang dipartisi, tetapi saya mendengar ini adalah tambahan yang sering diminta dan pengembang Skeema secara aktif meminta bantuan untuk mengimplementasikan fitur itu.

Menggabungkan Git, pt-online-schema-change, Skeema, dan pipeline Buildkite CI menghadirkan proses terprogram yang andal, dapat diulang, ke perubahan skema database MySQL. Ini memberdayakan pengembang untuk mengelola skema database mereka dengan aman dan mengontrol seberapa cepat fitur dan perbaikan diluncurkan ke produksi.

Menyertakan pagar pembatas yang sesuai dalam file konfigurasi untuk perubahan Skeema dan pt-online-schema, memberikan ukuran kepercayaan bagi pengembang yang menerapkan perubahan skema dan memberikan umpan balik yang berharga tentang kemungkinan cara untuk melanjutkan perubahan skema jika pagar pembatas tersebut terkena.

Tim Operasi Data tetap tersedia untuk membantu sepuluh persen kasus yang tersisa yang proses ini tidak dapat diterapkan dan akan mengerjakan alat tambahan untuk meningkatkan proses ini di masa mendatang.