ระบบความพร้อมใช้งานสูง (High availability)

สวิตช์ควบคุมเพียงปุ่มเดียวจะช่วยสลับการทำงานของแพลตฟอร์มทั้งหมดระหว่าง โหมด Standalone ที่ใช้งาน 1 replica ต่อส่วนประกอบ และ โหมด High Availability ที่ทำงานร่วมกับหลาย replica, กำหนดการขัดข้องที่ยอมรับได้ (disruption budget) และการใช้ฐานข้อมูลแบบคลัสเตอร์ โดยคุณไม่จำเป็นต้องเข้าไปตั้งค่าทรัพยากรของแต่ละส่วนประกอบด้วยตัวเอง เนื่องจากตัว chart จะคำนวณจำนวน replica ที่เหมาะสมให้โดยอัตโนมัติจากการตัดสินใจจุดเดียวนี้

เอกสารนี้เหมาะสำหรับใคร

วิศวกรแพลตฟอร์ม (platform engineer) ที่ต้องการประเมินขนาดทรัพยากรของแพลตฟอร์มสำหรับการใช้งานจริง โหมด Standalone จะมีความเพียงพอสำหรับการทดสอบนำร่องหรือการใช้งานภายในทีมเดี่ยว ส่วนโหมด HA จะมีไว้เพื่อประมวลผลทราฟฟิกจริงในระดับองค์กรและรองรับการทำงานของหลายทีม

สวิตช์ควบคุมแบบจุดเดียว

global:
  highAvailability: true

• false (ค่าเริ่มต้น) → โหมด standalone: 1 replica ต่อส่วนประกอบ, ไม่สร้าง PodDisruptionBudget และไม่กำหนดเงื่อนไข anti-affinity ทำให้ใช้ทรัพยากรระบบต่ำที่สุด เหมาะสำหรับการใช้งานนำร่องหรืองานทั่วไปที่ไม่วิกฤต
• true → โหมด high availability: ใช้งานหลาย replica, สร้าง PodDisruptionBudget และกำหนดเงื่อนไข soft pod anti-affinity เพื่อกระจายการทำงานของ replica ไปยังโหนดต่าง ๆ

การเปลี่ยนแปลงหลักในโหมด HA

เมื่อกำหนดค่า global.highAvailability เป็น true จำนวน replica ของแต่ละส่วนประกอบจะถูกคำนวณโดยอัตโนมัติ ดังนี้

ส่วนประกอบ	โหมด Standalone	โหมด High availability
Gateway (data plane)	1	2 ขึ้นไป
Control plane	1	2 (มีการเลือกผู้นำสำหรับงานเบื้องหลัง)
Web console	1	2
SSO (oauth2-proxy)	1	2
Keycloak	1	2
PostgreSQL (control plane)	1 instance	คลัสเตอร์แบบ 3 instances พร้อมระบบสลับการทำงานอัตโนมัติ (failover)
Keycloak PostgreSQL	1 instance	คลัสเตอร์แบบ 3 instances
Redis	1	3 (ทำงานแบบ replication ร่วมกับ Sentinel)
Observability	1	2 ขึ้นไป (จัดเก็บข้อมูลบนระบบ object storage)

ทั้งนี้คุณยังคงสามารถกำหนดค่าจำนวน replica ทับ (override) ของแต่ละส่วนประกอบได้โดยการระบุตัวเลขในคีย์ replicas โดยตรง เช่น gateway.replicas: 3 หรือหากปล่อยว่างไว้ระบบจะทำงานตามสวิตช์ควบคุมหลักโดยอัตโนมัติ

การกำหนดค่าขัดข้องที่ยอมรับได้และการกระจายโหนด

ในโหมด HA ตัว chart จะสร้างทรัพยากร PodDisruptionBudget สำหรับส่วนประกอบที่ละเอียดอ่อนต่อการหยุดชะงัก และใช้เงื่อนไข soft anti-affinity โดยอิงตามชื่อโฮสต์ เพื่อให้มั่นใจได้ว่าการกวาดโหนด (node drain) หรือการทยอยอัปเกรดระบบ (rolling upgrade) จะไม่ทำลายการทำงานของทุก replica ในส่วนประกอบนั้นพร้อมกันในคราวเดียว

งานเบื้องหลังจะทำงานผ่านระบบการเลือกผู้นำ

control plane จะรันงานตามรอบเวลา ได้แก่ การปรับประสานสถานะ, การซิงก์ราคา และการทำความสะอาดประวัติการใช้งาน เมื่อมี replica หลายตัว งานเหล่านี้จะถูกป้องกันไม่ให้ทำงานซ้ำซ้อนโดยใช้ระบบล็อกใน PostgreSQL เพื่อจำกัดให้ประมวลผลเพียงงานเดียวทั่วทั้งคลัสเตอร์ สำหรับการปรับประสานสถานะแบบเขียนข้อมูล (write-driven reconcile) จะมีคุณสมบัติ idempotent และไม่จำเป็นต้องใช้ระบบล็อกนี้

ส่วนประกอบจัดเก็บสถานะในโหมด HA

• PostgreSQL: ทำงานในรูปแบบคลัสเตอร์ CloudNativePG ขนาด 3 instances พร้อมระบบ replication แบบสตรีมมิ่งและระบบ failover อัตโนมัติ ควรใช้งานฟีเจอร์นี้ควบคู่กับแผน การสำรองข้อมูลและการกู้คืน (Backup & DR)
• Redis: ทำงานร่วมกับระบบ replication และ Sentinel เพื่อช่วยสลับสิทธิ์การเขียนอ่านหลัก (master failover) โดยอัตโนมัติ
• Observability: จะเปลี่ยนมาใช้งานที่จัดเก็บข้อมูลบนระบบ object-storage ด้วยการระบุ observability.storage: object ในโหมด HA แทนการใช้งาน local volume ปกติ ดูรายละเอียดเพิ่มเติมได้ที่ ระบบตรวจสอบสถานะการทำงานของแพลตฟอร์ม

การประเมินขนาดทรัพยากร

โหมด HA จะใช้ทรัพยากรเพิ่มขึ้นประมาณ 2 ถึง 3 เท่าตัวเมื่อเทียบกับโหมด Standalone โปรดตรวจสอบให้แน่ใจว่าคลัสเตอร์ของคุณมีทรัพยากรว่างเพียงพอตามที่ระบุใน ข้อกำหนดของระบบ ก่อนทำการเปิดใช้งาน และอย่าลืมว่าการเปิดใช้งานฟีเจอร์ด้านความหมาย (semantic) จะมีการติดตั้ง Qdrant และ Ollama เพิ่มเติมด้วย

ขั้นตอนต่อไป

• การสำรองข้อมูลและการกู้คืน (Backup & DR) — วิธีปกป้องฐานข้อมูลที่เป็นแหล่งข้อมูลความจริงของ control plane
• ระบบตรวจสอบสถานะการทำงานของแพลตฟอร์ม — โครงสร้างที่จัดเก็บข้อมูลและนโยบายการจัดเก็บในโหมด HA
• การอัปเกรดระบบ — ขั้นตอนการทยอยอัปเกรดระบบร่วมกับการบังคับใช้ PodDisruptionBudget