การวิเคราะห์หลังเหตุการณ์กรณี Kagi เมื่อสัปดาห์ที่แล้ว
(status.kagi.com)การแก้ไขปัญหาความไม่เสถียรของบริการ 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 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนแรกพบว่า การอัปเกรดโครงสร้างพื้นฐาน ที่เพิ่ม RAM ให้ VM เกิดขึ้นตรงกับช่วงเวลาที่ระบบล่มาพอดีเป็นเรื่องบังเอิญล้วน ๆ แต่ “เรื่องบังเอิญ” แบบนี้เกิดขึ้นบ่อยมากจนระหว่างตามหาสาเหตุ คุณจะเริ่มสงสัยแม้กระทั่งการมีอยู่ของมันเอง
พออยู่ในสภาพตื่นตระหนก สุดท้ายก็มักจะผลัก hotfix เข้าไปจนทำอย่างอื่นพังตาม และหลังจากนั้นทุกอย่างจะยิ่งเจ็บปวดกว่าเดิม
กฎของเมอร์ฟี โหดร้ายกับผู้ดูแลระบบและนักพัฒนา
มีคำพูดหนึ่งที่ผมชอบ: “ถ้าคุณไม่รู้ว่าทำไม/อย่างไรถึงแก้ได้ ก็อาจแปลว่าคุณยังไม่ได้แก้จริง ๆ”
“โชคดี” ที่มันไม่เกี่ยวกับคิวรีของผม แต่พอความบังเอิญสองอย่างมาซ้อนกัน มันน่ากลัวมากจริง ๆ
พอเจอเรื่องแบบนี้มามากพอ ก็เริ่มมีนิสัยตั้งข้อสงสัยกับสมมติฐานมากขึ้น และไม่ติดป้ายสิ่งที่ยังไม่ยืนยันว่าเป็น ข้อมูลที่ยืนยันแล้ว
มันไม่ได้ทำให้ความลำเอียงหรือการด่วนสรุปหายไปหมด แต่ช่วยได้ และการรักษาใจให้เปิดกว้างก็เป็นเรื่องค่อนข้างยาก
ความสามารถสำคัญของวิศวกรคือการ ให้เหตุผลเชิงวิพากษ์ กับการเปลี่ยนแปลงที่ทำระหว่างรับมือเหตุขัดข้อง ดีบักมัน และ “แยกออกมาทดสอบ” ได้ ซึ่งยากกว่าที่เห็นมาก และมักเป็นทักษะระดับซีเนียร์
ผมเป็นหนึ่งในผู้ใช้ที่รายงานปัญหานี้ใน Discord ผมชอบ Kagi แต่ค่อนข้างผิดหวังที่หน้าแสดงสถานะยังบอกว่าทุกอย่างปกติ
แม้มีเหตุขัดข้องที่กระทบผู้ใช้จริง หน้าแสดงสถานะ ก็ดูเหมือนไม่ใช่สิ่งที่ถูกให้ความสำคัญ ทำให้รู้สึกไม่สบายใจ และหวังว่าต่อไปจะอัปเดตได้แม่นยำกว่านี้
บริการที่ผมเคยพึ่งพามากในอดีต เช่น GitHub จะอัปเดตหน้าแสดงสถานะทันที ทำให้ผมสบายใจได้ว่า ปัญหาไม่ได้อยู่ที่อุปกรณ์ของผม แต่เป็นปัญหาที่ฝั่งบริการรับรู้แล้ว
ครั้งนี้วันนั้นผมต้องหาร้านขายของชำใกล้บ้านที่ยังเปิดก่อนหิมะตก สุดท้ายเลยต้องกลับไปใช้ Google ซึ่งก็ผิดหวังนิดหน่อย
ถึงอย่างนั้น 99.9% ของเวลาที่ใช้ Kagi มันดีกว่า Google อยู่แล้ว ผมก็ยังจะใช้ต่อ และหวังว่าตามที่บอกไว้ใน postmortem พวกเขาจะย้ายโค้ดของหน้าแสดงสถานะไปไว้บนบริการ/แพลตฟอร์มอื่น
สุดท้ายแล้ว แค่การจะโพสต์อะไรสักอย่างลงหน้าแสดงสถานะก็กลายเป็นบทสนทนาหนึ่งขึ้นมาเอง และบทสนทนานั้นก็กินทั้งเวลาและความสนใจของวิศวกร ซึ่งยิ่งทำให้การแก้เหตุขัดข้องช้าลง
ต้องคอยหาสมดุลระหว่าง การสื่อสาร กับการกู้ระบบจริง ๆ และคำตอบที่ถูกต้องก็ไม่ได้ชัดเจนเสมอไป
ถ้ามีคนพอ อาจให้ Technical Incident Manager รับหน้าที่สื่อสาร และเพิ่มวิศวกรไปช่วยด้านคอมมูนิเคชันได้ แต่ก็ไม่ได้ทำได้เสมอไป บางระบบก็เฉพาะทางมาก เอกสารมีน้อย และระบบวัดผลก็ไม่เพียงพอ
โดยส่วนตัวผมชอบวิธีประกาศกว้าง ๆ และคลุมเครือก่อนเลยว่า “กำลังตรวจสอบความเป็นไปได้ของปัญหา” ทันทีที่เห็นสัญญาณผิดปกติ แล้วค่อยเติมรายละเอียดทีหลังหรือถอนประกาศภายหลัง แต่บริษัทที่ผมเคยทำงานด้วยไม่ค่อยชอบแนวคิดนี้
ตอนนั้นผมเลยเริ่มสนใจ Kagi อย่างจริงจัง และสลับใช้กับบางคำค้นอยู่พักหนึ่ง แต่พอ LLM, Perplexity และ Google เริ่มตอบคำถามให้ได้เลยบนหน้าค้นหาเองมากขึ้น คำค้นที่เหลือให้ Kagi ใช้ก็มีไม่มากแล้ว
ถ้า Kagi รวมกับ Perplexity ได้ไม่ทางใดก็ทางหนึ่งก็น่าจะน่าสนใจมาก
หลายกรณีถึงขั้นไม่แสดงเลยจนจบ
เหตุขัดข้องแบบนี้คุ้นเคยจนชวนตกใจมาก
ส่วนตัวผมเคยรับมือเหตุขัดข้องชนิดเดียวกันนี้หลายครั้งมากจนแทบไม่อยากยอมรับ และก็เคยลองมาตรการบรรเทาแบบเดียวกับทีม Kagi เช่น ตกลงไปในโพรงกระต่ายของ สถานะ connection pool ของฐานข้อมูล แล้วเชื่อว่าถ้าเพิ่มอินสแตนซ์ใหม่เข้าไปหรือ “รีเซ็ต” ทราฟฟิกก็คงหาย แต่สุดท้ายก็เสียแรงเปล่า
สิ่งที่ไม่ช่วยเลยคือ ในเหตุขัดข้องแบบนี้ เมตริกการอิ่มตัวทั่วไปของฐานข้อมูลอย่างการใช้ CPU, IOPS มักแทบไม่ขยับ คุณจะเห็นแค่ latency ของคิวรีสูงขึ้น แล้วก็คิดว่า “แต่ CPU กับ IOPS ยังเหลือนะ…” ก่อนจะพลาดไม่เห็นว่าต้นเหตุจริงคือ lock contention ที่ซ่อนอยู่ตามเคย
จากประสบการณ์ของผม ความผิดปกติของ connection pool ฝั่ง DB 98% มีที่มาจากความผิดปกติของ DB เอง ผมไม่รู้ว่า Kagi ใช้ฐานข้อมูลเชิงสัมพันธ์ตัวไหน แต่ขอแนะนำอย่างยิ่งให้ทำกราฟเวลารอ I/O รวมของ DB (วินาที/วินาที), เวลาการได้มาซึ่ง lock รวม (วินาที/วินาที) และเวลาการรันแยกตาม normalized query (วินาที/วินาที)
ถ้าเพิ่มกราฟการใช้ CPU เข้าไปด้วย ก็จะกลายเป็นแดชบอร์ดที่ช่วยระบุปัญหาประสิทธิภาพขนาดใหญ่ส่วนใหญ่ได้อย่างรวดเร็ว
อีกเรื่องหนึ่ง การที่คำค้นหาทำให้เกิดการเขียนลงฐานข้อมูลเชิงสัมพันธ์ก็ค่อนข้างน่าแปลกใจ ผมคิดว่าฐานข้อมูลเชิงสัมพันธ์น่าจะใช้แค่กับพวกการตั้งค่าผู้ใช้ การจัดการล็อกอิน อะไรแบบนั้น
ถ้า Kagi กำลังนับการใช้งาน เช่น การเพิ่มค่าเคาน์เตอร์ บนฐานข้อมูลเชิงสัมพันธ์อยู่ นี่ก็เป็นรูปแบบความล้มเหลวที่คลาสสิกมากเมื่อระบบเริ่มขยายขนาด
อาจมีการเขียนทางอ้อมจากการค้นหาได้ เช่น เวลาบล็อกผลลัพธ์การค้นหา และแน่นอนว่าก็อาจมีประวัติการเข้าชมหรือการวิเคราะห์ข้อมูลด้วย
ถึงอย่างนั้น ก็ยังไม่ชัดเจนว่าอะไรที่จะทำให้เกิด การแข่งขันแย่ง lock ตอนเขียน จากการค้นหาเพียง 1 ครั้ง
นี่เป็นเรื่องที่สตาร์ทอัพทุกแห่งต้องเจอสักวันหนึ่ง เคยเจอกับตัวแล้วและมันเจ็บปวดมาก
บางครั้งก็ไม่มีเวลาหรือทรัพยากรมากพอจะสร้างความสามารถเพื่อป้องกันปัญหาแบบนี้ และบางทีก็ไม่ได้นึกเลยว่าปัญหาบางอย่างอาจเกิดขึ้นได้ จนมาโดนเข้าแบบไม่ทันตั้งตัว
ความโปร่งใสสำคัญ และการเรียนรู้ก็สำคัญ แต่บางครั้งการชดเชยก็สำคัญเช่นกัน Kagi ควรพิจารณาให้ search credits สำหรับช่วงเวลาที่ใช้งานบริการไม่ได้
ยิ่งควรทำเช่นนั้นเมื่อพวกเขายอมรับเองว่าการตอบสนองแบบเรียลไทม์ยังไม่ดีพอ
เหตุขัดข้องของบริการแบบเสียเงินไม่เหมือนกับเหตุขัดข้องของบริการที่ “ผู้ใช้คือสินค้า”
เรื่องนี้สะท้อนให้เห็นหลายอย่างเกี่ยวกับระดับของ observability ที่มีอยู่ในระบบภายใน
พูดได้ง่ายว่าควรจะรู้ตัวให้เร็วกว่านี้ แต่ถ้ามี Datadog dashboard และ Splunk query ที่เหมาะสม ก็น่าจะเห็นได้ชัดเจนเร็วกว่านี้มาก
หวังว่าจะใช้เหตุการณ์นี้เป็นโอกาสในการเรียนรู้และลงทุนกับ monitoring ที่ดีกว่าเดิม
เหตุการณ์นี้เป็นประสบการณ์เพื่อการเรียนรู้ 100% แต่ผมพอจะให้บริบทเกี่ยวกับ observability เพิ่มได้อีกนิด
Kagi เป็นทีมเล็ก และคนที่ตอบสนองต่อเหตุการณ์แบบนี้ได้จริง ๆ มีอยู่เพียง 3 คน ซึ่งกระจายกันอยู่ 3 เขตเวลา นี่เป็นช่วงแรก ๆ ของอาชีพสายเว็บของผมและนักพัฒนาหลักอีกคน ดังนั้นเราไม่ใช่ซิลิคอนแวลลีย์รุ่นเก๋าที่ผ่านอะไรแบบนี้มาหมดแล้ว
แน่นอนว่าเรายังต้องเรียนรู้อีกมาก แต่เราก็ภูมิใจกับเส้นทางที่พา Kagi มาจากศูนย์จนถึงตอนนี้ และกับทิศทางที่กำลังจะไปต่อ
เราเริ่มให้ความสำคัญกับ observability อย่างจริงจังมากขึ้นตั้งแต่ราว 6 เดือนที่ผ่านมา ตอนนี้มี dashboard จำนวนมากแล้ว รวมถึง alert ที่ส่งตรงเข้า company chat channel พร้อมเรียกคนที่เกี่ยวข้องได้ทันที
ในฐานะคนที่ดูแล DB เป็นหลัก GCP Query Insights มีประโยชน์มาก ระหว่างเหตุขัดข้อง monitoring ก็แจ้งเตือน และ Query Insights ก็ชี้ให้เห็น query ที่เป็น “ตัวการ” แต่ถึงจะมี monitoring ครบทุกอย่างในโลก ก็อาจยังขาดประสบการณ์ในการตีความ root cause หรือวิธีบรรเทาที่มีประสิทธิภาพที่สุด
พูดอีกอย่างคือ เรายังขาดวิจารณญาณมากพอที่จะไม่โดนสิ่งที่ระบบของเราแสดงอยู่ gaslight เอาได้ถ้าไม่ระวัง ย้อนกลับไปดูแล้วผมบอกได้ว่า GCP Query Insights ถูกต้อง 100% และปัญหาไม่ได้เป็นบั๊กในฝั่ง application
การเติบโตทำให้ตอนนี้เราขยายทีมได้พอสมควรแล้ว ก่อนหน้านี้ก็เคยใช้ SRE consulting และต่อจากนี้ก็จะรับการสนับสนุนเพิ่มทั้งแบบ full-time หรือ part-time เพื่อปรับปรุงต่อไป
หมายความว่าผู้ใช้คนเดียวรัน scraper แล้วทำให้บริการล่มไป 7 ชั่วโมงเลยเหรอ? จะบอกว่า “น่าจะคาดไว้ได้สิ” จากคนนอกมันก็ง่ายอยู่หรอก แต่ก็ยังแปลกที่ตอนทดสอบไม่มีใครถามว่า “ถ้ามีการค้นหาเกิดขึ้นมหาศาลจะเป็นยังไง?”
https://news.ycombinator.com/item?id=39019936
สรุปคือเรามีบุคลากรหลักน้อยมาก เป็นทีมที่อายุน้อย และทุกคนต้องสวมหลายหมวกพร้อมกัน เรายังไม่มีทีม SRE โดยเฉพาะ
ส่วนคำถามว่า “ถ้ามีการค้นหาเกิดขึ้นมหาศาลจะเป็นยังไง?” นั้น ถ้าดูที่ https://kagi.com/stats จะเห็นว่ามี “การค้นหาจำนวนมาก” อยู่แล้ว และกำลังเข้าใกล้วันละ 400,000 ครั้ง ตามปกติระบบก็ทำงานได้โดยยังมีเผื่อ capacity มากพอ และก็มีมาตรการ auto-scaling บางส่วน
ปัญหาอยู่ที่รายละเอียดซึ่งผู้ใช้บางรายสามารถใช้ประโยชน์จาก กรณีสุดโต่ง ได้ เราแค่ยังไม่มีประสบการณ์พอจะรู้ว่าควรคาดการณ์และจำลอง traffic แบบธรรมชาติหรือ traffic แบบสุดโต่งบางอย่างล่วงหน้าอย่างไร
การจำลองโหลดผู้ใช้ค้นหาพร้อมกัน 20,000 คน ฟังดูเหมือนการทดลองที่น่าทำในช่วงแรก และเราก็ทำอะไรคล้าย ๆ กันไปบ้าง แต่เมื่อดูจากเหตุขัดข้องครั้งนี้ ก็น่าจะยังจับปัญหานี้ไม่ได้อยู่ดี
จนถึงตอนนี้เคยมีคนรัน security scanner ใส่บริการ production ของเราประมาณ 10 ครั้ง และ traffic ที่เกิดขึ้นตอนนั้นมากกว่าครั้งนี้อีก
การหาสมดุลของงานพัฒนาแบบนี้ในขณะที่ยังต้องสร้างฟีเจอร์ไปด้วยเป็นเรื่องยากมาก และแน่นอนว่าเราควรทำให้มากกว่านี้ อย่างที่ผมพูดไว้ในโพสต์อื่น เราวางแผนจะขยายทีมในเร็ว ๆ นี้เพื่อไม่ให้ความพยายามแบบนี้บางเกินไปอีก
มองย้อนกลับไปก็มีหลายอย่างที่พูดได้ แต่ผมหวังว่าเราจะสื่อสารได้โปร่งใสมากขึ้นว่าพวกเรามาถึงจุดนี้ได้อย่างไร
ยิ่งถ้าเป็นครั้งแรกที่มีคนโจมตีในรูปแบบนั้นก็ยิ่งเข้าใจได้
ถ้าเทียบกัน ระบบที่ผมดูแลไม่ถึงระดับ FAANG แต่ในแง่อัตราคำขอนั้นใหญ่กว่า Kagi แน่ ๆ Kagi ก็คงจะเรียนรู้ได้เร็ว และระหว่างทางถ้ายังมีปัญหาแบบนี้เกิดขึ้นอีกบ้าง ผมกลับคิดว่าก็พอยอมรับได้ในระดับหนึ่ง มันยังเป็นสัญญาณว่ากำลังเดินไปในทิศทางที่ถูกต้องด้วย
ในฐานะผู้ใช้ Kagi แบบเสียเงิน พอเจอ downtime แล้วก็เพิ่งรู้ว่าตัวเองมองข้าม ความน่าเชื่อถือ ของ Google ไปมากแค่ไหน
ตลอด 20 ปีที่ผ่านมา Google แทบไม่เคยล่มสำหรับผมเลย ยกเว้นสักครั้งหนึ่ง การเสียการเข้าถึง search engine เป็นเรื่องกระทบหนักพอสมควร
ผมชอบ Kagi มากจนยอมจ่ายเงิน แต่การเจอ downtime ตั้งแต่เดือนที่สองของการใช้งานก็ทำให้รู้สึกไม่สบายใจพอสมควร ผมชอบอ่าน postmortem นะ แต่ก็หวังว่าจะไม่ต้องมีอะไรให้ได้อ่าน
ถึงอย่างนั้นก็หวังว่าประสบการณ์ครั้งนี้จะทำให้ Kagi กลายเป็นบริการที่ทนทานและเชื่อถือได้มากขึ้น
search engine ไม่ใช่บริการที่มี lock-in แบบผู้ให้บริการอีเมลหรือ ISP
เห็นได้ชัดว่าผมพึ่งพา Kagi มากในเรื่องความเร็วและการใช้งานได้ดีทุกที่
ทำให้นึกถึงตอนที่บริษัทลูกค้ากำลังรัน proof of concept ของเครื่องมือ networking ตัวใหม่ พอรันไปได้สัก 2 นาที network ทั้งหมดของลูกค้าก็ดับลง
พวกเราอยู่ใน sandbox zone ที่แยกออกมา ดังนั้นไม่มีทางที่ผลิตภัณฑ์ของเราจะทำให้ network ทั้งระบบล่มได้ แต่ในหัวผมก็ยังคิดว่า “คงไม่ใช่หรอก ใช่ไหม... ใช่ไหม?!?!”
“ภายหลังเราได้ติดต่อกับบัญชีที่ถูกบล็อกนั้น และบัญชีนั้นอ้างว่าได้ใช้บัญชีเพื่อสแครปผลลัพธ์ของเราแบบอัตโนมัติ ซึ่งเป็นสิ่งที่ข้อกำหนดการใช้งานไม่อนุญาต”
ต้องใส่ การจำกัด QPS ให้กับคำขออินพุต RPC/API/HTTP ทุกแบบเท่าที่ทำได้ โดยเฉพาะคำขอแบบสาธารณะ
มีฟังก์ชันค้นหาที่มีระบบเติมคำอัตโนมัติอยู่ และเพื่อรองรับผู้ใช้ที่พิมพ์เร็ว เราจงใจเอาการจำกัดความเร็วของเอนด์พอยต์นั้นออก
เช้าวันหนึ่งราว 6 โมง มีใครบางคนใน Tennessee มาเริ่มงานแล้ววางกระเป๋าสตางค์ไว้บนคีย์บอร์ด ทำให้มันกดคีย์ค้างไว้ และเริ่มยิง API ทุกครั้งที่มีการกดแป้น
ตามคาด พอผ่านไปราว 15 นาที DB ก็เริ่มไม่เสถียรอย่างมาก และความหน่วงของ DB สูงจนเว็บเซิร์ฟเวอร์เครื่องหนึ่งล่ม เกิดความขัดข้องต่อเนื่องตามมา จนคลัสเตอร์ระบบโปรดักชันทั้งหมดล่ม
ไม่ต้องบอกก็รู้ว่าวันนั้นได้ใส่ การจำกัดความเร็ว กลับเข้าไปใหม่