เริ่มต้นใช้ API Gateway service บน Google Cloud
ลองใช้ API Gateway service ทั้ง Cloud Endpoints และ API Gateway (Beta) บน Google Cloud Platform
API Gateway
ทุกวันนี้การพัฒนาหรือใช้งาน API ถือว่าเป็นเรื่องปกติมากสำหรับ Developer และส่วนใหญ่ก็มีประสบการณ์ด้านนี้มาบ้างแล้ว ผมเลยจะขอข้ามไปว่า API คืออะไร บลา ๆ เลยก่อนละกัน
แต่ในบทความนี้เราจะมาโฟกัสกันที่ตัว API Gateway !!!
API Gateway คืออะไร ???
API Gateway เป็นประตูสำหรับการเข้าถึง API service ของเรา หรือมองได้ว่าเป็นเครื่องมือที่มาช่วยจัดการ Request ควมคุม กำหนด permission ต่าง ๆ ก่อนที่จะเข้าถึง Resource ของระบบเรา
API Gateway มีประโยชน์อย่างไร ?
ให้ลองนึกถึงว่าเรามี API services หลายตัว ตามภาพด้านล่าง
Client with API service
จะพบว่าถ้าเรามีหลาย services ซึ่งแต่ละ service เองก็จะมีหน้าที่ ที่แตกต่างกัน Client ก็จะเรียกใช้งาน service ต่าง ๆ ตาม domain service ที่ต้องการใช้งาน ซึ่งก็เป็นท่าทั่วไปที่เราสามารถใช้กันได้ แต่ถ้ากรณีมีหลาย service ก็จะใช้เวลามากขึ้นตามไปด้วย
ในขณะเดียวกัน API service ก็จะมีลักษณะงานที่คล้ายคลึงกันอยู่ในทุก ๆ service เช่น Authentication, Logging และอื่น ๆ เป็นต้น ตามภาพด้านล่าง
tasks on API services
จะดีกว่าไหม ถ้าให้งานลักษณะดังกล่าวมาอยู่รวมกัน ในจุด ๆ เดียวกันหมดเลย เพื่อลดความซ้ำซ้อนและง่ายต่อการ maintain ตามภาพด้านล่างนี้
API Gateway
ซึ่งจากภาพจะเห็นว่ามี proxy ตรงกลางมาคั้นก่อนที่ client จะ access ไปที่ API ของเรา รวมถึงการทำ Authentication, Logging, Rate Limit หรือการกำหนด permission ต่าง ๆ จะมารวมตัวกันที่ Gateway ดังนั้น API Service ของเราไม่จำเป็นที่ต้องเขียน code เพื่อ develop feature ดังกล่าวแล้ว ปล่อยให้ Gateway ทำหน้าที่จัดการไป ในขณะเดียวกัน client ก็ไม่ต้องเรียก API แยกตาม service แล้วสามารถที่จะ request เข้าไปที่ Gateway และให้ Gateway จัดการ routing ไปยัง service ปลายทางได้เลย ถ้าเข้าใจง่าย ๆ คือ จัดการ Ingress ของระบบเราให้ง่ายขึ้น ไม่ต้องกังวลหากมีหลาย services จะ maintain ลำบาก เพราะจัดการทุกอย่างที่เดียว (Single Point)
API Gateway services บน Google Cloud
ใน Google Cloud เองก็จะมี service ที่ค่อยให้บริการ API Gateway โดยเฉพาะเลย ซึ่งมีอยู่ 3 services ได้แก่
- Cloud Endpoints
- API Gateway (Beta)
- Apigee
ในบทความนี้เราจะขอข้าม Apigee ไปก่อน เพราะว่าถ้าอิงจาก Docs จริง ๆ แล้วตัว Apigee ถือว่าเป็น Platform เลย ไม่ใช่แค่ service แล้ว เพราะมี feature + capabilities สูงมาก รองรับงาน scale เล็ก ๆ จนถึง Enterprise ได้เลย และเป็นเจ้าตลาด API Gateway มาหลายปี ดังนั้นเนื้อหาอาจจะเยอะเกินไป เลยขอข้ามไปก่อนครับ ไว้มีโอกาสจะเขียนเป็น blog แยกไปเลย
Cloud Endpoints
เรียกได้ว่าเป็นตัวบุกเบิกของ Google Cloud ก็ได้ เพราะมีมาประมาณ 5 ปีได้แล้ว โดยตัว Endpoints ก็จะมี Component อยู่ประมาณ 3 ตัว เช่น ESP (Extensible Service Proxy), Developer Portal และ Endpoints service นั้นเอง
Cloud Endpoints Flow
โดยก่อนที่เราจะใช้ Cloud Endpoints เราจะต้อง deploy ตัว ESP ขึ้นมาก่อนลักษณะหน้าที่มันจะคล้ายกับ Nginx คือเป็น Proxy กั้นก่อนที่จะไปถึง API services ซึ่ง ทาง GCP เค้าจะมี Image Container มาให้แล้ว เราแค่กำหนดค่า configuration ต่าง ๆ เช่น Endpoints Revision ID, OpenAPI config เข้าไปในตอน Build เท่านั้นเอง
ดังนั้นถ้าใครจะเริ่มใช้ Endpoints อาจจะต้องมีความเข้าใจเรื่อง Container มาแล้วนิดนึงครับ
API Gateway (Beta)
ถือว่าเป็น API Gateway service น้องใหม่ได้เลย เพราะเพิ่ง release มาในช่วง Q2/2020 นี่เอง ด้วยความที่เพิ่งออกมาใหม่ feature หลาย ๆ อย่าง อาจจะยังไม่สมบูรณ์นัก แต่เราจะเริ่มเห็นการใช้งาน Serverless กับ API Gateway แล้ว (ชื่อ service คือ API Gateway เลยนะครับ ตอนนี้ยังเป็น Beta อยู่)
API Gateway (Beta)
จาก Cloud Endpoints เราจะเห็นว่าต้องมีตัว ESP มาเป็น Proxy server ให้ Gateway ซึ่งเราต้องทำการ Build + Deploy เอง แต่งานในส่วนนี้จะหายไป เพราะ API Gateway (Beta) จะทำการจัดการให้เราแล้ว Google Cloud จะดูแลส่วนนี้ให้เลย ทำให้เราไปโฟกัสและจัดการแค่ตัว OpenAPI Config เท่านั้น
ลองใช้งาน API Gateway
โดยใน blog นี้เราจะลองสร้าง API Gateway ด้วย Google Cloud Service ขึ้นมาดู เนื่องด้วยสอง services ที่เรากล่าวถึงมีความคล้ายคลึงกันมากในเชิงการใช้งานเลยจะขออธิบายทั้งสองตัวเลยครับทั้ง Cloud Endpoints และ API Gateway (Beta)
อาจจะไม่ได้แสดงขั้นตอนการใช้ UI สักเท่าไหร่ จะเน้นไปใช้ command gcloud ดังนั้นถ้าใครอยากลองทำตาม ก็ทำการ install gcloud command ไว้ก่อนครับ
โดย tools, component ที่เราต้องเข้าใจก่อนที่จะเริ่ม มีดังต่อไปนี้
OpenAPI/Swagger
ทำหน้าที่เป็น Configuration ให้ Cloud Endpoints, API Gateway (Beta) เพื่อเป็นตัวควมคุม Gateway และการกำหนด Policy ต่าง ๆ จนถึงการอธิบายด้วยตัว API Document ว่า resource นี้รับ Request schema แบบไหนและ return อะไรบ้าง ต้องทำการ Authentication ก่อนหรือไม่ เป็นต้น
OpenAPI Swagger
ตามภาพด้านบน เราจะเห็นด้านซ้ายคือตัว code ที่บอกว่า API ของเรามีอะไรบ้าง รับส่งข้อมูลอะไร ต้องทำการ Authentication ด้วยวิธีแบบไหน ซึ่งเจาะไปถึงระดับ Path และ Method เลย
ส่วนด้านขวาคือ Render ตัว code ออกมาให้เห็นอ่านง่ายขึ้นเฉย ๆ แต่ก็สามารถทำ Interactive ใช้งานจริงได้ แค่เอาไป Deploy ครับ หรือในกรณีใช้ Endpoints สามารถไปลองเล่นได้ที่ตัว Developer Portal
ทำไม Gateway ถึงต้องใช้ OpenAPI Docs
Gateway จะใช้ OpenAPI Docs เปรียบเสมือน Configuration เพื่อทำการ restrict request ที่เข้ามาว่าต้องมีข้อมูลอะไรส่งมาบ้าง ตามภาพด้านล่างนี้
จะเห็นว่า /api/v1/stock/info มี method GET อยู่ ซึ่งข้างในนั้นก็จะมีข้อมูลว่า client ที่ต้องส่งอะไรบ้างและจะได้รับอะไรกลับไปบ้าง เช่น client ต้องส่ง header Authorization แบบ Firebase มาทำ Authentication, API service จะ return 200 OK และตัวสำคัญคือ x-google-backend คือตัวที่จะกำหนดว่า path นี้จะไป service ไหน ตาม URL domain ที่เรากำหนด
ในขณะเดียวกัน ถ้า client ส่ง request มาครบถ้วนไม่มี Invalid เลย ตัว Gateway เองก็จะส่ง request ไปที่ API Service ต่อ โดยกรณีถ้าเราทำ Authentication ตัว Gateway จะจัดการตรวจสอบตรงนี้ให้และจะส่ง Header มาให้ฝั่ง API service สำหรับการระบุตัวตน client
ถ้ากรณีใช้ Firebase ตัว Gateway จะส่งค่า X-Endpoints-Api-UserInfo ผ่าน Header
กรณี Authentication ไม่ผ่าน ก็จะ return errorกลับไปหา client ทันที
(ถ้าใครมองหา framework ที่จะ generate ตัว API docs มาให้เลย แล้วใช้ Python อยู่ แนะนำให้ลองใช้ตัว FastAPI ครับ อ่านบทความ คลิกที่นี่)
API service
ถ้าเรามีแต่ Gateway ก็คงแปลก ๆ อยู่ เหมือนมีแต่ประตู เปิดแล้วเจอแต่ห้องว่าง ๆ เราคงต้องมี API Service ของเราด้วย โดยในบทความนี้จะ Mock API service เป็นแบบ RESTful ง่าย ๆ ขึ้นมา
ในบทความนี้จะใช้ตัว Cloud Run เป็นตัว Host API Service เพื่อความง่ายและรวดเร็ว สามารถดูรายละเอียดการใช้งาน Cloud Run ได้ที่นี
โดยผมจะทำการ Deploy ไว้บน Cloud Run และปิด Public Access ไว้ หมายถึงว่า Client ที่จะเข้ามาได้ จะต้องทำการ Authentication ก่อน
สำหรับใครที่ไม่อยากเสียเวลาอ่าน สามารถไปดู code ได้ที่ GitHub ได้เลยครับ คลิกที่นี่
เริ่มใช้งาน Cloud Endpoints
โดยตัวอย่างนี้จะใช้ Cloud Run เป็นหลัก ทั้งตัว ESP และ API services ตามภาพด้านล่างนี้
Cloud Endpoints Demo Diagram
เริ่มต้นการใช้งาน ESP
ESP Deployment
Diagram ด้านบนคือขั้นตอนการ build และ deploy ตัว ESP เดี๋ยวเราจะลองทำตามขั้นตอนด้านบนนี้กัน
1. ทำการ Reserve ESP Hostname
เนื่องด้วยตัวนี้ใช้ Cloud Run อยู่แล้วก็เลยไปเปิด service เพื่อทำการสำรอง Domain ไว้ก่อน
ESP Domain
ณ ตรงนี้จะใช้อะไรมา Deploy ก็ได้ แค่ initial service และ URL Domain ขึ้นมา เท่านั้น
2. กำหนด ESP Hostname ในไฟล์ OpenAPI
OpenAPI Endpoints with ESP Hostname
สำหรับคนที่ อาจจะไม่เข้าใจส่วนนี้หรือไม่คุ้นชินกับ OpenAPI สามารถไปดู code เต็ม ๆ ได้ที่ GitHub เลยครับ คลิกที่นี่
3. Deploy Endpoints service with OpenAPI Docs
ต่อจากนี้เราก็จะทำการ Deploy ตัว endpoints service ด้วย command ด้านล่างนี้
gcloud | Deploy endpoints service
หลังจากที่ทำการ run cmd เสร็จเรียบร้อยแล้วจะได้ผลลัพธ์ประมาณนี้ครับ
Endpoints Revision ID
ให้เราทำการ Copy ตัว 2020–12–28r0 เก็บไว้ครับ เพื่อใช้ในขั้นตอนต่อไป
ตอนนี้เราได้ทำการ deploy service ไปแล้ว ขั้นต่อไปก็คือ enable service ครับ
gcloud | Enable service
4. Build and Deploy ESP container Image
ก่อนอื่นเลย คือทาง GCP เค้าจะมี script สำหรับการ build image container และ push ไปเก็บไว้ที่ Container Registry ให้มาแล้ว ดังนั้นสิ่งที่เราทำการคือการ clone script มาใช้และใส่ parameter เท่านั้นครับ (สามารถดูรายละเอียดได้ที่ GitHub คลิกที่นี่)
Build ESP Image
หลังจากที่เราทำการ Run cmd แล้วจะได้ผลลัพธ์หน้าตาประมาณนี้
Building ESP Image Result
ให้เราทำการ Copy ตัว Image URL มา เพื่อใช้ในการ Deploy ต่อ
gcloud | Deploy cloud run
เท่านี้ก็เสร็จเรียบร้อยแล้ว สำหรับการ Deploy ESP
ทดลองใช้งานยิง Request
เนื่องด้วยว่า OpenAPI ที่ผมได้เขียนใช้กับ Cloud Endpoints ได้ทำการกำหนด Security ไว้หรือหมายถึง Authentication กำหนดไว้ว่าใช้แบบ Firebase ดังนั้นถ้า client ไม่ส่ง Authorization : Beader <Firebase_IdToken> มา Gateway ก็จะ return error ไป
Authentication on OpenAPI Docs
เริ่มต้นด้วยการไม่ส่ง Authorzation
จากภาพด้านบนจะเห็นว่า ถ้ายิง request เข้าไปที่ Gateway เปล่า ๆ ไม่ได้ใส่ Auth ใน Header เข้าไป ตัว Gateway ก็จะ return error กลับมาให้
ส่ง Authorzation แบบถูกต้องเข้าไป
จากภาพด้าน ยิง request เข้าไปที่ Gateway และใส่ Authorization Firebase ที่ถูกต้องเข้าไป ฝั่ง API service ก็ return data กลับมาให้ ทุกอย่างปกติ
ส่วนฝั่ง API service ก็สามารถรับค่า Header[‘x-endpoint-api-userinfo’] ที่ทาง Gateway ได้ส่งไป ซึ่งเราสามารถจะ Implement ต่อ เพื่อระบุตัวตน client ได้
IDToken Base64URL
เริ่มใช้งาน API Gateway (Beta)
หลังจากที่เราได้ลองใช้ตัว Endpoints ไปแล้ว ทีนี้ลองมาใช้อีก service นึง ก็คือ API Gateway (Beta) กันบ้าง
API Gateway (Beta) ลักษณะ concept การทำงานก็ยังทำหน้าที่เป็น Gateway เหมือนเดิม ไม่เปลี่ยนไปมากจาก Endpoints เพียงแต่ว่าการใช้อาจจะง่ายขึ้น เราไม่จำเป็นที่ต้อง Build และ Deploy ESP แล้ว ตัว API Gateway (Beta) จะจัดการดูแลในส่วนนี้ให้ แต่ยังคงใช้ OpenAPI เป็น config อยู่
API Gateway (Beta) จะมีลักษณะของ service และ versioning ของ OpenAPI , Gateway ที่แตกต่างกับ Endpoints นิดหน่อย
ให้เข้าใจง่าย ๆ ว่า APIs คือ parent ที่ใหญ่ที่สุด ข้างใน APIs มี API Config และ Gateway
API Config == OpenAPI Docs
ถ้าเราต้องการที่จะเปิด Gateway ขึ้นมาก็ต้องมี API Config ก่อน
ตัว Gateway จะ require API Config ซึ่งเราสามารถ upload API config ได้กี่ครั้งกี่ version ตามที่เราต้องการได้ และถ้าอยากให้ Gateway อ่าน Config จาก version ไหนก็ทำการตั้งค่าเลือกได้เลย
1.เริ่มต้นสร้าง APIs
gcloud | create APIs
สร้าง APIs เปรียบเสมือน Parent ใหญ่สุดของ API Gateway (Beta) เดี๋ยวเราจะค่อย ๆ เข้าไปสร้าง component แต่ละส่วนใน APIs กัน
หลังจากนั้นเมื่อสร้างเสร็จแล้ว ต้องทำการ Enable service ขึ้นมาด้วย โดยจะ run cmd ที่ Get metadata ของ services ขึ้นมาก่อน
gcloud | describe APIs
ผลลัพธ์จะได้ประมาณนี้ ให้เราทำการ Copy ตัว managedService
Result the gcloud describe APIs
จากนั้นทำการ enable service ด้วย gcloud cmd
gcloud | Enable API Gateway service
2. Upload OpenAPI to API Config
OpenAPI Docs ที่จะใช้กับ API Gateway (Beta) อาจจะแตกต่างกับที่ Cloud Endpoints เล็ก เช่น ไม่จำเป็นต้องประกาศ host แล้ว
ดูรายละเอียด code ได้ที่ GitHub คลิกที่นี่
ในตอนที่จะ Upload config ก็อย่าลืมใส่ — api ที่เราเพิ่งสร้างเข้าไปด้วย
gcloud | create API Config
3. Create Gateway with API Config
หลังจากที่ Upload API Config ขึ้นไปแล้ว ก็ทำการ create Gateway ได้เลย ซึ่งในส่วนนี้เราก็จะทำการใส่ param ต่าง ๆ เช่น APIs, API config และก็ Region Location ของ Gateway
ตอนนี้มี EU, US และใกล้บ้านเราสุดเป็น asis-east1 (Taiwan)
gcloud | create Gateway
ทดลองใช้งานยิง Request
เนื่องด้วย OpenAPI Docs ที่ใช้ demo กับ API Gateway จะใช้วิธี Authentication แบบ API KEY ดังนั้นถ้า client ไม่ส่ง Query string key=
ทดลองยิง request แบบไม่ส่ง API Key
จากภาพด้านบนจะเห็นว่า ถ้ายิง request เข้าไปที่ Gateway เปล่า ๆ ไม่ได้ใส่ API Key ใน Query String เข้าไป ตัว Gateway ก็จะ return error กลับมาให้
ส่ง API KEY แบบถูกต้องเข้าไป
จากภาพด้าน ยิง request เข้าไปที่ Gateway และใส่ Query String ที่เป็น ?key=API_KEY ที่ถูกต้องเข้าไป ฝั่ง API service ก็ return data กลับมาให้ ทุกอย่างปกติ
สรุปการใช้งาน API Gateway services บน Google Cloud Platform
จะเห็นได้ว่าทั้งสอง service นี้สามารถตอบโจทย์งาน API Gateway ได้ดีพอสมควรเมี่อเทียบกับเวลาที่ใช้ Implement และความซ้ำซ้อนของ services ที่ไม่ยากจนเกินไป แบ่งเบาภาระในการดูแล Proxy server เช่น serverless หรือ Auto-scaling ก็สามารถเลือก managed services ที่ Google Cloud support ได้เลย
ทั้งนี้ API Gateway (Beta) อาจมีข้อจำกัดอยู่ในบาง feature ที่ยังไม่ได้เปิดเป็น GA แต่จะว่าเห็นแนวทาง serverless ของตัว Gateway จะช่วยลดภาระในการดูแล Proxy server ได้ค่อนข้างดี กลับกันกับที่ Cloud Endpoints ที่ GA แล้ว Feature หลายอย่างค่อนข้างมีมากกว่า API Gateway (Beta) แต่หากต้องการปรับเปลี่ยน OpenAPI document ก็ต้องทำการ build + Deploy ESP และ deploy Endpoints revision ใหม่ ซึ่งค่อนข้างใช้เวลา
อันที่จริงแล้ว services ที่เกี่ยวข้องกับ API Gateway ของ Google Cloud มี Feature + Tools ที่จะคอยช่วยเหลืองานด้านต่าง ๆ ที่เกี่ยวข้อง เช่น
Developer Portal
เป็น WebUI interface ที่จะ render ตัว OpenAPI มาเป็น Web ที่เราสามารถ Interactive ใช้งานกับ API + Gateway ที่เราได้ทำการ Deploy แล้ว
Authentication via Developer Portal
Response
Monitoring | Logging
Monitoring Proxy Server Usage
Monitoring Proxy Server each Path API
ก็จะเห็นว่า API Gateway service บน Google Cloud มี tool feature หลายอย่างที่ค่อนข้างครอบคลุมกับงานปัจจุบันได้พอสมควร และหากเราใช้งาน Google Cloud แล้วก็ยังสามารถ ไป Integrate กับ service อื่น ๆ ที่เกี่ยวข้องได้อีก เช่น export Log จาก service ไปทำ Data Pipeline เข้า BigQuery ต่อด้วย Visualize บน Data Studio หรือ
กรณีที่ต้องการทำ IaaC สำหรับ API Gateway (OpenAPI Config) แยก จากบทความก็จะเห็นว่าวิธีการ enable service และการ deployment สามารถใช้ gcloud cmd ได้ ซึ่งทำเป็น Continuous Deployment ด้วย Cloud Build ได้เช่นกัน
ทั้งนี้ ถ้าบทความนี้ ผิดพลาดในส่วนใด ๆ สามารถทักท้วงหรือคอมเม้นกันได้ครับ
ขอบคุณครับ
Written by Peem Srinikorn
Cloud Ace Thailand
Make It Now!
หากคุณสนต้องการคำปรึกษา Cloud Ace Thailand พร้อมให้บริการที่จะสนับสนุนคุณตั้งแต่ การให้คำปรึกษา จนถึงการออกแบบระบบ ติดตั้งระบบ ย้ายระบบ ในฐานะ Google Cloud Partner ที่มีความเชี่ยวชาญ และได้รับรางวัล Service partner of the year ในปี 2019
ติดต่อเรา th_sales@cloud-ace.com
Subscribe to us
Thank you for subscribing!
Have a great day!
