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

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

คำสำคัญและแนวคิด

คำขอส่งข้อความ: คำขอส่งข้อความ FCM ซึ่งสามารถใช้แทนกันได้กับ "request", "message" หรือ "query"

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

โทเค็นโควต้า ที่เก็บข้อมูลโทเค็น และการเติมโทเค็น: เมื่อส่งข้อความให้กับ API ของ FCM HTTP v1 แต่ละคำขอจะใช้โทเค็นโควต้าที่จัดสรรในกรอบเวลาที่กำหนด หน้าต่างนี้เรียกว่า "ที่เก็บข้อมูลโทเค็น" ซึ่งจะเติมข้อมูลให้เต็มเมื่อสิ้นสุดกรอบเวลา ตัวอย่างเช่น 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.7s)

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

ปัญหา: การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว

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

แผนภูมิเส้นแสดงการเข้าชมที่พุ่งสูงขึ้นในช่วงเวลาไม่ปกติ

การจราจรที่ติดขัดคืออะไร

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

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

แผนภูมิเส้นแสดงแนวโน้มการเพิ่มขึ้นแบบครึ่งชั่วโมงและครึ่งชั่วโมง

ลองขยายเสียงอีกครั้ง: การลองส่งคำขอที่ล้มเหลวหรือหมดเวลาอีกครั้งโดยไม่มี Exponential Backoff อาจสะสมเป็นระลอกคลื่นการเข้าชมซ้ำๆ ทับยอดการเข้าชมที่มีอยู่

แผนภูมิเส้นแสดงรูปแบบการเพิ่มขึ้นอย่างฉับพลัน

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

แผนภูมิเส้นแสดงการเพิ่มขึ้นอย่างฉับพลัน 1 ครั้ง

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

แผนภูมิเส้นแสดงการเพิ่มขึ้นอย่างรวดเร็วมาก

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

แผนภูมิเส้นแสดงการเพิ่มขึ้นซ้ำๆ หลายครั้ง

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

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

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

ในบางกรณี การใช้ FCM เพื่อส่งการแจ้งเตือนนั้นไม่จำเป็นหรือเหมาะสม

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

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

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

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

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

หลีกเลี่ยงการจราจร "ในช่วงเวลา"

หากเป็นไปได้: ให้หลีกเลี่ยงการส่งข้อความภายในกรอบเวลา 2 นาทีนับจากเครื่องหมาย 00, 15, 30 และ 45 นาทีแต่ละรายการ

ใช้การควบคุมฝั่งเซิร์ฟเวอร์

ใช้การควบคุมฝั่งเซิร์ฟเวอร์เพื่อตรวจสอบและจัดการโฟลว์การรับส่งข้อมูลไปยัง FCM

การจัดการการดำเนินการซ้ำ

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

หมดเวลา

ตั้งค่าระยะหมดเวลาอย่างน้อย 10 วินาทีในการส่งคำขอก่อนลองอีกครั้ง การเรียกใช้กระบวนการระยะไกลภายในของ FCM ส่วนใหญ่จะใช้การหมดเวลา 10 วินาที

ข้อผิดพลาด

  • สำหรับข้อผิดพลาด 400, 401, 403, 404 ให้ยกเลิกและไม่ต้องลองใหม่
  • สำหรับข้อผิดพลาด 429 ให้ลองอีกครั้งหลังจากรอจนครบระยะเวลาที่กำหนดไว้ในส่วนหัว "ลองอีกครั้ง" หากไม่ได้ตั้งค่าการลองอีกครั้งหลังจากตั้งค่าส่วนหัวไว้ ค่าเริ่มต้นจะเป็น 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% หรือเร็วกว่านั้น "Soak" (สังเกตการทำงานของระบบขณะโหลด) แต่ละขั้นตอนเป็นเวลา 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% การเพิ่มจำนวนอย่างราบรื่นจาก 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 หากเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

  • โควต้าเริ่มต้นไม่ตรงตาม Use Case ของคุณอีกต่อไป
  • คุณกำลังเปลี่ยนรูปแบบการส่งภายในกรอบเวลา 3 เดือนด้วยระดับ 100,000 RPS ทั่วโลก หรือ 30,000 RPS ในทวีป