เจาะลึกระบบไอที: เซิร์ฟเวอร์ค้นหากันเองได้อย่างไรด้วย DNS
ไขข้อสงสัยเบื้องหลังการสื่อสารของเซิร์ฟเวอร์ในระบบคลาวด์ ตั้งแต่ Public DNS, Private DNS ไปจนถึง Service Discovery
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เซิร์ฟเวอร์ในระบบคลาวด์สื่อสารกันได้โดยไม่ต้องพึ่งพาอินเทอร์เน็ตสาธารณะ
- DNS ทำหน้าที่แปลงชื่อโดเมนให้กลายเป็นหมายเลข IP Address เพื่อให้คอมพิวเตอร์ติดต่อกันได้
- Private DNS ช่วยจัดการชื่อเซิร์ฟเวอร์ภายในองค์กรอย่างปลอดภัยโดยไม่เปิดเผยสู่โลกภายนอก
- Service Discovery ทำหน้าที่เป็นหอควบคุมการบินเพื่อจัดการอินสแตนซ์และสถานะสุขภาพของบริการ
การเชื่อมต่อระหว่างเว็บเซิร์ฟเวอร์และฐานข้อมูล เช่น PostgreSQL ภายในสภาพแวดล้อมคลาวด์อย่าง AWS, Azure, GCP หรือศูนย์ข้อมูลส่วน องค์กร ไม่จำเป็นต้องอาศัยเครือข่ายอินเทอร์เน็ตสาธารณะ แต่คำถามสำคัญที่นักพัฒนาหลังบ้านต้องเผชิญคือ เซิร์ฟเวอร์เหล่านี้รู้ได้อย่างไรว่าอีกเครื่องหนึ่งตั้งอยู่ ณ จุดใด เนื่องจากเซิร์ฟเวอร์ไม่ใช่ มนุษย์ การค้นหาตำแหน่งจึงเป็นโจทย์สำคัญที่นำไปสู่การพัฒนาสถาปัตยกรรมระบบกระจายตัวในปัจจุบัน
หากเปรียบเทียบกับการใช้ชีวิตประจำวัน มนุษย์เราจดจำสถานที่ด้วยชื่อ เช่น โรงพยาบาล ธนาคาร หรือร้านอาหาร แทนที่จะจำพิกัด GPS เป็นตัวเลขยาวเหยียด คอมพิวเตอร์ก็ทำงานในลักษณะเดียวกันผ่านระบบ Domain Name System (DNS) ซึ่งทำหน้าที่แปลงชื่อโดเมนให้อยู่ในรูปของ IP Address ยกตัวอย่างเช่น เมื่อผู้ใช้งานพิมพ์ google.com คอมพิวเตอร์จะส่งคำถามไปยังระบบ DNS เพื่อหาค่า IP Address ก่อนที่การเชื่อมต่อจะเริ่มต้นขึ้นได้ กระบวนการนี้ช่วยป้องกันไม่ให้อินเทอร์เน็ตกลายเป็นตารางสเปรดชีตขนาดมหึมาของหมายเลข IP
ในเชิงสถาปัตยกรรมไอที การทำความเข้าใจกลไกการแปลงชื่อและการค้นหาบริการถือเป็นหัวใจสำคัญของการสร้างระบบที่มีความเสถียรสูง (High Availability) การพึ่งพาหมายเลข IP แบบตายตัวในระบบสมัยใหม่ที่มีการขยายตัวและหดตัวตลอดเวลาจะสร้างความเสี่ยงด้านการปฏิบัติงานอย่างมาก แนวทางอย่าง Private DNS และ Service Discovery จึงถูกออกแบบมาเพื่อลดความซับซ้อนและเพิ่มความยืดหยุ่นให้โครงสร้างพื้นฐาน
อย่างไรก็ตาม เว็บไซต์สาธารณะใช้งาน Public DNS ได้ดี แต่บริการภายในระบบหลังบ้าน เช่น API, Redis, PostgreSQL, RabbitMQ หรือ Elasticsearch ไม่ควรถูกเปิด 100% สู่สาธารณะโดยเด็ดขาด องค์กรจึงต้องใช้ Private DNS ซึ่งเปรียบเสมือนสมุดรายชื่อภายในบริษัทที่พนักงานหรือทรัพยากรภายใน Virtual Private Cloud (VPC) เท่านั้นที่เข้าถึงได้ ผ่านชื่อโดเมนภายในอย่าง db.internal หรือ redis.internal โดยที่อินเทอร์เน็ตภายนอกไม่มีทางรับรู้ถึงการมีอยู่ของชื่อเหล่านี้
เมื่อนักพัฒนาสร้างแพลตฟอร์มขนาดใหญ่ที่มีสถาปัตยกรรมซับซ้อน เช่น ระบบอีคอมเมิร์ซ การกำหนดค่าหมายเลข IP เช่น 10.0.12.55 ลงในแอปพลิเคชันโดยตรงจะกลายเป็นฝันร้ายในการบริหารจัดการโครงสร้างพื้นฐาน เพราะหากโครงสร้างต้องย้ายฐานข้อมูลไปยัง IP ใหม่ ทีมงานจะต้องคอยแก้ไขค่าด้วยมือ นี่จึงเป็นจุดที่แนวคิดเรื่อง Service Discovery เข้ามาแก้ปัญหาการค้นหาบริการแทนการค้นหาเครื่องคอมพิวเตอร์รายเครื่อง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในยุคที่ระบบถูกย่อยเป็น Microservices เช่น User Service, Order Service, Payment Service และ Notification Service แต่ละบริการอาจรันอยู่บนอินสแตนซ์จำนวนมาก เช่น Payment Service ที่มีทั้ง payment-1 ถึง payment-4 เมื่อ User Service ต้องการเรียกใช้งาน Payment Service การใส่ค่าแบบฮาร์ดโคดจึงเป็นไปไม่ได้ เพราะระบบต้องรู้ว่ามีบริการใดบ้าง ตั้งอยู่ ณ จุดใด และบริการเหล่านั้นยังมีสุขภาพดีพร้อมทำงานหรือไม่
ระบบ Service Discovery จึงเปรียบเสมือนหอควบคุมการจราจรทางอากาศสำหรับบริการต่างๆ โดยบริการจะคอยส่งสัญญาณแจ้งสถานะและที่อยู่ไปยัง Registry และเมื่อบริการอื่นต้องการติดต่อ ระบบ Registry จะทำหน้าที่บอกว่าควรส่งคำขอไปยังอินสแตนซ์ใด เช่นเดียวกับที่ Netflix เคยพัฒนาแพลตฟอร์มชื่อ Eureka ขึ้นมาเพื่อแก้ความท้าทายนี้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น