อ่านบทความเรื่องของ Slack’s Migration to a Cellular Architecture
ซึ่งทางระบบของ Slack ทำการ migrate architecture ของระบบ
มาใช้ cell-based architecture เป็นอีกหนึ่ง architecture pattern
โดยอธิบายรายละเอียดจาก AWS นั่นเอง
มีเป้าหมายเพื่อ
- รองรับผู้ใช้งานจำนวนสูง
- ในมุมมองของผู้ใช้งานหรือลูกค้า ระบบต้องสามารถใช้งานได้ตลอดเวลา
- ถ้าระบบมีปัญหาขึ้นมา ต้องสามารถเกิดผลกระทบในกรอบที่จำกัดเท่านั้น ไม่ใช่พังทั้งระบบ (Isolated failure)
เป้าหมายหลัก ๆ ของ Slack นั้น ทำการ migrate เฉพาะ service ที่สำคัญ ๆ เท่านั้น
ทำการย้ายจาก monolith มายัง cell-based architecture
แน่นอนว่า แนวคิดนี้มีทั้งข้อดีและข้อเสียที่ต้องทำความเข้าใจ
มาทำความรู้จักกับ component ต่าง ๆ ของ cell-based architecture
- Cell คือส่วนการทำงานหลัก โดยในแต่ละ cell จะทำงานจบในตัวเอง เป็นอิสระ ทั้งข้อมูล การพัฒนา การ deploy การ monitor/observe รวมทั้ง resource ต่าง ๆ ที่ใช้งาน ใน cell จะมี service ที่จำเป็นต่อการใช้งานใน cell ไปเลย
- Interface คือ ช่องทางการติดต่อของแต่ละ cell ทั้งขาเข้าและออก
- Inter-cell component สำหรับการติดต่อสื่อสารกับ cell จำนวนมาก เช่น Router, Load balance และ Messaging เป็นต้น
เมื่อทำตามนี้แล้วจะได้ระบบตามที่ต้องการข้างต้น
ทั้ง scalability, performance และ resilience
รวมทั้งขอบเขตของปัญหาและการทดสอบก็เล็กลง
แต่ก่อให้เกิดปัญหาตามมาเช่นกัน
- ความซับซ้อนในการสร้างและจัดการ อย่าลืมว่า แต่ละ cell ต้องมี redundant ด้วยนะ (ทั้งใน zone และต่าง zone)
- เพิ่ม overhead ของระบบงาน รวมทั้งค่าใช้จ่ายของ resource ที่ใช้งาน เพราะว่าต้องแยกเป็นอิสระต่อกัน
อีกทั้งเรื่องของการ Isolate หรือแยกกันนั้น
ต้องดูให้ครบทุกมุมมองว่าจะ Isolate แบบไหนบ้าง เช่น
- Physical
- Virtual
- Process
- Network
จะเห็นได้ว่าทุก ๆ pattern นั้นล้วนมีข้อดีและข้อเสีย
เลือกใช้ให้เหมาะกับงาน หรือ requirement ด้วยเสมอ
อย่าลืมว่า เรานำมาใช้งานเพื่อแก้ไขปัญหา หรือ ต้องมีประโยชน์นะครับ !!!
ระวังปัญหาที่อาจจะเกิดขึ้นจาก gap ระหว่าง business, architecture, development และ deployment
อย่าให้เป็นดังรูป
Reference Websites
