แนวทางปฏิบัติแนะนำเมื่อส่งข้อความ FCM จำนวนมาก

ไม่ว่าคุณจะพัฒนาแอปที่เพิ่งเริ่มต้นหรือให้บริการที่มีการเข้าชมสูงอยู่แล้ว คุณก็จะได้รับประโยชน์จากข้อมูลเชิงลึกและคําแนะนําเกี่ยวกับวิธีปรับขนาดอย่างราบรื่นด้วย FCM จากคู่มือนี้ แนวคิดและแนวทางปฏิบัติเหล่านี้จะช่วยหลีกเลี่ยงผลกระทบเชิงลบเมื่อคุณต้องส่งข้อความจำนวนมาก

คําศัพท์และแนวคิดสําคัญ

คําขอข้อความ: คําขอข้อความ FCM ใช้แทนกันได้กับ "คําขอ" "ข้อความ" หรือ "การค้นหา"

คำขอต่อวินาที (RPS): เมตริกที่อธิบายอัตราการส่งคำขอไปยัง FCM ซึ่งใช้แทนกันได้กับคำค้นหาต่อวินาที (QPS)

โทเค็นโควต้าที่เก็บโทเค็น และการเติมโทเค็น: เมื่อส่งข้อความไปยัง FCM HTTP v1 API คําขอแต่ละรายการจะใช้โทเค็นโควต้าที่ได้รับตามที่กำหนดไว้ในช่วงเวลาหนึ่งๆ กรอบเวลานี้เรียกว่า "Token Bucket" จะเติมเต็มจนเต็มเมื่อสิ้นสุดกรอบเวลา ตัวอย่างเช่น HTTP v1 API จะจัดสรรโทเค็นโควต้า 600, 000 รายการสำหรับแต่ละที่เก็บโทเค็น 1 นาที ซึ่งจะเติมเต็มใหม่จนเต็มเมื่อสิ้นสุดกรอบเวลา 1 นาทีแต่ละครั้ง

การจำกัดฝั่งเซิร์ฟเวอร์: เมื่อปริมาณการเข้าชมเกินความจุของบริการ FCM ระบบจะปฏิเสธคำขอที่เกินขีดจำกัดของการแสดงเพื่อจำกัดอัตราการเข้าชม ระบบอาจแสดงการตอบกลับข้อผิดพลาด 429 พร้อมส่วนหัว retry-after เพื่อระบุว่าคุณควรรอตามระยะเวลาที่กำหนดก่อนที่จะส่งคำขออีกครั้ง

การจำกัดฝั่งไคลเอ็นต์: เมื่อไคลเอ็นต์สังเกตเห็นว่าคำขอไม่สำเร็จ เวลาในการตอบสนองสูง หรือมีข้อผิดพลาด 429 ก็ควรจำกัดอัตราการส่งออกเพื่อหลีกเลี่ยงการทำให้การจราจรคับคั่งรุนแรงขึ้น

Exponential Backoff: เมื่อเกิดข้อผิดพลาดในการลองอีกครั้ง ให้เพิ่มเวลารอแบบทวีคูณ เช่น 1 วินาที, 2 วินาที, 4 วินาที, 8 วินาที, 16 วินาที, 32 วินาที และอื่นๆ

การกระโดด: หลีกเลี่ยงการลองส่งคำขออีกครั้งในช่วงเวลาที่แน่นอน เมื่อใช้การกระจัดกระจาย คุณจะทำให้ระยะเวลาในการลองอีกครั้งแตกต่างกันไปผ่านกระบวนการแบบสุ่มเพื่อกระจายระยะเวลาเหล่านั้นอย่างสม่ำเสมอเมื่อเวลาผ่านไป (เช่น 0.9 วินาที, 2.3 วินาที, 4.1 วินาที, 8.5 วินาที, 17.9 วินาที, 34.7 วินาที)

การขยายการส่งคำขออีกครั้ง: เมื่อมีการพยายามส่งคำขอที่ล้มเหลวอีกครั้งโดยไม่มี Exponential Backoff/การกระโดดแบบสุ่ม มักจะมีการสะสมและเพิ่มภาระการเข้าชมอย่างต่อเนื่อง ซึ่งอาจ "ขยาย" และทำให้ปัญหาการจราจรคับคั่งรุนแรงขึ้น

ปัญหา: การเข้าชมเพิ่มขึ้นอย่างฉับพลัน

FCM ประมวลผลคำขอหลายล้านรายการต่อวินาที (RPS) ปัจจัยที่ทำให้เกิดปัญหาความแออัดของระบบ ปัญหาเวลาในการตอบสนอง และการหยุดทำงานคือการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว

การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็วคืออะไร

การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็วมีหลายประเภท

การเพิ่มขึ้นในช่วงชั่วโมง: FCM ได้รับการเข้าชมมากกว่า 2 เท่าในช่วง 30 วินาทีแรกถึง 2 นาทีของทุกๆ ชั่วโมง นอกจากนี้ เรายังสังเกตเห็นการเพิ่มขึ้นที่คล้ายกันแต่น้อยกว่านี้เมื่อถึงครึ่งชั่วโมงและ 15 นาที (เช่น 00:15, 00:30, 00:45)

การขยายการลองอีกครั้ง: การลองส่งคำขอที่ไม่สำเร็จหรือหมดเวลาอีกครั้งโดยไม่การลดจำนวนคำขอแบบทวีคูณอาจทําให้จำนวนคำขอเพิ่มขึ้นเป็นระลอกซ้ำๆ นอกเหนือจากจำนวนคำขอสูงสุดที่มีอยู่

รูปแบบการเข้าชมเปลี่ยนแปลงอย่างฉับพลัน: การเปลี่ยนเส้นทางการเข้าชมใหม่ไปยัง FCM หรือย้ายการเข้าชมไปยัง FCM ทั่วภูมิภาคโดยไม่คำนึงถึงปัจจัยต่างๆ เช่น การเพิ่มจำนวนอย่างค่อยเป็นค่อยไป อาจทําให้การเข้าชมเพิ่มขึ้นอย่างรวดเร็ว

การใช้โทเค็นโควต้าในช่วงต้น: การใช้โทเค็นโควต้าทั้งหมดในช่วงเริ่มต้นของกรอบเวลาโควต้าแทนที่จะกระจายคำขออย่างสม่ำเสมอในกรอบเวลาโควต้าจะทำให้เกิดความสั่นไหวแบบเปิด/ปิดซึ่งทำให้โหลดบาลานซ์ได้ยากและค่าใช้จ่ายสูง

กิจกรรมพิเศษ: การเข้าชมเพิ่มขึ้นในช่วงวันหยุด (วันส่งท้ายปีเก่า) หรือการแข่งขันกีฬา (ฟุตบอลโลก)

แก้ไขปัญหาการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็วด้วย "การทำให้เส้นโค้งแบนลง"

ส่วนนี้จะอธิบายกลยุทธ์ในการปรับการเข้าชมที่เพิ่มขึ้นอย่างฉับพลันให้ราบรื่นขึ้นหากเป็นไปได้ ซึ่งเป็นกลยุทธ์ในการ "ปรับเส้นโค้งให้เรียบ"

ใช้ FCM เฉพาะกับกรณีการใช้งานที่เหมาะสมเท่านั้น

มีบาง Use Case ที่ไม่จําเป็นหรือเหมาะสมที่จะใช้ FCM เพื่อส่งการแจ้งเตือน

ตัวอย่างเช่น สำหรับการแจ้งเตือนกิจกรรมในปฏิทิน คุณสามารถกำหนดเวลา��านในเครื่องในแอปให้แสดงการแจ้งเตือนในเวลาที่เหมาะสมแทนการส่งการแจ้งเตือนจากเซิร์ฟเวอร์แอป จำกัดข้อความ FCM ไว้สำหรับการซิงค์ปฏิทิน

หลีกเลี่ยงการเพิ่มขึ้นอย่างรวดเร็ว

รูปแบบการขยายขนาดที่ไม่เหมาะสมอย่างหนึ่งคือการส่งการแจ้งเตือน FCM อย่างรวดเร็วที่สุดเท่าที่ระบบจะอนุญาต แทนที่จะใช้การจำกัดฝั่งเซิร์ฟเวอร์ ลองพิจารณาสิ่งต่อไปนี้

• ลูกค้าทุกคนต้องได้รับการแจ้งเตือนเดียวกันภายในกรอบเวลา 1 นาทีไหม ตัวอย่างเช่น กรอบเวลาการนำส่ง 5 นาทีจะยังคงตรงกับความต้องการของธุรกิจไหม
• ลูกค้าสามารถแบ่งกลุ่มตามลําดับความสําคัญเพื่อลดความผันผวนได้ไหม
• ฉันตั้งเวลาการแจ้งเตือนล่วงหน้าได้ไหม

เมื่อเป็นไปได้: หลีกเลี่ยงกลยุทธ์ที่ส่งผลให้โควต้าการส่ง 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 แบบสุ่มเพื่อลองส่งคำขออีกครั้ง ตัวอย่างเช่น Firebase Admin SDK ใช้การถดถอยแบบทวีคูณ

การตั้งค่าที่แนะนําเพิ่มเติมมีดังนี้

• ช่วงเวลาขั้นต่ำ: อย่าส่งคำขอที่ดำเนินการไม่สำเร็จด้วย FCM อีกครั้งทันที โปรดรออย่างน้อย 10 วินาทีก่อนที่จะส่งคำขอที่ล้มเหลวอีกครั้ง
• ช่วงเวลาสูงสุด: กำหนดช่วงเวลาสูงสุดสำหรับการยกเลิกคำขอที่ไม่ทันเวลาแล้ว แทนที่จะลองใหม่อย่างไม่จำกัด

หากระบบพยายามส่งคําขอซ้ำอย่างต่อเนื่องโดยใช้ Exponential Backoff แต่ยังคงไม่สําเร็จหลังจากผ่านไป 60 นาที แสดงว่าระบบจัดหมวดหมู่ข้อผิดพลาดไม่ถูกต้องว่าเป็นข้อผิดพลาดที่ลองใหม่ได้ หรือ FCM หยุดทํางานอยู่ ซึ่งการลองใหม่อาจทําให้สถานการณ์แย่ลงโดยไม่ตั้งใจ

สร้างแผนการเปิดตัวและการเลิกใช้งาน รวมถึงทําการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป

เมื่อทำการเปลี่ยนแปลงการเข้าชมขนาดใหญ่ เช่น เพิ่มการเข้าชม FCM หรือย้ายการเข้าชมไปยังภูมิภาคหรือเครือข่ายต่างๆ การออกแบบแผนการเปิดตัว/การเลิกใช้งาน และการใช้การเปลี่ยนแปลงแบบค่อยเป็นค่อยไปจะช่วยปกป้องผู้ใช้ บริการ และ FCM

• แผนการเปิดตัวช่วยให้ผู้มีส่วนเกี่ยวข้องมีมุมมองที่ตรงกัน ในบางสถานการณ์ (ตามที่อธิบายไว้ด้านล่าง) คุณอาจต้องแชร์แผนการเปิดตัวกับทีม FCM ล่วงหน้าเพื่อไม่ให้เกิดความประหลาดใจ
• แผนการย้อนกลับช่วยให้คุณพิจารณาถึงเหตุการณ์ที่ไม่คาดคิดและเตรียมกลไกในการกู้คืนจากความล้มเหลวที่ไม่คาดคิดได้อย่างรวดเร็วและปลอดภัย
• การเปลี่ยนแปลงแบบค่อยเป็นค่อยไปมี 2 ด้าน ดังนี้
  • การเพิ่ม "แบบขั้น": ขั้นตอนควรเป็น 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% หรือละเอียดยิ่งขึ้น "ทดสอบการทํางานอย่างต่อเนื่อง" (สังเกตลักษณะการทํางานของระบบภายใต้ภาระงาน) แต่ละขั้นตอนเป็นเวลา 1 วันถึง 1 สัปดาห์ วิธีนี้ช่วยให้คุณพบปัญหาที่อาจเกิดขึ้นได้ก่อนที่จะ "เลื่อนขั้น" ไปอีกขั้น
  • เพิ่มจำนวนการเข้��ชมอย่างค่อยเป็นค่อยไป: เมื่อทำตาม "ขั้นตอน" แต่ละขั้นตอนเพื่อเพิ่มจำนวนการเข้าชม ให้เพิ่มจำนวนการเข้าชมอย่างราบรื่นในช่วงระยะเวลาอย่างน้อย 1 ชั่วโมง วิธีนี้ช่วยให้โครงสร้างพื้นฐานการกระจายภาระของ FCM สามารถปรับขนาดการเข้าชมใหม่ได้อย่างเหมาะสม ขณะเดียวกันก็ลดโอกาสที่อาจเกิดฮอตสปอตและการจราจรคับคั่ง

ต่อไปนี้เป็นสถานการณ์สมมติสำหรับการย้ายข้อมูล RPS 500,000 ครั้งทั่วโลกจาก FCM Legacy HTTP API ไปยัง FCM HTTP v1 API

สัปดาห์	Step	กลยุทธ์การเพิ่มจำนวนอย่างค่อยเป็นค่อยไป
0	การเพิ่มจำนวน 1%	เพิ่มจำนวนคำขอต่อวินาทีจาก 0 เป็น 5,000 RPS ไปยัง FCM HTTP v1 ได้อย่างราบรื่นภายใน 1 ชั่วโมง
1	การเพิ่มจำนวน 5%	เพิ่มจำนวนคำขอต่อวินาทีจาก 5,000 เป็น 25,000 RPS ได้อย่างราบรื่นภายใน 2 ชั่วโมง
2	การเพิ่มจำนวน 10%	เพิ่ม RPS จาก 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 ระดับทวีป