PostgreSQL veritabanı geçişi 11 saniyelik kesintiyle tamamlandı

 (gds.blog.gov.uk)
2 puan yazan GN⁺ 2024-01-19 | 1 yorum | WhatsApp'ta paylaş
  • GOV.UK Notify, PaaS’in kapanışına hazırlanırken 400 GB PostgreSQL 11 veritabanını kendi AWS hesabındaki PostgreSQL 15 RDS’ye taşıdı ve kesintiyi yaklaşık 11 saniyeye indirdi
  • Hedef veritabanında önce yalnızca tablolar oluşturuldu; veriler DMS full load ile kopyalandıktan sonra indeksler ve anahtar kısıtları uygulanarak büyük ölçekli yükleme süresi azaltıldı
  • Kaynak veritabanı yaklaşık 1,3 milyar satır, 85 tablo, 185 indeks ve 120 foreign key ölçeğindeydi; hafta içi saniyede yaklaşık 1.000 ekleme/güncelleme ve buna benzer sayıda okuma gerçekleşiyordu
  • Uygulama yeniden dağıtımı yaklaşık 5 dakika sürdüğü için aynı kimlik bilgileri ve Route53 DNS ağırlık geçişi önceden hazırlandı; böylece gerçek geçiş süresi kısaltıldı
  • DMS, PaaS ve AWS desteği almayı kolaylaştırdığı için seçildi; ancak PostgreSQL’den PostgreSQL’e geçişte pglogical gibi alternatiflerin daha basit olabileceği ihtimali var

PaaS’in kapanışına uygun Notify veritabanı geçişi

  • GOV.UK Notify, GOV.UK Platform as a Service üzerinde barındırılıyordu ve PaaS’in kapanması nedeniyle tüm altyapının kendi AWS hesaplarına taşınması gerekiyordu
  • Notify’nin veritabanı, PaaS AWS hesabındaki AWS RDS PostgreSQL idi; bildirim gönderim verilerinden hizmet ekiplerinin kullandığı yüz binlerce şablonun içeriğine kadar her şeyi saklıyordu
  • Geçişte mevcut veritabanı source database, yeni veritabanı ise target database olarak ayrıldı
  • Temel zorluk yeni bir PostgreSQL veritabanı oluşturmak değil, tüm verileri taşırken ve uygulamanın bağlanacağı hedefi değiştirirken kesinti süresini en aza indirmekti

Kaynak veritabanının ölçeği ve hizmet kısıtları

  • Kaynak veritabanı yaklaşık 400 GB büyüklüğünde PostgreSQL 11 idi
    • Yaklaşık 1,3 milyar satır
    • 85 tablo
    • 185 indeks
    • 120 foreign key
  • Sıradan bir hafta içi saniyede yaklaşık 1.000 ekleme veya güncelleme gerçekleşiyor, benzer sayıda okuma da yapılıyordu
  • GOV.UK Notify her gün sel uyarıları ve pasaport başvurusu durumları gibi önemli ve zamana duyarlı milyonlarca bildirim gönderiyor
  • Tüm bildirim gönderimleri veritabanı erişimi gerektirdiği için hizmet kesintisinin kısa tutulması gerekiyordu

DMS ile kurulan ilk yükleme ve sürekli çoğaltma yapısı

  • PaaS ekibi, AWS Database Migration Service kullanan bir veritabanı geçiş yöntemi sundu
  • DMS, verileri kaynak veritabanından hedef veritabanına taşır ve kaynak ya da hedef AWS hesabında çalıştırılabilir
  • DMS işi iki aşamaya ayrılır
    • full load: Belirli bir ana kadar var olan tüm verileri tablo bazında kopyalar
    • sürekli çoğaltma: Kaynak veritabanındaki yeni transaction’ları hedef veritabanında yeniden oynatarak iki veritabanını senkronize eder
  • Uygulamanın kaynak veritabanı yerine hedef veritabanını kullanacak şekilde geçirilmesi işini Notify ekibi doğrudan üstlendi

Hedef veritabanının hazırlanması ve full load

  • DMS instance’ı kaynak AWS hesabında oluşturuldu
    • PaaS ekibi hesap içinde DMS instance’ını zaten kurmuş olduğundan hızlıca hazırlanabildi
    • DMS instance’ının kaynak ve hedef PostgreSQL veritabanlarına bağlanabilecek kimlik bilgilerine ihtiyacı vardı
  • DMS instance’ı ile hedef veritabanı farklı VPC’lerde olduğu için VPC peering yapılandırıldı; böylece PaaS VPC’sinden gelen DMS trafiği genel internete çıkmadan kendi VPC’lerine yönlendirildi
  • Hedef RDS instance’ı kendi AWS hesaplarında oluşturuldu; PostgreSQL 11 desteğinin sona ermesi yaklaştığından yeni veritabanı PostgreSQL 15 olarak yapılandırıldı
  • Kaynak veritabanı şeması pg_dump ile dump edilerek şemayı yeniden oluşturacak SQL dosyası üretildi ve başlangıçta hedef veritabanına yalnızca tablo tanımları uygulandı
  • Foreign key’ler full load sırasında uygulanmadı
    • Çünkü DMS full load, verileri foreign key kısıtlarının sırasına göre kopyalamaz
  • Primary key’ler ve indeksler de full load’dan önce oluşturulmadı
    • Her eklemede indeks güncellemesi gerekeceğinden, milyarlarca satır yüklenirken toplam süre ciddi ölçüde uzayabilirdi
    • Önce tüm verileri kopyalayıp sonra indeks eklemek daha hızlıydı
  • Full load işi, başlat düğmesine basıldığı anda var olan verileri kopyaladı
    • Ondan sonra oluşan yeni veriler veya güncellemeler full load’a dahil edilmedi
    • Full load’ın tamamlanması yaklaşık 6 saat sürdü
  • Full load’dan sonra kalan şema dosyası uygulanarak indeksler ve anahtar kısıtları eklendi; bu işlem yaklaşık 3 saat sürdü

10 gün çoğaltmayı sürdürdükten sonra trafiğin geçirilmesi

  • Full load tamamlandığında hedef veritabanı, full load’ın başladığı andaki kaynak veritabanıyla eşleşiyordu; ancak sonrasında kaynakta ekleme, güncelleme ve silmeler devam etti
  • DMS’in sürekli çoğaltma, yani change data capture işi başlatılarak full load’ın başlangıcından sonraki kaynak veritabanı transaction log transaction’ları hedef veritabanına gönderildi
  • Çoğaltma sürecinin arayı kapatması birkaç saat sürdü; sonrasında DMS çoğaltma gecikmesi izlenerek senkronizasyon durumu kontrol edildi
  • DMS çoğaltması yaklaşık 10 gün boyunca arka planda çalıştı ve kullanıcılara önceden duyurulan trafik geçişi anına kadar iki veritabanını senkronize tuttu
  • Trafik geçiş prosedürü önceden Python betikleriyle yazıldı
    • Kaynak veritabanına giden uygulama trafiği durdurulur
    • Çoğaltmanın tamamen arayı kapatıp kapatmadığı kontrol edilir
    • Uygulamanın hedef veritabanına bağlanmasına izin verilir
  • Uygulamaların bir kısmının kaynak DB’yi, kalanının hedef DB’yi kullandığı bir durumdan kaçınılması gerekiyordu
    • Çünkü hedef DB’de oluşan değişiklikler kaynak DB’ye yansımayacağı için kullanıcılar tutarsız veriler görebilirdi
  • Betik, manuel işlemlere göre daha açık, tekrarlanabilir ve hızlı çalışacak şekilde hazırlandı; ön testlerde ve provalarda en az 40 kez kullanıldı
  • Hedef kesinti süresi 5 dakikanın altıydı ve migrasyon zamanı gece yarısından kaçınılarak, görece sakin bir cumartesi akşamına alındı

11 saniyelik kesintiyi sağlayan DNS geçişi

  • Kaynak veritabanı trafiğinin durdurulması, uygulama bağlantıları için pg_terminate_backend çağrılarak yapıldı ve 1 saniyeden kısa sürdü
  • Uygulamanın kaynak DB’ye yeniden bağlanmasını engellemek için PostgreSQL kullanıcı parolası da değiştirildi; böylece yeniden bağlantıda kimlik doğrulama hatası oluştu
  • DMS hedef veritabanında çoğaltma durumu tablosu oluşturup bunu her dakika güncelliyordu; migrasyon betiği kaynak ve hedef arasındaki gecikmeyi bu tabloyla kontrol etti
  • Ek bir güvenlik önlemi olarak, uygulama kaynak DB’ye erişmeyi bıraktıktan sonra betik kaynak DB’ye tek bir kayıt yazdı ve bunun hedef DB’ye ulaşmasını bekledi
  • Uygulamanın veritabanı bağlantı bilgisi SQLALCHEMY_DATABASE_URI ortam değişkeniyle sağlanıyordu
    • Mevcut biçim, kullanıcı adı, parola ve RDS konumunu içeren postgresql://...@random-identifier.eu-west-1.rds.amazonaws.com:5432 biçimindeydi
    • Veritabanı konumunu veya kimlik bilgilerini değiştirmek uygulamanın yeniden dağıtılmasını gerektiriyordu ve yeniden dağıtım yaklaşık 5 dakika sürüyordu
  • Yeniden dağıtımdan kaynaklanacak ek kesintiyi önlemek için migrasyondan önce iki şey hazırlandı
    • Kaynak ve hedef veritabanlarında aynı kullanıcı adı ve parolaya sahip kullanıcılar oluşturuldu
    • AWS Route53 üzerinde database.notifications.service.gov.uk DNS kaydı oluşturuldu ve TTL 1 saniye olarak ayarlandı
  • DNS kaydında başlangıçta ağırlık kaynak için %100, hedef için %0 olarak bırakıldı
  • Uygulama URI’si önceden ortak kullanıcı adı/parola ve yeni alan adını kullanacak şekilde değiştirildi
  • Gerçek geçiş sırasında betik AWS’in DNS ağırlığını hedef için %100’e çevirdi ve 1 saniyelik TTL’nin dolmasını bekledi
  • 4 Kasım 2023 Cumartesi akşamı yapılan geçiş anında hedef veritabanı ile kaynak veritabanı arasındaki gecikme birkaç saniye düzeyindeydi
  • Migrasyon betiğinin çalışması sonucunda uygulama kaynak DB’ye erişmeyi bıraktı ve yeni hedef DB’yi kullanmaya başladı; kesinti yaklaşık 11 saniye oldu

DMS seçiminin değerlendirilmesi ve sonraki işler

  • DMS, GOV.UK PaaS tarafından iyi desteklendiği ve AWS desteği de alınabildiği için seçildi
  • Gelecekte PostgreSQL’den PostgreSQL’e bir veritabanı geçişi tekrar yapılırsa pglogical gibi alternatif araçların daha fazla incelenmesi planlanıyor
  • DMS, diğer araçlara kıyasla daha fazla karmaşıklık ve alışık olunmayan bir çoğaltma süreci eklemiş olabilir
  • Veritabanı geçişinden sonraki aşama uygulama geçişi
  • GOV.UK Notify uygulaması AWS Elastic Container Service’e taşınacak; süreç daha sonra paylaşılacak

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-19
Hacker News yorumları

  • Biz de benzer bir geçişi AWS RDS Blue-Green Deployments ile yaptık; veritabanı biraz daha büyüktü ama kesinti süresi yaklaşık 20 saniyeydi ve iş yükü de çok daha azdı. Bu başlıkta henüz bahsedilmemiş olmasına şaşırdım.
    Temelde, istediğiniz değişiklikleri içeren yeni bir Blue/Green deployment ayağa kaldırıyorsunuz; mevcut blue yapı trafiği işlemeye devam ederken AWS, green deployment’ı mantıksal replikasyon ile senkronize ediyor.
    Green tarafına yazma yapmadığınız sürece değişiklik, test ve yük testi de yapabiliyorsunuz; yazmalar canlı olan blue’ya gitmeye devam ediyor ve ardından green’e replike ediliyor.
    Hazır olduğunuzda switch komutunu çalıştırıyorsunuz; AWS senkronizasyon kontrolünü, yazmaların ve bağlantıların kesilmesini, replikasyonun yetişmesini beklemeyi, veritabanı adlarının değiştirilmesini, bağlantıların ve yazmaların yeniden başlatılmasını hallediyor.
    Bizim ölçümümüze göre kesinti 20 saniyenin altındaydı ve primary ile birden çok okuma replikası dahil tüm yapı sorunsuz geçti. AWS veritabanı URL’sini de değiştirdiği için ayar değiştirmemize gerek kalmadı; green blue oluyor, eski blue da old blue oluyor ve sonra silebiliyorsunuz.
    Kesinlikle öneririm, ancak hesaplar arası taşıma gibi durumlarda çalışmayabilir; bazı sınırlamalar var: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-...

    • Blue/Green için +1. Yine de bu örnekte hesaplar arası taşıma nedeniyle kullanılamamış olabilir. Hem MySQL hem de Postgres’te kullandım; MySQL tarafında saniyedeki sorgu sayısı yazıdakinden iki basamak daha yüksekti, ikisi de sorunsuz geçti.
      Dokümantasyonu, özellikle de sınırlamaları tekrar tekrar okumak gerekiyor. Geliştirme ortamında yük altındayken test çalıştırmak, ardından staging’de tekrar denemek iyi olur.
      Ya da doğrudan prod’a YOLO şeklinde de koyabilirsiniz, muhtemelen sorun çıkmayabilir.
    • MySQL 5.7’den 8.0’a major engine version upgrade yaparken RDS Blue/Green deployment kullandık; kesinti süresi açısından harikaydı. API’de gözlenen kesinti sanırım yaklaşık 13 saniyeydi.
      Ancak RDS Blue/Green’in rastgele herhangi bir değişiklik için kullanılamayacağını zor yoldan öğrendik. Bizim durumda bunun yalnızca engine version yükseltmek için kullanılabildiğini, düşürmek için kullanılamadığını fark ettik.
      MySQL 8.0’da bir stored procedure çok nadiren hata verdiği için 5.7’ye geri dönme seçeneğini değerlendirdik, ama bu mümkün değildi.
    • Daha önce şifrelenmemiş RDS storage’ı Blue/Green ile şifreleyen biri var mı merak ediyorum.
    • Veritabanına erişen uygulamayı nasıl durdurup yeniden başlattıklarını merak ediyorum. ECS’te çalışan birden fazla task var; kapanmaları 1 dakika, tekrar ayağa kalkmaları birkaç dakika sürebiliyor.
    • Route53 Groups ve Blue/Green kurulumu için +1. Biz de PostgreSQL yükseltmesinde benzer şekilde yaptık; AWS R53 groups ve kendi Rails ActiveRecord transaction yamamızla, işlem sırasında devam eden sorguları yeniden deneyerek kesintisiz hallettik.
      Ödün olarak, birkaç saniye boyunca bazı istekler yavaşladı.
      DNS Groups ile retry kombinasyonu bu tür işler için oldukça kullanışlı bir mekanizma.
      Kullandığımız araç: https://github.com/shayonj/pg_easy_replicate

  • Gelen Postgres sorgularını “duraklatmanın” birkaç yolu var; örneğin pgbouncer kullanarak, sorguları başarısızlığa düşürmeden replikasyon yetişene kadar geciktirip sonra yeni veritabanında devam etmelerini sağlayabilirsiniz.
    Bir şeyler ters gider ve replikasyon yetişemezse duraklatmayı kaldırıp bu sorguların eski veritabanında çalışmasını sağlayabilirsiniz.
    Böylece 11 saniyelik kesinti, 0–11 saniyelik ek sayfa yüklenme süresine dönüşür. Daha önemlisi, şimdiye kadar hiç sorgu hatası görmemiş binlerce veritabanı kullanıcısı içinde hatalı bir error handling yolu varsa ya da tek bir başarısız sorgu tüm batch job’ı bozuyorsa bile ikincil zarar çok daha azalır.

    • Sorguları durdurmak mümkün olabilir, ama halihazırda devam eden transaction’ları da durdurmanın mümkün olup olmadığını merak ediyorum. Bu nasıl çalışıyor?

  • https://knock.app/blog/zero-downtime-postgres-upgrades ile karşılaştırınca ilginç. İlgili tartışma https://news.ycombinator.com/item?id=38616181 adresindeydi.
    O dönemde tartışmaların önemli bir kısmı “birkaç dakikalık kesintiden kaçınmak için fazla karmaşık değil mi?” noktasına varmıştı. Bu örnek bir tür kanıt gibi görünüyor; AWS Data Migration Service kullanıp DNS kaydını değiştirerek üretime devrettikten sonra 11 saniyelik kesintiyi kabul etmek yeterli gibi duruyor.

    • Burada “sadece” diye bir şey yok. Asıl ders “öğrenilenler” bölümünde yer alıyor.

      DMS’i seçmemizin nedeni GOV.UK PaaS üzerinde iyi desteklenmesi ve AWS desteği alabilmemizdi. İleride PostgreSQL’den PostgreSQL’e bir veritabanı taşıyacak olursak pglogical gibi alternatif araçları değerlendirmek için daha fazla zaman ayırırız. DMS, başka araçlarda yaşayacağımızdan daha fazla karmaşıklık ve alışık olmadığımız replikasyon süreçleri eklemiş olabilir. Bu, AWS’in PostgreSQL’ler arası geçişler hakkında doğrudan söyledikleriyle de uyumlu.
      Buradaki mesaj “sadece DMS kullanın” değil.

    • https://cloud.google.com/database-migration/docs/postgres/qu... ile benzer bir iş yapmış olan var mı merak ediyorum. AWS DMS’e benzer şekilde mi çalışıyor?
    • DMS içeride pglogical kullanıyor gibi görünüyor ama birçok tuzağı var. Donanım düzeyinde replikasyon olmadığı için büyük satırlar, büyük sütunlar ve büyük tablolar sorun çıkarabilir; yabancı anahtarları da düzgün ele alamaz.
      Bazı özel veri tiplerini hiç işleyemeyebilir. Geçişten sonra sequence’ların da güncellenmesi gerekir; aksi halde yinelenen birincil anahtar hataları oluşabilir.
      Uygun bir birincil anahtar yoksa, tüm satırı her zaman tek seferde kopyalamadığı için de sorun çıkabilir.
      Veritabanları aynı AWS hesabı içindeyse ve 4-5 dakikalık kesintiyi kabul edebiliyorsanız, global database ya da snapshot kullanarak donanım düzeyinde replikasyon muhtemelen daha kolay olabilir.

  • Yakın zamanda kendi barındırdığımız 3 TB PostgreSQL veritabanını 12’den 16’ya taşıdık ve Ubuntu 18’den Ubuntu 22’ye geçtik. Aynı anda çeşitli eklentileri de yükseltmemiz gerekiyordu; özellikle Timescale için tüm kombinasyonları karşılayan uyumlu bir sürüm yoktu.
    Bunu salt okunur bir replikayı yükselterek yaptık: başlangıçta PG12, Ubuntu 18, TS2.9 vardı; önce Ubuntu 22 üzerinde PG12 ve TS2.9’u koruyan salt okunur bir replika oluşturduk.
    Ardından bakım moduna geçip tüm servisleri durdurduk, salt okunur replikayı ayırdık ve Ubuntu 22 üzerinde PG12’yi PG15’e yükselttik, TS2.9’u ise koruduk.
    Sonra PG15 ve TS2.9’dan TS2.13’e yükselttik; son olarak Ubuntu 22 üzerinde PG15’i PG16’ya yükseltirken TS2.13’ü koruduk.
    En sonunda servisleri yeni veritabanı sunucusuna yeniden bağladık, tüm servisleri tekrar başlattık ve bakım modundan çıktık.
    Tüm veritabanı yükseltme adımlarını Ansible ile yeterince test edip otomatikleştirmiştik, ancak test sırasında ortaya çıkmayan bir sorun yaşandı ve kesinti yaklaşık 30 dakikaya uzadı. Bizim kullanımımız için bu tamamen kabul edilebilir düzeydeydi.
    Mantıksal replikasyon kullansaydık son andaki beklenmedik sorunu azaltabilirdik; bir sonraki yükseltme döngüsünde bu yaklaşımı değerlendirmeyi planlıyoruz.

    • Biz de yakın zamanda neredeyse aynı yükseltme yolunu izledik. Ancak o sırada Timescale henüz PG16’yı desteklemediği için PG15 + TS 2.12 seviyesinde durduk.
      Yükseltme kesintisini azaltmak için mantıksal replikasyonu da değerlendirdik, ancak veritabanı şeması ve DDL komutları replike edilmediğinden Timescale işin içindeyken önerilmiyor gibi görünüyordu.
      Timescale’in içeride yapması gereken temel şema değişiklikleri büyük ölçüde hypertable chunk boyutu ve gelen yazma deseninin bir fonksiyonu olacağından planlanabilir ya da zamanlaması ayarlanabilir; fakat bunun potansiyel karmaşıklığını ve riskini, pg_upgrade tamamlanırken kısa bir bakım penceresi ayırmaya kıyasla fazla yüksek gördük.

  • Bu tür düşük kesintili ya da kesintisiz geçişlerin düşmanı uzun süren sorgulardır.
    Örneğin 30 dakika süren tek bir update sorgunuz varsa, ya o sorguyu öldürüp geri almanız ya da 30 dakikalık erişilebilirlik kaybını kabul etmeniz gerekir.
    Bildiğim kadarıyla hâlen çalışmakta olan sorguları taşımanın bir yolu yok.

    • Bir yazılım mühendisliği projesiyse transaction sürelerini bundan çok daha kısa sınırlamak daha iyidir. statement_timeout ayarı dostunuzdur.
      Aşırı uzun transaction’larınız varsa, muhtemelen geçişi onların çalışmadığı bir zamana denk getirebilirsiniz. Umarım rastgele ortaya çıkan şeyler değil de zamanlanmış işler gibi sonuçlardır.
      Transaction zaman sınırı, eski primary’yi fail ettirmek gibi failover yapılandırmaları ve pgbouncer benzeri şeylerin birleşimiyle, kesinti yerine yavaşlama süresini oldukça hassas biçimde kontrol edebilirsiniz.
      Açıkçası beni daha çok endişelendiren, tüm stack’in ve bağımlı olunan harici önbellek DNS sunucularının DNS TTL’e gerçekten uyup uymadığı.
      Ama uygulamalarda genellikle 10 saniye civarı kesintiden kaçınmak kritik değildir; bu yüzden sizin için daha basit olan çözümü seçmek daha doğru.
    • Şahsen 30 dakikalık bir update sorgusunun aşırı verimsiz yazılmadığı ya da tek seferlik büyük ölçekli bir veri geçişi olmadığı bir durumu hayal etmekte zorlanıyorum.
      Elbette ilki gerçekte çok sık var. Dakikalar ya da saatler süren işleri milisaniyelere indirmekten epey keyif aldım.
    • Yeni bir şey öğrendim. 30 dakikadan uzun süren yazmaların nasıl bir niteliği olduğunu merak ediyorum.
      Hangi veriler ve hangi insanlar böyle veritabanı yazmalarıyla uğraşıyor da, üst katmanda kuyruğa alıp daha küçük parçalara bölmek yerine DB motorunun bu kadar uzun çalışmasına bel bağlıyor, merak ediyorum.

  • AWS Route53’te database.notifications.service.gov.uk için 1 saniyelik TTL’e sahip bir DNS kaydı oluşturup, geçiş betiğinin AWS’in DNS ağırlığını hedef veritabanı konumuna %100 gönderecek şekilde değiştirmesi ve ardından TTL’in dolması için 1 saniye beklemesi kısmı tuhaf
    O zaman uygulama bir sonraki kez veritabanına sorgu atmaya çalıştığında hedef veritabanını sorgulayacak denmiş; bu, ORM’lerinin ya da Python’ın varsayılan davranışının her sorguda DNS sorgusu yapıp bloklandığı anlamına mı geliyor?
    Çözümlenen adresi belli bir süre önbelleğe bile almıyor, bağlantı havuzu ya da yeniden kullanım da yapmıyorlar mı?

    • Muhtemelen bu davranışı OS’in getaddrinfo ya da gethostname çağrıları gösteriyordur. Python sistem düzeyi çağrıları pek yeniden uygulamadığı için sistem ayarlarına bağlıdır
      1 saniyelik TTL’e uyulduysa 1 saniye boyunca önbelleğe alınmıştır; ama DNS sorgulama kütüphanelerinin ve özellikle önbellekleyen DNS sunucularının TTL’e tamamen uymaması da nadir değil. Açıkçası gözlemlenen kesintinin bir kısmını bu açıklıyor olabilir

  • Güzel. Biz de az önce RDS’te yaklaşık 2 TB veri ve 8 veritabanı içeren 3 Postgres kümesini Postgres 14’ten 16’ya geçirdik. 00:00’dan 04:00’a kadar kapalı kaldı
    Önce Cloudflare Workers üzerinde çalışan çok hafif bir yedek site olan “bakım modu”nu açtık ve Terraform ile veritabanına yazan tüm uygulamaları 0’a ölçekledik
    AWS web arayüzünde yükseltme düğmesine basıp pg_upgrade ile 14→15’i çalıştırdık ve bitmesini bekledik; sonra tekrar basıp 15→16’yı yaptık
    Veritabanının bağlantı kabul etmeye başlamasını bekledik; ready olarak görünmeden önce de bağlantı kabul ediyor gibiydi ve AWS’in pg_upgrade dışında başka şeyler de yaptığı anlaşılıyordu
    Ardından VACUUM ANALYZE; REINDEX DATABASE CONCURRENTLY başlattık. Amaç, sürümler arası performans sorunlarından kaçınmak ve yeni sürümün performans iyileştirmelerinden yararlanmaktı
    Uygulamaları tekrar ayağa kaldırmaya başladık; tüm uygulamalarda birkaç konteynerin çalıştığını gördükten sonra trafik almaya başladık, bakım sitesini kapattık ve yatmaya gittik
    REINDEX CONCURRENTLY en büyük veritabanında 18 saat daha çalıştı ama hiçbir şeyi engellemedi
    Bir dahaki sefere kesintiden kaçınmak için AWS Blue/Green dağıtımı kullanmayı planlıyoruz. Bu kez Blue/Green’in desteklediği 14 için en düşük minör sürüm olan 14.9’da olmadığımızdan kullanamadık
    Kendim yapacak olsam AWS’e para vermeden, mantıksal replikasyon ve yük dengeleyiciyle Blue/Green’i kendim kurardım

    • Ben olsam yerinde yükseltme için pg_upgrade --hardlinks kullanırdım
      Kendi on-premises Postgres instance’larımızda 2 TB DB’yi 1 dakikadan kısa sürede işlediğim oldu

  • GOV.UK Notify, GDS’in Birleşik Krallık kamu kurumlarına sunduğu hizmet paketinin bir parçası. GOV.UK Pay ve GOV.UK PaaS de bunun içinde; eskiden Government As A Platform olarak biliniyordu

  • DMS berbat bir geçiş aracı. Çeşitli geçiş sorunlarıyla neredeyse bir ay uğraştıktan sonra vazgeçtik
    text ve json tiplerini taşıyamadı; AWS desteği de çözüm sunamadı
    AWS Blue/Green’i ilk test aşamasında kullandık ve bu sayede neredeyse kesintisiz yükseltme gerçekçi hale geldi

    • DMS’in kötü bir geçiş aracı olduğunu düşünüyorsanız, bir de harici hedeflere sürekli replikasyon için kullanmayı deneyin
      Tamamen bozuk

  • İlginç, ama devletin en başta neden AWS kullandığını anlamıyorum. Bu, ürün-pazar uyumunu bulmaya çalışan, hack’leyerek ilerleyen bir startup değil; pazarlama kaynaklı trafik patlamasını öngöremeyip tepki vermeye çalışan bir durum da değil
    Böyle bir hizmete uzun vadede ihtiyaç olduğunu biliyorlar ve kullanım kalıpları da oldukça iyi tahmin edilebilir
    Kamu sektörü bulutu kurabilirler ya da makul bir on-premise yaklaşımı benimseyebilirler. Para, koordinasyon ve teknik liderlik gerektirir ama uzun vadede vergi mükelleflerine muazzam maliyet tasarrufu sağlar
    Kamu sektörü IT’si genel olarak karmakarışık, ama orada çalışan iyi mühendisler olduğunu da biliyorum

    • Bir startup olarak “bulut”, yani PaaS kullanmamızın nedeni trafik patlamalarını karşılamak değil, odaklanmadır
      Sabit diskler ve sürücülerle, ya da bunların bulut sürümü olan depolama ve Ansible gibi şeylerle uğraşarak geçirilen 1 saat, müşterinin ihtiyaç duyduğu şeyi üretmeye harcanmayan 1 saattir
      Devlet için neden farklı olsun?
      Devletin kendi arabasını üretmesini beklemeyiz; Volkswagen ya da Renault’dan satın almasını bekleriz. Devletin ulaşım ihtiyacı açıkça olsa bile böyle. O halde IT altyapısını neden kendi yapmasında ısrar edildiğini anlamıyorum
    • Devletin ihtiyaçlarının ve talebinin öngörülebilir olduğunu düşünüyorsanız siyaseti, özellikle de son 10 yılın Birleşik Krallık siyasetini takip etmemişsiniz demektir
      Ayrıca pandemi gibi tamamen beklenmedik yerden çıkan olaylar da var. Pandemi sırasında talebe göre ölçeklenebilmiş olmak, kamu sektörünün ticari public cloud kullanması gerektiğinin başlıca gösterim örneklerinden biriydi
    • Birleşik Krallık hükümetinin tamamı, büyük public cloud’larla birlikte bazı on-premise ve colocation çözümlerini de işletiyor
      Gov.UK’nin çeşitli iterasyonlarını ve bulutlar arası migrasyonunu ele alan Eylül sunumunu https://youtube.com/watch?v=mpY1lxkikqM&pp=ygUOUmljaGFyZCB0b... izlemenizi öneririm
      En azından Birleşik Krallık hükümetinde, tedarik gereklilikleri nedeniyle birkaç yılda bir kullanım bazlı fiyat teklifini yeniden piyasaya açmak zorundasınız
      Örneğin Oracle Cloud fiyatı onda biriyse ihaleyi kazanma olasılığı yüksek olur; bu durumda sözleşme süresi içinde Oracle’a migrate etmeniz gerekir ve daha sonra daha ucuz başka bir bulut çıkarsa tekrar taşınmanız gerekebilir
    • AB’deki birçok ülke kamu bulutu kurmuş olmalı. Hırvatistan’da bunu bizzat yaşadım; oraya deployment yapmak zorunda kalan geliştiricilerden biriydim
      Hayatımda gördüğüm en kötü şeylerden biriydi. VB.NET, Web Forms, eski SharePoint, Basic, hatta tüm uygulamanın devasa bir stored procedure yığınından ibaret olduğu legacy sistemlerle çok uğraşmış olmama rağmen böyleydi
      AWS, Azure, Google Cloud en azından son kullanıcıyı, yani geliştiriciyi düşünerek tasarlanmış. Buna karşılık devlet bulutu, ilk hedefi mümkün olan her yerden maliyet kısmak olan en düşük fiyatı veren tarafından tasarlanıp inşa edilmişti
    • Birleşik Krallık’ı bilmiyorum ama ABD’de AWS uzun zamandır GovCloud sunuyor ve açıkçası orada gördüğüm birçok altyapıyla kıyaslayınca neredeyse nimet gibi
      Öte yandan Alman devletine bağlı sağlık kurumlarının kurum içi veri merkezini yöneten gerçekten harika altyapı ve operasyon sorumlularıyla da tanıştım. Oradaki sorun ne teknoloji ne de insanlardı; altyapı ekibiyle mühendislik ekibi arasındaki her etkileşimde darboğaz olmaya çalışan yönetim ve süreçler %100 sorundu