Shadow mode

Shadow mode คือการให้ระบบหรือ model ตัวใหม่ขึ้นไปรับงานจริงคู่ขนานไปกับตัวที่ใช้อยู่ โดยผลลัพธ์ที่ตัวใหม่ผลิตออกมาจะไม่ถูกส่งกลับไปถึงผู้ใช้ แต่ถูกเก็บไว้เทียบกับของเดิมทีหลัง เอกสาร Shadow tests ของ Amazon SageMaker AI เรียกวิธีทำงานแบบนี้ว่า shadow testing และอธิบายว่าเป็นการประเมินความเปลี่ยนแปลงใดก็ตามที่จะทำกับ infrastructure ที่ใช้ให้บริการ model ด้วยการเทียบ performance ของมันกับ infrastructure ที่ deploy อยู่ในปัจจุบัน เอกสารหน้าเดียวกันเขียนว่าการทดสอบแบบนี้ช่วยให้จับ configuration error และปัญหาด้าน performance ที่อาจเกิดขึ้นได้ก่อนที่มันจะกระทบผู้ใช้ปลายทาง หัวใจของเรื่องอยู่ในประโยคสั้นๆ ที่เอกสารเขียนไว้ในส่วนของ workflow บนคอนโซลว่า เมื่อเลือก production variant ที่ต้องการทดสอบด้วยแล้ว SageMaker AI จะ deploy variant ตัวใหม่ในโหมด shadow ให้อัตโนมัติ แล้วส่งสำเนาของ inference request ไปยังตัวใหม่แบบเรียลไทม์ภายใน endpoint เดียวกัน โดยมีเพียง response ของ production variant เท่านั้นที่ถูกส่งกลับไปยัง application ที่เรียกเข้ามา ของใหม่จึงได้เห็นงานจริงตามสัดส่วนทราฟฟิกที่ตั้งไว้ทั้งที่ยังไม่มีสิทธิ์ตอบใคร

กลไกที่ทำให้เป็นแบบนั้นคือการทำสำเนาคำขอ เอกสาร Validation of models in production ของ SageMaker เขียนไว้ว่า inference request ส่วนหนึ่งที่วิ่งเข้า production variant จะถูก replicate ไปยัง shadow variant และ response ของ shadow variant จะถูก log ไว้เพื่อการเปรียบเทียบ ไม่ได้ถูกส่งกลับไปยังผู้เรียก ซึ่งทำให้ทดสอบ performance ของ shadow variant ได้โดยไม่ต้องให้ผู้เรียกเจอ response ที่ shadow variant ผลิตออกมา หน้า Shadow tests เสริมว่าเราเลือกได้ว่าจะทิ้ง response ของ shadow variant หรือจะ log เก็บไว้เพื่อเทียบแบบ offline วิธีคิดเดียวกันนี้มีอยู่ในโลก service mesh ภายใต้ชื่ออื่น เอกสาร Traffic mirroring ของ Istio เปิดหน้าด้วยประโยคว่า traffic mirroring หรือที่เรียกอีกชื่อว่า shadowing เป็นแนวคิดทรงพลังที่ช่วยให้ทีมนำความเปลี่ยนแปลงขึ้น production ได้โดยมีความเสี่ยงน้อยที่สุดเท่าที่จะเป็นไปได้ และอธิบายต่อว่า mirroring คือการส่งสำเนาของทราฟฟิกจริงไปยัง service ที่ถูก mirror โดยทราฟฟิกที่ถูก mirror นั้นเกิดขึ้นนอกเส้นทางคำขอที่วิกฤติของ service หลัก เอกสารฉบับเดียวกันระบุว่าคำขอเหล่านี้ถูก mirror แบบ fire and forget ซึ่งหมายความว่า response จะถูกโยนทิ้ง และเมื่อทราฟฟิกถูก mirror คำขอที่ส่งไปยัง service ปลายทางจะมี Host หรือ Authority header ต่อท้ายด้วย -shadow ร่องรอยเล็กๆ ตรงนี้เองที่ทำให้ฝั่งรับแยกออกว่าคำขอนั้นมาจากขาเงา ส่วนปริมาณที่ส่งไปก็ปรับได้ Istio ระบุว่าใช้ field ชื่อ value ใต้ mirrorPercentage เพื่อ mirror ทราฟฟิกเพียงเศษส่วนแทนการ mirror ทุกคำขอได้ และถ้าไม่ระบุ mirrorPercentage ไว้ ทราฟฟิกทั้งหมดจะถูก mirror

สำหรับหัวหน้าทีมที่กำลังจะเอา AI ไปรับงานแทนของเดิม ประโยชน์ของขั้นนี้คือได้หลักฐานจากงานจริงมาวางบนโต๊ะก่อนเปลี่ยน ต่างจากการทำ proof-of-concept ด้วยตัวอย่างที่คัดมาเอง เอกสาร Shadow tests ไล่สถานการณ์ที่ใช้ได้ไว้เป็นข้อๆ โดยกำกับว่าเป็นรายการที่รวมถึงแต่ไม่จำกัดเพียงเท่านี้ ข้อแรกคือกำลังพิจารณาเลื่อน model ตัวใหม่ที่ผ่านการ validate แบบ offline มาแล้วขึ้น production แต่อยากประเมิน operational performance metric เช่น latency และ error rate ก่อนตัดสินใจ อีกสองข้อคือกำลังจะเปลี่ยน container ของระบบให้บริการ เช่น การปะช่องโหว่หรืออัปเกรดเป็นเวอร์ชันใหม่ และการเปลี่ยนเครื่อง ML ที่ใช้รัน แล้วอยากประเมินว่าเครื่องใหม่จะรับมือ inference request จริงได้ดีแค่ไหน ข้อควรระวังข้อแรกคือต้นทุน เพราะช่วงทดสอบเท่ากับมีระบบสองชุดรันพร้อมกัน หน้า Best practices ของ SageMaker แนะนำว่าถ้าไม่ได้ใช้ shadow variant เพื่อประเมิน instance ชนิดอื่นหรือขนาดอื่น ให้ใช้ instance ชนิด ขนาด และจำนวนเดียวกัน เพื่อให้มั่นใจได้ว่า shadow variant รับปริมาณ inference request ไหวหลังถูกเลื่อนขึ้น production งบของช่วงนี้จึงต้องเผื่อเครื่องอีกชุดไว้ด้วย ข้อควรระวังข้อที่สองคือสัดส่วนทราฟฟิกที่ก๊อบปี้ไป เอกสารฉบับเดียวกันเขียนว่าการ sample คำขอ 100 percent ทำให้ยืนยันได้ว่า shadow variant รับทราฟฟิกระดับ production ไหวเมื่อถูกเลื่อนขึ้นใช้จริง และเขียนต่อว่าจะเริ่มจากสัดส่วนต่ำกว่านั้นแล้วค่อยไล่ขึ้นเมื่อมั่นใจใน variant มากขึ้นก็ได้ แต่แนวปฏิบัติที่ดีคือต้องเพิ่มทราฟฟิกให้ถึง 100 percent ก่อนเลื่อนขึ้น production ซึ่งเป็นเงื่อนไขที่ทำให้ตัวเลข throughput ของขาใหม่มาจากปริมาณงานเต็มจำนวนจริงๆ เอกสารยังแนะนำอย่างหนักแน่นให้ตั้ง autoscaling บน shadow variant เพื่อให้มันตอบสนองต่อจำนวนคำขอที่พุ่งขึ้นหรือรูปแบบคำขอที่เปลี่ยนไปได้ และระบุว่าถ้าตั้ง autoscaling ไว้แล้ว จะ validate การเปลี่ยน autoscaling policy ได้ด้วยโดยไม่กระทบผู้ใช้ ข้อควรระวังข้อสุดท้ายคือความเข้ากันได้ เพราะเอกสารเขียนว่าฟีเจอร์บางอย่างของ endpoint อาจทำให้ endpoint นั้นใช้ shadow test ไม่ได้ และถ้า endpoint ใช้ฟีเจอร์ในรายการที่เอกสารไล่ไว้ คำขอตั้ง shadow test จะกลายเป็น validation error โดยรายการนั้นมี serverless inference, asynchronous inference, marketplace container, endpoint หลาย container, multi-model endpoint และ endpoint ที่ใช้เครื่องตระกูล Inf1 สิ่งที่ตัวเลขบน dashboard ตอบให้ไม่ได้คือคำถามว่าคำตอบของ AI ดีกว่าของเดิมไหม ทีมที่ทำ llmops จึงมักวาง human-review ไว้อ่าน log ของขาเงาควบคู่กัน และเมื่อเปิดใช้จริงแล้วงาน observability กับการเฝ้าดู model-drift ก็ยังต้องทำต่อ เพราะหลักฐานที่เก็บได้ในสัปดาห์ทดสอบเป็นภาพของทราฟฟิกในสัปดาห์นั้น

ตัวอย่างจากบทสนทนาจริง

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

หัวหน้าทีมเทคนิค: ให้มันรันแบบ shadow mode ไปก่อนครับ ตั๋วทุกใบที่เข้ามาจะถูกส่งเข้าทั้งสองทาง ทางเดิมยังเป็นคนคัดและเป็นผลที่ระบบใช้จริง ส่วน AI ก็จัดกลุ่มไปด้วยแต่ผลของมันเก็บลง log เฉยๆ ไม่ไปโผล่หน้าจอใครทั้งนั้น ครบสองสัปดาห์เราค่อยเปิดตารางเทียบว่ามันตรงกับที่คนคัดกี่ใบ ผิดแบบไหนบ้าง

หัวหน้าฝ่ายบริการลูกค้า: แล้วถ้ามันตอบช้าจนคิวค้าง ลูกค้าจะเดือดร้อนไหม

หัวหน้าทีมเทคนิค: ไม่ครับ เพราะขาเงาอยู่นอกเส้นทางที่ลูกค้ารออยู่ ระบบไม่รอผลของมัน ต้นทุนที่เพิ่มมาช่วงนี้คือค่ารันสองระบบพร้อมกันประมาณสองสัปดาห์ ซึ่งผมคิดว่าถูกกว่าการเปิดใช้แล้วต้องถอยกลับกลางเดือน

ระวังสับสนกับ

• shadow-ai : ชื่อคล้ายกันจนคนสลับกันบ่อย แต่เป็นคนละเรื่องกันสิ้นเชิง shadow AI คือการที่พนักงานหยิบเครื่องมือ AI มาใช้กับงานเองโดยองค์กรไม่รู้และไม่ได้อนุมัติ ซึ่งเป็นปัญหาด้านความเสี่ยงที่ต้องไปตามเก็บ ส่วน shadow mode เป็นขั้นตอนทดสอบที่ทีมตั้งใจวางไว้เองและมีคนดูแลอยู่ เจอคำว่า shadow ในเอกสารฉบับไหนต้องอ่านบริบทให้ชัดก่อนว่าหมายถึงอันไหน
• a-b-testing : ต่างกันที่ผู้ใช้เห็นอะไร เอกสารของ SageMaker อธิบายฝั่ง A/B ไว้ว่าถ้ามีหลาย production variant อยู่หลัง endpoint เดียวกัน เราแบ่งสัดส่วนคำขอไปให้แต่ละ variant ได้ โดยแต่ละคำขอจะถูก route ไปยัง production variant เพียงตัวเดียว และ variant ที่รับคำขอนั้นเป็นตัวที่ตอบกลับไปหาผู้เรียก แปลว่าผู้ใช้กลุ่มหนึ่งเจอผลของขาใหม่จริง ส่วน shadow mode ผู้ใช้ไม่เห็นผลของขาใหม่เลยแม้แต่คนเดียว
• feature-flag : feature flag คือสวิตช์ที่ใช้เปิดหรือปิดฟีเจอร์กับผู้ใช้จริงในภายหลัง ส่วน shadow mode คือขั้นเก็บหลักฐานก่อนหน้านั้นว่าควรกดสวิตช์หรือยัง ในโครงการเดียวกันมักได้ใช้ทั้งคู่ คือรันเงาไว้ก่อน แล้วค่อยทยอยกดแฟล็กเปิดให้ผู้ใช้ทีละกลุ่มเมื่อตัวเลขนิ่งแล้ว
• regression-testing : regression test รันกับชุดข้อมูลที่เตรียมไว้ล่วงหน้าเพื่อดูว่าของที่เคยทำงานได้ยังทำงานเหมือนเดิมไหม ส่วน shadow mode ใช้คำขอจริงที่กำลังไหลเข้าระบบในตอนนั้น จึงเจอเคสประหลาดที่ไม่มีใครคิดจะเขียนลงชุดทดสอบ ทั้งสองอย่างใช้แทนกันไม่ได้และมักทำต่อกันเป็นลำดับ