กำลังเตรียมประสบการณ์ดิจิทัล
เมื่อแก้ระเบียน DNS หรือเปิดฟีเจอร์ของโดเมน ทุกวินาทีที่รอให้ค่าใหม่มีผลคือช่วงที่เว็บอาจชี้ไปผิดที่ Cloudflare ลดเวลานี้ (ค่ามัธยฐาน) จากราว 7.7 วินาทีเหลือ 3.3 วินาที ลดช่วงช้าที่สุดจาก 14.6 นาทีเหลือ 1.2 นาที และลดหน่วยความจำของระบบลง 85% ด้วยหลักคิดเดียว คือสร้างใหม่เฉพาะส่วนที่เปลี่ยน แทนการสร้างข้อมูลทั้งโซนใหม่ทุกครั้ง บทความนี้สรุปว่าออกแบบอย่างไรให้เร็วขึ้นโดยข้อมูลไม่ผิด
เมื่อแก้ระเบียน DNS หรือเปิดฟีเจอร์ของโดเมน ทุกวินาทีที่รอให้ค่าใหม่มีผลคือช่วงที่เว็บอาจชี้ไปผิดที่ Cloudflare ลดเวลานี้ (ค่ามัธยฐาน) จากราว 7.7 วินาทีเหลือ 3.3 วินาที ลดช่วงช้าที่สุดจาก 14.6 นาทีเหลือ 1.2 นาที และลดหน่วยความจำของระบบลง 85% ด้วยหลักคิดเดียว คือสร้างใหม่เฉพาะส่วนที่เปลี่ยน แทนการสร้างข้อมูลทั้งโซนใหม่ทุกครั้ง บทความนี้สรุปว่าออกแบบอย่างไรให้เร็วขึ้นโดยข้อมูลไม่ผิด
ทุกการเปลี่ยนแปลง DNS ของลูกค้าจะไหลผ่าน Kafka (ระบบคิวข้อความ) ไปยังบริการชื่อ Zone Builder ที่แปลงข้อมูลเป็นคีย์แล้วเขียนลง Quicksilver ฐานข้อมูลแบบคีย์-ค่าที่กระจายไปทุกศูนย์ข้อมูล การแก้ระเบียนทีละรายการมีทางลัดอยู่แล้ว แต่การเปลี่ยนค่าระดับโซน เช่น เปิดใบรับรอง SSL อัตโนมัติ ยังต้องสร้างข้อมูลใหม่ทั้งโซน ปริมาณงานเพิ่มจากราว 250 เป็น 700 การเปลี่ยนแปลงต่อวินาทีตั้งแต่ปี 2022 และบางโซนมีระเบียนเกิน 20 ล้านรายการ การสร้างใหม่ทั้งโซนจึงทั้งช้าและกินหน่วยความจำมหาศาล
ระบบต้นทางส่งรายละเอียดมากับเหตุการณ์ด้วยว่าเปลี่ยนช่องไหน จากค่าอะไรเป็นค่าอะไร ตัววางแผนใช้ข้อมูลนี้เลือกขนาดงาน และมีกติกาสำคัญข้อเดียวคือ ถ้าไม่แน่ใจ ให้ทำงานมากขึ้น ไม่ใช่น้อยลง เหตุการณ์ที่ข้อมูลไม่ครบหรือไม่รู้จักจึงตกไปเป็นการสร้างใหม่ทั้งโซนเสมอ
| แบบ | สร้างใหม่อะไร | ใช้เมื่อ |
|---|---|---|
| เฉพาะชื่อ | ระเบียนของชื่อที่เปลี่ยน | แก้ระเบียนทั่วไป |
| ชื่อ + ข้อมูลกลาง | ชื่อที่เปลี่ยนและคีย์ข้อมูลกลางของโซน | เปลี่ยน nameserver หรือ wildcard |
| ยอดโซน + ข้อมูลกลาง | ชื่อโดเมนหลักและข้อมูลกลาง | เปลี่ยนค่าระดับโซน เช่น SSL อัตโนมัติ |
| ลบออก | ถอดโซนที่ไม่ควรเผยแพร่แล้ว | ยกเลิกหรือย้ายโดเมน |
| ทั้งโซน | ทุกระเบียน | โซนใหม่ หรือพิสูจน์ไม่ได้ว่างานเล็กกว่าปลอดภัย |
ก่อนลงมือจริง ระบบอ่านสถานะล่าสุดจากฐานข้อมูลอีกรอบ ถ้าพบว่าสถานการณ์เปลี่ยนก็ยกระดับเป็นงานใหญ่ขึ้น เปลี่ยนเป็นการลบ หรือข้ามไป และปฏิเสธการอ่านจากฐานข้อมูลสำรองที่ข้อมูลยังตามไม่ทัน ส่วนงานในคิวของโซนเดียวกันจะถูกรวมเป็นงานเดียว โดยงานที่ใหญ่กว่าชนะเสมอ
งานแต่ละชิ้นเสร็จไม่เรียงลำดับได้ แต่ตำแหน่งที่ยืนยันกับ Kafka ว่าอ่านแล้ว (commit offset) จะขยับก็ต่อเมื่อทุกข้อความก่อนหน้าทำเสร็จ ถ้าระบบรีสตาร์ต ข้อความที่ยังไม่ยืนยันจะถูกทำซ้ำ ทีมเลือกยอมเสียแรงทำซ้ำ ดีกว่าเสี่ยงให้การเปลี่ยนแปลงของลูกค้าหายไปเงียบ ๆ
การทดสอบเทียบผลของการสร้างทั้งโซนกับแบบเฉพาะส่วนจากข้อมูลชุดเดียวกันแบบไบต์ต่อไบต์ ระหว่างทยอยเปิดใช้ ระบบยังสร้างทั้งโซนคู่ขนานไว้เทียบ และตั้ง Zone Builder ชุดเงาที่อ่านข้อมูลจริงจาก production แต่เขียนไปที่ปลายทางที่ไม่ได้ให้บริการ เทียบตัวอย่าง 20% ของโซน ผลต่างอยู่ที่ 0.31% จาก 234,313 โซน และส่วนใหญ่เกิดจากจังหวะเวลา ไม่ใช่ข้อมูลผิด การเปิดใช้เริ่มจากโซนแบบฟรีก่อนแล้วค่อยไปโซนแบบเสียเงิน
| ตัววัด | ก่อน | หลัง |
|---|---|---|
| เวลารอค่ามีผล (ค่ามัธยฐาน) | ราว 7.7 วินาที | ราว 3.3 วินาที |
| ช่วงช้าที่สุด (p99) | 14.6 นาที | 1.21 นาที |
| หน่วยความจำเฉลี่ย | 49 GiB | 7 GiB |
| หน่วยความจำสูงสุด | 79 GiB | 12 GiB |
| งานที่ต้องสร้างทั้งโซน | เกือบทุกงานระดับโซน | 7.04% (อีก 92.95% ใช้งานแบบเล็ก) |
หลักคิดนี้ใช้ได้กับระบบของธุรกิจไทยหลายแบบ เช่น การสร้างดัชนีค้นหาสินค้าใหม่ การล้างแคชหน้าเว็บ หรือการสร้างรายงานจากฐานข้อมูล ที่มักสร้างใหม่ทั้งหมดทุกครั้งที่มีข้อมูลเปลี่ยนเล็กน้อย อ่านอีกตัวอย่างของการลดหน่วยความจำในระบบ DNS ได้ที่บทความเรื่องแคช DNS ทีมงาน Smart Cyber Tech ออกแบบระบบคลาวด์ที่อัปเดตเร็วและใช้ทรัพยากรคุ้มค่า ปรึกษาได้ที่ แบบฟอร์มติดต่อ
บทความอื่นที่เกี่ยวข้อง
ในระบบที่เก็บข้อมูลหลายแสนล้านชิ้น ไบต์เดียวที่เปลืองต่อชิ้นก็กลายเป็นหน่วยความจำหลายร้อยกิกะไบต์ Cloudflare ปรับวิธีเก็บแคชของบริการ DNS อย่าง 1.1.1.1 ห้ารอบ ลดหน่วยความจำต่อรายการได้กว่าครึ่ง คืนหน่วยความจำทั้งระบบราว 100 เทระไบต์ และแคชยังเร็วขึ้นด้วย บทความนี้จัดกลุ่มการเปลี่ยนแปลงตามหลักคิด ซึ่งทีมไทยนำไปใช้กับแคชหรือคิวงานของตัวเองได้แม้สเกลจะเล็กกว่ามาก
อ่านบทความ
เว็บที่อัปเดตบ่อยมักมีผู้ใช้กลุ่มหนึ่งเจอหน้าโหลดช้าทุกครั้งหลัง deploy ทั้งที่ค่าเฉลี่ยดูปกติ Vercel แก้ปัญหานี้ที่ชั้น CDN จนเวลาค้นหาข้อมูลเส้นทางของคำขอกลุ่มที่ช้าที่สุด 1 เปอร์เซ็นต์ (P99) ลดจาก 215.8 เหลือ 19.1 มิลลิวินาที โดยไม่ได้เพิ่มเครื่อง แต่เปลี่ยนจากการดึงข้อมูลทีละเส้นทางมาเป็นการดึงเป็นก้อนขนาดราว 200 KB ที่มีดัชนีในตัว เราสรุปแนวคิด ตัวเลข และสิ่งที่ทีมพัฒนาเว็บในไทยหยิบไปใช้กับระบบ cache ของตัวเองได้
อ่านบทความ
วันที่ 11 ตุลาคม 2569 กุญแจที่ใช้ลงลายเซ็นรากของระบบ DNS จะเปลี่ยนจากชุดเดิม KSK-2017 เป็นชุดใหม่ KSK-2024 คนทั่วไปและเจ้าของเว็บส่วนใหญ่ไม่ต้องทำอะไร แต่องค์กรที่ตั้งเครื่อง DNS resolver ของตัวเองและเปิดตรวจ DNSSEC ไว้ ถ้าเครื่องยังไม่รู้จักกุญแจใหม่ ผู้ใช้ในองค์กรอาจเปิดเว็บแทบไม่ได้เลยตั้งแต่วันนั้น บทความนี้อธิบายว่ากุญแจนี้ทำหน้าที่อะไร ใครต้องตรวจ และวิธีทดสอบที่ใช้เวลาไม่ถึงนาที
อ่านบทความตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย
