ถึงเวลาแล้วที่จะทิ้ง 'Leap Second' ไว้ในอดีต

xguru · 2022-07-26T10:39:48+09:00

อธิกวินาที (Leap Second) ถูกนำมาใช้เพื่อชดเชยความแตกต่างระหว่าง UT1 (เวลาสากล) และ UTC ที่เกิดจากความเร็วการหมุนของโลก สิ่งนี้ทำให้สามารถใช้ UTC สำหรับวัตถุประสงค์หลากหลาย เช่น การสังเกตการณ์ทางดาราศาสตร์ จึงเป็นประโยชน์หลักต่อบรรดานักวิทยาศาสตร์และนักดาราศาสตร์ หากไม่ปรับแก้ UTC ก็จำเป็นต้องปรับเทียบอุปกรณ์และซอฟต์แวร์แบบเลกาซีที่ซิงก์กับ UTC เพื่อการสังเกตการณ์ทางดาราศาสตร์ นับตั้งแต่มีการเสนออธิกวินาทีจนถึงปัจจุบัน UTC ถูกปรับทั้งหมด 27 ครั้ง ในปี 1972 อธิกวินาทีเป็นทางออกที่ยอมรับได้ซึ่งตอบโจทย์ทั้งวงการวิทยาศาสตร์และอุตสาหกรรมโทรคมนาคม แต่ปัจจุบัน UTC ในรูปแบบนี้ไม่ดีทั้งต่อแอปพลิเคชันดิจิทัลและนักวิทยาศาสตร์ → พวกเขามักเลือกใช้ TAI (International Atomic Time, เวลาปรมาณูสากล) หรือ UT1 แทน Meta สนับสนุนความพยายามของอุตสาหกรรมในการยุติการเพิ่มอธิกวินาทีในอนาคต และคงค่าปัจจุบันไว้ที่ 27 การเพิ่มอธิกวินาทีใหม่เป็นแนวปฏิบัติที่เสี่ยงและให้ผลเสียมากกว่าผลดี และถึงเวลาแล้วที่จะต้องนำเทคโนโลยีใหม่มาใช้แทน Leap of Faith หนึ่งในหลายปัจจัยที่ทำให้การหมุนของโลกไม่สม่ำเสมอ คือหิมะและน้ำแข็งถาวรบนภูเขาที่สูงที่สุดของโลกยังคงละลายและกลับมาแข็งตัวซ้ำไปมา เรื่องนี้มองภาพได้ง่ายหากนึกถึงนักสเก็ตลีลาที่กำลังหมุนตัว จนถึงตอนนี้มีแต่อธิกวินาทีแบบบวก ดังนั้นจึงเพียงแค่แทรกวินาทีพิเศษ 23:59:60 ระหว่าง 23:59:59 กับ 00:00:00 เท่านั้น แต่เมื่อรูปแบบการหมุนของโลกเปลี่ยนไป ก็มีแนวโน้มสูงว่าในอนาคตจะเกิดอธิกวินาทีแบบลบ ซึ่งจะทำให้หลัง 23:59:58 กลายเป็น 00:00:00 ทันที ผลกระทบของอธิกวินาทีแบบลบนี้ยังไม่เคยถูกทดสอบในระดับใหญ่ และอาจส่งผลร้ายแรงต่อซอฟต์แวร์ที่พึ่งพา timer หรือ scheduler Smearing ในช่วงหลังมานี้ แนวปฏิบัติที่นิยมคือค่อย ๆ "เกลี่ย" (Smear) อธิกวินาทีด้วยการทำให้นาฬิกาช้าลงหรือเร็วขึ้นทีละน้อย แม้จะไม่มีวิธีมาตรฐานสากลสำหรับทำเช่นนี้ แต่ที่ Meta จะทำการ Smear อธิกวินาทีตลอดช่วงเวลา 17 ชั่วโมงนับจาก 00:00:00 เนื่องจากมี NTP server หลายร้อยเครื่องทำงานร่วมกันที่ Stratum 2 หาก Smearing มากเกินไป NTP client อาจมองว่าเป็นความผิดพลาดและตัดออกจาก quorum ซึ่งอาจนำไปสู่ outage การเริ่มที่ 00:00:00 ก็ไม่ได้เป็นมาตรฐานเช่นกัน จึงอาจมีตัวเลือกได้หลายแบบ → ตัวอย่างเช่น บางบริษัทอาจเริ่มที่ 12:00:00 UTC แล้วดำเนินการต่อเนื่องเป็นเวลา 24 ชั่วโมง นอกจากนี้ตัว Smearing เองก็มีอัลกอริทึมหลายแบบ เช่น kernel leap second correction, Linear Smearing และ Quadratic (ที่ Meta ใช้อยู่) ทั้งหมดนี้ต้องอาศัยตรรกะการแปลงที่สำคัญ รวมถึง Time Appliance เฉพาะของ Meta หาก NTP server รีสตาร์ตระหว่างช่วง Smearing นี้ เวลาแบบ "Old" และ "New" อาจถูกส่งไปยัง client พร้อมกันและทำให้เกิด outage ได้ The negative impact of Leap Seconds อธิกวินาทีและค่าออฟเซ็ตของมันสร้างปัญหาให้กับทั้งอุตสาหกรรม วิธีที่ง่ายที่สุดที่จะทำให้เกิด outage คือการเขียนโค้ดโดยตั้งสมมติฐานว่าเวลาจะเดินไปข้างหน้าเสมอ start := time.Now() // do something spent := time.Now().Sub(start) ขึ้นอยู่กับว่า spent ด้านบนถูกนำไปใช้อย่างไร มันอาจกลายเป็นค่าติดลบได้ในช่วงที่มีอธิกวินาที Reddit เคยเกิดเหตุหยุดชะงักครั้งใหญ่ในปี 2012 เพราะอธิกวินาที ทำให้เว็บไซต์ไม่สามารถเข้าถึงได้เป็นเวลา 30~40 นาที Cloudflare ได้เผยแพร่ บทความอย่างละเอียด ในปี 2017 เกี่ยวกับผลกระทบที่มีต่อ DNS สาธารณะของบริษัท Moving beyond the leap second เหตุการณ์อธิกวินาทีก่อปัญหาทั่วทั้งอุตสาหกรรมและยังคงแฝงความเสี่ยงไว้อีกมาก ในการทำงานจริง เรามักเจอปัญหาทุกครั้งที่มีการเพิ่มอธิกวินาที และเพราะมันเป็นเหตุการณ์ที่เกิดขึ้นได้ยากมาก ทุกครั้งที่เกิดขึ้นจึงสร้างความเสียหายให้กับชุมชนอย่างหนัก เมื่อความต้องการด้านความแม่นยำของนาฬิกาเพิ่มขึ้นในทุกอุตสาหกรรม อธิกวินาทีจึงกลายเป็นสิ่งที่ให้ผลเสียมากกว่าผลดี และนำไปสู่ outage ในฐานะวิศวกรของ Meta เราสนับสนุนอย่างมากต่อการยุติการเพิ่มอธิกวินาทีในอนาคต และคงค่าปัจจุบันไว้ที่ 27 ซึ่งเชื่อว่าเพียงพอไปอีกพันปี

(engineering.fb.com)

15 คะแนน โดย xguru 2022-07-26 | 5 ความคิดเห็น | แชร์ทาง WhatsApp

อธิกวินาที (Leap Second) ถูกนำมาใช้เพื่อชดเชยความแตกต่างระหว่าง UT1 (เวลาสากล) และ UTC ที่เกิดจากความเร็วการหมุนของโลก
สิ่งนี้ทำให้สามารถใช้ UTC สำหรับวัตถุประสงค์หลากหลาย เช่น การสังเกตการณ์ทางดาราศาสตร์ จึงเป็นประโยชน์หลักต่อบรรดานักวิทยาศาสตร์และนักดาราศาสตร์
หากไม่ปรับแก้ UTC ก็จำเป็นต้องปรับเทียบอุปกรณ์และซอฟต์แวร์แบบเลกาซีที่ซิงก์กับ UTC เพื่อการสังเกตการณ์ทางดาราศาสตร์
นับตั้งแต่มีการเสนออธิกวินาทีจนถึงปัจจุบัน UTC ถูกปรับทั้งหมด 27 ครั้ง
ในปี 1972 อธิกวินาทีเป็นทางออกที่ยอมรับได้ซึ่งตอบโจทย์ทั้งวงการวิทยาศาสตร์และอุตสาหกรรมโทรคมนาคม แต่ปัจจุบัน UTC ในรูปแบบนี้ไม่ดีทั้งต่อแอปพลิเคชันดิจิทัลและนักวิทยาศาสตร์
→ พวกเขามักเลือกใช้ TAI (International Atomic Time, เวลาปรมาณูสากล) หรือ UT1 แทน
Meta สนับสนุนความพยายามของอุตสาหกรรมในการยุติการเพิ่มอธิกวินาทีในอนาคต และคงค่าปัจจุบันไว้ที่ 27
การเพิ่มอธิกวินาทีใหม่เป็นแนวปฏิบัติที่เสี่ยงและให้ผลเสียมากกว่าผลดี และถึงเวลาแล้วที่จะต้องนำเทคโนโลยีใหม่มาใช้แทน

Leap of Faith

หนึ่งในหลายปัจจัยที่ทำให้การหมุนของโลกไม่สม่ำเสมอ คือหิมะและน้ำแข็งถาวรบนภูเขาที่สูงที่สุดของโลกยังคงละลายและกลับมาแข็งตัวซ้ำไปมา
เรื่องนี้มองภาพได้ง่ายหากนึกถึงนักสเก็ตลีลาที่กำลังหมุนตัว
จนถึงตอนนี้มีแต่อธิกวินาทีแบบบวก ดังนั้นจึงเพียงแค่แทรกวินาทีพิเศษ 23:59:60 ระหว่าง 23:59:59 กับ 00:00:00 เท่านั้น แต่เมื่อรูปแบบการหมุนของโลกเปลี่ยนไป ก็มีแนวโน้มสูงว่าในอนาคตจะเกิดอธิกวินาทีแบบลบ
ซึ่งจะทำให้หลัง 23:59:58 กลายเป็น 00:00:00 ทันที
ผลกระทบของอธิกวินาทีแบบลบนี้ยังไม่เคยถูกทดสอบในระดับใหญ่ และอาจส่งผลร้ายแรงต่อซอฟต์แวร์ที่พึ่งพา timer หรือ scheduler

Smearing

ในช่วงหลังมานี้ แนวปฏิบัติที่นิยมคือค่อย ๆ "เกลี่ย" (Smear) อธิกวินาทีด้วยการทำให้นาฬิกาช้าลงหรือเร็วขึ้นทีละน้อย
แม้จะไม่มีวิธีมาตรฐานสากลสำหรับทำเช่นนี้ แต่ที่ Meta จะทำการ Smear อธิกวินาทีตลอดช่วงเวลา 17 ชั่วโมงนับจาก 00:00:00
เนื่องจากมี NTP server หลายร้อยเครื่องทำงานร่วมกันที่ Stratum 2 หาก Smearing มากเกินไป NTP client อาจมองว่าเป็นความผิดพลาดและตัดออกจาก quorum ซึ่งอาจนำไปสู่ outage
การเริ่มที่ 00:00:00 ก็ไม่ได้เป็นมาตรฐานเช่นกัน จึงอาจมีตัวเลือกได้หลายแบบ
→ ตัวอย่างเช่น บางบริษัทอาจเริ่มที่ 12:00:00 UTC แล้วดำเนินการต่อเนื่องเป็นเวลา 24 ชั่วโมง
นอกจากนี้ตัว Smearing เองก็มีอัลกอริทึมหลายแบบ เช่น kernel leap second correction, Linear Smearing และ Quadratic (ที่ Meta ใช้อยู่)
ทั้งหมดนี้ต้องอาศัยตรรกะการแปลงที่สำคัญ รวมถึง Time Appliance เฉพาะของ Meta
หาก NTP server รีสตาร์ตระหว่างช่วง Smearing นี้ เวลาแบบ "Old" และ "New" อาจถูกส่งไปยัง client พร้อมกันและทำให้เกิด outage ได้

The negative impact of Leap Seconds

อธิกวินาทีและค่าออฟเซ็ตของมันสร้างปัญหาให้กับทั้งอุตสาหกรรม
วิธีที่ง่ายที่สุดที่จะทำให้เกิด outage คือการเขียนโค้ดโดยตั้งสมมติฐานว่าเวลาจะเดินไปข้างหน้าเสมอ

start := time.Now()
// do something
spent := time.Now().Sub(start)

ขึ้นอยู่กับว่า spent ด้านบนถูกนำไปใช้อย่างไร มันอาจกลายเป็นค่าติดลบได้ในช่วงที่มีอธิกวินาที
Reddit เคยเกิดเหตุหยุดชะงักครั้งใหญ่ในปี 2012 เพราะอธิกวินาที ทำให้เว็บไซต์ไม่สามารถเข้าถึงได้เป็นเวลา 30~40 นาที
Cloudflare ได้เผยแพร่ บทความอย่างละเอียด ในปี 2017 เกี่ยวกับผลกระทบที่มีต่อ DNS สาธารณะของบริษัท

Moving beyond the leap second

เหตุการณ์อธิกวินาทีก่อปัญหาทั่วทั้งอุตสาหกรรมและยังคงแฝงความเสี่ยงไว้อีกมาก
ในการทำงานจริง เรามักเจอปัญหาทุกครั้งที่มีการเพิ่มอธิกวินาที
และเพราะมันเป็นเหตุการณ์ที่เกิดขึ้นได้ยากมาก ทุกครั้งที่เกิดขึ้นจึงสร้างความเสียหายให้กับชุมชนอย่างหนัก
เมื่อความต้องการด้านความแม่นยำของนาฬิกาเพิ่มขึ้นในทุกอุตสาหกรรม อธิกวินาทีจึงกลายเป็นสิ่งที่ให้ผลเสียมากกว่าผลดี และนำไปสู่ outage
ในฐานะวิศวกรของ Meta เราสนับสนุนอย่างมากต่อการยุติการเพิ่มอธิกวินาทีในอนาคต และคงค่าปัจจุบันไว้ที่ 27 ซึ่งเชื่อว่าเพียงพอไปอีกพันปี

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

galadbran 2022-07-26

ว้าว หัวข้อนี้น่าสนใจมากเลย! แต่เอ่อ… เข้าใจนะว่าการเพิ่มอธิกวินาทีเป็นเรื่องใหญ่ แต่ยังไม่ค่อยเข้าใจว่ากำลังทุ่มเทอย่างมากอะไรบ้างเพื่อคงไว้ที่ 27 วินาที

budlebee 2022-07-26

น่าจะหมายถึงสิ่งเหล่านี้

https://th.news.hada.io/topic?id=1752

dodok8 2022-07-26

ชื่อบทความดูแปลก ๆ

dodok8 2022-07-26

หัวข้อของข้อความที่บอตบน Twitter หรือ Slack ส่งมาดูปกติดี แต่พอไปดูบนเว็บไซต์กลับแปลก ๆ

xguru 2022-07-26

อ๊ะ เหมือนว่ามันมีอะไรแปลก ๆ อยู่ ผมเลยแก้ไขแล้วครับ