Apigee hybrid รองรับ MCP: พลิกโฉม AI Agent ใน Kubernetes

14 ต.ค. 2026

เมื่อเดือนธันวาคมที่ผ่านมา เราได้ประกาศเปิดตัวรุ่น preview ของการรองรับ MCP ใน Apigee เพื่อเปลี่ยน API เดิมที่มีการรักษาความปลอดภัยและกำกับดูแลไว้แล้ว ให้กลายเป็นเครื่องมือที่ AI Agent ค้นหาและเรียกใช้งานได้ทันทีโดยไม่ต้องเขียนโค้ดหรือตั้งค่า MCP server เอง ซึ่งได้รับผลตอบรับล้นหลามพร้อมคำถามสำคัญว่า “จะใช้งานในสภาพแวดล้อม runtime ของตัวเองได้หรือไม่”

สำหรับลูกค้า Apigee หลายราย runtime ไม่ได้รันบนโครงสร้างพื้นฐานของ Google แต่รันใน data center ของตนเอง, colocation หรือ public cloud อื่นๆ เนื่องจากข้อกำหนดด้านระเบียบการดำเนินงานหรือระบบจัดเก็บข้อมูล (systems of record) อยู่ในเครือข่ายเฉพาะ ลูกค้ากลุ่มนี้ต้องการเข้าถึง API ในรูปแบบ agentic โดยไม่ต้องย้าย runtime ออกจากสภาพแวดล้อมเดิม

วันนี้ความต้องการดังกล่าวเป็นจริงแล้วด้วย Apigee hybrid 1.17.0 ที่เปิดตัวเมื่อวันที่ 14 กันยายน 2026 โดยการรองรับ Model Context Protocol พร้อมใช้งานใน Apigee hybrid และ MCP data plane จะรันอยู่ภายใต้ Kubernetes cluster ของคุณเองโดยสมบูรณ์

โมเดลเชิงแนวคิดยังคงเรียบง่ายเหมือนเวอร์ชันบน Apigee คุณเพียงอธิบาย API ด้วย OpenAPI 3.0.x specification และสร้าง MCP Discovery Proxy ขึ้นมา ทุก operation จะกลายเป็นเครื่องมือ MCP ทันที โดยเอเจนต์จะสื่อสารผ่าน JSON-RPC ใช้ tools/list เพื่อค้นหาเครื่องมือ และ tools/call เพื่อเรียกใช้งาน โดย Apigee จะจัดการเรื่องโปรโตคอลและการแปลงรหัส (transcoding) ให้ทั้งหมด ช่วยลดภาระการเขียนโค้ดและบริหารจัดการ MCP server แยกต่างหาก

ความเปลี่ยนแปลงสำคัญในรุ่น hybrid คือสถานที่ประมวลผล โดย MCP data plane จะรันภายใน Kubernetes cluster ของคุณเอง Apigee control plane จะสร้างการกำหนดค่าเครื่องมือจาก OpenAPI Specification จากนั้น cluster จะดึงข้อมูลไปใช้และประมวลผลทราฟฟิก MCP ภายใน cluster เท่านั้น แผนภาพด้านล่างแสดงตำแหน่งการทำงานของ MCP data plane ในแต่ละรูปแบบการติดตั้ง

สถาปัตยกรรมนี้มีจุดเด่นสำคัญสองประการที่ฝ่ายความปลอดภัยจะให้ความสำคัญเป็นพิเศษ:

1. ทราฟฟิก MCP อยู่ภายใน cluster ของคุณ: คำขอ tools/call จากเอเจนต์จะถูกรับ ตรวจสอบสิทธิ์ และส่งไปยัง backend ภายในโครงสร้างพื้นฐานของคุณเองทั้งหมด ข้อมูลจะไม่ข้ามขอบเขตไปยัง Google Cloud ในขณะที่มีการร้องขอ

2. การกำหนดค่าเป็นระบบ Pull ไม่ใช่ Push: sidecar ภายใน cluster จะเป็นฝ่ายเชื่อมต่อออกไปดึงการกำหนดค่าจาก Apigee control plane (บน Google Cloud) เอง โดยที่ทาง Google จะไม่เป็นฝ่ายเริ่มการเชื่อมต่อเข้ามาใน cluster ทำให้ MCP ไม่จำเป็นต้องเปิดเส้นทางขาเข้า (inbound) จากภายนอกเครือข่าย

Agentic endpoint รันในจุดเดียวกับ API เดิม: Apigee hybrid ช่วยให้คุณโฮสต์ runtime บน Kubernetes แพลตฟอร์มใดก็ได้ และ MCP ก็สืบทอดคุณสมบัตินั้นมา โดย MCP sidecar จะใช้ตัวตน apigee-watcher ที่มีอยู่เดิม ไม่ต้องสร้าง Google service account หรือมอบสิทธิ์ IAM role ใหม่ เพียงให้สิทธิ์ระดับ control-plane ครั้งเดียวต่อองค์กรก็พร้อมใช้งาน

รักษา Data residency และอำนาจเหนือข้อมูล: MCP ใน Apigee hybrid รองรับทั้งองค์กรแบบ Subscription และ Evaluation รวมถึงองค์กรที่เปิดใช้งาน Data Residency โดยทราฟฟิกจะคงอยู่ใน cluster ตามโครงสร้าง ตอบโจทย์ทีมที่มีข้อกำหนดเข้มงวดว่า "คำขอห้ามออกนอกเขตอำนาจศาลหรือ VPC นี้" ซึ่งสถาปัตยกรรมนี้รองรับได้โดยตรง

นำนโยบายการกำกับดูแลเดิมมาใช้กับเอเจนต์: เนื่องจาก MCP endpoint คือ Apigee proxy จึงสืบทอดฟีเจอร์ความปลอดภัยอย่าง OAuth 2.0, OpenID Connect และการตรวจสอบ API key ได้ทันที คุณสามารถควบคุมระดับเครื่องมือผ่าน API product เพื่อกำหนดโควตาและสิทธิ์การเข้าถึง หากไคลเอนต์ไม่มีสิทธิ์ในเครื่องมือใด เช่น delete_account เครื่องมือนั้นจะไม่ปรากฏในรายการ tools/list ตั้งแต่แรก

ติดตามทราฟฟิกเอเจนต์ได้จากที่เดียว: MCP Discovery Proxy จะถูกเพิ่มใน Apigee API hub อัตโนมัติในรูปแบบ MCP style ช่วยให้นักพัฒนาค้นหาเครื่องมือด้วยภาษาธรรมชาติได้ ในส่วนของ API insights มีตัวกรอง API style และ MCP tool name เพื่อแยกวิเคราะห์ทราฟฟิกเอเจนต์ออกจาก REST ปกติ ช่วยให้เห็นประสิทธิภาพ, latency และข้อผิดพลาดของแต่ละเครื่องมือได้อย่างชัดเจน

MCP เป็นฟีเจอร์เสริมที่ไม่ได้เปิดใช้งานโดยค่าเริ่มต้น หากต้องการใช้งานใน Apigee hybrid 1.17.0 ขึ้นไป สามารถดำเนินการผ่าน Helm ได้ดังนี้:

ตั้งค่า enableMcpServer: true ในไฟล์ overrides.yaml จากนั้นอัปเกรด chart apigee-operator เป็นลำดับแรก และตามด้วย apigee-org เป็นลำดับที่สอง (ลำดับมีความสำคัญมากเพื่อให้ pod ของ MCP ทำงานถูกต้อง) พร้อมให้สิทธิ์ตัวตน apigee-watcher เข้าถึง control plane เพื่อดึงข้อมูลการกำหนดค่า โดยค่าเริ่มต้นจะมี MCP replica สองชุดและขยายตัวอัตโนมัติได้ถึงสิบชุด

สิ่งที่ควรระวังคือการเปิดหรือปิดใช้งาน MCP จะกระตุ้นการปล่อย runtime pod แบบ staged canary จึงควรทำในช่วงเวลาซ่อมบำรุง สามารถดูรายละเอียดได้ในคู่มือการเปิดใช้งาน

MCP proxy จะแสดงผลเป็น endpoint เดียวที่เส้นทาง /mcp โดย Apigee จะติดแท็กแต่ละคำขอด้วยชื่อเครื่องมือเพื่อให้ API insights จำแนกและวิเคราะห์การใช้งานได้ละเอียด ดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบทราฟฟิกได้ที่นี่ และการใช้งานแดชบอร์ดที่นี่

สำหรับการติดตามประสิทธิภาพแบบละเอียด เรามีแท็บประสิทธิภาพของเครื่องมือ (tool performance) ใน API insights ดังภาพด้านล่าง เนื่องจากการเรียกเครื่องมือ MCP ต้องผ่านทั้ง AI client, Apigee และ backend เราจึงรองรับ distributed trace ผ่าน OpenTelemetry (OTEL) เพื่อให้เห็นภาพรวมของ latency ในจุดต่างๆ ได้ในที่เดียว ตัวอย่างคำขอเรียกใช้งานเครื่องมือผ่าน curl:

curl -X POST "https://xxx.xxx.xxx.net/mcp" \
-H "Content-Type: application/json" \
-H "MCP-Protocol-Version: 2025-11-25" \
-d '{
"jsonrpc": "2.0",
"id": 321,
"method": "tools/call",
"params": {
"name": "createReward",
"arguments": {
"reward": "123"
},
"_meta": {
"traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
}
}
}'

การใช้ distributed trace ใน Google CloudTrace จะแสดงข้อมูลการเรียกทั้งหมดแบบ end-to-end โดย MCP client จะส่ง W3C trace context ผ่านฟิลด์ _meta ของ JSON-RPC ซึ่ง Apigee จะแปลงข้อมูลดังกล่าวเป็น header traceparent และ tracestate ให้ backend อ่านได้ทันทีโดยไม่ต้องแก้โค้ด ช่วยลดสัญญาณรบกวนในระบบและลดค่าใช้จ่ายในการนำเข้าข้อมูล trace

ปัจจุบันชุมชน MCP กำลังผลักดันข้อเสนอ SEP-2028 เพื่อกำหนดมาตรฐานการส่งต่อ W3C trace context นี้ให้เป็นพฤติกรรมหลักของ MCP server ซึ่ง Apigee ได้รองรับมาตรฐาน OpenTelemetry นี้แล้ว

เริ่มต้นใช้งาน MCP ใน Apigee hybrid 1.17.0 ได้ที่ ภาพรวม MCP, การเปิดใช้งานผ่าน Helm หรือลองใช้ MCP quickstart เพื่อเริ่มสร้างเครื่องมือสำหรับเอเจนต์ของคุณได้ตั้งแต่วันนี้