[Review] Designing Data+AI System That Last ในงาน Data+AI Day 2025: Empowering Intelligence

[Review] Designing Data+AI System That Last ในงาน Data+AI Day 2025

Technology 20

เคยสงสัยไหมว่า ทำไมบางระบบพัฒนาไปได้เรื่อย ทนทานต่อการเปลี่ยนแปลง และง่ายต่อการเพิ่มฟีเจอร์ใหม่ ๆ แต่บางระบบทำไม่ได้แบบนั้น ? 🤔

คุณกานต์ ตำแหน่ง Data Product Developer & Technical Enabler จาก ODDS-TEAM จะชวนทุกคนมาขบคิดเรื่อง “Designing Data+AI System that last” ว่าจะทำยังไงให้ระบบที่เราสร้างทนทานต่อการเปลี่ยนแปลงของเทคโนโลยี และธุรกิจที่เปลี่ยนไปทุกวัน

บทความนี้เป็นการสรุป Session Designing Data+AI System That Last ในงาน Data+AI Data 2025: Empowering Intelligence

เลือกอ่านเฉพาะหัวข้อ -
3 ทักษะสำคัญในการพัฒนา Software อย่างยั่งยืน
1. Translating Business Driver into Architecture Decision
Functional Requirements คุณสมบัติพื้นฐานที่จำเป็น
Non-Functional Requirements คุณสมบัติของระบบที่ควรจะเป็น
Common Non-Functional Characteristics ที่ควรรู้:
2. Evaluating Trade-offs and Making Informed Choices
ควรใช้ Apache Airflow หรือ N8N?
Model สำหรับเปรียบเทียบและตัดสินใจทาง Technical
1. Performance (ประสิทธิภาพ)
2. Scalability (การขยายตัว)
3. Data Model (โครงสร้างข้อมูล)
4. Integration (การเชื่อมต่อ)
5. High Availability (ความพร้อมใช้งานสูง)
6. Operation Complexity (ความซับซ้อนในการดูแล)
7. Cost (ค่าใช้จ่าย)
8. Community Support (ชุมชนและการสนับสนุน)
ตัวอย่างการเปรียบเทียบ: Apache Airflow vs N8N
3. Expanding Technical Breadth While Keeping Sufficient Depth
Key Takeaway

3 ทักษะสำคัญในการพัฒนา Software อย่างยั่งยืน

1. Translating Business Driver into Architecture Decision

เปลี่ยน Business Requirement ให้เป็น Software Requirement ซึ่งเหมือนกับการสร้างบ้าน – ไม่ใช่แค่รู้ว่า “อยากได้บ้าน” แต่ต้องรู้ว่าอยากได้บ้านแบบไหนระหว่าง บ้านริมทะเล กับ บ้านชานเมือง เพราะแบบแปลนของบ้านสองแบบนี้มีข้อกำหนดที่แตกต่างกันโดยสิ้นเชิง:

บ้านริมทะเล 🏖️

  • ต้องใช้วัสดุทนต่อการกัดเซาะของน้ำเค็ม
  • ต้องมีฐานรากที่แข็งแรงรับแรงคลื่น
  • ต้องมีระบบระบายน้ำที่ดี

บ้านชานเมือง 🏡

  • เน้นความสะดวกสบาย ความเป็นส่วนตัว
  • ไม่ต้องลงทุนกับระบบกันน้ำทะเลราคาแพง
  • เน้นพื้นที่ใช้สอยและการจอดรถ

หากเชื่อมโยงกับการพัฒนา Software โดยปกติการพัฒนา Software ให้ใช้งานได้เราต้องเข้าใจ 2 มิติของความต้องการ:

Functional Requirements คุณสมบัติพื้นฐานที่จำเป็น

Functional Requirements คือ สิ่งที่ระบบ “ทำได้” เป็นฟีเจอร์ที่ผู้ใช้งานเห็นและใช้งานโดยตรง

ตัวอย่าง Functional Requirements

  • ผู้ใช้สามารถ Login/Logout ได้
  • แสดงรายการสินค้าพร้อมราคา
  • เพิ่มสินค้าใส่ตะกร้าได้

คล้ายกับ: บ้านต้องมีประตู หน้าต่าง ห้องนอน ห้องน้ำ

Functional Requirements ตอบคำถาม: “ระบบต้องทำอะไรได้บ้าง?”

Non-Functional Requirements คุณสมบัติของระบบที่ควรจะเป็น

Non-Functional Requirements คือ สิ่งที่ระบบ “เป็น” เป็นคุณภาพและลักษณะการทำงานของระบบ เป็นคุณสมบัติเฉพาะที่มักถูกมองข้าม แต่สำคัญต่อการทำให้ Software ยืนระยะการทำงานได้นาน ทำให้ระบบของเรา

  • เมื่อถูกแฮกก็กู้คืนได้ง่าย
  • เมื่อผู้ใช้งานมากขึ้นระบบยังทำงานได้เร็วเหมือนเดิม

คล้ายกับ: บ้านต้องทนทานต่อแผ่นดินไหว, ตั้งอยู่ได้นาน 50 ปี, เก็บเสียงได้ดี

Non-Functional Requirements ตอบคำถาม: “ระบบต้องทำงานอย่างไรให้ดี?”

Common Non-Functional Characteristics ที่ควรรู้:

รายการ Non-functional characteristics ที่ควรคำนึงถึง

1. Performance (ประสิทธิภาพ)

ระบบทำงานได้เร็วแค่ไหน ใช้ทรัพยากรเท่าไหร่ ?

ตัวอย่าง:

  • API ตอบกลับภายใน 200ms
  • ประมวลผล 1 ล้านรายการต่อวินาที

ความสำคัญ:

  • User Experience: ผู้ใช้ไม่ต้องรอ → พึงพอใจมากขึ้น
  • ต้นทุน: ประมวลผลเร็ว = ใช้ Server น้อยลง = ค่าใช้จ่ายต่ำลง
  • Revenue: Amazon พบว่าระบบช้าขึ้น 100ms → ยอดขายลด 1%
2. Scalability (ความสามารถในการขยายตัว)

ระบบรองรับผู้ใช้งานหรือข้อมูลที่เพิ่มขึ้นได้ดีแค่ไหน ? โดยไม่ทำให้ช้าลง

รูปแบบการ Scaling หรือการขยายประสิทธิภาพมี 2 แบบใหญ่ ๆ ดังนี้

  • Horizontal Scaling: เพิ่มจำนวน Server (เหมือนเพิ่มคนทำงาน)
  • Vertical Scaling: อัพเกรด Server (เหมือนทำให้คนทำงานเก่งขึ้น)

ตัวอย่าง: ระบบรองรับผู้ใช้จาก 1,000 เป็น 1 ล้านคนได้ไหม

ความสำคัญ:

  • ธุรกิจเติบโต → ลูกค้าเพิ่มขึ้น → ระบบต้องรับได้
  • ถ้าไม่สามารถ Scale ได้ → ต้องเขียนระบบใหม่ทั้งหมด
3. Data Integrity (ความถูกต้องของข้อมูล)

ข้อมูลถูกต้อง สมบูรณ์ ไม่มีการสูญหายหรือเสียหายหรือไม่ ? เมื่อเกิดปัญหา

ตัวอย่าง: ยอดเงินในบัญชีต้องตรงทุกครั้ง, Transaction ต้องไม่หาย

เทคนิค: Database Constraints, Validation, ACID Properties

4. Data Consistency (ความสอดคล้องของข้อมูล)

ข้อมูลในระบบต่าง ๆ สอดคล้องกันครบถ้วยมั้ย ?

โดยรูปแบบการจัดการความสอดคล้องของข้อมูลอาจจะมองได้ใน 2 มุมดังนี้

  • Strong Consistency: ข้อมูลอัพเดททันทีทุกที่ (เหมาะกับธนาคาร)
  • Eventual Consistency: ข้อมูลจะสอดคล้องในที่สุด (เหมาะกับ Social Media)

ตัวอย่าง: โพสต์ Facebook อาจใช้เวลากระจายไปทุก Server

5. Availability (ความพร้อมใช้งาน)

ระบบทำงานได้ตลอดเวลา มี Downtime น้อย

โดยอาจจะกำหนดเป็น Service Level Agreement (SLA) เมื่อเกิดปัญหา ต้องสามารถกลับมาใช้ได้ตามเงื่อนไข ไม่งั้นจะส่งผลเสียต่อธุรกิจ เช่น

  • 99.9%: ระบบใช้งานไม่ได้ไม่เกิน 8.76 ชั่วโมงต่อปี
  • 99.99%: ระบบใช้งานไม่ได้ไม่เกิน 52 นาทีต่อปี
6. Fault Tolerance (ความทนทานต่อความผิดพลาด)

ระบบยังทำงานได้แม้บางส่วนพังหรือไม่ ?

ตัวอย่าง: Server 1 ตัวล่ม ระบบยังใช้ได้ผ่าน Server อื่น

เทคนิค: Redundancy, Backup Systems, Circuit Breaker

7. Responsiveness (การตอบสนอง)

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

ตัวอย่าง: กดปุ่มแล้วเห็น Loading ทันที

8. Elasticity (ความยืดหยุ่นของทรัพยากร)

ปรับทรัพยากรอัตโนมัติตามความต้องการ

ตัวอย่าง: ช่วงเทศกาลมีคนใช้เยอะ เพิ่ม Server อัตโนมัติ, กลางคืนลดลง ก็ลด Server

ประโยชน์: ประหยัดค่าใช้จ่าย ไม่จ่ายเกินความจำเป็น

9. Testability (ความสะดวกในการทดสอบ)

ระบบสามารถเขียน Test ง่าย หา Bug เจอเร็ว

ตัวอย่าง: Code แยกส่วนดี, Mock ได้ง่าย, CI/CD Pipeline ครบ

ประโยชน์: Deploy มั่นใจ Bug น้อย

10. Recoverability (การกู้คืนระบบ)

กู้ระบบกลับมาใช้ได้เร็วแค่ไหนเมื่อเกิดปัญหา ?

โดยมีตัวแปรที่เราให้ความสนใจดังนี้

  • RTO (Recovery Time Objective): เวลาที่ยอมให้ระบบดับได้
  • RPO (Recovery Point Objective): ข้อมูลสูญหายย้อนหลังได้นานแค่ไหน

ตัวอย่าง: Backup ทุกชั่วโมง กู้คืนได้ภายใน 15 นาที

11. Adaptability (ความสามารถในการปรับตัว)

แก้ไข เปลี่ยนแปลง หรือเพิ่มฟีเจอร์ใหม่ได้ง่ายแค่ไหน ?

ตัวอย่าง: เปลี่ยน AI Model ใหม่ไม่ต้องแก้ทั้งระบบ

เทคนิค: Modular Design, Plugin Architecture

12. Extensibility (ความสามารถในการขยายฟีเจอร์)

ระบบสามารถเพิ่มความสามารถใหม่ ๆ โดยไม่กระทบของเดิมได้หรือไม่ ?

ตัวอย่าง: เพิ่ม Payment Method ใหม่ ไม่ต้องแก้ Core System

เทคนิค: Design Pattern: Open/Closed Principle

13. Interoperability (การทำงานร่วมกับระบบอื่น)

ระบบเชื่อมต่อกับ Service อื่น ๆ ได้ง่ายแค่ไหน ?

ตัวอย่าง: รองรับ REST API, GraphQL, Message Queue

ประโยชน์: Integrate กับระบบภายนอกได้รวดเร็ว

14. Concurrency (การทำงานพร้อมกัน)

จัดการ Request หลาย ๆ อันพร้อมกันได้มากแค่ไหน ?

ตัวอย่าง: 1,000 คนกดซื้อสินค้าชิ้นเดียวกันพร้อมกัน ต้องไม่ขายเกิน Stock

เทคนิค: Locking, Queue, Event-driven Architecture

15. Deployability (ความสะดวกในการ Deploy)

สามารถปล่อยระบบขึ้น Production ง่ายและปลอดภัยแค่ไหน ?

ตัวอย่าง: Deploy ได้วันละหลายรอบ, Rollback ได้ทันที

เทคนิค: CI/CD, Blue-Green Deployment, Canary Release

16. Configurability (การตั้งค่าได้)

เปลี่ยนพฤติกรรมระบบผ่าน Config ได้ ไม่ต้อง Deploy ใหม่ได้มั้ย ?

ตัวอย่าง: เปลี่ยน Timeout, API Key, Feature Flag

ประโยชน์: ปรับแต่งได้เร็ว ไม่ต้องรอ Deploy

2. Evaluating Trade-offs and Making Informed Choices

การพัฒนา Software มี Trade-offs เสมอ (ข้อแลกเปลี่ยน) เสมอ อย่างเช่น

  • เลือกความเร็ว → อาจเสียความปลอดภัย
  • เลือกความยืดหยุ่น → อาจเสียความเรียบง่าย
  • เลือกประหยัดต้นทุน → อาจเสีย Performance

คำถามสำคัญคือเราจะรู้ได้ยังไงว่าควรเลือกอะไร?

ควรใช้ Apache Airflow หรือ N8N?

เครื่องมือข้อดีข้อเสีย
Apache Airflowเหมาะกับ Data Pipeline ซับซ้อน
Scalable มาก รองรับ Task หลักหมื่นรายการ		Setup ยาก ต้องมีความรู้ Python
Resource-intensive ต้องใช้ Server แรง
N8Nใช้งานง่าย มี UI แบบ Drag-and-Drop
Setup เร็ว เหมาะกับทีมเล็ก		Scalability ต่ำ
ควรใช้ Apache Airflow หรือ N8N?

คำตอบขึ้นอยู่กับ:

  • ทีมมีความรู้ Python มากแค่ไหน?
  • Pipeline ซับซ้อนขนาดไหน?
  • งบประมาณ Infrastructure เท่าไหร่?

ไม่ว่าจะคำถามไหน ก็ไม่คำตอบตายตัว ขึ้นอยู่กับบริบทและการให้ความสำคัญ แต่หลาย ๆ ครั้งเราพบว่า เราเลือกได้ไม่ชัดเจน เพราะเราไม่แน่ใจว่าต้องพิจารณาในมุมไหนบ้าง หรือเราในฐานะผู้พัฒนามีข้อจำกัดอะไรบ้าง (เวลา ทรัพยากร)

Model สำหรับเปรียบเทียบและตัดสินใจทาง Technical

หากจะต้องเลือก Technology ที่ต้องใช้ในการพัฒนาระบบ ควรคำนึงถึงสิ่งเหล่านี้

1. Performance (ประสิทธิภาพ)

วัดประสิทธิภาพผ่าน Throughput, Latency และ Resource Usage

ตัวอย่าง:

  • Apache Kafka: ส่งข้อความได้ล้านต่อวินาที
  • Redis: อ่านข้อมูลเร็วมาก (< 1ms)

คำถามประกอบการตัดสินใจ: ระบบต้องการความเร็วขนาดไหน?

2. Scalability (การขยายตัว)

เทคโนโลยีรองรับ Horizontal หรือ Vertical Scaling แค่ไหน ?

ตัวอย่าง:

  • MongoDB: Scale แนวนอนง่าย (Sharding)
  • PostgreSQL: Scale แนวตั้งดีกว่า แต่ Scale แนวนอนยาก

คำถามประกอบการตัดสินใจ: คาดการณ์การเติบโตอย่างไร? (10x, 100x, 1000x?)

3. Data Model (โครงสร้างข้อมูล)

Technology นั้นเหมาะกับการเก็บข้อมูลอย่างไรระหว่าง Relational vs NoSQL vs Graph ?

ตัวอย่าง:

  • PostgreSQL: ดีสำหรับข้อมูลที่มี Relationship ซับซ้อน
  • MongoDB: เหมาะกับข้อมูลที่โครงสร้างเปลี่ยนบ่อย
  • Neo4j: เหมาะกับ Graph Data (Social Network)

คำถามประกอบการตัดสินใจ: ข้อมูลมีลักษณะอย่างไร? มี Relationship ซับซ้อนไหม?

4. Integration (การเชื่อมต่อ)

Service หรือ Technology นั้นมี API Support, Protocol, Connector สำหรับระบบของเราหรือไม่ ?

ตัวอย่าง:

  • Apache Airflow: มี Operator เชื่อมต่อหลากหลาย
  • Custom Solution: ต้องเขียน Integration เอง

คำถามประกอบการตัดสินใจ: ต้องเชื่อมต่อกับระบบอะไรบ้าง?

5. High Availability (ความพร้อมใช้งานสูง)

การจัดการเรื่องการทำงานกรณีระบบมีปัญหา

ตัวอย่าง:

  • AWS RDS: Multi-AZ Automatic Failover
  • Self-hosted: ต้องจัดการเอง

คำถามประกอบการตัดสินใจ: ยอมให้ระบบดับได้นานแค่ไหน?

6. Operation Complexity (ความซับซ้อนในการดูแล)

เมื่อต้องมาดูแล หรือใช้งานจริงมีความซับซ้อนมากแค่ไหนตั้งแต่การ Setup, Monitoring, Maintenance และ Troubleshooting

ตัวอย่าง:

  • Managed Service (AWS Lambda): ดูแลง่าย แต่ค่าใช้จ่ายสูง
  • Self-hosted (Kubernetes): Flexible แต่ซับซ้อน

คำถามประกอบการตัดสินใจ: Team มีทักษะและเวลาดูแลเองไหม?

7. Cost (ค่าใช้จ่าย)

มีค่าใช้จ่ายในการใช้งาน Service หรือ Technology นั้นยังไงบ้าง ? เช่นค่า License, Infrastructure หรือ Human Resource ในการดูแลระบบ

ตัวอย่าง:

  • Open Source: ไม่มีค่า License แต่มีค่าบำรุงรักษา
  • Enterprise License: มีค่า License แต่ได้ Support
  • Cloud Managed: จ่ายตามใช้งาน (Pay-as-you-go)

คำถามประกอบการตัดสินใจ: มี Budget เท่าไหร่? ต้องจ่ายล่วงหน้าหรือจ่ายตามใช้จริง ถึงจะคุ้มค่ากว่า ?

8. Community Support (ชุมชนและการสนับสนุน)

มี Documentation, Forum หรือ Tutorial ที่ง่ายต่อการศึกษาแค่ไหน ?

ตัวอย่าง:

  • React: Community ใหญ่ หา Solution ง่าย
  • Library ใหม่: Documentation น้อย ต้องลองผิดลองถูก

คำถามประกอบการตัดสินใจ: หา Solution แก้ปัญหาง่ายไหม? มี Expert ช่วยได้ไหม?

ตัวอย่างการเปรียบเทียบ: Apache Airflow vs N8N

CriteriaApache AirflowN8N
Performanceจัดการ Workflow ซับซ้อน ขนาดใหญ่ได้ดีเหมาะกับงานขนาดกลาง-เล็ก
ScalabilityScale ได้ดีมากจำกัด
Data ModelN/AN/A
IntegrationOperator เยอะมาก (1000+)Integration พื้นฐานครบ
High AvailabilityN/AN/A
Operation Complexityซับซ้อน ต้องมีทักษะSetup ง่าย
CostOpen Source + Infrastructure CostOpen Source + Infrastructure Cost
Community SupportCommunity ใหญ่มาก Documentation ครบCommunity กำลังเติบโต
ตัวอย่างการเปรียบเทียบ: Apache Airflow vs N8N

สรุป: Airflow เหมาะกับงานใหญ่ซับซ้อน, N8N เหมาะกับ Team เล็กต้องการความง่าย

3. Expanding Technical Breadth While Keeping Sufficient Depth

ขยายความรู้กว้างทางเทคนิค พร้อมรักษาความเชี่ยวชาญเฉพาะด้าน

Expanding knowledge to see more solutions to the problem

เราไม่สามารถแก้ปัญหาได้ดีที่สุด หากรู้จักทางแก้เพียงวิธีเดียวที่ถนัด การมีความรู้หลากหลายช่วยให้เห็นทางเลือกและแนวทางแก้ปัญหาได้มากขึ้น

Key Takeaway

ออกแบบระบบ Data+AI ที่ดี ไม่ใช่แค่เลือก Technology ที่ Hot ที่สุด แต่คือการ

  • เข้าใจ Business Requirement แบบลึกซึ้ง
  • ชั่งน้ำหนัก Trade-offs อย่างรอบคอบ
  • เปิดใจเรียนรู้เทคโนโลยีใหม่ๆ อย่างต่อเนื่อง

บทความที่เกี่ยวข้อง

พีเตอร์ ผู้ตัดสินใจกระโดดข้ามสายงานจากนักออกแบบ มาสู่โลกแห่งเทคโนโลยี สนใจในเทคโนโลยีใหม่ ๆ ที่จะพัฒนาคุณภาพชีวิตคนให้ดีขึ้น อ่านรายละเอียดเพิ่มเติม