Laravel Bulut Yönetimli Kuyruklar ve Horizon: Kaybettikleriniz ve Kazandıklarınız

Kaynak: hafiz.dev

Laravel Cloud, 26 Mayıs’ta Managed Queues’i hizmete sundu. Bu sistem, iş yükü arttıkça otomatik olarak işçi sayısını artırabilen, boş kaldığında sıfıra ölçeklenebilen ve başarısız işlerin görüntülenebileceği yerleşik bir panel sunan bir yapıdır. Supervisor yapılandırmaları, Redis ayarları veya dağıtım scriptinizde horizon:terminate komutu yok.

Bugün Horizon kullanıyorsanız, sormanız gereken temel soru: önemi ne? Bu soruyu yanıtlamak için dökümantasyonu, duyuru postunu ve fiyat modelini inceledim. Kısacası: Managed Queues gerçek sorunları çözüyor, ancak Horizon kullanıcıları bunun ötesinde bazı şeylerden vazgeçiyorlar. 15 dakikalık bir gecikme limiti var ve bu, birçok uygulamayı sessizce kırabilir. Ayrıca, Horizon kullanıcılarının bel bağladığı Redis özellikleri SQS dünyasında yok.

İşte dürüst bir inceleme.

Managed Queues Nedir?

Öncelikle mimari, çünkü her şeyi açıklar. Managed Queues ile Laravel Cloud, kuyruk sürücünüz haline geliyor. Temelde SQS kullanıyor: uygulamanızın composer.json dosyasında aws/aws-sdk-php bulunmalıdır ve Cloud, kuyrukları sağlar, erişim ayarlarını yapılandırır ve kuyruk derinliğini doğrudan SQS’den okuyarak uygulamanıza gitmeden işlem yapar.

Her işçi, garantili bellekle izole bir konteynerda çalışır. 256 MiB’den 8 GiB’ye kadar bir seviye seçersiniz ve CPU buna göre ölçeklenir. İşler geldiğinde Cloud, kuyruk basınca (derinlik ve mesaj yaşı) bağlı olarak işçileri başlatır. Kuyruk boşaldığında, işçiler sıfıra ölçeklenir ve faturalama durur.

Hafiz.dev’de etkileşimli diyagramı inceleyin

Bunu Horizon (Haziran 2026 itibarıyla v5.47): ücretsiz bir paket, yalnızca Redis kullanıyor, kendi altyapınızda çalışıyor. İşçi havuzlarını ve dengeleme stratejilerini config/horizon.php dosyasında tanımlarsınız, ana süreci Supervisor ile canlı tutarsınız ve her dağıtımda horizon:terminate komutunu çağırmayı unutmazsınız. Horizon size muazzam kontrol sağlar. Ama aynı zamanda tüm operasyonel sorumluluğu da üstlenirsiniz.

Gerçek değişim burada: kontrol ve Redis özellikleri ile tam altyapı ve sekund başı faturalama arasında bir tercih.

Ne Kazanıyorsunuz?

Sıfıra ölçeklenme. Bu başlıca avantaj. Forge ile yönetilen bir VPS veya Hetzner kutusunda bir Horizon kurulumu, bir milyon işi işleyip işlemediğinizde aynı ücreti alır. Managed queue işçileri atıl durumda ise hiçbir maliyet yok. Yan proje, test ortamları ve patlayıcı iş yüküne sahip uygulamalar için bu gerçek bir fark yaratır.

Gerçek işçi izolasyonu. Her işçi, garantili bellek ile kendi konteynerini alır. Bir iş, belleği aşarsa sadece o işçi etkilenir, komşuları değil. Horizon’da işçiler aynı sunucuyu paylaşır; bellek tüketen bir iş, tüm sunucuyu çökertir.

Kapasite planlaması olmadan patlama emilimi. Cloud, sıfırdan maksimum işçi kapasitesine otomatik olarak ölçeklenir. Horizon’da maxProcesses, satın aldığınız RAM ile sınırlıdır. Aynı anda 10,000 iş göndermek, ya tüm ay boyunca ödemeniz gereken bir kaynak sağlar ya da geride yavaşça tükenen bir kuyruk izlersiniz. 10,000 görevi işlemenin bir boyutlandırma alıştırması olduğunu Horizon’da unuttun, Managed Queues’te bir yapılandırma alanıdır.

Destek ekibinizin kullanabileceği bir başarısız işler paneli. Başarısız işler tamamen yük ile, istisna ve yığın izi detayları ile görünür ve ortam erişimine sahip herkes bir tıklama ile yeniden deneyebilir. php artisan queue:retry için SSH ile uğraşmaya gerek yok. Geliştirici olmayanların “ihracatım hiç gelmedi” destek taleplerini yönettiği ekipler için bu, görünenden daha önemlidir.

Arayüzden durdurma ve silme. Durdurma, işçileri hemen durdurur ve işler güvenli bir şekilde birikirken faturayı durdurur. Horizon’daki queue:pause ile karıştırmayın; Horizon’un versiyonu işçileri canlı tutmaya devam eder (ve hala sunucunuzda maliyet oluşturur), Cloud’un versiyonu gerçekten faturayı durdurur.

Ne Kaybediyorsunuz?

Bu, lansman postunda pek üzerinde durulmayan bölüm.

Gecikmeli işler 15 dakika ile sınırlıdır. Bu en büyük tuzak ve kalın harflerle vurgulanmayı hak ediyor. SQS, katı bir 15 dakikalık gecikme limiti sunar ve Managed Queues bunu miras alır. Uygulamanız ->delay(now()->addHour()) ile bir takip e-postası gönderiyorsa veya yarın sabah için bir yeniden deneme programlıyorsa, bu kırılır. Horizon, Redis üzerinde gecikmeleri istediğiniz kadar uzun süre ayarlayabilir. Bu nedenle, birçok Laravel uygulaması uzun gecikmeler kullanmadan düşünmeden geçiyor. Taşımayı düşünmeden önce her delay() ve release() çağrısını denetleyin.

En az bir kez teslimat. Kesin sıralama yok, tam olarak bir kez işleme yok. Bir işçi görünürlük zaman aşımına uğrarsa, dağıtım sırasında sonlandırılırsa veya bir kuyruk uçuşta durdurulursa, işler yeniden teslim edilebilir. İşleriniz idempotent olmalıdır. İyi kuyruk kodu her zaman idempotent olmalıdır ama Horizon’da Redis kullanan birçok uygulama, bir işin sadece bir kez çalıştığını varsayarak gizlice yürüttü. Managed Queues’te bu varsayım bir noktada başınıza iş açar.

Horizon’un Redis araç kutusu yok. Belirli modeller veya iş türleri için izleme etiketleri. Redis::funnel() ve Redis::throttle() üçüncü taraf API çağrılarını sınırlamak için. Yük temelinde işçileri kuyruklar arasında değiştiren dengeleme stratejileri. Per-kuyruk bekleme süresi uyarıları via Slack veya SMS. Tüm bunlar Managed Queues’te yok. Dashboard, her kuyruk için hacim, süre, bellek ve işçi sayıları gösterir, bu iyi bir operasyonel görünürlük sağlıyor. Ancak bu, Horizon’un etiket, işler düzeyindeki granülerliği değil. Daha derin izleme için Laravel’in yanıtı Cloud ile Nightwatch’ı eşleştirmektir; ancak bu, başka bir abonelik gerektirir.

Her managed queue için bir kuyruk adı. Horizon, bir denetleyici ile default,emails,exports öncelikleri ile boşaltmanıza imkan tanır. Cloud’da her kuyruk adı kendi managed kuyruk olup, kendi yapılandırması ile gelir. Starter planında yalnızca 1 kuyruk ve 3 maksimum işçi, Growth, 10 kuyruk ve her biri için 25 işçi tanır; Business ise sınır tanımaz (50 işçiler için yumuşak sınır, artırılabilir). Uygulamanız kuyruk adlarını öncelik yolları olarak kullanıyorsa, yapınızı yeniden düzenlemeniz gerekecek.

Soğuk başlatmalar. Sıfıra ölçeklendirilmiş bir kuyruk, ilk işçisini başlatmak için birkaç saniye sürecektir (mühendislik ekibine göre yaklaşık 10 saniye). Arka plan raporları kimsenin fark etmeyeceği için geçerli. Kullanıcı yüzlü işler “indirilmeniz hazır” gibi ise, iş süresinin üzerine 10 saniyelik bir eklenti gözle görülürdür. İşçileri şu anda sıcak tutmak mümkün değil; yapılandırılabilir bir sıcak minimum planlandı ancak henüz gönderilmedi.

Şu an için yalnızca dashboard üzerinden yönetim. Dağıtımda kuyruk oluşturma, durdurma veya yapılandırma için API veya CLI mevcut değil. Eğer altyapıyı kodla yönetiyorsanız, bu, versiyon kontrolünde bir horizon.php dosyasından gerileme demektir.

Laravel Cloud’dasınız. Belli, ancak değinmeye değer: Managed Queues yalnızca Laravel Cloud’un bir platform özelliği olarak mevcuttur. Horizon her yerde Redis varsa çalışır.

Fiyat Hesaplaması

Managed Queues, iki ölçüm üzerinden faturalandırılır: işçi hesaplama süresi (bellek tabanlı) ve kuyruk işlemleri. Her milyon işlemin maliyeti 1 dolardır. Bir işlem, kuyrukla ilgili herhangi bir API çağrısıdır: her dispatch, alma, silme ve yapılandırdığınız aralıkta her polling kontrolü (varsayılan, 5 saniye). Yüksekliği 64 KB’lik parçalar halinde ölçülür ve maksimum 1 MiB işe sahiptir.

Tipik bir küçük üretim uygulaması için rakamları hesaplayın: diyelim ki ayda 300,000 iş, her biri ortalama 2 saniye sürüyor ve 256 MiB işçi ile. Bu, kabaca 600,000 işçi-saniyesi ve yaklaşık bir milyon işlem (her iş için üç artı polling) eder. Aylık tek haneli dolarlık bir maliyet bekliyoruz ve çoğu gün atıl kalan bir geliştirme veya test ortamı maliyeti neredeyse sıfırdır.

Şimdi Horizon tarafında: ayda €4.49’lık bir Hetzner CX22, bu yük için Horizon’u rahatça çalıştırır. Sabit bir sunucu, sabit bir hacimde, yüksek ve sürekli hacim için ise “per-second” metrikleri daha yüksek olabilir. Kesin bir rakam yok; çünkü bu, iş süresine ve bellek seviyesine bağlıdır. Ancak şekil açıktır: patlayıcı ve atıl durum Managed Queues’i, düz ve sürekli ise sabit bir işçi lehine.

Ayrıca, bu nedenle Cloud hala işçi kümeleri sunuyor (daima queue:work çalıştıran sabit işçiler) ve bunları sürdürülebilir, öngörülebilir throughput için öneriyor. Laravel’ın kendi platformunda bile, otomatik ölçeklendirme her zaman cevap değildir.

Peki Kim Geçiş Yapmalı?

Horizon’da kalın: eğer her yerde 15 dakikadan uzun gecikmeler kullanıyorsanız, etiketlere, Redis::throttle() veya dengeleme stratejilerine bağımlıysanız, throughput’unuz sabit yeterince yükte olduğu için sabit bir sunucu daha ucuzsa veya Laravel Cloud’da değilseniz geçiş için başka bir nedeniniz yoksa kalınız. Horizon olgun, ücretsiz ve v5.47’nin hala aktif bir şekilde sürdürüldüğünü gösteriyor.

Managed Queues kullanın: eğer zaten Cloud üzerindeyseniz (uygulama arka plan süreçleri orada varsayılanı olmalı), iş yükleriniz patlayıcı veya atıl ise, destek personelinin başarısız işleri UI üzerinden denemesini istiyorsanız veya yeni bir projeye başlıyorsanız ve Supervisor yapılandırması yazmak istemiyorsanız. İlk olarak 256 MiB’den bir kuyrukla başlayın, bellek grafiğini izleyin ve ayarlayın.

Uçuş ortasında geçiş yapmayın; bir denetim olmadan. Gecikme limiti ve en az bir kez süreç, sessiz kırıcı değişikliklerdir. delay(, release( ve WithoutOverlapping için grep yapın ve üretim kuyruğunuza geçmeden önce her sonucu kontrol edin.

Kendi görüşüm: Managed Queues, Cloud üzerindeki yeni uygulamalar için doğru varsayılan. Ancak Horizon silinmedi. Operasyonel dikkatinizi per-saniye faturalama yerine yönlendiren daha yetenekli bir araç. Önce 15 dakikalık gecikme limiti ile başlayarak, fiyat, özellikler öncesinde kontrol edin.

Sıkça Sorulan Sorular

Horizon’u Laravel Cloud’da Managed Queues yerine çalıştırabilir miyim?

Evet. Cloud’un işçi kümeleri ile kendi queue:work işlemlerinizi kendi sürücünüzle yönetebilirsiniz ve orada Horizon’u bir Redis örneği üzerinde çalıştırabilirsiniz. Ölçeklenmeyi sıfıra ve yerleşik başarısız işler panelini kaybedersiniz ancak Redis özelliklerini ve uzun gecikmeleri korursunuz.

Managed Queues, Laravel 10 ile çalışır mı?

Hayır. Desteklenen minimumlar Laravel 11.53.1, 12.60.2 ve 13.11.2’dir ve uygulamanızda aws/aws-sdk-php bulunmalıdır. Desteklenmeyen bir sürümde yönetilen bir kuyruk oluşturan dağıtımlar açık bir hata ile başarısız olur.

Başarısız işler tablom ne olacak?

Managed Queues, başarılamayan işleri Cloud panelinde otomatik olarak görünür hale getirir, herhangi bir başarısız işler sürücüsü yapılandırmaya gerek yoktur. Başarısızlıklar, yük, istisna ve yığın izi ile görünür, aynı zamanda UI üzerinden yeniden deneyebilir veya silebilirsiniz.

Uzun gecikmeleri olan programlı işler 15 dakikalık sınıra sahip olduğunda nasıl çalışır?

Doğrudan çalışmaz. Çözüm, yeniden yapılandırmaktır: Uzun gecikmelerle çalıştırmaktansa, planlanan çalışma zamanını saklayın ve zaman geldiğinde job’u scheduler üzerinden gönderin. Bu, bilinen bir SQS modelidir ancak yazmanız ve test etmeniz gereken bir kod.

Horizon’un kullanım ömrü doluyor mu?

Hayır. Horzizon v5.47.2, Haziran 2026’nın başında gönderildi ve Laravel 13 ile desteklenmektedir. Cloud’un kendi kuyruk kümeleri, Managed Queues lehine kaldırıldı ama Horizon, framework paketi olarak hala kendi kendine barındırılan Redis kuyrukları için standarttır.

Sonuç

Managed Queues, kuyruk altyapısı yürütmekten nefret eden ekipler için Laravel Cloud’un şimdiye kadarki en güçlü argümanı: gerçek izolasyon, gerçekten çalışmaya göre ödeme, ve Horizon’un hiçbir zaman sahip olmadığı başarısız işler hikayesi. Horizon, Redis mantığına, uzun gecikmelere, ayrıntılı kontrol ve öngörülebilir düz maliyetlere ihtiyaç duyduğunuzda hala tercih olmaktadır. Uygulamanızın hangi listeye girdiğini bilin ve her şeyden önce bu 15 dakikalık gecikme limitini kontrol edin.

Laravel Cloud’a geçiş yapmayı düşünüyorsanız veya bir kuyruk yapılandırmasını çözmeye çalışıyorsanız, iletişime geçelim.