Meteor in production

ครั้งแรกเลยกับ MeteorJS

ประมาณเดือนสองเดือนที่ผ่านมา ได้มีโอกาสรับงานนึงซึ่งลูกค้าเองก็เป็นเพื่อนสมัยเรียนเมื่อสิบปีที่แล้ว scope งานคือทำเว็บไซต์ที่เป็นเหมือน service เอาไว้สั่งพรีออเดอร์สินค้า ประมาณว่าเป็นแบบฟอร์มให้คนที่สนใจสินค้าเข้ามากรอกแบบฟอร์ม เสร็จทุกอย่างเรียบร้อยแล้วก็ส่งเมลแจ้งยืนยันรายการสั่งซื้ออะไรทำนองนั้น ซึ่งหลังบ้านก็เป็น admin dashboard ธรรมดาที่เขียนเอาไว้ให้ลูกค้าเปิดร้าน ตั้งค่า กรอกใส่รายละเอียด campaign แล้วก็เพิ่มสินค้าประกอบกับระบุจำนวนที่จะเปิดให้จองในรอบนั้นลงไป ฟังดูธรรมดาไม่ได้มีอะไรยุ่งยากเท่าไหร่

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

ไอ้ผมเองก็ติดตาม MeteorJS เนี่ยมาตั้งแต่เวอร์ชั่น 0.6 แล้วก็เห็นว่างานนี้น่าจะเหมาะมากกับการเอามาลองใช้จริงจังบน production โดยที่เราเองก็ไม่ได้เคยหยิบมาใช้กับงานใหญ่ขนาดนี้เลยมาก่อน.. แต่ในใจตอนนั้นรู้ว่า เห้ย framework ตัวนี้แม่งเจ๋งมาก แล้วก็เพิ่งขึ้น stable version 1.0 พอดีเลยด้วย

ที่ผมเรียกว่างานใหญ่ก็เพราะว่า ร้านเนี้ยโครต hot เลยทีเดียว สถิติที่ผ่านมาจากที่ลูกค้าผมเก็บมาให้ดูคือ สินค้าเปิด preorder 3000 ชิ้น ถูกจองหมดภายในเวลาประมาณ 20 วินาทีแรกเลย แล้วที่ฮาคือ hotmail เองแจ้งว่าเป็น email bomb เพราะมีการใช้งานมากเกินภายในหนึ่งนาที เลยมานั่งลองคิดกันดูว่า คนที่น่าจะเข้ามาเว็บไซต์ใน session นึงที่ร้านโพสต์ลิงค์น่าจะอยู่ราวเกือบ 10k ในนาทีแรก

คน 10k ต่อหนึ่งนาทีเข้ามาหน้าเว็บไซต์พร้อมกันเพื่อกรอกข้อมูลรายละเอียดส่วนตัว กด submit แบบฟอร์มปุ๊บ ระบบต้องทำการส่งเมลแจ้งผลการจองทันทีว่าลูกค้าคนนั้นได้สินค้า หรือต้องรอรอบพิเศษ หรือไม่ได้เลย คือ flow มันดู clear มาก แต่ว่าความกังวลหลักๆเลยคือ MeteorJS เองเนี่ยมัน stable มากพอที่จะรันงานนี้ได้หรือเปล่า แล้วจะมั่นใจได้แค่ไหนว่า socket ที่จะต้อง update แบบ real-time ให้ผู้ใช้เกือบ 10k มันไม่ทำให้ทุกอย่าง down

สุดท้ายแล้วผมกับหุ้นส่วนก็ตัดสินใจที่จะเลือกใช้ MeteorJS จริงจังโดยมีเวลาเขียนร่วม 20 วัน โดยที่ไม่ได้มีประสบการณ์หรือเคยนำมาใช้อะไรก่อนเลย(ส่วนใหญ่ JindaTheme เราใช้ Ruby on Rails เป็นหลัก) โอเคพอเรารู้แล้วว่าใช้ MeteorJS เป็นทั้ง front-end/back-end คือระบบที่เขียนเป็น pure Javascript เลยแล้วใช้ MongoDB เป็นฐานข้อมูล จากนั้นก็ดูเรื่อง Server การ scale, optimize, etc เพราะเวลามันมีค่อนข้างจำกัด ความรู้อะไรที่หาได้ในช่วงนั้นก็เสียเงินซื้อมาอ่านมาลองปรับ อย่างเช่นของเว็บไซต์ discovermeteor หรือ bulletproofmeteor ที่เขียนเกี่ยวกับเรื่อง optimize โดยเฉพาะก็ซื้อมาอ่านมาลองดู

ปัญหาคือตอนนั้นที่เขียนมันยังไม่รองรับ load balance เลยต้องไปเช่า EC2 ของ Amazon โดยที่เลือกตัวที่คิดว่าน่าจะไหวที่สุดก็เป็น c3.8xlarge (32core) ซึ่งก็แพงชิบหายตกชั่วโมงละ 2.2$ (ประมาณ 70 บาท) ช่วงที่ test กันก่อนจะใช้จริงก็นั่งลองใช้ bot ยิงเข้าเครื่องตัวเองอยู่บ้าง ถึงค่อนข้างเข้าหน้าแบบฟอร์มได้ช้า อัพเดทสินค้าได้กระตุกอยู่พอสมควร แต่ก็คิดว่าน่าจะพอไหว เลยปล่อยเลยตามเลยนำไปใช้กับ production รอบแรกจริงๆ

ปรากฏว่าลูกค้าโพสต์ลิงค์ไปได้ประมาณ 1 นาที เว็บก็ขึ้นหน้าขาว เข้าหน้าเว็บที่เขียนเองไม่ได้เสียอย่างนั้น ผมนี่นั่งตัวแข็งหน้าซีดไปเลย ตอนแรกก็คิดกลัวไปแล้วว่า แม่งเอ้ยรอบนี้พังแน่เลย order ที่จองไม่เข้า function ทุกอย่างพังใช้ไม่ได้เป็นแน่แท้ แต่พอ command line เข้าไปดูที่เครื่องก็ปรากฏว่ายอด order ยังถูกจองเข้ามาเรื่อยๆ ก็เลย งง กันอยู่พักนึงว่าถ้ามันล่มแล้วทำไมยอดจองยังเข้ามาอยู่ แต่ในช่วงนั้นก็มีคนโพสต์ไปที่ facebook page ของลูกค้าบ่นเข้ามาเป็นระยะๆ ว่าเว็บล่มบ้างหน้าขาวบ้าง แต่บางคนกลับโพสต์ว่าเข้าได้ปรกติยังจองได้อยู่

สรุปผ่านไปเกือบชั่วโมงยอดจองก็ครบ(แต่เราเองก็ยังเข้าไปหน้าเว็บไซต์ไม่ได้) ก็เลยตัดสินใจ command line เข้าไปปิดระบบก่อนเลยดีกว่า พอมานั่งลองดูพักนึงหลังจากวันนั้นแล้วก็พบว่าไอ้ที่ทำให้มันขาวไปอย่างนั้น ก็น่าจะเป็นเพราะตัวอัพเดทจำนวนสินค้าแบบ real-time น่าจะทำให้ socket มันทำงานค่อนข้างหนัก อีกทั้งช่วงที่ผู้ใช้กด submit เข้ามา ไม่ได้ queue ส่งอีเมลไว้ ซึ่งอาจจะเป็นเพราะมันยังไม่ support หรืออะไรก็ตามแต่เนี่ยน่าจะทำให้เกิด deadlock ตรงนี้(mail service ที่ใช้ก็ล่ม เข้า dashboard ไม่ได้อยู่พักใหญ่) คนที่เข้าหน้าฟอร์มแต่แรกได้ก็จะใช้ได้อยู่อย่างนั้น คนอื่นที่จะเข้ามากรอกก็ต้องรอคนเก่าออก

สรุปแล้วผ่านวันนั้นมา function ถือว่ายังใช้ได้ order เข้าอยู่ตลอด แต่มีปัญหาอย่างที่ว่ามาทั้งหมด เลยตัดสินใจเปลี่ยน technology stack กลับมาใช้ Ruby on Rails แล้วตัดในเรื่องของ real-time update ออกไป ส่วนตัวแล้วผมคิดว่า MeteorJS ยังไงก็ยังน่าสนใจ แล้วก็สนุกมากเวลาที่เขียน แต่ถ้าให้เลือกว่าจะต้องกลับมาใช้อีกมั้ย ก็คงคิดว่าต้องรอไปอีกสักพักใหญ่ๆ ให้อะไรๆ เริ่มนิ่ง เริ่มเหมาะกับเอามา scale หรือทำอะไรที่ใหญ่ขึ้นกว่านี้ได้หน่อย แล้ว MeteorJS เนี่ยน่าจะเหมาะกับเอามาทำ product สำหรับ startup พอสมควรเลยด้วย

ส่วนตัวคิดว่าไม่น่านานเกินรอครับ ยิ่งข่าวล่าสุดที่ทีมเพิ่งได้ funding ไป 20 ล้านเหรียญ ไปไม่นาน เราน่าจะได้เห็นอะไรเพิ่มขึ้นกว่าเมื่อก่อนเยอะแน่นอน