เรื่องเล่าว่า CTO เอาอาชีพเป็นเดิมพัน ลงไปถึงระดับบิตเพื่อแฮ็กฐานข้อมูลได้อย่างไร
(tech.devsisters.com)- เหตุขัดข้อง 36 ชั่วโมงของ CookieRun: Kingdom ที่ยาวนานที่สุดในประวัติศาสตร์ของ Devsisters
- ใช้ CockroachDB เป็นฐานข้อมูลแบบกระจายหลัก: 4 โหนด, สตอเรจ 12TB, รีพลิกา 7 ชุด
- ระหว่างงานขยายฐานข้อมูล มีโหนดล่มไปครึ่งหนึ่ง
- ส่งผลให้เกิดเหตุขัดข้องต่อทั้งบริการ และวิศวกรซัพพอร์ตฝั่ง CockroachDB ก็ตัดสินว่าไม่สามารถกู้คืนได้
- จึงเป็นบทความที่สรุปความพยายามต่างๆ ในการค้นหาข้อมูลที่ถูกเก็บอยู่ในสตอเรจด้วยตัวเอง
24 ความคิดเห็น
เป็นบทความที่มีประเด็นถกเถียงค่อนข้างมากเลยนะครับ..? ในแง่มุมของบริการจะเป็นอย่างไรไม่แน่ใจ แต่คิดว่านักพัฒนาที่ได้ลงมือทำงานนี้คงภูมิใจมากเลยครับ
ไม่แน่ใจว่าผู้ใช้ตอบรับกันอย่างไรบ้าง แต่ในฐานะผู้ใช้ ผมอยากให้คำชมหนึ่งเสียงตรงที่พยายามป้องกันการโรลแบ็กเซิร์ฟเวอร์.. แม้เมื่อคิดถึงการสูญเสียผู้ใช้และประสบการณ์ลูกค้าที่คงเกิดขึ้นตลอด 36 ชั่วโมง ความเสียหายอาจจะมากกว่าก็ได้ แต่ในมุมของนักพัฒนา ผมมองว่าเป็นความท้าทายที่น่าสนใจ ถ้าบริษัทนั้นไม่ใช่เกมแต่เป็นธนาคาร จะเป็นอย่างไรนะ?
ดูเหมือนว่า Pokémon Go จะใช้ Spanner ของ GCP (https://cloud.google.com/blog/topics/…) แต่ฝั่ง AWS ก็ไม่มีทางเลือกที่เหมาะสมเท่าไรนัก
เมื่อพิจารณาจากเจตนาของทีมพัฒนาบนพื้นฐานของเอกสารดังกล่าว ก็เห็นได้ว่าในโปรเจกต์นั้นไม่ควรใช้ CockroachDB ตั้งแต่แรกครับ
ควรใช้ DB อะไรดี?
ขึ้นอยู่กับบริการ เนื้อหานี้อาจทำให้รู้สึกขนลุกได้เลยนะครับ
อ่านสนุกมากครับ
ดูเหมือนว่าบล็อกนั้นจะลงบทความเป็นชุดเกี่ยวกับเหตุขัดข้องครั้งนี้ไว้ ผมลองอ่านต่อเนื่องแล้วก็รู้สึกประทับใจมากกับอาการสติแตกที่คนซึ่งกำลังกู้สถานการณ์นั้นคงต้องเจอ
ผม/ฉันก็ไม่ค่อยแน่ใจนักว่า ในเชิงธุรกิจ การเลือกกู้คืนข้อมูลผู้ใช้ทั้งหมดตลอด 36 ชั่วโมงนั้นเป็นการตัดสินใจที่ถูกต้องกว่าการโรลแบ็กซึ่งทำลายประสบการณ์ของผู้ใช้บางส่วนเพื่อปกป้องผู้ใช้ส่วนใหญ่หรือไม่ แต่ในมุมมองของนักพัฒนา เนื้อหานี้ก็น่าสนใจครับ/ค่ะ
มีเนื้อหาแบบนี้อยู่ในบทความ
ภารกิจของเราคือมอบประสบการณ์ที่ดีที่สุดให้ลูกค้า และเราได้พยายามอย่างจริงใจเพื่อทำสิ่งนี้ให้เกิดขึ้น ไม่มีใครท้อแท้หรือยอมแพ้เลย
น่าตกใจที่มาได้ยินคำพูดทำนองว่าเพื่อเงินแล้วทิ้งผู้ใช้บางส่วนไปก็ได้ที่นี่ด้วย ทำให้รู้สึกได้อีกครั้งถึงวิธีที่วงการเกมเกาหลีปฏิบัติต่อผู้เล่น
นั่นดูเหมือนจะตีความแบบบิดเกินไปหน่อย และถ้ามองจากผลลัพธ์แล้ว หากแก้ปัญหาไม่ได้ก็เท่ากับเสียเวลาไปเปล่า ๆ แถมยังต้องโรลแบ็กเซิร์ฟเวอร์และโดนคนบ่นอยู่ดี
อีกทั้งในมุมมองที่ว่าเมื่อให้บริการไม่ได้ ก็เท่ากับทอดทิ้งผู้ใช้ในช่วงเวลานั้นด้วย ก็ยังเป็นเรื่องเดียวกันครับ
เห็นด้วยอย่างแรงมากๆ...
ในมุมมองของนักพัฒนา ผมอ่านแล้วรู้สึกน่าสนใจมาก (รวมถึงพาดหัวที่ชวนกระตุ้นด้วย) และผมเองก็มองเรื่องนี้ในมุมคล้ายกันครับ แม้จะเป็นเนื้อหาที่ถูกกล่าวถึงในบทความเมื่อสักพักแล้วจึงอาจต่างจากความเป็นจริงอยู่บ้าง แต่เหมือนว่า Cookie Run: Kingdom จะมีรายได้เกิน 3 แสนล้านวอน ดังนั้นก็น่าจะเป็นการตัดสินใจโดยเปรียบเทียบระหว่างการแปลงเวลาหยุดให้บริการ 36 ชั่วโมงเป็นรายได้ที่คาดว่าจะสูญเสีย กับมูลค่าค่าชดเชยหลังการโรลแบ็ก
ผมคิดว่าการเป็นองค์กรที่มีวัฒนธรรมนักพัฒนาซึ่งให้ความสำคัญกับการแก้ปัญหาอย่างมาก ก็น่าจะมีอิทธิพลต่อเรื่องนี้อยู่พอสมควร
ถ้าเป็นผมเองจะตัดสินใจแบบไหน ตอนนี้ก็ยังไม่แน่ใจเหมือนกันครับ
ทุกวันนี้ในเกมต่าง ๆ (โดยเฉพาะเกมที่มีระบบสุ่มกาชา) การโรลแบ็กคือ...เป็นวิธีที่ใช้ได้เฉพาะในกรณีเลวร้ายที่สุดจริง ๆ... เว้นแต่ว่าจะเป็นเกมค่าย L ที่ไม่ค่อยใส่ใจภาพลักษณ์แบบนั้น ไม่อย่างนั้นก็แทบเป็นไปไม่ได้ โดยเฉพาะในกรณีนี้กลับกลายเป็นว่าเพราะไม่โรลแบ็กแล้วไปให้การชดเชยหนัก ๆ ภายหลัง ผู้เล่นก็เลยถึงกับล้อกันว่า ถ้าทรัพยากรไม่พอ เซิร์ฟเวอร์จะระเบิดอีกรอบไหมนะ? อะไรทำนองนั้นกันด้วยซ้ำ... ผมมองว่าเป็นการตัดสินใจที่ถูกต้องครับ
เพราะเป็นเกม ถ้าย้อนกลับไป 36 ชั่วโมงก่อนก็คงมีโอกาสเกิดความเสียหายทางการเงินจากเรื่องแคชได้มากเหมือนกัน
ขอลงคะแนนว่าไม่น่าจะเป็นการตัดสินใจที่ถูกต้องในเชิงธุรกิจ
ความผิดพลาดในการตั้งค่าที่ไม่ได้ตั้งใจ (นี่คือ human error ที่วิกฤตที่สุดและน่าเหลือเชื่อที่สุด ทำให้ replica ทำงานไม่ได้ด้วยการกระทำร้ายแรงแบบนี้ ต่อให้พานักพัฒนาออกแบบ db มาทั้งหมดก็ยังกู้คืนอันนี้ไม่ได้)
ดังนั้นเพราะจะปล่อยให้ข้อมูลหายไปทั้งหมดไม่ได้... จึงต้องยอมทิ้ง data consistency ล่าสุด แล้วไปค้นหาข้อมูล DB ในรูปแบบไบนารีที่ถูกบันทึกไว้ล่าสุดโดยตรง (7 TB) และเขียนโปรแกรม go เพื่อแปลงสิ่งนี้เป็น csv... ?
การทำโปรแกรม go สำหรับแปลงข้อมูลนี้ ต่อให้ทำออกมาดีแค่ไหน มันจะมีความหมายอะไรนักนะ.. เฮ้อ.. แค่คิดก็อึดอัดแล้ว ทำไมถึงต้องกลายเป็นแบบนี้ด้วย.. คงสำคัญที่สุดที่จะต้องเสริมความเข้มงวดของ process เพื่อไม่ให้เกิด human error แบบนี้อีก อย่าเล่าเรื่องที่ต้องลำบากแปลงไบนารีระหว่างรับมือ incident เลย
มีเหตุผลอื่นอีกหรือที่ไม่ควรเล่าเรื่องแบบนี้? การเปิดเผยโพสต์มอร์เท็มนั้นมีความหมายในตัวมันเองอยู่แล้วนี่ครับ
ในความเห็นของผม ถ้าจะเขียนบทความที่เป็นประโยชน์จริง ๆ ชื่อเรื่องน่าจะต้องเป็นแบบนี้ไม่ใช่หรือครับ?
"วิเคราะห์สาเหตุและบทเรียนจากข้อผิดพลาดที่ทำให้คลัสเตอร์ใช้งานไม่ได้ เนื่องจากตั้งค่าโหนดผิดพลาด"
เรื่องแบบนั้นแยกไปเขียนต่างหากก็ได้อยู่แล้ว และ “การวิเคราะห์สาเหตุของเหตุขัดข้อง” กับ “กระบวนการแก้ไขเหตุขัดข้อง” ก็เป็นคนละประเด็นกัน และทั้งคู่ก็เป็นเรื่องสำคัญ แต่การลดทอนคุณค่าของบทความเพียงเพราะไม่มี “การวิเคราะห์สาเหตุของเหตุขัดข้อง” นี่เข้าใจได้ยากจริง ๆ...
ถ้าจะบอกว่าถ้ามีบทความวิเคราะห์สาเหตุออกมาตามต่ออีกก็น่าจะยิ่งดี แบบนั้นก็พูดได้ แต่การบอกว่าไม่มีคุณค่าก่อนจะพูดแบบนั้น ไม่ใช่ท่าทีที่ดีนักครับ
พูดอย่างเคร่งครัดแล้ว มันไม่ใช่ 'กระบวนการแก้ไขเหตุขัดข้อง' แต่เป็นกระบวนการ "ลงแรงกู้คืนข้อมูลที่ไม่สมบูรณ์" มากกว่า แค่ลดขอบเขตความเสียหายลงได้บ้าง? ประมาณนั้นครับ
ตรงไหนของบทความด้านบนที่บอกว่าการกู้คืนข้อมูลนั้น “ไม่สมบูรณ์”? อย่างน้อยจากเนื้อหาในบทความข้างต้นก็บอกว่ากู้คืนได้สำเร็จอย่างสมบูรณ์นะครับ แล้วการกู้คืน DB ที่ทำพังไป ถ้าไม่ใช่การแก้เหตุขัดข้องแล้วจะเรียกว่าอะไร? หลังจากเหตุการณ์นั้น บริการดังกล่าวได้ยุติการให้บริการไปเลยหรือครับ?
นั่นไม่ใช่เหตุผลที่จะไม่เล่าเรื่องนี้นะครับ?
ชีวิตนี่ช่างลำบากจริง ๆ สำหรับคุณนะ