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'sine 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 saniye, 2 saniye, 4 saniye, 8 saniye, 16 saniye, 32 saniye vb.
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 birkaç farklı şekilde gerçekleşebilir.
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.
Kota jetonu kullanımını öne yükleme: İstekleri kota aralıkları boyunca eşit olarak dağıtmak yerine kota aralığının başında tüm kota jetonlarını tüketmek, yük dengelemesi yapılması zor ve pahalı olan açma/kapatma dalgalanmaları oluşturur.
Ö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'ü 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 uygulama sunucunuzdan göndermek yerine bildirimi uygun zamanlarda görüntülemek üzere uygulamanızda yerel bir görev planlayabilirsiniz. FCM mesajlarını takvim senkronizasyonlarıyla sınırlayın.
Ani artışlardan kaçının
Ölçeklendirmeyle ilgili anti-patternlerden biri, sunucu tarafı throttling uygulamak yerine FCM bildirimlerini sistemlerin izin verdiği en hızlı şekilde 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 ve jeton havuzunuz yeniden doldurulduğunda aynı kalıbı tekrarlayan stratejilerden kaçının. 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ı tarama sınırlamasını 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 kullanılabilirlik için çaba gösterse de bazı isteklerin zaman aşımına uğraması veya başarısız olması mümkündür. 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.
Zaman aşımları
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 sayısının artmasını önlemek için, isteklerin yeniden denenmesi için jitter ile birlikte üstel geri yükleme 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 gelen trafiği artırmak veya trafiği bölgeler ya da ağlar arasında taşımak 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.
- Lansman planı, paydaşların beklentilerini uyumlu hale getirir. Belirli durumlarda (aşağıda açıklanmaktadır), sürprizlerle karşılaşmamak için kullanıma sunma planınızı FCM ekibiyle önceden paylaşmak isteyebilirsiniz.
- Geri alma planı, beklenmedik durumlara karşı hazırlıklı olmanızı ve beklenmedik hatalardan hızlı ve güvenli bir şekilde kurtulmak için mekanizmalar hazırlamanızı sağlar.
- 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 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 sayede, bir sonraki "seviye atlamadan" önce olası sorunları tespit edebilirsiniz.
- Trafiği kademeli olarak artırma: Trafiği artırmak için her "adımı" atarken trafiği en az bir saat boyunca kademeli olarak artırın. 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 | Yavaş yavaş 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 RPS'ye sorunsuz bir şekilde geçiş yapın. |
| 2 | %10 artış | 2 saat içinde 25.000 RPS'den 50.000 RPS'ye sorunsuz şekilde geçiş |
| 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 kademeli 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 seviyelere dönene kadar önceki adımlara geri dönmeye 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önderme 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.