İster yeni bir uygulamayı büyütüyor 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, büyük hacimli iletiler 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 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. 429 üstbilgileri içeren retry-after hata yanıtları, isteği yeniden denemeden önce belirli bir süre beklemeniz gerektiğini belirtmek için 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.
Titreme: İstekleri tam aralıklarla yeniden denemeyi önleme. 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 nedir?
Birkaç farklı trafik artışı türü vardır.
Saat başı 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ö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 üstel geri çekilme olmadan yeniden denemek, mevcut trafik zirvelerinin üzerinde tekrarlanan trafik dalgaları oluşturabilir.
Ani trafik kalıbı değişiklikleri: 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 yaymak 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 aynı bildirimi 1 dakika içinde 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 2 dakika içinde mesaj göndermeyin.
Sunucu tarafı sınırlamayı 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 çaba gösterse de bazı istekler zaman aşımına uğrayabilir veya başarısız olabilir. Nedenleri değişse de aşağıdaki en iyi uygulamalar, yeniden deneme davranışını optimize ederek iletileri mümkün olan en kısa sürede teslim 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 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 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 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 arızalardan hızlı ve güvenli bir şekilde kurtulmanızı sağlayacak 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" (sistem davranışını yük altında 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 hotspot ve tıkanıklık olasılığını en aza indirir.
Aşağıda,dünya genelinde 500.000 RPS'yi FCM Eski HTTP API'den FCM HTTP v1 API'ye taşıma ile 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ı:
- 95. yüzdelik dilim gecikmesi 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.