Merkezileştirilmiş ağ yönlendirmesi ile dağıtık sistemlerin karşılaştırması üstünde kafa yorduğunuz oluyor mu kanka? Merkezileştirilmiş sistemler tek nokta hatasına karşı dayanıksızken, dağıtık sistemlerde tutarlılık ve gecikme sorunları çıkabiliyor. Peki siz hangi mimariyi tercih edersiniz? Maliyet, güvenilirlik ve ölçeklenebilirlik üçgeninde hangi faktör daha önemli geliyor? Ben de uzun süredir bu dengeyi kurcalıyorum, siz nasıl yaklaşıyorsunuz?
Merkezileştirilmiş yönlendirme: Artılarıyla eksileriyle?
👁️ 5 görüntüleme💬 5 cevap❤️ 0 beğeni
5 Cevap
Geçen sene akıllı ev sistemlerimi merkezileştirilmiş bir şekilde kurmaya karar verdim, özellikle de her şeyi bir hub üzerinden kontrol edebilmek için. Eve ilk kurduğumda her şey sanki peri masalından çıkmış gibiydi: Kablosuz ışıklar, termostat, kameralar hepsi tek bir uygulamadan çalışıyordu. Derken o meşhur "tek nokta hatası" ile tanıştım vallahi! Bir akşam o hub’ın elektrikleri gitti, ev aniden "aptal eve" döndü. LAN kablosunu devreye sokana kadar 3 saatimi çöpe attım, en basit lamba bile çalışmıyordu.
Sonra dağıtık sistemi denemeye karar verdim, her cihazı kendi wifi ağına ya da meshlere bağladım. İlk başta tutarsızlıklar canımı sıkıyordu, mesela bazen ışıklar geç açılıyordu ya da aksi sesli komutları duymuyordu. Ama mesh sistemler ve yerel olarak çalışan otomasyonlarla biraz optimize ettikten sonra aslında bence dağıtık sistemlerdeki esneklik ve güvenilirlik çok daha işlevsel oldu. Maliyetini biraz abartsa da ölçeklenebilirliği ve hiçbir cihaz bağımsız olarak çalışabildiği için en kararsız internet durumunda bile evim çalışmaya devam ediyor. Artık hangi mimarinin daha iyi olduğunu tartmak yerine bir arada kullanıyorum: Kritik cihazlar merkezileştirilmiş, gerisi dağıtık sistemde.
Merkezileştirilmiş yönlendirmenin en büyük handikabı SPOF (Single Point of Failure) dedikoducularını birebir yaşadığım projedeydi. API gateway üzerinden tüm trafik tek bir yük dengeleyiciyle yönlendiriliyordu; ortada patlayan bir AWS AZ durumunda sistem 3-4 dakika içerisinde logaritmik olarak büyüyen bir hata zinciriyle çöktü. O süreçten sonra, masrafı %15 artıracak şekilde AWS Global Accelerator + Route 53 trafik politikasına geçtik ve 2.000+ bölgesel uç noktaya dağılmış dağıtık bir yol haritası çizdik. Basitçe, CloudFront + Lambda@Edge kombinasyonunda kullanıcı nearest entry point’e yönlendirilirken, backend tarafında her AZ kendi bölgesel NAT gateway’ine sahip; böylece tek birAvailability Zone’ın çökmesi sistem genelini etkilemiyor.
Dağıtık sistemlerde karşılaştığım en büyük kâbus tutarlılık oldu. MongoDB cluster’ımızı shard’larken, iki farklı shard arasında gerçekleşen 150ms gecikmesi yüzünden order kaydı oluştuktan 2 saniye sonra stock güncelleniyordu ve siparişlerimiz çift faturalandırılmaya başladı. Bu süreçte tutarlılığı sağlamak için Raft konsensüs algoritmasına geçtik ve her write operasyonunu 3 node onayına bağladık. Maliyet tarafında elbette %8-10 arası bir artış var, ama 1.000.000+ daily active kullanıcıda sistemin %99,95 availability’yi tutturabilmesi için bu bedeli ödemeye değdiğini gördüm. Eğer kullanıcı sayın 10.000’lerdeyse, merkezileştirilmiş bir Redis cluster’ı + lokal cache sistemi daha basit ve ucuz bir çözüm olabilir. Önceliği kullanıcı deneyimine göre belirlemek gerekiyor: düşük hata toleransı ve global ölçek istiyorsan dağıtık sistemler mecbur, yoksa küçücük bir oyuncuysan merkezileştirilmiş mimariyi optimize etmek çok daha akıllıca.
Dağıtık sistemlerdeki veritabanı tutarlılığıyla ilgili yaşadığım ufak karışıklıklarda hep kafa karıştırıcı oluyor, acaba merkezi bir dizin yerine birden fazla node'un nasıl senkronize olduğunu tam olarak anlamaya çalışıyorum.
Kişisel olarak dağıtık sistemleri tercih ederim çünkü tek nokta hatasına karşı daha dayanıklı ve ölçeklenebilirler. Ama tutarlılık sorunu için CAP teoremi’ne göre seçim yapmak gerekiyor; mesela veritabanı seçiminde tutarlılık ve kullanılabilirlikte esnek olmak lazım.
Tek nokta hatasına dayanıksızlık dert etmek istemiyorsan, dağıtık sistemlere geçmek zorunda kalıyorsun. Ben kendi projelerimde Kubernetes kullandım; ilk başta karmaşık geldi ama statefulset ve headless service’le tutarlılık sorunlarını geçtim. Maliyet biraz yüksek olsa da Node sayısını artırmak kadar basit bir ölçeklendirme yöntemi var.
Ama eğer bütçen dar ve hata toleransı yüksekse, merkezileştirilmiş bir API gateway ile başlayıp daha sonra dağıtıma geçebilirsin. Örneğin; Cloudflare Workers’ı denedim sonra kendi kümeleme yapımıza geçtik. Karar verirken AWS’in "well-architected" çerçevesi bana çok yardımcı oldu, sen de mutlaka bak.
Tartışmaya katılmak için giriş yap
Giriş Yap