Yeni bir uygulamayı büyütüyor veya yüksek trafikli bir hizmeti yönetiyor olsanız da bu rehberdeki FCM ile sorunsuz ölçeklendirme hakkındaki analizlerden ve önerilerden yararlanabilirsiniz. Bu kavramlar ve uygulamalar, büyük hacimli iletiler göndermeniz gerektiğinde olumsuz etkilerden kaçınmanıza yardımcı olabilir.
Önemli terimler ve kavramlar
Mesaj isteğ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 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 grubu için 600.000 kota jetonu ayırır. Bu jeton grubu, her 1 dakikalık dönemin 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. 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 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. Sistemik 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şı 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 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: 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ş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ırlayı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. Aşağıdakileri göz önünde bulundurun:
- 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şaretlerinden her birinin 2 dakikalık aralığında mesaj göndermeyin.
Sunucu tarafı kısıtlamayı uygulama
FCM'ye giden trafik akışını izlemek ve yönetmek için sunucu tarafı kısıtlama uygulayın.
Yeniden denemeleri işleme
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 değişse de aşağıdaki en iyi uygulamalar, trafiğin tıkanması üzerindeki etkiyi en aza indirirken iletileri mümkün olan en kısa sürede teslim etmek için yeniden deneme davranışını optimize eder.
Engelleme
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 iptal edin ve yeniden 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 büyütmesini önlemek için istekleri yeniden denerken eksponansiyel geri yüklemeyi jittering ile birlikte uygulayın. Örneğin, Firebase Admin SDK'sı eksponansiyel geri yükleme uygular.
Önerilen diğer ayarlar şunlardır:
- Minimum aralık: Başarısız olan bir isteği FCM ile hemen yeniden denemeyin. Başarısız olan 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ü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 bir kesinti yaşanıyor olabilir. Bu durumda yeniden denemeler durumu istemeden kötüleştirebilir.
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 arızalardan 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 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 "üst sürüme geçiş" işleminden önce olası sorunları tespit edebilirsiniz.
- Aşamalı trafik artışları: Trafiği artırmak için her "adım" atıldığında 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 sıcak noktalar 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 RPS'den 250.000 RPS'ye yükselme |
| 5 | %75 artış | 6 saat içinde 250.000'den 375.000 RPS'ye artış |
| 6 | %100 artış | 6 saat içinde 375.000 RPS'den 500.000 RPS'ye yükselme |
Varsayımsal geri alma planı:
- %95'lik gecikme süresi 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ğı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ğil
- 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.