- AWS ve DigitalOcean'dan migrate ederek Hetzner'e geçilmesiyle bulut maliyetleri %76 azaltıldı ve kaynak kapasitesi 3 katına çıktı
- Geçmişte AWS'nin kararlılığı ve DigitalOcean'ın sadeliği temel alınarak iki bulut hizmeti birlikte kullanılıyordu
- Ücretsiz krediler tükendikten sonra aylık 449 doların üzerinde işletim maliyeti yükü oluştu ve Hetzner gibi alternatifler aranmaya başlandı
- Maliyetleri düşürmek için Talos Linux tabanlı Kubernetes, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager gibi bileşenlerin bir araya getirildiği self-hosted bulut yığını kuruldu
- Hetzner'in ARM paylaşımlı vCPU sunucuları ve S3 uyumlu depolaması kullanılarak performans ve kararlılık korunurken büyük ölçekli kaynak genişlemesi sağlandı
- Yönetim kolaylığı bir miktar düşse de Avrupa içindeki alternatif bir bulut olarak maliyet/performans verimliliği son derece yüksek
Arka plan
- DigitalSociety'nin geliştirdiği tüm yazılımlar bulut tabanlı çalışıyor
- Migrasyon öncesinde ana altyapı AWS'de (ana hizmetler ile kimlik doğrulama, e-posta vb. yönetimi) ve DigitalOcean'da (hafif hizmetler, izleme, Kubernetes) işletiliyordu
- AWS, 15 yılı aşkın süredir kullanılan tanıdıklığı ve yüksek API kararlılığı nedeniyle seçildi
- DigitalOcean ise basit bir Kubernetes ortamı, ücretsiz control plane ve maliyet verimliliği sayesinde tercih edildi
- Başlangıçta yalnızca DigitalOcean kullanıldı ancak tap gibi veri yoğun SaaS'lerde çok fazla kaynak ve ek kredi ihtiyacı doğunca AWS'nin startup kredisi ($1,000) kullanıldı
Kredilerin bitmesi ve maliyet yükü
- AWS'nin Fargate'i (sunucusuz container çalıştırma) sayesinde başlangıçta düşük maliyetli kurulum mümkün oldu, ancak tap hizmetinin veri yoğun yapısı nedeniyle performansı korumak için en az 2x CPU ve 4 GiB RAM gerekiyordu
- Fargate'te bu özelliklerde bir container aylık 70 doların üzerinde maliyete ulaşıyor; iki worker instance ve diğer altyapıyla birlikte toplam aylık maliyet 449,50 dolara çıktı
- Sağlanan ücretsiz krediler 6 ay dolmadan tükendi ve öz sermayeyle büyüyen bir startup için ciddi bir sabit maliyet yükü yarattı
Alternatif arayışı
- Yüksek işletme maliyetlerini azaltmak ve teknik bağımsızlık kazanmak için Birleşik Krallık/AB tabanlı bulut sağlayıcıları araştırıldı
- Hetzner'in fiyat rekabetçiliği etkileyici bulundu ve self-managed VPS ortamı ile işletim karmaşıklığına rağmen hem AWS'den hem de DigitalOcean'dan taşınma kararı alındı
- Hizmetlerin çoğu zaten Kubernetes tabanlı çalıştığı için, Talos Linux'un kolay cluster kurulum özellikleri sayesinde Hetzner ortamında da kendi Kubernetes cluster'ı kuruldu
- AWS veya DigitalOcean'daki managed DB hizmetlerinin karşılığı bulunmasa da CloudNativePG ile PostgreSQL cluster'ı Kubernetes ortamında güvenli biçimde entegre şekilde yönetildi (izleme, yedekleme, arıza müdahalesi vb.)
Yeni altyapı yığını
- Hetzner: ARM sunucular, block storage, load balancer, ağ, firewall, S3 uyumlu object storage
- Talos Linux: deklaratif yapılandırmayla Kubernetes node yönetimi ve operasyon otomasyonu
- CloudNativePG: Kubernetes manifest'lerinde DB cluster tanımı, otomatik yedekleme ve arıza yönetimi için entegre destek
- Ingress NGINX Controller: cluster içindeki HTTP yönlendirmesinin merkezi yönetimi
- ExternalDNS: ingress kaynaklarıyla DNS'in otomatik entegrasyonu
- cert-manager: HTTPS için TLS sertifikalarının otomatik verilmesi
- Tüm altyapı Terraform ve Helm ile kodlandı; GitHub Actions üzerinden otomatik dağıtımla DevOps uygulandı
Maliyet karşılaştırması
- Taşınma öncesi aylık maliyet: AWS + DigitalOcean = $559.36
- Taşınma sonrası aylık maliyet: Hetzner = $132.96 (-%76)
- Kaynak artışı:
- CPU: 12 vCPU → 44 vCPU (+%367)
- RAM: 24 GiB → 88 GiB (+%367)
- Kaynaklar artmasına rağmen toplam aylık maliyet çok daha düşük kaldı
Migrasyon sürecindeki zorluklar ve deneme-yanılmalar
- Hetzner'in network zone yapısı AWS'nin Availability Zone yapısıyla tamamen aynı değil
- AWS'de tek bir region içinde birden fazla Availability Zone bulunuyor ve private networking region genelinde geniş biçimde bağlı
- Hetzner'de tek bir network zone (
eu-central) altında birden fazla location var ve bunlar arasında ağ gecikmesi (latency) yüksek olabiliyor
- Gerçekte birden fazla bölgeye dağıtım yapıldığında performans düşüşü gibi sorunlar yaşandığı izleme üzerinden görüldü
- Alternatif olarak tek bir bölgede (Nürnberg) Placement Group kullanılarak fiziksel sunucu dağılımı üzerinden hata dayanıklılığı sağlandı
- Container tabanlı hizmetlerde bile taşınabilirlik basit değil
- Ortam AWS ECS'den Kubernetes'e taşınırken tüm yapılandırma için otomasyon script'lerini, özellikle config dosyası dağıtımını, yeniden düzenlemek beklenenden uzun sürdü
- Sonunda Kustomize ile hassas yapılandırmaların entegrasyonu ve config dosyası yönetimi iyileştirilerek izlenebilirlik ve inceleme kolaylığı artırıldı
Sonuç
- Hetzner, kullanımı kolay bir managed service olmasa da self-management yapabilen ekipler için çok verimli bir seçenek
- Kendi işletimi sayesinde ayrıntılı yapılandırma üzerinde kontrol kazanılırken maliyet başına performans en üst düzeye çıkarıldı
- Bu yaklaşımla veri yoğun bir SaaS olan tap'i makul maliyet ve kararlı performans altında geliştirmeye ve işletmeye devam edebilecek bir temel oluşturuldu
1 yorum
Hacker News görüşleri
Doğrudan bare metal’e deploy ettiğinizde hissedilen performans artışının gerçekten çok büyük olduğunu vurgulamak isterim. Bizim servisimizde performans 2 katına çıktı ve öngörülebilir, istikrarlı bir performans elde ettik. Bunun birkaç nedeni var:
Düşük gecikme: Ağı doğrudan yönettiğinizde büyük veri merkezlerinin karmaşık ortak ağını paylaşmadığınız için gecikme 10 kattan fazla azalıyor
Cache optimizasyonu: Donanıma optimize edilmiş dağıtımla modern CPU’ların gerçek performansını tam kullanabiliyorsunuz
Ayrılmış NVMe kullanımı: Disk I/O hızı inanılmaz
Bir diğer avantaj da autoscaler’a pek ihtiyaç kalmaması. Aynı fiyata donanım performansı 10 kat daha yüksek, hız da 2 kat olunca tam kapasite çalıştırmak daha mantıklı oluyor. Tüm sistem daha istikrarlı ve yönetimi daha kolay
S3 ücretlerini de dert etmeniz gerekmiyor. Her sunucuya 15TB NVMe sürücü takıp MinIO/garage cluster çalıştırmanız yeterli. Biz 10 düğümlü bir cluster’da saniyede 20GiB ve 50 bin API çağrısı işliyoruz. S3 olsaydı yalnızca API çağrıları için saniyede $20~$250 ücret çıkardı; aradaki fark inanılmaz
Sadece aylık sabit ücret ödüyorsunuz
Ayrıca ucuz ve hızlı depolama, büyük PostgreSQL instance’larını düşük maliyetle çalıştırma ve bulutta hissedilen kısıtlar ile gereksiz uğraşlar ciddi biçimde azalıyor
Böyle bir yapıya yatırım yapsanız bile maliyet AWS’nin 10’da 1’i oluyor
Eğer bunu doğrudan yönetmek gözünüzü korkutuyorsa, biz (https://lithus.eu) AWS’nin yarı fiyatına sizin yerinize yönetiyor ve DevOps desteği de veriyoruz. İletişim için alan adındaki adam@ adresine bakabilirsiniz
Teknik arka plan: bare metal, 'sanallaştırma (VM)' yerine doğrudan fiziksel sunucuda çalıştırma yöntemidir
Gerçekten de, 'makine ekledikçe hızlanır', 'maliyet çok da önemli değil' denilen eski dönemi geride bırakmayı istiyorum. Kariyerimde .NET döneminde tek bir kabinet sunucuyla milyonlarca kullanıcıya hizmet verdiğim oldu. Sonra bulut tabanlı, container kullanan, Node mikroservisli bir şirkete geçtiğimde faturalarla performans sorunlarının kaosunu her gün yaşadım; hâlâ bazen ürperiyorum
Değişim galiba hep tekrar ediyor. Şirketimize bakınca, yeni teknoloji olmadan hareket etmemenin aslında local cloud/edge/kurum içi IDC akımının ön cephesinde olmak gibi hissettirdiğini düşünüyorum
S3 API kullanmak soğan soymak gibi. Kullandıkça gözleriniz daha çok yaşarıyor
Bare metal kullanırsanız ağ yönetimi, güvenlik · izleme, yamalar ve güncellemeler için özel personel gerekir. Bu tür uzman insan maliyeti ancak belli bir ölçeğin üstünde verimli olur. Bu yüzden KOBİ’ler için bulut hâlâ güvenlik ve operasyon maliyeti açısından avantajlıdır
AWS de Lambda için 1 vCPU tahsisinde gerçekte yalnızca yaklaşık %50 verdiğini kendi dokümantasyonunda belirtiyor. Bellek·CPU tahsisini artırdıkça oran iyileşiyor ama her zaman %100 performans vermiyor
Eskiden beri bağımsız sunucularla verimliliğin en üst düzeye çıkarılabileceğini düşünürdüm. Hetzner’da birkaç node çalıştırıyorum ve 3 yıllık eski sunucuları bile açık artırmadan kiraladığınızda VM’lerle kıyaslanamayacak bir performans alıyorsunuz. Sunucu donanımları çekirdek sayısı ve I/O odaklı optimize ediliyor, çoğu bulut da donanımı aşırı tahsisli sunuyor. Hatta disk I/O’da bile NAS üstünde çalıştırıp bunu local disk gibi emüle eden türlü numaralar yapılıyor. Çoğu startup’ın bu kadar aşırı sanallaştırmaya, NAS tabanlı disklere ihtiyacı yok. Aksine, Hetzner gibi yerlerden sunucu kiralayarak çok daha uzağa çok daha ucuza gidebilirsiniz. Kuzey Amerika’da (özellikle Kanada’da) Hetzner seviyesinde fiyat/kalite sunan sağlayıcıları merak ediyorum. OVH’yi biliyorum; benzer başka seçenekler varsa duymak isterim
Birçok insanın Google·Facebook’un yaptığı mimariyi doğrudan takip etmek gerektiğini düşündüğünü hissediyorum. Biz Avrupa VPS’leriyle sade bir şekilde çalışıyoruz. Ama yeni işe girenler (iş tarafı da geliştirme tarafı da) her seferinde bir cloud migration projesi başlatılması gerektiğini söylüyor. Ben de her seferinde "biz zaten bulut kullanıyoruz, CV’n için bir cloud migration projesi yaptıramam" diye ikna etmek zorunda kalıyorum
Bulut ve bare metal sunucu CPU performansını gerçekten benchmark ettiğim bir yazım var, bakmak isterseniz https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12
Yakın zamanda bulduğum şu site de yardımcı olabilir: https://vpspricetracker.com Konsepti çok etkileyici. Burada listelenen sağlayıcıların çoğu bağımsız sunucu da sunuyor
Eğer 'ABD içinde Hetzner kalitesi olsun ama yerel marka olması şart değil' diyorsanız, Hetzner’ın kendisinin de ABD’de 2 veri merkezi var
Kanada için bakılabilecek sağlayıcılar arasında https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ var
Biz de aynı trendi yaşıyoruz. Birçok ekip Hetzner’a geçip fiyat/performansa hayran kalıyor ama Postgres operasyonlarını (yedekleme, failover, izleme vb.) yeniden kurmaları gerektiğini fark ediyor. Bu yüzden doğrudan Hetzner üstünde çalışan yönetilen bir Postgres yaptık. Aynı donanım optimizasyonunu korurken yüksek erişilebilirlik (HA), yedekleme ve zaman noktasına kurtarma (PITR) da sağlıyor. Açık kaynak, donanıma yakın çalışıyor ve AWS’de sık görülen I/O ücretleri ile veri çıkışının gizli tuzakları da yok. Merak ederseniz bloglara bakabilirsiniz 1, 2
Bu yüzden Big Cloud’a, özellikle de PaaS ile yönetilen SQL’e büyük çekim duyuyorum (tavsiye verdiğim geliştirme ekipleri de öyle). Operasyon deneyimi çok olmasa bile veritabanı yedekleme/kurtarma, yamalar, erişim kısıtlama, port yönetimi, anomali tespiti ve DoS saldırılarına müdahale gibi konuların otomatik ele alınması içimi rahatlatıyor. Politik olarak da teknik olarak da popüler bir bulut şirketini kullanmak psikolojik bir güvenlik ağı sağlıyor
Kendi yapılandırılmış, kendi yönettiğiniz Postgres’te sorun yaşıyorsanız https://www.elephant-shed.io/ bakmaya değer olabilir
Bu tür yazıların ya da yorumların tavsiyeyi neredeyse hiç bağlama oturtmadan vermesi ilginç. Boş zamanınızda bir kilise bülteni mi döndürüyorsunuz, yoksa dünyanın dört bir yanındaki müşterilere hizmet veren yüksek trafikli kurumsal bir SaaS mı işletiyorsunuz; gerekli şartlar buna göre tamamen değişir. Kendi ortamınızı anlatmadan verilen fiyat, performans ve erişilebilirlik tavsiyeleri pratikte anlamsız. Web altyapısının gereğinden fazla karmaşıklaşmasının nedenlerinden biri de, farklı gereksinimleri olan insanların birbirinin tavsiyesini kopyalaması
'Gereksinimler farklıyken tavsiyeyi sorgulamadan uygulamak gerçeği daha da karmaşıklaştırıyor' düşüncene katılıyorum. Bazı şirketlerde bulut hesap yöneticisi C-level yöneticilerin öğle yemeğine kadar girip AWS kullanımını dayatabiliyor. Bu süreçte AWS mimarları doğrudan bizim ekibe atanıyor ve doğal olarak en pahalı serverless seçenekler öneriliyor. Ama gerçekte sonunda yine Docker OS image’larını yeniden deploy ediyor, tıpkı sıradan bare metal sunuculardaki yamalar gibi sürekli bakım yapıyor oluyorsunuz
Benim kişisel Pastebin’im bile bare metal olmadan ayakta kalamıyor (şaka)
Bu, IT sektörünün tipik bir örneği
Gereksinimler, teknik seviye, maliyet yapısı ve problem alanı tamamen farklı. Hetzner ile AWS yüzeyde benzer bulutlar gibi görünse de gerçekte tamamen farklı hizmetler. Bunu ikisini de kullanmış biri olarak söylüyorum
Kesinlikle katılıyorum. Bu konuda görüşümü bir blog yazısında da paylaştım, bakabilirsiniz https://news.ycombinator.com/item?id=45616366 Özeti şu: "Hosting sağlayıcılarını DIY’den enterprise’a kadar bir fiyat skalası olarak anlayın; kullanmamak daha avantajlıysa (YAGNI) sırf var diye seçmeyin"
10 yılı aşkın süredir SaaS’ımı Hetzner üzerinde çalıştırıyorum. Tamamen bağımsız donanım kullanıyorum, Almanya ve Finlandiya veri merkezlerinde cluster kurdum, yönetimi ansible ile yapıyorum. Sunucular arası VPN bağlantısı için vpncloud kullanıyorum (bu yazılım gerçekten harika). Aylık hosting maliyeti AWS vb. ile kıyaslandığında çok düşük, sunucular da çok daha hızlı. Basit yapı ve az sayıda sunucuyla rahatça yürüyor. Gerektiğinde sadece sunucu ekliyorum; ama bare metal olduğu için birkaç dakika içinde ölçeklenmiyor. Birkaç saat ya da birkaç gün önceden planlamak gerekiyor. Veritabanı tarafında arızalara karşı RethinkDB (yakında FoundationDB’ye geçeceğim) dağıtık mimarisini kullanıyorum
Ben de rethinkdb ile benzer bir yapı çalıştırıyorum. Ama neden özellikle FoundationDB’yi seçtiğini merak ettim. RethinkDB hâlâ bakım görüyor ve ara sıra yeni özellikler de geliyor. Beklenenden daha canlı bir Slack topluluğu var
Hâlâ RethinkDB kullanan birini görmek sevindirici
Hetzner DE/ FI merkezleri arasında doğrudan vpncloud mu kuruyorsunuz? Hetzner’ın bunu kendi içinde ucuz bir özellik olarak sunduğunu sanıyordum
Son dönemde AWS’den Hetzner’a (ve Netcup’a) geçen birçok ekibe destek verdim; insanları en çok şaşırtan şey maliyet ya da performansın kendisi değil, 15 katmanlı yönetim soyutlamasını (servisleri) kaldırdığınızda yapının bir anda çok daha basit hale gelmesi oluyor. S3/EFS/FSx seçimi, Lambda cold start, EBS burst credit gibi dertler ortadan kalkıyor. Hızlı NVMe’ye Docker deploy ediyorsunuz ve çalışıyor. Elbette biraz daha fazla DevOps yetkinliği gerekiyor (izleme, yedekleme, yamalama vb.). Ama bu operasyon işleri otomasyona bağlandığında her hafta değişen şeyler değil. Elestio’da biz de bu sadeleşmeye odaklanıyoruz; 400’den fazla açık kaynak yazılımın tamamen yönetilen stack’ini her bulutta sunuyoruz (CI/CD dahil). Hetzner dâhil her yerde production seviyesine kadar kapsıyoruz https://elest.io (not: Ben Elestio’da çalışıyorum ve Multi-Cloud açık kaynak servisleri sunuyorum)
Kariyerimin başlarında çok iyi bir şirkette çalışıyordum ama o dönem RDS’nin desteklemediği bir Postgres sürümüne ihtiyacımız vardı; bu yüzden EC2’de defalarca Postgres kurmak zorunda kaldım. Docker’ın bile olmadığı zamanlardı ve kurulum tam anlamıyla zaman israfına dönüşüyordu. RDS o sürümü destekler desteklemez her şey bir anda kolaylaştı. Sabah 3’e kadar tekrar tekrar Postgres kurduğum günleri hâlâ canlı hatırlıyorum. Bu yazı güzel ama sonuçta belki ayda birkaç yüz dolar tasarruf ediyorsunuz. Bir mühendisin ayda sadece 1 saatlik yönetim maliyeti bile bu tasarrufu sıfırlayabilir. Bir de aniden arıza çıkarsa, bir günlük sorun bir yıllık tasarrufu silebilir. Zamanınızın çok değerli olmadığı kişisel projelerde (özellikle büyük sunucu gerekiyorsa) bare metal işletmek daha mantıklı olabilir. Ama sonunda kendi zamanınızın daha değerli hale geldiği noktaya geliyorsunuz. Örneğin Ghost blog’un resmi hosting’ini aylık $10’a kullanabilirsiniz; ya da Hetzner instance’ında birkaç tane çalıştırabilirsiniz. Ama bir şey bozulduğunda 2-3 saat uğraşmak yerine acaba $20 fazla versem daha mı iyi diye düşünmeye başlıyorsunuz
Hetzner’ın (bazı) bağımsız sunucularındaki en büyük avantaj sınırsız bant genişliği. Ben ağırlıklı olarak görsel barındıran bir site işletiyorum; Hetzner’a geçtikten sonra 3 yıldır sadece sabit ücret ödeyip geceleri rahat uyuyabiliyorum
Hetzner’ın ölçek büyütme konusunda belirgin sınırları var. Biz de başlangıçta Hetzner tabanlı yüzlerce VM çalıştırıyorduk ve zirvede bini aşkın ölçeğe çıkmamız gerekiyordu. Sorunlar da burada başladı: Kara listede olan IP’ler zaman zaman atanıyordu ve bu da AWS, Google’a (özellikle S3’e) bağlantıda sıkıntı yaratıyordu. Hatta bir noktada bölgemizde hiç VM kalmadı ve yeni tahsis tamamen durdu. Sonuçta, büyük ölçekli genişleme gerekmiyorsa Hetzner harika; ama gerçekten genişleme gerektiğinde başka servislerle karıştırarak kullanmak zorunda kaldık
Bir bölgede VM’lerin tamamen tükenmesi belirli bir buluta özgü bir sorun gibi gelmiyor. GCP’de de birkaç yıl önce benzeri vardı. Yoğun saatlerde tek seferde yüzlerce VM isterseniz, sanırım hiçbir bulut bunu kolay kaldıramıyor
Microsoft’un Hetzner·Scaleway servislerini engellemesi iyi bilinen bir olay https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. AWS ve GCP’nin de bunu yaptığını bilmiyordum ama çok da şaşırtıcı değil. Büyük bulut şirketleri bunu 'spam akışı' bahanesiyle meşrulaştırıyor ama gerçekte öyle değil
Burada anlatılanın, Hetzner’ın gerçek donanımını (Server Auction vb.) kullananlarla sanal sunucu (VM) kullananlar arasındaki fark olması mümkün. Gerçek fiziksel sunucular fiyat/performans ve hız açısından çok daha iyi; VM tarafı devrimsel olmasa da rakiplerden hâlâ daha ucuz
Bu tartışma Hetzner Cloud ürünüyle (VM) ilgili. Cloud ürünü, bağımsız sunuculara kıyasla nispeten yeni çıktı. Birçok kullanıcı Hetzner’a esas olarak bağımsız sunucuların sunduğu değer için geliyor
Gerçekten merak ettim, yüzlerce ya da binlerce VM gerektirecek nasıl bir servis işletiyordunuz ve neden bağımsız sunucular yerine VM tercih ettiniz? Hetzner’ın en yüksek özellikli VM’inin (48 çekirdek, 192GB RAM, 960GB SSD) olduğu söyleniyor; bu kadar kapasite ihtiyacı ilginç geldi
Hetzner kullanmak için nedenler var ama dikkat edilmesi gereken birkaç nokta da var. AWS’ye göre erişilebilirlik biraz daha düşük ve region çeşitliliği de az. Bu yüzden mutlaka Cloudflare ile birlikte kullanılmasını öneririm. Hetzner üzerinde çekirdek sistemi (K8s) çalıştırıyoruz; veriyi ise R2/D1/KV ve Edge Durable Objects üzerinde dağıtıyoruz. Müşteri verilerini her DO başına shard ederek hem ana veritabanının yükünü azaltıyor hem de güvenlik avantajı elde ediyoruz
AWS’nin de şaşırtıcı derecede büyük çaplı kesintileri oldu. Sonuçta multi-region mimari yoksa erişilebilirlik sorunlarından yapısal olarak kaçınmak zor
Ben de Hetzner’da bağımsız sunucular üzerinde çekirdek ve storage yedekliliği kurup, OVH’de dünya geneline edge node’lar ekleyerek kendi CDN’im gibi çalışan bir yapı tasarladım
Müşteri verisi edge’deyse, o zaman 'çekirdek' tam olarak neyi ifade ediyor?