เราทำให้ Moove เร็วขึ้น 59% ได้อย่างไร
ผู้ใช้ Moove ส่วนใหญ่อยู่ไกลจากเซิร์ฟเวอร์ของเรา เราลดเวลารอการตอบกลับครั้งแรกลง 59% โดยไม่ต้องย้ายเซิร์ฟเวอร์ และสิ่งที่ยากกว่าที่คิดคืออะไร
ระยะทางคือสิ่งที่ทำให้เราช้าที่สุด
คนส่วนใหญ่ที่เปิด Moove app ใช้เครือข่ายมือถือในไนจีเรียและอินโดนีเซีย ซึ่งอยู่ห่างจากเซิร์ฟเวอร์ที่ตอบสนองพวกเขาหลายพันกิโลเมตร เดือนนี้เราเปลี่ยนวิธีที่คำขอของพวกเขามาถึงเรา และ เวลาถึงไบต์แรก (TTFB) ซึ่งคือเวลาตั้งแต่โทรศัพท์ส่งคำขอจนถึงตอนที่ส่วนแรกของคำตอบมาถึง ลดลง 59% จาก 0.74 วินาที เหลือ 0.31 วินาที โดยเราไม่ได้ย้ายเซิร์ฟเวอร์แม้แต่เครื่องเดียว
บทความนี้อธิบายว่าทำไมระยะทางจึงทำให้เราเสียเวลามากกว่าที่คาด เราเปลี่ยนอะไรไปบ้าง ส่วนที่ยากกว่าตัวการเปลี่ยนแปลงเอง และสิ่งที่เราอยากบอกทีมอื่นที่กำลังจะทำแบบเดียวกัน
ทำไมการเดินทางไกลครั้งเดียวจึงกลายเป็นสามครั้ง
วิศวกรเรียกความล่าช้าระหว่างการส่งข้อมูลกับการที่ข้อมูลไปถึงว่า ความหน่วง (latency) และเรียกเวลาที่ข้อความเดินทางไปถึงเซิร์ฟเวอร์แล้วคำตอบเดินทางกลับมาว่า เวลาไป-กลับ (RTT) จากลากอสถึงเซิร์ฟเวอร์ของเรา RTT อยู่ระหว่าง 200 ถึง 300 มิลลิวินาที ตัวเลขนี้เพียงลำพังยังพอรับได้ แต่ปัญหาคือคำขอแทบไม่เคยเดินทางตามลำพัง
ก่อนที่โทรศัพท์จะขอข้อมูลใดผ่านการเชื่อมต่อที่ปลอดภัย โทรศัพท์ต้องทำ การจับมือ (handshake) สองครั้งให้เสร็จก่อน ซึ่งเป็นการแลกเปลี่ยนสั้น ๆ เพื่อตั้งค่าการเชื่อมต่อ TCP handshake เปิดการเชื่อมต่อ จากนั้น TLS handshake ตกลงกุญแจเข้ารหัสที่ทำให้การเชื่อมต่อเป็นส่วนตัว แต่ละครั้งใช้เวลาไป-กลับเต็มหนึ่งรอบ หลังจากนั้นตัวคำขอจึงถูกส่งออกไป ซึ่งเป็นรอบที่สาม ที่รอบละ 250 มิลลิวินาที ผู้ใช้ต้องรอราวสามในสี่วินาทีโดยที่เซิร์ฟเวอร์ของเรายังไม่ได้ทำงานอะไรเลย
บนเครือข่ายมือถือ ต้นทุนนี้ต้องจ่ายบ่อยกว่าที่ใครคิด โทรศัพท์ย้ายไปมาระหว่างเสาสัญญาณ คลื่นวิทยุเข้าสู่โหมดพักเพื่อประหยัดแบตเตอรี่ และแอปถูกส่งไปทำงานเบื้องหลัง เหตุการณ์เหล่านี้อาจทำให้การเชื่อมต่อหลุดได้ทั้งนั้น คำขอครั้งถัดไปจึงต้องเริ่มจาก การเชื่อมต่อแบบเย็น (cold connection) คือการเชื่อมต่อที่ยังไม่ได้ทำ handshake เลย และต้องจ่ายต้นทุนการตั้งค่าเต็มจำนวนอีกครั้ง ส่วน การเชื่อมต่อแบบอุ่น (warm connection) ที่เปิดไว้และปลอดภัยอยู่แล้วจะข้ามไปส่งคำขอได้ทันที
เราย้ายลากอสให้ใกล้เซิร์ฟเวอร์ของเราไม่ได้ แต่เราย้ายขั้นตอนตั้งค่าให้ใกล้ลากอสได้
ย้าย handshake ไม่ใช่ย้ายเซิร์ฟเวอร์
เครือข่ายกระจายเนื้อหา (CDN) มักถูกอธิบายว่าเป็นแคช คือชุดของสถานที่ทั่วโลกที่เก็บสำเนาไฟล์ไว้เพื่อให้ส่งจากที่ใกล้ผู้ใช้ได้ เราใช้ CDN เพื่อจุดประสงค์ที่ต่างออกไป สำหรับ API ซึ่งเป็นอินเทอร์เฟซที่แอปใช้คุยกับเราในทุกการทำงาน เราปิดการแคชทั้งหมด ทุกคำขอยังเดินทางไปถึง origin ซึ่งเป็นชื่อที่ CDN ใช้เรียกเซิร์ฟเวอร์ที่อยู่ข้างหลัง
สิ่งที่เปลี่ยนคือจุดที่การเชื่อมต่อเริ่มต้น ตอนนี้โทรศัพท์เปิดการเชื่อมต่อไปยัง edge location ที่ใกล้ที่สุด หรือเรียกอีกอย่างว่า จุดให้บริการ (PoP) ซึ่งเป็นหนึ่งในสถานที่ของ CDN ทั่วโลก มักอยู่ห่างเพียงหลักสิบมิลลิวินาทีแทนที่จะเป็นหลักร้อย edge ทำ TLS termination หมายความว่าการเชื่อมต่อที่ปลอดภัยจากโทรศัพท์สิ้นสุดที่นั่น จากนั้น edge ใช้กลุ่มการเชื่อมต่อแบบอุ่นไปยัง origin ของเราซ้ำ โดยเปิดค้างไว้ด้วย keep-alive ซึ่งเป็นการตั้งค่าให้การเชื่อมต่อเปิดอยู่ระหว่างคำขอแทนที่จะปิดทิ้ง การเดินทางตั้งค่าสองรอบที่แพงจึงเกิดขึ้นบนช่วงสั้น ๆ และมีเพียงตัวคำขอเท่านั้นที่ข้ามมหาสมุทร บนการเชื่อมต่อที่อุ่นอยู่แล้ว
การเดินทางไกลสามครั้งกลายเป็นการเดินทางไกลหนึ่งครั้งกับการเดินทางสั้นสองครั้ง นั่นคือแนวคิดทั้งหมด
ส่วนที่เหลือเราตั้งใจทำให้เรียบง่าย
- ฝั่งไคลเอนต์ไม่รู้สึกถึงความเปลี่ยนแปลง แอปและเว็บไซต์ใช้ที่อยู่เดิม จึงไม่ต้องออกแอปเวอร์ชันใหม่ และไม่มีใครต้องอัปเดตอะไร
- พฤติกรรมเมื่อเกิดข้อผิดพลาดเหมือนเดิม ค่า timeout ตรงกับที่เคยมี สิ่งที่เคยล้มเหลวจึงยังล้มเหลวแบบเดิม เราไม่ต้องการข้อผิดพลาดรูปแบบใหม่
- edge ปิดการเชื่อมต่อที่ว่างก่อนเสมอ ทุกการเชื่อมต่อมี idle timeout คือระยะเวลาที่ปล่อยไว้โดยไม่ได้ใช้ก่อนจะถูกปิด ถ้าเซิร์ฟเวอร์ของเราปิดการเชื่อมต่อที่เงียบอยู่ในขณะที่ edge ยังคิดว่าเปิดอยู่ คำขอถัดไปจะล้มเหลว การตั้งค่า timeout ของ edge ให้สั้นกว่าจึงทำให้ edge เลิกใช้ก่อนเสมอและเปิดการเชื่อมต่อใหม่แทน
- โปรโตคอลรุ่นใหม่สำหรับโทรศัพท์ โทรศัพท์เชื่อมต่อผ่าน HTTP/3 ได้ ซึ่งเป็นโปรโตคอลคำขอรุ่นล่าสุดของเว็บ โดยทำงานบน QUIC ที่รวม handshake ทั้งสองไว้ในการไป-กลับรอบเดียว และรับมือกับการสูญหายของแพ็กเก็ตที่พบบ่อยบนเครือข่ายมือถือได้ดีกว่า
- ไม่ตกหล่นภูมิภาคใด แพ็กเกจราคาถูกของเครือข่าย edge มักข้ามสถานที่ในส่วนของโลกที่ผู้ใช้ของเราอยู่พอดี เราจึงเลือกความครอบคลุมเต็มรูปแบบ
สิ่งที่เราวัด
เราวัดจากซิดนีย์ ซึ่งอยู่ห่างจากเซิร์ฟเวอร์ของเราพอ ๆ กับลากอส โดยเทียบเส้นทางเดิมกับเส้นทางใหม่ ในแต่ละเส้นทางเราเปิดการเชื่อมต่อแบบเย็นใหม่ห้าครั้ง ซึ่งเป็นกรณีที่สำคัญที่สุดบนเครือข่ายมือถือ แล้วใช้ ค่ามัธยฐาน (median) หรือเขียนว่า p50 คือผลลัพธ์ตรงกลาง ที่คำขอครึ่งหนึ่งเร็วกว่าและอีกครึ่งหนึ่งไม่เร็วกว่า โครงการเดียวกันนี้ยังเปิด การบีบอัด (compression) สำหรับสคริปต์ของเว็บไซต์ ซึ่งก่อนหน้านี้ถูกส่งแบบขนาดเต็ม การบีบอัดทำให้ไฟล์เล็กลงก่อนส่ง แล้วเบราว์เซอร์ขยายกลับเมื่อได้รับ เราใช้ Brotli ซึ่งเป็นรูปแบบการบีบอัดที่สร้างมาสำหรับเว็บ
| สิ่งที่เราวัด | ก่อน | หลัง | การปรับปรุง |
|---|---|---|---|
| TCP และ TLS handshake เสร็จสมบูรณ์ (p50) | 490 ms | 59 ms | เร็วขึ้น 88% |
| เวลาถึงไบต์แรก (p50) | 743 ms | 307 ms | เร็วขึ้น 59% |
| ขนาดสคริปต์ของหน้าแรก | 1.76 MB | 560 KB | เล็กลง 68% |
ตัวเลข 59% มาจากเวลาถึงไบต์แรก การเชื่อมต่อที่เคยใช้เวลาตั้งค่าครึ่งวินาที ตอนนี้พร้อมใช้ในไม่ถึงหนึ่งในสิบวินาที และการเข้าเว็บไซต์ของเราครั้งแรกตอนนี้ดาวน์โหลดน้อยลงสองในสาม บนการเชื่อมต่อที่หลายคนต้องจ่ายเงินทุกเมกะไบต์
ตัวเลขเหล่านี้มาจากเมืองเดียว ไม่ใช่เกณฑ์มาตรฐานระดับโลก แต่การคำนวณใช้ได้กับลากอสและจาการ์ตาเช่นกัน และนั่นคือที่ที่ผู้ใช้ของเราอยู่
ส่วนที่ยากคือการรู้ว่าใครเป็นผู้เรียก
การวางบางอย่างไว้หน้าเซิร์ฟเวอร์ของคุณเป็นเรื่องง่าย แต่การทำให้มาตรการป้องกันของคุณยังทำงานได้หลังจากนั้นคือจุดที่เราใช้ความพยายามมากที่สุด
เหมือนแพลตฟอร์มการชำระเงินส่วนใหญ่ Moove ใช้ การจำกัดอัตรา (rate limiting) ซึ่งเป็นการกำหนดเพดานว่าผู้เรียกแต่ละรายส่งคำขอได้กี่ครั้งในช่วงเวลาหนึ่ง และขีดจำกัดเหล่านี้อ้างอิงกับ ที่อยู่ IP (IP address) ของผู้เรียก ซึ่งเป็นตัวเลขที่ระบุอุปกรณ์บนอินเทอร์เน็ต หลังเครือข่าย edge ทุกคำขอจะมาจากที่อยู่ของ edge location แทนที่จะเป็นที่อยู่ของผู้ใช้ ถ้าไม่มีอะไรเปลี่ยนอีก ทุกคนในลากอสจะใช้โควตาเดียวกัน และบ่ายที่ยุ่งเพียงวันเดียวก็จะเริ่มปฏิเสธคนที่ไม่ได้ทำอะไรผิด
วิธีแก้ตั้งอยู่บนสองแนวคิด
เชื่อถือเฉพาะชั้นที่คุณมีอยู่จริง CDN เป็น reverse proxy ชนิดหนึ่ง คือเซิร์ฟเวอร์ที่อยู่หน้าเซิร์ฟเวอร์ของคุณและส่งต่อคำขอ proxy แต่ละตัวจะเพิ่มที่อยู่ที่ได้รับคำขอมาลงใน header มาตรฐานชื่อ X-Forwarded-For ผู้เรียกจริงจึงอยู่ถอยหลังไปในรายการนั้นเป็นจำนวนขั้นหรือ hop ที่แน่นอน การนับผิดเป็นบั๊กทั้งสองทิศทาง ถ้านับชั้นน้อยเกินไป ผู้ใช้ทุกคนจะดูเหมือนเป็น edge location ของตัวเอง ถ้านับมากเกินไป คุณจะเริ่มเชื่อรายการที่ผู้เรียกเขียนขึ้นเอง เราจึงทำให้ตัวเลขนี้เป็นคุณสมบัติของโครงสร้างพื้นฐานแทนที่จะเป็นของโค้ด มันเปลี่ยนในจังหวะเดียวกับที่เครือข่ายเปลี่ยน และบริการของเราจะไม่ยอมเริ่มทำงานหากค่านั้นไม่สมเหตุสมผล แทนที่จะเดา
ให้ edge รับรองผู้เรียก และเชื่อเฉพาะ edge ตอนนี้ edge เขียนที่อยู่ของผู้เรียกจริงลงในทุกคำขอ และเขียนทับสิ่งที่ผู้เรียกส่งมาแทนที่ มาตรการป้องกันของเราจะเชื่อค่านี้ก็ต่อเมื่อตรวจสอบได้ว่าคำขอนั้นผ่าน edge ของเรามาจริง ทุกขีดจำกัดที่เคยอ้างอิงที่อยู่เครือข่ายตอนนี้อ้างอิงผู้เรียกจริงสำหรับทราฟฟิกจาก edge เราเพิ่มกฎเหล่านี้เคียงข้างกฎเดิมแทนที่จะแก้ไขกฎเดิม ทุกการเปลี่ยนแปลงในการนำออกใช้จึงเป็นการเพิ่มล้วน ๆ ที่ใครก็ตรวจสอบได้ในการอ่านครั้งเดียว
บั๊กที่เราจับได้ก่อนปล่อย
Moove Profiles สามารถอยู่บนโดเมนของร้านค้าเองได้ คำขอสำหรับโดเมนเหล่านั้นถูกส่งผ่านเว็บไซต์ของเราพร้อมโดเมนของร้านค้าที่แนบมา เพื่อให้เว็บไซต์รู้ว่าต้องแสดงโปรไฟล์ใด
edge ใหม่หน้าเว็บไซต์ตัดข้อมูลประเภทนั้นออกจากคำขอที่เข้ามา ซึ่งถูกต้องพอดี เพราะผู้เข้าชมไม่ควรตั้งค่านี้ได้เลย แต่นั่นก็หมายความว่าเมื่อเว็บไซต์ย้ายไปอยู่หลัง edge ทุกโดเมนของร้านค้าจะแสดงหน้าแรกของ Moove อย่างเงียบ ๆ แทนที่จะเป็นโปรไฟล์ของร้านค้า
เราจับได้ในการรีวิว จึงย้ายเส้นทางของโดเมนร้านค้าไปไว้ที่ route ของตัวเองก่อน และทำให้โครงสร้างพื้นฐานของเราปฏิเสธการใช้การเปลี่ยนแปลงของเว็บไซต์ในทุกที่ที่ยังไม่ได้ย้าย ความผิดพลาดที่เคยอยู่แค่ในหัวของผู้รีวิว ตอนนี้เป็นสิ่งที่ขั้นตอนบิลด์หยุดไว้ได้
บทเรียนทั่วไปคือ เมื่อคุณเพิ่มชั้นที่ทำความสะอาดอินพุต ให้มองหาทุกสิ่งที่พึ่งพาอินพุตที่คุณกำลังจะทำความสะอาด
เรานำออกใช้อย่างไร
โครงสร้างพื้นฐานการชำระเงินไม่ใช่ที่ที่จะ "ปล่อยแล้วค่อยดู" เราจึงเปลี่ยน staging ก่อนแล้วจึงเปลี่ยน production และการตัดสินใจไม่กี่อย่างทำให้การสลับราบรื่น เราลดค่า TTL (time to live) ของระเบียน DNS ซึ่งเป็นสมุดรายชื่อของอินเทอร์เน็ตที่แปลงชื่ออย่าง moove.xyz เป็นที่อยู่เซิร์ฟเวอร์ TTL คือระยะเวลาที่ส่วนอื่นของอินเทอร์เน็ตแคชคำตอบนั้นได้ เราลดจากหนึ่งชั่วโมงเหลือห้านาที ล่วงหน้าเต็มหนึ่งชั่วโมงก่อนที่จะย้ายอะไร คำตอบเก่าจึงหมดอายุทุกที่แล้ว และการย้อนกลับจะมีผลภายในไม่กี่นาที เราเก็บระเบียนที่อยู่ไว้ในรูปแบบที่สลับได้ในที่เดิม เพราะการลบแล้วสร้างใหม่จะทิ้งช่องว่าง และช่องว่างคือเหตุขัดข้อง แต่ละขั้นที่เสี่ยงเป็นการเปลี่ยนแปลงเล็ก ๆ ของตัวเอง พร้อมขั้นตอนการย้อนกลับที่เขียนไว้เรียงตามลำดับ
สิ่งที่เราอยากบอกทีมอื่น
ถ้าผู้ใช้ของคุณอยู่ไกลจากเซิร์ฟเวอร์ เครือข่าย edge คุ้มค่าที่จะมีแม้จะไม่แคชอะไรเลย ก่อนสลับ:
- ทำรายการทุกอย่างที่อ่านที่อยู่ของผู้เรียก รวมถึงการจำกัดอัตรา allowlist สัญญาณการฉ้อโกง บันทึกการตรวจสอบ และกฎความปลอดภัย ทุกอย่างเหล่านี้จะเห็นที่อยู่ของ edge เว้นแต่คุณจะเปลี่ยน
- ทำให้จำนวนชั้นที่เชื่อถือเป็นส่วนหนึ่งของโครงสร้างพื้นฐาน และไม่ยอมเริ่มทำงานเมื่อค่าผิด
- ให้ edge บันทึกผู้เรียกจริง และเชื่อบันทึกนั้นเฉพาะกับทราฟฟิกที่คุณตรวจสอบได้ว่ามาจาก edge ของคุณ
- ตรวจให้แน่ใจว่าเซิร์ฟเวอร์ของคุณรับทราฟฟิกผ่าน edge เท่านั้น และเฝ้าดูก่อนบังคับใช้
- ถ้าคุณแคชหน้าเว็บ ให้สร้าง คีย์แคช (cache key) ซึ่งเป็นชุดรายละเอียดของคำขอที่แคชใช้ตัดสินว่าสองคำขอใช้คำตอบที่เก็บไว้ร่วมกันได้หรือไม่ จากทุกอย่างที่คำตอบแปรผันตามจริง เซิร์ฟเวอร์ระบุรายละเอียดเหล่านั้นไว้ใน header Vary ดังนั้นให้อ่านจากตรงนั้นแทนที่จะพึ่งความจำ
- วัดก่อนและหลัง และดูเวลา handshake กับเวลาถึงไบต์แรกแยกกัน เพื่อให้แยกการตั้งค่าการเชื่อมต่อออกจากเวลาที่เซิร์ฟเวอร์ใช้ทำงานได้
มองไปข้างหน้า
หน้าส่วนใหญ่ของเราปรับแต่งให้แต่ละคน แคชของ edge สำหรับเว็บไซต์จึงส่วนใหญ่ว่างอยู่ในตอนนี้ การปรับปรุงการเชื่อมต่อใช้ได้กับทุกหน้าไม่ว่าจะอย่างไร และแต่ละหน้าสามารถเลือกใช้การแคชได้เมื่อปลอดภัยที่จะแชร์ การแคชคำตอบของ API ต้องมีการออกแบบและการรีวิวของตัวเอง และเป็นสิ่งต่อไปที่เราอยากดู
เงินควรเคลื่อนที่ด้วยความเร็วของเครือข่าย ไม่ใช่ความเร็วของแสงที่ข้ามมหาสมุทร
หากคุณสร้างบน Moove โปรดอ่าน บทแนะนำ API และ SDK การชำระเงิน Web3 สำหรับนักพัฒนาของเรา และ Moove Developer Program
เขียนโดยทีมวิศวกรของ moove.xyz
เกี่ยวกับ moove.xyz
moove.xyz เป็นแพลตฟอร์มฟินเทค Web3 ระดับโลกที่สร้างขึ้นเพื่อการเคลื่อนย้ายมูลค่าแบบ permissionless และไร้ความยุ่งยาก เราช่วยให้ธุรกิจและผู้บริโภคทั่วโลกส่ง รับ สเตก และสลับคริปโตใดก็ได้ข้ามบล็อกเชนใดก็ได้ ทั้งหมดในแพลตฟอร์มเดียว
เราเป็นหนึ่งในบริษัทฟินเทค Web3 กลุ่มแรกของโลกที่คิดค้นและสร้างโครงสร้างพื้นฐานการชำระเงินด้วยคริปโตและการเงินแบบกระจายศูนย์ครบวงจร ครอบคลุมการเข้าถึงกระเป๋าหลายเชน handle กระเป๋าส่วนบุคคล การสลับโทเค็นข้ามเชน ธุรกรรมข้ามเชนแบบฝังในแอป และเครือข่ายการเงินเชิงสังคมแบบกระจายศูนย์ ผลิตภัณฑ์หลักของเราได้แก่ Moove Profile, Moove Send, Moove Receive, Moove Stake, Moove Swap, Moove Rewards, Moove Discover และอื่น ๆ
พันธกิจของเราเรียบง่าย คือสร้างและเผยแพร่เทคโนโลยีการเงินแบบ permissionless และไร้ความยุ่งยากสำหรับผู้ใช้ Web3 พันล้านคนถัดไป เราเชื่ออย่างยิ่งว่าอนาคตของการเคลื่อนย้ายเงินและมูลค่าจะไร้ต้นทุน ไร้พรมแดน permissionless ไร้ความยุ่งยาก และสร้างมาเพื่อทุกคน และเรากำลังสร้างแพลตฟอร์มฟินเทค Web3 ที่ดีที่สุดเพื่อให้อนาคตนั้นเป็นจริง
เงินของคุณ จังหวะของคุณ






