เมื่อช่วงต้นเดือนที่ผ่านมา Blognone มีงานเสวนาที่ไม่ได้ประกาศภายนอก โดยเชิญผู้ร่วมงานเป็นกลุ่มตัวแทนของผู้ดูแลเว็บขนาดใหญ่จำนวนหนึ่ง เช่น Sanook.com, Kapook, MThai, ไทยรัฐ, Thaitrend, Tarad.com, และ Pantip.com ทั้งหมดได้ร่วมพูดคุยกันถึงประสบการณ์ปัญหาต่างๆ ที่เคยเจอมาว่าในการทำเว็บที่ใหญ่ขึ้นเรื่อยๆ เคยเจอปัญหากันอย่างไร และมีประสบการณ์การแก้ไขกันอย่างไรมาแล้วบ้าง
คนแรกคือคุณเชิดศักดิ์ โชครวมชัย รองประธานอาวุโสฝ่ายปฏิบัติการเครือข่ายจากเว็บสนุก ได้เล่าถึงกระบวนการการปรับตัวของเว็บในแต่ละระดับเป็น 7 ระดับ นับแต่การทำเว็บแบบเน้นฟีเจอร์อย่างเดียว ไล่ไปจนถึงระดับที่อาจจะไม่มีใครที่เรารู้จักเคยเจอโหลดในระดับเดียวกันมาก่อน ประสบการณ์เหล่านี้จะแสดงให้เห็นว่าเมื่อเราสามารถผ่านระดับที่ความยุ่งยากต่างๆ ไปได้ เราจบพบในช่วงที่ระบบสามารถขยายออกไปได้อย่างมีประสิทธิภาพ แต่ในสุดท้ายแล้วหากเว็บยังคงเติบโตด้วยความเร็วสูง เราจะพบปัญหาที่ต้องสร้างความรู้ด้วยตัวเอง ปัญหาใหม่ๆ เช่น พลังงาน, ผู้ใช้จากหลายประเทศทำให้ต้องใช้งาน CDN, ไปจนถึงกระบวนการจัดการกระบวนการทำงานและการจัดการคน
คุณโดม เจริญยศ เล่าถึงกระบวนการดูแลเว็บ Kapook และ TVPool โดยเล่าถึงประสบการณ์การเลือกเทคโนโลยี เช่น การเลือกของ Rackspace โดยปัจจัยสำคัญของการเลือกเทคโนโลยี คือ "เอาอยู่" เขาเล่าถึงการใช้ PHP ที่ใช้งานได้ดีแม้อาจจะต้องใช้หน่วยความจำสูงสักหน่อย และการเลือกการทำเครื่องเสมือนด้วย OpenVZ แต่ยังหาแนวทางใหม่ๆ เช่น Lua บน Nginx และกำลังหันไปใช้ docker มาแทนเครื่องเสมือนแล้วรันผ่านพอร์ตอย่างเดียว
ทางฝั่ง MThai เข้ามาเล่าถึงการพัฒนาแอพพลิเคชั่นที่โหลดหนักที่สุดนั่น คือ "lotto" (ตรวจหวยออนไลน์) ทาง MThai ใช้ Wordpress และเคยใช้ TotalCache มาก่อน แต่สุดท้ายต้องพัฒนาปลั๊กอินของตัวเองเพื่อให้ความต้องการ สร้างไฟล์ static ขึ้นมา และเมื่อมีการอัพเดตก็ปรับไฟล์ static ใหม่อีกครั้ง เป็นแนวทางที่ MThai เลือกต่างออกไปจากผู้ให้บริการรายอื่นๆ ที่พัฒนาแอพพลิเคชั่นเองทั้งหมด
เว็บไซต์ไทยรัฐออนไลน์ โดยคุณ สิริชัย มีมุทา ผู้จัดการฝ่ายวิจัยและพัฒนาได้มาเล่าถึงปัญหาแอพพลิเคชั่นที่พบมา ปัญหาหลักคือฐานข้อมูล ทางไทยรัฐจึงพยายามให้โค้ดต้องยุ่งกับฐานข้อมูลน้อยที่สุด เพราะปัญหาหลายครั้งก็ไม่ใช่ปัญหาจากโหลดภายนอกแต่เป็นโปรแกรมเองที่ไม่ได้ทดสอบบนโหลดที่หนัก
บริการถัดไปเป็นบริการที่เราอาจจะไม่ได้ใช้ "เว็บ" โดยตรง เพราะเป็นระบบ Thaitrend โดยคุณคเชนท์ หวังธรรมมั่ง ที่เก็บทวีตของคนไทยจำนวนมากในแต่ละวันตั้งแต่ปี 2010 เป็นต้นมา โหลดของ Thaitrend นั้นต่างจากโหลดของเว็บอื่นๆ เพราะเป็นโหลด "เขียน" ช่วงที่โหลดหนักที่สุดคือ 20000 ทวีตต่อนาที รวมสี่ล้านทวีตต่อวันโดยประมาณ ข้่อมูลรวมประมาณ 1 GB ต่อวัน จากผู้ใช้รวมประมาณสองล้านคน ทำให้ต้องปรับกระบวนการประมวลผลเป็นรูปแบบ asynchronous โดยต้องเก็บข้อมูลหลายชั้น เช่น การเก็บข้อมูลเข้าสู่ Redis ก่อนที่จะเขียนลง MySQL โดยตอนนี้กำลังทำระบบวิเคราะห์ทวีตหกเดือนย้อนหลังผ่านระบบ Elasticsearch ที่ต้องการประมวลผล โดย Elasticsearch มีข้อดีสำคัญคือระบบการสเกลเช่น sharding หรือ cluster ล้วนทำโดยอัตโนมัติทั้งสิ้น
คุณคเชนท์ยังเล่าถึงประสบการณ์การดูแลเว็บ Tarad.com ที่เคยเจอ spike ถึง 30 เท่าของโหลดปกติ ระบบ shopping cart และระบบจัดการสมาชิกล่ม กระบวนการแบบนี้ยังคงเกิดขึ้นเรื่อยๆ เมื่อมีรายการโปรโมชั่นใหม่ๆ และการออกโทรทัศน์ทำให้เว็บโหลดหนัก การใช้แคชในการกระบวนการเหล่านี้ไม่สามารถทำได้เพราะเป็นระบบที่คิดเงิน ทำให้วางแผนกันปรับไปใช้ระบบไฟล์ GlusterFS เพื่อเก็บฐานข้อมูล MariaDB กันต่อไป
คุณสมศักดิ์ ศรีประยูรสกุล จากบริษัท INOX ที่ช่วย Pantip.com ดูแลระบบ โดยประสบการณ์ของเขาคือปัญหาการสเกลนั้นมักจะเป็นปัญหาที่ผสมกัน เช่น Pantip เคยเจอปัญหาแบนด์วิดท์เต็มก่อนจึงไปพบปัญหา มาจนถึงปัญหาการกระจายโหลดที่ไม่สมดุลระหว่างกัน ทำให้การกระจายโหลดไม่ทั่วถึง
คุณ FordAntitrust พูดถึงการดูแลเครื่องในบริการ subscription ที่ใหญ่น่าจะที่สุดในประเทศไทย (เปิดเผยชื่อไม่ได้) ความพิเศษของประสบการณ์นี้คือบริการทั้งหมดอยู่บนกลุ่มเมฆทั้งหมด และโหลดหนักมากจนกระทั่งต้องขอเพิ่มเครื่องเป็นกรณีพิเศษ ประสบการณ์การใช้บริการกลุ่มเมฆทำให้ latency ของระบบมีค่อนข้างสูงทำให้เธรดต้องรอการเชื่อมต่อนานกว่าปกติ การใช้บริการบนกลุ่มเมฆยังมีข้อจำกัดเช่น การดูแลระบบของผู้ให้บริการ ไปจนถึงสเปคเครื่องที่ไม่สามารถกำหนดได้ตามความต้องการ และการควบคุมเครือข่ายไม่ได้ ทำให้แต่ละเครื่องอาจจะเชื่อมต่อกันไม่ได้ตามต้องการ เครื่องที่สร้างขึ้นมาใหม่อาจจะมี latency ระหว่างเครื่องอาจจะสูงเกินไป อย่างไรก็ดีบริการบนกลุ่มเมฆยังมีความได้เปรียบสำคัญคือการปรับขนาดระบบได้อย่างยืดหยุ่น โหลดที่คาดเดาไม่ได้นั้นแทบจะเป็นไปไม่ได้เลยที่จะซื้อเครื่องเซิร์ฟเวอร์ตามสเปคที่ต้องการมาเตรียมไว้ล่วงหน้า บริการกลุ่มเมฆเปิดให้ผู้ให้บริการสามารถขยายบริการไปบนเครื่องที่อาจจะมีข้อจำกัดบ้าง แต่ยังขยายต่อออกไปได้
ในงานยังมีการนำเสนอจากคุณ javaboom พูดถึงการพัฒนาประมาณการความต้องการของโครงสร้างพื้นฐานว่าเราจะประมาณการกันอย่างไร และคุณกิตติพงษ์ พูดถึงระบบการยุบรวมชั้นต่างๆ ของบริการเว็บเข้าเป็นแพลตฟอร์มที่บางลง และปรับกระบวนการพัฒนาไปเป็นภาษาเนทีฟ โดยใช้ภาษา vala และภาษา C เพื่อให้ระบบรวมเร่งความเร็วขึ้นไปได้นับสิบเท่าจากระบบปกติที่เราใช้กันทั่วไป
Blognone Quest มีความตั้งใจที่จะเป็นชุดของงานที่หยิบยกประเด็นต่างๆ ในโลกไอที เพื่อหาผู้ที่มีประสบการณ์ร่วมกันเข้ามาแลกเปลี่ยนกัน งาน High Scalability เป็นงานครั้งแรกที่เราจัดขึ้น ในอนาคตเราจะหาหัวข้อและผู้ร่วมแลกเปลี่ยนที่กันในอนาคตต่อไป
วิดีโอทั้งงานสามารถเข้าดูได้ที่ YouTube: Blognone Quest - High Scalability
Comments
พัฒนาปลั๊กอินของตัวเองเพื่อให้ความต้องการ? < เหมือนตกอะไรไปครับ?
ปล.เป็นบทความที่ดีมาก ทุกเว็บล้วนเป็นคู่ค้าและคู่แข่งกัน แต่ก็ร่วมกันแบ่งปันความรู้พัฒนาวงการ ;)
my blog
ย่อหน้าสุดท้าย "ในอนาคตเราจะหาหัวข้อและผู้ร่วมแลกเปลี่ยนที่กันในอนาคตต่อไป" ..ที่กัน.. คงมีอะไรตกหล่นนะครับ
ข้อมูล
May the Force Close be with you. || @nuttyi
เป็นการเสวนาที่เป้นประโยชน์ต่อผู้ทำงานเกี่ยวข้องกับวงการนี้มากครับ
เขาไม่สนใจ php hiphop เลยหรอ
น่าสนใจมากครับ ขอบคุณครับ
เขียนเว็บโดยใช้ C เนี่ยนะ - -
หนีไปใช้ .NET Framework หรือ Java ดูจะคุ้มกว่าอีก แลกกับ Performance ที่ลดลงจาก C นิดหน่อย แต่ได้ความเร็วในการ Dev เพิ่มขึ้นหลายเท่าจาก C
ผมว่า C กับ Java เนี่ยไม่แค่"นิดหน่อย"หละครับ ทั้งแง่ performance และ rapid
เห็น Benchmark ระหว่าง Java 7 กับ GCC รึยังคับ ผมเข้าใจ ว่าคนส่วนใหญ่คิดว่า Java ช้า เพราะแต่ก่อนผมก็อคติเหมือนกัน แต่พอได้มาดูจริงๆจังๆ ถึงได้เข้าใจว่ามันไม่ได้ช้าอย่างที่คิด ที่เห็นมันช้าเพราะ Swing มันห่วย
ถ้าในแง่ perform มันคุ้มค่าต่อการเสียเวลาก็ได้ครับ
ผมมองว่า มันไม่คุ้มหรอก ทางออกที่ดีที่สุดสำหรับผมคือ พัฒนาด้วย .NET Framework หรือ Java ส่วนที่มันจำเป็นต้อง Optimize อย่างการทำ Image Processing ก็โยนไปให้ Native แทนโดยใช้ Mixed Assembly หรือ JNI
เขียนเว็บทั้งเว็บด้วยภาษา C หรือ C++ นี่บ้าไปแล้วแน่ๆ
ไม่คุ้มในแง่มุมของเรา แต่ในแง่ธุรกิจ การลด Server ลงไปได้ 1% ในงานหนึ่งๆ ด้วย C/C++ ที่ไม่ได้แก้ไขบ่อยๆ จากเดิมที่ใช้ภาษาระดับสูงกว่าแต่ต้องการระบบที่มีประสิทธิภาพเยอะขึ้น มันเป็นเงินที่เยอะมากก็ได้
Facebook เขียน "คอมไพล์เลอร์" ขึ้นมาใช้พัฒนาเว็บครับ
Google พัฒนา "ภาษาโปรแกรม" ใหม่ (Golang) สำหรับใช้ประมวลผลภายใน
เบาะๆ ก็อย่างคุณโดมที่ปรับแต่ง "เคอร์เนล" เอง เพื่อรีดประสิทธิภาพเครื่องออกมาให้มากที่สุด
การต่อ JNI ของคุณเองก็คือการเชื่อมต่อกับ C/C++ นั่นล่ะครับ ไม่ว่าคุณจะเขียนเองหรือต่อผ่าน lib ที่คนอื่นเขียน ภาษา native รุ่นใหม่ๆ ทุกวันนี้ก็ไม่ได้ดิบขนาดที่ไม่มีเครื่องมือใช้งานและต้องทำทุกอย่างเองหมดเหมือนแต่ก่อน ภาษารุ่นใหม่ๆ อย่าง C++11, Vala, Go, PHP (HipHop) ขาดฟีเจอร์บางอย่างของภาษาไดนามิกไปบ้างแต่ก็ไม่ได้ห่างกันมาก พวก memory management นี่มีกันหมดแทบทุกภาษาแล้ว
lewcpe.com , @wasonliw
ประเดนของผมมันอยู่ที่ "เขียนเว็บทั้งเว็บด้วย C/C++"
ที่ผมบอกว่า ใช้ .NET Framework หรือ Java เอาจะคุ้มกว่า มันคือหนึ่งใน Solution การ Optimize ส่วนที่ต้องใช้พลังประมวลผลสูง
แล้วใครใช้ C/C++ ทั้งหมดหรือครับ? ผมเขียนสรุปงานเองยังจำไม่ได้ว่ามีใครระบุอย่างนั้น
คุณเห็นภาษา C แล้วตื่นไปเองรึเปล่าครับ
lewcpe.com , @wasonliw
"คุณกิตติพงษ์ พูดถึงระบบการยุบรวมชั้นต่างๆ ของบริการเว็บเข้าเป็นแพลตฟอร์มที่บางลง และปรับกระบวนการพัฒนาไปเป็นภาษาเนทีฟ โดยใช้ภาษา vala และภาษา C"
ยุบรวมชั้นต่างๆของบริการเว็บ ไม่ได้หมายถึง "ทั้งเว็บ" เหรอคับ? หรือผมอ่านประโยคนี้แล้วผมตีความผิดไปเองว่าการยุบรวมชั้นต่างๆของบริการเว็บคือการยุบรวมทั้งเว็บแล้วพัฒนาเว็บนั้นๆเป็น C แทน
ภาษา Vala นี่คนละภาษากับ C นะครับ
lewcpe.com , @wasonliw
"ชั้นต่างๆ" มันไม่ได้แปลว่า "ทุกชั้น" นี่ครับ?
ใช่ครับ คุณตีความผิดไปครับ อธิบายนัยนึงก็เหมือนรื้อประมาณเลเยอร์ล่างๆ หรือแก้แบบ from scratch ยิ่ง native ได้ก็ยิ่งดี ส่วนเลเยอร์บนจะเป็น mod อะไร หรือจะรองรับภาษาอะไร ก็แล้วแต่ adapter หรือ driver ที่เป็นเลเยอร์ที่อยู่เกือบจะบนๆจะรองรับครับ
จริงๆ ในยุคก่อนๆถึงปัจจุบัน ก็ยังมีใช้ C/C++ ในส่วน business process กับ presentation ในการพัฒนาเว็บ (ไม่ได้บ้าด้วยครับ) คนที่ถนัดใช้ C/C++ ก็ไม่ได้ถือว่าน้อย เราก็เลือกใช้เครื่องมือให้ถูกตัว ถูกตามกำลังและทักษะบุคคลากรที่มี ถ้าหาคนใช้ C/C++ ไม่ได้ ก็ต้องหาทางเลือกอื่น ลองเปิดดู youtube ของงานนี้ที่บางท่านแชร์ประสบการณ์ได้ครับ บางท่านก็ตามใจโปรแกรมเมอร์ว่าถนัดอะไร แต่ตัวคอร์ก็ใช้แนวคล้ายๆกัน
My Blog
มายืนยันว่ามี bp ที่ใช้ c++ พัฒนาจริง ๆ รับเมสเสจเป็น XML แล้วยิงกลับไปเป็น XML เป็นการ Reuse เอาโค๊ดเดิมที่ทำงานแบบ Desktop มารับงานแบบ Server โดยการตัด GUI layer ออก
คุณอาจจะมองว่าบ้า แต่ก็อย่าลืมว่าเราจะทิ้ง 10 ปีของการพัฒนาโปรแกรมไปไม่ได้นะครับ
+1
งานทั้งงานนี่พูดถึงประสิทธิ์ภาพในแง่การ รับโหลดครับ ถ้าเอาความเร็วในการ Dev ใช้ CMS กันปกติไม่ต้องทำอะไรมากแก้เท่าที่ต้องการฟีเจอร์ สบายกันอยู่แล้ว
lewcpe.com , @wasonliw
แนวคิดที่ผมเสนอคือ layer ล่าง ๆ ของ Platform เขียนด้วย C ส่วน layer บน ๆ และ App เขียนด้วย Vala โดยทุกส่วนจะสอดประสานกันเป็นเนื้อเดียวกัน ถูกออกแบบมาเพื่อกันและกัน ตัด overhead ออกไปให้มากที่สุด ที่ทำได้เพราะ Vala มันถูก compile ให้เป็น C แล้วคอมไพล์เป็นภาษาเครื่องอีกที
ส่วนความเร็วในการ develop อันนี้ประเมินยาก เพราะขึ้นอยู่กับหลายปัจจัย แต่ผมให้ข้อมูลเบื้องต้นคือ
- Vala เป็นภาษาที่ลอก C# มา ถึงไม่ดีเท่า C# แต่ก็ cover ประมาณ 90% ของ C#
- นักพัฒนาไม่ต้องเขียน C เลยแม้แต่บรรทัดเดียว (ไม่เกี่ยวกับทีมสร้าง Platform นะครับ)
- มีระบบ build อัตโนมัติ นักพัฒนาไม่ต้องมายุ่งกับการ build
- มี MVC Framework
- ORM ที่สร้าง Model ได้เร็วพอ ๆ กับ SQLAlchemy แต่การ query ยุ่งยากหน่อย
- Template ใช้แนวคิดเดียวกับ Jade (http://jade-lang.com/)
ดังนั้นผมคิดว่า Productivity โดยรวมก็น้อง ๆ MVC Framework ของภาษา dynamic ครับ
Lua :)
ไม่มี manager.co.th เหรอครับ ^^
สนใจด้วยเหมือนกัน ค่ายนี้มาทางสาย Microsoft ซะด้วย
ทึ่งเว็บเขาตั้งแต่ตอนไล่นายกแล้วครับ
ขอบคุณครับ ได้ความรู้เยอะเลย ^^
วีดีโอขำๆ เกี่ยวปัญหา Scalability ของเวป healthcare.gov ในอเมริกาครับ http://www.youtube.com/watch?v=hsT_q_MR7Xw
สาระความรู้ล้วนๆเลยครับ ทำให้ผมมองกว้างขึ้นเยอะเลย
งานที่ต้องการ Performance นี่มันต้องรู้ลึกจริงๆสุดยอดครับ
บทความนี้มีประโยชน์สำหรับเว็บมาสเตอร์หลายๆท่านจริงๆ
ผมขอถาม pantip ว่าการที่ไม่เอา topic และ comment รวมไว้ใน doc เดียวกัน เป็นเพราะอะไรครับ
อยากรู้ด้วยครับ
เพราะ doc ของ mongodb มันลิมิตขนาดรึเปล่าครับ(รู้สึกจะ 16M) คงกลัวจะไม่พอมั้งครับ (แถมใน comment ยังมี sub comment อีกนะครับ มี like ด้วย)
และมันคงไม่สะดวกเวลาต้องการ list เฉพาะ topic
และถ้าเอามารวมเป็น doc เดียวกันคงทำ pagination ของ comment ลำบากนะ
อาจตอบไม่ตรงคำถาม แต่คุณอภิศิลป์ผู้ดูแลพันทิบเขียนเอาไว้ อ่านประดับความรู้กันครับ
http://macroart.net/2013/10/mongodb-lessons-learned-on-pantip/
ขอบคุณมากครับ บนความในลิงค์ที่แชร์มานี้ดีมากเลยครับ
ผมว่าบทความสั้นๆ อั้นนี้ ตอบคำถามที่ว่า "ทำงานในบริษัทที่มีบริการขนาดใหญ่แล้วได้อะไร" ได้ดีมากๆ
ผมคิดว่าถ้าผมทำงานที่ปัจจุบันทั้งชีวิตผมก็คงไม่ได้เจออะไรแบบนี้ อยากไปนั่งฟัง นั่งซัก นั่งรื้อโค้ดจริงๆ
ไปด้วยยยยยยย
ไม่ทราบมีทีไหนใช้สาย Microsoft มั่งครับอยากไปสมัครทำงานด้วย