İster yeni bir uygulamayı büyütüyor olun ister yüksek trafikli bir hizmeti yönetiyor olun, bu rehberdeki FCM ile sorunsuz ölçeklendirme hakkındaki analizlerden ve önerilerden yararlanabilirsiniz. Bu kavramlar ve uygulamalar, çok sayıda ileti göndermeniz gerektiğinde olumsuz etkilerden kaçınmanıza yardımcı olabilir.
Temel terimler ve kavramlar
Mesaj İsteği: FCM mesajı isteği; "istek", "mesaj" veya "sorgu" ile birbirinin yerine kullanılır.
Saniyedeki istek sayısı (RPS): FCM'ye gelen isteklerin hızını açıklayan bir metrik. Saniyedeki sorgu sayısı (QPS) ile birbirinin yerine kullanılır.
Kota Jetonları, Jeton Grupları ve Yeniden Doldurma: FCM HTTP v1 API'sine mesaj gönderirken her istek, belirli bir zaman aralığında ayrılan kota jetonunu tüketir. "Token Bucket" adı verilen bu pencere, zaman aralığının sonunda tamamen dolar. Örneğin: HTTP v1 API, her 1 dakikalık jeton grubu için 600.000 kota jetonu ayırır. Bu jeton grubu, her 1 dakikalık pencerenin sonunda tamamen dolar.
Sunucu Tarafı Kısıtlama: Trafik hacmi FCM hizmetinin kapasitesini aştığında, giriş akışına hız sınırı uygulamak için hizmet kapasitesinin üzerindeki istekler reddedilir. İsteği yeniden denemeden önce belirli bir süre beklemeniz gerektiğini belirtmek için retry-after üstbilgileri içeren 429 hata yanıtları döndürülebilir.
İstemci Tarafında Sınırlama: İstemciler istek hataları, yüksek gecikme veya 429 hataları gözlemlediğinde tıkanıklığı daha da kötüleştirmemek için çıkış akışını gönüllü olarak hız sınırlamalıdır.
Eksponansiyel geri yükleme: Hataları yeniden denerken katlanarak artan zaman gecikmeleri ekleyin. Örneğin: 1 sn, 2 sn, 4 sn, 8 sn, 16 sn, 32 sn vb.
Titreşim: İstekleri tam aralıklarla yeniden denemeyi önler. Titretme ile, yeniden deneme gecikmelerini rastgele bir işlemle değiştirerek zaman içinde eşit şekilde dağıtırsınız (örneğin: 0,9 sn, 2,3 sn, 4,1 sn, 8,5 sn, 17,9 sn, 34,7 sn).
Yeniden deneme amplifikasyonu: Başarısız istekler eksponansiyel geri yükleme/titretme olmadan yeniden denendiğinde genellikle birikir ve devam eden trafik yüküne eklenir. Bu durum, trafik sıkışıklığı sorunlarını "amplifiye" edip daha da kötüleştirebilir.
Sorun: Trafikteki ani yükselişler
FCM, saniyede milyonlarca isteği (RPS) işler. Sistemsel tıkanıklık, gecikme sorunları ve kesintilere en büyük katkıyı trafik artışları yapar.
Ani trafik artışı nedir?
Birkaç farklı trafik artışı türü vardır.
Saat başındaki ani artışlar: FCM, her saatin ilk 30 saniye ile 2 dakikası arasında iki katından fazla trafik alıyor. Benzer ancak daha küçük artışlar, yarım saat ve çeyrek saat aralıklarında da gözlemlenir (örnekler: 00:15, 00:30, 00:45).
Yeniden deneme amplifikasyonu: Başarısız olan veya zaman aşımına uğrayan istekleri üstel geri çekilme olmadan yeniden denemek, mevcut trafik zirvelerinin üzerinde tekrarlanan trafik dalgaları oluşturabilir.
Trafik modelinde ani değişiklikler: Yeni trafiği FCM'ye yönlendirmek veya trafiği bölgeler arasında FCM'ye taşımak, kademeli artış gibi yumuşatma faktörleri olmadan ani artışlara neden olabilir.
Kota jetonu kullanımını önceden yükleme: İstekleri kota pencerelerine eşit şekilde dağıtmak yerine kota pencerelerinin başında tüm kota jetonlarını tüketmek, yük dengelemesi zor ve maliyetli olan açma/kapama salınımları oluşturur.
Özel etkinlikler: Tatillerde (Yılbaşı) veya spor etkinliklerinde (FIFA Dünya Kupası) trafikteki ani artışlar.
"Eğriyi düzleştirerek" trafik artışlarını düzeltme
Bu bölümde, mümkün olduğunda trafik artışlarını yumuşatmak için kullanılan stratejiler ("eğriyi düzleştirme" stratejileri) açıklanmaktadır.
FCM özelliğini yalnızca uygun kullanım alanlarında kullanın
Bildirim göndermek için FCM'nin gerekli veya uygun olmadığı bazı kullanım alanları vardır.
Örneğin, takvim etkinliği bildirimleri için uygulamanızdan göndermek yerine uygun zamanlarda bildirim göstermek üzere uygulamanızda yerel bir görev planlayabilirsiniz. FCM mesajlarını takvim senkronizasyonlarıyla sınırlayın.
Ani artışlardan kaçınma
Bir ölçeklendirme karşı kalıbı, sunucu tarafı sınırlama uygulamak yerine FCM bildirimlerini sistemlerin izin verdiği kadar hızlı göndermektir. Aşağıdakileri göz önünde bulundurun:
- Tüm müşterilerinizin 1 dakika içinde aynı bildirimi alması mı gerekiyor? Örneğin, 5 dakikalık bir teslimat aralığı işletme ihtiyaçlarınızı karşılamaya devam eder mi?
- Ani artışları yumuşatmak için müşterileriniz önceliğe göre segmentlere ayrılabilir mi?
- Bildirimleriniz önceden planlanabilir mi?
Mümkün olduğunda: FCM gönderme kotanızın hemen tükenmesine neden olan ve jeton paketiniz yeniden dolduğu anda tekrarlanan stratejilerden kaçının. Bu erişim kalıbı, FCM ve bağımlı sistemleri için yük dengeleme sorunlarına neden olur. Trafiği mümkün olduğunca kademeli olarak artırın. En azından 60 saniyelik bir zaman aralığında 0'dan maksimum RPS'ye kadar artış yapın. Daha yüksek RPS için daha uzun aralıkları tercih edin.
"Saat başı" trafiğinden kaçınma
Mümkün olduğunda: :00, :15, :30 ve :45 dakikalık işaretlerin her birinden 2 dakika önce veya sonra mesaj göndermeyin.
Sunucu tarafı sınırlamayı uygulama
FCM'ye trafik akışını izlemek ve yönetmek için sunucu tarafı sınırlama uygulayın.
Yeniden denemeleri işleme
FCM yüksek kullanılabilirlik için çaba gösterse de bazı istekler zaman zaman zaman aşımına uğrar veya başarısız olur. Nedenleri değişse de aşağıdaki en iyi uygulamalar, mesajları mümkün olan en kısa sürede iletmek için yeniden deneme davranışını optimize ederken trafik sıkışıklığı üzerindeki etkiyi en aza indirir.
Zaman aşımı
Yeniden denemeden önce gönderme isteklerinde en az 10 saniyelik bir zaman aşımı ayarlayın. FCM'nin dahili Uzaktan Prosedür Çağrıları'nın çoğu 10 saniyelik bir zaman aşımı kullanır.
Hatalar
- 400, 401, 403, 404 hataları için: işlemi durdurun ve yeniden denemeyin.
- 429 hataları için: retry-after üstbilgisinde ayarlanan süre boyunca bekledikten sonra yeniden deneyin. Yeniden deneme sonrası üstbilgisi ayarlanmamışsa varsayılan olarak 60 saniye kullanılır.
- 500 hataları için: Eksponansiyel geri yüklemeyle yeniden deneyin.
Eksponansiyel geri yükleme
Yeniden deneme büyütmesini önlemek için istekleri yeniden denerken eksponansiyel geri yüklemeyi jittering ile birlikte uygulayın. Örneğin, Firebase Admin SDK'sında eksponansiyel geri yükleme uygulanır.
Önerilen diğer ayarlardan bazıları:
- Minimum aralık: Başarısız olan bir isteği FCM ile hemen yeniden denemeyin. Başarısız bir isteği yeniden denemeden önce en az 10 saniye bekleyin.
- Maksimum aralık: Süresi dolmuş istekleri süresiz olarak yeniden denemek yerine, bu istekleri bırakmak için maksimum aralık belirleyin.
Bir istek, eksponansiyel geri yüklemeyle sürekli olarak yeniden denenmesine rağmen 60 dakika sonra hâlâ başarısız oluyorsa bu istek, yeniden denenebilir bir hata olarak yanlış sınıflandırılmış olabilir veya FCM'de, yeniden denemelerin durumu istemeden kötüleştirebileceği bir kesinti yaşanıyor olabilir.
Kullanıma sunma ve geri alma planları oluşturma ve kademeli değişiklikler yapma
FCM'ye gelen trafiği artırmak veya bölgeler ya da ağlar arasında trafik kaydırmak gibi büyük ölçekli trafik değişiklikleri yaparken bir kullanıma sunma/geri alma planı tasarlamak ve kademeli değişiklikler uygulamak kullanıcılarınızı, hizmetinizi ve FCM'yi korur.
- Kullanıma sunma planı, paydaşların beklentilerini karşılar. Bazı durumlarda (aşağıda açıklanmıştır) sürprizlerle karşılaşmamak için dağıtım planınızı önceden FCM ekibiyle paylaşmak isteyebilirsiniz.
- Geri alma planı, beklenmedik durumları hesaba katmanıza ve öngörülemeyen hatalardan hızlı ve güvenli bir şekilde kurtulmak için mekanizmalar hazırlamanıza olanak tanır.
- Kademeli değişiklik yapmanın iki yönü vardır:
- "Adım adım" artışlar: Adımlar %1 -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 veya daha ince olmalıdır. Her adımı 1 gün ila 1 hafta boyunca "Soak" (yük altındaki sistem davranışını gözlemleyin). Bu sayede, bir sonraki "üst seviyeye geçiş" öncesinde olası sorunları tespit edebilirsiniz.
- Trafiği kademeli olarak artırma: Trafiği artırmak için her "adım"ı attığınızda trafiği en az bir saatlik süreye yayın. Bu sayede, FCM'nin yük dengeleme altyapısı, yeni trafiğinizi uygun şekilde ölçeklendirirken hotspot ve tıkanma olasılığını en aza indirir.
Aşağıda,FCM Eski HTTP API'sinden FCM HTTP v1 API'sine küresel olarak 500.000 RPS'nin taşınmasıyla ilgili varsayımsal bir senaryo verilmiştir:
| Hafta | Step | Aşamalı artış stratejisi |
|---|---|---|
| 0 | %1 artış | Bir saat içinde 0'dan 5.000 RPS'ye kadar FCM HTTP v1'e sorunsuz bir şekilde geçiş yapın. |
| 1 | %5 artış | 2 saat içinde 5.000 RPS'den 25.000 RPS'ye sorunsuz bir şekilde çıkın. |
| 2 | %10 artış | 2 saat içinde saniyede 25.000 istekten 50.000 isteğe sorunsuz bir şekilde çıkış yapın. |
| 3 | %25 artış | 3 saat içinde 50.000 RPS'den 125.000 RPS'ye yükselme |
| 4 | %50 artış | 6 saat içinde 125.000 RPS'den 250.000 RPS'ye yükselme |
| 5 | %75 artış | 6 saat içinde 250.000 RPS'den 375.000 RPS'ye yükselme |
| 6 | %100 artış | 6 saat içinde 375.000 RPS'den 500.000 RPS'ye yükselme |
Varsayımsal geri alma planı:
- Gecikme değeri 95. yüzdelik dilimde 500 ms'den fazla artarsa veya hata oranı herhangi bir adımda bir saatten uzun süre% 1'i aşarsa önceki adıma hemen geri dönmek için dinamik yapılandırmayı kullanın.
- Gecikme ve hata oranı normal seviyelere dönene kadar önceki adımlara geri dönmeye devam edin.
FCM'ye ne zaman ulaşmalısınız?
Aşağıdaki durumlardan herhangi biri geçerliyse Firebase Destek Ekibi aracılığıyla FCM ile iletişime geçin:
- Varsayılan kotalar artık kullanım alanınıza uygun değil
- Gönderme kalıplarınızı 3 aylık bir süre içinde, küresel olarak 100.000 RPS veya kıtasal olarak 30.000 RPS ölçeğinde değiştiriyorsunuz.