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 Grupları ve Yeniden Doldurma: FCM HTTP v1 API'ye mesaj gönderirken her istek, belirli bir zaman aralığında ayrılan bir kota jetonunu tüketir. "Token Bucket" adı verilen bu pencere, zaman aralığının sonunda yeniden 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 dönemin 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ı 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 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 göndermemeyi ifade eder. 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 olan istekler eksponansiyel geri yükleme/titretme olmadan yeniden denendiğinde genellikle birikerek devam eden trafik yüküne eklenir ve trafik tıkanıklığı sorunlarını "amplifiye" edip daha da kötüleştirebilir.
Sorun: Trafik artışları
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şı 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örülür (örnekler: 00:15, 00:30, 00:45).
Yeniden deneme amplifikasyonu: Başarısız olan veya zaman aşımına uğrayan istekleri eksponansiyel geri yükleme olmadan yeniden denemek, mevcut trafik zirvelerinin üzerinde tekrarlayan trafik dalgaları oluşturabilir.
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ı ö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şatacak stratejiler (yani "eğriyi düzleştirecek" stratejiler) 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çının
Bir ölçeklendirme anti-pattern'i, sunucu tarafı sınırlama uygulamak yerine sistemlerin izin verdiği en hızlı şekilde FCM bildirimleri göndermektir. Aşağıdakileri göz önünde bulundurun:
- Tüm müşterilerinizin aynı bildirimi 1 dakika içinde alması mı gerekiyor? Örneğin, 5 dakikalık bir teslimat aralığı işletmenizin ihtiyaçlarını karşılamaya devam eder mi?
- Müşterileriniz, yoğunluk dönemlerini yumuşatmak için önceliğe göre segmentlere ayrılabilir mi?
- Bildirimleriniz önceden planlanabilir mi?
Mümkün olduğunda: Jeton paketiniz yeniden doldurulur doldurulmaz tekrarlanacak şekilde, FCM gönderme kotanızın hemen tükenmesine neden olan stratejilerden kaçının. Bu erişim şekli, 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 kademeli olarak artırı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 dakika işaretlerinden her birinin 2 dakikalık aralığında mesaj göndermeyin.
Sunucu tarafı kısıtlamayı uygulama
FCM'ye gelen 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 çabalasa da bazı isteklerin zaman aşımı veya başarısızlık yaşaması mümkündür. 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.
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 iptal edin ve yeniden denemeyin.
- 429 hataları için: retry-after üstbilgisinde ayarlanan süre boyunca bekledikten sonra yeniden 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ında eksponansiyel geri yükleme uygulanır.
Önerilen diğer bazı ayarlar:
- 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ü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 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 gelen trafiği artırmak veya bölgeler ya da ağlar arasında trafiği değiştirmek 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 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 ince olmalıdır. Her adımı 1 gün ila 1 hafta boyunca "ıslatın" (sistemin yük altındaki 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.
Aşağıda,FCM Eski HTTP API'den FCM HTTP v1 API'ye 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 25.000 RPS'den 50.000 RPS'ye sorunsuz bir şekilde yükseltme |
| 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ı:
- %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ğıdaki durumlardan herhangi biri geçerliyse Firebase Destek 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 dönem içinde, küresel olarak 100.000 RPS veya kıtasal olarak 30.000 RPS ölçeğinde değiştiriyorsunuz.