การวิเคราะห์หลังเหตุการณ์กรณี Kagi เมื่อสัปดาห์ที่แล้ว

 (status.kagi.com)
1 คะแนน โดย GN⁺ 2024-01-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การแก้ไขปัญหาความไม่เสถียรของบริการ Kagi.com

  • กำลังตรวจสอบ - หลังการปล่อยใช้งานเกิดปัญหาขึ้น และทีมกำลังดำเนินการแก้ไขอยู่ (12 มกราคม 16:45 UTC)
  • เฝ้าติดตาม - ได้ย้อนกลับการเปลี่ยนแปลงค่าตั้งที่คาดว่าเป็นสาเหตุของปัญหา และกำลังเฝ้าติดตามอย่างต่อเนื่องว่าบริการกลับสู่ภาวะปกติแล้วหรือไม่ (12 มกราคม 18:30 UTC)
  • อัปเดต - เพื่อกู้คืนเสถียรภาพอย่างสมบูรณ์ จะหยุดทราฟฟิกชั่วคราวและเปลี่ยนเส้นทางผู้ใช้มายังหน้านี้ โดยจะให้รายละเอียดเพิ่มเติมตามความคืบหน้าระหว่างการค่อยๆ คืนโหลดกลับสู่บริการอย่างมีการควบคุม (12 มกราคม 20:26 UTC)
  • เฝ้าติดตาม - ทราฟฟิกได้รับการกู้คืนแล้ว และกำลังเฝ้าติดตามต่อเนื่องว่าบริการกลับสู่ภาวะปกติเต็มที่หรือไม่ (12 มกราคม 21:14 UTC)
  • แก้ไขแล้ว - ทุกบริการกลับมาทำงานตามปกติ ขอบคุณผู้ใช้ที่รอระหว่างการแก้ไขปัญหา

การวิเคราะห์หลังเหตุการณ์

  • Zac ผู้นำด้านเทคนิคของ Kagi ได้แบ่งปันการวิเคราะห์หลังเหตุการณ์อย่างละเอียดเกี่ยวกับการหยุดให้บริการเมื่อสัปดาห์ที่แล้ว
  • Seth วิศวกรอาวุโส และ Luan วิศวกร DevOps ได้ร่วมกันรับมือกับเหตุการณ์นี้
  • มีผู้ไม่หวังดีที่ใช้งานบริการในทางที่ผิดและอาศัยคอขวดของอินฟราสตรักเจอร์ ทีมจึงได้ออกมาตรการบรรเทาผลกระทบทันที และกำลังปรับปรุงทั้งโค้ดและการสื่อสารในหลายด้าน

ลำดับเหตุการณ์

  • ราว 17:30 น. ของวันที่ 12 มกราคม ทีมรับรู้ว่ามีปัญหาอินฟราสตรักเจอร์จากการมอนิเตอร์ภายในและรายงานปัญหาจากผู้ใช้
  • ลักษณะของปัญหาทำให้ผู้ใช้ในหลายภูมิภาคพบการโหลดช้าหรือหน้าเว็บหมดเวลา
  • การแก้ปัญหาใช้เวลาค่อนข้างนาน และมีการอธิบายทั้งภูมิหลัง ความคืบหน้า และแผนต่อจากนี้

กระบวนการแก้ปัญหาทางเทคนิค

  • ในตอนแรก ปัญหาเกิดขึ้นพร้อมกับการอัปเกรดทรัพยากร RAM เพิ่มให้ VM โดยบังเอิญ
  • ระบบมอนิเตอร์รายงานค่า latency สูงและปัญหาเกี่ยวกับ database connection pool ของแอปพลิเคชัน
  • connection pool เข้าสู่ภาวะอิ่มตัว ซึ่งหมายความว่าจำนวนการเชื่อมต่อทั้งหมดเกินขีดจำกัดสูงสุดที่ตั้งไว้
  • ระหว่างประเมินสุขภาพภายในของฐานข้อมูลและประสิทธิภาพของคิวรี ทีมได้ทดลองเปลี่ยนบางอินสแตนซ์เพื่อดูผลในการลดความแออัด
  • เมื่อดูเหมือนว่าการเปลี่ยนบางอินสแตนซ์ช่วยได้ จึงหยุดทราฟฟิกของผู้ใช้ชั่วคราวเพื่อรีเซ็ต connection pool ทั้งหมดพร้อมกันอย่างสมบูรณ์
  • หลังจากตรวจสอบสถานะฐานข้อมูล ก็ชัดเจนว่าต้นตอของปัญหาคือการแย่งกันใช้งานแถวในตารางผู้ใช้สูงผิดปกติ
  • การแย่งกันใช้งานนี้ทำให้ latency ของการเขียนเพิ่มสูงขึ้นอย่างมาก สร้าง backpressure ให้กับ connection pool ของแอปพลิเคชัน และสุดท้ายทำให้การเชื่อมต่อที่มีอยู่ทั้งหมดถูกใช้จนหมด
  • ก่อนหน้านี้ Kagi ใช้ฐานข้อมูลแบบ single-core ที่ถูกที่สุดบน GCP ซึ่งมีความเสี่ยงที่จะทำให้ฐานข้อมูลล่มได้ง่าย
  • ทีมระบุตัวผู้ไม่หวังดีได้ โดยพบทั้งบัญชีที่สร้างภายใน 24 ชั่วโมง และบัญชีผู้ใช้เดี่ยวที่ทำการค้นหามากกว่า 60,000 ครั้งในช่วงเวลาสั้นๆ
  • ได้ปิดความสามารถในการค้นหาของบัญชีนั้น และออก hotfix เพื่อปิดการเขียนบางอย่างที่เป็นต้นเหตุของปัญหา
  • ภายในเที่ยงคืน ปัญหาถูกแก้ไขอย่างสมบูรณ์ และทีมยังคงเฝ้าติดตามอย่างใกล้ชิดว่าผู้กระทำการเหล่านั้นจะกลับมาหรือไม่

มาตรการต่อจากนี้

  • ทีมได้เรียนรู้มากจากเหตุการณ์นี้ และได้เริ่มดำเนินแผนทันทีเพื่อเสริมความแข็งแกร่งให้ระบบ รวมถึงปรับปรุงกระบวนการสื่อสารเมื่อเกิดเหตุ
  • อย่างแรก ทีมยอมรับว่าการอัปเดตหน้า status ทำได้ไม่รวดเร็วพอ
  • จะย้ายไปใช้แพลตฟอร์มหน้า status ที่เปิดเผยข้อมูลจากระบบมอนิเตอร์ภายในแบบอัตโนมัติให้ผู้ใช้เห็นได้ง่ายขึ้น เพื่อให้รับรู้สุขภาพของแพลตฟอร์มแบบเรียลไทม์
  • กำลังบรรเทาคิวรีที่เป็นปัญหาโดยตรง และรันการทดสอบโหลดเพื่อค้นหาว่ายังมีจุดบกพร่องลักษณะคล้ายกันอีกหรือไม่
  • จะติดตั้งระบบมอนิเตอร์เพิ่มเติมเพื่อชี้ตำแหน่งที่ถูกต้องในอินฟราสตรักเจอร์ได้เร็วขึ้น และไม่ต้องเสียเวลาไล่ตามสัญญาณที่ผิดเหมือนครั้งนี้
  • กำลังเสริมความแข็งแกร่งให้ระบบตรวจจับการใช้งานในทางที่ผิดลักษณะนี้ และจำเป็นต้องตั้งข้อจำกัดอัตโนมัติเพื่อบังคับใช้ เพราะสิ่งนี้ไม่เพียงกระทบประสิทธิภาพ แต่ยังก่อให้เกิดต้นทุนโดยตรงด้วย
  • ข้อจำกัดใหม่มีผลบังคับใช้แล้ว ณ เวลาที่เขียนโพสต์นี้ และทีมจะเฝ้าติดตามผลกระทบพร้อมปรับแต่งต่อไปตามความจำเป็น
  • หากคิดว่าการเข้าถึง Kagi ของตนถูกบล็อกโดยผิดพลาด ขอให้ติดต่อ support@kagi.com

ความเห็นของ GN⁺

  • Kagi ประสบปัญหา latency ในการเขียนจากการแย่งกันใช้งานแถวในตารางผู้ใช้ ซึ่งสร้าง backpressure ให้กับ connection pool ของแอปพลิเคชันและนำไปสู่การหยุดให้บริการ
  • ปัญหานี้เป็นผลจากความเสี่ยงที่เกิดขึ้นเพราะ Kagi ใช้ฐานข้อมูลแบบ single-core ที่ถูกที่สุดบน GCP
  • จากเหตุการณ์ครั้งนี้ ทีม Kagi แสดงให้เห็นถึงความพยายามในการยกระดับเสถียรภาพและความโปร่งใสของบริการ ด้วยการเสริมระบบ ปรับปรุงการสื่อสารกับผู้ใช้ และตั้งข้อจำกัดอัตโนมัติเพื่อป้องกันการใช้งานในทางที่ผิด ความพยายามเหล่านี้สะท้อนถึงความตั้งใจของ Kagi ในการมอบบริการที่น่าเชื่อถือยิ่งขึ้นแก่ผู้ใช้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-18
ความคิดเห็นจาก Hacker News

  • ความเห็นเกี่ยวกับเหตุการณ์ที่เกิดขึ้นพร้อมกับการอัปเกรดโครงสร้างพื้นฐาน

    • เหตุการณ์ที่เกิดขึ้นพร้อมกับการอัปเกรดโครงสร้างพื้นฐานโดยเพิ่ม RAM ให้กับ VM นั้น เป็นเรื่องบังเอิญล้วนๆ
    • กล่าวว่าความ "บังเอิญ" แบบนี้เกิดขึ้นบ่อย และทำให้ระหว่างแก้ปัญหาถึงกับสงสัยในการมีอยู่ของตัวเอง
    • เตือนว่าหากตื่นตระหนกระหว่างแก้ปัญหา อาจออก hotfix ที่ไปทำให้ส่วนอื่นพังได้ ซึ่งอาจกลายเป็นกฎของเมอร์ฟีอันโหดร้ายสำหรับผู้ดูแลระบบและนักพัฒนา

  • ประสบการณ์ของผู้ใช้กับหน้าสถานะของ Kagi

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

  • คอมเมนต์ที่แชร์ประสบการณ์ส่วนตัว

    • แชร์ว่าเคยเจอการหยุดให้บริการประเภทเดียวกันนี้หลายครั้ง และพยายามแก้ปัญหาเกี่ยวกับสถานะสุขภาพของ database connection pool
    • ชี้ว่าตัวชี้วัดความอิ่มตัวของฐานข้อมูลทั่วไป เช่น CPU%, IOPS เป็นต้น มักแทบไม่เปลี่ยนระหว่างเหตุขัดข้องแบบนี้ และปัญหาอาจมาจาก lock contention แทน
    • เสนอว่า สำหรับ RDBMS ที่ Kagi ใช้งานอยู่ ควรทำกราฟของ global I/O latency, lock acquisition time และ query execution time เป็นต้น

  • คอมเมนต์เกี่ยวกับประสบการณ์ของสตาร์ทอัป

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

  • คอมเมนต์เกี่ยวกับการสังเกตการณ์ระบบภายใน

    • ชี้ว่าควรรับรู้ปัญหาให้เร็วกว่านี้ และ dashboard ของ Datadog กับ query ของ Splunk ที่ถูกต้องควรทำให้เห็นปัญหาได้ชัดเจนเร็วกว่านี้มาก
    • แนะนำว่าควรลงทุนกับการมอนิเตอร์ให้ดีขึ้น และใช้เรื่องนี้เป็นประสบการณ์ในการเรียนรู้

  • ความเห็นของผู้ใช้แบบชำระเงินเกี่ยวกับความน่าเชื่อถือของ Kagi

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

  • คอมเมนต์เกี่ยวกับ scraper ที่ทำให้บริการหยุดชะงัก

    • ต่อข้อเท็จจริงที่ว่าบริการหยุดชะงักนาน 7 ชั่วโมงเพราะ scraper ที่ผู้ใช้คนหนึ่งรันอยู่ มีการตั้งคำถามว่าระหว่างทดสอบไม่ได้ถามหรือว่า "ถ้ามีการค้นหาจำนวนมากจะเกิดอะไรขึ้น?"

  • คอมเมนต์เกี่ยวกับประสบการณ์การใช้ Kagi และบทวิเคราะห์หลังเหตุการณ์

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

  • คอมเมนต์เกี่ยวกับฐานข้อมูล single-core ที่ใช้บน GCP

    • มีปฏิกิริยาในเชิงบวกต่อข้อเท็จจริงที่ว่า Kagi ใช้ฐานข้อมูล single-core ที่ถูกที่สุดที่มีบน GCP
    • เสนอให้พิจารณาบางอย่างอย่าง PolyScale ที่อาจช่วยรองรับภาระการอ่านที่เพิ่มขึ้นอย่างรวดเร็วและดันประสิทธิภาพให้สูงขึ้นได้อีก

  • คอมเมนต์เกี่ยวกับ automated scraping

    • กล่าวถึงว่าผู้ใช้ที่ติดต่อกลับมาหลังจากบัญชีถูกระงับ อ้างว่าใช้บัญชีเพื่อ scrape ผลลัพธ์แบบอัตโนมัติ
    • แนะนำให้ตั้งขีดจำกัด QPS (queries per second) สำหรับทุก RPC / API / HTTP request ที่เข้ามา โดยเฉพาะคำขอแบบสาธารณะ