Supabase tarafından yönetilen Fly Postgres

 (supabase.com)
2 puan yazan GN⁺ 2023-12-17 | 1 yorum | WhatsApp'ta paylaş
  • Supabase ile Fly.io arasındaki yönetilen Postgres iş birliği, Fly altyapısında Supabase veritabanı özelliklerini kullanmayı amaçlayan bir girişimdi; ancak şu anda kullanımdan kaldırılmış durumda
  • Hizmet, Postgres’i Fly.io’nun 37’den fazla konumunda çalışan edge computing ortamına yerleştirerek Fly uygulamalarıyla veritabanlarını birbirine daha yakın konumlandırmayı hedefliyordu
  • Özellik kapsamı 40’tan fazla eklenti, pgvector, Supavisor, günlük yedekleme, belirli bir ana geri yükleme, branching, gözlemlenebilirlik, migration, dashboard ve REST·GraphQL otomatik oluşturulan API’leri içeriyordu
  • İlk dağıtım kademeli olarak yapılacaktı; faturalandırma, destek devri, iç eğitim gibi şirketler arası entegrasyon işleri ve ilk test kullanıcılarından gelen hata düzeltmeleri hâlâ bekliyordu
  • Fly’ın mevcut Postgres’i, operasyon sorumluluğunun kullanıcıda olduğu yönetilmeyen bir seçenekken Fly Postgres, ölçekleme·yedekleme·replikasyon·yükseltmeleri Supabase’in üstlendiği yönetilen bir hizmetti

Yayın durumu ve hizmet kapsamı

  • Fly Postgres şu anda kullanımdan kaldırılmıştır; ayrıntılar kullanımdan kaldırma duyurusunda bulunabilir
  • Supabase ve Fly.io, Fly altyapısında çalışan yönetilen Postgres hizmeti olarak Fly Postgres’i yayımladı
  • Veritabanları Fly.io’nun edge computing platformunda çalışır ve Fly.io’nun 37’den fazla konumu arasından seçim yapılarak başlatılabilir
  • Fly’a dağıtılan veri yoğun uygulamalar, veritabanını aynı altyapı içinde tutarak daha düşük gecikme bekleyebilir

Supabase yönetilen Postgres özellikleri

  • Fly Postgres, Supabase yönetilen veritabanından beklenen temel özellikleri Fly ortamına sunar
    • Supabase Postgres için 40’tan fazla eklenti
    • pgvector tabanlı Vector/AI iş yükleri desteği
    • Supabase’in Postgres bağlantı havuzlayıcısı Supavisor
    • Günlük yedekleme ve belirli bir ana geri yükleme
    • Branching, gözlemlenebilirlik, migration
    • Veritabanı yönetimi için dashboard
    • Otomatik oluşturulan Data API

Kademeli rollout ve ilk testler

  • Yayın kademeli rollout ile ilerledi
  • Şirketler arası entegrasyonda faturalandırma, destek devri ve Supabase çalışanlarının eğitimi gibi işler yer aldı
  • Bazı erken dönem test kullanıcılarıyla doğrulama yapılıyordu ve düzeltilmesi gereken hatalar vardı
  • Teste katılmak isteyenler waitlist listesine kaydolabiliyordu
  • Sonraki ay daha fazla test kullanıcısı almayı planlıyorlardı; veri güvenliğinden emin olduktan sonra ek yayın takvimini paylaşacaklardı

Yönetilen ve yönetilmeyen Postgres farkı

  • Fly’ın mevcut Postgres sunma biçimi yönetilmeyen bir modeldir
    • Kullanıcının ölçekleme, belirli bir ana yedekleme, replikasyon, majör sürüm yükseltmeleri gibi işleri kendisinin ele alması gerekir
  • Supabase’in işlettiği Fly üzerindeki yönetilen Postgres ile kullanıcılar uygulama geliştirmeye daha fazla odaklanabilir
  • Yönetilen hizmet Fly extension API ile oluşturuldu
  • Test kullanıcıları fly extensions komutuyla Postgres veritabanı oluşturabiliyordu
    • fly extensions supabase create
  • Hizmet kararlı hâle geldiğinde postgres namespace’iyle değiştirilecekti
    • fly postgres create

Fly Machines tabanlı uygulama

  • Fly Postgres, Fly machines üzerine inşa edildi
  • Machines hafif Firecracker VM’lerdir ve Machines API, uygulama yaşam döngüsü üzerinde ayrıntılı kontrol sağlar
  • Machines, etkin olmadığında durdurulabilir ve yeni bir istek geldiğinde birkaç saniye içinde yeniden başlatılabilir
  • Supabase, Fly API ile etkileşimi basitleştirmek için fly-admin adlı bir TypeScript wrapper’ı oluşturdu
  • Supabase, Postgres’e birkaç ek hizmeti paketlediği için Fly Machines API’ye iletilebilecek tek bir Docker imajı hazırladı
  • Mevcut build süreci Packer ile AWS için AMI oluşturur; bu pipeline’ın bir bölümü yeniden kullanılarak All In One Image build edildi
  • All In One Image, tek bir Docker container içinde bir Supabase projesini çalıştırmak için gereken tüm hizmetleri içerir

Multicloud’a geçiş

  • Bu yayınla Supabase resmen multicloud oldu
  • Supabase, multicloud geçişini basitleştirmek için AWS’in yönetilen hizmetlerinden bilinçli olarak kaçındı
  • Bulut sağlayıcılarının temel primitive’leri büyük ölçüde farklı olduğundan geçiş basit değildir
  • Fly Machines, kullanılmayan VM’leri durdurup birkaç saniye içinde şeffaf biçimde yeniden başlatma yöntemi sunar
    • Etkin olmayan veritabanlarını duraklatma süreci basitleşir
    • AWS’te bunu doğrudan sağlayan bir primitive yoktur
  • Buna karşılık Fly’da, AWS’in sunduğu bazı primitive’ler olmadığı için geçici çözümler gerekir
    • Fly Machines’te ağa bağlı storage yoktur
    • Supabase, Fly volumes üzerindeki verileri geçici veri olarak ele alır
    • Fly’da çalışan tüm projeler için WAL-G ile fiziksel yedekleme yapar
    • Veritabanı değişiklikleri sürekli olarak S3’e stream edilir
    • Host veya volume hasarı yaşanırsa proje, en güncel S3 verileri kullanılarak yeni bir Fly host’una geri yüklenir

Operasyonel gözlemlenebilirlik ve imaj dağıtımı

  • AWS’te host sorunlarını yakalamak için AWS Health events dinlenir
  • Fly’da Machine logları fly-log-shipper üzerinden Logflare’a gönderilir
  • Supabase, All In One imajını AWS container registry’nin yanı sıra Fly Docker registry’ye de yayımlar
  • Fly Docker registry’ye yayımlama, Fly’da proje başlatırken güvenilirliği ve performansı iyileştirir

Fly eklentileri ve kimlik doğrulama entegrasyonu

  • Fly, platform eklentileri için Extensions API sunar
  • Supabase, kullanıcıları ve projeleri provision etmek için API’ye birkaç route ekledi
  • Fly kullanıcıları mevcut Fly kimlik bilgileriyle Supabase dashboard’una erişebilir
  • Supabase API, kullanıcı kimlik doğrulaması için Fly ile OAuth akışını başlatır
  • Supabase Auth ekibi, API entegrasyonunu kolaylaştırmak için Fly OAuth provider oluşturdu

Kalan konular

  • Supabase, Fly ekibiyle birlikte bazı operasyonel konuları ele almaya devam ediyordu

  • Ağ kısıtlama desteği

    • Ağ kısıtlama özelliğinin çalışması için container’ın bağlanan istemcinin doğru IP’sini alması gerekir
    • Mevcut yapılandırmada container, istemci IP’si yerine Fly proxy IP’sini görür
    • Bağlantı, Proxy protocol’ü açığa çıkaran Fly proxy’den geçer
    • Postgres bu bilgiyi doğrudan kullanamaz; Supabase, Supavisor’ın proxy-protocol’ü tanımasını sağlamayı değerlendiriyor

  • Fly içinde yedekleme

    • Fly henüz yönetilen Blob storage sunmadığı için Fly proje yedeklemeleri AWS S3 üzerine yapılıyor
    • Bu yöntem bulutlar arası bant genişliği maliyetleri doğuruyor
    • Fly, Blob Storage üzerinde çalışıyor

Başlama yöntemi ve fiyatlandırma

  • Ön izleme başvurusu preview form üzerinden yapılabiliyordu
  • Organizasyon izin listesine eklendiğinde dokümanlardaki Quickstart ile başlanabiliyordu
  • Fly organizasyonları 1 ücretsiz proje alabilir
  • Faturalandırma ayrıntıları hâlâ üzerinde çalışılıyordu; ancak fiyatların mevcut Supabase fiyatlandırmasına kıyasla büyük ölçüde değişmemesi bekleniyordu

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-17
Hacker News yorumları

  • Supabase CEO'suyum. Fly'ın mevcut Postgres'i yönetilmeyen bir hizmet olduğu için, Fly ile birlikte yönetilen bir hizmet işletmek üzere çalışıyoruz
    Fly Redis'te Upstash ekibiyle izlediğimiz modelin aynısı: https://fly.io/docs/reference/redis/
    Hâlâ test kullanıcılarıyla yüksek erişilebilirlik özelliklerini dağıtıyoruz ve kesin bir takvim yok; ama Fly ekibiyle mümkün olduğunca hızlı ilerleyeceğiz

    • Fly'ın neden DigitalOcean ya da büyük bulutlar gibi kendi yönetilen hizmetini sunup üst pazara çıkmadığını merak ediyorum
      Başka bir şirketin barındırılmayan hizmetlerini barındırılan sürümler olarak yönetmek için dışarıdan bir şirketin gelip iş birliği yaptığı örnekleri pek duymadım
    • Dağıtık SQLite'a nasıl baktığınızı merak ediyorum. İleride Postgres yerine varsayılan tercih olabileceğini düşünüyor musunuz?

  • Eskiden Supabase'e bakmıştım ama temel REST API'yi nasıl oluşturduğunu anlamakta zorlanmıştım
    Tablo oluşturunca etkileşim için API'yi otomatik üretmesi güzel görünüyor; ama o zaman iş mantığını nereye koymak gerektiğini anlayamadım
    Edge Functions'a da baktım ama örnekler daha çok iş işleme tarafına yakındı; bu amaçla mı kullanılmalı net değildi ve sanki basit bir şeyi kaçırıyormuşum gibi geldi

    • PostgREST arayüzünü kullanırsanız, sonunda mantığı stored procedure'lara koyacağınızı akılda tutmak gerekiyor
      REST API, join gibi veri toplama işlerinde oldukça kullanışlı; ama transaction gibi şeylere ihtiyaç duyduğunuz anda zorlanmaya başlıyor
      Rol tabanlı erişim denetimi için satır düzeyi güvenlik (RLS) de zahmetliydi ve geliştirici deneyimi yetersiz kaldı
      DB gereksinimleri basitse REST API çok kullanışlı; ama karmaşık şeyler planlıyorsanız PL/pgSQL öğrenmek ya da normal DB bağlantısı kullanmak daha iyi
    • Birkaç seçenek var: normal bir Postgres DB gibi Postgres'e doğrudan bağlanmak, bahsettiğiniz otomatik oluşturulan REST API olan PostgREST'e bağlanmak ya da Deno tabanlı Edge Functions kullanmak
      Çoğu durumda 1. seçenek yeterli; 2. ve 3. seçenekler daha çok gerektiğinde kullanılan ek araçlar gibi
    • Temel bileşen https://postgrest.org/en/stable/ . k8s üzerindeki büyük ölçekli bir şirket projesinde prodüksiyonda kullanıyoruz
      Birçok kullanım senaryosunda mantığı SQL stored procedure'lara koyabilirsiniz; PostgreSQL, JS veya Python stored procedure'lara da izin veriyor
      Ancak mantık kodunu normal CI/CD container'ları ya da function'lar olarak dağıtmak geliştirici deneyimi açısından daha iyi; maliyet dengelerine göre ikisi de yaygın kullanılıyor
      Supabase, Deno serverless function'larını öneriyor; ama bir web projesiyse çoğu kişinin Node function'larını Cloudflare'a dağıtmayı daha çok tercih edeceğini düşünüyorum
      Sonuçta hedef müşteri kitlesi, mantığın %99'unu JS frontend'de tutup backend'in yalnızca CRUD ve kimlik doğrulamayı işlemesini isteyenler gibi görünüyor
    • Biz iş mantığının önemli bir kısmını Postgres'in trigger ve constraint'lerine koyuyoruz. Ancak dış entegrasyonlar gibi başka işler de var
      O kısmı, Postgres WAL tabanlı bir event sistemi oluşturup callback sistemi gibi ele aldık
      Başlangıçta Supabase Realtime'ı fork'layarak başladığımız, Elixir için küçük bir kütüphane de yaptık: https://github.com/cpursley/walex
      Son dönemde, Elixir bilmeye gerek kalmadan WalEx'in event'leri webhook ya da EventRelay'e iletecek şekilde yapılandırılmasını sağlayan bir özellik ekledik
    • DB, yapılandırmaya bağlı olarak hem istemciden hem sunucudan erişilebilir
      Next.js kullandığımız için DB çağrılarının önemli bir kısmı Next serverless function'larının içinde
      Ancak DB'ye mümkün olduğunca yakın tutmak için bazı mantıkları Supabase function'larına taşımayı da değerlendireceğim; fakat henüz Deno'ya taşımak istemedim
      Sunucudan Supabase'e erişirken Supabase client'ın kullandığı PostgREST özelliklerini kullanabilir ya da normal pg kütüphanesiyle Postgres'e doğrudan erişebilirsiniz

  • Buna geçmeyi dört gözle bekliyorum. Fly.io ve Fly Postgres üzerinde Booklet'i geliştirirken uygulamayı dağıtık olacak şekilde kurguladım: https://www.contraption.co/essays/booklet-architecture/
    En büyük sorun Fly Postgres kurulumu oldu. Özellikle Fly, Postgres'in önüne HAProxy koyup 30 dakikalık bağlantı sınırı uygulayarak bağlantıları sürekli kesiyor: https://community.fly.io/t/postgresql-connection-issues-have...
    Yönetilebilir olması gereken bir sorun; ama bağlantı sonlandırma davranışı dokümantasyonla uyuşmayan garip yönler gösterdiği için sürekli istikrarsız kalıyor
    Yeni Postgres'in önünde de aynı HAProxy'nin olup olmayacağını merak ediyorum

  • Bugün Fly dokümanlarında bunu görünce HN'de kaçırdım sandım; meğer yeni çıkmış
    İkinci düşündüğüm şey, kenar çubuğunda Postgres by Fly ile Postgres by Supabase'in birlikte durmasının tuhaf olduğuydu
    Göze çarpan bir karşılaştırma da yok; bu yüzden Fly'a uygulama dağıtıp Postgres'e ihtiyaç duyarsam ne kullanmam gerektiği kafa karıştırıyor
    Kişisel olarak Fly'da bir DBMS'e ihtiyaç duyarsam LiteFS dağıtık SQLite kullanırdım; Postgres gerekiyorsa Fly ile Supabase arasındaki farkın fiilen yönetilmeyen ve yönetilen hizmet farkı olduğunu düşünüyorum

    • Yönetilen veritabanına ihtiyacınız varsa Supabase kullanın. Fly.io Postgres yönetilmeyen bir hizmet ve temel fark gerçekten de bu

  • Çok iyi. Supabase'in ağ kısıtlama ayarlarını pek sevmiyordum: https://supabase.com/docs/guides/platform/network-restrictio...
    Eskiden baktığımda, Fly uygulamasının IP'sini Supabase'e açıp Supabase'i o IP'ye kilitleme konusunda garip bir sorun olduğunu hatırlıyorum
    Supabase'in gerçekten Fly ağının içine girmesi harika

    • Buradaki sorun, fly.io'nun giden IP adresinin tutarlılığını garanti etmemesi; bu yüzden kaynak IP tabanlı izin listesi kullanılamıyor
      Fly.io ağ dokümantasyonunda da bu yazıyor

  • Supabase'in prototip aşamasını geçince ölçeklenebilirlik sorunları olduğunu duydum; prodüksiyon deneyimi olan biri anlatabilir mi merak ediyorum

    • AWS üzerinde çalışan Postgres olduğu için, bu kombinasyondan bekleneceği kadar ölçekleneceğini düşünürüm
      Özellikle hangi sorundan bahsediyorsun?

  • Fly.io tarafından Joshua. Bu entegrasyon hakkında sorularınız varsa yanıtlarım

    • Bu gerçekten heyecan verici. Genel güvenilirlik endişeleri, özellikle dağıtım etrafındaki sorunlar ve anlaşılması zor hata mesajları dışında, yönetilen Postgres eksikliği Fly'ı ciddi şekilde kullanmamın önündeki başlıca nedendi
      Birkaç yan proje için kullanıyorum ama henüz büyük projelerde kullanmadım
      Sırada Blob depolama istiyorum; durum tutan şeyleri temelde yönetilen hizmet olarak kullanmak istediğim için bunun üzerinde de çalışılıyor olmasına sevindim
      Yeni Postgres hizmetinin fiyatlandırmasına dair ayrıntılar var mı merak ediyorum

  • Şu anda Fly'da büyük bir DB çalıştırıyoruz ve yönetilen PostgreSQL arayışındayız; bu haber çok sevindirici
    Tamamen Elixir ekibiyiz, zamanlama daha iyi olamazdı

    • Bunun, sadece supabase.com'a kaydolup Elixir uygulamasına DB kimlik bilgilerini koymaktan daha iyi yanı ne, merak ediyorum

  • “Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
    AWS kullanmadım ve ağa bağlı depolamayı da pek bilmiyorum; Fly volume'ları ile diğer sağlayıcıların ağa bağlı depolaması tam olarak nasıl farklı, merak ediyorum
    Fly volume oluşturunca aynı bölgedeki başka bir sunucuya taşıyabiliyorduk diye hatırlıyorum; o zaman teknik olarak ağa bağlı depolama değil mi?

    • Hayır. Fly Volumes bağlı NVMe depolamadır ve oluşturuldukları fiziksel host'a bağlıdır
      İçeride bir volume'u bir fiziksel host'tan diğerine taşıyabiliyoruz; yöntemi oldukça ilginç ama henüz bunu kamuya çok açmadık
      Bu yıl daha görünür hale getirmeyi planlıyoruz
      Fly Volumes düzenli olarak ağ dışı blok depolamaya yedekleniyor ve bununla ilgili de yakında daha fazla duyurumuz olacak
      Temel olarak anlaşılması gereken şu: Fly Volumes SAN depolama değildir ve S3 gibi doğası gereği güvenilir bir depolama da değildir
      Fly Machines içinde basit bir ext4 dosya sistemi olarak görünür; güvenilirlik, dayanıklılık ve çoğaltma gerekiyorsa bunları uygulama katmanında sağlamalısınız
      Fly Postgres okuma replikalarından oluşan bir küme olarak çalışır ve gerekirse herhangi bir replika yazma lideri rolünü devralabilir; bu yüzden bu yaklaşım ona uyar
      Tek düğümlü bir Postgres kümesi oluşturmaya çalıştığınızda konsolda büyük kırmızı uyarı göstermemizin nedeni de bu
      Önümüzdeki birkaç çeyrek içinde güvenilirlik ve performans spektrumunda yeni seçenekler sunacağımızı düşünüyorum; ancak iSCSI gibi yalnızca blok aygıtı sunan SAN sürücülerini doğrudan işlettiğimiz bir model olmayacak gibi

  • Bu iki şirketin fiyatlandırma modelinden gerçekten hoşlanmıyorum
    Bir uçta Supabase var; Vercel benzeri geliştirici platformu tarzı katmanlı paketler, gerçek kullanımdan daha fazlasını ödeten bir yapı
    Diğer uçta Fly var; Lambda gibi saniye, bellek ve CPU bazında aşırı parçalanmış fiyatlandırma, muhtemelen çok az ödeyip performans düşüşü yaşamanıza yol açabilir
    Cloudflare Workers gibi bir şey varken neden ikisinden birini seçiyorsunuz pek anlamıyorum. Neden hâlâ ölçeklenmeyi dert etmek istiyorsunuz?

    • Cloudflare Workers'ta Postgres seçeneği yok. En fazla başka yerde barındırılan Postgres'e bağlanan Hyperdrive var; o da özünde bir connection pooler olduğu için ek kısıtlar getiriyor
      Cloudflare'ın gerçek Postgres sunması da pek olası görünmüyor. Cloudflare'ın felsefesi, dağıttığınız her şeyin tüm dünyaya dağıtılması yönünde; ilişkisel veritabanı ise tek bir sunucuyu doğruluğun kaynağı olarak dayatır
      Elbette yanıldığım kanıtlansa sevinirim
    • İhtiyacınız olan herhangi bir Docker container'ını Cloudflare Workers üzerinde çalıştırmayı deneyin, sebebini anlarsınız
      Fly'ın aylık fiyatlandırması oldukça anlaşılır ve Lambda'ya hiç benzemiyor. Hatta ikisi arasında Cloudflare Workers'ın fiyatlandırma modeli Lambda'ya daha yakın
    • Sonuçta PostgreSQL ekosistemi, geliştirici deneyimi ve çeşitli ek özellikler yüzünden