- 2010'ların başına kadar MQ tabanlı dağıtık sistem kurulumları hakkında çok konuşuluyordu, ama bugünlerde bununla ilgili pek yazı yok
- Aklıma gelen birkaç teori şunlar; bunlardan biri mi, yoksa başkalarının düşünceleri farklı mı, merak ediyorum
- Redis çoğu kullanım durumunu ve hatta önbellekleme işini de çözdüğü için ayrı bir mesaj aracısı işletmenin faydası kalmadı. Kafka ise gerçekten çok büyük ölçeğe gitti.
- DB'ler (geniş anlamda bakarsak) büyük ölçekli işlemleri çok daha iyi yapar hale geldikçe, "geçici" işlemler ana depoda ele alınmaya başladı
- MQ tabanlı mimarilerin beklendiği kadar iyi çalışmadığı anlaşıldı ve artık başka yaklaşımlar kullanılıyor
- Aslında MQ teknolojileri artık olgunluk dönemine girdi; insanlar bunun hakkında yazacak kadar heyecan duymuyor. Ama hâlâ yaygın biçimde kullanılıyor
hnthrowaway_99
- 2000'lerin sonu ile 2010'ların başındaki pek çok "popüler" mimari, sonunda "Sen Google değilsin. Şirketin de asla Google olmayacak" gerçeği fark edilince ortadan kayboldu
- O dönemde "başarılı büyük şirketlerin kurduğu gibi kurma" arzusu çok güçlüydü
- Ama sonrasında birçok kişi, şirketlerin %99'u için bu kadar karmaşıklığın gerekli olmadığını fark etti
- Donanım ve standart veritabanları çok daha iyi hale geldikçe, bu tür "Scalability Trick"lere ihtiyaç duyan şirketlerin sayısı da giderek azalıyor
- "Bütün bunları Postgres ile yapmamamız için bir sebep var mı?" sorusuna koyduğum eşik, 10 yıl öncesine göre çok daha yükseldi
- Bu yoruma gelen yanıtlar
- Artık makul maliyetlerle kullanılabilen çok daha büyük tek makineler var. Eskiden küçük kümeler gerekirdi, ama artık tek bir sistem bile çok çeşitli iş yüklerini taşıyabiliyor
- Dürüst olmak gerekirse, ben Google'da kuyrukları ortadan kaldırmaya yönelik birkaç projede yer aldım. Yani mesele muhtemelen sadece popülerliğin düşmesinden daha fazlası
biglain
- Alaycı olacak ama bence MQ mimarileri ve bunlarla ilgili blog yazıları "Resume Driven Development" idi. Gerçekte ise monolitin ötesine ölçeklenmeye gerek kalmadan tek bir dizüstü bilgisayarda çalışabilecek işler yapılıyordu.
- Muhtemelen bunlar, ayda on binlerce dolar AWS faturası çıkaran kâbus gibi mikroservis felaketleri kuran kişilerdi
- "Gerçek iş problemlerini pratik biçimde çözmektense kariyerlerinde teknik başarı biriktirmeyi öncelik haline getiren insanlar" bugünlerde AI hakkında hype yaratıp blog yazıyor
tuckerconnelly
- Yakın zamanda mikroservislerin fazla karmaşık ve çok fazla tekrar eden kod içerdiğini görüp monolite geri döndük. Mikroservis yoksa mesaj kuyruklarına olan ihtiyaç da azalıyor
- Asenkron işler için bir projede RabbitMQ kullandım ama fazlasıyla eski ve aşırı tasarlanmış hissettirdi
- Üstelik etrafındaki birçok araç da (Celery), Redis odaklı daha modern araçlar (
bullmq) kadar iyi değildi
- Çok aşamalı DAG tarzı süreçlerde ben mümkünse her şeyi tek bir büyük işte halletmeyi ya da az sayıda işe bölmeyi tercih ediyorum
- Gerçekten DAG gerekiyorsa bunun için özel yapılmış araçlar var (Airflow). Ama sorunları debug etmenin zor olduğunu duyduğum için mümkünse kaçınmak daha iyi
- Redis'in çok düğümlü mimarisinin saçma derecede karmaşık olduğunu ve ölçekleme tarafında sorun çıkardığını düşündüğüm için tek düğümde kalıyorum. Ama elle sharding yapmak benim için sorun değil ve iyi çalışıyor
- Bu yazıya kypro'nun yorumu
- Benim deneyimimde monolit karmaşıklığı azaltmıyor, sadece taşıyor
- Monolitlerin en büyük sorunu, alanlar arasındaki sorumlulukların net ve açık biçimde ayrılmaması nedeniyle zamanla kod tabanının yoğun biçimde birbirine bağlı bir spagetti kod karmaşasına dönüşmeye çok yatkın olması
- Özellikle çok sayıda geliştiriciyle büyük projeler kurarken ve geliştiricilerin çoğu çalıştıkları kodun alan karmaşıklığını tam olarak anlamıyorsa bu daha da belirginleşiyor
- Monolitler az geliştiricili küçük projeler için uygundur; aksi halde birkaç yıl içinde çoğu ekip monolit kurmuş olmaktan pişman olur
- Ayrıca tekrar eden kod noktası konusunda da katılmıyorum. Aynı dili kullanıp projeler arasında paket paylaşıyorsanız bunun neden büyük bir sorun olduğunu anlamıyorum
- Her hâlükârda mikroservislerle çalışırken ben bu sorunları hiç yaşamadım
- Ayrıca mikroservislerin ortalama olarak monolitlerden daha karmaşık olup olmadığı konusunda da şüpheliyim
- Mikroservis mimarisinde en sevdiğim şey, tek tek mikroservisleri anlamanın ve onlara katkı vermenin ne kadar kolay olduğu
- Mimari ve provisioning daha karmaşık olabilir, ama mikroservis üzerinde çalışan geliştirici açısından monolite göre çok daha basit olabilir
democracy
- Şu düşünce bana doğru geliyor: "MQ teknolojileri artık olgunlaştı; hakkında yazı yazacak kadar heyecan verici değil ama hâlâ yaygın şekilde kullanılıyor"
- Mesajlaşma tabanlı mimariler çok popüler
- Bu yazıya gelen yorumlar
- casper14 : Katılıyorum. Artık sadece bir araç haline geldi. Tıpkı artık kimsenin bulutta sanal makine kullanma yöntemleri hakkında yazmaması gibi
- bwhaley : Asıl doğru cevap bu. Büyük ölçekte çalışan neredeyse her dağıtık sistemin, bir şekilde mesaj kuyruğu kullandığını rahatlıkla söyleyebiliriz
- ipsum2 : Bu en güçlü aday gibi. Eskiden Angular'ı React ile yeniden yazma yazıları popülerdi; şimdi herkes zaten React kullanıyor ya da React'i Vue'ya rewrite etme yazıları yazıyor
busterarm
- Popüler olmayan bir cevap vereceğim
- Kuyruklar, stream'ler ve Pub/Sub çoğu mühendisin iyi anlamadığı kavramlar
- Ne zaman gerekli olduklarını bilmiyorlar, nasıl doğru kullanılacağını bilmiyorlar ve yanlış amaçlarla kullanıyorlar
- Ben hâlâ yukarıdakilerin hepsiyle çalışıyorum (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
- Kuzey Amerika'daki ilk 3-4 okuldan gelen en "parlak" mühendisleri işe alan bir şirkette çalışıyorum ve neredeyse herkes için burası ilk iş
- Bizim mühendisler şu tarz çılgınlıklar yaptı:
- RabbitMQ'ya bir anda on binlerce 100MB mesaj basıp sonra neden çöktüğünü merak etmek
- Bunu yapmayın diyen tüm uyarılara rağmen RabbitMQ üzerinden genel olarak oldukça büyük mesajlar göndermek
- 2024'te en güncel RabbitMQ sürümüyle yeni projeye başlayıp classic queue kullanmaya çalışmak
- Replikasyon politikası olmadan quorum queue oluşturmak ya da kelimenin tam anlamıyla HA için hiçbir şey yapmamak
- Yönetici kullanıcısı
guest/guest iken kümeyi internete açmak
- Kurumdaki en üst düzey mimarın yeni bir mimari desen ilan edip tüm organizasyona toplantı yapması ve demo göstermesi
- Mesajı kuyruğa koyup ardından ikinci bir tüketicinin kuyruktaki mesajı isteğe bağlı olarak işlemesini sağlayacak bir backchannel kurmayı yeni bir erdem/desen gibi övmesi (ve böylece artık kuyruğun kuyruk olmaktan çıkması)
- Ve benden başka hiç kimsenin "sıralı işlenmesi gereken mesajları neden kuyruğa koyuyoruz?" dememesi; sonra da bu "desen"in yerleşmesi!
- Kafka'yı varsayılan mesaj kuyruğu olarak kullanmak
- Merkezi veri merkezinden dünyanın dört yanına dağılmış veri merkezlerine veri göndermek ve her hedef veri merkezi güncellenmiş nesneyi aldığını onaylayana kadar nesne üzerinde global kilit ile tüm işlemleri sürdürmek. Üstelik verinin AJAX isteğiyle gönderildiği için bu sürecin asenkron olduğunu iddia etmek
- Sonuç olarak insanlar aslında çok etkileyici şeyler yapmasalar bile işler yine de yürüyor. Bu yüzden araçlar yanlış kullanılıyor, kötüye kullanılıyor ya da yetersiz kullanılıyor
- İyi kullanıldıkları yerlerde ise muhtemelen bunları duymuyorsunuzdur
- Önemli gerçek: Organizasyonumuzda mühendis başına 30'dan fazla mikroservis var. Lütfen beni öldürün. Binlerce mikroservisin olduğu dev bir monorepo ile çalışan başka bir organizasyonda olmaktansa kelimenin tam anlamıyla Kurt Cobain olmayı tercih ederim
- Bu yazıya gelen yorumlar
- zug_zug : Bu teoriyi gerçek verilerle desteklemek gerekirse
- New York'ta Akka (Scala'nın event-driven queueing yaklaşımı) kullanan bir startup'ta çalışmıştım
- Neden böyleydi? Önceki işindeki yöneticisi bu yöntemin "her şeyin yavaş olduğu" zamanda şirketi "kurtardığını" söylediği için yeni işte bunu zorunlu tuttuğu için mi?
- Gerçekte kuyruklamaya ihtiyaç duyan iş neydi? Web sitesi üzerinden çalışanların 401k bilgilerini göstermek, varlık dağılımını ayarlamalarını sağlamak ve günde birkaç yüz e-posta göndermekten ibaretti
- Beklendiği gibi insanlar 401k sitesine pek sık giriş yapmıyordu
- Orada yaklaşık 1 yıl çalıştıktan sonra, sunucuların sürekli yanlış yapılandırıldığını ve temelde web istekleri için eşzamanlılığın 0 olduğunu fark ettim
- (Bunu fark etmemiştik çünkü 2 production sunucusu tüm trafiği zaten her zaman karşılıyordu)
- Sonunda gereksiz ve gereksiz yere karmaşıklığı artırdığı için Akka kaldırıldı
- Geçen ay şirket bir kez daha nakde dönüş seçeneği içeren yatırım turuna çıktı; belli ki değerlemesi artmış ve hâlâ iyi gidiyor gibi görünüyor
- scary-size : Bu kulağa gerçekten de sadece "parlak" mühendisler işe alıyormuşsunuz gibi gelmiyor?
- roncesvalles : Tasarım inceleme süreci yok gibi duruyor. Ben olsam ünlü üniversite mezunlarından ziyade adı sanı duyulmamış okullardan 2-5 yıllık geliştiricileri alırdım. Yazılım mühendislerinin kariyerlerinin ilk 5 yılında öğrendikleri ve büyüdükleri şeylerin miktarı muazzam; muhtemelen kariyerlerinin kalanının toplamından bile fazla.
burutthrow
- MQ'nun epey commodity haline geldiğini düşünüyorum
- Confluent, RedPanda ya da MSK'yı servis olarak alırsanız Kafka'yı kendiniz yönetmeniz gerekmiyor
- Change Data Capture (CDC) de çok iyi hale geldi ve ana akım oldu. Veriyi RDBMS'e yazıp ardından değişiklik verisini yakalayarak başka sistemlere yaymak artık nispeten kolay
- Örneğin mesaj kuyruğu, CDC sisteminin mesajları iletmek için kullandığı omurgadan ibaret olabiliyor; bu yüzden insanlar artık Kafka hakkında yazmıyor olabilir
- Bu mimariler elbette hâlâ var ve çoğu organizasyonun kısıtlarını karşılıyor
- Kafka gibi bir kez yazılıp çok kez okunan kuyruklar olduğunda, organizasyonun diğer kısımlarına API açmak yerine bu desen kullanılıyor. Birçok şirket, ekipler arası veriyi karıştırıp kullanmak için bu modeli benimsiyor
- Çok sayıda mikroservise sahip küçük ekipler özgeçmiş odaklı geliştiriciler gibi hissettirse de, 100'den fazla mühendisi olan şirketlerde bu desen mantıklı
angarg12
- MQ, dağıtık sistemler araç kutusundaki bir araçtır. Gerektiğinde harika çalışır
- Senin teorilerin içinden biri doğruysa bence bu şu: "İnsanlar genelde yeni ve parlak şeyler hakkında blog yazısı yazar"
- Ben kişisel olarak tasarımlarımda her zaman kuyruk kullanıyorum; özellikle de yüksek derecede ayrışmış farklı sistemler arasında veri taşırken
- Yaşadığım tek acı, upstream sistemden 7 günlük verinin yeniden doldurulması sırasında kuyruğun eski isteklerle tıkanmasıydı
- Normal şekilde çalıştırsaydık tüm veriyi işlemek 100 saatten fazla sürecekti ve yeni verilerin gecikmesi de aşırı artacaktı
- Çözüm, kuyruğu manuel temizlemek ve eksik en güncel veriyi elle yeniden doldurmak oldu
- Sınırsız kuyruk boyutuna dikkat etmek gerekir ama hâlâ harika bir araç olduğunu düşünüyorum
rossdavidh
- MQ, Gartner Hype Cycle içinde
- 'Peak of inflated expectations' aşamasını geçti
- 'trough of disillusionment' aşamasını geçti
- ve şimdi 'Slope of Enlightenment', hatta 'plateau of productivity' aşamasına doğru ilerliyor
robertclaus
- "Açıkça hepimiz hâlâ mesaj kuyrukları ve worker'lar kullanıyoruz, sadece bunun hakkında yazmıyoruz" diyen yorumun, mikroservisler ve gerçek ölçeklenebilirlik tartışmaları arasında gerilerde kalması çok ilginç
- Bu yorumu okuyan junior mühendisler, artık web sunucusundaki ağır hesaplamaları worker'lara devretmemeleri gerektiği gibi yanlış bir izlenim edinebilir
pm90
- Teknoloji sıkıcı hale geldiği için onunla ilgili blog yazıları azaldı
- Bu iyi bir şey. Örneğin RabbitMQ resmi dokümantasyonu artık çok daha iyi ve çok faydalı
- İnsanlar bunu Postgres/MySQL kullanır gibi temel araç olarak kullanıyor
- Mimari vb. tasarlamak için de olağanüstü teknikler gerekmiyor
- Ben sıkıcı yazılımı seviyorum: "I love boring software"
slowmovintarget
- Bu mimarilerin çoğu kurumsal veri merkezlerinde çalışıyordu
- Buluta geçiş ve küçük stateless servislerin yaygınlaşmasıyla (SPA'lerin ortaya çıkışı), karmaşık çok adımlı event-driven sistemlere daha az ihtiyaç duyulmaya başlandı
- Örneğin AWS'de SQS ve biraz SNS ya da bazı durumlarda Kinesis kullanmak yeterli oluyor. Burada MQ artık tasarımın merkezi değil
- MQ tabanlı mimariler veri işleme için iyidir ama etkileşimli web siteleri için pek uygun değildir; çoğu insan etkileşimli web siteleri geliştiriyorsa başka tercihlerin öne çıkması normal görünüyor
- Ben hâlâ veri işleme için event sistemleri tasarlıyorum (özellikle yeni bir gerçeğin ortaya çıktığı ama bunun "yanlış" olabildiği ya da önceki bir zamanda farklı bilginin bilinmesi gereken immutable iş verilerinde)
- Ama çoğu uygulamada... buna ihtiyaç yok
mannyv
- Bizim tüm backend'imiz kuyruk tabanlı
- Asenkron bir işse ve hızlı yanıt süresi gerekmiyorsa kuyruk kullanırım. Kolaydır, güvenilirdir ve kuyruk Lambda'yı tetikleyebilir
- Ayrıca kuyruk kullanınca metrik ve performans verisi toplamak da kolaylaşıyor
- Yük yüksek olduğunda kuyruk yüz binlerce hatta milyonlarca mesaja kadar şişip zamanla tekrar küçülebilir
- Ya da isterseniz yüzlerce Lambda oluşturup tüm mesajları işleyebilirsiniz
vishnugupta
- Benim deneyimime göre MQ yok olmadı, soyutlandı
- Örneğin SQS + polling kullanan bir kuyruk, sunucuya daha az çağrı yapan bir sürece dönüşmüş olabilir. Bir yerde yine mesaj kuyruğu vardır, sadece görünmüyordur
- SQS'den bir kat daha soyut olan AWS SNS, özellik bakımından o kadar zenginleşti ki fiilen SQS'in yerini alabilir hale geldi
- Ayrıca streaming çok sağlam bir teknoloji haline geldiği için, kuyruğu streaming pipe olarak kullanan kullanım senaryoları özel streaming çözümlerine taşındı
memset
- Bunun nedeni Lambda'nın (cloud function'ların) daha popüler hale gelmesi ve birden çok platformda desteklenmesi olabilir
- Kuyruğa bir şey eklersiniz, sonra birilerinin onu alıp işlemesi gerekir. Lambda bunu tek bir invocation ile yapar. Ayrıca worker çalıştırmanız ya da ölçeklendirmeniz gerekmez
- Kafka'nın geçici veri deposu olarak kullanılması ve stream'den veri toplamak için büyük bir ekosisteme sahip olması nedeniyle popülerliğini koruduğunu düşünüyorum
- Ben şahsen kuyrukları çok kullanıyorum ve açık kaynaklı bir SQS alternatifi geliştiriyorum. Açık kaynak bir Lambda alternatifi de faydalı olur mu diye merak ediyorum
liampulles
- "MQ teknolojileri artık olgunluk dönemine girdi; insanlar bunun hakkında yazacak kadar heyecan duymuyor. Ama hâlâ yaygın biçimde kullanılıyor"
- Evet, bence doğru olan bu. Basit Pub/Sub mesajlaşması kullanan asenkron iletişimin basit kullanım senaryoları çok yararlı ve kullanımı da çok zor değil
- Biz (geliştirici topluluğu olarak), event sourcing, karmaşık ağlar ve gereksiz ölçek kurma dönemini aştık. Yani hype döngüsünü geçmiş durumdayız
- Ekibimiz asenkron Pub/Sub ve senkron Request/Response için NATS kullanıyor
- Bu komut tabanlı bir model ve gönderdiğimiz tüm mesajları içeren dev bir log tablomuz var
- Şema ve bu mesajların kullanımı ekibimizin içinde kalıyor; kullanım sonrasında NATS'ten siliniyor
at-least-once delivery kullanıyoruz ve mesaj işleyicilerinin idempotent olması bekleniyor
- NATS'in yanlış yapılandırılması nedeniyle mesajların yeniden oynatıldığı veya mesaj kaybı yaşandığı bir iki sorun oldu ama genel olarak çok başarılıydı; üstelik sadece 3 kişilik bir geliştirme ekibiydik
- Bence Kubernetes gibi: temellere sadık kalır ve fazla zeki olmaya çalışmazsan iyi çalışıyor
11 yorum
Kuyruğun gerekli olduğu uygun durumlar vardır. Ancak çoğu ölçek ve kullanım biçiminde, kuyruk kullanmak ya da bunu bir küme halinde çalıştıracak şekilde kurmak, karmaşıklığı artırırken performans açısından da çoğu zaman büyük bir avantaj sağlamaz. Ölçeklenebilirlik ve büyük veri göz önünde bulundurularak kurulmuş büyük şirketlerin övündüğü karmaşık yapılar, benim sistemim için uygun hale geleceği noktaya hiç ulaşmayabilir.
Teknik olarak çekiciliği yüksek yeni teknolojiler ve havalı yapılar da olsa, gerçek dünyadaki sorunları düşünerek uygun çözümü seçmek gerekir. Çoğu durumda işlenecek büyük veri yoktur ve pek çok durumda PostgreSQL ile çözüm mümkündür.
Biz de bu sorunun farkındayız ve basit bir yapıda, tek bir düğüm üzerinde TB düzeyindeki veriyi işleyebilen bir veritabanı geliştiriyoruz. Biraz temkinli söylemek gerekirse, bunu da başka bir seçenek olarak değerlendirmenizi öneririz.
İçtihat verilerini hızlıca aranabilir hale getirmek
Genel olarak prosedürel yaklaşımı anlamak kolaydır; ancak MQ yöntemi çoğu insana hemen sezgisel gelmez ya da yapısını anlamak zor olabilir diye düşünüyorum. Şirketlerde genellikle herkesin bilgi seviyesi aynı olmuyor; bu durumda MQ yanlış bilgiyle kullanılırsa adeta cehenneme dönüşebiliyor.
Bence bu sadece MQ'ya özgü değil; belli ölçüde uzmanlık gerektiren teknolojilerin çoğunda, yeterli eğitim olmadan uygulandığında her zaman ortaya çıkan bir sorun.
PHP'de MQ aslında fiilen zorunlu...
Canım yandı!
Şu anda adı Quee geçen bir Toy Project üzerinde çalışıyorum da.
Açıkçası, hizmet %99 sadece ülke içinde verilecekse bunların hiçbirine gerek olmadığını düşünüyorum..
Hizmet kapsamından ziyade, hizmetin niteliğiyle ne kadar maliyet verimliliğinin hesaba katılması gerektiği daha önemli değil mi?
Karar alma süreci sonuçta dikey olduğu için, “prosedürel” olanın daha çok tercih edildiği ya da daha uygun görüldüğü söylenebilir mi?
Eğer her departman ve ekip gevşek biçimde örgütlenmişse, prosedürel olmayan bir mimarinin daha sorunsuz çalışacağı ve bu yüzden bu tür kuyruk uygulamalarının da daha iyi işleyeceği düşünülebilir mi, bunu merak ediyorum.
Özgeçmiş odaklı geliştirme, bu tür popülerlik dalgalarını açıklayan anahtar kelime gibi görünüyor.
Vay be, özgeçmiş odaklı geliştirme ne kadar da veciz bir söz...
Kardeş ürünü olarak hype-driven development da var