AWS Step Functions และ Camunda 8 เลือกใช้อะไรสำหรับระบบ Saga
เจาะลึกการเปรียบเทียบ AWS Step Functions และ Camunda 8 สองระบบออร์เคสตราเตอร์สำหรับ Saga pattern ทั้งโครงสร้างต้นทุนและการจัดการความล้มเหลว
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- AWS Step Functions เป็นระบบจัดการสถานะแบบ Managed Service ที่คิดค่าบริการตาม State Transitions
- Camunda 8 ใช้โมเดล BPMN และ Zeebe ช่วยจัดการระบบ Saga พร้อมรองรับการทำ Versioning ขณะรันงาน
- ทั้งสองระบบช่วยแก้ปัญหาความซับซ้อนของ Distributed Transaction ด้วยการใช้ Central Brain
- ค่าใช้จ่ายของ Step Functions จะเพิ่มขึ้นตามจำนวนครั้งที่เกิดความล้มเหลวและมีการ Retry ซ้ำๆ
ทีมนักพัฒนาหลายทีมมักตกหลุมพรางในการเลือกใช้เครื่องมือจัดการ Saga pattern โดยการเทียบฟีเจอร์กันแบบข้อต่อข้อแล้วตัดสินใจเลือกจากบิลคลาวด์ที่มีอยู่ สุดท้ายผ่านไปหนึ่งปี ทีมหนึ่งต้องคอยปรับจูนพาร์ทิชัน Zeebe ตอนตีสอง ในขณะที่อีกทีมมองบิลค่า AWS Step Functions ที่พุ่งเร็วกว่าปริมาณทราฟฟิก พร้อมกับสงสัยว่าเหตุใดรูปแบบเดียวกันจึงสร้างงานที่แตกต่างกันได้ขนาดนี้
ในความเป็นจริง ทั้งสองระบบรันรูปแบบการทำงานที่เหมือนกัน Saga คือลำดับของทรากชันย่อยในท้องถิ่น หากขั้นตอนที่สี่เกิดความล้มเหลว ระบบจะทำการชดเชย (Compensating Actions) เพื่อย้อนกลับขั้นตอนที่หนึ่งถึงสาม เนื่องจากไม่มี Distributed Transaction คอยโรลแบ็กให้ ทั้ง AWS Step Functions และ Camunda 8 ต่างก็ทำหน้าที่เป็น Orchestration-style saga coordinators ซึ่งเปรียบเสมือนสมองส่วนกลางที่จดจำขั้นตอน สั่งการตามลำดับ และเรียกใช้งานระบบชดเชยเมื่อมีข้อผิดพลาดเกิดขึ้น
จุดที่แตกต่างกันอย่างแท้จริงคือความรับผิดชอบในการดูแลระบบ ผู้เขียนใช้งาน Camunda 8 ในระบบจริงสำหรับเวิร์กโฟลว์การออกใบรับรองและการจัดตารางเวลา ในขณะที่อีกระบบศึกษาจากเอกสารและประเมินราคาสำหรับข้อเสนอจริง การเปรียบเทียบที่ถูกต้องจึงไม่ใช่การดูว่าระบบใดมีฟีเจอร์มากกว่ากัน แต่เป็นการดูว่าความล้มเหลวรูปแบบใดที่เป็นภาระที่คุณต้องรับผิดชอบ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
AWS Step Functions เป็น Managed State Machine ที่ให้คุณอธิบายระบบ Saga ผ่าน Amazon States Language ซึ่งอยู่ในรูปของ JSON โดยที่ AWS จะเป็นผู้ดูแลระบบให้ทั้งหมด ไม่ว่าจะเป็นการจัดการบร็อกเกอร์ การกำหนดขนาดคลัสเตอร์ หรือการดูแล Exporter สำหรับหลายๆ ทีม ข้อนี้ถือเป็นจุดเด่นสำคัญ พร้อมทั้งมีระบบ Retry และ Error routing เป็นการกำหนดค่าแบบ Declarative
สำหรับระบบ Saga ที่ทำงานเป็นระยะเวลานานจะต้องใช้ Standard Workflows ซึ่งเป็นจุดที่มักสร้างความประหลาดใจด้านค่าใช้จ่าย ทุกๆ สเตปที่เครื่องทำงานจะถูกนับเป็นหนึ่ง Transition ไม่ว่าจะเป็น Task, Wait หรือ Choice โดย 4,000 ครั้งแรกของเดือนจะไม่มีค่าใช้จ่าย หลังจากนั้นจะคิดราคา $0.000025 ต่อครั้ง ซึ่งดูเหมือนราคาถูกจนกระทั่งอ่านเงื่อนไขถัดไปที่ระบุว่า ความพยายามในการลองใหม่ (Retry) แต่ละครั้งจะถูกนับเป็น State Transition ที่ต้องเสียเงินเช่นกัน ช่วงเวลาที่คุณระบบมีปัญหาและระบบพยายาม Retry มากที่สุด จึงเป็นช่วงเวลาที่คุณเสียค่าใช้จ่ายมากที่สุดเช่นกัน
"A retry storm is a billing event."
Andrii Boyko
การวิเคราะห์เพิ่มเติม: ปัญหาค่าใช้จ่ายที่เกิดจาก Retry Storm ใน Step Functions แสดงให้เห็นถึงความเสี่ยงของการใช้ Cloud Services ที่คิดเงินตามจำนวนครั้งการทำงานย่อย (Usage-based pricing) ในสถานการณ์ที่ระบบเกิดความผิดพลาดบ่อยครั้ง ต้นทุนการดำเนินงานอาจพุ่งสูงขึ้นสวนทางกับรายได้ทางธุรกิจ นักพัฒนาจึงต้องออกแบบระบบ Error Handling ให้รัดกุมเพื่อหลีกเลี่ยงการเรียกใช้งานซ้ำโดยไม่จำเป็น หรือพิจารณาเลือกใช้ Express Workflows หากเป็นงานที่มีปริมาณทราฟฟิกสูงและใช้เวลาสั้น แม้จะมีข้อจำกัดเรื่องระยะเวลาทำงานก็ตาม
ในฝั่งของ Camunda 8 จะมีแนวทางการจัดการที่แตกต่างออกไปโดยสิ้นเชิง คุณจะออกแบบ Saga ผ่าน BPMN และกำหนดให้การชดเชย (Compensation) เป็นโครงสร้างหลักระดับเฟิร์สต์คลาส โดยการแนบ Compensation boundary event เข้ากับแต่ละกิจกรรม กำหนดตัวจัดการย้อนกลับ เมื่อเกิดข้อผิดพลาด ระบบจะเรียกตัวจัดการเหล่านั้นทำงานย้อนหลังโดยอัตโนมัติ ไม่ต้องคอยเขียนโค้ดเส้นทางโรลแบ็กเอง
นอกจากนี้ Camunda ยังมีจุดเด่นสำคัญในเรื่อง In-flight process versioning เมื่อคุณแก้ไขบั๊กในระบบ Saga ที่กำลังรันอินสแตนซ์อยู่หลายพันรายการ การอัปเกรดเป็นเวอร์ชันสองจะไม่ส่งบวกกวนอินสแตนซ์ที่กำลังทำงานอยู่เดิม พวกมันจะทำงานต่อจนจบเวอร์ชันที่เริ่มต้น และสามารถโยกย้ายอินสแตนซ์ผ่าน Operate หรือ Zeebe API ได้อย่างราบรื่น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น