ลองใช้ 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 ได้แก่

1. Cloud Endpoints
2. API Gateway (Beta)
3. 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= ที่ถูกต้องมา Gateway ก็จะ return error ไป

ทดลองยิง 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