ในช่วงทศวรรษ 1960 และ 1970 สถาปัตยกรรมแบบโมโนลิธิก เป็นที่นิยมสำหรับการพัฒนาแอปพลิเคชันในยุคที่ทรัพยากรการประมวลผลมีจำกัด ซึ่งจำเป็นต้องรวมฟังก์ชันทั้งหมดไว้ในหน่วยเดียวที่ทำงานร่วมกันได้
สถานการณ์นี้ดำเนินต่อมาจนถึงช่วงปลายยุค 90 และต้นยุค 2000 เมื่อโครงสร้างแบบ Monolithic เริ่มรองรับขนาดและความซับซ้อนของแอปพลิเคชันที่เพิ่มขึ้นอย่างต่อเนื่องไม่ได้อีกต่อไป โดยเฉพาะอย่างยิ่งเมื่ออินเทอร์เน็ตและระบบแบบกระจายศูนย์เติบโตขึ้นอย่างรวดเร็ว
จุดนี้เองที่นำไปสู่การพัฒนาแนวทางแบบ Modular มากขึ้น เช่น สถาปัตยกรรมเชิงบริการ (SOA) และ, ต่อมา, สถาปัตยกรรม Microservices (MSA)ซึ่งได้รับความนิยมอย่างแพร่หลายในช่วงต้นยุค 2010
ทั้งหมดที่กล่าวมาเป็นเพียงการอธิบายแนวคิดพื้นฐานและการใช้งาน Microservices โดยสังเขป ต่อไปเราจะมาดูกันว่า Microservices เข้ามาแทนที่สถาปัตยกรรมแบบ Monolithic ได้อย่างไร Microservices ทำงานอย่างไร และมีตัวอย่างอะไรบ้าง จากนั้นเราจะพูดถึงแง่มุมสำคัญของการ Deploy Microservices และสิ่งที่ควรทำหากต้องการ Deploy Microservices
Microservices คืออะไร และทำงานอย่างไร?
ดังที่กล่าวไว้ก่อนหน้านี้ Microservices เกิดขึ้นเพื่อแก้ปัญหาความซับซ้อนและขนาดของแอปพลิเคชันที่เพิ่มขึ้น โดยช่วยให้บริษัทต่างๆ สามารถแยกฟังก์ชันการทำงานออกเป็น Service อิสระที่ Deploy ได้แยกกัน
คำว่า Microservices ได้รับการเผยแพร่อย่างเป็นทางการโดยผู้เชี่ยวชาญในวงการอย่าง Martin Fowler และ James Lewis ซึ่งได้นิยามคำนี้อย่างเป็นทางการในบทความบล็อกเมื่อปี 2014 งานของพวกเขากำหนดหลักการและคุณลักษณะสำคัญต่างๆ ไว้ ได้แก่ ความจำเป็นในการมี Service ที่ Deploy ได้อย่างอิสระ การจัดการข้อมูลแบบกระจายศูนย์ และความเป็นกลางทางเทคโนโลยี
นับตั้งแต่นั้นมา Microservices ได้กลายเป็นแนวทางสถาปัตยกรรมหลักที่ได้รับการสนับสนุนจากพัฒนาการด้าน เทคโนโลยี Containerization อย่าง Dockerเครื่องมือ Orchestration อย่าง Kubernetes และแพลตฟอร์ม Serverless Computing แต่ Microservices ทำงานอย่างไรกันแน่?
Microservices ทำงานอย่างไร?
โดยพื้นฐานแล้ว สถาปัตยกรรม Microservices จะแยกแอปพลิเคชันขนาดใหญ่ออกเป็น Service ย่อยๆ ที่มีหน้าที่ชัดเจน โดยแต่ละ Service รับผิดชอบความสามารถทางธุรกิจเฉพาะด้าน Service เหล่านี้สื่อสารกันผ่านเครือข่าย โดยมักใช้ REST API, gRPC หรือ Message Broker อย่าง RabbitMQ หรือ Apache Kafka
ตามนิยามของ Martin Fowler และ James Lewis Microservices มีคุณลักษณะสำคัญ 4 ประการ ดังนี้
- ความรับผิดชอบเดี่ยว: แต่ละ Microservice ถูกออกแบบมาให้ทำหน้าที่หรืองานเฉพาะด้าน ซึ่งช่วยให้เกิดความเชี่ยวชาญเฉพาะทางและลดความซับซ้อนลง
- อิสระภาพ: Microservices สามารถพัฒนา Deploy และปรับขนาดได้อย่างอิสระจากกัน ซึ่งให้ความยืดหยุ่นและความทนทานต่อความล้มเหลว
- การจัดการข้อมูลแบบกระจายศูนย์ (Decentralized Data Management): Microservices มักมีฐานข้อมูลของตัวเอง ทำให้ไม่จำเป็นต้องพึ่งพาฐานข้อมูลกลางเพียงแห่งเดียว
- เป็นกลางต่อเทคโนโลยี ทีมงานสามารถเลือกเทคโนโลยีที่เหมาะสมที่สุดสำหรับแต่ละ Service ได้อย่างอิสระ โดยไม่ต้องยึดติดกับการเลือกของ Service อื่น
แนวทางนี้แตกต่างจากสถาปัตยกรรมแบบ Monolithic ดั้งเดิม ซึ่งองค์ประกอบทั้งหมดของแอปพลิเคชันถูกรวมเข้าด้วยกันแน่นหนาในหน่วยเดียว
ขั้นตอนสำคัญของการ Deploy Microservices
แม้สถาปัตยกรรม Microservices จะมีข้อดีมากมาย เช่น การปรับขนาดได้สูง ความยืดหยุ่น ประสิทธิภาพ การแยกความล้มเหลว และอื่นๆ แต่การจะ Deploy ให้ได้ผลดีนั้นต้องอาศัยทั้งความเข้าใจในการ Deploy Microservices อย่างถูกต้องและการวางแผนอย่างรอบคอบ
นั่นจึงเป็นเหตุผลที่การมีความเข้าใจอย่างครบถ้วนเกี่ยวกับแนวคิดหลัก ขั้นตอน และ Best Practice ของ Microservices ในการ Deploy นั้นมีความสำคัญอย่างยิ่งต่อความสำเร็จของสถาปัตยกรรม Microservices มาดูขั้นตอนสำคัญของการ Deploy Microservices และสิ่งที่แต่ละขั้นตอนต้องการกัน
การวางแผนและเตรียมการสำหรับการ Deploy Microservices
สิ่งดี ๆ ทุกอย่างต้องอาศัยการวางแผนและความอดทน การ deploy microservices ให้ประสบความสำเร็จก็เช่นกัน คุณต้องวางแผนและเตรียมการอย่างรอบคอบ นั่นคือเหตุผลที่การปฏิบัติตาม best practices ของ microservices และเตรียมทุกอย่างให้พร้อมก่อน deploy จึงสำคัญมาก
อย่างที่กล่าวไปก่อนหน้านี้ หนึ่งในหลักการและคุณสมบัติสำคัญของ microservices คือ หลักการความรับผิดชอบเดียวการยึดมั่นในหลักการนี้และทำให้แน่ใจว่า microservice แต่ละตัวมุ่งเน้นและรับผิดชอบเพียงหน้าที่เดียว จะช่วยให้ทีมพัฒนา deploy และขยายขนาด service ได้อย่างอิสระ
นอกจากนี้ หลักการย่อยของแนวคิดนี้คือ หลักการออกแบบแบบคลายตัวซึ่งหมายความว่า service แต่ละตัวทำงานได้อย่างอิสระในการสื่อสาร และพึ่งพา service อื่นน้อยที่สุด ส่งผลให้การเปลี่ยนแปลงหรืออัปเดต service หนึ่งไม่กระทบ service อื่น และสามารถขยายขนาด microservices แต่ละตัวได้โดยไม่ต้องพึ่งกัน
สิ่งนี้ช่วยลดความเสี่ยงของ cascading failures ซึ่งเกิดขึ้นเมื่อปัญหาหรือความล้มเหลวในส่วนหนึ่งของระบบก่อให้เกิดปฏิกิริยาลูกโซ่ จนนำไปสู่ความล้มเหลวทั่วทั้งระบบและทำให้ service หยุดทำงานทั้งหมด
แนวปฏิบัติสำคัญอย่างหนึ่งของ microservices คือการมี data storage แยกต่างหากสำหรับแต่ละ service เมื่อ deploy microservices ซึ่งเป็นส่วนหนึ่งของ loose coupling design principle วิธีนี้ช่วยป้องกันความขัดแย้งและรองรับการขยายขนาด service ได้ดียิ่งขึ้น
นอกจากนี้ คุณยังต้องใช้รูปแบบการสื่อสารแบบ asynchronous สำหรับ microservices เช่น message brokers เพื่อให้ทุก service สื่อสารกันได้โดยไม่ต้องพึ่งพากันโดยตรง
ส่วนสุดท้ายที่ขาดไม่ได้คือการนำ Continuous Integration และ Continuous Delivery (CI/CD) pipelines มาใช้กับ microservices โดย pipelines เหล่านี้ช่วยให้ทีมสามารถ deploy ฟีเจอร์ใหม่หรือแพทช์แก้ไขผ่าน เครื่องมือ CI/CD เช่น Jenkins และ GitLab ช่วยให้องค์กรรักษาเสถียรภาพของระบบได้ในขณะที่ release ความสามารถใหม่อย่างต่อเนื่อง
เมื่อคุณเข้าใจภาพรวมของการวางแผนและเตรียมการที่จำเป็นสำหรับการ deploy microservices แล้ว มาดู deployment strategies ของ microservices กัน
กลยุทธ์การ Deploy Microservices
เมื่อต้อง deploy microservices การเลือก deployment strategy ขึ้นอยู่กับหน้าที่ของ service ปริมาณ traffic การตั้งค่า infrastructure ความเชี่ยวชาญของทีม และค่าใช้จ่าย โดยทั่วไป deployment strategies ของ microservices มีดังนี้
- บริการต่อคอนเทนเนอร์ แนวทางนี้ให้ microservice แต่ละตัวรันในคอนเทนเนอร์ของตัวเอง ซึ่ง isolate ได้ดีกว่าโมเดลที่รันหลาย instance บน host เดียวกัน คอนเทนเนอร์ช่วยให้การขยายขนาดทำได้ง่ายและจัดสรรทรัพยากรได้มีประสิทธิภาพมากขึ้น
- บริการแต่ละอินสแตนซ์ต่อเครื่องเสมือน: แต่ละ service รันบน virtual machine (VM) แยกต่างหาก ซึ่ง isolate ได้มากกว่าคอนเทนเนอร์ แม้จะช่วยเพิ่มความปลอดภัยและเสถียรภาพ แต่โดยทั่วไปก็มี overhead สูงกว่า
- การเปิดตัวแบบขั้นตอน: เริ่มต้นด้วยการ deploy microservice เวอร์ชันใหม่ให้กับผู้ใช้กลุ่มเล็ก ๆ ก่อน เพื่อทดสอบเสถียรภาพก่อน rollout เต็มรูปแบบ แนวทางนี้ช่วยลดผลกระทบหากเกิดปัญหา และ rollback ได้อย่างรวดเร็วเพื่อรักษาความสมบูรณ์ของระบบ
- การปรับใช้สีน้ำเงิน-เขียว: วิธีนี้ใช้ production environment สองชุดที่เหมือนกัน โดยชุดหนึ่งรับ traffic จริงอยู่ ส่วนอีกชุดใช้ทดสอบ release ถัดไป Blue-green deployment รองรับการ rollback ได้ง่ายและอัปเดตโดยไม่มี downtime เพราะสามารถสลับ traffic ระหว่างสองสภาพแวดล้อมได้ทันที
- ปล่อยออกแบบขั้นตอน กลยุทธ์นี้ค่อย ๆ rollout อัปเดตไปยังกลุ่มผู้ใช้หรือสภาพแวดล้อมต่าง ๆ ทีละขั้น โดยมักเริ่มจาก internal environment ก่อนถึง production ซึ่งช่วยจำกัดขอบเขตความเสียหายหากเกิดปัญหา และให้ทีมแก้ไขได้เป็นลำดับขั้น
- การปรับใช้แบบ Serverless: แนวทางนี้ใช้ serverless platform เช่น AWS Fargate และ Google Cloud Run ซึ่งจัดการ infrastructure อัตโนมัติโดยดูแลการขยายขนาดและการจัดสรรทรัพยากรให้คุณ เมื่อใช้ serverless deployment คุณไม่ต้องจัดการ server โดยตรง และโฟกัสได้ที่ microservices ของคุณอย่างเต็มที่
เมื่อเลือก deployment strategy ข้างต้นสำหรับ microservices แล้ว คุณจะต้องมีเครื่องมือสำหรับ orchestrate microservices ด้วย
การจัดการไมโครเซอร์วิส
หลังจากเลือกกลยุทธ์การ deploy microservices แล้ว คุณจะต้องมีเครื่องมือสำหรับจัดการ microservice orchestration โดยเฉพาะ เครื่องมือ microservice orchestration เช่น Kubernetesช่วยทำให้การ deploy, การ scale, การ monitor และการจัดการ containerized microservices เป็นแบบอัตโนมัติ
ตัวอย่างเช่น Airbnb ใช้ Kubernetes เพื่อให้วิศวกรสามารถ deploy การเปลี่ยนแปลงได้หลายร้อยรายการโดยไม่ต้องดูแลด้วยตนเอง หนึ่งในฟีเจอร์สำคัญของเครื่องมือ orchestration อย่าง Kubernetes คือ load balancing ที่ติดมาพร้อมใช้งานทันที
ฟีเจอร์ load balancing ที่มีประสิทธิภาพช่วยกระจาย traffic ขาเข้าไปยัง instance หลายตัวของ microservice เดียวกัน ทำให้ไม่มี instance ใดกลายเป็น bottleneck และระบบรองรับ traffic ที่พุ่งสูงขึ้นได้ดียิ่งขึ้น
Kubernetes มีบทบาทสำคัญในการจัดการ microservices ผ่านความสามารถ self-healing ที่จะแทนที่และรีสตาร์ท container ที่ล้มเหลวโดยอัตโนมัติ The New York Times ใช้ฟีเจอร์นี้เพื่อดูแล microservices โดยไม่กระทบประสบการณ์ของผู้ใช้และหลีกเลี่ยง downtime
นอกจากนี้ Kubernetes ยังเสริมความปลอดภัยของ microservice ด้วยการจัดการ configuration และข้อมูลลับ เช่น credentials ของฐานข้อมูลหรือ API keys ผ่าน ConfigMaps และ Secrets ซึ่งสำคัญมากสำหรับบริษัทและบริการที่ต้องดูแลข้อมูลส่วนตัวของลูกค้า เช่น Uber
สุดท้าย เครื่องมือ microservices orchestration อย่าง Kubernetes มีประโยชน์โดยตรงกับกลยุทธ์ที่ต้องการ rolling update และ rollback เช่น staged releases โดย rolling update ช่วยให้ deploy microservice เวอร์ชันใหม่ได้โดยไม่หยุดให้บริการ เพราะ instance บางส่วนของเวอร์ชันเดิมยังคงทำงานอยู่
เมื่อตั้งค่าเครื่องมือ microservices orchestration เรียบร้อยแล้ว คุณจะต้องสร้างและทำให้ ไปป์ไลน์ CI/CD สำหรับการ deploy microservices เป็นแบบอัตโนมัติ
CI/CD Pipelines สำหรับการ Deploy Microservices
ดังที่กล่าวไว้ก่อนหน้า Continuous Integration และ Continuous Delivery pipelines สำหรับ microservices เป็นส่วนสำคัญของการ deploy microservices โดย CD pipeline ใน CI/CD pipeline มีหน้าที่ deploy code ที่ผ่านขั้นตอนการทดสอบและ integration ไปยัง production โดยอัตโนมัติ
จากนั้น CD ใน CI/CD pipeline จะทำงานโดยทุกครั้งที่ code ผ่านขั้นตอนการทดสอบและ integration บริการจะถูก deploy ไปยังเครื่องมือ microservices orchestration เช่น Kubernetes cluster
นอกจากนี้ ขั้นตอนการทดสอบและ integration ทั้งหมดดำเนินการโดยอัตโนมัติผ่าน CI/CD pipeline ซึ่งรวม unit tests, integration tests และ end-to-end tests เข้าไว้ใน pipeline เดียวกัน
ทำให้ทีมสามารถตรวจสอบ update ในแต่ละขั้นตอนได้ในขณะที่ระบบยังคงเสถียร และหาก code มีปัญหาใด ๆ แม้จะผ่านการทดสอบหลายชั้น ระบบยังสามารถ rollback กลับไปยังเวอร์ชันที่เสถียรก่อนหน้าได้โดยอัตโนมัติ
การใช้งาน CI/CD pipelines สำหรับ microservices ตาม best practices ช่วยให้องค์กรพัฒนาได้เร็วขึ้น ลดข้อผิดพลาดที่เกิดจากการทำงานด้วยมือ และรักษามาตรฐานคุณภาพของ code ให้อยู่ในระดับสูงอย่างสม่ำเสมอ
บริษัทชั้นนำหลายแห่ง เช่น Spotify, Expedia, iRobot, Lufthansa และ Pandora ใช้ CI/CD pipelines สำหรับ microservices ผ่านเครื่องมืออย่าง CircleCI, AWS CodePipeline และ GitLab เพื่อทำให้กระบวนการ deploy เป็นแบบอัตโนมัติ รักษาคุณภาพของ code ให้สม่ำเสมอ และส่งมอบฟีเจอร์ใหม่ได้รวดเร็วโดยไม่กระทบความเสถียรของระบบ
รูปแบบการสื่อสารของ Microservices
วิธีที่ microservices สื่อสารกันขึ้นอยู่กับฟังก์ชันการทำงาน สถาปัตยกรรมโดยรวม ความต้องการด้าน scalability และความน่าเชื่อถือของ microservices ของคุณ โดยทั่วไปมีรูปแบบการสื่อสารหลักสองประเภทที่นิยมใช้ คือ ซิงโครนัส และ ไม่ซิงโครนัส รูปแบบการสื่อสาร microservices
ในรูปแบบการสื่อสาร microservices แบบ synchronous บริการจะโต้ตอบกันแบบ real-time หมายความว่าบริการจะส่ง request และรอ response ก่อนดำเนินการต่อ รูปแบบที่นิยมใช้มากที่สุดได้แก่ REST (การถ่ายโอนสถานะเชิงตัวแทน) APIs, gRPC (Google Remote Procedure Call) และ GraphQL.
รูปแบบการสื่อสาร microservices แบบนี้มักถูกใช้ในอุตสาหกรรมที่ต้องการประมวลผลข้อมูลแบบ real-time และตอบสนองทันที เช่น การเงิน สาธารณสุข และ e-commerce ซึ่งต้องการให้ธุรกรรม การดึงข้อมูล หรือการโต้ตอบเกิดขึ้นทันที เพื่อมอบประสบการณ์ที่ลื่นไหลและตอบสนองรวดเร็วแก่ผู้ใช้
อย่างไรก็ตาม แม้รูปแบบการสื่อสาร microservices แบบ synchronous จะมีข้อดีอย่างการตอบสนองแบบ real-time และความเรียบง่าย แต่ก็มีข้อเสียเช่นกัน ไม่ว่าจะเป็น bottleneck ที่อาจเกิดจาก tight coupling, scalability ที่ต่ำเมื่อรับโหลดสูง, response time ที่ช้าลง และ latency สูงในช่วงที่ traffic พุ่ง
ในทางกลับกัน รูปแบบการสื่อสารแบบ asynchronous มักเหมาะสมกับ microservices มากกว่า เพราะสอดคล้องกับหลักการ Loose Coupling ที่ได้กล่าวไว้ก่อนหน้านี้
รูปแบบการสื่อสารนี้แยก service ออกจากกัน โดยให้ส่งและรับข้อความผ่าน broker อย่าง Kafka หรือ RabbitMQ แทนที่จะรอการตอบกลับโดยตรง service จะส่งข้อความไปยัง queue ที่ทำหน้าที่เป็น buffer ทำให้แต่ละ service ทำงานได้อย่างอิสระ service อื่นสามารถประมวลผลข้อความในจังหวะของตัวเอง ส่วน service ที่ส่งก็ทำงานต่อได้ทันทีโดยไม่ต้องรอผู้รับ
รูปแบบการสื่อสารแบบ asynchronous ไม่เพียงแต่ช่วยให้ microservices แยกออกจากกันได้อย่างชัดเจน แต่ยังให้การตอบสนองแบบ real-time ได้เช่นเดียวกับรูปแบบการสื่อสารแบบ synchronous
สิ่งนี้เป็นผลมาจากสถาปัตยกรรม event-driven ของรูปแบบการสื่อสารแบบ asynchronous event-driven โดย service จะสื่อสารกันด้วยการปล่อย event เมื่อมีการกระทำบางอย่างเกิดขึ้น service อื่นสามารถ subscribe รับ event เหล่านั้นและตอบสนองได้ทันที วิธีนี้ทำให้ระบบตอบสนองต่อการเปลี่ยนแปลงแบบ real-time ได้ โดยไม่มีการ coupling โดยตรงระหว่าง service
นอกจากนี้ ในโหมดอะซิงโครนัส การเผยแพร่และสมัครสมาชิก (Pub/Sub) ในรูปแบบการสื่อสารนี้ service ฝั่ง publisher จะส่งข้อความไปยัง topic และ service ฝั่ง subscriber จะคอยฟัง topic นั้นเพื่อรับการอัปเดต รูปแบบนี้รองรับ subscriber หลายตัวพร้อมกัน ทำให้สามารถกระจายข้อความไปยัง service จำนวนมากได้ในคราวเดียว
สุดท้าย รูปแบบ asynchronous ที่คล้ายกับ event-driven คือ การสวดมนต์ตามการเต้นรำ รูปแบบการสื่อสารนี้ก็ใช้ event ในการสื่อสารระหว่าง service เช่นกัน แต่จะแตกต่างตรงที่มีลำดับที่กำหนดไว้ชัดเจน กล่าวคือ แต่ละ event จะกระตุ้น service ถัดไปและขั้นตอนถัดไปตามลำดับที่วางไว้
ข้อแตกต่างหลักคือ ใน event-driven pattern ไม่มีลำดับหรือ workflow ที่ตายตัว และ service หลายตัวสามารถตอบสนองต่อ event เดียวกันได้ ในขณะที่ choreography-based saga pattern จะมีกระบวนการและลำดับที่แน่นอน
การเลือกรูปแบบการสื่อสารแบบ asynchronous ขึ้นอยู่กับงานและหน้าที่โดยรวมของ microservices Message queue อย่าง RabbitMQ และ Amazon SQS มักใช้สำหรับการจัดตารางงาน การกระจาย workload และงาน e-commerce เช่น การประมวลผลคำสั่งซื้อและระบบแจ้งเตือน
Event-driven message broker อย่าง Apache Kafka และ AWS EventBridge มักใช้สำหรับประมวลผล event stream ขนาดใหญ่แบบ real-time และการจัดเส้นทาง event ระหว่าง microservices ในงานด้านการเงินและสภาพแวดล้อม AWS
สำหรับ Publish-Subscribe (Pub/Sub) message broker อย่าง Google Cloud Pub/Sub และ Redis Streams มักใช้สำหรับการส่งข้อความในระบบกระจายขนาดใหญ่ งาน real-time analytics การรับ event และระบบแจ้งเตือนแบบ real-time รวมถึงแอปพลิเคชันแชท
สุดท้าย choreography-based saga message broker ใช้งานหลักในการประมวลผลคำสั่งซื้อของ eCommerce ระบบจองการเดินทาง และกรณีที่ต้องประสานงาน transaction ที่ซับซ้อนหลายขั้นตอนข้ามหลาย service โดยไม่มีตัวควบคุมกลาง
การค้นหาบริการไมโครเซอร์วิส
เมื่อกำหนดและนำรูปแบบการสื่อสารที่เหมาะสมไปใช้แล้ว สิ่งต่อไปที่ต้องมั่นใจคือ service แต่ละตัวสามารถค้นหาตำแหน่งของกันและกันได้ ดังที่กล่าวไว้ก่อนหน้านี้ เครื่องมือ orchestration อย่าง Kubernetes มีบทบาทสำคัญใน microservice service discovery
ทำได้ผ่าน service discovery ที่มีมาในตัวของ Kubernetes DNS ซึ่งจะอัปเดต IP address และ record ของ DNS แบบ dynamic เมื่อ service มีการ scale หรือเปลี่ยนตำแหน่งภายใน cluster
วิธีการ microservices service discovery นี้เรียกว่า server-side discovery เพราะความรับผิดชอบในการกำหนดเส้นทางถูกมอบให้ load balancer ซึ่งจะ query registry และส่ง traffic ไปยัง instance ที่เหมาะสม
ในทางกลับกัน ยังมีวิธีการแบบ client-side discovery สำหรับ microservice service discovery โดย service หรือ API gateway จะ query service registry อย่าง Consul หรือ Eureka เพื่อค้นหา instance ที่พร้อมใช้งาน
การเลือกวิธี service discovery ที่เหมาะสมกับ microservices ขึ้นอยู่กับความต้องการและขนาดของระบบ
ด้วย client-side microservice service discovery ฝั่ง client จะมีอำนาจเต็มในการเลือก instance ที่ต้องการสื่อสารด้วย วิธีนี้ช่วยให้ปรับแต่งได้มากขึ้น และยังลดความซับซ้อนเพราะไม่ต้องมี centralized discovery service
ตัวอย่างเช่น Netflix ใช้ client-side microservice service discovery ร่วมกับ Eureka และ Ribbon สำหรับ load balancing ทำให้ client สามารถเลือก instance ที่ดีที่สุดตามเกณฑ์อย่าง latency และ server load
อย่างไรก็ตาม server-side microservice service discovery เหมาะกว่าสำหรับสภาพแวดล้อมขนาดใหญ่ เพราะ centralized service discovery ช่วยเพิ่มประสิทธิภาพและทำให้ load balancing สม่ำเสมอทั่วทั้งระบบกระจาย
โซลูชัน server-side microservice service discovery อย่าง Kubernetes, AWS Elastic Load Balancing และ API Gateway (Kong, NGINX และอื่น ๆ) ช่วยกำหนดเส้นทาง traffic ได้อย่างมีประสิทธิภาพและรักษา high availability โดยบริษัทอย่าง Airbnb, Pinterest, Expedia และ Lyft ต่างก็ใช้งานโซลูชันเหล่านี้
ความปลอดภัยของไมโครเซอร์วิส
แม้ว่าสถาปัตยกรรมแบบ Monolithic จะด้อยกว่า MSA ในหลายด้าน แต่จุดที่ Monolithic เคยได้เปรียบคือเรื่องความปลอดภัย เนื่องจาก Microservices ถูกสร้างบนหลักการ Loose Coupling และมีลักษณะกระจายตัว จึงไม่สามารถใช้มาตรการรักษาความปลอดภัยแบบเดียวครอบคลุมทั้งระบบได้
เนื่องจากแต่ละ Service ต้องได้รับการรักษาความปลอดภัยแยกกัน จึงจำเป็นต้องมีมาตรการเพิ่มเติม เพราะพื้นผิวที่อาจถูกโจมตีนั้นกว้างกว่า Monolithic มาก ในแง่นี้ มาตรฐานอย่าง OAuth2 และ JSON Web Tokens (JWT) จึงถูกนำมาใช้เพื่อการยืนยันตัวตนและการกำหนดสิทธิ์เป็นหลัก
นอกจากนี้ มักมีการใช้ API Gateway เพื่อจัดการความปลอดภัยใน Microservices โดยบังคับใช้การยืนยันตัวตนและการกำหนดสิทธิ์ที่จุดเข้าถึงหลัก ยิ่งกว่านั้น API Gateway ยังรองรับ Rate Limiting, Logging และ Monitoring ซึ่งเพิ่มชั้นความปลอดภัยให้กับ Microservices ได้อีกด้วย
อย่างไรก็ตาม การรักษาความปลอดภัยที่จุดเข้าถึงหลักเพียงอย่างเดียวยังไม่เพียงพอ ยังจำเป็นต้องมีมาตรการเพิ่มเติมเพื่อครอบคลุมการสื่อสารระหว่าง Service ด้วย
นี่คือจุดที่ Service Mesh เข้ามามีบทบาท โดยเพิ่มชั้นความปลอดภัยระดับเครือข่าย เข้ารหัสการรับส่งข้อมูลระหว่าง Service และบังคับใช้นโยบายต่าง ๆ เช่น Mutual TLS โดยพื้นฐานแล้ว Service Mesh จะสร้างการเข้ารหัสแบบ End-to-End ที่ครอบคลุม ซึ่งช่วยยกระดับความปลอดภัยของ Microservices ได้อย่างมีนัยสำคัญ
การปรับขนาด Microservice
หนึ่งในข้อดีที่โดดเด่นที่สุดของ MSA และเหตุผลหลักที่มันถูกพัฒนาขึ้นมาแทน Monolithic คือความสามารถในการ Scale ที่สูง โดยทั่วไป Microservices สามารถ Scale ได้สองแบบ คือ Vertical และ Horizontal
โดยพื้นฐานแล้ว Vertical Scaling (Scale Up) คือการเพิ่มทรัพยากรให้กับ Instance ที่มีอยู่ เช่น CPU หรือหน่วยความจำ ส่วน Horizontal Scaling (Scale Out) คือการกระจายโหลดและเพิ่มความจุของระบบ
ในแง่ของการดำเนินการ Vertical Scaling ทำได้ง่ายกว่า เพราะเพียงแค่ปรับ Instance เดียว ไม่ว่าจะเป็นการอัปเกรดไปใช้ Server ที่ใหญ่ขึ้น เพิ่มหน่วยความจำหรือกำลังประมวลผลใน Cloud Instance หรือเพิ่มพื้นที่จัดเก็บข้อมูล
การ Scale แบบนี้มักใช้ในกรณีที่การเพิ่ม RAM หรือกำลัง CPU สามารถปรับปรุงประสิทธิภาพ Query และการประมวลผลข้อมูล เช่น Service ที่รับผิดชอบงาน In-memory Caching
อย่างไรก็ตาม แม้ Vertical Scaling จะทำได้ง่ายและให้ผลตอบสนองด้านประสิทธิภาพทันที แต่ก็มีข้อจำกัด Vertical Scaling ถูกจำกัดด้วยความจุฮาร์ดแวร์ของ Server ดังนั้นในบางจุดคุณจะต้องเปลี่ยนไปใช้ Horizontal Scaling เพื่อให้ระบบเติบโตต่อไปได้
นอกจากนี้ Vertical Scaling มีต้นทุนสูง เพราะฮาร์ดแวร์และ Instance ขนาดใหญ่มักมีราคาแพง และสุดท้าย หาก Instance ที่ Scale Up แล้วเกิดล้มเหลว Service ทั้งหมดจะหยุดทำงาน เนื่องจากไม่มี Instance สำรองมารับโหลดแทน
สำหรับ Horizontal Scaling แทนที่จะอัปเกรดทรัพยากรของ Instance เดิม คุณจะ Deploy Instance ใหม่ของ Service นั้นเพิ่มขึ้นมา แม้ Instance เหล่านี้จะทำงานแยกกัน แต่ก็ยังรองรับ Service เดียวกันและรับผิดชอบส่วนหนึ่งของ Workload เดียวกัน
ต่างจาก Vertical Scaling ตรงที่ Horizontal Scaling ไม่มีขีดจำกัด คุณสามารถเพิ่ม Instance ได้มากเท่าที่ต้องการเพื่อรองรับ Workload ที่เพิ่มขึ้นและช่วง Traffic Spike ทำให้ระบบสามารถขยายได้อย่างยืดหยุ่น
ยิ่งกว่านั้น เมื่อมีหลาย Instance หาก Instance หนึ่งล้มเหลว Instance อื่นยังคงรับ Request ต่อได้โดยไม่สะดุด ซึ่งต่างจากการที่ความล้มเหลวทั้งหมดกระจุกอยู่ที่จุดเดียว และในระยะยาว Horizontal Scaling ยังคุ้มค่ากว่ามาก เพราะใช้ Instance ขนาดเล็กราคาถูกหลายตัวมารวมกันให้ประสิทธิภาพที่ดีกว่าและเชื่อถือได้มากกว่า
อย่างไรก็ตาม Horizontal Scaling และการเพิ่ม Instance จำเป็นต้องใช้ Load Balancer เพิ่มขึ้น รวมถึง Microservice Service Discovery และเครื่องมือ Microservice Orchestration ซึ่งทำให้สถาปัตยกรรม Microservices ของคุณซับซ้อนขึ้นอย่างมาก
Horizontal Scaling เหมาะสำหรับ Use Case เช่น Web Service และแอปพลิเคชันอย่าง E-commerce หรือ Social Media Platform ซึ่งมักเผชิญกับ Traffic ที่ผันผวนและปริมาณ Request สูง
อย่างไรก็ตาม นี่ไม่ใช่การเลือกอย่างใดอย่างหนึ่ง เพราะ Microservices รองรับทั้งสองรูปแบบและมักต้องใช้ทั้งคู่ โดยทั่วไปองค์กรขนาดเล็กจะเริ่มด้วย Vertical Scaling เพราะจัดการได้ง่ายกว่า แต่เมื่อแอปพลิเคชันเติบโตขึ้น Horizontal Scaling จะถูกนำมาใช้เพื่อรองรับความต้องการที่เพิ่มสูงขึ้น
สุดท้าย Cloud Platform มักมีบริการ Auto-scaling ที่เพิ่มหรือลด Instance โดยอัตโนมัติตามความต้องการจริงในแต่ละช่วงเวลา ซึ่งช่วยให้องค์กรสามารถสมดุลระหว่าง Vertical และ Horizontal Scaling ได้อย่างมีประสิทธิภาพ
การตรวจสอบ Microservice
เมื่อถึงขั้นตอนนี้ การ Deploy Microservices ของคุณก็เกือบเสร็จสมบูรณ์แล้ว สิ่งที่เหลืออยู่คือการตรวจสอบให้แน่ใจว่าระบบทำงานได้อย่างสม่ำเสมอและเชื่อถือได้ นี่คือจุดที่เครื่องมือ Microservice Monitoring อย่าง Prometheus และ Grafana เข้ามา
เครื่องมือเหล่านี้ให้ข้อมูล Metric ของ Service แบบ Real-time เพื่อให้ทีมติดตามการใช้ทรัพยากร, Latency และอัตรา Error ได้ นอกจากนี้ยังรองรับ Distributed Tracing (เช่น Jaeger, Zipkin) ซึ่งช่วยให้มองเห็นเส้นทาง Request ที่ไหลผ่าน Service ต่าง ๆ และมีประโยชน์อย่างมากในการวินิจฉัยปัญหา
สุดท้าย เนื่องจากความล้มเหลวสามารถแพร่กระจายไปยัง Service อื่นได้เพราะลักษณะกระจายตัวของ Microservices การรวบรวม Log จึงเป็นแนวปฏิบัติที่สำคัญใน Microservice Monitoring การนำ Log มารวมไว้บน Platform กลางและตั้งค่าการแจ้งเตือน Real-time จะช่วยให้คุณรู้ปัญหาก่อนที่มันจะส่งผลกระทบต่อผู้ใช้
สรุป
แม้โลกของ Microservices จะมีความซับซ้อนสูง แต่การเข้าใจพื้นฐานและขั้นตอนหลักของการ Deploy Microservices จะช่วยให้กระบวนการทั้งหมดง่ายขึ้นมาก ยิ่งกว่านั้น เครื่องมือใหม่ ๆ ที่มีฟีเจอร์ครบครันก็มีให้เลือกใช้มากขึ้นเรื่อย ๆ ทำให้การ Deploy Microservices ทำได้ง่ายกว่าที่เคย
คำถามที่พบบ่อย
กลยุทธ์การ Deploy ที่นิยมใช้กับ Microservices มีอะไรบ้าง?
แม้จะมีกลยุทธ์การ Deploy Microservices หลายรูปแบบ แต่ที่นิยมใช้มากที่สุด ได้แก่ Service Instances per Container, Phased Release, Blue-green Deployment และ Serverless Deployment ซึ่งแต่ละแบบให้ระดับของการแยกส่วน, ความยืดหยุ่น และความสามารถในการ Scale ที่แตกต่างกัน
Kubernetes มีบทบาทอย่างไรในการจัดการ microservices?
Microservices ต้องพึ่งพาเครื่องมือจัดการ microservice อย่าง Kubernetes เพื่อทำให้การ deploy การปรับขนาด และการจัดการ containerized services เป็นอัตโนมัติ รวมถึงรองรับ load balancing, auto-scaling และความสามารถในการซ่อมแซมตัวเอง เพื่อให้ microservices ทำงานได้อย่างมีประสิทธิภาพและเสถียร
จะรับประกันความปลอดภัยใน microservices environment ได้อย่างไร?
เนื่องจาก microservices มีลักษณะกระจายตัว การดูแลความปลอดภัยจึงซับซ้อนกว่า monolithic architecture การรักษาความปลอดภัยใน microservices ครอบคลุมการยืนยันตัวตนและการอนุญาต request การเข้ารหัสการสื่อสารระหว่าง service รวมถึงการติดตั้ง API gateway และ service mesh เช่น Istio เพื่อจัดการความปลอดภัยจากศูนย์กลาง
