İster yeni ortaya çıkan bir uygulamayı geliştiriyor olun, ister halihazırda yüksek trafikli bir hizmeti çalıştırıyor olun, bu kılavuzun FCM ile nasıl sorunsuz bir şekilde ölçekleneceğine ilişkin görüşlerinden ve önerilerinden yararlanabilirsiniz. Bu kavram ve uygulamalar, büyük hacimli mesajlar göndermeniz gerektiğinde olumsuz etkilerden kaçınmanıza yardımcı olabilir.
Anahtar terimler ve kavramlar
Mesaj İsteği : Bir FCM mesaj isteği; "istek", "mesaj" veya "sorgu" ile birbirinin yerine kullanılır.
Saniye başına istek (RPS) : FCM'ye gelen isteklerin oranını açıklayan bir ölçüm; Saniyedeki sorgu sayısı (QPS) ile birbirinin yerine kullanılır.
Kota Tokenları, Token Grupları ve Yeniden Doldurmalar : FCM HTTP v1 API'sine karşı mesaj gönderirken, her istek, belirli bir zaman penceresinde tahsis edilmiş bir Kota Tokenını tüketir. " Jeton Kovası " olarak adlandırılan bu pencere, zaman penceresinin sonunda tamamen dolar . Örneğin: HTTP v1 API'si, her 1 dakikalık Token Kovası için 600.000 Kota Tokenı tahsis eder ve bu, her 1 dakikalık pencerenin sonunda tamamen doldurulur.
Sunucu Tarafında Kısıtlama : Trafik hacmi FCM hizmetinin kapasitesini aştığında, giriş akışını hız sınırıyla sınırlamak için hizmet kapasitesinin üzerindeki istekler reddedilir. İsteği yeniden denemeden önce belirli bir süre beklemeniz gerektiğini belirtmek için retry-after başlıklara sahip 429 hata yanıtları döndürülebilir.
İstemci Tarafında Kısıtlama : İstemciler istek başarısızlıklarını, yüksek gecikmeyi veya 429 hatalarını gözlemlediğinde, tıkanıklığın daha da kötüleşmesini önlemek için çıkış akışını gönüllü olarak sınırlamalıdır.
Üstel geri çekilme : Hataları yeniden denerken, üstel olarak artan zaman gecikmeleri ekleyin. Örneğin: 1'ler, 2'ler, 4'ler, 8'ler, 16'lar, 32'ler.
Titreşim : İsteklerin belirli aralıklarla yeniden denenmesinden kaçınmak. Titreşimle, yeniden deneme gecikmelerini zamana eşit bir şekilde dağıtmak için rastgele bir süreç aracılığıyla değiştirirsiniz (örneğin: 0,9s, 2,3s, 4,1s, 8,5s, 17,9s, 34,7s).
Yeniden deneme amplifikasyonu : Başarısız istekler, üstel gerileme/titreşim olmadan yeniden denendiğinde, genellikle birikir ve devam eden trafik yüküne eklenir, potansiyel olarak trafik sıkışıklığı sorunlarını "yükseltir" ve daha da kötüleştirir.
Sorun: trafikte ani artışlar
FCM, saniyede milyonlarca isteği (RPS) işler. Sistemik tıkanıklığa, gecikme sorunlarına ve kesintilere en büyük katkıyı trafik artışları sağlıyor.
Ani trafik nedir?
Trafik ani artışlarının birkaç farklı türü vardır.
Saat içi ani artışlar: FCM, her saatin ilk 30 saniyesi ile 2 dakikası arasında iki kattan fazla trafik alır. Daha az da olsa benzer şekilde yarım saat ve çeyrek saatlerde de artışlar görülüyor (örnekler: 00:15, 00:30, 00:45)
Yeniden deneme amplifikasyonu : Üstel geri çekilme olmadan başarısız veya zaman aşımına uğramış isteklerin yeniden denenmesi, mevcut trafik tepelerinin üzerinde tekrarlanan trafik dalgaları şeklinde birikebilir.
Ani trafik düzeni değişiklikleri: Kademeli artış gibi yumuşatıcı faktörler olmadan yeni trafiği FCM'ye yönlendirmek veya trafiği bölgeler arasında FCM'ye taşımak ani artışlara neden olabilir.
Önden yüklemeli kota belirteci kullanımı: İstekleri kota pencereleri arasında eşit bir şekilde dağıtmak yerine tüm kota belirteçlerinin kota pencerelerinin başlangıcında tükenmesi, yük dengelemesi zor ve pahalı olan açma-kapama salınımları yaratacaktır.
Özel etkinlikler: Tatiller (Yılbaşı Gecesi) veya spor etkinlikleri ( FIFA Dünya Kupası ) sırasında trafikte artışlar olur.
Trafik artışlarını "eğriyi düzleştirerek" giderin
Bu bölümde mümkün olan yerlerde trafik artışlarını yumuşatmaya yönelik stratejiler, yani "eğriyi düzleştirmeye" yönelik stratejiler açıklanmaktadır.
FCM'yi yalnızca uygun kullanım durumları için kullanın
Bildirim göndermek için FCM kullanmanın gerekli veya uygun olmadığı bazı kullanım durumları vardır.
Örneğin, takvim etkinliği bildirimleri için, bir bildirimi uygulama sunucunuzdan göndermek yerine, uygun zamanlarda görüntüleyecek şekilde uygulamanızda yerel bir görev zamanlayabilirsiniz. FCM mesajlarını takvim senkronizasyonlarıyla sınırlandırın.
Ani artışlardan kaçının
Ölçeklendirme anti-modellerinden biri, sunucu tarafı kısıtlama uygulamak yerine FCM bildirimlerini sistemlerin izin verdiği kadar hızlı göndermektir. Aşağıdakileri göz önünde bulundur:
- Tüm müşterilerinizin 1 dakikalık bir süre içinde aynı bildirimi alması mı gerekiyor? Örneğin 5 dakikalık bir teslimat aralığı yine de iş ihtiyaçlarınızı karşılayabilir mi?
- Ani artışları gidermek için müşterileriniz önceliğe göre bölümlere ayrılabilir mi?
- Bildirimleriniz önceden planlanabilir mi?
Mümkün olan her yerde : FCM gönderme kotanızın hemen tükenmesine neden olacak stratejilerden kaçının; yalnızca jeton kovanız dolduğunda modeli tekrarlayın. Bu erişim düzeni, FCM ve ona bağlı sistemler için yük dengeleme sorunları yaratır. Trafiği mümkün olduğunca kademeli olarak artırın. En azından 60 saniyelik bir zaman aralığı boyunca 0'dan maksimum RPS'ye çıkın. Daha yüksek RPS için daha uzun pencereleri tercih edin.
"Saat içi" trafikten kaçının
Mümkün olduğunda :00, :15, :30 ve :45 dakika işaretlerinin her birinin 2 dakikalık aralığı içinde mesaj göndermekten kaçının.
Sunucu tarafı azaltmayı uygulayın
FCM'ye giden trafik akışını izlemek ve yönetmek için sunucu tarafı kısıtlamayı uygulayın.
Yeniden denemeleri işleme
FCM yüksek oranda erişilebilir olmaya çalışsa da zaman zaman bazı istekler zaman aşımına uğrayabilir veya başarısız olabilir. Sebepler farklılık gösterse de, aşağıdaki en iyi uygulamalar, trafik sıkışıklığının etkisini en aza indirirken mesajları mümkün olan en kısa sürede iletmek için yeniden deneme davranışını optimize eder.
Zaman aşımları
Yeniden denemeden önce gönderme isteklerine en az 10 saniyelik bir zaman aşımı süresi 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: iptal edin ve yeniden denemeyin.
- 429 hataları için: retry-after başlığında ayarlanan süreyi bekledikten sonra yeniden deneyin. Yeniden deneme başlığı ayarlanmadıysa varsayılan süre 60 saniyedir.
- 500 hata için: üstel geri çekilmeyle yeniden deneyin.
Üstel geri çekilme
Yeniden deneme amplifikasyonunu önlemek amacıyla, yeniden deneme istekleri için titreşimli üstel gerileme uygulayın. Örneğin Firebase Yönetici SDK'sı üstel geri çekilme uygular.
İşte önerilen bazı ayarlar:
- 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 olmayan isteklerin bırakılması için maksimum bir aralık ayarlayın.
Bir istek sürekli olarak üstel geri çekilmeyle yeniden deneniyorsa ve 60 dakika sonra hâlâ başarısız oluyorsa, bu ya yeniden denenebilir bir hata olarak yanlış sınıflandırılır ya da FCM, yeniden denemelerin yanlışlıkla durumu kötüleştirebileceği bir kesinti yaşıyor demektir.
Kullanıma sunma ve geri alma planları oluşturun ve kademeli değişiklikler yapın
FCM'ye gelen trafiği artırmak veya trafiği bölgeler veya ağlar arasında 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şiklikleri uygulamak kullanıcılarınızı, hizmetinizi ve FCM'yi koruyacaktır.
- Bir kullanıma sunma planı paydaşların beklentilerini uyumlu hale getirir. Belirli durumlarda (aşağıda ele alınmıştır), sürprizlerden kaçınmak için kullanıma sunma planınızı FCM ekibiyle önceden paylaşmak isteyebilirsiniz.
- Geri alma planı, beklenmedik arızaları 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ş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 ince olmalıdır. 1 günden 1 haftaya kadar her adımı " Islatma " (sistemin yük altındaki davranışını gözlemleyin). Bu, bir sonraki "adım adım" öncesinde potansiyel sorunları tespit etmenize olanak tanır
- Kademeli trafik artışları: Trafiği artırmak için her "adım" atılırken, trafiği en az bir saat boyunca yumuşatın. Bu, FCM'nin yük dengeleme altyapısının, sıcak nokta ve tıkanıklık potansiyelini en aza indirirken yeni trafiğinizi uygun şekilde ölçeklendirmesine olanak tanır.
Aşağıda, küresel olarak 500.000 RPS'nin FCM Eski HTTP API'sinden FCM HTTP v1 API'sine taşınmasına yönelik varsayımsal bir senaryo verilmiştir:
| Hafta | Adım | Kademeli Artış Stratejisi |
|---|---|---|
| 0 | %1 artış | Bir saat içinde 0'dan 5.000 RPS'ye, FCM HTTP v1'e sorunsuz bir şekilde çıkın. |
| 1 | %5 artış | 2 saat içinde 5.000'den 25.000 RPS'ye sorunsuz bir şekilde çıkın. |
| 2 | %10 artış | 2 saatte 25.000 RPS'den 50.000 RPS'ye sorunsuz bir şekilde çıkın |
| 3 | %25 artış | 3 saatte 50.000'den 125.000 RPS'ye artış |
| 4 | %50 artış | 6 saatte 125.000'den 250.000 RPS'ye artış |
| 5 | %75 artış | 6 saatte 250.000 RPS'den 375.000 RPS'ye artış |
| 6 | %100 artış | 6 saatte 375.000'den 500.000 RPS'ye artış |
Varsayımsal geri alma planı:
- Yüzde 95'lik gecikme süresi 500 ms'nin üzerine çıkarsa veya herhangi bir adımda hata oranı bir saatten fazla süreyle %1'i aşarsa hemen önceki adıma geri dönmek için dinamik yapılandırmayı kullanın.
- Gecikme ve hata oranı nominal 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 Desteği aracılığıyla FCM ile iletişime geçin:
- Varsayılan kotalar artık kullanım durumunuzu karşılamıyor
- Gönderme düzenlerinizi 3 aylık bir pencere içinde dünya çapında 100.000 RPS veya kıtasal olarak 30.000 RPS ölçeğinde değiştiriyorsunuz.