ไม่ว่าคุณจะพัฒนาแอปที่เพิ่งเริ่มต้นหรือให้บริการที่มีการเข้าชมสูงอยู่แล้ว คุณก็จะได้รับประโยชน์จากข้อมูลเชิงลึกและคําแนะนําเกี่ยวกับวิธีปรับขนาดอย่างราบรื่นด้วย 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 คำขอดังกล่าวมักจะสะสมและเพิ่มปริมาณการรับส่งข้อมูลอย่างต่อเนื่อง ซึ่งอาจ "เพิ่มปริมาณขึ้น" และทำให้เกิดปัญหาการจราจรที่คับคั่งยิ่งขึ้น
ปัญหา: การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว
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 ใช้ Exponential Backoff
การตั้งค่าที่แนะนําเพิ่มเติมมีดังนี้
- ช่วงเวลาขั้นต่ำ: อย่าส่งคำขอที่ดำเนินการไม่สำเร็จด้วย 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 ระดับทวีป