İster yeni ortaya çıkan bir uygulamayı büyütüyor ister halihazırda yüksek trafik alan bir hizmet çalıştırıyor olun, FCM ile sorunsuz şekilde ölçeklendirme yapma konusunda bu kılavuzdaki analizlerden ve önerilerden yararlanabilirsiniz. Bu kavramlar ve uygulamalar, çok sayıda mesaj göndermeniz gerektiğinde olumsuz etkilerden kaçınmanıza yardımcı olabilir.
Anahtar terimler ve kavramlar
Mesaj İsteği: FCM mesaj isteği; "request", "message" veya "query" ile birbirinin yerine kullanılır.
Saniye başına istek sayısı (RPS): FCM'ye gelen isteklerin oranını tanımlayan bir metriktir. Saniye başına sorgu sayısı (QPS) ile birbirinin yerine kullanılır.
Kota Jetonları, Jeton Paketleri ve Yedekler: FCM HTTP v1 API'ye mesaj gönderirken her istek, belirli bir zaman aralığında tahsis edilen bir Kota Jetonu kullanır. "Jeton Paketi" adı verilen bu aralık, zaman aralığının sonunda tamamen doldurulur. Örneğin, HTTP v1 API, her 1 dakikalık Jeton Paketi için 600 bin Kota Jetonu ayırır. Bu jeton, her 1 dakikalık sürenin sonunda tamamen doldurulacak şekilde doldurulur.
Sunucu tarafı sınırlama: Trafik hacmi FCM hizmetinin kapasitesini aştığında, sunma kapasitesini aşan istekler hız sınırı giriş akışına yönelik olarak reddedilir. İsteği yeniden denemeden önce belirli bir süre beklemeniz gerektiğini belirtmek için retry-after başlıklarına sahip 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ığı artırmaktan kaçınmak için hız sınırlamasını gönüllü olarak sınırı uygulanmalıdır.
Eksponansiyel geri yükleme: Hataları yeniden denerken katlanarak artan süre gecikmeleri ekleyin. Örneğin: 1 sn., 2 sn., 4 sn., 8 sn., 16 sn., 32 sn.
Ses dalgalanması: Tam aralıklarda yeniden deneme yapmaktan kaçınma. Titreme ile, zaman içinde eşit şekilde dağıtmak için yeniden deneme gecikmelerini rastgele bir işlemden geçirirsiniz (örneğin: 0,9 sn, 2,3 sn, 4,1 sn, 8,5 sn, 17, 9 sn, 34, 7 sn).
Yükseltmeyi yeniden deneme: Başarısız istekler üstel geri çekilme/titreşme olmadan yeniden denendiğinde, genellikle birikerek devam eden trafik yüküne eklenir ve bu da trafik tıkanıklığı sorunlarını "yükselterek" ve alevlendirebilir.
Sorun: ani trafik artışları
FCM, saniyede milyonlarca isteği (RPS) işler. Sistemsel tıkanıklığa, gecikme sorunlarına ve kesintilere en çok katkıda bulunan faktörler, trafikteki ani artışlardır.
Ani trafik artışı nedir?
Birkaç farklı türde trafik artışı vardır.
Saat içi artışlar: FCM, her saatin ilk 30 saniyesi ila 2 dakikası arasında iki kattan fazla trafik alır. Benzer şekilde, daha az olsa da artışlar yarım saat ve çeyrek saat işaretlerinde de görülür (örnekler: 00:15, 00:30, 00:45).
Artırmayı yeniden deneme: Başarısız veya zaman aşımına uğrayan istekleri üstel geri yükleme olmadan yeniden denemek, mevcut trafik eşiklerinin yanı sıra yinelenen trafik dalgalarına neden olabilir.
Ani trafik kalıbı değişiklikleri: Yeni trafiğin FCM'ye yönlendirilmesi veya kademeli artış gibi yumuşatıcı faktörler olmadan trafiği FCM'ye taşımak ani artışlara neden olabilir.
Önden yükleme kota jetonu kullanımı: İstekleri kota aralıkları genelinde eşit şekilde dağıtmak yerine, kota aralıklarının başında tüm kota jetonlarının tükenmesi, yük dengelemesi zor ve pahalı olan açma-kapama salınımlarına yol açar.
Özel etkinlikler: Tatillerde (Yılbaşı Gecesi) veya spor etkinliklerinde (FIFA Dünya Kupası) ani trafik artışları.
"Eğriyi düzleştirerek" trafikteki ani artışları düzeltme
Bu bölümde, mümkün olduğunda trafik artışlarını düzeltmeye yönelik stratejiler ("eğriyi düzeltme" stratejileri) açıklanmaktadır.
FCM'yi yalnızca uygun kullanım alanları için kullanın
Bildirim göndermek için FCM'nin kullanılmasının gerekli veya uygun olmadığı bazı kullanım alanları vardır.
Örneğin, takvim etkinliği bildirimleri için uygulamanızda yerel bir görevi, uygulama sunucunuzdan göndermek yerine uygun zamanlarda bildirim görüntüleyecek şekilde planlayabilirsiniz. FCM iletilerini takvim senkronizasyonlarıyla sınırlandırın.
Ani artışlardan kaçının
Ölçeklendirme karşıtı kalıplardan biri, FCM bildirimlerini sunucu tarafı kısıtlama uygulamak yerine, sistemlerin izin verdiği hızda göndermektir. Aşağıdakileri göz önünde bulundurun:
- Tüm müşterilerinizin aynı bildirimi 1 dakikalık süre içinde alması gerekiyor mu? Örneğin, 5 dakikalık bir teslimat aralığı işletmenizin ihtiyaçlarını yine de karşılar mı?
- Müşterileriniz, ani artışları sorunsuz hale getirme önceliğine göre segmentlere ayrılabilir mi?
- Bildirimlerinizi önceden planlayabilir misiniz?
Mümkün olduğunda: FCM gönderme kotanızın hemen tükenmesine neden olan stratejilerden kaçının. Jeton paketiniz dolduğunda kalıbı tekrar edin. Bu erişim kalıbı, FCM ve ona bağlı sistemleri için yük dengeleme problemleri oluşturur. 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 geçiş yapın. Daha yüksek RPS için daha uzun aralıklar tercih edin.
"Saat içi" trafikten kaçınma
Mümkün olduğunda: İletileri :00, :15, :30 ve :45 dakika işaretlerinin her birinde 2 dakikalık bir zaman aralığı içinde göndermekten kaçının.
Sunucu tarafı kısıtlama 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 düzeyde kullanılabilirlik için çaba gösterse de bazen bazı istekler zaman aşımına uğrayabilir veya başarısız olabilir. Nedenler değişiklik gösterse de aşağıdaki en iyi uygulamalar, trafik sıkışıklığı üzerindeki etkiyi en aza indirirken mesajları 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ı süresi ayarlayın. FCM'nin dahili Uzak Prosedür Çağrılarının çoğu 10 saniyelik zaman aşımını kullanır.
Hatalar
- 400, 401, 403, 404 hataları için: İşlemi iptal edin ve yeniden denemeyin.
- 429 hataları için: Sonra yeniden deneme başlığında belirlenen süreyi bekledikten sonra yeniden deneyin. Yeniden deneme üstbilgisi ayarlanmazsa varsayılan olarak 60 saniyeye ayarlanır.
- 500 hataları için: Eksponansiyel geri yükleme ile tekrar deneyin.
Eksponansiyel geri yükleme
Yeniden deneme yükseltmeyi önlemek amacıyla yeniden deneme isteklerinde titremeyle üstel geri çekme uygulayın. Örneğin, Firebase Admin SDK'da eksponansiyel geri yükleme uygulanır.
Önerilen diğer ayarlardan bazıları şunlardır:
- Minimum Aralık: Başarısız 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üresiz olarak yeniden denemek yerine, artık zamanında gelmeyen isteklerin düşülmesi için maksimum aralık belirleyin.
Bir istek üstel geri yükleme ile sürekli olarak yeniden deneniyorsa ve 60 dakika sonra hâlâ başarısız oluyorsa bu, yeniden denenebilir hata kategorisinde yanlış kategorize edilmiş veya FCM, yeniden denemelerin yanlışlıkla durumu kızıştırabileceği bir kesinti yaşamıştır.
Kullanıma sunma ve geri alma planları oluşturup kademeli değişiklikler yapın
FCM'ye giden trafiği artırmak veya trafiği bölgeler ya da ağlar arasında değiştirmek gibi büyük ölçekli trafik değişiklikleri yaptığınızda, bir kullanıma sunma/geri alma planı tasarlamak ve kademeli değişiklikler uygulamak kullanıcılarınızı, hizmetinizi ve FCM'yi koruyacaktır.
- Kullanıma sunma planı, paydaşların beklentilerini birbiriyle uyumlu hale getirir. Bazı durumlarda (aşağıda açıklanmıştır) sürprizlerin önüne geçmek için kullanıma sunma planınızı FCM ekibiyle önceden paylaşabilirsiniz.
- Geri alma planı, beklenmedik durumları hesaba katabilmenizi ve öngörülemeyen arızalardan hızlı ve güvenli bir şekilde kurtulmak için mekanizmalar hazırlamanızı sağlar.
- Kademeli değişiklikler yapmanın iki boyutu vardır:
- "Adım adım" artışlar: Adımlar %1 -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 veya daha hassas olmalıdır. Her adım için 1 gün ila 1 hafta boyunca "Balama" (yükleme altındaki sistem davranışını gözlemleyin). Bu, bir sonraki "adım artışı"ndan önce olası sorunları tespit etmenize olanak tanır.
- Kademeli trafik artışları: Trafiği artırmak için her "adımı" uygularken trafiği en az bir saatlik bir süre boyunca sadeleştirin. Bu, FCM'nin yük dengeleme altyapısının yeni trafiğinizi uygun şekilde ölçeklendirmesini sağlarken hotspot ve tıkanıklık olasılığını en aza indirir.
Dünya genelinde 500.000 RPS'yi FCM Eski HTTP API'den FCM HTTP v1 API'ye taşımayla ilgili varsayımsal bir senaryoyu burada görebilirsiniz:
| Hafta | Step | Kademeli Artış Stratejisi |
|---|---|---|
| 0 | %1 artış | Bir saat içinde 0'dan 5.000 RPS'den FCM HTTP v1'e sorunsuz şekilde yükselin. |
| 1 | %5 artış | 2 saatte 5.000 RPS'den 25.000 RPS'ye sorunsuz şekilde başlayın. |
| 2 | %10 artış | 2 saatte 25.000'den 50.000 RPS'ye sorunsuz şekilde artış |
| 3 | %25 artış | 3 saatte 50.000 RPS'den 125.000 RPS'ye artış |
| 4 | %50 artış | 6 saatte 125.000 RPS'den 250.000 RPS'ye artış |
| 5 | %75 artış | 6 saatte 250.000 RPS'den 375.000 RPS'ye yükselme |
| 6 | %100 artış | 6 saatte 375.000 RPS'den 500.000 RPS'ye yükselme |
Varsayımsal geri alma planı:
- Herhangi bir adımda 95 yüzdelik gecikme 500 ms'nin üzerine çıkarsa veya hata oranı bir saatten uzun bir süre boyunca% 1'i aşarsa hemen önceki adıma dönmek için dinamik yapılandırmayı kullanın.
- Gecikme ve hata oranı nominal düzeylere dönene kadar önceki adımlara geri alma işlemine devam edin.
FCM ile ne zaman iletişime geçmelisiniz?
Aşağıdakilerden herhangi biri geçerliyse Firebase Desteği üzerinden FCM ile iletişime geçin:
- Varsayılan kotalar artık kullanım alanınızı karşılamıyor
- Gönderme kalıplarınızı 3 aylık bir zaman aralığında dünya genelinde 100.000 RPS veya kıtasal olarak 30.000 RPS ölçeğinde değiştiriyorsunuz.