เขียน query เดิมทุกอย่าง แต่ทำไม Workers ต่อ Postgres ถึงช้าเป็นวินาที

ทีมที่ย้ายแอปมารันบน Cloudflare Workers มักเจอปัญหาที่ไม่คาดคิดตอนต่อฐานข้อมูล Postgres เดิมที่ใช้อยู่แล้ว query ที่เขียนเหมือนเดิมทุกตัวอักษร โครงสร้างตารางเหมือนเดิม แต่เวลาตอบสนองกลับช้าลงอย่างเห็นได้ชัด บางครั้งถึงหลักวินาทีทั้งที่ query เดียวกันบน server แบบเดิมใช้เวลาไม่ถึง 50 มิลลิวินาที

ต้นตอของปัญหาไม่ได้อยู่ที่ query หรือฐานข้อมูล แต่อยู่ที่ลักษณะการทำงานของ Workers ที่เป็น serverless function รันสั้น ๆ แล้วจบ ทำให้ไม่สามารถคง connection pool แบบที่ backend ทั่วไปทำได้ ทุกครั้งที่ Worker ต้องคุยกับ Postgres จึงต้องเปิด TCP connection ใหม่ ทำ TLS handshake ใหม่ และยืนยันตัวตนใหม่ทุกรอบ ซึ่งมี overhead สูงมากเมื่อเทียบกับเวลารัน query จริง

Hyperdrive คือคำตอบของ Cloudflare สำหรับปัญหานี้ บทความนี้จะอธิบายว่า Hyperdrive ทำงานอย่างไร ทำไมถึงช่วยลด latency ได้จริง วิธีตั้งค่าใช้งาน และข้อจำกัดที่ต้องเข้าใจก่อนวางแผนย้ายฐานข้อมูลมาต่อกับ Workers ผ่านช่องทางนี้

ทำไม Worker ที่ต่อ Postgres โดยตรงถึงช้ากว่าที่คิด

Postgres แบบดั้งเดิมถูกออกแบบมาให้ทำงานกับ client ที่เปิด connection ค้างไว้เป็นเวลานาน แล้ว reuse connection เดิมสำหรับหลาย query ต่อเนื่อง ซึ่งเป็นรูปแบบที่ backend server แบบดั้งเดิมทำได้ดีเพราะ process รันอยู่ตลอดเวลา แต่ Workers ทำงานในโมเดลตรงข้ามกัน คือรันสั้น ๆ ตอบ request แล้วอาจถูกปิดหรือ recycle ไป

ผลที่ตามมาคือทุก request ที่เข้ามาอาจต้องเปิด connection ใหม่ไปยัง Postgres ซึ่งต้องผ่านขั้นตอน TCP handshake, TLS negotiation และการยืนยันตัวตนก่อนถึงจะเริ่ม query ได้จริง ขั้นตอนเหล่านี้รวมกันอาจกินเวลาหลายร้อยมิลลิวินาทีถึงเกินหนึ่งวินาที ขึ้นอยู่กับระยะทางเครือข่ายระหว่าง Worker กับตัวฐานข้อมูล

ปัญหานี้ยิ่งชัดเจนขึ้นเมื่อ Worker รันอยู่ในจุดที่ใกล้ผู้ใช้แต่ไกลจากฐานข้อมูล เช่น Worker รันที่ edge location ในเอเชียตะวันออกเฉียงใต้ แต่ฐานข้อมูล Postgres อยู่ที่ region สหรัฐอเมริกา ทำให้ทุกครั้งที่ต้องเปิด connection ใหม่ ต้องเสียเวลาเดินทางข้ามทวีปไปกลับหลายรอบก่อนจะได้ query จริงกลับมา

Hyperdrive แก้ปัญหานี้อย่างไร

Hyperdrive ทำงานเป็นชั้นกลางระหว่าง Worker กับฐานข้อมูล Postgres หรือ MySQL ที่อยู่ภายนอก โดยรักษา connection pool ไว้ที่จุดใกล้กับฐานข้อมูลจริง แทนที่แต่ละ Worker instance จะต้องเปิด connection ใหม่เอง Worker จะเชื่อมต่อผ่าน Hyperdrive ซึ่งจัดการ pool ของ connection ที่เปิดค้างไว้แล้วให้แทน

นอกจากการ pool connection แล้ว Hyperdrive ยังแคชข้อมูลเส้นทางเครือข่ายและ metadata การเชื่อมต่อ ทำให้การเชื่อมต่อครั้งถัดไปเร็วขึ้นโดยไม่ต้องผ่านขั้นตอน negotiation ทั้งหมดซ้ำทุกครั้ง กลไกนี้ทำงานคล้ายกับ connection pooler อย่าง PgBouncer ที่หลายทีมคุ้นเคย แต่ Hyperdrive ทำงานในระดับเครือข่ายของ Cloudflare โดยตรง ทำให้ไม่ต้องดูแล infrastructure เพิ่มเติมเอง

ผลลัพธ์คือ query ที่เคยใช้เวลาเป็นวินาทีเพราะต้องเปิด connection ใหม่ทุกครั้ง จะลดเหลือใกล้เคียงเวลารัน query จริงบวก latency เครือข่ายปกติ เพราะ Hyperdrive จัดการส่วนที่กินเวลาที่สุดคือขั้นตอนเปิด connection ให้แทนแล้ว

ตั้งค่า Hyperdrive เชื่อม Worker กับ Postgres เดิม

การตั้งค่า Hyperdrive ไม่ต้องย้ายฐานข้อมูลไปไหน ฐานข้อมูล Postgres เดิมยังอยู่ที่เดิม ไม่ว่าจะ host เองหรือใช้บริการ managed database ทั่วไป ขั้นตอนต่อไปนี้เป็นลำดับทั่วไปในการเชื่อมต่อ

1. สร้าง Hyperdrive configuration ผ่าน CLI หรือ dashboard โดยระบุ connection string ของฐานข้อมูล Postgres เดิม รวมถึง host, port, ชื่อฐานข้อมูล และข้อมูลยืนยันตัวตน
2. ผูก Hyperdrive configuration เข้ากับ Worker ผ่านการตั้งค่า binding ใน wrangler config เพื่อให้ Worker เข้าถึง connection string ที่ผ่าน Hyperdrive แล้วในโค้ด
3. แก้โค้ดฝั่ง Worker ให้ใช้ connection string ที่ได้จาก Hyperdrive binding แทนการเชื่อมต่อฐานข้อมูลตรงแบบเดิม โดยไลบรารี driver ของ Postgres ที่รองรับ edge runtime ส่วนใหญ่ใช้ connection string รูปแบบเดียวกับที่ต่อฐานข้อมูลปกติ
4. ทดสอบ query ผ่าน Hyperdrive ในสภาพแวดล้อม development ก่อน เพื่อยืนยันว่า query ที่ซับซ้อน เช่น transaction หลายขั้นตอนหรือ prepared statement ยังทำงานถูกต้องผ่านชั้น pooling นี้
5. วัด latency ก่อนและหลังเปลี่ยนมาใช้ Hyperdrive ด้วย query จริงที่ใช้งานบ่อย เพื่อยืนยันว่าการปรับปรุงเกิดขึ้นจริงในสภาพแวดล้อม production ไม่ใช่แค่ในทฤษฎี

เปรียบเทียบ Latency แบบต่อตรงกับผ่าน Hyperdrive

ตารางด้านล่างเป็นตัวอย่างสมมติเพื่อให้เห็นภาพลักษณะของความต่าง ตัวเลขจริงขึ้นอยู่กับระยะทางเครือข่าย ปริมาณ query และลักษณะฐานข้อมูลของแต่ละทีม ควรวัดจากสภาพแวดล้อมจริงของตัวเองเสมอ

Hyperdrive แคชผลลัพธ์ query ด้วยไหม

จุดที่มักเข้าใจผิดคือ Hyperdrive ไม่ได้แคชผลลัพธ์ของ query เหมือนที่ระบบแคชทั่วไปทำ สิ่งที่ Hyperdrive แคชคือข้อมูลเส้นทางการเชื่อมต่อและจัดการ connection pool เท่านั้น ทุกครั้งที่ query ถูกส่งผ่าน Hyperdrive มันจะยังไปรันจริงที่ฐานข้อมูลปลายทางเสมอ ไม่ได้ส่งผลลัพธ์เก่ากลับมาแทน

ความเข้าใจผิดนี้สำคัญเพราะทีมที่คาดหวังว่า Hyperdrive จะช่วยลดโหลดของฐานข้อมูลด้วยการแคชผลลัพธ์ query ที่ซ้ำกัน อาจผิดหวังเพราะฐานข้อมูลยังต้องรับภาระ query จริงเท่าเดิม สิ่งที่ลดลงคือ overhead ของการเปิด connection ใหม่เท่านั้น ถ้าต้องการแคชผลลัพธ์ query จริง ต้องทำเพิ่มเองด้วยกลไกอื่น เช่นแคชที่ระดับ application หรือใช้ KV ของ Cloudflare เก็บผลลัพธ์ที่เปลี่ยนแปลงไม่บ่อย

สำหรับ query ที่ข้อมูลเปลี่ยนบ่อยและต้องการความสดใหม่เสมอ Hyperdrive ยังเหมาะสม เพราะไม่มีปัญหาข้อมูลเก่าค้างเหมือนระบบแคชผลลัพธ์ แต่สำหรับ query ที่ผลลัพธ์เหมือนเดิมนานและถูกเรียกบ่อยมาก การเพิ่มแคชผลลัพธ์แยกต่างหากยังจำเป็นอยู่เพื่อลดโหลดฐานข้อมูลจริง

ฐานข้อมูลแบบไหนใช้กับ Hyperdrive ได้บ้าง

Hyperdrive รองรับฐานข้อมูลที่ใช้ protocol ของ Postgres และ MySQL เป็นหลัก ไม่ว่าจะ host เองบนเซิร์ฟเวอร์ของทีม หรือใช้บริการ managed database จากผู้ให้บริการภายนอก ตราบใดที่ฐานข้อมูลนั้นเปิดให้เชื่อมต่อจากภายนอกเครือข่ายของตัวเองได้ ก็สามารถตั้งค่าให้ Hyperdrive เชื่อมต่อได้

ข้อควรระวังคือฐานข้อมูลที่ตั้งอยู่หลัง firewall หรือ VPC แบบปิดสนิทที่ไม่อนุญาตการเชื่อมต่อจากภายนอกเลย จะต้องตั้งค่าเปิดช่องทางให้ Hyperdrive เข้าถึงได้ก่อน ซึ่งต้องพิจารณาเรื่องความปลอดภัยของเครือข่ายให้รอบคอบ เพราะการเปิดฐานข้อมูลให้เข้าถึงจากภายนอกมีความเสี่ยงที่ต้องจัดการด้วย whitelist IP หรือกลไกยืนยันตัวตนที่รัดกุม

ทีมที่ใช้ D1 ของ Cloudflare อยู่แล้วไม่จำเป็นต้องใช้ Hyperdrive เพราะ D1 รันอยู่ในเครือข่ายเดียวกับ Workers อยู่แล้ว ไม่มีปัญหาเรื่อง latency ข้ามเครือข่ายแบบที่ Hyperdrive แก้ให้ Hyperdrive เหมาะกับกรณีที่ทีมมีฐานข้อมูล Postgres หรือ MySQL เดิมอยู่แล้วและยังไม่พร้อมย้ายไป D1 มากกว่า

เมื่อไหร่ควรใช้ Hyperdrive และเมื่อไหร่ไม่จำเป็น

Hyperdrive เหมาะกับทีมที่มีฐานข้อมูล Postgres หรือ MySQL เดิมอยู่แล้ว ต้องการย้าย backend มารันบน Workers เพื่อประโยชน์เรื่อง edge computing แต่ไม่พร้อมย้ายฐานข้อมูลทั้งหมดไปยังบริการอื่น การใช้ Hyperdrive ช่วยลดปัญหา latency ได้โดยไม่ต้องเปลี่ยนโครงสร้างฐานข้อมูลเดิมเลย

ถ้าทีมกำลังเริ่มโปรเจกต์ใหม่ตั้งแต่ต้นและไม่มีข้อจำกัดเรื่องฐานข้อมูลเดิม การพิจารณาใช้ D1 หรือฐานข้อมูลที่ออกแบบมาสำหรับ edge computing โดยตรงอาจให้ผลลัพธ์ที่ดีกว่าในระยะยาว เพราะไม่ต้องผ่านชั้น pooling ข้ามเครือข่ายเลย แต่ถ้าต้องการความสามารถของ Postgres เช่น extension เฉพาะทางหรือ feature ที่ D1 ยังไม่รองรับ การอยู่กับ Postgres ผ่าน Hyperdrive ยังเป็นทางเลือกที่สมเหตุสมผล

สำหรับงานที่ query ไม่บ่อยมากหรือ Worker ไม่ได้ต้องการ latency ต่ำมากเป็นพิเศษ อาจไม่คุ้มที่จะเพิ่มความซับซ้อนของการตั้งค่า Hyperdrive เข้ามา ควรประเมินจากปริมาณ traffic จริงและความอ่อนไหวต่อ latency ของแต่ละ endpoint ก่อนตัดสินใจ

ทำแบบนี้แล้วพัง เพราะเข้าใจผิดว่า Hyperdrive แก้ได้ทุกปัญหา

ทีมที่คาดหวังว่า Hyperdrive จะแก้ปัญหา query ที่ช้าเพราะออกแบบไม่ดีตั้งแต่ต้น เช่น query ที่ไม่มี index รองรับหรือ join ตารางใหญ่โดยไม่จำเป็น มักผิดหวังเพราะ Hyperdrive แก้แค่ปัญหา overhead ของการเปิด connection เท่านั้น ไม่ได้ทำให้ query ที่ออกแบบไม่ดีเร็วขึ้น ปัญหาประสิทธิภาพของ query ยังต้องแก้ที่ระดับ database schema และ index เหมือนเดิม

อีกอาการที่พบคือทีมตั้งค่า Hyperdrive แล้วแต่ลืมว่าฐานข้อมูลปลายทางยังมีข้อจำกัดเรื่องจำนวน connection สูงสุดที่รับได้ ถ้า Worker มี traffic สูงมากจนแม้ผ่าน pool ของ Hyperdrive แล้วก็ยังชนขีดจำกัด connection ของฐานข้อมูลเอง ต้องพิจารณาปรับขนาด pool หรือ scale ฐานข้อมูลปลายทางให้รองรับควบคู่กันไปด้วย ไม่ใช่พึ่งพา Hyperdrive อย่างเดียว

อาการที่สามคือทีมไม่ได้ทดสอบ transaction ที่ซับซ้อนผ่าน Hyperdrive ก่อนขึ้น production แล้วพบว่าพฤติกรรมบางอย่างต่างจากการต่อฐานข้อมูลตรง เช่นการจัดการ session state หรือ prepared statement ที่ผูกกับ connection เฉพาะ ควรทดสอบ workload จริงในสภาพแวดล้อม staging ให้ครบก่อนเปลี่ยนมาใช้งานจริงทั้งระบบ

สรุป

ปัญหาที่ Worker ต่อ Postgres แล้วช้าเป็นวินาทีไม่ได้มาจาก query ที่เขียนผิด แต่มาจากธรรมชาติของ serverless ที่ต้องเปิด connection ใหม่ทุกครั้ง Hyperdrive แก้ปัญหานี้ด้วยการ pool connection ไว้ใกล้ฐานข้อมูลจริง ทำให้ overhead ของการเชื่อมต่อลดลงอย่างมีนัยสำคัญโดยไม่ต้องเปลี่ยนโค้ด query เดิมเลย

สิ่งสำคัญคือต้องเข้าใจขอบเขตของ Hyperdrive ให้ชัดเจน มันแก้ปัญหา connection overhead ไม่ใช่ตัวช่วยแก้ query ที่ออกแบบไม่ดีหรือแคชผลลัพธ์แทนฐานข้อมูล การใช้งานที่ได้ผลดีที่สุดคือเข้าใจว่ามันช่วยตรงไหนจริง แล้ววางแผนแก้ปัญหาส่วนอื่นด้วยเครื่องมือที่เหมาะสมควบคู่กันไป

• Hyperdrive pool connection ไว้ใกล้ฐานข้อมูลจริง ลด overhead ของการเปิด connection ใหม่ทุกครั้งจาก Workers
• ไม่ต้องย้ายฐานข้อมูลหรือแก้ query เดิม เปลี่ยนแค่ connection string ที่ Worker ใช้เชื่อมต่อ
• ไม่ได้แคชผลลัพธ์ query ยังต้องรัน query จริงที่ฐานข้อมูลทุกครั้ง ถ้าต้องการลดโหลดต้องเพิ่มแคชแยก
• รองรับ Postgres และ MySQL ที่เปิดให้เชื่อมต่อจากภายนอกได้ ต้องตั้งค่าเครือข่ายให้ Hyperdrive เข้าถึงได้
• เหมาะกับทีมที่มีฐานข้อมูลเดิมอยู่แล้วและยังไม่พร้อมย้ายไป D1 ไม่ใช่ทางแก้สำหรับ query ที่ออกแบบไม่ดี

คำถามที่พบบ่อย