Skeema ile Şema Yönetimi

Not: Bu gönderi SendGrid'in Mühendislik Ekibinden gelmektedir. Bunun gibi daha fazla teknik mühendislik gönderisi için teknik blog listemize göz atın.

Veritabanı şeması yönetimi, üretim sürecinde herkesin "canlı olarak yapabileceği" vahşi bir batıdan, yalnızca bir meshedilmiş bireyin üretim veritabanına dokunabileceği şelale benzeri çok adımlı, çok ekipli inceleme sürecine kadar uzanır.

İlişkisel veritabanlarında bulunan veriler bir şirket için daha değerli hale geldikçe ve veritabanının kullanılabilirliği işletme için daha önemli hale geldikçe, olası şema değişikliklerinin kırılmasının önündeki engeller ortaya çıkar.

Önceleri, Veritabanı Yöneticileri (DBA'lar), veritabanını kötü şeylerden korumak için veritabanının kapı bekçileri oldular. Ancak geliştiriciler ve uygulamalarının veritabanı arasında eski tarz bir DBA'ya sahip olmak, bir uygulamanın geliştirme yaşam döngüsünde önemli bir yavaşlamaya neden olabilir, geliştirme ve operasyon siloları oluşturabilir ve ekipler arasında sürtüşme yaratabilir.

Günümüzün mikro hizmet geliştirme odaklı dünyasında, geliştiricilerin veritabanı şeması değişikliklerini kendi başlarına yönetebilmeleri gerekir, çünkü bunlar kendi verileridir ve uygulamanın performansından ve çalışma süresinden nihai olarak onlar sorumludur. DBA'lar ve Operasyon ekipleri, geliştirme ekiplerinin veritabanlarının sahibi olmalarına yardımcı olmak için uygun araçları ve tavsiyeleri sağlamalıdır.

Şemayı nasıl yönetiriz

Mevcut şema yönetimi sürecimiz, tüm veritabanı kümelerimiz için ilk şemayı depolamak için tek bir Git deposu kullanır ve bireysel tablo değiştikçe/oluşturuldukça ve damlalar uygulandıkça bu şemadaki tüm takip eden değişiklikleri içerir:

• Bir geliştirici yerel olarak bir şema değişikliği yapar ve bir değiştir/oluştur/bırak ifadesi oluşturur ve bunu bir entegrasyon dalına çekme isteği olarak ekler.
• Test/hazırlama ve üretim ortamlarımızda şema değişikliklerini gözden geçirmek ve uygulamak için Veri İşlemleri ekibi için bir dizi Jira bileti oluşturulur.
• Veri İşlemleri ekibinin bir üyesi, istenen değişikliği inceler ve değişikliği test etme/hazırlama ortamına uygular ve PR'yi entegrasyon şubesiyle birleştirir.
• Talepte bulunan geliştirici, değişikliği test/hazırlama ortamlarımızda test eder ve değişikliğin üretime aktarılmasını onaylar.
• Son olarak, Data Operations tümleştirme dalını master ile birleştirir ve şema değişikliğini üretim ortamına uygular.

Veritabanlarımızda depolanan verilerin değeri ve bu veritabanlarının her zaman iyi çalışır durumda olması arzusu göz önüne alındığında, kendimizi kendimizden korumak için bu Bizans olayları dizisini belirledik.

Veritabanını korumak bir şeydir, ancak bu süreç şema değişikliklerinin güvenilir ve verimli bir şekilde yapılmasının önünde birkaç engel oluşturur:

• Şema değişikliklerinin gözden geçirilmesi ve yapılması haftada iki kez gerçekleşir ve birden fazla ekip aynı Git deposunda farklı veritabanları üzerinde çalıştığından ve herkes çeşitli ortamları gözden geçirmek ve değişiklik yapmak için Veri İşlemleri ekibindeki birine bağımlı olduğundan kolayca raydan çıkabilir.
• Tüm ilişkisel veritabanı şemaları için tek bir havuza sahip olmak zorlu yayın süreçlerine yol açabilir. Üretime hazır olan bir şemada yapılan değişiklik, üretime gönderilmeye hazır olmayan ancak ek testler için aşamalandırmada bekleyen başka şema değişiklikleri varsa üretime gidemez.
• Küçük bir ekip olan Data Operations ekibi, hangi değişikliğin ne zaman üretime geçip geçemeyeceğini yönetmeye çalışan bir darboğaz haline gelir. Zamanlama çakışmaları ve personel kullanılabilirliği, mevcut uygulamalara yeni özelliklerin veya düzeltmelerin yayınlanmasını gerçekten yavaşlatabilir.
• Bu değişiklikleri, çekme taleplerinde ve Jira biletlerinde yorumları kullanarak üretim sistemlerine manuel olarak uyguluyoruz; bazen kopyala yapıştır korkunç derecede yanlış gidebilir.

Skeema'ya girin (ve birkaç yardımcı)

Bu süreç engellerini ortadan kaldırmak, şema değişikliklerini insan hatası olasılığını azaltmak, geliştiricilerin kendi uygulamalarının şemasını yönetmesine izin vermek ve potansiyel olarak geliştirme hızını artırmak için Veri İşlemleri ekibi, veritabanı şeması.

Mevcut araçlarımız Git, Buildkite CI ve pt-online-schema-change'i kullanarak yerel geliştirmeden üretime şema değişikliklerinin uygulanmasını, bir tane daha Skeema ekleyerek otomatikleştirdik.

Buradaki fikir, monolitik DB şeması depomuzu, her veritabanı kümesi için bir tane olacak şekilde ayrı şema havuzlarına bölmek ve geliştiricilerin tanıdıkları bir ortamda kendi şema değişikliklerini yapmalarına izin vermektir. Ayrıca, geliştiricilerin büyük, karmaşık veya potansiyel olarak yıkıcı şema değişiklikleri yapmak için ek yardım aramasına yardımcı olmak için makul korkuluklara sahip olmak istiyoruz.

Skeema, SQL kullanarak MySQL şemasını bildirimsel bir şekilde yöneten bir CLI aracıdır.

Bir veritabanındaki her tablo için veri tanımlama dili (DDL) oluşturabilir ve DDL'yi Git aracılığıyla bir izleme deposuyla entegrasyon için yerel bir dosya sistemine aktarabilir. Skeema, Git deposundaki SQL dosyalarını canlı bir MySQL veritabanıyla karşılaştırabilir ve bu farklılıkları DDL ifadeleri olarak çıkarabilir.

Ayrıca, Percona'nın pt-online-schema-change aracını kullanacak ve gerekli pt-online-schema-change komutunu, çalışan MySQL veritabanının şemasını Git deposunda tanımlanan şemayla eşleştirmek için biçimlendirecek şekilde yapılandırılabilir.

Skeema ayrıca yerel, test ve üretim gibi çeşitli ortamlarda şemayı her birinde farklı konfigürasyonlarla yönetebilir. Son olarak, çekme talebine dayalı bir iş akışına kolayca uyarlanabilir.

Bireysel MySQL veritabanı şeması depoları oluşturmak, mevcut monolitik db-şema Git depomuzu bozacak ve ayrı ekiplerdeki geliştiricilerin, uygulamalarının MySQL şemasını paylaşılan bir depo (db-şema) yerine kendi depolarında yönetmelerine olanak tanıyacaktır.

Her veritabanı şeması için ayrı bir havuza sahip olmak, uygulama geliştirme ekibine daha fazla özerklik sağlayacaktır. Bu, tüm şema değişikliklerini katı bir programa göre koordine etme ihtiyacını ortadan kaldırır ve değişikliklerin uygulama ekibinin istediği gibi üretime taşınmasına izin verir.

Bu süreci otomatikleştirmenin hayati bir bileşeni, Buildkite'ın CI boru hattıdır. Şunları sağlayan bir boru hattı oluşturduk:

• SQL sözdizimi hatalarını kontrol eder
• Veritabanı şemasının mevcut ana dalını kullanarak bir test MySQL sunucusu oluşturur ve çekme talebindeki (PR) değişikliklerin uygulamasını test eder.
• Farklılıkları kontrol edin ve PR değişikliklerini test MySQL ortamımıza uygulayın
• Farklılıkları kontrol edin ve PR değişikliklerini hazırlama ortamımıza uygulayın ve üretim ortamından bazı tablo istatistiklerinin çıktısını alın

Üretim çıktı istatistikleri, diskteki tablo boyutu ve tahmini satır sayılarıdır. Bu istatistikler, şema değişikliğinin bir miktar hizmet kesintisine neden olup olmayacağını ve özel işlem gerektirip gerektirmediğini belirlemeye yardımcı olabilir. PR master için birleştirildiğinde, buildkite ardışık düzeni ana dal ile üretimde çalışmakta olan arasındaki farkları kontrol eder.

Farklar PR'den beklenen değişikliklerse, geliştirici bu son adımın engellemesini kaldırabilir ve Skeema değişiklikleri üretim MySQL veritabanı kümesine uygular. Bu adımların her biri, bir sonraki adıma geçmeden önce talep edilen değişiklikten sorumlu mühendislik ekibinin onayını gerektiren bir engelleme adımıdır.

Korkuluklar söz konusu olduğunda, Skeema'yı varsayılan olarak üretimde yıkıcı şema değişikliklerine izin vermeyecek şekilde yapılandırdık.

Test ve evreleme ortamlarımızda yıkıcı değişikliklere izin verilir.

Ayrıca Skeema'yı şema değişiklikleri yapmak için pt-online-schema-change kullanacak şekilde yapılandırdık. Bu, DataOps ekibinin aşina olduğu ve SendGrid'de yıllardır kullanmakta olduğu şema değiştirme aracının aynısıdır. pt-online-schema-change için, çoğaltma geride kalırsa veya veritabanındaki etkin iş parçacıkları aşırı hale gelirse, değişikliklerini geri alması için bir dizi makul seçenek geliştirdik.

Skeema'nın bu şekilde yapılandırılması, DataOps ekip üyeleri tarafından pt-online-schema-change komutlarının uygulanması ve elle kodlanması için manuel adımlara sahip olmanın olası hatalarını ortadan kaldırır.

Programlı korkulukların eklenmesiyle, bireysel ekipler MySQL veritabanı şemalarının yönetiminden ve bu değişikliklerin üretim öncesi ve üretim ortamlarına göreceli güvenlikle uygulanmasından sorumlu olabilir. Korkuluklara vurulursa, şema değişikliği başarısız olur ve geri alınır. Şema değişikliği başarısızlığının nedenleri, ek inceleme için derleme günlüklerine gönderilir.

Geliştiricilerin bir dizüstü bilgisayardaki yerel testten üretime kadar olan değişiklikleri yönetmelerine izin vermek, geliştirici özerkliğini ve uygulamalarını destekleyen veritabanının sahipliğini büyük ölçüde artırır. Skeema'nın MySQL veritabanı yönetim sürecimize otomasyonu ve entegrasyonu, genel şema değişikliği yönetimi görevlerimizin yaklaşık yüzde doksanını kolayca kapsar.

Çoğu şema değişikliği sütun eklemek, numaralandırma alanlarını değiştirmek, varsayılanları değiştirmek ve dizin eklemek içindir. Şema değişikliklerinin kalan yüzde onu büyük tablolar, çok aktif veritabanları veya bölümlenmiş tablolar gibi özel durumlarla ilgilidir. Bu gönderi itibariyle, Skeema henüz bölümlenmiş tablolarda şema değişiklikleri yapmakla ilgilenmiyor, ancak bunun sıklıkla istenen bir ekleme olduğunu ve Skeema'nın geliştiricisinin aktif olarak bu özelliği uygulamak için yardım istediğini duydum.

Git, pt-online-schema-change, Skeema ve bir Buildkite CI ardışık düzenini birleştirmek, MySQL veritabanı şeması değişikliklerine güvenilir, tekrarlanabilir, programlı bir süreç getiriyor. Geliştiricilere, veritabanlarının şemasını güvenli bir şekilde yönetme ve özelliklerin ve düzeltmelerin üretime ne kadar hızlı sunulacağını kontrol etme yetkisi verir.

Skeema ve pt-online-şema değişikliği için yapılandırma dosyalarına uygun korkulukları dahil etmek, şema değişikliklerini uygulayan geliştiriciler için bir güven ölçüsü sağlar ve bu korkuluklar vurulursa şema değişikliğine devam etmenin olası yolları hakkında değerli geri bildirim sağlar.

Veri İşlemleri ekibi, bu sürecin uygulanamayacağı vakaların geri kalan yüzde onuna yardımcı olmak için hazır durumda ve gelecekte bu süreci geliştirmek için ek araçlar üzerinde çalışacak.