Event-Driven Architecture คืออะไร? ระบบตอบสนองทันที

Event-Driven Architecture คืออะไร? ระบบตอบสนองทันที

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

Event-Driven Architecture (EDA) คือแนวคิดการออกแบบระบบที่แก้ปัญหานี้ โดยให้ระบบต่างๆ สื่อสารกันผ่านเหตุการณ์ (event) ที่เกิดขึ้นจริง แทนการวนถามกันเป็นรอบหรือเรียกกันตรงๆ ทีละคู่ บทความนี้อธิบายว่า EDA คืออะไร ประกอบด้วยอะไร เหมาะกับงานโลจิสติกส์อย่างไร และมีข้อควรระวังอะไรบ้างก่อนนำไปใช้

Event-Driven Architecture คืออะไร

EDA คือรูปแบบสถาปัตยกรรมซอฟต์แวร์ที่ระบบหนึ่งประกาศ "เหตุการณ์" เมื่อมีสิ่งสำคัญเกิดขึ้น เช่น "ใบสั่งซื้อถูกสร้าง" "สินค้าถึงประตูรับสินค้า" หรือ "ตู้คอนเทนเนอร์ผ่านด่านศุลกากร" แล้วระบบอื่นที่สนใจเหตุการณ์นั้นจะรับไปทำงานต่อของตนเอง โดยผู้ประกาศไม่จำเป็นต้องรู้ว่าใครรับไปบ้าง

เปรียบเทียบง่ายๆ คือ แบบเดิมเหมือนการโทรไปถามทุกแผนกทีละคนว่า "มีอะไรใหม่ไหม" ส่วน EDA เหมือนระบบประกาศเสียงตามสาย ใครเกี่ยวข้องก็ได้ยินและลงมือทันที

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

องค์ประกอบหลักของ EDA

สถาปัตยกรรมแบบนี้ประกอบด้วยส่วนสำคัญสามส่วน

ผู้ผลิตเหตุการณ์ (Producer):
ระบบหรืออุปกรณ์ที่ตรวจพบและประกาศเหตุการณ์ เช่น ระบบ WMS เซนเซอร์ GPS เครื่องสแกนบาร์โค้ด หรือระบบ ERP

ตัวกลางจัดการเหตุการณ์ (Event Broker):
ศูนย์กลางที่รับเหตุการณ์ เก็บไว้ชั่วคราวหรือถาวร และกระจายไปยังผู้สนใจ ตัวอย่างเทคโนโลยีที่ใช้กันมีทั้ง Apache Kafka, RabbitMQ และบริการคลาวด์ของผู้ให้บริการรายใหญ่

ผู้บริโภคเหตุการณ์ (Consumer):
ระบบที่ติดตามเหตุการณ์และทำงานตามที่กำหนด เช่น ส่งการแจ้งเตือนลูกค้า ปรับแผนจัดคิวรถ หรือสร้างงานตรวจสอบให้เจ้าหน้าที่

รูปแบบการสื่อสารที่พบบ่อยคือ publish/subscribe ซึ่งผู้ผลิตเผยแพร่เหตุการณ์ไปยังหัวข้อ (topic) และผู้บริโภคสมัครรับเฉพาะหัวข้อที่เกี่ยวข้อง ทำให้เพิ่มผู้บริโภครายใหม่ได้โดยไม่ต้องแก้ระบบต้นทาง

EDA ต่างจากการเชื่อมต่อแบบเดิมอย่างไร

ระบบที่เชื่อมต่อกันแบบจุดต่อจุดมักมีลักษณะที่ระบบหนึ่งเรียกอีกระบบหนึ่งโดยตรง หรือดึงข้อมูลเป็นรอบ ซึ่งมีข้อจำกัดชัดเจน

ความผูกพันระหว่างระบบ:
เมื่อระบบ A เรียกระบบ B ตรงๆ ถ้า B ล่มหรือช้า A ก็ได้รับผลกระทบ ส่วนใน EDA ตัวกลางเก็บเหตุการณ์ไว้ให้ ผู้บริโภคกลับมาประมวลผลต่อได้เมื่อพร้อม

ความเร็วในการตอบสนอง:
การดึงข้อมูลเป็นรอบทำให้เกิดช่วงว่างระหว่างเหตุการณ์กับการรับรู้ ขณะที่ EDA ส่งต่อเหตุการณ์ทันทีที่เกิด

การขยายระบบ:
การเพิ่มบริการใหม่ เช่น ระบบวิเคราะห์ความเสี่ยง หรือแดชบอร์ดผู้บริหาร ทำได้โดยสมัครรับเหตุการณ์ที่มีอยู่ ไม่ต้องรื้อการเชื่อมต่อเดิมทุกเส้น

ทั้งนี้ EDA ไม่ได้มาแทนที่ทุกอย่าง งานที่ต้องการคำตอบทันทีแบบถาม-ตอบ เช่น การเช็กราคาหรือสต็อกขณะลูกค้ารออยู่ ก็ยังเหมาะกับการเรียก API ตามปกติ สถาปัตยกรรมที่ใช้งานจริงมักผสมทั้งสองแบบ

ตัวอย่างการใช้งานในโลจิสติกส์และซัพพลายเชน

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

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

การจัดการข้อยกเว้น:
เมื่อมีเหตุการณ์ "รถล่าช้าเกินเกณฑ์" ระบบสามารถเรียกกฎให้จัดช่องจอดใหม่ แจ้งทีมคลังสินค้า และเสนอทางเลือกการขนส่งสำรองโดยอัตโนมัติ แทนการรอให้คนสังเกตเห็นเอง

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

การเชื่อมต่อกับอุปกรณ์:
เซนเซอร์อุณหภูมิ ตัวติดตามตำแหน่ง และอุปกรณ์ในคลังสินค้า ส่งข้อมูลต่อเนื่องเป็นสตรีมเหตุการณ์ ซึ่งเหมาะกับตัวกลางแบบ event streaming มากกว่าระบบที่ออกแบบมาสำหรับธุรกรรมทีละรายการ

การแบ่งปันข้อมูลข้ามองค์กร:
ภาคอุตสาหกรรมเริ่มกำหนดแนวทางที่อิงเหตุการณ์ เช่น มาตรฐาน EPCIS ของ GS1 ที่บันทึกว่าสินค้าอะไรอยู่ที่ไหนและเกิดอะไรขึ้นกับมัน และมาตรฐานของ DCSA ที่กำหนดเหตุการณ์สำหรับการติดตามการขนส่งทางทะเล ช่วยให้คู่ค้าเข้าใจเหตุการณ์ตรงกัน

รูปแบบที่เกี่ยวข้อง: Event Sourcing และ CQRS

เมื่อใช้ EDA ลึกขึ้น มักพบสองแนวคิดที่ใช้ร่วมกัน

Event Sourcing:
แทนที่จะเก็บเพียงสถานะล่าสุด เช่น "สต็อกคงเหลือ 100 ชิ้น" ระบบเก็บลำดับเหตุการณ์ทั้งหมดที่นำไปสู่สถานะนั้น ข้อดีคือย้อนดูประวัติ ตรวจสอบที่มาของตัวเลข และสร้างสถานะ ณ เวลาใดก็ได้ขึ้นใหม่ได้ แต่ต้องออกแบบการเก็บและการอ่านข้อมูลอย่างระมัดระวัง

CQRS (Command Query Responsibility Segregation):
แยกฝั่งการเขียนข้อมูลออกจากฝั่งการอ่านข้อมูล เพื่อให้แต่ละฝั่งออกแบบและขยายขนาดได้เหมาะกับหน้าที่ของตน มักใช้ควบคู่กับ Event Sourcing

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

ความท้าทายที่ต้องเตรียมรับมือ

EDA ให้ประโยชน์มาก แต่ก็มีความซับซ้อนที่องค์กรควรทราบล่วงหน้า

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

ลำดับและการซ้ำของเหตุการณ์:
ในระบบกระจาย เหตุการณ์อาจมาถึงไม่ตามลำดับหรือถูกส่งซ้ำ ผู้บริโภคจึงต้องออกแบบให้ประมวลผลซ้ำได้โดยผลไม่เปลี่ยน (idempotency) และจัดการลำดับให้เหมาะกับธุรกิจ

การออกแบบสัญญาข้อมูลของเหตุการณ์:
โครงสร้างเหตุการณ์คือข้อตกลงระหว่างทีม หากเปลี่ยนโดยไม่แจ้งอาจทำให้ผู้บริโภคเสียหายได้ ควรมีการกำกับดูแลเวอร์ชันและทะเบียนโครงสร้างข้อมูล (schema registry) รวมถึงอาจพิจารณามาตรฐานการอธิบายเหตุการณ์ เช่น CloudEvents

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

ทักษะและวัฒนธรรมของทีม:
การคิดแบบเหตุการณ์ต่างจากการคิดแบบฐานข้อมูลและคำขอ-ตอบกลับที่ทีมส่วนใหญ่คุ้นเคย การเริ่มโดยไม่มีการฝึกอบรมมักนำไปสู่ระบบที่ซับซ้อนเกินจำเป็น

แนวทางเริ่มต้นอย่างรอบคอบ

องค์กรที่ต้องการเริ่มใช้ EDA ควรทำตามขั้นตอนต่อไปนี้

1. เลือกกรณีใช้งานที่มูลค่าสูงและขอบเขตเล็ก:
เริ่มจากกระบวนการที่ความล่าช้าของข้อมูลสร้างความเสียหายชัดเจน เช่น การแจ้งเตือนความล่าช้าของการขนส่ง แทนการเปลี่ยนทั้งองค์กรพร้อมกัน

2. ระบุเหตุการณ์สำคัญทางธุรกิจ:
ให้ฝ่ายปฏิบัติการและฝ่ายไอทีร่วมกันกำหนดว่าเหตุการณ์ใดมีความหมายต่อธุรกิจ และใครต้องรับรู้ ก่อนเลือกเทคโนโลยี

3. ออกแบบเหตุการณ์ให้มีความหมายและเสถียร:
ตั้งชื่อด้วยภาษาธุรกิจ ใส่ข้อมูลที่จำเป็นต่อผู้บริโภคอย่างครบถ้วน และไม่ใส่ข้อมูลอ่อนไหวเกินความจำเป็น

4. วางระบบเฝ้าระวังตั้งแต่ต้น:
ติดตามความหน่วงของเหตุการณ์ จำนวนข้อความที่ค้างหรือถูกปฏิเสธ และมีขั้นตอนจัดการข้อความที่ประมวลผลไม่สำเร็จ

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

สรุป

Event-Driven Architecture คือการเปลี่ยนวิธีคิดจากการให้ระบบวนถามกันเป็นรอบ มาเป็นการให้ระบบตอบสนองต่อเหตุการณ์ที่เกิดขึ้นจริง ซึ่งสอดคล้องกับธรรมชาติของงานโลจิสติกส์และซัพพลายเชนที่เหตุการณ์เกิดขึ้นตลอดเวลา ผลที่ได้คือการรับรู้ปัญหาเร็วขึ้น ระบบยืดหยุ่นต่อการเพิ่มบริการใหม่ และแต่ละส่วนล้มหรือช้าโดยไม่ลากทั้งระบบไปด้วย

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