HR รีพอร์ต

ลองนึกภาพว่าคุณเป็นเจ้าของร้านขายของออนไลน์เล็กๆ เริ่มแรกมีลูกค้าแค่วันละ 10 คน ใช้สมุดบันทึกเล่มเดียวก็พอ แต่แล้ววันหนึ่งร้านคุณดังขึ้น มีลูกค้า 1,000 คน 10,000 คน แล้วก็ 1 ล้านคนต่อวัน สมุดเล่มเดียวไม่พอแล้ว คุณต้องทำยังไง?

นี่คือปัญหาที่ Martin Kleppmann ผู้เขียนหนังสือ “Designing Data-Intensive Applications” ต้องการตอบ หนังสือเล่มนี้ไม่ใช่แค่คู่มือเทคนิค แต่เป็นเหมือนเรื่องเล่าของคนที่เจอปัญหาจริงๆ และหาทางออกมาได้

1. เมื่อความเรียบง่ายกลายเป็นความซับซ้อน

เรื่องเล่าจากโลกจริง: กรณี Netflix

ย้อนกลับไปปี 2007 Netflix ยังเป็นบริษัทส่งแผ่น DVD ทางไปรษณีย์ ระบบฐานข้อมูลของพวกเขาก็เรียบง่าย เก็บรายชื่อหนัง รายชื่อลูกค้า และใครยืมอะไรไป

แต่พอเปลี่ยนมาเป็น Streaming ทุกอย่างเปลี่ยน ตอนนี้ Netflix ต้องจัดการกับ:

• ผู้ใช้ 230 ล้านคนทั่วโลก
• การดูหนังพร้อมกันนับล้านชั่วโมงต่อวัน
• ระบบแนะนำหนังที่ต้องเรียนรู้ความชอบของแต่ละคน
• การเก็บวิดีโอหลายล้านไฟล์ในหลายคุณภาพ

Kleppmann อธิบายว่านี่คือสิ่งที่เขาเรียกว่า “Data-Intensive Applications” – แอปพลิเคชันที่ปัญหาหลักไม่ใช่การคำนวณที่ซับซ้อน แต่เป็นการจัดการข้อมูลจำนวนมหาศาล

2. สามเสาหลักของระบบที่ดี

เขาเปรียบเทียบการสร้างระบบข้อมูลเหมือนการสร้างสะพาน ต้องมั่นใจในสามสิ่ง:

1. ความน่าเชื่อถือ (Reliability)

ตัวอย่าง: ระบบการโอนเงิน

ลองคิดถึงตอนที่คุณโอนเงินผ่านมือถือ กดส่งไปแล้ว หน้าจอค้าง แต่เงินหายจากบัญชี ใจเต้นแรงมั้ย? นี่คือเหตุผลที่ธนาคารใช้เงินมหาศาลสร้างระบบที่ “ไม่เสีย”

ระบบที่เชื่อถือได้ต้องทำงานถูกต้องแม้ว่า:

• ฮาร์ดแวร์พัง (ฮาร์ดดิสก์เสีย RAM ขัดข้อง)
• ซอฟต์แวร์มีบัค (โค้ดผิด อัปเดตใหม่มีปัญหา)
• คนใช้ทำผิด (กรอกข้อมูลผิด กดปุ่มผิด)

วิธีแก้ในโลกจริง:

• สำรองข้อมูลหลายที่ (Amazon เก็บข้อมูลคุณอย่างน้อย 3 สำเนา)
• ทำ Failover อัตโนมัติ (เซิร์ฟเวอร์หลักพัง เปลี่ยนไปใช้ตัวสำรองทันที)
• Test กระทั่งในสถานการณ์แย่ที่สุด (Netflix เจตนาปิดเซิร์ฟเวอร์เพื่อทดสอบ!)

2. ความสามารถขยายตัว (Scalability)

ตัวอย่าง: ปรากฏการณ์ “Shopee 9.9”

วันเซลครั้งใหญ่ คนทั้งประเทศเข้าแอป Shopee พร้อมกันตอน 00:00 น. ปกติแอปรับได้ 100,000 คนพร้อมกัน แต่วันนั้นมี 5 ล้านคน!

ระบบที่ Scale ได้ต้องเตรียมรับมือสองแบบ:

• Scale Up (Vertical): เพิ่มพลังเครื่องเดิม (CPU แรงขึ้น RAM เยอะขึ้น) เหมือนซื้อรถคันใหญ่กว่า
• Scale Out (Horizontal): เพิ่มเครื่องใหม่ เหมือนซื้อรถหลายคัน

Shopee ใช้วิธีผสม:

• เพิ่มเซิร์ฟเวอร์ชั่วคราวก่อนเซล
• แยกระบบตามหน้าที่ (ระบบค้นหาสินค้า / ระบบชำระเงิน / ระบบแชท)
• ใช้ CDN กระจายรูปภาพไปตามเมืองใหญ่

3. การดูแลรักษาได้ (Maintainability)

ตัวอย่าง: ปัญหาโค้ด “มรดกตกทอด”

บริษัทแห่งหนึ่งมีระบบเงินเดือนที่เขียนเมื่อ 20 ปีก่อน โปรแกรมเมอร์คนเดิมลาออกหมดแล้ว คนใหม่เข้ามาดูโค้ด เหมือนอ่านตำราโบราณ ไม่มีคอมเมนต์ ไม่มีเอกสาร เปลี่ยนอะไรหน่อยกลัวระบบพัง

ระบบที่ดูแลง่ายต้องมี:

• เข้าใจง่าย: อ่านโค้ดแล้วรู้ว่าทำอะไร
• เปลี่ยนง่าย: เพิ่มฟีเจอร์ใหม่ไม่ต้องแก้ทั้งระบบ
• ใช้ซ้ำได้: เขียนครั้งเดียว ใช้ได้หลายที่

3. สงครามของฐานข้อมูล – SQL vs NoSQL

เรื่องเล่า: วิวัฒนาการของ Facebook

ปี 2004 Facebook เริ่มจากห้องหอพักมหาวิทยาลัย ใช้ MySQL ธรรมดาก็พอ แต่พอผู้ใช้เยอะขึ้น ปัญหาตามมา:

ปัญหาของ SQL แบบเดิม:

• ข้อมูลต้องมีโครงสร้างแน่นอน (เหมือนตารางเรียน ต้องมีคอลัมน์ชัดเจน)
• ขยายยาก (เหมือนโต๊ะใหญ่ ใส่คนเยอะไม่ได้)
• แก้โครงสร้างยาก (เปลี่ยนตารางทีต้องหยุดทำงาน)

Facebook เลยเปลี่ยนมาใช้ NoSQL เพิ่ม:

• Document Database: เก็บโปรไฟล์คนเป็น JSON ยืดหยุ่นกว่า
• Graph Database: เก็บความสัมพันธ์เพื่อน-เพื่อน ใครรู้จักใคร
• Key-Value Store: เก็บรูปภาพ วิดีโอ ค้นหาง่าย

ตัวอย่างการใช้งานจริง:

SQL แบบเดิม: 
ตาราง Users | ID | ชื่อ | นามสกุล | อีเมล |
เพิ่มคอลัมน์ "งานอดิเรก" = ต้องแก้ทั้งตาราง

NoSQL แบบใหม่:
User 1: { "ชื่อ": "สมชาย", "งานอดิเรก": ["อ่านหนังสือ", "เล่นเกม"] }
User 2: { "ชื่อ": "สมหญิง", "ที่อยู่": {...}, "สัตว์เลี้ยง": [...] }
เพิ่มข้อมูลอะไรก็ได้ ไม่ต้องแก้โครงสร้าง

4. ศิลปะการคัดลอกข้อมูล (Replication)

ตัวอย่าง: ระบบ LINE ในเอเชีย

LINE มีผู้ใช้กระจายทั่วเอเชีย ถ้าเก็บข้อมูลแค่ที่ญี่ปุ่น คนไทยส่งข้อความไปเกาหลี จะต้องส่งสัญญาณไปญี่ปุ่นก่อน ช้ามาก!

วิธีแก้: Replication – คัดลอกข้อมูลไปหลายที่

แบบ Master-Slave:

• เซิร์ฟเวอร์หลัก (Master) เก็บข้อมูลจริง
• เซิร์ฟเวอร์สำรอง (Slave) คัดลอกจากหลัก
• อ่านข้อมูลจากสำรองได้ (ลดภาระตัวหลัก)
• เขียนข้อมูลที่หลักเท่านั้น (ป้องกันความสับสน)

ปัญหาที่เจอ: ข้อความใหม่มาที่เซิร์ฟเวอร์หลัก แต่ยังไม่ทันคัดลอกไปสำรอง ผู้ใช้อ่านจากสำรองจะไม่เห็นข้อความล่าสุด

วิธีแก้ในโลกจริง:

• Read-after-write consistency: หลังส่งข้อความ บังคับอ่านจากหลักสักพักหนึ่ง
• Async replication: คัดลอกไปสำรองแบบไม่รอ (เร็วแต่อาจไม่ทันเวลา)
• Sync replication: คัดลอกแล้วรอให้เสร็จ (ช้าแต่ทันเวลา)

5. การแบ่งข้อมูล (Partitioning/Sharding)

ตัวอย่าง: ระบบจองตั้วยาวของ Grab

ช่วงเก็บค่าแท็กซี่ Grab มีข้อมูลการเดินทางเป็นล้านล้านรายการ ถ้าเก็บในฐานข้อมูลเดียว จะช้ามากและพังง่าย

วิธีแก้: Sharding – แบ่งข้อมูลไปเก็บหลายเครื่อง

วิธีแบ่งแบบต่างๆ:

1. แบ่งตามพื้นที่:
   • Shard 1: กรุงเทพและปริมณฑล
   • Shard 2: ภาคเหนือ
   • Shard 3: ภาคใต้
2. แบ่งตาม Hash:
   • เอา User ID มา hash ได้เลข 0-100
   • 0-33 ไป Shard A
   • 34-66 ไป Shard B
   • 67-100 ไป Shard C

ปัญหาที่พบ:

• Hot Shard: ถ้าคนกรุงเทพใช้เยอะ Shard กรุงเทพจะโหลดหนักกว่าอื่น
• Cross-Shard Query: อยากดูสถิติทั้งประเทศต้องไปถามทุก Shard
• Rebalancing: ข้อมูลเยอะขึ้น ต้องเพิ่ม Shard ใหม่ แต่ย้ายข้อมูลเก่ายาก

6. บทเรียนจาก Transaction – สัญญาที่ต้องรักษา

เรื่องจริง: วิกฤติ Knight Capital ปี 2012

บริษัทเทรดหุ้น Knight Capital เปิดระบบซื้อขายใหม่ เพื่อประหยัดเวลา พวกเขาไม่ใช้ Transaction กับการซื้อขายหุ้น

ผลลัพธ์: ใน 45 นาที ระบบซื้อหุ้นผิดคำสั่ง เสียเงิน 440 ล้านดอลลาร์ บริษัทเกือบล้มละลาย!

Transaction คืออะไร?

เหมือนสัญญาที่ว่า “ทำให้สำเร็จทุกขั้นตอน หรือไม่ทำเลย”

ตัวอย่างโอนเงิน:

1. ตรวจสอบเงินในบัญชีผู้ส่ง
2. หักเงินจากบัญชีผู้ส่ง
3. เพิ่มเงินให้บัญชีผู้รับ
4. บันทึกประวัติการโอน

ถ้าขั้นตอนใดล้มเหลว ต้องยกเลิกทุกขั้นตอน ไม่งั้นเงินหายหรือเพิ่มจากอากาศ

ACID Properties:

• Atomicity: ทำให้สำเร็จหมด หรือไม่ทำเลย
• Consistency: ข้อมูลถูกต้องตามกฎที่กำหนด
• Isolation: แต่ละ Transaction ไม่รบกวนกัน
• Durability: เสร็จแล้วต้องไม่หาย แม้ไฟดับ

7. เมื่อหลายเครื่องต้องตกลงกัน (Consensus)

ตัวอย่าง: ระบบเลือกตั้งออนไลน์

ลองคิดถึงการเลือกตั้งออนไลน์ ต้องเก็บคะแนนในเซิร์ฟเวอร์หลายเครื่อง แต่เซิร์ฟเวอร์บางเครื่องอาจพัง เน็ตอาจช้า แล้วจะมั่นใจได้ยังไงว่าทุกเครื่องนับคะแนนเหมือนกัน?

ปัญหา Byzantine Generals:

นักรบ 3 นายพล ล้อมกรุงศัตรู ต้องตกลงกันว่าจะรุกหรือถอน ถ้าไม่พร้อมเพรียงจะแพ้ แต่:

• นายพลบางคนอาจเป็นสายลับ (โหวตเท็จ)
• ระบบสื่อสารขาด (ข้อความไม่ถึง)
• ข้อความถูกแก้ไขกลางทาง

วิธีแก้ในระบบคอมพิวเตอร์:

Raft Algorithm (ง่ายกว่า Paxos):

1. มีผู้นำ (Leader) คนหนึ่ง
2. ผู้นำเสนอความเห็น
3. ข้างมาก (Majority) เห็นด้วยถึงจะทำ
4. ถ้าผู้นำหาย เลือกใหม่

ตัวอย่างการใช้จริง:

• etcd (Kubernetes ใช้เก็บการตั้งค่า)
• Consul (Service Discovery)
• Apache Kafka (Message Queue)

8. การประมวลผลข้อมุลยุคใหม่

Stream Processing กับ Batch Processing

ตัวอย่าง Batch: งานบัญชีประจำเดือน

• รวบรวมใบเสร็จทั้งเดือน
• ประมวลผลทีเดียวทั้งหมด
• ได้รายงานเสร็จสิ้น
• ใช้เวลานาน แต่ประมวลผลได้เยอะ

ตัวอย่าง Stream: การแจ้งเตือนธนาคาร

• ลูกค้าจ่ายเงิน
• ระบบตรวจสอบทันที
• ส่ง SMS แจ้งทันที
• ประมวลผลเร็ว แต่ทีละรายการ

Lambda Architecture: รวมจุดเด่นทั้งสอง

• Batch Layer: ประมวลผลข้อมูลใหม่ทุกวัน (ช้าแต่ครบถ้วน)
• Speed Layer: ประมวลผลข้อมูลใหม่ทันที (เร็วแต่อาจไม่ครบ)
• Serving Layer: รวมผลลัพธ์จากทั้งสองชั้น

ตัวอย่างจริง: ระบบแนะนำสินค้า

• Batch: วิเคราะห์พฤติกรรมลูกค้าทั้งเดือน อัปเดตโมเดล AI
• Stream: ลูกค้าดูสินค้า แนะนำทันทีตามที่เคยซื้อ
• Serving: รวมผลจากทั้งสอง แนะนำที่ดีที่สุด

สรุป: บทเรียนสำคัญจากโลกแห่งข้อมูล

หลังจากอ่านหนังสือเล่มนี้จนจบ มีบทเรียนสำคัญที่ Kleppmann อยากให้เราจำ:

1. ไม่มีเทคโนโลยีไหนเหมาะกับทุกสถานการณ์

เหมือนเครื่องมือช่าง ประแจใช้ขันน็อต ค้อนใช้ตอกตะปู ใช้ผิดที่จะเจ็บตัว

• MySQL: ดีสำหรับข้อมูลที่มีความสัมพันธ์ซับซ้อน (ธนาคาร ร้านค้า)
• MongoDB: ดีสำหรับข้อมูลแบบเอกสาร (บล็อก โปรไฟล์)
• Redis: ดีสำหรับข้อมูลที่ต้องเข้าถึงเร็ว (Cache, Session)
• Cassandra: ดีสำหรับข้อมูลจำนวนมหาศาลที่ต้อง Scale (IoT, Log)

2. เข้าใจหลักการก่อนเลือกเครื่องมือ

เทคโนโลยีเปลี่ยนเร็ว แต่หลักการยังคงเหมือนเดิม:

• CAP Theorem: เลือกได้แค่ 2 ใน 3 (Consistency, Availability, Partition tolerance)
• ACID vs BASE: เลือกระหว่างความถูกต้องกับประสิทธิภาพ
• Normalization vs Denormalization: เลือกระหว่างประหยัดพื้นที่กับความเร็ว

3. วัดผลจากการใช้งานจริง ไม่ใช่การโฆษณา

อย่าเชื่อโบรชัวร์ วัดเอง:

• Latency: เร็วแค่ไหนในสถานการณ์จริง?
• Throughput: รับได้กี่คำขอต่อวินาที?
• Availability: เซิร์ฟเวอร์ดาวน์บ่อยมั้ย?
• Consistency: ข้อมูลถูกต้องเสมอมั้ย?

4. การออกแบบที่ดีคือการเตรียมรับการเปลี่ยนแปลง

ระบบที่ดีต้องปรับตัวได้:

• Modularity: แบ่งเป็นชิ้นเล็กๆ เปลี่ยนชิ้นเดียวไม่กระทบอื่น
• Monitoring: รู้ทันทีเมื่อมีปัญหา
• Documentation: คนใหม่อ่านแล้วเข้าใจ
• Testing: ทดสอบก่อนเปิดใช้จริง

การเดินทางที่ยังไม่สิ้นสุด

“Designing Data-Intensive Applications” ไม่ใช่แค่หนังสือเทคนิค แต่เป็นเหมือนแผนที่สำหรับการเดินทางในโลกแห่งข้อมูล มันทำให้เราเข้าใจว่าเหตุใดเราถึงใช้ Google ค้นหาได้ในพริบตา ทำไม Facebook รู้จักเพื่อนที่เราอาจรู้จัก และทำไมเราสามารถ streaming Netflix ได้ไม่สะดุด

ที่สำคัญกว่านั้น มันสอนให้เราคิดแบบ System Thinker – มองเห็นภาพใหญ่ เข้าใจว่าทุกชิ้นส่วนเชื่อมโยงกันอย่างไร และเตรียมพร้อมสำหรับปัญหาที่ยังไม่เกิดขึ้น

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

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

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

#hrรีพอร์ต