เจาะประเด็น
Infrastructure
MCP เลิกผูก Session แล้ว แต่ AWS บอกตรงๆ ว่าภาระทั้งหมดไม่ได้หายไปไหน
สเปกใหม่ของ Model Context Protocol ตัด session ระดับโปรโตคอลทิ้ง เปิดทางให้ deploy เซิร์ฟเวอร์บน AWS ได้ยืดหยุ่นขึ้น แต่ของที่ต้องแลกมาคือความรับผิดชอบที่ถูกผลักไปชั้นอื่น
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
เรื่องนี้ไม่ใช่แค่ปรับสเปกให้สวยขึ้น แต่คือการย้ายความรับผิดชอบทั้งก้อนจากชั้นโปรโตคอลไปหาคนเขียนแอปแทน
ใครที่เคย deploy เซิร์ฟเวอร์ MCP แบบ remote บน AWS คงรู้ดีว่าปวดหัวแค่ไหนกับเรื่อง session affinity เพราะเดิมที Model Context Protocol ผูก session ไว้ที่ระดับโปรโตคอลเอง แปลว่า request ที่ตามมาในบทสนทนาเดียวกันต้องวิ่งกลับไปหา instance เดิมเสมอ ไม่งั้นบริบทที่สะสมไว้ก็หายเกลี้ยง ทำเอาการ scale แนวนอนกลายเป็นเรื่องยุ่ง เพราะโหลดบาลานเซอร์ต้องตั้ง sticky session และเซิร์ฟเวอร์ทุกตัวต้องมีที่เก็บ session ที่ sync กันได้
AWS ออกมาเล่ารายละเอียดว่าสเปกล่าสุดของ MCP เอาองค์ประกอบพวกนี้ออกหมดแล้ว ทั้ง session ระดับโปรโตคอล ข้อกำหนด sticky session และ session storage สำหรับ remote MCP server ฟังดูเหมือนข่าวดีล้วนๆ และมันก็เป็นแบบนั้นในมุมของ infrastructure แต่ถ้าคุณเป็นคนเขียนแอปที่รันอยู่บนเซิร์ฟเวอร์พวกนี้ เรื่องนี้ไม่ได้ง่ายขึ้นเลย มันแค่ย้ายที่
พอไม่มี session ผูกกับโปรโตคอลแล้ว request แต่ละอันก็กลายเป็นอิสระต่อกัน routing จึงทำได้แบบไม่ต้องสนใจว่ามาก่อนมาหลัง ตัวโหลดบาลานเซอร์ไม่ต้องตั้ง sticky อีกต่อไป และการ scale แนวนอนก็ตรงไปตรงมามากขึ้น เพราะไม่มี state ค้างอยู่ในตัวเซิร์ฟเวอร์ที่ต้องเก็บให้ตรงกันข้ามเครื่อง สำหรับคนที่ดูแลระบบอยู่ นี่คือของขวัญชิ้นใหญ่ที่ลดความซับซ้อนของ deployment ลงได้เยอะ
แต่ AWS ก็ไม่ได้ขายฝันอย่างเดียว ในเมื่อโปรโตคอลไม่แบก state ให้แล้ว งานที่เคยเป็นหน้าที่ของมันก็ต้องมีคนรับไป นั่นหมายความว่า application state, การ retry, observability และ idempotency ทั้งหลายถูกผลักไปอยู่ในความรับผิดชอบของชั้นอื่นแทน จะเป็นตัวแอปเองบ้าง ตัว client บ้าง หรือโครงสร้างพื้นฐานที่คุณสร้างขึ้นมาครอบอีกทีบ้าง แล้วแต่สถาปัตยกรรมที่เลือก
ลองไล่ดูว่าอะไรถูกผลักออกจากชั้นโปรโตคอลบ้าง จะเห็นภาพชัดขึ้นว่าทำไมเรื่องนี้ถึงต้องคิดก่อน deploy ไม่ใช่แค่กดอัปเกรดเวอร์ชันแล้วจบ
Application state
เมื่อโปรโตคอลไม่ถือ session ให้แล้ว ใครจะจำบริบทของบทสนทนาก็ต้องเป็นตัวแอปหรือที่เก็บข้อมูลที่คุณออกแบบเอง
Retries
การลองใหม่เมื่อ request ล้มเหลวไม่ใช่เรื่องของโปรโตคอลอีกต่อไป ต้องมีกลไกของตัวเองมารองรับ
Observability
พอ request แต่ละอันเป็นอิสระ การไล่ตามรอยว่าอะไรเกิดขึ้นตรงไหนก็ต้องพึ่งเครื่องมือฝั่งคุณมากขึ้น
Idempotency
เมื่อไม่มีการผูก session คอยกันไว้ การเรียกซ้ำต้องจัดการให้ผลลัพธ์ไม่เพี้ยน ซึ่งเป็นงานที่คนเขียนแอปต้องออกแบบเอง
มุมมองของผมคือ การเปลี่ยนแปลงนี้ถูกทางแล้วในเชิงสถาปัตยกรรม การที่โปรโตคอลแบก session ไว้เองมันฝืนธรรมชาติของการทำ distributed system มาพักหนึ่งแล้ว การผลัก state ออกไปให้ชั้นที่เหมาะกับมันกว่าคือสิ่งที่ควรทำตั้งแต่แรก แต่อย่าหลงคิดว่ามันคือการลดงาน มันคือการย้ายงานไปที่ที่คุณมองเห็นและควบคุมได้ชัดเจนขึ้นต่างหาก ซึ่งดีกว่าในระยะยาวก็จริง แต่ก็หมายความว่าทีมที่เคยพึ่งความสะดวกของโปรโตคอลต้องกลับมาออกแบบเรื่องพวกนี้เองให้ครบ
สำหรับคนที่ทำแอป AI ที่คุยกับเครื่องมือภายนอกผ่าน MCP อยู่ นี่คือจังหวะที่ควรกลับไปดูสถาปัตยกรรมของตัวเองว่าพร้อมรับภาระที่ถูกย้ายมาให้หรือยัง เพราะต่อให้โปรโตคอลเรียบง่ายขึ้นแค่ไหน ระบบที่รันจริงยังต้องรับผิดชอบเรื่องพวกนี้อยู่ดี ไม่มีอะไรหายไปจากโลกนี้ฟรีๆ
Stateless MCP ทำให้ deploy ง่ายขึ้นจริง แต่ความง่ายนั้นมาจากการย้ายความซับซ้อนไปหาคนเขียนแอป ไม่ใช่ทำให้มันหายไป ใครที่คิดว่าแค่อัปสเปกแล้วจบ อาจเจองานงอกทีหลังแบบไม่ทันตั้งตัว
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...