IT General
Distributed Systems Fundamentals
Distributed Systems Fundamentals คืออะไร / ทำไมถึงสำคัญ
น้องๆ เคยสงสัยไหมว่า ทำไม Facebook, Google หรือ LINE มันไม่เคยล่มเลย? หรือถ้าล่ม ก็แป๊บเดียวเดี๋ยวก็กลับมา? นั่นแหละคือพลังของ Distributed Systems หรือระบบกระจายศูนย์ พูดง่ายๆ คือ แทนที่เราจะเอาระบบทั้งหมดไปกองไว้ที่คอมพิวเตอร์เครื่องเดียว (Monolithic) เราก็แบ่งมันออกเป็นส่วนๆ แล้วกระจายไปไว้หลายๆ เครื่อง
สมัยผมทำร้านเน็ต SiamCafe.net เมื่อ 20 กว่าปีที่แล้ว ระบบยังไม่ซับซ้อนขนาดนี้ แต่ก็เริ่มเห็นเค้าลางแล้วว่าถ้าทุกอย่างมากองอยู่ที่ Server ตัวเดียว มีหวังเจ๊งแน่นอน! ลองนึกภาพว่าถ้ามีคนเข้ามาเล่นเกมพร้อมกัน 100 คน แล้ว Server ดับไป จะเกิดอะไรขึ้น? ลูกค้าโวยวายสิครับ!
Distributed Systems เลยเข้ามาแก้ปัญหานี้แหละครับ มันช่วยให้ระบบเรา Scale ได้ดีขึ้น (รองรับผู้ใช้งานได้มากขึ้น), Fault-tolerant (ถ้าเครื่องนึงพัง เครื่องอื่นก็ยังทำงานต่อได้) และ Performance ดีขึ้น (เพราะโหลดมันกระจายๆ กันไป)
พื้นฐานที่ต้องรู้
CAP Theorem: Consistency, Availability, Partition Tolerance
อันนี้เป็นทฤษฎีพื้นฐานที่ต้องเข้าใจเลยครับ CAP Theorem บอกว่า เราไม่สามารถมีทั้ง Consistency (ข้อมูลทุกเครื่องเหมือนกัน), Availability (ระบบพร้อมใช้งานตลอดเวลา) และ Partition Tolerance (ระบบยังทำงานได้แม้บางส่วนจะขาดการเชื่อมต่อ) ได้พร้อมๆ กัน เราต้องเลือกว่าจะเน้นอะไร
สมัยผมทำร้านเน็ต ผมเลือก Availability เป็นหลัก เพราะถ้าเกมเล่นไม่ได้ ลูกค้าก็เดินออกไปเลย! ข้อมูลบางอย่างอาจจะไม่เป๊ะ 100% แต่ระบบต้องใช้งานได้ตลอดเวลา
Consensus Algorithms: Raft, Paxos
Consensus Algorithms คือ Algorithms ที่ใช้เพื่อให้หลายๆ เครื่องในระบบเห็นตรงกัน (Agree) ในเรื่องใดเรื่องหนึ่ง เช่น ใครเป็น Leader, ข้อมูลอะไรถูกเขียนลงไปแล้วบ้าง
Raft กับ Paxos เป็น Algorithms ที่ได้รับความนิยม Raft จะเข้าใจง่ายกว่า Paxos แต่ Paxos ก็มีมานานกว่า
Message Queues: RabbitMQ, Kafka
Message Queues คือตัวกลางที่ใช้ส่งข้อความ (Message) ระหว่าง Services ต่างๆ ใน Distributed Systems ลองนึกภาพว่ามี Services A ต้องการส่งข้อมูลไปให้ Service B แทนที่จะส่งตรงๆ ก็ส่งผ่าน Message Queue ก่อน แล้วให้ Service B ค่อยมาดึงข้อมูลไป
Message Queues ช่วยให้ Services ต่างๆ ไม่ต้องคุยกันโดยตรง (Decoupled) และทำให้ระบบมีความยืดหยุ่นมากขึ้น
วิธีใช้งาน / เริ่มต้นยังไง
เอาล่ะ มาถึงส่วนที่สำคัญที่สุด คือเราจะเริ่มใช้งาน Distributed Systems ยังไง? บอกเลยว่ามันไม่ได้ยากอย่างที่คิด แต่ก็ต้องค่อยๆ เป็น ค่อยๆ ไป
สมัยผมเริ่มทำระบบหลังบ้านของ SiamCafe.net ผมเริ่มจากการแยก Database ออกเป็นหลายๆ ตัว แล้วใช้ Replication เพื่อให้ข้อมูลมัน Sync กัน ตอนนั้นยังไม่มี Cloud Services อะไรแบบนี้ ต้องทำเองหมด!
ขั้นตอนปฏิบัติจริง
1. เลือก Architecture ที่เหมาะสม
Distributed Systems มีหลาย Architecture ให้เลือก เช่น Microservices, Message Queue, Shared Database แต่ละ Architecture ก็มีข้อดีข้อเสียต่างกันไป เราต้องเลือกให้เหมาะสมกับความต้องการของเรา
Microservices เป็น Architecture ที่ได้รับความนิยมในปัจจุบัน เพราะมันช่วยให้เราพัฒนาและ Deploy Services ต่างๆ ได้อย่างอิสระ แต่ก็ต้องแลกมาด้วยความซับซ้อนที่มากขึ้น
2. Implement Monitoring และ Logging
Monitoring และ Logging เป็นสิ่งสำคัญมากๆ ใน Distributed Systems เพราะมันช่วยให้เราเห็นภาพรวมของระบบ และรู้ว่ามีอะไรผิดปกติเกิดขึ้น
สมัยผมทำร้านเน็ต ผมจะ Monitor CPU Usage, Memory Usage และ Network Traffic ของ Server ทุกตัว ถ้ามีอะไรผิดปกติ ก็จะรีบเข้าไปดูทันที
3. Testing, Testing, Testing!
การ Testing เป็นสิ่งสำคัญมากๆ ใน Distributed Systems เพราะมันช่วยให้เรามั่นใจว่าระบบเราทำงานได้อย่างถูกต้อง
ต้อง Test ทั้ง Unit Test, Integration Test และ End-to-End Test อย่าขี้เกียจ Test นะน้องๆ ไม่งั้นเดี๋ยวเจอปัญหาตอน Production แน่นอน!
// ตัวอย่าง code (สมมติว่าเป็น Python)
def add(a, b):
return a + b
def test_add():
assert add(2, 3) == 5
assert add(-1, 1) == 0
assert add(0, 0) == 0
เปรียบเทียบกับทางเลือกอื่น
แน่นอนว่า Distributed Systems ไม่ใช่คำตอบสำหรับทุกอย่าง มันก็มีข้อเสียของมันเหมือนกัน ทางเลือกอื่น เช่น Monolithic Architecture ก็ยังมีข้อดีของมันอยู่
Monolithic Architecture เหมาะสำหรับ Project ขนาดเล็กที่ไม่ซับซ้อนมาก เพราะมันง่ายต่อการพัฒนาและ Deploy แต่ถ้า Project ใหญ่ขึ้นเรื่อยๆ Distributed Systems จะเป็นทางเลือกที่ดีกว่า
| Feature | Monolithic Architecture | Distributed Systems |
|---|---|---|
| Complexity | ต่ำ | สูง |
| Scalability | จำกัด | ดีมาก |
| Fault Tolerance | ต่ำ | สูง |
| Development Speed | เร็ว | ช้า (ในช่วงแรก) |
| Deployment | ง่าย | ซับซ้อน |
สุดท้ายแล้ว การเลือกว่าจะใช้ Architecture แบบไหน ขึ้นอยู่กับความต้องการและข้อจำกัดของแต่ละ Project ไม่มีอะไรถูกหรือผิดเสมอไป
ลองเข้าไปดูบทความอื่นๆ ใน SiamCafe Blog นะครับ อาจจะมีอะไรที่เป็นประโยชน์กับน้องๆ ก็ได้
น้องๆ ที่สนใจเรื่อง IT ลองแวะไปอ่านบทความอื่นๆ ที่ SiamCafe Blog ได้นะ มีเรื่องน่าสนใจเยอะเลย!
Best Practices / เคล็ดลับจากประสบการณ์
เอาล่ะน้องๆ หลังจากที่เรารู้พื้นฐาน Distributed Systems กันไปแล้ว คราวนี้มาดู Best Practices หรือเคล็ดลับที่พี่บอมสั่งสมมาจากการทำร้านเน็ต SiamCafe ตั้งแต่ยุคบุกเบิกกันบ้างดีกว่า บอกเลยว่าแต่ละข้อเนี่ย ผ่านร้อนผ่านหนาวมาเยอะ เจ็บจริงอะไรจริง!
เทคนิคที่ 1: Simplify Everything
สมัยพี่ทำร้านเน็ตใหม่ๆ ไฟแรงไง อยากทำอะไรที่มันซับซ้อน เท่ๆ แต่สุดท้ายปวดหัวเอง! บทเรียนคือ ทำให้ทุกอย่างมันง่ายเข้าไว้ครับน้อง ระบบที่ซับซ้อน = จุดผิดพลาดเยอะ แก้ไขยาก เสียเวลา
ยกตัวอย่างง่ายๆ สมมติเราจะทำระบบเก็บ Log ไฟล์ สมัยก่อนพี่เคยใช้สารพัด Database สุดท้ายมาจบที่ Text File ธรรมดานี่แหละ อ่านง่าย แก้ไขง่าย grep หาอะไรก็สะดวก
# tail -f access.log | grep "error"
เทคนิคที่ 2: Design for Failure
เชื่อพี่เถอะน้อง อะไรๆ ก็พังได้! ไม่ว่าจะเป็น Server ไฟดับ Network ล่ม Harddisk เจ๊ง ดังนั้นออกแบบระบบให้มัน "เผื่อ" พังไว้ด้วยเสมอ
สมัยก่อน Server ร้านเน็ตพี่มี Redundant Power Supply (PSU) 2 ตัว ตัวนึงพัง อีกตัวก็ทำงานต่อได้ทันที หรือ RAID ก็ช่วยได้เยอะ ถ้า Harddisk ตัวนึงเสีย ข้อมูลก็ยังอยู่ครบ
เทคนิคที่ 3: Monitor Everything
"ถ้าเราวัดอะไรไม่ได้ เราก็ปรับปรุงมันไม่ได้" อันนี้เป็นคติประจำใจพี่เลย น้องต้อง Monitor ทุกอย่างในระบบ ตั้งแต่ CPU Usage, Memory Usage, Disk I/O, Network Traffic ไปจนถึงจำนวน Users ที่ Login
สมัยก่อนพี่ใช้ MRTG (Multi Router Traffic Grapher) ในการ Monitor Traffic Network ของร้านเน็ต ทำให้รู้ว่า Bandwidth พอหรือไม่ หรือมีใครแอบโหลด BitTorrent อยู่รึเปล่า!
เทคนิคที่ 4: Automate Everything (Possible)
อะไรที่ทำซ้ำๆ ได้ ให้ Automate ซะ! ไม่ต้องเสียเวลาทำเอง ลดโอกาสผิดพลาด แถมยัง Scale ได้ง่ายอีกด้วย
สมัยก่อนพี่ใช้ Script ง่ายๆ ในการ Backup ข้อมูลทุกวัน หรือ Deploy Program ใหม่ๆ ไปยัง Client ทุกเครื่อง
#!/bin/bash
rsync -avz /data/ backup_server:/backup/
FAQ คำถามที่พบบ่อย
Q: Distributed Systems ยากไหม?
A: ยาก! (ตอบแบบตรงๆ) แต่ถ้าเราเข้าใจพื้นฐาน Concept ต่างๆ และ Practice บ่อยๆ ก็ไม่ยากเกินไปแน่นอน เหมือนหัดขี่จักรยานนั่นแหละ
Q: ต้องเรียนภาษาอะไรบ้าง?
A: ขึ้นอยู่กับว่าน้องอยากทำอะไร ถ้า Backend ก็พวก Java, Python, Go ถ้า Frontend ก็ JavaScript แต่ที่สำคัญกว่าภาษาคือ Algorithm และ Data Structure ครับ
Q: เริ่มต้นยังไงดี?
A: เริ่มจาก Project เล็กๆ ครับ ลองทำ API ง่ายๆ สักตัว หรือลอง Deploy Application บน Cloud ง่ายๆ ดูก่อน แล้วค่อยๆ ขยับไปทำ Project ที่ใหญ่ขึ้น
Q: Distributed Systems เหมาะกับ Project แบบไหน?
A: เหมาะกับ Project ที่มี Traffic เยอะๆ ต้องการ High Availability และต้องการ Scale ได้ง่ายๆ เช่น Social Media, E-commerce, Streaming Services
สรุป
Distributed Systems เป็นเรื่องที่ท้าทาย แต่ก็สนุกและมีประโยชน์มากๆ ถ้าเราเข้าใจ Concept และ Best Practices ต่างๆ ก็จะสามารถสร้างระบบที่ Scalable, Reliable และ Maintainable ได้ iCafeForex ก็เป็นอีกหนึ่งตัวอย่างที่ใช้ Distributed Systems ในการจัดการ Transaction จำนวนมหาศาล
อย่ากลัวที่จะลองผิดลองถูกครับน้อง ไม่มีใครเก่งมาตั้งแต่เกิด ทุกคนต้องเริ่มจาก 0 ทั้งนั้น และอย่าลืมติดตาม SiamCafe Blog นะครับ พี่จะคอยอัพเดท Tips and Tricks ดีๆ เกี่ยวกับ IT ให้เรื่อยๆ
