Yeni bir uygulamayı büyütüyor veya zaten yüksek trafik alan bir hizmet sunuyor olsanız da FCM ile sorunsuz şekilde ölçeklendirme yapmayla ilgili bu kılavuzun analizlerinden ve önerilerinden yararlanabilirsiniz. Bu kavramlar ve uygulamalar, çok sayıda ileti göndermeniz gerektiğinde olumsuz etkileri önlemenize yardımcı olabilir.
Temel terimler ve kavramlar
Mesaj İsteği: "İstek", "mesaj" veya "sorgu" ile birlikte kullanılan bir FCM mesaj isteği.
Saniyedeki istek sayısı (RPS): FCM'ye gelen isteklerin hızını tanımlayan bir metriktir. Saniyedeki sorgu sayısı (QPS) ile birbirinin yerine kullanılabilir.
Kota jetonları, jeton paketleri ve yeniden doldurma işlemleri: FCM HTTP v1 API'ye karşı mesaj gönderirken her istek, belirli bir zaman aralığında ayrılmış bir kota jetonu tüketir. "Jeton Havuzu" olarak adlandırılan bu pencere, zaman aralığının sonunda tam olarak yeniden doldurulur. Örneğin: HTTP v1 API, her 1 dakikalık jeton paketi için 600.000 kota jetonu ayırır. Bu jetonlar, her 1 dakikalık aralığın sonunda tam olarak doldurulur.
Sunucu tarafı akış kontrolü: Trafik hacmi FCM hizmetinin kapasitesini aştığında, yayın kapasitesinin üzerindeki istekler giriş akışını hız sınırına tabi tutmak için 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ında akış sınırlaması: İstemciler istek hatası, yüksek gecikme veya 429 hataları gözlemlediğinde, tıkanıklığın artmasını önlemek için çıkış akışını gönüllü olarak hız sınırlamalıdır.
Eksponansiyel geri yükleme: Hataları yeniden denediğinizde katlanarak artan zaman gecikmeleri ekleyin. Örneğin: 1 sn, 2 sn, 4 sn, 8 sn, 16 sn, 32 sn.
Düzensiz aralıklarla tekrarlama: İstekleri tam aralıklarla tekrarlamaktan kaçınma. Jitter ile, yeniden deneme gecikmelerini zaman içinde eşit olarak dağıtmak için rastgele bir işlemle değiştirirsiniz (örneğin: 0,9 sn, 2,3 sn, 4,1 sn, 8,5 sn, 17,9 sn, 34,7 sn).
Tekrar denemeyle ilgili artış: Başarısız istekler, üstel geri yükleme/jitter olmadan tekrar denediğinde genellikle birikir ve devam eden trafik yüküne eklenir. Bu da trafik sıkışıklığı sorunlarını "artırabilir" ve kötüleştirebilir.
Sorun: Trafikte ani artışlar
FCM, saniyede milyonlarca istek (RPS) işler. Sistemsel tıkanıklığa, gecikme sorunlarına ve kesintilere en çok katkıda bulunan faktör trafik ani artışlarıdır.
Ani artış gösteren trafik nedir?
Trafikte ani artışların birkaç farklı türü vardır.
Saatlik artışlar: FCM, her saatin ilk 30 saniyesinden 2 dakikasına kadar iki kattan fazla trafik alır. Yarım saat ve çeyrek saat işaretlerinde de benzer ancak daha düşük artışlar gözlemlenir (örnek: 00:15, 00:30, 00:45).
Tekrar denemeyle güçlendirme: Başarısız veya zaman aşımına uğrayan istekleri üssel geri çekilme olmadan yeniden denemek, mevcut trafik zirvelerinin üzerine tekrarlanan trafik dalgaları halinde birikebilir.
Ani trafik kalıbı değişiklikleri: Yeni trafiği FCM'ye yönlendirmek veya trafiği kademeli artış gibi yumuşatma faktörleri olmadan bölgeler arasında FCM'ye taşımak ani artışlara neden olabilir.
Önden yükleme kota jetonu kullanımı: İstekleri kota aralıkları arasında eşit şekilde dağıtmak yerine kota zamanları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 (Yeni Yıl'ın son gecesi) veya spor etkinliklerinde (FIFA Dünya Kupası) trafikte ani artışlar
"Eğriyi düzleştirerek" trafik ani artışlarını giderme
Bu bölümde, mümkün olduğunda trafik artışlarını düzleştirmeye yönelik stratejiler (yani "eğriyi düzleştirme" stratejileri) açıklanmaktadır.
FCM öğesini yalnızca uygun kullanım alanları için 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 uygulama sunucunuzdan göndermek yerine bildirimi uygun zamanlarda görüntülemek üzere uygulamanızda yerel bir görev 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 1 dakika içinde aynı bildirimi alması gerekiyor mu? Örneğin, 5 dakikalık bir teslimat aralığı işletmenizin ihtiyaçlarını karşılamaya devam eder mi?
- Müşterileriniz, ani artışları 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ın hemen tükenmesine neden olan stratejilerden kaçının. Jeton paketiniz dolduğunda kalıbı tekrar edin. Bu erişim modeli, FCM ve bağımlı sistemleri için yük dengeleme sorunları 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 kadar rampa yapın. Daha yüksek PBM için daha uzun aralıkları tercih edin.
"Saatlik" trafikten kaçının
Mümkün olduğunda: :00, :15, :30 ve :45 dakika işaretlerinin her birinin 2 dakikalık zaman aralığında mesaj göndermekten kaçının.
Sunucu tarafı kısıtlama uygulama
FCM'ye gelen trafik akışını izlemek ve yönetmek için sunucu tarafı akış denetimi 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 iletileri en kısa sürede yayınlamak için yeniden deneme davranışını optimize eder.
Engelleme
Tekrar denemeden önce istek gönderme işlemi için en az 10 saniyelik bir zaman aşımı ayarlayın. FCM'nin dahili uzak 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 başlığında ayarlanan süreyi bekledikten sonra yeniden deneyin. Yeniden deneme sonrası üstbilgisi ayarlanmamışsa varsayılan olarak 60 saniyedir.
- 500 hataları için: Eksponansiyel geri yüklemeyle yeniden 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'sı eksponansiyel geri yükleme uygular.
Önerilen diğer ayarlar:
- Minimum Aralık: Başarısız bir isteği FCM ile hemen tekrar 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, üstel geri yüklemeyle sürekli olarak yeniden deneniyor ve 60 dakika sonra hâlâ başarısız oluyorsa bu istek, yeniden denemeye uygun bir hata olarak yanlış sınıflandırılmış veya FCM'de, yeniden denemelerin durumu yanlışlıkla kötüleştirebileceği bir kesinti yaşanıyor demektir.
Kullanıma sunma ve geri alma planları oluşturma ve kademeli değişiklikler yapma
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.
- Lansman planı, paydaşların beklentilerini uyumlu hale getirir. Belirli durumlarda (aşağıda ele alınmış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 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ı 1 gün ila 1 hafta boyunca "soğutarak" (yük altında sistem davranışını gözlemleyerek) çalıştırın. 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 sayede FCM'nin yük dengeleme altyapısı, yoğunluk ve tıkanıklık olasılığını en aza indirirken yeni trafiğinizi uygun şekilde ölçeklendirebilir.
Dünya genelinde 500.000 RPS'nin FCM eski HTTP API'sinden FCM HTTP v1 API'ye taşınmasına ilişkin varsayımsal bir senaryo aşağıda verilmiştir:
| Hafta | Step | Kademeli Artış Stratejisi |
|---|---|---|
| 0 | %1 artış | Bir saat içinde FCM HTTP v1 için 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'e kadar RPS'yi sorunsuz bir şekilde artırın. |
| 2 | %10 artış | 2 saatte 25.000'den 50.000 RPS'ye sorunsuz şekilde artış |
| 3 | %25 artış | 3 saat içinde 50.000'den 125.000 RPS'ye artış |
| 4 | %50 artış | 6 saat içinde 125.000'den 250.000 RPS'ye artış |
| 5 | %75 artış | 6 saat içinde 250.000'den 375.000'e RPS'de artış |
| 6 | %100 artış | 6 saat içinde 375.000'den 500.000 RPS'ye artış |
Varsayımsal geri alma planı:
- 95. yüzdelik dilimdeki gecikme 500 ms'den fazla artarsa veya herhangi bir adımda hata oranı bir saatten uzun süre boyunca %1'i aşarsa dinamik yapılandırmayı kullanarak hemen önceki adıma geri dönü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 Destek Ekibi aracılığıyla FCM ile iletişime geçin:
- Varsayılan kotalar artık kullanım alanınızı karşılamıyor
- Gönderim kalıplarınızı 3 aylık bir süre içinde dünya genelinde 100.000 RPS veya kıta bazında 30.000 RPS ölçeğinde değiştiriyorsunuz.