เว็บเร็วขึ้น โตได้โดยไม่จ่ายเกินจำเป็น ตอนที่ 3: เพิ่มเครื่องแล้วต้องเพิ่มงานที่ทำสำเร็จได้จริง

ภาพปกสร้างด้วย AI เพื่ออธิบายร้านสมมติ ไม่ใช่ภาพระบบที่ติดตั้งหรือผลทดสอบจริง

ร้านช่างพร้อมเพิ่มเซิร์ฟเวอร์จากหนึ่งเป็นสองเครื่อง แต่ลูกค้าบางคนเข้าสู่ระบบแล้วหลุด และภาพที่เพิ่งอัปโหลดกลับหาไม่เจอ เหตุการณ์สมมตินี้ชี้ว่าการคูณจำนวนเครื่องยังไม่พอ งานจะย้ายไปเครื่องอื่นได้ก็ต่อเมื่อสถานะที่จำเป็นไม่ติดอยู่กับเครื่องเดิม และส่วนกลางยังรับภาระที่เพิ่มขึ้นไหว

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

เครื่องใหญ่ขึ้นกับหลายเครื่องแก้คนละเรื่อง

Scale up คือเพิ่มทรัพยากรของเครื่องหรือบริการ เช่น CPU หรือหน่วยความจำ อาจทำได้ง่ายกว่าในระบบเดิม แต่มีขีดจำกัดและวิธีเปลี่ยนขนาดที่ต้องตรวจ บางระบบต้องหยุดหรือย้ายงาน และเครื่องใหญ่ขึ้นไม่ได้แก้ query ที่อ่านข้อมูลเกินจำเป็นหรือคำขอที่รอบริการภายนอก

Scale out คือเพิ่มหน่วยบริการแล้วแบ่งงานให้หลายหน่วย ช่วยขยายบางชั้นและลดการพึ่งเครื่องเดียวได้ แต่เพิ่มงานประสาน การส่งต่อสถานะ การติดตามข้อผิดพลาด และการจัดการเวอร์ชัน หากภาระไม่มากและทีมเล็ก การใช้บริการที่ดูแลง่ายหรือเพิ่มขนาดอย่างพอดีอาจเหมาะกว่าการสร้างส่วนประกอบหลายชุด

เอาสถานะที่ต้องใช้ร่วมกันออกจากเครื่องแอป

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

ไฟล์สินค้าที่ต้องคงอยู่ไม่ควรฝากไว้เฉพาะดิสก์ชั่วคราวของแอป แยกที่เก็บไฟล์ที่มีสิทธิและวงจรชีวิตชัดเจน ทดสอบว่าเครื่องใหม่อ่านไฟล์ที่อนุญาตได้ และไฟล์ส่วนตัวไม่กลายเป็น URL สาธารณะ การแยกที่เก็บเพิ่มบริการที่ต้องจ่ายและดูแล จึงต้องนับอยู่ในต้นทุน ไม่มองเป็นของฟรีจากคำว่า stateless

งานตามกำหนดเวลาเป็นอีกจุดที่พลาดง่าย หากทุกเครื่องเริ่มส่งอีเมลหรือปิดรอบเหมือนกัน อาจทำงานซ้ำ ต้องมีเจ้าของงานหรือกลไกประสานที่เหมาะสม และออกแบบผลทางธุรกิจให้ทนการทำซ้ำ ไม่ใช้แค่เงื่อนไข “ปกติมีเครื่องเดียว” เมื่อได้เปลี่ยนเป็นหลายเครื่องแล้ว

Load balancer ต้องรู้ว่าเครื่องใดพร้อมรับงาน

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

ไม่ควรให้การตรวจสุขภาพทุกครั้งทำ query หนักหรือเรียกบริการหลายชั้นจนเป็นภาระเอง และระวังการตัดทุกเครื่องออกพร้อมกันเมื่อบริการส่วนกลางสะดุดชั่วคราว เลือกเงื่อนไขและช่วงเวลาให้สอดคล้องกับวิธีลดระดับบริการ เช่น อาจยังให้เปิดแค็ตตาล็อกได้ขณะปิดยืนยันคำสั่งซื้อ โดยแสดงสถานะตรงกับความจริง

เมื่อปลดเครื่องหรือส่งเวอร์ชันใหม่ ให้หยุดรับงานใหม่และเปิดโอกาสให้งานเดิมจบภายในขอบเขตที่กำหนด หรือย้ายงานด้วยวิธีที่ทนการขาดช่วง ลูกค้าที่ส่งคำสั่งซื้อระหว่าง deploy ไม่ควรถูกทิ้งเงียบ ๆ ทั้งต้องมีวิธีทราบผลและลองใหม่โดยไม่สร้างรายการซ้ำ เรื่องนี้จะขยายในตอนคิวและ idempotency

เพิ่มแอปแล้วจำนวนการเชื่อมต่ออาจเพิ่มตาม

สมมติแต่ละเครื่องเปิด pool ฐานข้อมูลได้สูงสุด 20 connection ถ้าขยายจาก 2 เป็น 10 เครื่อง เพดานรวมเฉพาะแอปส่วนนี้เปลี่ยนจาก 40 เป็น 200 ยังไม่รวม worker งานเบื้องหลัง ผู้ดูแล และการ deploy ที่มีเครื่องเก่าใหม่ทับกัน นี่คือตัวอย่างคำนวณเพดาน ไม่ใช่จำนวนที่ฐานข้อมูลควรมีหรือใช้งานจริงตลอดเวลา

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

บริการภายนอกก็มีเพดาน เช่น จำนวนคำขอ อัตราส่งอีเมล หรือการเชื่อมต่อ API คู่ค้า การเพิ่มเครื่องของเราไม่ได้เพิ่ม quota ของเขา ต้องมี timeout ที่คิดจากเวลารวมของคำขอ จำกัดการลองซ้ำ และวิธีแสดงผลเมื่องานบางส่วนช้าหรือไม่พร้อม อย่าปล่อยให้ทุกชั้นลองซ้ำเต็มจำนวนจนภาระคูณกัน

Autoscaling มีช่วงที่กำลังยังมาไม่ถึง

Autoscaling ปรับจำนวนหรือขนาดทรัพยากรตามสัญญาณและนโยบาย ไม่ใช่กำลังสำรองที่ปรากฏทันที มีทั้งเวลาที่ตัวชี้วัดส่งสัญญาณ เวลาเริ่มหน่วยใหม่ และเวลาอุ่นระบบ เอกสารของแพลตฟอร์มจึงให้พิจารณา warmup และเลือก metric ที่สัมพันธ์กับภาระต่อหน่วยจริง

ถ้า CPU ไม่ขึ้นเพราะทุกคำขอรอฐานข้อมูล การขยายตาม CPU อย่างเดียวอาจไม่ช่วย แต่การขยายตามจำนวนคำขอก็อาจยิ่งส่งงานไปจุดตันเดิม ผมจะใช้สัญญาณหลายด้านเพื่อวินิจฉัย แล้วเลือกตัวควบคุมที่เข้าใจพฤติกรรมของมัน พร้อมกำหนดจำนวนต่ำสุด สูงสุด และการตอบสนองต่อขีดจำกัดนั้น

งานพุ่งที่รู้ล่วงหน้าอาจต้องเตรียมกำลังก่อนเวลา ส่วนงานพุ่งที่ไม่คาดต้องมี headroom หรือกำลังเผื่อที่เลือกจากความเสี่ยง และมีมาตรการจำกัดงานเกินกำลัง ค่าใช้จ่ายส่วนเผื่อจึงไม่ได้สูญเปล่าเสมอ มันซื้อความสามารถผ่านช่วงรอ แต่ต้องมีเหตุผลและวัดว่ามากเกินไปหรือไม่

การทดสอบต้องไปไกลกว่าจำนวนเครื่องที่เพิ่มขึ้น

ทดสอบว่าระบบทำงานสำเร็จเพิ่มขึ้นเท่าใดที่เวลาตอบสนองและความผิดพลาดตามเป้า อย่ารับผลว่า “เพิ่มเป็นสิบเครื่องได้แล้ว” โดยไม่ดู throughput ที่ใช้งานได้จริง แยกสาเหตุที่เพิ่มไม่ตามสัดส่วน เช่น การแย่ง lock เครือข่าย ส่วนที่แบ่งไม่ได้ หรือบริการร่วมเต็ม

ทดสอบการหายของหนึ่งเครื่องขณะมีงาน การลดจำนวนหลังโหลดตก และการ deploy ระหว่างรับรายการด้วย การปิดเครื่องหนึ่งในห้องทดลองไม่ใช่หลักฐานว่ารอดจากทุกเหตุขัดข้อง แต่ช่วยตรวจสมมติฐานเฉพาะเรื่องที่ระบุไว้ได้ เขียนขอบเขตของผลให้ชัดเพื่อไม่ให้คนอนุมัติงบเข้าใจว่าเป็นความพร้อมทุกระดับ

เครื่องที่เพิ่มกับคนที่ดูแลต้องขยายไปด้วยกันได้

เมื่อจำนวนเครื่องเปลี่ยน ต้องยังค้น trace และ log ของรายการเดียวกันได้ ค่าตั้ง รุ่นโค้ด และความลับต้องถูกจัดส่งด้วยวิธีที่ตรวจสอบและเพิกถอนได้ ไม่อาศัยการเข้าไปแก้มือเฉพาะเครื่อง การเพิ่มเครื่องที่ทำงานไม่เหมือนกันสร้างปัญหาสุ่มซึ่งคนดูแลตามยากกว่าระบบเล็กที่รู้พฤติกรรม

ตั้งการเตือนเมื่อชนจำนวนสูงสุดหรือกำลังใหม่เริ่มไม่สำเร็จ ไม่ใช่เตือนเฉพาะ CPU สูง และเก็บเวลาตั้งแต่สั่งลดจนทรัพยากรหยุดคิดเงินตามบริการจริงด้วย การลดจำนวนที่เห็นในหน้าควบคุมไม่ใช่ข้อพิสูจน์ว่ารายจ่ายทุกส่วนหายทันที ยังอาจมีดิสก์ IP ที่เก็บไฟล์ หรือฐานบริการขั้นต่ำอยู่

หากทีมยังใช้เวลาแก้เหตุแต่ละเครื่องมาก การทำให้ระบบติดตั้งซ้ำและตรวจสถานะได้อาจคุ้มกว่าการเพิ่มกลไก orchestration ใหม่ทันที เลือก VM บริการแอปที่จัดการให้ หรือแพลตฟอร์มอื่นตามภาระและทักษะจริง Kubernetes เป็นทางเลือกหนึ่งที่ต้องรับผิดชอบงานดูแล ไม่ใช่ใบรับรองว่าเว็บไซต์โตได้แล้ว

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

อ่านต้นทางและขอบเขตของตัวอย่าง

เอกสารต่อไปนี้เป็นแหล่งอธิบายแนวคิดและข้อจำกัด ตรวจเมื่อ 18 ตุลาคม 2569 ตัวเลขร้านสมมติและข้อเสนอการเลือกทางเป็นการเรียบเรียงของผู้เขียน ไม่ใช่ราคา ผลทดสอบ หรือคำรับรองของแหล่งอ้างอิง ก่อนนำไปตั้งค่าจริงต้องตรวจรุ่น แผน และเงื่อนไขที่ใช้อยู่

• AWS Well-Architected: Make systems stateless where possible
• AWS EC2 Auto Scaling: Target tracking
• PostgreSQL 18: Connections and Authentication