บทที่ 13 · Part 3 — Scale & Reliability
Multi-AZ, Multi-Region & DR
RTO/RPO, active-active กับ active-passive, การ failover ฐานข้อมูล, backup ที่กู้ได้จริง และ game day
"เราต้องทำ multi-region" เป็นข้อเสนอที่มักถูกยอมรับเร็วเกินไป หลายทีม ลด availability ของตัวเองด้วยการไป multi-region เพราะความซับซ้อนที่เพิ่มขึ้นล้มบ่อยกว่าที่ region เดียวเคยล้ม บทนี้คือวิธีคุยเรื่องนี้ด้วยตัวเลขและคำถามที่ถูก
จบบทนี้คุณจะ
- ใช้คำ RTO, RPO, failure domain ได้ถูกต้อง
- เลือก topology ได้ตามความจำเป็นจริง ไม่ใช่ตามความอยาก
- รู้ว่าทำไม replication ไม่ใช่ backup
- รู้ว่า RTO จริงของคุณคือเวลาที่วัดได้จากการ restore ครั้งล่าสุด ไม่ใช่ตัวเลขในเอกสาร
- รัน game day ที่ให้ action item ออกมาได้
คำศัพท์ที่จะถูกถาม
| คำ | ความหมาย | ผลต่อ design |
|---|---|---|
| RTO (Recovery Time Objective) | ล่มได้นานที่สุดเท่าไหร่ | กำหนดว่าต้องมี failover automation ระดับไหน |
| RPO (Recovery Point Objective) | เสียข้อมูลได้ย้อนหลังเท่าไหร่ เป็นหน่วยเวลา | RPO 0 บังคับให้ต้องมี synchronous replication |
| Failure domain | ชุดของสิ่งที่ล้มพร้อมกัน | rack, AZ, region, cloud account, certificate, config push, shared library version, deployment pipeline, vendor |
Failure domain ที่คนลืมนับ
ทีมส่วนใหญ่นับแค่ rack/AZ/region แต่ failure domain ที่ทำให้ redundancy กลายเป็นนิยายมักไม่ใช่เรื่องกายภาพ:
- Certificate ใบเดียวกัน หมดอายุพร้อมกันทุก replica
- Config push ชุดเดียวกัน ไปถึงทุก node ใน 30 วินาที
- Library version เดียวกัน ที่มี bug เดียวกัน
- Deployment pipeline เดียวกัน ที่ deploy โค้ดเสียไปทุกที่พร้อมกัน
- Vendor รายเดียวกัน ที่ล่มทั้ง region ของเขา
ทางแก้: ทยอย rollout config และ certificate และ map failure domain ออกมาเป็นตารางในเอกสาร design
เลือก topology
| Topology | RTO / RPO | ความซับซ้อน | ประเมินอย่างซื่อสัตย์ |
|---|---|---|---|
| Single AZ | ชั่วโมง / ชั่วโมง | ง่ายมาก | ไม่รับได้สำหรับบริการทางการเงินบน production |
| Multi-AZ, region เดียว | วินาที–นาที / 0 | ปานกลาง; ส่วนใหญ่ managed ให้แล้ว | คำตอบที่ถูกสำหรับระบบส่วนใหญ่ — synchronous replication ใน region เดียวเสียแค่ ~1–2 ms เอาอันนี้แล้วหยุด |
| Multi-region, warm standby | นาที–ชั่วโมง / วินาที–นาที | สูง | สมเหตุสมผลเมื่อมีข้อกำหนด DR จาก regulator · ส่วนที่ยากไม่ใช่ replication — คือการซ้อม failover แผน DR ที่ไม่เคยทดสอบคือเอกสาร ไม่ใช่ความสามารถ |
| Multi-region active-active | ~0 / ~0 สำหรับ read | สูงมาก | ทำเฉพาะเมื่อจำเป็นจริง · ต้องแก้ปัญหา write conflict และสำหรับเงิน คำตอบที่ซื่อสัตย์มักคือ "1 region เป็นเจ้าของ 1 account" (partition ownership) ไม่ใช่ multi-master จริงๆ |
Multi-region ไม่ใช่การอัปเกรด reliability โดยปริยาย
การเพิ่ม region ที่ 2 เพิ่ม: replication lag ที่คุณต้องคิดถึงทุกที่, ความเสี่ยง split-brain, ค่าใช้จ่าย 2 เท่า, เรื่อง deployment ที่ยากกว่ามาก, และ cross-region latency ในทุกเส้นทางที่เป็น synchronous
ก่อนเสนอ ตอบ 3 คำถามนี้อย่างซื่อสัตย์:
- failure แบบไหนโดยเฉพาะ ที่อันนี้ป้องกันได้แต่ multi-AZ ป้องกันไม่ได้
- ใครจะรันและทดสอบ failover ทุกเดือน
- สำหรับการเคลื่อนย้ายเงิน — region ไหนเป็น authoritative สำหรับ account หนึ่งๆ และ region อีกฝั่งปฏิเสธการเขียนได้อย่างไร
ถ้าตัวขับคือข้อผูกพัน DR ตามกฎ ให้พูดออกมาตรงๆ ว่า "เราทำเพราะข้อกำหนด X จาก [แหล่งที่มา]" แล้วออกแบบ topology ที่ถูกที่สุดที่ตอบข้อนั้น — นั่นเป็นเหตุผลที่ชอบธรรม และการเรียกชื่อมันป้องกัน scope creep ไปเป็น active-active
ถ้าต้องทำ multi-region สำหรับเงิน — partition ownership
Account ownership แบบชัดเจน (ปลอดภัยกว่า multi-master มาก)
acc_A00000 - acc_M99999 -> region SG เป็นเจ้าของ (เขียนได้)
acc_N00000 - acc_Z99999 -> region TH เป็นเจ้าของ (เขียนได้)
region ที่ไม่ใช่เจ้าของ:
- อ่านได้จาก replica (บอกผู้ใช้ว่าข้อมูลอาจช้า X วินาที)
- เขียน -> ปฏิเสธด้วย 409 หรือ proxy ไปหาเจ้าของ
- ห้าม "เขียนแล้วค่อย merge ทีหลัง" กับเงิน
การย้ายเจ้าของ (ตอน failover):
1. หยุดรับ write ที่ region เดิม (fence)
2. ยืนยันว่า replica ตามครบแล้ว (LSN/GTID ตรงกัน)
3. เปลี่ยน shard map ให้ region ใหม่เป็นเจ้าของ
4. ค่อยเปิดรับ write
--> ขั้นที่ 1 กับ 2 คือสิ่งที่ทำให้ split-brain เป็นไปไม่ได้
และเป็น 2 ขั้นที่ automated failover มักข้ามAutomated failover ข้าม region เป็นความเสี่ยง ไม่ใช่แค่ฟีเจอร์
incident ของ GitHub ปี 2018 (บทที่ 12) คือกรณีตัวอย่าง — network blip 43 วินาทีทำให้ failover ทำงาน แล้ว 2 ฝั่งรับ write ที่แยกทางกัน
สำหรับเงิน failover ข้าม region ควรต้องมีคนตัดสินใจ โดยมีข้อมูลว่า replication lag เท่าไหร่และมีรายการค้างเท่าไหร่ ไม่ใช่ automation ที่ trigger จาก health check เพียงลำพัง
Backup — รากฐานที่ไม่หวือหวา
Replication ไม่ใช่ backup
Replication คัดลอก DELETE FROM accounts ของคุณไปทุก replica อย่างซื่อสัตย์
ภายในไม่กี่มิลลิวินาที
สิ่งที่ต้องมีจริง:
| สิ่งที่ต้องมี | เหตุผล |
|---|---|
| Point-in-time recovery | กู้กลับไปยังวินาทีก่อนที่คำสั่งผิดจะรัน |
| เก็บใน account / credential domain แยก | credential ของ production ที่ถูกเจาะต้องลบ backup ไม่ได้ |
| Immutability / object-lock ถ้ามีให้ใช้ | กัน ransomware และกันการลบโดยไม่ตั้งใจ |
| Encryption | ทั้ง at rest และ in transit และจัดการ key แยกจากข้อมูล |
Backup ที่ไม่เคย restore คือสมมติฐาน ไม่ใช่ความสามารถ
จัดตาราง restore test จริง — restore ลง environment ที่แยกออกมา, ยืนยันจำนวนแถวและ checksum ของตารางที่สำคัญ, และบันทึกว่าใช้เวลานานเท่าไหร่
ระยะเวลาที่วัดได้นั้นคือ RTO จริงของคุณ ไม่ว่าเอกสารนโยบายจะเขียนว่าอะไร
ทดสอบ restore ของของที่ยุ่งยากด้วย
- ตารางเดียว (เวลาแก้ข้อมูลผิดจุดเดียว)
- ข้อมูลของลูกค้าคนเดียว — คุณจะต้องใช้สำหรับคำขอตาม PDPA หรือกรณีข้อพิพาท
- Secret และ config ไม่ใช่แค่ฐานข้อมูล
Restore test log ที่ควรมี (เก็บเป็น artefact ให้ auditor ดูได้)
วันที่ 2026-07-15
Backup ที่ใช้ 2026-07-14 23:00 UTC (point-in-time -> 2026-07-15 02:17)
Environment dr-restore-test (isolated VPC, ไม่มี network ออก)
เวลาที่ใช้ 1 ชม. 48 นาที <-- นี่คือ RTO จริง
ผลการตรวจ accounts row count ตรง, checksum ตรง
ledger_entries row count ตรง, sum(amount) ตรง
transfers row count ตรง
ปัญหาที่เจอ secret ของ rail adapter ไม่อยู่ใน backup -> action item
ผู้ทำ / ผู้ตรวจ <ชื่อ> / <ชื่อ>Chaos และ game day
คุณไม่รู้ว่าระบบทนได้จนกว่าจะเคยทำให้มันพังโดยตั้งใจ เริ่มเล็กและปลอดภัย ใน environment ที่ไม่ใช่ production แล้วค่อยเลื่อนขั้น
1. Tabletop ก่อน (ฟรี)
รวมทีม 1 ชั่วโมง
"ตอนนี้บ่าย 2 ของวันที่ 25 ฐานข้อมูล primary เพิ่ง failover และ transfer 20% ค้างอยู่ที่
PENDINGเริ่มเลย"
ดูว่าใช้เวลานานแค่ไหนกว่าจะหา dashboard ที่ถูกเจอ ทุกช่องว่างคือ action item
2. Fault injection ใน non-prod
kill pod · เพิ่ม latency 500 ms · เติม disk ให้เต็ม ·
ทำให้ certificate หมดอายุ · ให้ dependency ตอบ 503 ·
ชี้ service ไปที่ read-only replica
3. Production แบบมีขอบเขตและประกาศล่วงหน้า
Fault injection บน production ในองค์กรที่ถูกกำกับดูแล
ทำได้เฉพาะเมื่อมีครบทุกข้อ: เจ้าของ, สมมติฐานที่จะทดสอบ, ขอบเขต blast radius, kill switch, และ stakeholder ที่เห็นด้วย
และต้องมี การอนุมัติอย่างชัดแจ้งจากผู้รับผิดชอบที่มีอำนาจ — ขอเป็นลายลักษณ์อักษร
ห้ามรัน experiment ที่อาจเคลื่อนย้ายหรือทำให้เงินของลูกค้าหายเด็ดขาด
อ้างอิง: Principles of Chaos Engineering
Lab 13 — Game day
ส่วน A — เตรียม (20 นาที) เลือก 1 scenario จาก failure table ของคุณ กำหนดบทบาท: incident commander, comms, investigator 2 คน, และ 1 คนเล่นเป็น "dashboard" (คนนี้ตอบได้แค่สิ่งที่ทีมมองเห็นได้จริงในวันนี้)
ส่วน B — รัน (30 นาที) จับเวลาเข้ม 30 นาที ห้ามเกิน
ส่วน C — Debrief (30 นาที) ให้คะแนน 3 ตัว:
| ตัวชี้วัด | ความหมาย |
|---|---|
| นาทีถึงการตรวจพบ | ถ้าไม่มีใครรู้จนลูกค้าโทรมา นั่นคือช่องว่างที่ใหญ่ที่สุด |
| นาทีถึงสมมติฐานที่ถูก | วัดว่า observability ชี้ทางได้จริงไหม |
| จำนวนครั้งที่พูดว่า "เราไม่มี metric นั้น" | ทุกครั้งคือ action item 1 ข้อ |
ส่วน D — ผูกมัด (20 นาที) เปลี่ยนช่องว่างเป็นรายการเปลี่ยนแปลง 5 ข้อที่มีเจ้าของ โดย1 ข้อต้องเป็น alert บน business outcome และ 1 ข้อต้องเป็น runbook ที่คุณเขียนจริงในสัปดาห์นี้
Checklist DR
- RTO และ RPO เขียนไว้เป็นตัวเลข และใครเป็นคนกำหนด
- Multi-AZ พร้อม synchronous standby (RPO 0) สำหรับข้อมูลการเงิน
- Failure domain map ออกมาเป็นตาราง รวม certificate, config push, pipeline, vendor
- Config และ certificate rollout แบบทยอย ไม่ใช่พร้อมกันทั้งหมด
- Backup อยู่ใน credential domain แยก, immutable, encrypted
- มี restore test ที่ทำจริงในรอบ 6 เดือน พร้อมเวลาที่วัดได้
- ทดสอบ restore ของตารางเดียว, ของลูกค้าคนเดียว, และของ secret/config แล้ว
- ถ้ามี multi-region — ตอบได้ว่า region ไหนเป็นเจ้าของ account ไหน และ region อื่นปฏิเสธ write อย่างไร
- Failover ข้าม region สำหรับเงินต้องมีคนตัดสินใจ ไม่ใช่ automation ล้วน
- เคยรัน game day และมี action item ที่ปิดแล้ว
สรุปบทนี้
Multi-AZ + synchronous standby คือคำตอบสำหรับระบบส่วนใหญ่ — เอาแล้วหยุด · multi-region เพิ่ม failure mode มากกว่าที่ลบ ให้ตอบ 3 คำถามให้ได้ก่อน · สำหรับเงินใช้ partition ownership ไม่ใช่ multi-master · replication ไม่ใช่ backup · RTO จริงคือเวลาที่วัดได้จาก restore ครั้งล่าสุด · และ game day ที่ดีวัดกันที่จำนวนครั้งที่ทีมพูดว่า "เราไม่มี metric นั้น"