ทำไม Python Async ถึงยังไม่กลายเป็นกระแสหลัก?
(tonybaloney.github.io)ทำไม Python Async ถึงยังไม่กลายเป็นกระแสหลัก?
asyncio ของ Python เป็นเครื่องมือทรงพลังที่สามารถลดเวลารอในสภาพแวดล้อมที่มีงาน I/O (อินพุต/เอาต์พุต) จำนวนมาก และช่วยเพิ่มประสิทธิภาพของโปรแกรมได้อย่างมาก แต่แม้จะมีข้อดีหลายอย่าง ก็ยังไม่ใช่นักพัฒนา Python ทุกคนที่จะนำมาใช้แบบจริงจัง ซึ่งมีเหตุผลเชิงพื้นฐานอยู่หลายข้อ
1. หัวเริ่มตีกัน: ภาระทางความคิด
อุปสรรคที่ใหญ่ที่สุดคือ ความซับซ้อน โค้ดแบบ synchronous นั้นเข้าใจได้ง่าย เพราะเราสามารถตามลำดับการทำงานจากบนลงล่างได้เหมือนอ่านหนังสือ
แต่โค้ดแบบ asynchronous ต่างออกไป ลองนึกภาพเชฟคนหนึ่งทำพาสต้า ระหว่างต้มเส้นอยู่ (ช่วงเวลาที่ต้องรอ) ก็หันไปทำซอส แล้วถ้ายังมีเวลาเหลือก็ไปหั่นผักต่อ ผลลัพธ์คืออาจทำอาหารเสร็จได้เร็วขึ้น แต่ในหัวของเชฟต้องคอยตามสถานะหลายอย่างตลอดเวลา เช่น ‘ตอนนี้เส้นสุกแค่ไหนแล้ว?’ หรือ ‘ซอสจะไหม้หรือเปล่า?’
เพราะลำดับการทำงานของโค้ดกระโดดไปมาระหว่างหลายจุด จึงทำให้ยากที่จะรู้ว่า ณ ตอนนี้งานไหนกำลังรันอยู่ และงานไหนกำลังรออยู่ โดยเฉพาะเวลาเกิดบั๊ก กระบวนการดีบักเพื่อไล่หาสาเหตุก็จะยิ่งยุ่งยากมาก
2. ระบบนิเวศแยกกันเดิน: ความเข้ากันได้ของไลบรารี
อีกปัญหาหนึ่งของ Python คือ ระบบนิเวศของไลบรารี ถูกแบ่งเป็นฝั่ง 'synchronous' และ 'asynchronous' ไลบรารียอดนิยมและใช้งานสะดวกจำนวนมาก (เช่น requests ซึ่งเป็นไลบรารีมาตรฐานสำหรับส่ง HTTP request หรือ ORM จำนวนมาก) ทำงานได้เฉพาะแบบ synchronous เท่านั้น
หากใช้ไลบรารี synchronous ผิดที่ผิดทางภายในโค้ด asynchronous ระหว่างที่โค้ด synchronous นั้นกำลังทำงาน ข้อได้เปรียบสำคัญที่สุดของ async อย่าง 'event loop' จะหยุดนิ่งไปทันที มันเหมือนสร้างถนนไว้หลายเลน แต่กลับใช้งานอยู่แค่เลนเดียว ทำให้แทบไม่มีประโยชน์ที่จะใช้ async เลย เพื่อแก้ปัญหานี้ นักพัฒนาต้องไปเรียนรู้และเปลี่ยนมาใช้ไลบรารีอีกชุดที่รองรับ async (aiohttp, asyncpg เป็นต้น) ซึ่งยิ่งทำให้เส้นโค้งการเรียนรู้ชันขึ้น
3. จัดการได้ทีละตัว: GIL (Global Interpreter Lock)
GIL (Global Interpreter Lock) เป็นหนึ่งในลักษณะเฉพาะที่เป็นปัญหาเรื้อรังของ Python โดยมันเป็นกลไกที่จำกัดว่า ภายในหนึ่งโปรเซส แม้จะมีหลายเธรด ก็สามารถมีได้เพียงหนึ่งเธรดเท่านั้นที่รันพร้อมกัน asyncio ทำงานอยู่บนเธรดเดียว จึงไม่ได้ชนกับ GIL โดยตรง แต่การมีอยู่ของ GIL ก็ยังจำกัดขอบเขตการใช้งานของ async อยู่ดี
asyncio เหมาะมากกับการใช้ประโยชน์จากช่วงเวลารอของ I/O (เช่น รอการตอบกลับจากเครือข่าย หรือรออ่านไฟล์) แต่ถ้ามี งานแบบ CPU-intensive ที่ต้องคำนวณหนักมากอยู่ภายในฟังก์ชัน async event loop ทั้งหมดจะหยุดค้างจนกว่าการคำนวณนั้นจะเสร็จ ระหว่างนั้นงาน I/O อื่น ๆ ก็ทำอะไรไม่ได้ นอกจากรอไปก่อน สุดท้ายแล้ว สำหรับงานที่ต้องการ parallel processing อย่างแท้จริง ก็ยังมีข้อจำกัดที่ต้องพึ่งเทคนิคอื่นอย่าง multiprocessing อยู่ดี
4. ความหวังในอนาคต: Python 3.14 และการถอด GIL
อย่างไรก็ตาม มีข่าวที่น่ามองในแง่ดีมากเกี่ยวกับข้อจำกัดเหล่านี้ นั่นคือความเคลื่อนไหวเรื่อง การถอด GIL แบบเลือกได้ ซึ่งเริ่มเข้ามาแบบทดลองตั้งแต่ Python 3.13 และคาดว่าจะมีความสมบูรณ์มากขึ้นในเวอร์ชัน 3.14
การเปลี่ยนแปลงนี้ถูกผลักดันผ่านข้อเสนอชื่อ PEP 703 โดยมีเป้าหมายให้ผู้พัฒนาสามารถรันโค้ด Python ได้โดยไม่ต้องมี GIL หากสิ่งนี้เกิดขึ้นจริง Python ก็จะสามารถทำ multithreading ที่แท้จริงได้ โดยหลายเธรดใช้หลาย CPU core พร้อมกัน
สิ่งนี้สามารถสร้างแรงเสริมอย่างมหาศาลเมื่อใช้ร่วมกับ asyncio งาน I/O จะถูกจัดการอย่างมีประสิทธิภาพด้วย asyncio ส่วนงาน CPU ที่ต้องคำนวณหนักก็สามารถโยนไปให้เธรดแยกไปประมวลผลแบบขนานได้ง่ายขึ้น โดยไม่ติดข้อจำกัดของ GIL การเปลี่ยนแปลงนี้มีแนวโน้มจะเป็นจุดเปลี่ยนสำคัญของระบบนิเวศ Python และมีความคาดหวังอย่างมากว่าจะช่วยทลายกำแพงหลายอย่างที่เคยขัดขวางการยอมรับ async ในวงกว้าง
9 ความคิดเห็น
รู้สึกว่า GIL โผล่มาแบบค่อนข้างไม่เข้าประเด็นนะ.. ต่อให้เอา GIL ออกไปได้
ถ้าอยากใช้มัลติเธรดทั้งกับงานแบบ I/O bound และ CPU bound
ก็คงจะดีกว่าถ้าเลือกทางเลือกอื่นที่ไม่ใช่ Python..
เหมือนว่า
asyncioจะเป็นอะไรที่คนซึ่งลงลึกกับ Python หลายคนไม่ค่อยชอบกันพอสมควรเหมือนกันนะเหมือนเคยได้ยินความเห็นอยู่บ่อยๆ ว่า
geventน่าจะได้กลายเป็นกระแสหลักมากกว่าผมเห็นด้วยว่าเราไม่อาจคาดหวังได้ว่าทิศทางปัจจุบันของ GIL จะทำให้มันไม่ด้อยกว่าเมื่อเทียบกับ "ทางเลือกอื่น" ต่าง ๆ
แต่ผมคิดว่าการบอกว่าควรเลือกใช้ทางเลือกอื่นแทน Python ไม่ควรนำไปสู่น้ำเสียงว่าไม่มีปัญหาอยู่แล้ว แต่ควรนำไปสู่น้ำเสียงว่ายังมีปัญหาอยู่ไม่ใช่หรือครับ
ใช้
asyncioกันเยอะนะครับ.. ใช้งานได้ดีทีเดียว.. มีข้อจำกัดตรงที่การยกเลิกงานเป็นแบบ edge-triggered (ไม่ใช่ level-triggered) แต่จริง ๆ แล้วงานเขียนโค้ดที่ต้องรับรู้การยกเลิกงานและจัดการแบบ graceful ก็ไม่ได้เกิดขึ้นบ่อยนัก และปัญหาที่ใหญ่กว่านั้นคือ event loop ถือ weak reference ไปยัง task จึงอาจหายไปได้เพราะ gc.. แต่เรื่องนั้นแก้ได้ด้วย structured concurrency.สำหรับงาน i/o สำคัญ ๆ โดยทั่วไปก็หาไลบรารีที่รองรับ asyncio ได้ไม่ยาก..
ส่วน GIL? ก็ไม่ได้เกี่ยวมากนัก.. แนวคิดที่จะใช้ asyncio เพื่อรันงานที่กิน CPU แบบขนานกันนั้นค่อนข้างแปลกอยู่แล้ว.. ถ้า GIL ได้รับการปรับปรุง ก็น่าจะเป็นประโยชน์กับการทำมัลติเธรดสำหรับงานที่กิน CPU มากกว่า.. async คือการหมุนช่วงคอขวดของ i/o ให้มีประสิทธิภาพสูงที่สุด...
สรุปก็คือ.. แม้จะมีปัญหาด้านการออกแบบอยู่บ้าง แต่ในการใช้งานเพื่อให้บรรลุเป้าหมายก็ไม่มีปัญหาอะไรเป็นพิเศษ และใช้งานใน production ได้ดีครับ.
คุณเคยเจอกรณีที่ task ถูก gc เก็บไปไหม?
แน่นอนว่าผมเองก็ใช้
asyncioในโปรดักชันจนช่ำชองเหมือนกัน แต่ผมก็ยังไม่พอใจกับประสบการณ์การใช้งานในตอนนี้มากพอที่จะประเมินได้ว่า "ใช้งานได้ดี" ครับ..asyncioในปัจจุบันถูกออกแบบมาโดยมี GIL เป็นเงื่อนไขตั้งต้น พูดอีกอย่างหนึ่งก็คือเป็นกลยุทธ์หลีกเลี่ยง GIL ดังนั้น GIL จึงไม่ได้โต้ตอบกับasyncioโดยตรงแต่ถ้ามองจากภาพรวมของการเขียนโปรแกรมแบบ concurrency ทั้งหมดที่ทำงานอยู่บนพื้นฐานของ
asyncioผมคิดว่าการพูดว่า GIL ไม่เกี่ยวข้อง ก็เหมือนกับการพูดทำนองว่า 'เพราะเป็น Python ก็เลยทำไม่ได้อยู่แล้ว'ผมขอใช้ joblib ดีกว่า
ปัญหาของ Asyncio ไม่ใช่ความยากของการเขียนโปรแกรมแบบอะซิงโครนัสที่ยากอยู่แล้ว แต่เป็นคุณภาพที่ต่ำต่างหาก การออกแบบที่ทิ้งทั้งความสม่ำเสมอและความเป็นสากลอาจไม่ใช่เรื่องแปลกนักใน Python แต่ของอย่าง ProactorEventLoop นี่ แม้แต่บั๊กที่ทำให้บริการล่มซึ่งมีการรายงานไว้ตั้งแต่ 5 ปีก่อนก็ยังคงอยู่
สำหรับคนที่จำใจต้องใช้ มันยากมากที่จะอ่านบทความแบบนี้แล้วหัวเราะผ่าน ๆ ไปได้
แน่นอนว่าเหตุผลที่ใหญ่กว่าน่าจะเป็นเพราะ ด้วย GIL ประโยชน์ที่ได้ตั้งแต่แรกก็มีน้อยกว่าเมื่อเทียบกับสภาพแวดล้อมอื่นอยู่แล้ว
ผมคิดว่าการพูดว่าถ้าไม่มี GIL ก็จะสร้างซินเนอร์จีได้ เป็นคำพูดที่เกือบจะหลอกลวง ลองนึกภาพนักวิ่งที่ไม่มีขาข้างหนึ่ง คุณใส่ขาเทียมให้เขาเพื่อให้พอวิ่งได้สะดวกขึ้นหน่อย แบบนั้นเรียกว่า "ซินเนอร์จี" หรือ?