Replication

1ทำไมต้อง Replicate ข้อมูล

2Replication Model พื้นฐาน

3Quorum-Based (Voting) Protocol

ตัวอย่าง: N=5, W=3, R=3 — R+W=6 > 5 ดังนั้นทุกครั้งที่อ่าน อย่างน้อยหนึ่งในสำเนาที่อ่านได้จะเป็นสำเนาที่เพิ่งถูกเขียนล่าสุด (เพราะเซตของ R replica และเซตของ W replica ต้องมี overlap กันอย่างน้อยหนึ่งตัวเสมอในทางคณิตศาสตร์)

4Gossip Architecture: การกระจายอัปเดตแบบ Eventually Consistent

แต่ละ replica manager เก็บ timestamp table ของตัวเอง (แนวคิดคล้าย vector clock ในบทที่ 7) เพื่อรู้ว่าตนเองมีอัปเดตล่าสุดจากแต่ละ replica อื่นถึงจุดไหนแล้ว — เมื่อ gossip กับ replica อื่น จะแลกเฉพาะอัปเดตที่อีกฝ่ายยังไม่มี

5CAP Theorem: กรอบคิดที่รวมทุกอย่างในบทนี้เข้าด้วยกัน

6Replication ไม่ใช่ Backup และไม่ใช่ Sharding

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

7Consistency Model: คำว่า “ตรงกัน” มีหลายระดับ

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

Session Guarantee: สัญญาเล็ก ๆ ที่ทำให้ผู้ใช้ไม่งง

• Read-your-writes — หลังผู้ใช้แก้ชื่อของตนเอง หน้ารีเฟรชถัดไปต้องเห็นชื่อใหม่ แม้ replica อื่นยังตามไม่ทัน
• Monotonic reads — เมื่อเคยเห็นข้อมูลรุ่น 12 แล้ว การอ่านครั้งถัดไปต้องไม่ย้อนกลับไปเห็นรุ่น 10
• Monotonic writes — การเขียนของผู้ใช้คนเดียวกันต้องถูกนำไปใช้ตามลำดับ ไม่ใช่คำสั่งหลังแซงคำสั่งก่อน
• Writes-follow-reads — ถ้าเขียนโดยอาศัยข้อมูลที่เพิ่งอ่าน การเขียนนั้นต้องเกิดบนสถานะที่ไม่เก่ากว่าข้อมูลดังกล่าว

8Primary–Backup แบบลงรายละเอียด

คำว่า primary–backup ดูเหมือนง่าย: ส่งทุกคำสั่งไปที่ primary แล้วคัดลอกไป backup แต่รายละเอียดว่า “ตอบ client ตอนไหน” เปลี่ยนความหมายของความทนทานโดยตรง

1. Client ส่งคำสั่งเขียนไปที่ primary
2. Primary บันทึกคำสั่งลง log ของตนเองและส่งไปยัง backup
3. Backup บันทึกหรือประมวลผล แล้วตอบรับกลับมา
4. Primary จึงถือว่าคำสั่ง commit และตอบ client

ถ้า primary ตอบตั้งแต่ข้อ 2 latency ต่ำลง แต่ primary อาจล่มก่อน backup ได้รับข้อมูล Client ได้ยินคำว่า “สำเร็จ” แล้วข้อมูลกลับหายหลัง failover เรียกว่า acknowledged-write loss หากรอ backup ทุกตัว ระบบทนต่อข้อมูลหายมากขึ้นแต่ replica ที่ช้าเพียงตัวเดียวทำให้ทั้งระบบช้า วิธีที่ใช้จริงจึงมักรอเพียง quorum หรือ replica ตามจำนวนที่กำหนด

9Multi-Leader และ Leaderless Replication

Multi-Leader: เขียนได้หลายศูนย์ข้อมูล

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

Leaderless: ไม่มีใครเป็นเจ้าของคำตอบคนเดียว

ระบบแบบ Dynamo ให้ coordinator ส่งการเขียนไป replica หลายตัวโดยไม่ตั้ง primary ถาวร การอ่านอาจได้หลาย version แล้วเลือกค่าล่าสุดหรือรวมผล ข้อดีคือรับงานต่อได้แม้บาง node ล่ม ข้อเสียคือความซับซ้อนย้ายจาก leader ไปอยู่ที่ versioning, conflict resolution และกระบวนการซ่อมสำเนา

10Quorum ในโลกจริง: Sloppy Quorum และการซ่อมข้อมูล

สมการ R + W > N ให้ภาพทางคณิตศาสตร์ที่ดี แต่สมมติว่า quorum ที่อ่านและเขียนมาจากชุด replica เดียวกันเสมอ ในระบบจริง node เจ้าของข้อมูลอาจล่ม ระบบจึงยอมฝากข้อมูลไว้กับ node อื่นชั่วคราว เรียกว่า sloppy quorum ความพร้อมใช้งานดีขึ้น แต่เซตอ่านกับเซตเขียนอาจไม่ทับกันตามที่คิด จึงไม่ได้ linearizability มาโดยอัตโนมัติ

• Hinted handoff — node ชั่วคราวเก็บ “โน้ตฝากส่ง” ว่าข้อมูลนี้ควรกลับไปหา replica ใด เมื่อเจ้าของกลับมาจึงส่งคืน
• Read repair — ตอนอ่าน ถ้าพบ replica ให้ค่าต่างกัน coordinator ส่งค่าที่ใหม่กว่าไปซ่อมตัวที่ล้าหลัง
• Anti-entropy — replica เปรียบเทียบชุดข้อมูลเป็นระยะ มักใช้ Merkle tree เพื่อตรวจว่าช่วงใดต่างกันโดยไม่ต้องส่งข้อมูลทั้งหมด

11ความขัดแย้ง: ตรวจอย่างไร และรวมอย่างไร

Timestamp จากนาฬิกาจริงดูสะดวก แต่เครื่องแต่ละตัวเดินไม่ตรงกันและเวลาย้อนกลับได้ การเลือก last-write-wins จึงอาจทิ้งข้อมูลที่มีความหมายเพียงเพราะนาฬิกาเครื่องหนึ่งเร็วกว่า Vector clock หรือ version vector บอกได้ว่ารุ่นหนึ่งสืบต่อจากอีกรุ่นหรือเป็น concurrent siblings แต่สุดท้ายระบบยังต้องตอบว่าเมื่อพบ siblings แล้วจะทำอย่างไร

CRDT ใช้กฎทางคณิตศาสตร์ทำให้ replica รวมผลคนละลำดับแล้วได้คำตอบเดียวกัน เช่น grow-only counter เพิ่มได้อย่างเดียว หรือ observed-remove set ที่เก็บบริบทของการเพิ่มและลบ จุดสำคัญไม่ใช่ว่า CRDT “ไม่มี conflict” แต่เป็นการย้ายกฎแก้ conflict เข้าไปอยู่ในชนิดข้อมูลตั้งแต่ตอนออกแบบ

12Gossip และ Anti-Entropy: ข่าวลือที่มีวินัย

คำว่า gossip ทำให้นึกถึงการส่งข่าวแบบไร้แบบแผน แต่ protocol จริงควบคุมว่าเลือก peer อย่างไร ส่ง digest อะไร และจำกัดข้อมูลต่อรอบเท่าใด ถ้าแต่ละ node สุ่มคุยกับ peer จำนวนเล็กน้อย ข่าวจะกระจายแบบทวีคูณ ในไม่กี่รอบ node ส่วนใหญ่ก็รับรู้ โดยไม่ต้องให้เครื่องกลาง broadcast ไปหาทุกคน

• Push — ผู้มีข่าวส่ง update ให้อีกฝ่าย เหมาะช่วงข่าวยังใหม่และคนส่วนใหญ่ยังไม่มี
• Pull — ผู้รับถามว่าตนขาดอะไร เหมาะกับการเก็บตกท้ายกระบวนการ
• Push–pull — ทั้งสองฝ่ายแลก digest แล้วส่งสิ่งที่อีกฝ่ายขาด ลดเวลาลู่เข้า

ต้องวัด convergence time, fanout, payload size และผลของ node ที่เข้าออกบ่อย ไม่ใช่เพียงบอกว่า “เดี๋ยวข้อมูลก็ตรงกัน” เพราะคำว่าเดี๋ยวอาจหมายถึง 200 มิลลิวินาทีหรือ 20 นาที ซึ่งส่งผลต่อผู้ใช้ต่างกันมาก

13CAP และ PACELC แบบไม่ใช้เป็นคำขวัญ

CAP พูดถึงพฤติกรรมเมื่อเครือข่ายแบ่งฝั่งและข้อความข้ามฝั่งส่งไม่ถึง ถ้าแต่ละฝั่งยังตอบการเขียนต่อ ระบบรักษา availability แต่ไม่อาจรับประกัน linearizability เพราะสองฝั่งไม่รู้การตัดสินใจของกันและกัน ถ้าต้องรักษา consistency อย่างเข้ม ฝั่งที่ไม่มี quorum ต้องหยุดรับบางคำขอ

PACELC เติมอีกครึ่งหนึ่งว่า ถ้ามี Partition ให้เลือกระหว่าง Availability กับ Consistency; Else เมื่อเครือข่ายปกติ ก็ยังเลือกระหว่าง Latency กับ Consistency การรอ replica ไกลเพื่อยืนยันค่าล่าสุดย่อมช้ากว่าตอบจากสำเนาใกล้ ๆ ดังนั้น trade-off ไม่ได้หายไปหลัง partition จบ

14จาก Replication ไปสู่ Consensus

Replication ตอบว่า “จะทำสำเนาสถานะอย่างไร” ส่วน consensus ตอบว่า “หลาย node จะตกลงลำดับคำสั่งเดียวกันได้อย่างไร” State machine replication นำสองเรื่องมาประกบกัน: ใช้ consensus ตกลง log แล้วให้ state machine ที่ deterministic ประมวลผล log เดียวกันตามลำดับเดียวกัน ทุก replica จึงควรได้สถานะเดียวกัน

แต่ไม่ควรใช้ consensus กับทุกข้อมูลเพียงเพราะให้คำตอบชัด ค่าใช้จ่ายคือ latency, quorum dependency และความซับซ้อนในการดำเนินงาน ข้อมูลที่ merge ได้หรือยอม stale ได้อาจเหมาะกับ eventual consistency มากกว่า บทถัดไปจึงไม่ใช่คำตอบที่ “ดีกว่า” replication แต่เป็นเครื่องมือสำหรับส่วนที่ระบบต้องตกลงร่วมกันจริง ๆ

15กรณีศึกษา: ออกแบบระบบตะกร้าสินค้าหลายภูมิภาค

1. ตั้ง invariant — การเพิ่มสินค้าควรไม่หาย การลบต้องนิยามว่าชนะการเพิ่มพร้อมกันหรือไม่ และจำนวนติดลบไม่ได้
2. เลือกรูปแบบ — ใช้ multi-leader หรือ leaderless เพื่อให้ผู้ใช้เพิ่มสินค้าได้แม้เส้นทางข้ามภูมิภาคขาด
3. เก็บ version context — แยกให้ได้ว่า update ใดเกิดสืบต่อกันและ update ใดเกิดพร้อมกัน
4. กำหนด merge — รวมรายการโดย product ID พร้อมกฎเรื่องจำนวนและการลบ ไม่ใช้ last-write-wins แบบเหมารวม
5. แยก checkout — ตอนชำระเงินจริง ความต้องการเปลี่ยนจาก availability ไปเป็นการตรวจ stock และ payment อย่างเข้มกว่าเดิม

16สิ่งที่ควรวัดและคำถามก่อนนำขึ้นระบบจริง

• Replication lag อยู่ที่ percentile ใด และนานแค่ไหนในช่วง traffic สูง
• เมื่อ replica ล่มหนึ่งตัว การอ่านและเขียนยังผ่านได้หรือไม่ และ latency เปลี่ยนเท่าใด
• Client retry ทำให้เขียนซ้ำหรือไม่ มี idempotency key หรือ deduplication หรือยัง
• มี stale read กี่ครั้ง ผู้ใช้กลุ่มใดได้รับผล และ session guarantee ทำงานจริงหรือไม่
• Repair backlog โตได้แค่ไหนก่อนกระทบ foreground traffic
• เคยซ้อม failover, split brain และกู้คืน backup ล่าสุดเมื่อใด

ระบบ replication ที่ดีจึงไม่ได้วัดเพียงว่า replica “up” กี่ตัว แต่ต้องวัดว่าข้อมูลแต่ละชุดใหม่เพียงใด ตรงกันหรือไม่ และเมื่อไม่ตรงกันระบบรู้ตัวเร็วแค่ไหน

17Geo-Replication: สำเนาใกล้ผู้ใช้ แต่ไกลกันเอง

เมื่อ replica อยู่คนละภูมิภาค ประโยชน์คือผู้ใช้อ่านข้อมูลจากศูนย์ที่ใกล้และระบบยังให้บริการบางส่วนได้เมื่อทั้งภูมิภาคมีปัญหา แต่ speed of light ทำให้การยืนยันข้ามทวีปมีต้นทุนที่ลดด้วยการปรับโค้ดไม่ได้ เราจึงต้องจำแนกข้อมูลตามความต้องการแทนการใช้ policy เดียวทั้งระบบ

ต้องกำหนดเรื่อง data residency ด้วย บางข้อมูล replicate ข้ามเขตอำนาจศาลไม่ได้ แม้ทางเทคนิคจะทำได้ง่าย ดังนั้น topology ของสำเนาเป็นทั้งการตัดสินใจด้าน latency, fault domain, ค่าใช้จ่าย และกฎระเบียบ

18Hot Key และ Replica ที่ไม่ได้ช่วยเท่ากัน

การมี replica หลายตัวช่วย read scaling เมื่อคำขอกระจายได้ แต่ hot key เช่นผลการแข่งขันนัดชิงหรือโพสต์ไวรัลอาจทำให้ทุกคนขอ key เดียวพร้อมกัน Replica แต่ละตัวจึงยังร้อนพร้อมกัน และถ้าค่าต้องสดมาก cache ก็หมดอายุพร้อมกันเกิด cache stampede

• กระจาย read ไป replica หลายพื้นที่และใช้ CDN สำหรับข้อมูลสาธารณะ
• ใส่ jitter ใน TTL เพื่อไม่ให้ cache หมดพร้อมกัน
• ใช้ request coalescing ให้คำขอแรกไปต้นทาง ส่วนคำขอที่เหลือรอผลเดียวกัน
• แยก counter ที่รวมผลได้เป็น shard ย่อย แล้ว aggregate ภายหลัง
• ตรวจว่าการเพิ่ม replica ทำให้ write amplification สูงเกินประโยชน์หรือไม่

19ความหมายของ “เขียนสำเร็จ”

API ตอบ 200 ไม่ควรเป็นคำสัญญาที่คลุมเครือ ทีมต้องตกลงว่าหมายถึงรับไว้ในหน่วยความจำ บันทึกลง local disk, fsync แล้ว, replicate ถึงหนึ่ง backup หรือ commit บน quorum แล้ว แต่ละระดับมี latency และความเสี่ยงต่างกัน หาก client เข้าใจว่า durable แต่ server หมายเพียง queued ข้อมูลอาจหายโดยไม่มีใครทำผิดตามนิยามของตนเอง

20สรุปและขั้นตอนถัดไป

Replication เริ่มจากความตั้งใจที่ดี คืออยากให้ระบบเร็วขึ้นและไม่หยุดเมื่อเครื่องหนึ่งล่ม แต่เมื่อข้อมูลมีหลายสำเนา เราแลกปัญหาเครื่องล่มหนึ่งตัวกับปัญหาการตกลงกันของหลายตัว จึงต้องระบุ consistency model, วิธีรับมือ conflict, quorum, repair และ failover ให้ครบ

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

ขั้นตอนถัดไปคือบท Coordination & Agreement ซึ่งจะลงลึกว่า เมื่อบางการตัดสินใจยอมให้ replica เห็นต่างกันไม่ได้ เราจะเลือกผู้นำ จัดลำดับคำสั่ง และตกลงค่าเดียวกันภายใต้ความล้มเหลวได้อย่างไร