มี MCP Server ในเครื่อง 5 ตัว จะเปิดให้พนักงาน 40 คนใช้ร่วมกันได้ไหม

ทีมพัฒนาที่เพิ่งเริ่มเขียน MCP Server ส่วนใหญ่เริ่มจากรันในเครื่องตัวเองก่อน เพราะตั้งค่าง่ายและทดสอบเร็ว แต่พอถึงจุดที่อยากให้ทีมอื่นในองค์กรใช้ Tool เดียวกันได้ด้วย คำถามที่ตามมาคือจะเปิดให้หลายคนเข้าถึง Server ตัวเดียวกันได้อย่างไรโดยไม่ต้องให้ทุกคนติดตั้งเองในเครื่อง

สมมติทีมมี Server ในเครื่องนักพัฒนา 5 ตัวที่ครอบระบบภายในไว้ต่างกัน และอยากเปิดให้พนักงานฝ่ายอื่นอีก 40 คนใช้ผ่านผู้ช่วย AI ในเครื่องมือของตัวเอง คำตอบทางเทคนิคคือ Remote MCP แต่การย้ายจาก Local ไป Remote มีรายละเอียดที่ถ้าข้ามไปจะเจอปัญหาเรื่องความปลอดภัยและความเสถียรตามมาแน่นอน

บทความนี้อธิบาย Remote MCP คืออะไรในเชิงสถาปัตยกรรม ต่างจาก Local MCP ตรงไหน และสิ่งที่ทีมต้องเตรียมเพิ่มก่อนเปิดให้คนจำนวนมากใช้งานร่วมกัน

Remote MCP คืออะไร ต่างจาก Local MCP Server ตรงไหน

Local MCP Server คือ Server ที่รันอยู่บนเครื่องเดียวกับ Host สื่อสารกันผ่าน stdio ซึ่งเป็นช่องทางสื่อสารภายในเครื่อง ไม่มีใครนอกเครื่องเข้าถึงได้ เหมาะกับงานที่ต้องแตะไฟล์ในเครื่องหรือทดสอบส่วนตัว ส่วน Remote MCP Server คือ Server ตัวเดียวกันในเชิงแนวคิด แต่ถูก Deploy ขึ้นไปรันบนเซิร์ฟเวอร์กลาง แล้วสื่อสารกับ Host ผ่าน HTTP หรือ Server-Sent Events (SSE) แทน

ความต่างเชิงสถาปัตยกรรมที่สำคัญที่สุดคือ Local Server มีผู้เรียกได้แค่ Host เดียวที่รันอยู่บนเครื่องเดียวกัน ในขณะที่ Remote Server ต้องออกแบบให้รองรับหลาย Connection พร้อมกันจากหลาย Host หลายผู้ใช้ ซึ่งหมายความว่าโค้ดฝั่ง Server ต้องคิดเรื่อง Concurrency, Session แยกต่อผู้ใช้ และการยืนยันตัวตนที่ Local Server ไม่จำเป็นต้องมี

สัญญาณที่บอกว่าถึงเวลาต้องย้ายไป Remote MCP

ไม่ใช่ทุกทีมที่ต้องรีบทำ Remote MCP ตั้งแต่แรก ถ้ามีแค่นักพัฒนาคนเดียวใช้ Tool ในเครื่องตัวเอง Local Server ก็เพียงพอและดูแลง่ายกว่ามาก สัญญาณที่บอกว่าถึงเวลาต้องย้ายคือเมื่อมีมากกว่าหนึ่งทีมหรือมากกว่าหนึ่งแผนกต้องการใช้ Tool ชุดเดียวกัน หรือเมื่อ Agent ที่ต้องเรียก Tool ไม่ได้รันอยู่บนเครื่องเดียวกับ Server อีกต่อไป เช่น Agent รันเป็น Background Service

อีกสัญญาณคือเมื่อทีมเริ่มเบื่อกับการที่ทุกคนต้องติดตั้ง Server เดียวกันซ้ำในเครื่องตัวเอง และต้องคอยอัปเดต Configuration พร้อมกันทุกเครื่องเวลามีการแก้ไข การรวมศูนย์เป็น Remote Server ทำให้แก้ Logic ครั้งเดียวแล้วทุกคนได้ผลลัพธ์ใหม่ทันทีโดยไม่ต้องอัปเดตอะไรฝั่งเครื่องผู้ใช้เลย

เทียบ Local MCP กับ Remote MCP แบบเห็นภาพ

ก่อนตัดสินใจย้าย ควรเข้าใจข้อแตกต่างทั้งหมดที่กระทบต่อการดูแลระบบในระยะยาว ไม่ใช่แค่มองเรื่องจำนวนผู้ใช้อย่างเดียว:

ทำไม Remote MCP ต้องมี Authentication เสมอ

จุดที่ทีมย้ายจาก Local ไป Remote พลาดบ่อยที่สุดคือเปิด Server ให้เข้าถึงได้จากเครือข่ายโดยยังไม่มีระบบยืนยันตัวตน เพราะตอนเป็น Local Server ไม่เคยต้องคิดเรื่องนี้มาก่อน เมื่อ Server เข้าถึงได้จากนอกเครื่อง ใครก็ตามที่รู้ที่อยู่ของ Server อาจเรียก Tool ที่เชื่อมกับข้อมูลอ่อนไหวได้โดยไม่ได้รับอนุญาต

แนวทางมาตรฐานที่ MCP รองรับคือใช้ OAuth เป็นกลไกยืนยันตัวตนสำหรับ Remote Server ซึ่งทำให้ระบุได้ว่าใครเป็นคนเรียก และจำกัดสิทธิ์การเรียก Tool ตามบทบาทของผู้ใช้แต่ละคนได้ รายละเอียดของการตั้งค่าส่วนนี้อธิบายลึกกว่าใน MCP OAuth ซึ่งควรอ่านคู่กันก่อนเริ่ม Deploy Remote Server จริง

แยกข้อมูลผู้ใช้แต่ละคนอย่างไรเมื่อ Server ใช้ร่วมกัน

ตัวอย่างสมมติ: บริษัทเปิด Remote MCP Server ให้พนักงานขาย 40 คนใช้ร่วมกันเพื่อดึงข้อมูลลูกค้าจาก CRM แต่พนักงานแต่ละคนควรเห็นเฉพาะลูกค้าที่ตัวเองดูแล ไม่ใช่เห็นข้อมูลลูกค้าของทุกคนในบริษัท ถ้า Server ไม่แยก Session ตามตัวตนผู้เรียก จะเกิดปัญหาข้อมูลรั่วข้ามคนทันที

การแก้ปัญหานี้ต้องผูก Session ของ Client แต่ละตัวเข้ากับ Identity ที่ได้จากขั้นตอน Authentication แล้วให้ Business Logic ฝั่ง Server กรองข้อมูลตาม Identity นั้นทุกครั้งที่มีการเรียก Tool ไม่ใช่กรองแค่ตอนแรกแล้วเชื่อว่า Session จะปลอดภัยตลอดไป เพราะ Session อาจถูกขโมยหรือใช้ผิดวัตถุประสงค์ได้ถ้าไม่มีการตรวจซ้ำ

เตรียมโครงสร้างพื้นฐานอย่างไรให้รองรับผู้ใช้ 40 คนพร้อมกัน

การ Deploy Remote MCP Server ให้รองรับผู้ใช้จำนวนมากพร้อมกันต้องคิดเรื่อง Scaling เหมือนกับ Deploy เว็บเซิร์ฟเวอร์ทั่วไป คือต้องมี Load Balancer ถ้าคาดว่าปริมาณการเรียกจะสูง ต้องตั้ง Timeout ที่เหมาะสมไม่ให้ Request หนึ่งค้างนานจนกระทบผู้ใช้คนอื่น และต้องมี Monitoring เพื่อรู้ว่า Tool ไหนถูกเรียกบ่อยที่สุดและ Tool ไหนตอบช้าผิดปกติ

อีกเรื่องที่ต้องเตรียมคือ Rate Limit ต่อผู้ใช้แต่ละคน เพราะถ้ามี Agent ตัวใดตัวหนึ่งเรียก Tool ถี่ผิดปกติจากบั๊กหรือ Prompt ที่ทำให้วนซ้ำ ไม่ควรให้กระทบการใช้งานของผู้ใช้คนอื่นทั้งระบบ การจำกัดสิทธิ์ระดับ Session จึงต้องคิดคู่กับการจำกัดทรัพยากรระดับระบบไปพร้อมกัน

เลือก Transport แบบไหนระหว่าง SSE กับ Streamable HTTP เมื่อทำ Remote Server

เมื่อตัดสินใจแล้วว่าจะทำ Remote MCP Server ยังมีทางเลือกย่อยอีกชั้นหนึ่งที่ต้องตัดสินใจ คือจะใช้ Transport แบบ HTTP ร่วมกับ Server-Sent Events (SSE) ตามที่สเปก MCP รุ่นแรกกำหนดไว้ หรือใช้ Streamable HTTP ซึ่งเป็นแนวทางที่รวมการรับส่งข้อความเข้ากับ Endpoint HTTP เดียว ไม่ต้องเปิด Connection แบบ Stream ค้างไว้ตลอดเวลาเหมือน SSE ความต่างนี้ไม่ใช่แค่รายละเอียดทางเทคนิคเล็กน้อย แต่ส่งผลตรงต่อว่าระบบที่ Deploy จริงจะรอดหรือพังเมื่อมีคนใช้งานพร้อมกันจำนวนมาก

SSE ต้องการให้ Connection ระหว่าง Client กับ Server เปิดค้างไว้ตลอดช่วงที่ Session ยังทำงานอยู่ ซึ่งโครงสร้างพื้นฐานทั่วไป เช่น Reverse Proxy หรือ Load Balancer มาตรฐาน มักตั้ง Timeout ปิด Connection ที่ไม่มีข้อมูลไหลผ่านนานเกินกำหนดโดยอัตโนมัติ ทำให้ Session ของ MCP หลุดโดยที่ทั้ง Client และ Server ไม่รู้ตัวทันที Streamable HTTP แก้ปัญหานี้ด้วยการให้ Client เปิด Connection ใหม่ต่อการเรียกแต่ละครั้งได้ตามปกติ แล้วค่อย Upgrade เป็น Stream เฉพาะตอนที่ Server ต้องส่งข้อมูลกลับหลายชิ้นเท่านั้น ทำให้เข้ากันได้ดีกว่ากับโครงสร้างพื้นฐาน HTTP ทั่วไปที่ทีมส่วนใหญ่ใช้อยู่แล้วโดยไม่ต้องปรับ Proxy เพิ่มเติม

เครือข่ายหลุดกลางการเรียก Tool ต้องจัดการอย่างไรไม่ให้ข้อมูลซ้ำ

ปัญหาที่ Local MCP Server แทบไม่เจอ แต่ Remote MCP Server เจอเป็นเรื่องปกติคือเครือข่ายหลุดระหว่างที่ Client กำลังรอผลลัพธ์จาก Tool ที่เรียกไป เพราะ Local Server สื่อสารผ่าน stdio ในเครื่องเดียวกัน โอกาสที่ท่อสื่อสารจะขาดกลางทางมีน้อยมาก แต่ Remote Server ต้องพึ่งพาเครือข่ายจริง ซึ่งอาจหลุดได้จากหลายสาเหตุ เช่น Wifi ของผู้ใช้ไม่เสถียร Proxy กลางถูก Restart หรือ Server เองกำลังถูก Deploy เวอร์ชันใหม่พอดีตอนนั้น

จุดที่อันตรายที่สุดไม่ใช่ตอนเครือข่ายหลุดก่อนส่ง Request เพราะกรณีนั้น Client แค่ลองใหม่ได้เลยอย่างปลอดภัย แต่คือกรณีที่ Client ส่ง Request ไปแล้ว Server เริ่มประมวลผล แต่การเชื่อมต่อหลุดก่อนที่ผลลัพธ์จะส่งกลับมาถึง Client ไม่มีทางรู้แน่ชัดว่า Server ทำงานสำเร็จไปแล้วหรือยังไม่ได้เริ่มทำ ถ้า Client ตัดสินใจเรียก Tool เดิมซ้ำแบบไม่ระวัง และ Tool นั้นเป็นตัวที่เขียนข้อมูล เช่น create_ticket หรือ update_order_status อาจเกิดข้อมูลซ้ำสองรายการจากคำสั่งเดียวของผู้ใช้

• ใช้ Idempotency Key ต่อการเรียกแต่ละครั้ง ให้ Client สร้างรหัสเฉพาะแนบไปกับทุก Request ที่เขียนข้อมูล ถ้า Server เห็นรหัสเดิมซ้ำ ให้คืนผลลัพธ์เดิมแทนที่จะประมวลผลใหม่
• แยกพฤติกรรม Retry ระหว่าง Tool อ่านข้อมูลกับ Tool เขียนข้อมูล Tool ที่แค่อ่าน เช่น get_order_status เรียกซ้ำได้โดยไม่มีผลข้างเคียง แต่ Tool ที่เขียนข้อมูลต้องมีกลไกกันซ้ำก่อนอนุญาตให้ Client Retry อัตโนมัติ
• ใช้ Exponential Backoff แทนการลองใหม่ทันที เพราะถ้าเครือข่ายหลุดจาก Server ฝั่งเดียวกันกำลังโหลดหนักอยู่แล้ว การให้ Client ทุกตัวลองใหม่พร้อมกันทันทีจะยิ่งซ้ำเติมปัญหาให้ Server ฟื้นตัวช้าลงไปอีก

ขั้นตอนย้ายจาก Local ไป Remote MCP โดยไม่รื้อ Business Logic

ข่าวดีคือการย้ายจาก Local ไป Remote ไม่จำเป็นต้องเขียน Business Logic ใหม่ทั้งหมด เพราะชั้น Business Logic ที่แยกออกจากชั้น Transport ตั้งแต่แรกสามารถใช้ซ้ำได้ ส่วนที่ต้องเพิ่มคือชั้น Transport ใหม่และชั้น Authentication

1. ตรวจสอบว่า Business Logic ในโค้ดปัจจุบันแยกออกจากชั้น Transport (stdio) ชัดเจนแล้วหรือยัง ถ้ายังผสมกันอยู่ ต้องแยกก่อนเริ่มย้าย
2. เพิ่มชั้น HTTP หรือ SSE Transport ครอบ Business Logic เดิม โดยไม่แก้ Logic การเรียก Tool ที่ทำงานถูกต้องอยู่แล้ว
3. ใส่ระบบ Authentication ตามแนวทาง OAuth ก่อน Deploy ขึ้นเซิร์ฟเวอร์จริง ห้ามเปิดให้เข้าถึงจากเครือข่ายก่อนมีชั้นนี้เด็ดขาด
4. ทดสอบกับผู้ใช้กลุ่มเล็กก่อน เช่น 3-5 คนจากทีมเดียวกัน ก่อนขยายไปเปิดให้ทั้งองค์กร 40 คนใช้พร้อมกัน เพื่อดูปัญหา Concurrency ที่อาจไม่เจอตอนทดสอบคนเดียว

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดตอนเปิด Remote MCP ให้องค์กรใช้

ทีมที่เปิด Remote MCP Server ให้คนจำนวนมากใช้ครั้งแรก มักเจอปัญหาที่ไม่เคยเจอตอนเป็น Local Server เพราะสเกลของผู้ใช้เปลี่ยนไปทั้งหมด

• เปิด Server ให้เข้าถึงได้จากเครือข่ายก่อนใส่ Authentication ทำแบบนี้แล้วพัง เพราะช่วงเวลาที่ยังไม่มีการยืนยันตัวตน ใครก็เรียก Tool ได้ ควรใส่ Authentication ให้เสร็จก่อน Deploy ขึ้นเซิร์ฟเวอร์ที่เข้าถึงได้จากภายนอก
• ไม่แยก Session ตามตัวตนผู้ใช้ ทำแบบนี้แล้วพัง เพราะข้อมูลของผู้ใช้คนหนึ่งอาจไปปนกับอีกคน โดยเฉพาะเมื่อ Server เชื่อมกับระบบที่มีข้อมูลเฉพาะบุคคลอยู่แล้ว
• ไม่ตั้ง Rate Limit ต่อผู้ใช้ ทำแบบนี้แล้วพัง เพราะถ้ามี Agent ตัวใดตัวหนึ่งเรียก Tool วนซ้ำผิดปกติ จะดึงทรัพยากรจนผู้ใช้คนอื่นได้รับผลกระทบไปด้วย
• ทดสอบแค่ผู้ใช้คนเดียวก่อนเปิดใช้เต็มรูปแบบ ทำแบบนี้แล้วพัง เพราะปัญหา Concurrency เช่น Race Condition ในการอัปเดตข้อมูล มักไม่โผล่ให้เห็นจนกว่าจะมีคนเรียกพร้อมกันจริง

สรุป

Remote MCP ไม่ใช่แค่การเปลี่ยนช่องทางสื่อสารจาก stdio เป็น HTTP เพราะการเปิดให้หลายคนเข้าถึง Server เดียวกันพร้อมกันดึงเรื่อง Authentication, Multi-tenant Isolation และการดูแลระบบเข้ามาเป็นความรับผิดชอบใหม่ที่ Local Server ไม่เคยต้องมี

ทีมที่วางแผนย้ายควรแยกชั้น Business Logic ออกจากชั้น Transport ตั้งแต่ตอนเขียน Local Server เพื่อให้การย้ายในอนาคตทำได้โดยไม่ต้องรื้อโค้ดหลัก และควรทดสอบกับผู้ใช้กลุ่มเล็กก่อนเปิดให้ทั้งองค์กรใช้พร้อมกันเสมอ

• Remote MCP คือการรัน MCP Server บนเซิร์ฟเวอร์กลาง สื่อสารผ่าน HTTP หรือ SSE แทน stdio ในเครื่อง
• ต้องมี Authentication และการแยก Session ตามตัวตนผู้ใช้ก่อนเปิดให้เข้าถึงจากเครือข่ายเสมอ
• ควรแยกชั้น Business Logic กับ Transport ตั้งแต่แรก เพื่อให้ย้ายจาก Local ไป Remote ได้โดยไม่รื้อโค้ดหลัก
• ต้องเตรียม Rate Limit และ Monitoring ระดับระบบ เพราะความเสี่ยงเมื่อ Server ล่มกระทบผู้ใช้ทั้งหมดพร้อมกัน

คำถามที่พบบ่อย