İster yeni bir uygulama geliştiriyor ister yüksek trafikli bir hizmet sunuyor olun, FCM ile sorunsuz bir şekilde ölçeklendirme yapma konusunda bu kılavuzdaki analizlerden ve önerilerden yararlanabilirsiniz. Bu kavramlar ve uygulamalar, çok sayıda ileti göndermeniz gerektiğinde olumsuz etkilerden kaçınmanıza yardımcı olabilir.
Anahtar 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 oranını açıklayan bir metriktir. Saniyedeki sorgu sayısı (QPS) ile birbirinin yerine kullanılır.
Kota Jetonları, Jeton Paketleri ve Yenilemeler: FCM HTTP v1 API'ye mesaj gönderirken her istek, belirli bir zaman aralığında ayrılmış bir Kota Jetonu tüketir. "Jeton paketi" olarak adlandırılan bu pencere, zaman penceresinin sonunda tamamen yeniden doldurulur. Örneğin, HTTP v1 API, her 1 dakikalık jeton paketi için 600.000 kota jetonu ayırır. Bu paket, her 1 dakikalık zaman aralığının sonunda tamamen dolar.
Sunucu tarafı kısıtlama: Trafik hacmi FCM hizmetinin kapasitesini aştığında, giriş akışını sınırlamak için sunum kapasitesini aşan istekler reddedilir. İsteği yeniden denemeden önce belirli bir süre beklemeniz gerektiğini belirtmek için retry-after üstbilgileriyle 429 hata yanıtları döndürülebilir.
İstemci tarafı kısıtlama: İ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 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.
Jittering: İstekleri tam aralıklarla yeniden denemekten kaçınma. Jittering 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 artışı: Başarısız istekler, eksponansiyel geri yükleme/titreşim olmadan yeniden denendiğinde genellikle birikir ve devam eden trafik yüküne eklenir. Bu durum, trafik sıkışıklığı sorunlarını "artırabilir" ve daha da kötüleştirebilir.
Sorun: Trafik artışları
FCM, saniyede milyonlarca isteği (RPS) işler. Sistem genelinde tıkanıklık, gecikme sorunları ve kesintilerin en büyük nedeni trafik artışlarıdır.
Ani trafik artışı nedir?
Birkaç farklı trafik artışı türü vardır.
Saat başı ani artışlar: FCM, her saatin ilk 30 saniyesi ile 2 dakikası arasında iki katından fazla trafik alır. Benzer ancak daha küçük artışlar, yarım saat ve çeyrek saatlerde de (ör. 00:15, 00:30, 00:45) gözlemlenir.
Yeniden deneme artışı: Başarısız olan veya zaman aşımına uğrayan isteklerin eksponansiyel geri yükleme olmadan yeniden denenmesi, mevcut trafik artışlarının üzerine tekrarlanan trafik dalgaları ekleyebilir.
Trafik düzeninde 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ı öne alma: İstekleri kota pencerelerine eşit olarak dağıtmak yerine kota pencerelerinin başında tüm kota jetonlarını tüketmek, yük dengelemesi zor ve maliyetli olan açma-kapama dalgalanmalarına neden olur.
Özel etkinlikler: Tatiller (Yılbaşı Gecesi) veya spor etkinlikleri (FIFA Dünya Kupası) sırasında 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şatma stratejileri, yani "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 kullanmanın gerekli veya uygun olmadığı bazı kullanım alanları vardır.
Örneğin, takvim etkinliği bildirimleri için uygulama sunucunuzdan bildirim göndermek yerine uygun zamanlarda bildirim göstermek üzere uygulamanızda yerel bir görev planlayabilirsiniz. FCM mesajlarını takvim senkronizasyonlarıyla sınırlandırın.
Dikenlerden kaçının
Ölçeklendirme ile ilgili bir anti-pattern, sunucu tarafı kısıtlama uygulamak yerine FCM bildirimlerini sistemlerin izin verdiği hızda göndermektir. Bunun için aşağıdaki seçenekleri kullanabilirsiniz:
- Tüm müşterilerinizin aynı bildirimi 1 dakika içinde alması gerekiyor mu? Örneğin, 5 dakikalık bir teslimat aralığı işletmenizin ihtiyaçlarını karşılar mı?
- Müşterileriniz, yoğunlukları azaltmak için önceliğe göre segmentlere ayrılabilir mi?
- Bildirimleriniz önceden planlanabilir mi?
Mümkün olduğunda: FCM gönderme kotanızı hemen tüketen ve jeton paketiniz yeniden dolar dolmaz aynı kalıbı tekrarlayan stratejilerden kaçının. Bu erişim modeli, 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 yükseltin. 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 dakika işaretlerinin her birinin 2 dakikalık aralığında mesaj göndermekten kaçının.
Sunucu tarafı kısıtlaması uygulama
FCM'ye giden trafik akışını izlemek ve yönetmek için sunucu tarafı kısıtlama uygulayın.
Yeniden denemeleri yönetme
FCM, yüksek kullanılabilirlik sağlamaya çalışsa da bazen bazı istekler zaman aşımına uğrar veya başarısız olur. Nedenler farklılık gösterse de aşağıdaki en iyi uygulamalar, yeniden deneme davranışını optimize ederek iletileri en kısa sürede teslim eder ve trafik yoğunluğu üzerindeki etkiyi en aza indirir.
Engelleme
Yeniden denemeden önce gönderme isteklerinde en az 10 saniyelik bir zaman aşımı ayarlayın. FCM'nin dahili uzak 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 iptal edin ve tekrar denemeyin.
- 429 hataları için: retry-after üstbilgisinde ayarlanan süre kadar bekledikten sonra tekrar deneyin. "retry-after" ü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 sayısının artmasını önlemek için istekleri yeniden denerken gecikme ekleyerek üstel geri yükleme uygulayın. Örneğin, Firebase Admin SDK'sı eksponansiyel geri yükleme uygular.
Önerilen diğer ayarlar şunlardır:
- Minimum Aralık: FCM ile başarısız olan bir isteği hemen yeniden denemeyin. Başarısız bir isteği yeniden denemeden önce en az 10 saniye bekleyin.
- Maksimum Aralık: Süresiz olarak yeniden denemek yerine, artık zamanında olmayan istekleri bırakmak için maksimum bir aralık ayarlayın.
Bir istek, eksponansiyel geri yükleme ile sürekli olarak yeniden deneniyor ve 60 dakika sonra hâlâ başarısız oluyorsa yeniden denenebilir hata olarak yanlış kategorize edilmiştir veya FCM, yeniden denemelerin durumu istemeden daha da kötüleştirebileceği bir kesinti yaşıyordur.
Kullanıma sunma ve geri alma planları oluşturma ve kademeli değişiklikler yapma
FCM'ye giden trafiği artırma veya trafiği bölgeler ya da ağlar arasında kaydırma gibi büyük ölçekli trafik değişiklikleri yaparken 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 uyumlu hale getirir. Bazı durumlarda (aşağıda açıklanmıştır), sürprizlerle karşılaşmamak için kullanıma sunma planınızı FCM ekibiyle önceden paylaşmak isteyebilirsiniz.
- Geri alma planı, beklenmedik durumları hesaba katmanıza ve beklenmedik hatalardan hızlı ve güvenli bir şekilde kurtulmak için mekanizmalar hazırlamanıza olanak tanır.
- Kademeli değişiklikler yapmanın iki yönü vardır:
- "Adım adım" artışlar: Adımlar %1 -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 veya daha küçük olmalıdır. Her adımı 1 gün ila 1 hafta boyunca "bekletin" (yük altında sistem davranışını gözlemleyin). Bu sayede, bir sonraki "adım"dan önce olası sorunları tespit edebilirsiniz.
- Kademeli trafik artışları: Trafiği artırmak için her "adımı" atarken trafiği en az bir saatlik bir süreye yayın. Bu sayede FCM'nin yük dengeleme altyapısı, yeni trafiğinizi uygun şekilde ölçeklendirirken yoğunluk ve tıkanıklık olasılığını en aza indirir.
FCM eski HTTP API'den FCM HTTP v1 API'ye dünya genelinde saniyede 500.000 istek taşıma işlemiyle ilgili varsayımsal bir senaryoyu aşağıda bulabilirsiniz:
| Hafta | Step | Kademeli artış stratejisi |
|---|---|---|
| 0 | %1 artış | FCM HTTP v1'e bir saat içinde 0'dan 5.000 RPS'ye sorunsuz bir şekilde geçiş yapın. |
| 1 | %5 artış | 2 saat içinde 5.000'den 25.000 RPS'ye sorunsuz bir şekilde yükseltin. |
| 2 | %10 artış | 2 saat içinde 25.000'den 50.000 RPS'ye sorunsuz bir şekilde yükseltme |
| 3 | %25 artış | 3 saat içinde 50.000'den 125.000 RPS'ye artış |
| 4 | %50 artış | 6 saat içinde 125.000'den 250.000 RPS'ye yükseltme |
| 5 | %75 artış | 6 saat içinde 250.000'den 375.000 RPS'ye artış |
| 6 | %100 artış | 6 saat içinde 375.000'den 500.000 RPS'ye artış |
Varsayımsal geri alma planı:
- Herhangi bir adımda 95. yüzdelik dilim gecikmesi 500 ms'nin üzerine çıkarsa veya hata oranı bir saatten uzun süre% 1'i aşarsa dinamik yapılandırmayı kullanarak hemen önceki adıma geri dönü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ğıdakilerden herhangi biri geçerliyse Firebase Destek üzerinden FCM ile iletişime geçin:
- Varsayılan kotalar artık kullanım alanınıza uygun değilse
- Gönderim düzeninizi 3 aylık bir dönemde dünya genelinde 100.000 RPS veya kıta genelinde 30.000 RPS ölçeğinde değiştiriyorsanız.