Sahip Olduğunuz Sistemi Sonuna Kadar Kullanın

• Yazı, yazarın bir SaaS uygulamasında Postgres performansını yönetme deneyimini ele alıyor; veritabanı yükü karşılamakta zorlanıyordu.
• Yazarın ekibi, veritabanı fazla meşgul olduğunda her seferinde onu daha büyük bir instance ile değiştirerek dikey ölçekleme yaptı. Ancak zaten en büyük instance kullanıldığı için sistem aşırı yüklenme noktasına gelmişti.
• İki olası çözüm önerildi: yazmaları bağımsız veritabanı kümelerine shard etmek ve monoliti birbiriyle bağlantılı birden çok hizmete (mikroservisler) bölmek.
• Her iki çözüm de kapasiteyi artırır ve hata toleransı ile operasyonel dayanıklılık açısından ilginç seçenekler sunar, ancak karmaşıklığı da ciddi ölçüde artırır.
• Yazar, karmaşıklık artışının gerçek maliyetinin dikkat olduğunu ve bunun sonraki tüm teknik kararları daha karmaşık hale getirdiğini savunuyor.
• Yazar, karmaşıklığı büyük ölçüde artırmadan önce genellikle iş yükünü ayarlayarak, performansı ince ayarlayarak veya sistemi bir şekilde destekleyerek mevcut sistemden biraz daha fazla performans "sıkıştırma" fırsatı bulunduğunu öne sürüyor.
• Kendi durumlarında, ağır sorguları optimize ederek, Postgres ayarlarını ince ayarlayarak ve pahalı bazı salt okunur sorguları replica DB'ye offload ederek veritabanının haftalık en yüksek CPU kullanımını %90'dan %30'a düşürdüler.
• Yazar, karmaşıklığın gerekli ve kaçınılmaz olduğu sonucuna varıyor; ancak mümkün olduğunca uzun süre karmaşıklık artışını erteleyip önce mevcut sistemden alınabilecek maksimum performansı çıkarmanın tercih edilmesi gerektiğini söylüyor.

[GN⁺]

Hacker News görüşü

• Yazı, değiştirme veya yükseltmeyi düşünmeden önce mevcut sistemin potansiyelini en üst düzeye çıkarmanın önemini vurguluyor.
• Ekiplerin, mükemmel olmasa bile ellerindekini değerlendirmesi ve mevcut kaynaklarla hedeflere ulaşmanın yollarını bulması gerektiğini öne sürüyor.
• Uygulamayı veritabanında join kullanılmayacak şekilde tasarlama fikrini tartışıyor; depolamanın ucuz olduğunu ve her şeyin denormalize edilip transaction içinde güncellenmesi gerektiğini öne sürüyor.
• Hot partition'ları önlemek için UUID kullanılması öneriliyor; böylece sonunda sorun çıkarabilecek tamsayılara güvenmek yerine yatay olarak ölçeklenebiliyor.
• Bir ekibin, donanım veya karmaşıklık eklemek yerine probleme yaklaşımını değiştirerek sistem performansını büyük ölçüde artırdığı başarılı bir örnek paylaşılıyor.
• Yazı, monoliti tek seferde birden çok bağlantılı servise bölmeye karşı çıkıyor; bunun yerine en büyük etkiyi yaratacak ayrımı belirlemeyi öneriyor.
• ORM üzerine kurulu web uygulamalarında sorguları optimize etmenin önemini vurguluyor; çoğu zaman iyileştirme için geniş alan bulunduğunu belirtiyor.
• Mikroservis sistemleriyle çalışmanın getirdiği zihinsel yük ve karmaşıklık konusunda uyarıyor; bunların sık sık kesintilere ve kafa karışıklığına yol açtığını öne sürüyor.
• Verimlilik (israfı en aza indirme ve karmaşıklıktan kaçınma) ile optimizasyon (karmaşıklık ekleme pahasına özel algoritmalar kullanma) arasındaki farkı ayırt ediyor.
• Daha karmaşık bir altyapıya geçişle ilgili endişeleri paylaşıyor; bunun herkesin beklediği sihirli çözüm olmayabileceğini öne sürüyor.
• Özellikle kaynakların sınırlı olduğu ve sistemin çok kritik olmadığı durumlarda, karmaşıklık yerine sadeliği savunuyor.
• Son olarak yazı, tenant (müşteri) bazlı sharding'i ölçeklenebilirlik sorunlarına yönelik potansiyel bir çözüm olarak ele alıyor.