สรุปการย้ายระบบจาก Monolith ไปยัง Microservices ของ SHIFT Commerce

จากบทความเรื่อง SHIFT Commerce's Journey: Deconstructing Monolithic Applications into Services ทำการอธิบายขั้นตอนการเปลี่ยนสถาปัตยกรรมระบบจาก Monolith ไปเป็น Microservices เป็นกรณีศึกษาที่น่าสนใจ จึงทำการสรุปไว้นิดหน่อย

เหตุผลสำหรับการนำ Microservices มาใช้

1. เรื่องของการพูดคุยที่เยอะเกินไป ในการพัฒนาระบบนั้น พบว่า เมื่อต้องเริ่มต้นพัฒนา เมื่อต้องเพิ่ม feature เข้าไปยังระบบ เมื่อต้องแก้ไขระบบ สิ่งที่เกิดขึ้นคือ ต้องพูดคุย ประชุมกับหลายทีมมากมาย ดังนั้นกว่าจะได้เริ่มพัฒนา ต้องใช้เวลาสูงมาก ยิ่งเมื่อพัฒนาปัญหาก็เยอะมาก ปรับเปลี่ยนสิ่งใด จะยากมาก ๆ 2. การ deploy ระบบงานทุกครั้ง ใช้เวลา และ มีความเสี่ยงสูงทุกครั้ง เมื่อเกิดความกลัวแล้ว สิ่งที่ตามมาคือ ความระมัดระวัง ทั้งการเพิ่มขั้นตอนที่มากมาย ทั้งเวลาที่ใช้เยอะมาก ๆ ผลที่ตามมาคือ ระบบไม่สามารถใช้งานได้ นั่นคือผลกระทบต่อผู้ใช้และธุรกิจอีกด้วย 3. เจอข้อจำกัดของ infrastructure และภาษาโปรแกรม ยิ่งระบบมีขนาดใหญ่ขึ้น ปัญหาที่ตามมาคือ infrastructure ที่มีอยู่ไม่สามารถรองรับได้หรือถึงขีดจำกัด สิ่งที่ต้องทำคือ ขยายนั่นเอง ทำให้ต้องใช้ค่าใช้จ่ายที่สูงมาก ๆ รวมไปถึงภาษาโปรแกรมหรือเทคโนโลยีที่ใช้งานอีกด้วย เช่น ถ้าระบบเดิมคือภาษา Ruby นั้น เริ่มรองรับจำนวนผู้ใช้งานได้ช้าลง การจะเปลี่ยนไปใช้ภาษา Go หรือ NodeJS น่าจะดีกว่า แต่ก็ทำไม่ได้ หรือ ยากมาก ๆ

จากปัญหาต่าง ๆ เหล่านี้ จึงทำให้ทางทีมพัฒนานั้น เริ่มคิดและหาวิธีแก้ไข หนึ่งในนั้นคือ การแบ่งระบบงานใหญ่ ๆ ออกมาเป็นระบบหรือ service ย่อย ๆ ที่เราเรียกกันว่า Microservice นั่นเอง

ปล. ถ้ายังไม่มีปัญหาเหล่านี้ ก็ให้พิจารณากันหน่อยนะ

มาดูวิธีการแก้ไขปัญหากันดูว่าเป็นอย่างไรบ้าง ?

แน่นอนว่า เริ่มด้วยการแยก service บางตัวออกมาก่อน แต่การแยกเป็น service ย่อย ๆ ทั้งระบบเลยก็ไม่ได้ เพราะว่า จะมีปัญหาต่าง ๆ มากมายให้แก้ไข ซึ่งนรกมาก ๆ ยังไม่พอนะ ปัญหาที่ตามมาคือ เมื่อแยก service ออกมาแล้ว การติดต่อสื่อสารระหว่างระบบเดิมกับ service เล็ก ๆ ต้องทำอย่างไร ? ในระบบนี้มีความต้องการดังนี้ ทำงานแบบ real time ดังนั้นถ้ามีข้อมูลเปลี่ยนแปลง ส่วนต่าง ๆ ที่เกี่ยวข้องต้องทำงานด้วย แต่ไม่ต้องการให้แต่ละส่วนงานต่าง ๆ ยึดติดกันเกินไป (Decouple หรือ Loose coupling) จึงเลือกใช้งานการติดต่อกันแบบ Asynchronous แน่นอนว่าต้องมีคนกลางสำหรับการติดต่อกัน (Messaging) คำถามคือ ต้องใช้อะไรเป็นตัวกลางในการติดต่อกัน เช่น ActiveMQ, RabbitMQ และ Apache Kafka ทางทีมพัฒนานั้นเลือกใช้ Apache Kafka (ในบทความเป็น service บน Heruku นะ เพื่อลดปัญหาในการดูแลรักษาระบบเอง)

มาดูขั้นตอนการย้ายระบบกันบ้าง

ทำการย้ายแบบค่อยเป็นค่อยไป ไม่ทำแบบ big bang เนื่องจากมีความเสี่ยงสูงมาก ๆ โดยประกอบไปด้วย 8 ขั้นตอนดังนี้ ขั้นตอนที่ 1 สร้าง Producer logic ในฝั่งของระบบเดิม เริ่มด้วยการเพิ่ม code ในระบบเดิม ทำหน้าที่ส่ง event หรือการเปลี่ยนแปลงต่าง ๆ ไปยังตัวกลางคือ Apache Kafka ขั้นตอนที่ 2 สร้าง Consumer ในส่วนของ service ใหม่ ทำการดึงข้อมูลหรือ event จาก Apache Kafka มาจะเก็บใน Database ของ service ก่อน เพื่อจะนำมาใช้งานใน service นี้ต่อไป เป็นขั้นตอนแรกของการแยก service ออกมา แสดงดังรูป ขั้นตอนที่ 3 ทดสอบว่า Consumer ทำงานได้ดีและถูกต้องหรือไม่ ต้องทำให้แน่ใจและมั่นใจว่า Consumer ทำงานได้อย่างถูกต้อง ทั้ง event ต่าง ๆ และการบันทึกข้อมูลลง Database รวมทั้งทำความเข้าใจกับการทำงานในรูปแบบต่าง ๆ ของ Apache Kafka อีกด้วย เมื่อทุกอย่างเข้าที่เข้าทาง ก็ไปต่อกัน ขั้นตอนที่ 4 เริ่มสร้าง logic ในส่วนของ service ใหม่ นั่นคือการ copy หรือ duplicate logic การทำงานมาจากระบบเดิมนั่นเอง จากนั้นทำการทดสอบว่า ระบบยังคงทำงานได้เช่นเดิมหรือไม่ แสดงดังรูป ขั้นตอนที่ 5 เพิ่ม Logic เพื่อส่ง action event หรือการทำงานต่าง ๆ มายัง service จากสิ่งที่ผ่านมา เพียงแค่ส่งข้อมูลที่เปลี่ยนแปลงมาเท่านั้น สิ่งต่อมาคือ action event ของการทำงานนั่นเอง และความสามารถที่ต้องเพิ่มมาคือ Feature Toggle ในฝั่งระบบเดิม เพื่อให้เปิดปิดการส่งข้อมูลการทำงานส่วนต่าง ๆ มายัง service ใหม่ได้ แสดงดังรูป ขั้นตอนที่ 6 เมื่อ Service ใหม่ทำงานตาม action event แล้ว ก็ต้องผลการทำงานกับไปยังระบบเดิม สิ่งที่ต้องสร้างคือ Producer ในฝั่ง service ใหม่ Consumer ในฝั่งระบบเดิม แสดงดังรูป ขั้นตอนที่ 7 ทดสอบ ทดสอบ ทดสอบ ทั้งการเปิดปิดจาก Feature Toggle เพื่อทำให้มั่นใจว่า ระบบยังคงทำงานได้เช่นเดิม (ยากมาก ๆ) ขั้นตอนที่ 8 เมื่อมั่นใจก็ลบ logic หรือส่วนการทำงานออกจากระบบเดิม แน่นอนว่าต้องเปิด Feature Toggle ให้ไปใช้ logic ที่ service ใหม่ทั้งหมด ต่อไปในอนาคตอันใกล้ ก็ให้ลบ Feature Toggle ออกไป เนื่องจากการทำงานหลักจะย้ายไปที่ service ใหม่แล้ว นี่คือขั้นตอนการลบสิ่งที่ซ้ำซ้อนนั่นเอง

เมื่อทำงานครบทั้ง 8 ขั้นตอน ก็จะทำให้เราสามารถแยก service ออกมาจากระบบเดิมได้แบบปลอดภัยแล้วนะ

โดยสิ่งที่ทางทีมพัฒนาได้รับจากการเปลี่ยนแปลงประกอบไปด้วย

• Deploy และ Release ได้บ่อยขึ้น
• ลดปัญหาเรื่อง I/O Latency จากการเรียกผ่าน API
• ความพึงพอใจของผู้ใช้งานเพิ่มขึ้น

คำถามที่น่าสนใจ ทำไมเราถึงนำแนวคิดของ Microservices มาใช้งาน ?