Pinterest สร้างระบบนิเวศ MCP ระดับโปรดักชันสำหรับ AI Agent ได้อย่างไร

• Pinterest นำ MCP มาใช้เป็นมาตรฐานสำหรับเชื่อมต่อเครื่องมือของ AI agent และผสานเข้ากับเวิร์กโฟลว์วิศวกรรมจริง เช่น IDE, แชตภายใน และ AI agent ต่าง ๆ ในระดับโปรดักชัน
• เลือกสถาปัตยกรรมที่ผสาน MCP server หลายตัวแยกตามโดเมน (เช่น Presto, Spark, Airflow) เข้ากับ รีจิสทรีศูนย์กลาง แทนการใช้เซิร์ฟเวอร์โมโนลิธิกเพียงตัวเดียว
• ใช้ชั้นการยืนยันตัวตนแบบคู่ด้วย JWT ของผู้ใช้ปลายทาง + SPIFFE mesh identity พร้อมการควบคุมสิทธิ์ตามกลุ่มธุรกิจ เพื่อบังคับใช้หลักสิทธิ์ขั้นต่ำกับข้อมูลอ่อนไหว
• ทำผลงานเชิงตัวเลขได้ที่ 66,000 ครั้งต่อเดือน, ผู้ใช้แอ็กทีฟรายเดือน 844 คน, และประเมินว่า ประหยัดเวลาได้ 7,000 ชั่วโมงต่อเดือน
• ปัจจัยสำคัญที่ทำให้ MCP กลายเป็น โครงสร้างพื้นฐานด้านผลิตภาพของวิศวกร ไม่ใช่แค่การทดลอง คือการออกแบบที่ให้ความสำคัญกับความปลอดภัยเป็นอันดับแรก, ไปป์ไลน์ดีพลอยแบบรวมศูนย์ และการผสานเข้ากับเครื่องมือที่พนักงานใช้อยู่แล้วโดยตรง

---

ที่มาของการนำ MCP มาใช้

• Model Context Protocol (MCP) คือมาตรฐานโอเพนซอร์สที่ให้ LLM ใช้ โปรโตคอล client-server แบบรวมศูนย์ ในการสื่อสารกับเครื่องมือและแหล่งข้อมูล แทนการต้องสร้างอินทิเกรชันแยกสำหรับแต่ละโมเดลหรือแต่ละเครื่องมือ
• Pinterest ใช้ MCP ไม่ใช่แค่สำหรับ Q&A แต่เป็นฐานสำหรับ การทำงานวิศวกรรมแบบอัตโนมัติ โดยตั้งเป้าตั้งแต่ “อ่านล็อกแล้วหาปัญหา” ไปจนถึง “วิเคราะห์บั๊กทิคเก็ตแล้วเสนอ PR แก้ไข”

การออกแบบสถาปัตยกรรมช่วงแรก

โฮสต์บนคลาวด์ ไม่ใช่โลคัล

• แม้จะรองรับ MCP server แบบโลคัล (สื่อสารผ่าน stdio) แต่เลือกใช้ MCP server ที่โฮสต์บนคลาวด์ภายในองค์กร เป็นเส้นทางหลัก (paved path)
  • เป้าหมายคือการรันในสภาพแวดล้อมที่นำตรรกะด้าน routing และความปลอดภัยภายในมาใช้ได้ง่าย
  • อนุญาตให้ใช้เซิร์ฟเวอร์โลคัลเพื่อการทดลองเท่านั้น

เซิร์ฟเวอร์ขนาดเล็กหลายตัว vs. เซิร์ฟเวอร์โมโนลิธิกตัวเดียว

• แทนที่จะใช้เซิร์ฟเวอร์ขนาดใหญ่เพียงตัวเดียว เลือกใช้ MCP server ขนาดเล็กหลายตัวแยกตามโดเมน
  • แต่ละเซิร์ฟเวอร์สามารถใช้ การควบคุมสิทธิ์ที่ต่างกัน ได้
  • ป้องกันไม่ให้คอนเท็กซ์ของโมเดลถูกอัดแน่นด้วยข้อมูลที่ไม่จำเป็น
• ฟีดแบ็กช่วงแรกชี้ว่า การสร้าง MCP server ใหม่มีงานเตรียมล่วงหน้ามากเกินไป เช่น ไปป์ไลน์ดีพลอย การตั้งค่าบริการ และการเตรียมระบบปฏิบัติการ
  • ทางแก้คือสร้าง ไปป์ไลน์ดีพลอยแบบรวมศูนย์ เพื่อให้ทีมต้องนิยามแค่ตรรกะของเครื่องมือ ส่วนแพลตฟอร์มจะจัดการดีพลอยและสเกลให้อัตโนมัติ

รีจิสทรี MCP ภายใน

• เป็น แหล่งข้อมูลอ้างอิงเดียวที่เชื่อถือได้ (source of truth) สำหรับจัดการรายชื่อ MCP server ที่ผ่านการอนุมัติและวิธีเชื่อมต่อ
• เว็บ UI: ให้คนใช้งานสำรวจเซิร์ฟเวอร์ ดูทีมเจ้าของ ช่องทางซัพพอร์ต สถานะด้านความปลอดภัย สถานะการใช้งานจริง และเครื่องมือที่เปิดให้ใช้
• API: ให้ AI client (แชต AI ภายใน, อินทิเกรชันใน IDE, agent) ใช้ค้นหาและตรวจสอบเซิร์ฟเวอร์ รวมถึงตัดสินว่า “ผู้ใช้นี้ใช้เซิร์ฟเวอร์ X ได้หรือไม่”
• เฉพาะเซิร์ฟเวอร์ที่ลงทะเบียนในรีจิสทรีเท่านั้นจึงจะถือเป็น เซิร์ฟเวอร์ที่ได้รับอนุมัติสำหรับโปรดักชัน ทำหน้าที่เป็นแกนกลางด้าน governance

สถานะ MCP server ที่ใช้งานอยู่

เซิร์ฟเวอร์หลัก (ตามการใช้งาน)

• Presto MCP server: เป็นเซิร์ฟเวอร์ที่มีการใช้งานสูงสุดตามทราฟฟิก โดย agent (รวมถึง IDE ที่มี AI ช่วย) สามารถดึงข้อมูลจาก Presto แบบ on-demand เพื่อใช้ข้อมูลในเวิร์กโฟลว์ได้โดยตรงโดยไม่ต้องสลับไปดูแดชบอร์ด
• Spark MCP server: เป็นพื้นฐานของประสบการณ์ดีบัก Spark ด้วย AI รองรับการวินิจฉัยงาน Spark ที่ล้มเหลว การสรุปล็อก และการบันทึกการวิเคราะห์สาเหตุรากแบบมีโครงสร้าง ทำให้เธรดงานปฏิบัติการถูกเปลี่ยนเป็นองค์ความรู้ที่นำกลับมาใช้ซ้ำได้
• Knowledge MCP server: เป็นเอนด์พอยต์ความรู้แบบทั่วไป ที่ AI bot ภายในใช้ตอบคำถามด้านองค์ความรู้ของบริษัท, Q&A, เอกสาร และการดีบัก

การผสานกับบริการภายในของ Pinterest

• ผสานเครื่องมือ MCP เข้ากับ เว็บแชต LLM ภายใน ที่พนักงาน Pinterest จำนวนมากใช้งานทุกวัน
  • ฟรอนต์เอนด์จะจัดการ OAuth flow ให้อัตโนมัติ แล้วคืนรายการเครื่องมือที่ผู้ใช้ปัจจุบันมีสิทธิ์ใช้
  • AI chat agent ผูกเครื่องมือ MCP เข้ากับชุดเครื่องมือของ agent โดยตรง ทำให้ประสบการณ์ใช้งานไม่ต่างจากการเรียกเครื่องมือทั่วไป
• เพิ่มเครื่องมือ MCP ลงใน AI bot บนแพลตฟอร์มแชตภายใน ด้วย
  • จัดการการยืนยันตัวตนและการอนุญาตผ่าน Registry API
  • รองรับการจำกัดเครื่องมือ MCP บางตัวให้ใช้ได้เฉพาะบางช่อง เช่น เครื่องมือ Spark MCP ใช้ได้เฉพาะในช่องซัพพอร์ต Airflow

ความปลอดภัย, governance และนโยบาย

มาตรฐานความปลอดภัยของ MCP

• กำหนด MCP Security Standard แยกต่างหาก โดย MCP server ทุกตัวที่ไม่ใช่เพื่อการทดลองต้องมีการระบุทีมเจ้าของ ลงทะเบียนในรีจิสทรีภายใน และผ่านการอนุมัติทิคเก็ตตรวจสอบด้านความปลอดภัย/กฎหมาย/ความเป็นส่วนตัว/และ (ถ้ามี) GenAI
• ผลการตรวจสอบจะถูกใช้กำหนดนโยบายความปลอดภัย เช่น กลุ่มผู้ใช้ที่สามารถเข้าถึงเซิร์ฟเวอร์ได้

ชั้นคู่ของการยืนยันตัวตน (AuthN) และการอนุญาต (AuthZ)

• โฟลว์แบบอิง JWT ของผู้ใช้ปลายทาง

  1. ผู้ใช้โต้ตอบผ่านพื้นผิวต่าง ๆ เช่น AI chat, ปลั๊กอิน IDE, AI bot
  2. ไคลเอนต์รัน OAuth flow กับสแตกยืนยันตัวตนภายใน แล้วส่ง JWT ไปยัง MCP registry และเซิร์ฟเวอร์ปลายทาง
  3. Envoy ตรวจสอบ JWT และแมปเป็นเฮดเดอร์ X-Forwarded-User, X-Forwarded-Groups พร้อมบังคับใช้นโยบายความปลอดภัยระดับหยาบ
  4. ภายในเซิร์ฟเวอร์ใช้เดคอเรเตอร์ @authorize_tool(policy='…') เพื่อควบคุมสิทธิ์อย่างละเอียด (เช่น get_revenue_metrics เรียกได้เฉพาะกลุ่ม Ads-eng)

• การควบคุมการเข้าถึงตามกลุ่มธุรกิจ

  • แทนที่จะเปิดให้พนักงานและผู้รับจ้างของ Pinterest ที่ยืนยันตัวตนแล้วทุกคนเข้าถึงได้เหมารวม เซิร์ฟเวอร์ที่มีข้อมูลอ่อนไหวจะดึงสมาชิกภาพของกลุ่มธุรกิจจาก JWT แล้วตรวจว่าผู้ใช้อยู่ในกลุ่มที่ได้รับอนุมัติหรือไม่
  • Presto MCP server แม้จะเข้าถึงได้ทางเทคนิคจากหลายพื้นผิว แต่มีเพียง กลุ่มที่ได้รับอนุมัติ เช่น Ads, Finance และบางทีมโครงสร้างพื้นฐาน เท่านั้นที่สามารถสร้างเซสชันและรันเครื่องมือสิทธิ์สูงได้

• โฟลว์แบบอิง SPIFFE สำหรับบริการโดยเฉพาะ

  • ในกรณีความเสี่ยงต่ำและอ่านอย่างเดียว จะใช้เพียง การยืนยันตัวตนแบบ SPIFFE (mesh identity)
  • ใช้ได้เฉพาะเมื่อไม่มีผู้ใช้ปลายทางอยู่ในลูป และขอบเขตความเสียหายถูกจำกัดอย่างเข้มงวดเท่านั้น

ความต่างจากมาตรฐาน OAuth ของ MCP

• สเปกอย่างเป็นทางการของ MCP กำหนดโฟลว์การยืนยันตัวตนแบบ OAuth 2.0 ต่อเซิร์ฟเวอร์ (หน้าความยินยอมและการจัดการโทเคนรายเซิร์ฟเวอร์) แต่ Pinterest เลือกใช้วิธีรีไซเคิลเซสชันเดิมที่มีอยู่แล้ว
  • เมื่อผู้ใช้เปิดพื้นผิวอย่าง AI chat ก็ผ่านการยืนยันตัวตนกับสแตกภายในเรียบร้อยอยู่แล้ว จึงไม่ต้องมีพรอมป์ตล็อกอินเพิ่มหรือหน้าต่างขอความยินยอม
  • Envoy และเดคอเรเตอร์นโยบายจะจัดการการอนุญาตแบบโปร่งใสอยู่เบื้องหลัง

Human-in-the-Loop

• MCP server เปิดทางให้เกิดแอ็กชันอัตโนมัติได้ ทำให้ขอบเขตความเสียหายอาจใหญ่กว่าการทำด้วยมือ
• ตามแนวทางการกำกับ agent จะต้องมี การอนุมัติโดยมนุษย์ ก่อนแอ็กชันที่อ่อนไหวหรือมีต้นทุนสูง โดย agent จะเสนอแอ็กชันและให้มนุษย์อนุมัติหรือปฏิเสธได้ (รวมหลายรายการพร้อมกันก็ได้)
• ใช้ elicitation เพื่อขอการยืนยันก่อนทำแอ็กชันเสี่ยง เช่น การเขียนทับข้อมูลในตาราง

การสังเกตการณ์ระบบและตัวชี้วัดผลลัพธ์

• ใช้ ฟังก์ชันไลบรารี กับ MCP server ทุกตัว เพื่อให้มีการบันทึกอินพุต/เอาต์พุต การนับจำนวนการเรียก การติดตามข้อยกเว้น และ telemetry มาให้โดยอัตโนมัติ
• ตัวชี้วัดระดับระบบนิเวศ ได้แก่ จำนวน MCP server และเครื่องมือที่ลงทะเบียน จำนวนการเรียกใช้เซิร์ฟเวอร์ทั้งหมด และ เวลาที่คาดว่าประหยัดได้ต่อการเรียกหนึ่งครั้ง (เจ้าของเซิร์ฟเวอร์ประเมินจากฟีดแบ็กผู้ใช้แบบเบา ๆ และการเทียบกับเวิร์กโฟลว์แมนนวลเดิม)
• ตัวชี้วัดดาวเหนือเพียงตัวเดียวคือ เวลาที่ประหยัดได้ (time saved) โดยคำนวณคร่าว ๆ จากจำนวนการเรียก × นาทีที่ประหยัดได้ต่อการเรียก
• ต่อเดือนมี 66,000 ครั้งของการเรียกใช้งาน, ผู้ใช้แอ็กทีฟรายเดือน 844 คน, และคาดว่า ประหยัดเวลาได้ 7,000 ชั่วโมงต่อเดือน