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