AI API Failover และ Fallback Routing: ทุกสิ่งที่คุณต้องรู้

แอป AI ส่วนใหญ่เริ่มจากการผสานรวมแบบง่ายเพียงตัวเดียว

คุณเลือกผู้ให้บริการ LLM ใส่คีย์ API ส่งพรอมป์ รับการตอบกลับ แล้วปล่อยฟีเจอร์

สำหรับต้นแบบ โดยมากก็เพียงพอ

แต่โปรดักชันนั้นต่างออกไป

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

นั่นคือเหตุผลที่ AI API failover กลายเป็นข้อกำหนดเชิงปฏิบัติสำหรับทีมที่กำลังสร้างแอปพลิเคชัน LLM ระดับโปรดักชัน

แทนที่จะสมมติว่าผู้ให้บริการรายเดียวจะพร้อมใช้งานเสมอ แอป AI ที่แข็งแรงถูกออกแบบให้สลับเส้นทางได้เมื่อมีสิ่งผิดปกติเกิดขึ้น

AI API Failover คืออะไร?

AI API failover คือรูปแบบด้านความเชื่อถือได้ ที่ซึ่งแอปพลิเคชันของคุณสลับไปยังโมเดลสำรองหรือเส้นทางผู้ให้บริการสำรองโดยอัตโนมัติเมื่อเส้นทางหลักล้มเหลว

การผสานตรงที่เปราะบางมีลักษณะดังนี้:

Your App → Single AI Provider → Single Point of Failure

สถาปัตยกรรมที่ทนทานกว่ามีลักษณะดังนี้:

Your App → Unified LLM API Layer → Primary Model                                 → Fallback Model

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

ผู้ใช้ไม่จำเป็นต้องรู้ว่าโมเดลใดเป็นผู้จัดการคำขอ

พวกเขาเพียงได้รับคำตอบ

นี่คือเป้าหมายหลักของ AI API failover: เปลี่ยนความล้มเหลวฝั่งผู้ให้บริการให้กลายเป็นเหตุการณ์สลับเส้นทางเบื้องหลัง แทนการล้มเหลวที่ผู้ใช้มองเห็นได้

ทำไมแอป AI ที่พึ่งผู้ให้บริการรายเดียวจึงเปราะบาง

ผลิตภัณฑ์ AI จำนวนมากยังคงสร้างขึ้นบนการเรียก API โดยตรงไปยังผู้ให้บริการรายเดียว

ซึ่งมักหมายถึงแอปผูกติดอย่างแน่นหนากับ:

• คีย์ API เดียว
• SDK เพียงตัวเดียว
• รูปแบบการตอบกลับเพียงแบบเดียว
• รายการโมเดลเพียงรายการเดียว
• ระบบเรียกเก็บเงินเพียงระบบเดียว
• นโยบายจำกัดอัตราการเรียกใช้งานเพียงนโยบายเดียว
• โปรไฟล์เวลาพร้อมให้บริการเพียงโปรไฟล์เดียว

สิ่งนี้อาจใช้งานได้ดีในสภาพแวดล้อมพัฒนา แต่ก่อให้เกิดความเสี่ยงในโปรดักชัน

สถานการณ์ความล้มเหลวที่พบได้ทั่วไป ได้แก่:

• ผู้ให้บริการล่ม ผู้ให้บริการ AI ไม่พร้อมใช้งานหรือเสื่อมประสิทธิภาพบางส่วน.
• ข้อจำกัดอัตรา HTTP 429 แอปของคุณส่งคำขอมากกว่าที่ผู้ให้บริการอนุญาต.
• ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ 5xx ผู้ให้บริการส่งคืนข้อผิดพลาดแบ็กเอนด์ชั่วคราว.
• ความหน่วงเพิ่มสูงผิดปกติ โมเดลตอบสนองช้ากว่าที่ประสบการณ์ในโปรดักต์รองรับ.
• การเปลี่ยนแปลงความพร้อมใช้งานของโมเดล เส้นทางของโมเดลอาจไม่พร้อมใช้งานชั่วคราว ถูกเลิกใช้ หรือถูกจำกัด.

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

มันเป็นส่วนหนึ่งของโครงสร้างพื้นฐานของผลิตภัณฑ์

เมื่อ AI API ล้มเหลว ประสบการณ์ของผลิตภัณฑ์ก็ล้มเหลวตามไปด้วย

การผสานตรง เทียบกับ ชั้น API LLM แบบรวม

วิธีแก้ปัญหาไม่ใช่การเพิ่ม SDK ของผู้ให้บริการหลายเจ้าแบบสุ่มลงไปทั่วฐานโค้ดของคุณ

โดยปกติแล้วสิ่งนั้นจะสร้างความซับซ้อนมากกว่าลดลง

รูปแบบที่ดีกว่าคือวางชั้น API LLM แบบรวมไว้ระหว่างแอปพลิเคชันของคุณกับผู้ให้บริการโมเดลภายนอก

แทนที่จะทำแบบนี้:

Frontend → OpenAI SDKBackend Job → Anthropic SDKAgent Workflow → DeepSeek SDKVideo Feature → Separate Video API

ให้ใช้แบบนี้:

Application → Unified API Layer → Multiple Models / Providers

นามธรรมนี้ทำให้แอปของคุณมีอินเทอร์เฟซที่เสถียรหนึ่งจุด ขณะที่เปิดทางให้ชั้นโมเดลด้านล่างสามารถเปลี่ยนแปลงได้

ด้วยชั้น API แบบรวม แอปของคุณสามารถ:

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

ตัวอย่างเช่น การเรียกโมเดลภายในของคุณอาจยังคงเรียบง่าย:

await generateText({  messages,  model: "gpt-5.6",  temperature: 0.7});

ตรรกะโปรดักต์ของคุณไม่ควรต้องสนใจว่าคำขอถูกให้บริการโดย GPT-5.6, Claude, DeepSeek, Gemini หรือโมเดลที่เหมาะสมอื่นใด

ตรรกะการกำหนดเส้นทางควรอยู่ในเลเยอร์โครงสร้างพื้นฐานของโมเดล ไม่ควรกระจัดกระจายไปทั่วแอปพลิเคชัน.

เมื่อไรที่แอปของคุณควรสลับผู้ให้บริการ?

ระบบ failover ที่ดีควรแม่นยำ

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

กฎง่ายๆ คือ:

ทำ failover สำหรับความล้มเหลวฝั่งผู้ให้บริการ แก้บั๊กฝั่งแอปก่อน

ตัวอย่างเช่น ข้อผิดพลาดอย่าง 400 Bad Request, 401 Unauthorized และ 403 Forbidden มักหมายความว่ามีบางอย่างผิดกับคำขอของคุณ การยืนยันตัวตน หรือสิทธิ์การเข้าถึง การส่งคำขอที่เสียนี้ไปยังผู้ให้บริการรายอื่นจะไม่แก้ปัญหา

ในทางกลับกัน ข้อผิดพลาดอย่าง 429 Rate Limit, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout, การหมดเวลาคำขอ หรือความไม่พร้อมใช้งานชั่วคราวของโมเดล เป็นผู้สมัครที่เหมาะสมกว่าสำหรับการสลับเส้นทางอัตโนมัติ

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

เป้าหมายไม่ใช่การซ่อนข้อผิดพลาดทั้งหมด เป้าหมายคือปกป้องผู้ใช้จากความล้มเหลวฝั่งผู้ให้บริการ ขณะทำให้บั๊กฝั่งแอปยังคงมองเห็นได้โดยทีมวิศวกรรมของคุณ

สำหรับอ้างอิงสถานะ HTTP นักพัฒนาสามารถดูแหล่งข้อมูลอย่าง เอกสาร HTTP 429 ของ MDN หรือเอกสารข้อผิดพลาดของผู้ให้บริการ เช่น ข้อผิดพลาดของ Anthropic API

ระบบ failover ที่ดีควรแม่นยำ

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

ไม่ควรทำ Failover สำหรับข้อผิดพลาดเหล่านี้

ข้อผิดพลาดเหล่านี้มักหมายความว่ามีบางอย่างผิดกับคำขอหรือการตั้งค่าของคุณ:

การส่งคำขอที่เสียแบบเดิมไปยังผู้ให้บริการอีกรายจะไม่แก้ปัญหา มีแต่จะทำให้การดีบักยากขึ้น

ทริกเกอร์ Failover สำหรับข้อผิดพลาดเหล่านี้

กรณีเหล่านี้เหมาะกว่าสำหรับการสลับเส้นทางอัตโนมัติ:

กฎง่ายๆ:

ทำ failover สำหรับความล้มเหลวฝั่งผู้ให้บริการ อย่าทำ failover สำหรับบั๊กฝั่งแอป

สำหรับอ้างอิงสถานะ HTTP นักพัฒนาสามารถดูแหล่งข้อมูลอย่าง เอกสาร HTTP 429 ของ MDN หรือเอกสารข้อผิดพลาดของผู้ให้บริการ เช่น ข้อผิดพลาดของ Anthropic API

สร้างแอป AI ที่ทนทานด้วย Claude Code และ Cursor

เครื่องมือพัฒนาแบบมีผู้ช่วย AI เช่น Claude Code, Cursor และ GitHub Copilot ช่วยให้ทีมสร้างงานได้เร็วขึ้น

แต่ความแตกต่างระหว่างโค้ดที่ทำงานได้ในเครื่อง กับโค้ดที่ทนต่อทราฟฟิกโปรดักชันนั้นมีอยู่มาก

หากคุณถามผู้ช่วยโค้ดด้วย AI ว่า:

Add an AI chat feature to my application using an LLM API.

บ่อยครั้งมันจะสร้างการผสานผู้ให้บริการโดยตรง

ซึ่งอาจใช้ได้สำหรับเดโม แต่สร้างสถาปัตยกรรมโปรดักชันที่เปราะบาง

พรอมป์ที่ดีกว่าคือสิ่งที่เฉพาะเจาะจงมากขึ้น:

Create a unified LLM provider abstraction layer.​The application should call one stable internal interface.​Configure a primary model route and a fallback route through CometAPI.​If the primary route times out, returns HTTP 429, or returns a 5xx error, catch the exception and retry with the fallback model.​Do not retry 400, 401, or 403 errors.​Keep all provider-specific configuration separate from the core business logic.

สิ่งนี้เปลี่ยนผลลัพธ์จากโค้ดระดับฟีเจอร์ไปเป็นโค้ดระดับสถาปัตยกรรม

นี่แหละคือความต่างระหว่าง “มันใช้งานได้” กับ “มันอยู่รอดในโปรดักชันได้”

เพิ่มการสังเกตการณ์ก่อนเกิดเหตุขัดข้อง

Failover มีประโยชน์มากขึ้นเมื่อคุณมองเห็นว่าเกิดอะไรขึ้น

หากแอปของคุณสลับโมเดลอย่างเงียบๆ แต่คุณไม่ติดตาม คุณอาจพลาดประเด็นความเชื่อถือได้ที่สำคัญ

ชุดการสังเกตการณ์ AI แบบเบาๆ ควรติดตาม:

• สถานะการกำหนดเส้นทางที่ใช้งานอยู่ ขณะนี้โมเดลหรือผู้ให้บริการใดกำลังรับทราฟฟิก?
• บันทึกเหตุการณ์การสลับเส้นทาง เกิดการสลับเมื่อใด และทำไม?
• อัตราข้อผิดพลาดตามเส้นทาง มี 429 การหมดเวลา หรือข้อผิดพลาด 5xx เพิ่มขึ้นหรือไม่?
• ความหน่วงและเวลาในการได้โทเคนแรก โมเดลหลักเริ่มช้าเกินไปหรือไม่?
• การกระจายทราฟฟิก ทราฟฟิกไปยังเส้นทางหลักเทียบกับเส้นทางสำรองเป็นเท่าใด?
• ต้นทุนตามเส้นทางโมเดล การทำ failover ทำให้ต้นทุนเพิ่มขึ้นโดยไม่คาดคิดหรือไม่?

นี่ช่วยให้ทีมของคุณควบคุมสถานการณ์ได้

ถ้าโมเดลหลักเริ่มช้าลง คุณสามารถเลื่อนทราฟฟิกได้ก่อนที่ผู้ใช้จะบ่น หากการใช้เส้นทางสำรองพุ่งสูง ทีมของคุณสามารถตรวจสอบเส้นทางผู้ให้บริการ โควตา หรือความพร้อมใช้งานของโมเดลได้

ความเชื่อถือไม่ควรเป็นการคาดเดา

มันควรมองเห็นได้

แนวปฏิบัติที่ดีสำหรับ AI API Failover

AI API failover จะได้ผลดีที่สุดเมื่อถูกออกแบบตั้งแต่เนิ่นๆ ไม่ใช่ถูกอุดเป็นแพตช์ฉุกเฉินหลังเหตุขัดข้องครั้งแรก

ต่อไปนี้คือกฎปฏิบัติที่ใช้ได้จริงบางประการ

กำหนดเกณฑ์ Timeout ให้ชัดเจน

อย่ารอเส้นทางหลักตลอดไป

กำหนดงบความหน่วงสำหรับผลิตภัณฑ์ของคุณ ตัวอย่างเช่น อินเทอร์เฟซแชตแบบเรียลไทม์อาจต้องใช้ค่า timeout ที่สั้นกว่ามากเมื่อเทียบกับเวิร์กโฟลว์สร้างรายงานเบื้องหลัง

หากเส้นทางหลักเกินงบดังกล่าว ให้ทริกเกอร์เส้นทางสำรอง

อย่าทำ Failover ให้กับคำขอที่ไม่ถูกต้อง

หากคำขอมีรูปแบบผิด ไม่ได้รับอนุญาต หรือขาดพารามิเตอร์ที่จำเป็น ให้แก้คำขอก่อน

Failover ควรปกป้องผู้ใช้จากความล้มเหลวฝั่งผู้ให้บริการ ไม่ใช่ซ่อนบั๊กของแอป

ใช้โมเดลสำรองที่ใกล้เคียงกัน

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

ตัวอย่าง:

• งานด้านการเขียนโค้ดต้องใช้โมเดลสำรองที่เก่งโค้ด
• เวิร์กโฟลว์สนับสนุนลูกค้าต้องใช้โมเดลที่เชื่อฟังคำสั่งได้ดี
• เวิร์กโฟลว์เชิงสร้างสรรค์ต้องรักษาคุณภาพเอาต์พุต
• เวิร์กโฟลว์วิดีโอต้องมีเส้นทางสำรองที่รองรับมีเดียชนิดเดียวกัน

บันทึกทุกเหตุการณ์การสลับเส้นทาง

ทุกเหตุการณ์ failover ควรถูกบันทึก

ติดตาม:

• โมเดลเดิม
• โมเดลสำรอง
• ประเภทข้อผิดพลาด
• ความหน่วงของคำขอ
• จำนวนครั้งที่ลองใหม่
• สถานะสุดท้าย
• ต้นทุนโดยประมาณ

สิ่งนี้ช่วยให้ทีมของคุณเข้าใจว่า failover ทำงานตามคาดหรือกำลังซ่อนปัญหาเชิงโครงสร้างที่ลึกกว่า

ทบทวนคุณภาพของเส้นทางสำรองเป็นประจำ

โมเดลเปลี่ยนแปลงเร็ว

เส้นทางสำรองที่ดีเมื่อเดือนที่แล้ว อาจไม่ใช่เส้นทางที่ดีที่สุดวันนี้ ทั้งราคา คุณภาพ ความเร็ว และความพร้อมใช้งาน ล้วนเปลี่ยนได้

ทบทวนการตั้งค่าเส้นทางสำรองอย่างสม่ำเสมอ และอัปเดตกลยุทธ์การกำหนดเส้นทางควบคู่กับการเติบโตของผลิตภัณฑ์ของคุณ

ลองใหม่ (Retry) เทียบกับ Failover

Retry และ failover เกี่ยวข้องกัน แต่ไม่เหมือนกัน

Retry คือการส่งคำขอเดิมไปยังเส้นทางเดิมอีกครั้ง

Failover คือการส่งคำขอไปยังเส้นทางสำรองที่ต่างออกไปเมื่อเส้นทางหลักดูไม่พร้อมใช้งานหรือไม่น่าเชื่อถือ

ในโปรดักชัน มักใช้ทั้งสองอย่างร่วมกัน

ตัวอย่าง:

Request → Primary Model → Short Retry → Fallback Model → Response

วิธีนี้หลีกเลี่ยงการสลับเส้นทางที่ก้าวร้าวเกินไป ขณะยังคงปกป้องประสบการณ์ผู้ใช้เมื่อเส้นทางหลักไม่แข็งแรงจริงๆ

ข้อคิดส่งท้าย: Failover ไม่ใช่การออกแบบที่ฟุ่มเฟือย

สำหรับโปรเจ็กต์สุดสัปดาห์ การพึ่งผู้ให้บริการ AI รายเดียวอาจยอมรับได้

สำหรับแอปโปรดักชันที่มีผู้ใช้จริง การพึ่งผู้ให้บริการรายเดียวคือความเสี่ยงด้านความเชื่อถือได้

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

คำถามไม่ใช่ว่า API ภายนอกจะล้มเหลวบ้างหรือไม่

คำถามคือผู้ใช้ของคุณจะรู้สึกถึงมันหรือไม่

ชั้น LLM API แบบรวมที่มี failover จะเปลี่ยนปัญหาผู้ให้บริการให้กลายเป็นเหตุการณ์สลับเส้นทางที่ควบคุมได้ ช่วยให้ทีมของคุณคงสถานะออนไลน์ของผลิตภัณฑ์ ลดการล็อกอินกับผู้ขายรายเดียว ทำให้การสลับโมเดลง่ายขึ้น และจัดการโครงสร้างพื้นฐาน AI ได้อย่างเป็นระเบียบ

อย่ารอเหตุขัดข้องครั้งแรกค่อยออกแบบความเชื่อถือได้

สร้างชั้น AI API failover ตั้งแต่เนิ่นๆ

ผู้ใช้อาจไม่เคยรู้ว่ามันช่วยรักษาประสบการณ์ของพวกเขาไว้ และนั่นแหละคือหัวใจสำคัญ

พร้อมสร้างแอป AI ที่เชื่อถือได้มากขึ้นหรือยัง? เริ่มต้นได้ที่ CometAPI

คำถามที่พบบ่อย

AI API failover คืออะไร?

AI API failover คือรูปแบบด้านความเชื่อถือได้ที่แอปพลิเคชันสลับจากโมเดลหลักหรือเส้นทางผู้ให้บริการหลักไปยังเส้นทางสำรองโดยอัตโนมัติเมื่อเส้นทางหลักล้มเหลว หมดเวลา ถูกจำกัดอัตรา หรือไม่พร้อมใช้งาน

ทำไมแอป LLM ต้องมี failover?

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

ทุกข้อผิดพลาดของ API ควรทริกเกอร์ failover หรือไม่?

ไม่ ข้อผิดพลาดอย่าง 400 Bad Request, 401 Unauthorized และ 403 Forbidden มักชี้ว่าปัญหาอยู่ที่คำขอ คีย์ API หรือสิทธิ์ของคุณเอง Failover มีประโยชน์มากกว่าสำหรับการหมดเวลา ข้อจำกัดอัตรา 429 ข้อผิดพลาด 5xx และเส้นทางโมเดลที่ไม่พร้อมใช้งาน

ความต่างระหว่าง Retry กับ Failover คืออะไร?

Retry คือการส่งคำขอเดิมซ้ำไปที่เส้นทางเดิม ส่วน Failover คือการส่งคำขอไปยังโมเดลหรือเส้นทางผู้ให้บริการสำรองเมื่อเส้นทางหลักไม่พร้อมใช้งานหรือไม่น่าเชื่อถือ

CometAPI ช่วยเรื่อง AI API failover อย่างไร?

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

ฉันสามารถใช้ GPT-5.6 เป็นเส้นทางหลักและใช้โมเดลอื่นเป็นสำรองได้ไหม?

ได้ การตั้งค่าที่พบบ่อยคือใช้โมเดลที่แข็งแรงกว่า เช่น GPT-5.6 สำหรับงานให้เหตุผลหลัก แล้วตั้งค่าโมเดลที่เหมาะสมอีกตัวเป็นเส้นทางสำรอง ทางเลือกที่ดีที่สุดขึ้นกับกรณีใช้งานของคุณ ข้อกำหนดด้านคุณภาพ งบความหน่วง และเป้าหมายด้านต้นทุน