แคนารี เทสติ้ง API: ตรวจจับเวอร์ชันที่มีปัญหาก่อนผู้ใช้จะพบ

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

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

สำหรับ API โดยเฉพาะ คุณสามารถทำได้ดีกว่าแค่เฝ้าดูแดชบอร์ดและหวังว่าจะไม่มีอะไรเกิดขึ้น คุณสามารถรันชุดการทดสอบจริงกับ Canary ทันทีที่มันเริ่มทำงาน ตรวจสอบรหัสสถานะ, สคีมาการตอบกลับ และความหน่วง แล้วใช้ผลลัพธ์นั้นเป็นเกณฑ์ในการเผยแพร่ นั่นคือเวิร์กโฟลว์ที่คู่มือนี้จะอธิบาย และเราจะเชื่อมโยงมันเข้าด้วยกันตั้งแต่ต้นจนจบด้วย Apidog และโปรแกรมรันบรรทัดคำสั่ง เพื่อให้ทุกอย่างอยู่ภายในไปป์ไลน์ CI/CD ที่มีอยู่ของคุณ

การทดสอบแบบ Canary คืออะไรกันแน่

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

ในทางปฏิบัติ การปรับใช้แบบ Canary หมายถึงการรันสองเวอร์ชันของบริการของคุณพร้อมกัน:

• Stable (เสถียร): เวอร์ชันการผลิตปัจจุบันที่ให้บริการทราฟฟิกส่วนใหญ่
• Canary (คานารี): เวอร์ชันใหม่ที่ให้บริการทราฟฟิกเพียงเล็กน้อย (มักจะเริ่มต้นที่ 1% ถึง 5%)

โหลดบาลานเซอร์, เซอร์วิสเมช หรือ Ingress Controller จะแยกทราฟฟิกระหว่างสองเวอร์ชัน คุณจะเฝ้าดูอัตราข้อผิดพลาด, ความหน่วง และเมตริกทางธุรกิจของ Canary เทียบกับค่าพื้นฐานของเวอร์ชัน Stable หาก Canary ทำงานได้ดี คุณจะค่อยๆ เปลี่ยนทราฟฟิกไปให้มันมากขึ้นเป็นลำดับขั้นจนกว่าจะให้บริการได้ 100% และกลายเป็นเวอร์ชัน Stable ใหม่ หากประสิทธิภาพแย่ลง คุณจะส่งทราฟฟิกทั้งหมดกลับไปยังเวอร์ชัน Stable และการเผยแพร่ที่ไม่ดีนั้นก็จะไม่เข้าถึงผู้ใช้ส่วนใหญ่ของคุณ

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

การทดสอบแบบ Canary กับการทดสอบที่คุณทำอยู่แล้ว

การทดสอบแบบ Canary ไม่ได้มาแทนที่การทดสอบอื่นๆ ของคุณ แต่มันอยู่ท้ายสุดของห่วงโซ่และตรวจจับความล้มเหลวประเภทที่แตกต่างออกไป

เหตุผลที่การทดสอบแบบ Canary มีความสำคัญ: สัดส่วนอย่างมหาศาลของเหตุการณ์ที่เกิดขึ้นในการผลิตมาจากสิ่งแวดล้อมก่อนการผลิตที่ไม่สามารถจำลองได้อย่างสมบูรณ์ เช่น ตัวแปรสภาพแวดล้อมที่หายไป การตั้งค่า Connection Pool ที่ล้าสมัย ดัชนีฐานข้อมูลที่มีอยู่ใน Staging แต่ไม่มีใน Production การพึ่งพาปลายน้ำที่มีพฤติกรรมแตกต่างกันภายใต้การยืนยันตัวตนจริง โค้ดของคุณอาจถูกต้อง แต่สภาพแวดล้อมรอบๆ มันไม่ถูกต้อง การทดสอบแบบ Canary คือครั้งแรกที่การเผยแพร่ใหม่ของคุณพบกับสภาพแวดล้อมนั้น และคุณต้องการให้มันพบกับทราฟฟิกเพียงสองเปอร์เซ็นต์ ไม่ใช่ทั้งหมด

หากคุณต้องการบริบทที่กว้างขึ้นว่าสิ่งนี้เข้ากันได้อย่างไร คู่มือของเราเกี่ยวกับ วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD ครอบคลุมขั้นตอนต้นน้ำ และ การทดสอบ Smoke test เทียบกับการทดสอบ Regression test จะอธิบายประเภทการทดสอบสองประเภทที่ Canary ใช้ประโยชน์มากที่สุด

สิ่งที่ต้องวัดผลใน Canary

Canary จะมีประโยชน์ก็ต่อเมื่อคุณรู้ว่า "ปกติ" มีลักษณะอย่างไร เลือกชุดสัญญาณเล็กๆ และเปรียบเทียบ Canary กับค่าพื้นฐานที่เสถียร ไม่ใช่เทียบกับตัวเลขสัมบูรณ์ อัตราข้อผิดพลาด 1.2% อาจเป็นเรื่องปกติสำหรับบริการของคุณ สิ่งสำคัญคือ Canary นั้นแย่กว่าเวอร์ชัน Stable อย่างมีนัยสำคัญหรือไม่ในขณะนี้

สัญญาณสี่อย่างครอบคลุมกรณีส่วนใหญ่:

1. อัตราข้อผิดพลาด: สัดส่วนของการตอบกลับ 5xx และบ่อยครั้งคือ 4xx ที่ไม่ควรเกิดขึ้น เช่น การเพิ่มขึ้นอย่างรวดเร็วของ 401s หลังจากการเปลี่ยนแปลงการยืนยันตัวตน นี่คือเมตริกที่สำคัญที่สุดเพียงอย่างเดียว
2. ความหน่วง (Latency): p95 และ p99 ไม่ใช่อัตราเฉลี่ย ค่าเฉลี่ยจะซ่อนส่วนที่ช้าซึ่งผู้ใช้จริงรู้สึกเจ็บปวด Canary ที่ช้าลง 40 มิลลิวินาทีที่ p99 ถือเป็นคำเตือน แม้ว่าค่าเฉลี่ยจะดูปกติก็ตาม
3. ความถูกต้องของการตอบกลับ: เนื้อหา (body) ยังคงตรงตามสคีมาหรือไม่? การตอบกลับ 200 OK ที่มีรูปแบบผิดเพี้ยนแย่กว่า 500 เพราะการตรวจสอบจะไม่แจ้งเตือน
4. สัญญาณทางธุรกิจ: การชำระเงินสำเร็จ, การเข้าสู่ระบบสำเร็จ, สินค้าที่เพิ่มลงในตะกร้า สิ่งเหล่านี้จะตรวจจับการถดถอยเชิงตรรกะที่ในทางเทคนิคแล้วถือเป็นการตอบกลับ HTTP ที่ "สำเร็จ"

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

เวิร์กโฟลว์การทดสอบแบบ Canary ทีละขั้นตอน

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

1. ปรับใช้เวอร์ชันใหม่เป็น Canary ควบคู่ไปกับเวอร์ชัน Stable
2. กำหนดเส้นทางทราฟฟิกส่วนเล็กๆ (เช่น 5%) ไปยัง Canary
3. รันชุดการทดสอบ API แบบอัตโนมัติกับปลายทางของ Canary
4. เฝ้าดูอัตราข้อผิดพลาดและความหน่วงในช่วงเวลาสั้นๆ
5. เกณฑ์: หากการทดสอบผ่านและเมตริกยังอยู่ในงบประมาณ ให้เปลี่ยนทราฟฟิกมากขึ้น หากไม่เป็นไปตามนั้น ให้ย้อนกลับ (Roll back)
6. ทำซ้ำการเพิ่มทราฟฟิก (5% ไป 25% ไป 50% ไป 100%) โดยทดสอบซ้ำในแต่ละขั้นตอน
7. เลื่อนระดับ Canary ให้เป็น Stable, เลิกรองรับเวอร์ชันเก่า

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

การสร้างชุดทดสอบใน Apidog

ชุดทดสอบคือหัวใจของการทดสอบแบบ Canary และเป็นจุดที่ทีมส่วนใหญ่ละเลย การ "ทดสอบ" แบบ Canary ที่เพียงแค่ ping /health และตรวจสอบรหัส 200 บอกคุณเพียงว่ากระบวนการเริ่มต้นขึ้นแล้ว มันไม่ได้บอกคุณเลยว่าปลายทางที่แท้จริงของคุณทำงานได้หรือไม่

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

สถานการณ์ Canary ที่แข็งแกร่งสำหรับ API ของอีคอมเมิร์ซมีลักษณะดังนี้:

• ขั้นตอนที่ 1, ยืนยันตัวตน POST /auth/login ด้วยบัญชีทดสอบ ยืนยัน 200, ดึงโทเค็นจากการตอบกลับไปเก็บไว้ในตัวแปร
• ขั้นตอนที่ 2, อ่าน GET /products?limit=10 พร้อมโทเค็น ยืนยัน 200, ยืนยันว่าการตอบกลับเป็นอาร์เรย์, ยืนยันว่าแต่ละรายการมี id, name และ price
• ขั้นตอนที่ 3, เขียน POST /cart ด้วยผลิตภัณฑ์ที่ทราบ ยืนยัน 201, ยืนยันว่ายอดรวมตะกร้าสินค้าที่ส่งกลับตรงกับค่าที่คาดไว้
• ขั้นตอนที่ 4, ตรวจสอบสถานะ GET /cart ยืนยันว่าสินค้าที่คุณเพิ่งเพิ่มนั้นปรากฏอยู่

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

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

การรันชุดทดสอบจากบรรทัดคำสั่ง

ในการควบคุมการปรับใช้ ชุดทดสอบจะต้องรันแบบ Headless ใน CI Apidog มาพร้อมกับ CLI สำหรับสิ่งนี้โดยเฉพาะ ติดตั้งลงบน Build Agent ของคุณ:

npm install -g apidog-cli

ส่งออกข้อมูลสถานการณ์ทดสอบของคุณจาก Apidog เป็นไฟล์ที่จัดรูปแบบสำหรับ CLI หรือชี้โปรแกรมรันไปยังสถานการณ์ด้วย ID โดยใช้ Access Token จากนั้นรันมัน:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$CANARY_SCENARIO_ID" \
  -e "$CANARY_ENV_ID" \
  -r cli,html,junit

ธงบางอย่างที่ควรรู้สำหรับการทำงานแบบ Canary:

• -t, --test-scenario รันสถานการณ์เฉพาะด้วย ID ใช้ -f, --test-scenario-folder เพื่อรันทั้งโฟลเดอร์ของสถานการณ์
• -e, --environment เลือกสภาพแวดล้อมรันไทม์ ชี้สิ่งนี้ไปยังสภาพแวดล้อมที่ Base URL คือปลายทางของ Canary ของคุณ เพื่อให้การทดสอบเดียวกันสามารถเข้าถึง Canary, Staging หรือ Production ได้โดยการสลับค่าเดียว
• -r, --reporters ควบคุมผลลัพธ์ cli พิมพ์ไปยังคอนโซล, html สร้างรายงานที่แชร์ได้, และ junit ส่งออก XML ที่ GitHub Actions, GitLab, Jenkins และแดชบอร์ด CI ส่วนใหญ่สามารถแยกวิเคราะห์ได้โดยตรงเพื่อแสดงผลการผ่าน/ไม่ผ่านของการทดสอบแต่ละรายการ
• -d, --iteration-data รันชุดทดสอบหนึ่งครั้งต่อแถวของไฟล์ CSV หรือ JSON มีประโยชน์สำหรับการทดสอบ Canary ด้วยโปรไฟล์ผู้ใช้หลายโปรไฟล์หรือ ID ผลิตภัณฑ์หลายรายการในการรันครั้งเดียว
• --upload-report อัปโหลดสรุปการรันกลับไปยัง Apidog เพื่อให้ทีมสามารถดูประวัติ Canary ในแอปได้

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

สำหรับการเจาะลึกเพิ่มเติมเกี่ยวกับการรัน Apidog ในไปป์ไลน์ วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน GitHub Actions และ คู่มือการรวม Jenkins จะครอบคลุมแพลตฟอร์มเหล่านั้นโดยละเอียด

การเชื่อมโยงเข้ากับ CI/CD

นี่คือตัวอย่างงาน GitHub Actions ที่กระชับซึ่งปรับใช้ Canary, ทดสอบ และจะเลื่อนขั้นก็ต่อเมื่อสำเร็จ โครงสร้างนี้สามารถนำไปใช้กับ GitLab CI, CircleCI หรือ Jenkins ได้ โดยมีการเปลี่ยนแปลงไวยากรณ์เล็กน้อย

name: canary-release

on:
  push:
    branches: [main]

jobs:
  canary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy canary (5% traffic)
        run: ./deploy.sh --canary --weight 5

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Test the canary
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$CANARY_SCENARIO_ID" \
            -e "$CANARY_ENV_ID" \
            -r cli,junit
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          CANARY_SCENARIO_ID: ${{ vars.CANARY_SCENARIO_ID }}
          CANARY_ENV_ID: ${{ vars.CANARY_ENV_ID }}

      - name: Bake and watch (2 min)
        run: sleep 120 && ./check-metrics.sh --service canary --max-error-rate 1.0

      - name: Promote canary to 100%
        run: ./deploy.sh --promote

      - name: Roll back on any failure
        if: failure()
        run: ./deploy.sh --rollback

ตรรกะที่ทำให้สิ่งนี้เป็นการปรับใช้แบบ Canary แทนที่จะเป็นการปรับใช้ปกติคือลำดับ Canary จะได้รับส่วนหนึ่งของทราฟฟิกก่อนที่การทดสอบจะรัน ดังนั้นการทดสอบจึงเกิดขึ้นกับเวอร์ชันที่กำลังให้บริการคำขอจริงอยู่แล้ว ขั้นตอน if: failure() คือตาข่ายนิรภัย: หากชุดทดสอบส่งคืนค่าที่ไม่ใช่ศูนย์ หรือการตรวจสอบเมตริกเกิดข้อผิดพลาด งานจะล้มเหลวและการย้อนกลับจะทำงานก่อนที่ทราฟฟิกจะเพิ่มขึ้นเกิน 5%

คงค่า CANARY_ENV_ID ให้ชี้ไปยังสภาพแวดล้อม Apidog ที่ Base URL กำหนดเป้าหมายไปที่ Canary เมื่อคุณต้องการรันชุดทดสอบเดียวกันนี้เป็น Smoke test สำหรับ Production หลังการปรับใช้ คุณเพียงแค่สลับเป็น ID สภาพแวดล้อม Production โดยไม่ต้องเปลี่ยนแปลงสิ่งอื่น นั่นคือประเด็นของการนำกลับมาใช้ใหม่: หนึ่งชุดทดสอบ หลายขั้นตอน

ข้อผิดพลาดทั่วไปที่ทำให้การทดสอบแบบ Canary ไร้ประโยชน์

ทดสอบปลายทางผิด หากการทดสอบของคุณเข้าถึง URL สาธารณะที่ถูกโหลดบาลานซ์ คำขออาจไปตกที่อินสแตนซ์ Stable แทนที่จะเป็น Canary กำหนดเส้นทางทดสอบไปยัง Canary อย่างชัดเจน ไม่ว่าจะผ่านส่วนหัวที่เมชกำหนดเส้นทาง, โฮสต์เนมสำหรับ Canary โดยเฉพาะ, หรือสภาพแวดล้อมที่มี Base URL เป็นที่อยู่ของ Canary

ระยะเวลา "บ่ม" ที่เป็นศูนย์ ความล้มเหลวบางอย่างจะปรากฏขึ้นภายใต้โหลดที่ต่อเนื่องเท่านั้น: หน่วยความจำรั่ว, Connection Pool หมด, แคชเต็ม รันการทดสอบ จากนั้นเฝ้าดูสักสองสามนาทีก่อนที่จะเลื่อนขั้น Canary ที่ผ่านทันทีและได้รับการเลื่อนขั้นภายในสิบวินาที แทบจะไม่ใช่ Canary เลย

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

เกณฑ์สัมบูรณ์แทนที่จะเป็นการเปรียบเทียบ "ล้มเหลวหากอัตราข้อผิดพลาดสูงกว่า 1%" จะล้มเหลวในวันที่อัตราข้อผิดพลาดพื้นฐานของคุณอยู่ที่ 1.5% อย่างถูกต้อง เปรียบเทียบ Canary กับเวอร์ชัน Stable ปัจจุบัน และยกเลิกการเผยแพร่เมื่อ Canary แย่ลงอย่างมีนัยสำคัญ ไม่ใช่เมื่อมันเกินตัวเลขที่คุณเลือกไว้เมื่อหลายเดือนก่อน

การยืนยันที่ไม่ละเอียด การตอบกลับ 200 ที่มีเนื้อหา (body) ไม่ถูกต้องจะผ่านการตรวจสอบรหัสสถานะเพียงอย่างเดียวและสร้างปัญหาให้กับผู้ใช้ของคุณ ยืนยันตามสคีมาการตอบกลับ ไม่ใช่แค่รหัสเท่านั้น นี่คือจุดที่การออกแบบสัญญา API ของคุณก่อนและการ ตรวจสอบความถูกต้องของการตอบกลับกับสคีมา ให้ผลตอบแทนโดยตรง: การทดสอบ Canary ของคุณจะได้รับสัญญาโดยอัตโนมัติ

Canary ควรมีขนาดเท่าใดและนานแค่ไหน?

ไม่มีคำตอบสากล แต่มีค่าเริ่มต้นที่ใช้งานได้สำหรับทีมส่วนใหญ่:

• เริ่มต้นที่ 5% ของทราฟฟิก เล็กพอที่จะจำกัดความเสียหาย ใหญ่พอที่จะได้รับสัญญาณจริงภายในไม่กี่นาทีสำหรับบริการที่มีการใช้งานมาก API ที่มีทราฟฟิกน้อยอาจต้องใช้เวลานานขึ้นเพื่อรวบรวมคำขอให้เพียงพอ
• ค่อยๆ เพิ่มเป็นขั้นๆ: 5% ไป 25% ไป 50% ไป 100% รันชุดทดสอบซ้ำในแต่ละขั้นตอน การถดถอยที่ซ่อนอยู่ที่ 5% บางครั้งจะปรากฏขึ้นที่ 50% เมื่อ Connection Pool เต็ม
• "บ่ม" อย่างน้อยสองสามนาทีต่อขั้นตอน นานพอสำหรับความล้มเหลวที่ค่อยๆ แสดงอาการให้ปรากฏขึ้น สั้นพอที่คุณจะไม่หยุดการเผยแพร่ทุกครั้งเป็นชั่วโมง

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

การทดสอบแบบ Canary เหมาะสมกับกลยุทธ์การเผยแพร่ของคุณอย่างไร

การทดสอบแบบ Canary เข้าคู่กับ Feature Flag และการปรับใช้แบบ Blue-Green ได้อย่างเป็นธรรมชาติ และควรทำความเข้าใจความแตกต่างให้ชัดเจน Blue-Green จะสลับทราฟฟิกทั้งหมดจากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่งในคราวเดียว การย้อนกลับทำได้เร็ว แต่ไม่มีการเปิดเผยแบบค่อยเป็นค่อยไป Feature Flag จะสลับพฤติกรรมสำหรับผู้ใช้ที่เลือกโดยไม่ต้องปรับใช้ใหม่ การเผยแพร่แบบ Canary จะค่อยๆ เปลี่ยนทราฟฟิกจริงและใช้สัญญาณแบบสดเป็นเกณฑ์

ทีมที่มีความเชี่ยวชาญส่วนใหญ่ใช้ทั้งสามวิธี: Blue-Green สำหรับการสลับโครงสร้างพื้นฐาน, Canary สำหรับการเพิ่มทราฟฟิกทีละน้อยด้วยเกณฑ์อัตโนมัติ, และ Feature Flag สำหรับการควบคุมที่ละเอียดเมื่อโค้ดทำงานอยู่แล้ว สิ่งที่เหมือนกันคือไม่มีวิธีใดที่ทำให้ไม่จำเป็นต้องทดสอบการเผยแพร่กับ Production พวกเขาควบคุมว่าผู้ใช้ของคุณจะได้รับผลกระทบมากน้อยเพียงใดในขณะที่คุณดำเนินการ

นั่นคือบทสรุปที่แท้จริง การทดสอบแบบ Canary ไม่ใช่เครื่องมือที่คุณซื้อ แต่มันคือวินัย: ปรับใช้เล็กน้อย, ทดสอบเวอร์ชันที่ทำงานจริงด้วยการยืนยันที่แท้จริง, เฝ้าดูสัญญาณ, และใช้ผลลัพธ์เป็นเกณฑ์ในการเผยแพร่ เครื่องมือต่างๆ มีอยู่เพื่อทำให้แต่ละขั้นตอนเหล่านี้เป็นอัตโนมัติ ด้วย Apidog คุณสร้างชุดทดสอบเพียงครั้งเดียว รันจาก CLI ภายในไปป์ไลน์ใดก็ได้ และให้รหัสการออกเป็นผู้ตัดสินใจว่าการเผยแพร่จะดำเนินต่อไปหรือไม่ การเผยแพร่ที่ไม่ดีจะหยุดอยู่ที่ 5% ของทราฟฟิก และผู้ใช้ของคุณจะไม่เห็นข้อผิดพลาด 500 เลย

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

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

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

ฉันจำเป็นต้องมี Service Mesh เพื่อทำการทดสอบแบบ Canary หรือไม่? ไม่จำเป็น Service Mesh อย่าง Istio หรือ Linkerd ทำให้การแยกทราฟฟิกง่ายขึ้น แต่คุณสามารถรัน Canaries ได้ด้วยการกำหนดน้ำหนัก Load Balancer แบบธรรมดา, Canary Annotation ของ Ingress Controller หรือแม้กระทั่งการกำหนดน้ำหนัก DNS ส่วนของการทดสอบและควบคุมในเวิร์กโฟลว์ ซึ่งเป็นจุดที่คู่มือนี้เน้น จะทำงานเหมือนกันไม่ว่าคุณจะแยกทราฟฟิกอย่างไร

สิ่งนี้แตกต่างจากการทดสอบ Smoke test หลังการปรับใช้อย่างไร? Smoke test มักจะรันเพียงครั้งเดียวกับเวอร์ชันที่ปรับใช้เต็มรูปแบบเพื่อยืนยันว่ามันทำงานอยู่ การทดสอบแบบ Canary จะรันกับเวอร์ชันที่ให้บริการทราฟฟิกจริงเพียงส่วนน้อย และจะใช้เป็นเกณฑ์ในการเพิ่มทราฟฟิก การยืนยันอาจเหมือนกัน ความแตกต่างอยู่ที่เวลาและผลลัพธ์ Smoke test ที่ล้มเหลวหมายถึงการย้อนกลับสิ่งที่มีอยู่แล้วสำหรับทุกคน; Canary test ที่ล้มเหลวหมายถึงการหยุดการเผยแพร่ที่ 5% สำหรับความแตกต่างระหว่างชุด Smoke test และ Regression test โปรดดู คู่มือเปรียบเทียบของเรา

ฉันสามารถนำการทดสอบ API ที่มีอยู่มาใช้เป็นการทดสอบแบบ Canary ได้หรือไม่? บ่อยครั้งก็ทำได้ หากคุณมีสถานการณ์ทดสอบ Apidog ที่มีการยืนยันที่แท้จริงอยู่แล้ว คุณก็เพียงแค่ชี้พวกมันไปยังสภาพแวดล้อมที่มี Base URL เป็น Canary และรันด้วย CLI สิ่งสำคัญคือการทำให้แน่ใจว่าการทดสอบของคุณยืนยันจากเนื้อหา (body) ของการตอบกลับ ไม่ใช่แค่รหัสสถานะ และการกำหนดเส้นทางไปยัง Canary แทนที่จะเป็น URL สาธารณะที่ถูกโหลดบาลานซ์

จะเกิดอะไรขึ้นเมื่อ Canary test ล้มเหลวใน CI? Apidog CLI จะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อมีการยืนยันล้มเหลว ไปป์ไลน์ของคุณจะถือว่านี่เป็นขั้นตอนที่ล้มเหลวเช่นเดียวกับขั้นตอนอื่นๆ: งานจะหยุด, ขั้นตอนการเลื่อนขั้นจะถูกข้าม, และขั้นตอนการย้อนกลับ if: failure() ของคุณจะทำงาน ไม่จำเป็นต้องมีมนุษย์คอยเฝ้าดูเพื่อให้การย้อนกลับเกิดขึ้น