ไม่ว่าคุณจะกำลังพัฒนาแอปที่เพิ่งเริ่มต้นหรือให้บริการที่มีการเข้าชมสูงอยู่แล้วก็ตาม คุณจะได้รับประโยชน์จากข้อมูลเชิงลึกและคำแนะนำในคู่มือนี้เกี่ยวกับวิธีปรับขนาดบริการอย่างราบรื่นด้วย FCM แนวคิดและแนวทางปฏิบัติเหล่านี้จะช่วยคุณหลีกเลี่ยงผลกระทบด้านลบเมื่อคุณต้องส่งข้อความจำนวนมาก
คำและแนวคิดที่สำคัญ
คำขอข้อความ: คำขอข้อความ FCM ซึ่งใช้แทนกันได้กับ "คำขอ" "ข้อความ" หรือ "คำค้นหา"
คำขอต่อวินาที (RPS): เมตริกที่อธิบายอัตราคำขอขาเข้าไปยัง FCM ซึ่งใช้แทนกันได้กับคำค้นหาต่อวินาที (QPS)
โทเค็นโควต้า, บัคเก็ตโทเค็น และการเติม: เมื่อส่งข้อความเทียบกับ FCM HTTP v1 API คำขอแต่ละรายการจะใช้ โทเค็นโควต้า ที่จัดสรรไว้ในช่วงเวลา ที่กำหนด ช่วงเวลานี้เรียกว่า "บัคเก็ตโทเค็น" ซึ่งจะ เติม จนเต็มเมื่อสิ้นสุด ช่วงเวลา ตัวอย่างเช่น HTTP v1 API จัดสรรโทเค็นโควต้า 6 แสนรายการสำหรับบัคเก็ตโทเค็นแต่ละรายการที่มีระยะเวลา 1 นาที ซึ่งจะเติมจนเต็มเมื่อสิ้นสุดช่วงเวลา 1 นาทีแต่ละช่วง
การจำกัดอัตราคำขอจากฝั่งเซิร์ฟเวอร์: เมื่อปริมาณการรับส่งข้อมูลเกินความจุของบริการ FCM ระบบจะปฏิเสธคำขอที่เกินความจุในการให้บริการเพื่อจำกัดอัตราการไหลเข้า ระบบอาจแสดงการตอบกลับข้อผิดพลาด 429 พร้อมส่วนหัว retry-after เพื่อระบุว่าคุณควรรอระยะเวลาที่กำหนดก่อนที่จะลองส่งคำขออีกครั้ง
การจำกัดการส่งคำขอจากฝั่งไคลเอ็นต์: เมื่อไคลเอ็นต์พบข้อผิดพลาดของคำขอ เวลาในการตอบสนองสูง
หรือข้อผิดพลาด 429 ไคลเอ็นต์ควรจำกัดอัตราการไหลออกโดยสมัครใจเพื่อหลีกเลี่ยงไม่ให้เกิด
ความแออัดมากขึ้น
Exponential Backoff: เมื่อลองส่งคำขอที่เกิดข้อผิดพลาดอีกครั้ง ให้เพิ่มการหน่วงเวลาแบบทวีคูณ เช่น 1 วินาที, 2 วินาที, 4 วินาที, 8 วินาที, 16 วินาที, 32 วินาที และอื่นๆ
Jittering: หลีกเลี่ยงการลองส่งคำขออีกครั้งในช่วงเวลาที่แน่นอน การใช้ Jittering จะทำให้คุณเปลี่ยนการหน่วงเวลาในการลองอีกครั้งผ่านกระบวนการแบบสุ่มเพื่อกระจายการหน่วงเวลาอย่างสม่ำเสมอเมื่อเวลาผ่านไป (เช่น 0.9 วินาที, 2.3 วินาที, 4.1 วินาที, 8.5 วินาที, 17.9 วินาที, 34.7 วินาที)
การขยายการลองอีกครั้ง: เมื่อลองส่งคำขอที่ล้มเหลวอีกครั้งโดยไม่มี Exponential Backoff/Jittering คำขอเหล่านั้นมักจะสะสมและเพิ่มภาระการรับส่งข้อมูลที่กำลังเกิดขึ้น ซึ่งอาจ "ขยาย" และทำให้ปัญหาการรับส่งข้อมูลติดขัดมากขึ้น
ปัญหา: การเข้าชมเพิ่มขึ้นอย่างรวดเร็ว
FCM ประมวลผลคำขอหลายล้านรายการต่อวินาที (RPS) สาเหตุหลักที่ทำให้เกิดความแออัดของระบบ ปัญหาเวลาในการตอบสนอง และการหยุดทำงานคือการรับส่งข้อมูลเพิ่มขึ้นอย่างรวดเร็ว
การเข้าชมเพิ่มขึ้นอย่างรวดเร็วคืออะไร
การเข้าชมเพิ่มขึ้นอย่างรวดเร็วมีหลายประเภท
การเข้าชมเพิ่มขึ้นอย่างรวดเร็วเมื่อขึ้นชั่วโมงใหม่: FCM ได้รับการเข้าชมมากกว่า 2 เท่าในช่วง 30 วินาทีถึง 2 นาทีแรกของแต่ละชั่วโมง นอกจากนี้ยังพบการเข้าชมเพิ่มขึ้นอย่างรวดเร็วในลักษณะที่คล้ายกันแต่มีปริมาณน้อยกว่าเมื่อเวลาผ่านไปครึ่งชั่วโมงและ 15 นาที (เช่น 00:15, 00:30, 00:45)
การขยายการลองอีกครั้ง: การลองส่งคำขอที่ล้มเหลวหรือหมดเวลาอีกครั้งโดยไม่มี Exponential Backoff อาจ สะสมเป็นคลื่นการเข้าชมซ้ำๆ ที่เพิ่มขึ้นจากยอดการเข้าชมที่มีอยู่
การเปลี่ยนแปลงรูปแบบการเข้าชมอย่างกะทันหัน: การนำการเข้าชมใหม่ไปยัง FCM หรือการย้ายการเข้าชมไปยัง FCM ในภูมิภาคต่างๆ โดยไม่มีปัจจัยที่ช่วยให้การเปลี่ยนแปลงราบรื่น เช่น การเพิ่มจำนวนการเข้าชมอย่างค่อยเป็นค่อยไป อาจทำให้เกิดการเข้าชมเพิ่มขึ้นอย่างรวดเร็ว
การใช้โทเค็นโควต้าล่วงหน้า: การใช้โทเค็นโควต้าทั้งหมดจนหมดในช่วงเริ่มต้นของช่วงเวลาโควต้าแทนที่จะกระจายคำขออย่างสม่ำเสมอในช่วงเวลาโควต้าจะทำให้เกิดการแกว่งแบบเปิดและปิดซึ่งยากและมีค่าใช้จ่ายสูงในการจัดสรรภาระงาน
กิจกรรมพิเศษ: การเข้าชมเพิ่มขึ้นอย่างรวดเร็วในช่วงวันหยุด (วันขึ้นปีใหม่) หรือกิจกรรมกีฬา (ฟุตบอลโลก FIFA)
แก้ไขการเข้าชมเพิ่มขึ้นอย่างรวดเร็วด้วยการ "ลดการเพิ่มขึ้น"
ส่วนนี้อธิบายกลยุทธ์ในการลดการเข้าชมเพิ่มขึ้นอย่างรวดเร็วเมื่อเป็นไปได้ ซึ่งเป็นกลยุทธ์ในการ "ลดการเพิ่มขึ้น"
ใช้ FCM เฉพาะในกรณีการใช้งานที่เหมาะสม
มีบางกรณีการใช้งานที่ไม่จำเป็นหรือเหมาะสมที่จะใช้ FCM ในการส่งการแจ้งเตือน
ตัวอย่างเช่น สำหรับการแจ้งเตือนกิจกรรมในปฏิทิน คุณสามารถกำหนดเวลาให้แอปแสดงการแจ้งเตือนในเครื่องตามเวลาที่เหมาะสมแทนที่จะส่งจากเซิร์ฟเวอร์แอป จำกัดข้อความ FCM ให้เป็นการซิงค์ปฏิทิน
หลีกเลี่ยงการเข้าชมเพิ่มขึ้นอย่างรวดเร็ว
รูปแบบการปรับขนาดที่ไม่แนะนำคือการส่งการแจ้งเตือน FCM ให้เร็วที่สุดเท่าที่ระบบจะอนุญาตแทนที่จะใช้การจำกัดการส่งคำขอจากฝั่งเซิร์ฟเวอร์ โปรดพิจารณาสิ่งต่อไปนี้
- ลูกค้าทั้งหมดของคุณจำเป็นต้องได้รับการแจ้งเตือนเดียวกันภายในช่วงเวลา 1 นาทีหรือไม่ เช่น ช่วงเวลาการส่ง 5 นาทีจะยังคงตรงตามความต้องการทางธุรกิจของคุณหรือไม่
- คุณแบ่งกลุ่มลูกค้าตามลำดับความสำคัญเพื่อลดการเข้าชมเพิ่มขึ้นอย่างรวดเร็วได้หรือไม่
- คุณกำหนดเวลาการแจ้งเตือนล่วงหน้าได้หรือไม่
เมื่อเป็นไปได้: หลีกเลี่ยงกลยุทธ์ที่ทำให้โควต้าการส่ง FCM หมดลงทันที แล้วทำซ้ำรูปแบบเดิมทันทีที่ Bucket โทเค็นเติม รูปแบบการเข้าถึงนี้ทำให้เกิดปัญหาการจัดสรรภาระงานสำหรับ FCM และระบบที่ขึ้นอยู่กับ FCM เพิ่มจำนวนการเข้าชมอย่างค่อยเป็นค่อยไปมากที่สุดเท่าที่จะทำได้ อย่างน้อยที่สุด ให้เพิ่มจำนวนการเข้าชมจาก 0 เป็น RPS สูงสุดในช่วงเวลา 60 วินาที เลือกช่วงเวลาที่ยาวขึ้นสำหรับ RPS ที่สูงขึ้น
หลีกเลี่ยงการเข้าชม "เมื่อขึ้นชั่วโมงใหม่"
เมื่อเป็นไปได้: หลีกเลี่ยงการส่งข้อความภายในช่วงเวลา 2 นาทีของเวลา :00, :15, :30 และ :45 นาที
ใช้การจำกัดการส่งคำขอจากฝั่งเซิร์ฟเวอร์
ใช้การจำกัดการส่งคำขอจากฝั่งเซิร์ฟเวอร์เพื่อตรวจสอบและจัดการการไหลของการเข้าชมไปยัง FCM
การจัดการการลองอีกครั้ง
แม้ว่า FCM จะพยายามให้บริการที่มีความพร้อมใช้งานสูง แต่บางครั้งคำขออาจหมดเวลาหรือล้มเหลว แม้ว่าเหตุผลจะแตกต่างกันไป แต่แนวทางปฏิบัติแนะนำต่อไปนี้จะเพิ่มประสิทธิภาพลักษณะการทำงานของการลองอีกครั้งเพื่อส่งข้อความให้เร็วที่สุดเท่าที่จะทำได้ พร้อมทั้งลดผลกระทบต่อการรับส่งข้อมูลติดขัด
หมดเวลา
กำหนดเวลาหมดเวลาอย่างน้อย 10 วินาทีสำหรับคำขอส่งก่อนที่จะลองอีกครั้ง การเรียกกระบวนการระยะไกลภายในส่วนใหญ่ของ FCM ใช้เวลาหมดเวลา 10 วินาที
ข้อผิดพลาด
- สำหรับข้อผิดพลาด 400, 401, 403, 404: ยกเลิกและไม่ลองอีกครั้ง
- สำหรับข้อผิดพลาด 429: ลองอีกครั้งหลังจากรอระยะเวลาที่กำหนดไว้ในส่วนหัว retry-after หากไม่ได้ตั้งค่าส่วนหัว retry-after ให้ใช้ค่าเริ่มต้นเป็น 60 วินาที
- สำหรับข้อผิดพลาด 500: ลองอีกครั้งโดยใช้ Exponential Backoff
Exponential Backoff
หากต้องการหลีกเลี่ยงการขยายการลองอีกครั้ง ให้ใช้ Exponential Backoff พร้อม Jittering สำหรับการลองส่งคำขออีกครั้ง ตัวอย่างเช่น Firebase Admin SDK ใช้ Exponential Backoff
การตั้งค่าที่แนะนำเพิ่มเติมมีดังนี้
- ช่วงเวลาขั้นต่ำ: ไม่ลองส่งคำขอที่ล้มเหลวอีกครั้งทันทีด้วย FCM รออย่างน้อย 10 วินาทีก่อนที่จะลองส่งคำขอที่ล้มเหลวอีกครั้ง
- ช่วงเวลาสูงสุด: กำหนดช่วงเวลาสูงสุดสำหรับการยกเลิกคำขอที่ไม่ทันเวลาอีกต่อไปแทนที่จะลองอีกครั้งอย่างไม่มีกำหนด
หากระบบลองส่งคำขออีกครั้งอย่างต่อเนื่องโดยใช้ Exponential Backoff และคำขอยังคงล้มเหลวหลังจากผ่านไป 60 นาที แสดงว่าคำขอนั้นถูกจัดหมวดหมู่ผิดว่าเป็นข้อผิดพลาดที่ลองอีกครั้งได้ หรือ FCM กำลังหยุดทำงานซึ่งการลองอีกครั้งอาจทำให้สถานการณ์แย่ลงโดยไม่ตั้งใจ
สร้างแผนการเปิดตัวและแผนการย้อนกลับ รวมถึงทำการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป
เมื่อทำการเปลี่ยนแปลงการเข้าชมขนาดใหญ่ เช่น การเพิ่มการเข้าชมไปยัง FCM หรือการย้ายการเข้าชมระหว่างภูมิภาคหรือเครือข่าย การออกแบบแผนการเปิดตัว/ย้อนกลับและการทำการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไปจะช่วยปกป้องผู้ใช้ บริการ และ FCM
- แผนการเปิดตัวจะช่วยให้ผู้มีส่วนได้ส่วนเสียเข้าใจตรงกัน ในบางสถานการณ์ (กล่าวถึงด้านล่าง) คุณอาจต้องการแชร์แผนการเปิดตัวกับทีม FCM ล่วงหน้าเพื่อหลีกเลี่ยงปัญหาที่ไม่คาดคิด
- แผนการย้อนกลับช่วยให้คุณพิจารณาถึงเหตุการณ์ที่ไม่คาดคิดและเตรียมกลไกในการกู้คืนจากความล้มเหลวที่ไม่คาดคิดได้อย่างรวดเร็วและปลอดภัย
- การทำการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไปมี 2 ด้าน ได้แก่
- การเพิ่มจำนวนการเข้าชมแบบ "ทีละขั้น": ขั้นตอนควรเป็น 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% หรือละเอียดกว่านั้น "ทดสอบ" (สังเกตลักษณะการทำงานของระบบภายใต้ภาระงาน) แต่ละขั้นตอนเป็นเวลา 1 วันถึง 1 สัปดาห์ ซึ่งจะช่วยให้คุณพบปัญหาที่อาจเกิดขึ้นก่อนที่จะ "เพิ่ม" ขั้นตอนถัดไป
- การเพิ่มจำนวนการเข้าชมอย่างค่อยเป็นค่อยไป: เมื่อดำเนินการ "ทีละขั้น" เพื่อเพิ่มจำนวนการเข้าชม ให้กระจายการเข้าชมอย่างสม่ำเสมอในช่วงเวลาอย่างน้อย 1 ชั่วโมง ซึ่งจะช่วยให้โครงสร้างพื้นฐานการจัดสรรภาระงานของ FCM ปรับขนาดการรับส่งข้อมูลใหม่ได้อย่างเหมาะสม พร้อมทั้งลดโอกาสที่จะเกิดฮอตสปอตและความแออัด
ต่อไปนี้เป็นสถานการณ์สมมติสำหรับการย้ายข้อมูล 500,000 RPS ทั่วโลกจาก FCM Legacy HTTP API ไปยัง FCM HTTP v1 API
| สัปดาห์ | ขั้นตอน | กลยุทธ์การเพิ่มจำนวนการเข้าชมอย่างค่อยเป็นค่อยไป |
|---|---|---|
| 0 | การเพิ่มจำนวนการเข้าชม 1% | เพิ่มจำนวนการเข้าชมจาก 0 เป็น 5,000 RPS ไปยัง FCM HTTP v1 อย่างราบรื่นภายใน 1 ชั่วโมง |
| 1 | การเพิ่มจำนวนการเข้าชม 5% | เพิ่มจำนวนการเข้าชมจาก 5,000 เป็น 25,000 RPS อย่างราบรื่นภายใน 2 ชั่วโมง |
| 2 | การเพิ่มจำนวนการเข้าชม 10% | เพิ่มจำนวนการเข้าชมจาก 25,000 เป็น 50,000 RPS อย่างราบรื่นภายใน 2 ชั่วโมง |
| 3 | การเพิ่มจำนวนการเข้าชม 25% | เพิ่มจำนวนการเข้าชมจาก 50,000 เป็น 125,000 RPS ภายใน 3 ชั่วโมง |
| 4 | การเพิ่มจำนวนการเข้าชม 50% | เพิ่มจำนวนการเข้าชมจาก 125,000 เป็น 250,000 RPS ภายใน 6 ชั่วโมง |
| 5 | การเพิ่มจำนวนการเข้าชม 75% | เพิ่มจำนวนการเข้าชมจาก 250,000 เป็น 375,000 RPS ภายใน 6 ชั่วโมง |
| 6 | การเพิ่มจำนวนการเข้าชม 100% | เพิ่มจำนวนการเข้าชมจาก 375,000 เป็น 500,000 RPS ภายใน 6 ชั่วโมง |
แผนการย้อนกลับสมมติ
- หากเวลาในการตอบสนองเปอร์เซ็นไทล์ที่ 95 เพิ่มขึ้นเป็นมากกว่า 500 มิลลิวินาที หรือหากอัตราข้อผิดพลาดเกิน 1% เป็นเวลานานกว่า 1 ชั่วโมงในขั้นตอนใดก็ตาม ให้ใช้การกำหนดค่าแบบไดนามิกเพื่อย้อนกลับไปยังขั้นตอนก่อนหน้าทันที
- ดำเนินการย้อนกลับไปยังขั้นตอนก่อนหน้าต่อไปจนกว่าเวลาในการตอบสนองและอัตราข้อผิดพลาดจะกลับสู่ระดับปกติ
กรณีที่ควรติดต่อ FCM
ติดต่อ FCM ผ่าน ทีมสนับสนุน Firebase หากมีกรณีใดกรณีหนึ่งต่อไปนี้
- โควต้าเริ่มต้นไม่ตรงกับกรณีการใช้งานของคุณอีกต่อไป
- คุณกำลังเปลี่ยนรูปแบบการส่งภายในช่วงเวลา 3 เดือนในระดับ 100,000 RPS ทั่วโลกหรือ 30,000 RPS ในทวีป