เรื่องของ API Gateway จากหนังสือ Practical Site Reliability Engineering (SRE)

จากหนังสือ Practical Site Reliability Engineering (SRE) มีหลายเรื่องที่น่าสนใจ ยกตัวอย่างเช่น

• เป้าหมายของ SRE เป็นอย่างไร
• Docker นั้นช่วยเปิดทางให้เข้าสู่โลกของ container ได้อย่างไร
• ว่าด้วยเรื่องของการนำ DevOps และ Microservice มาให้ให้เกิดประโยชน์
• แนวคิดของ Service Mesh ตลอดจนการนำมาใช้งาน
• แนวปฏิบัติที่ดีสำหรับเรื่องของ performance และ reliability ของระบบ
• ว่าด้วยเรื่องของการจัดการ container จำนวนมาก ๆ ด้วย Kubernetes
• เข้าใจขั้นตอนการพัฒนาระบบงานตั้งแต่ต้นจนจบ ด้วยการนำ container มาใช้งาน

ใน blog นี้ได้หยิบหัวข้อเรื่องของ Microservice API Gateway มาอธิบาย เพื่อให้เห็นภาพและเข้าใจว่า มันคืออะไร ทำไมต้องนำมาใช้งาน ถ้าไม่ใช้ได้ไหม มาเริ่มกันเลย

API Gateway คืออะไร ?

เรียนได้ว่าเป็น Single Point of Contract ของ service จำนวนมากมายของเรา ยิ่งในโลกของ Microservice จะมี service จำนวนมาก ทำให้การเข้าถึง service เหล่านั้นน่าจะยาก จึงน่าจะมีตัวกลางในการเข้าถึงดีกว่าไหม ? โดยใน API Gateway นั้นจะมีความสามารถต่าง ๆ ดังนี้

• ทำการ register และ publish service ต่าง ๆ
• เป็นคนกลางในการจัดการ service ต่าง ๆ
• เป็นตัว route ไปยัง service ต่าง ๆ
• ทำการ verification ของ request ต่าง ๆ
• ทำการกรองข้อมูล ก่อนที่จะส่งต่อไป
• ทำการ authentication และ authorization แต่ละ request
• ทำการ monitoring การทำงานของ service ต่าง ๆ

แสดงดังรูป เมื่อระบบงานมีผู้ใช้งานจากหลาย ๆ ช่องทาง เช่น Web, Mobile และ application เป็นต้น สามารถเข้าใช้งานระบบเพียงที่เดียว และจะทำให้ผู้สร้างและดูแลระบบสะดวกสบายขึ้น

ประโยชน์ของ API Gateway มีอะไรบ้าง ?

• ซ่อนการเปลี่ยนแปลงของ service จากผู้ใช้งานภายนอก
• จัดการเรื่องของ security ของ service ได้ง่ายขึ้น
• เป็นตัวแปลง protocol การติดต่อสื่อสารระหว่าง service กับผู้ใช้งาน เช่นผู้ใช้งานติดต่อมายัง API Gateway ผ่าน HTTP จากนั้น API Gateway ก็ทำการติดต่อไปยัง service ผ่าน protocol อื่น ๆ ตามแต่ละ service ต่อไปได้
• ลดความซับซ้อนของ Microservice ลง ทำให้แต่ละ service ไปเน้นที่ business เป็นหลัก

เมื่อมันมีข้อดีก็ต้องมีข้อเสีย !!!

• กลายเป็น Single Point of Failure ไปได้
• ใครเป็นคนดูแลระบบนี้ ?
• จำเป็นต้องมี infrastructure ที่ดี
• อาจจะทำให้ business logic ไปอยู่ใน API Gateway มากเกินไป ทำให้เกิด vendor locked-in ได้ง่าย
• เกิดความซับซ้อนขึ้นมาในอีกจุด และอาจจะทำให้เกิดปัญหาคอขวดได้

 

อีกเรื่องที่น่าสนใจคือ Security ใน API Gateway

ถ้าเราเพิ่งพามาก ๆ จำเป็นต้องมีรูปแบบที่ดี เพื่อทำให้มั่นใจว่า service ของเราปลอดภัยทั้งการทำงานและข้อมูล ยกตัวอย่างดังรูปแสดงเรื่องของ authentication และ authorization

คำถามที่น่าสนใจคือ ทำไมระบบเราต้องมี API Gateway ด้วยละ ?