ที่ผ่านมาเว็บของเราจะปิดเพื่อทำ File System Maintenance ประมาณเดือนละ 1 ครั้ง ทางผมเองไม่เคยได้อธิบายเหตุผลอย่างเป็นเรื่องเป็นราวเสียที เนื่องจากคิดว่าคงต้องเขียนค่อนข้างยาวจึงจะสามารถอธิบายได้ และที่ผ่านมาไม่มีพื้นเหมาะๆสำหรับอธิบายโดยที่ไม่เป็นการรบกวน ตอนนี้มีพื้นที่ “คุยกับพันทิป” ตรงนี้ ซึ่งน่าจะพอเล่าอะไรยาวๆให้ฟังกันได้ จึงถือโอกาสมาเล่าสู่กันฟัง (อาจจะต้องศัพท์เทคนิคมากนิดหนึ่งนะครับ ศัพท์ไหนที่ท่านสมาชิกไม่คุ้น อาจจะต้องใช้ wiki ค้นดูนิดนะครับ เพราะถ้าขยายความทั้งหมดกระทู้จะยาวมาก)

ก่อนปี 2553เว็บพันทิปคาเฟ่ทำงานอยู่บนเซอร์เวอร์เครื่องเดียวแต่ก็ค่อนข้างแรง และเมื่อเว็บมีผู้ใช้บริการมากขึ้นทางทีมงานก็ทยอยอัพเกรดเครื่องให้แรงขึ้นตามจำนวนผู้ใช้มาเรื่อยๆ จนสุดท้ายเราพบว่าการอัพเกรดเครื่องดูจะไม่ค่อยช่วยแก้ปัญหา และเมื่อวิเคราะห์ละเอียดลงไปก็พบว่าสาเหตุของปัญหามาจาก I/O หรือการอ่านเขียนบนฮาร์ดดิสก์มีความถี่สูงมากจนฮาร์ดดิสก์ที่เร็วที่สุดไม่สามารถทำงานได้ทัน แม้จะพยายามกระจายเว็บไปบนฮาร์ดดิสก์หลายๆลูกแล้วก็ตาม

ในเวลานั้นเราหาทางออกโดยเริ่มจากการศึกษาเทคโนโลยี่ที่เรียกว่า Distributed File System ซึ่งเป็นการนำเซิร์ฟเวอร์หลายๆตัวมาเชื่อมต่อกันโดยมีการควบคุมจากโปรแกรมระบบเฉพาะ เพื่อให้กลุ่มของเซอร์เวอร์ดังกล่าวถูกมองเห็นเป็นฮาร์ดดิสก์ลูกใหญ่ๆหนึ่งลูกซึ่งนับเป็นเทคโนโลยีที่น่าสนใจมาก แต่เสียดายที่ไม่มีโอกาสได้นำมาใช้จริง เนื่องจากหลังจากศึกษาและเปรียบเทียบพบว่า SAN Storage มีราคาถูกลงกว่าเดิมมาก จนเมื่อคำนวนเปรียบเทียบแล้วเงินลงทุนที่ต้องใช้ไม่ต่างกันนัก แต่การทำ clustering โดยใช้ SAN Storage เป็นเทคโนโลยีที่ใช้กันแพร่หลายมานานจึงคิดว่าน่าจะอยู่ตัวกว่า

จากจุดนั้นเราจึงได้ตัดสินใจเปลี่ยนระบบที่รองรับการทำงานของเว็บพันทิปให้เป็นแบบ Clustering โดยใช้ SAN Storage เป็นที่เก็บข้อมูล และได้เลือกใช้ File System ที่ชื่อว่า OCFS2 ซึ่งเป็นผลพวกจากช่วงที่ศึกษา Distributed File System โดยพบว่า OCFS2 นั้นให้ประสิทธิภาพที่สูง ใช้ทรัพยากรน้อย และดูแลง่าย

เมื่อจัดเตรียมทุกอย่างเสร็จเรียบร้อย เราก็ได้ย้ายระบบจากที่ทำงานบนเซิร์ฟเวอร์เดียวไปอยู่บนระบบ Cluster ใหม่ที่เตรียมไว้ และเป็นจุดเริ่มของปัญหาที่ต่อเนื่องมาจนทุกวันนี้

ปัญหาแรกที่เราพบในเวลานั้น คือ i/o utilization สูงมาก จนเว็บล่มเกือบทั้งวัน ทั้งๆที่เป็นวันหยุดยาวซึ่งเพื่อนสมาชิกส่วนใหญ่จะไปเที่ยวกัน อยู่เล่นเว็บกันไม่มาก ด้วยความที่เป็นมือใหม่และไม่วิเคราะห์ปัญหาให้ดี ผมด่วนสรุปว่า SAN storage ที่ซื้อมาคงจะตัวเล็กไป ไม่พอที่จะรองรับ iops ที่ต้องการ จึงตัดสินใจสั่งซื้อ SAN storage เพิ่มเพราะร้อนใจอยากจะแก้ปัญหา ให้เว็บสามารถให้บริการได้เร็วๆ แต่สุดท้ายตรวจพบว่าปัญหาในเวลานั้นไม่ใช่ประเมินขนาดของ SAN ต่ำไป (สุดท้าย SAN ที่สั่งซื้อเพิ่มมาก็มีประโยชน์ในภายหลังซึ่งจะเล่าต่อไป) ปัญหาจริงๆคือแค่ไม่ได้ปิดตัวแปรที่ชื่อ atime ของ File System ตัวใหม่ทำให้ทุกครั้งที่มีการอ่านข้อมูลระบบจะบันทึกเวลาในการอ่านข้อมูลกลับลงไปในฮาร์ดดิสก์ล่าสุดลงไปด้วย ทำให้ IO ที่เกิดจาก atime สูงมาก ซึ่งเมื่อปิดตัวแปร atime ไป i/o ก็ลดลงจนเว็บก็สามารถใช้งานได้ตามปรกติ

ฟังดูเหมือนเรื่องน่าจะลงเอยด้วยดี ยกเว้นเรื่องที่ผมไปสั่งซื้อ SAN เพิ่มโดยไม่จำเป็นมาอีก 1 ชุด แต่ผลออกมาเป็นว่าเรื่องที่น่าจะจบมันไม่ยอมจบง่ายๆ อย่างที่หวังไว้ครับ

ระบบทำงานอย่างราบรื่นได้ประมาณ 1 เดือน ก็เริ่มแสดงอาการแปลกๆ ซึ่งในเวลานั้นเราเองก็ยังไม่รู้ว่าเกิดอะไรขึ้น รู้แต่ว่าเว็บช้าเป็นระยะๆ เมื่อเข้าไปดู ก็เหมือนกับว่าเราเจอปัญหา i/o อีกแล้ว แต่คราวนี้ ไม่เกี่ยวกับตัวแปร atime เพราะได้ปิดไว้แล้วเรียบร้อย ก็ได้พยายามทดลองหลายๆอย่าง ทั้งการเพิ่มเซอร์ฟเวอร์เข้าไปในระบบ การปรับตั้งค่าต่างๆของระบบ i/o และระบบ file system ซึ่งไม่ว่าจะทำอย่างไร ปัญหาก็ไม่ส่อแววว่าจะดีขึ้นเลยแม้แต่น้อย แถมมีอาการหนักขึ้นเรื่อยๆ โดยมีปรากฏการที่เพื่อนๆตั้งชื่อให้ว่า “กระทู้ด๋อย” เกิดขึ้นถี่มาก

ในเวลานั้นเราเองเป็นมือใหม่มากๆ และที่อยู่ตรงหน้าเป็นของที่เราไม่รู้จักมากมาย ทั้ง OCFS2 ทั้ง SAN ทั้ง SAN Switch เครื่องไม้เครื่องมือที่จะเข้าไปวิเคราะห์ปัญหาทั้งใน SAN หรือ SAN Switch ก็ไม่มีอยู่ในมือ ในช่วงนั้นระบบถือว่ารวนมากเป็นประวัติการ ทางทีมงานและที่ปรึกษารวมไปถึงซัพพลายเออร์ก็พยายามแก้ปัญหากันเต็มที่ แต่ก็เป็นเรื่องที่ไม่ง่ายเลย เพราะในเวลานั้นชี้ชัดไม่ได้ด้วยซ้ำไปว่าปัญหามาจากที่ไหน ระหว่าง OCFS2 หรือSAN หรือ SAN Switch

โดยส่วนตัว ช่วงเวลานั้นเป็นช่วงเวลา 3-4 เดือนที่วิกฤติที่สุดในชีวิตผม เพราะปัญหาที่อยู่ตรงหน้ามันเกินสติปัญหาแค่หางอึ่งที่ผมมีไปมาก แต่ก็ไม่สามารถจะละจากมันไปได้ ในเวลากลางวันงานปรกติก็ยังต้องทำอยู่ แถมด้วยการเฝ้าหน้าจอของเครื่องเซอร์เวอร์ เวลากลางคืนก็ไม่ได้ทำอะไรเลยนอกจากนั่งเฝ้าหน้าจอของเซอร์เวอร์ต่อ เพื่อคอยปิดเปิดระบบ เพื่อให้เว็บยังให้บริการอยู่ได้จนหลังเที่ยงคืนจึงปล่อยไปได้ ทำแบบนี้ตลอดทุกวันไม่มีวันหยุด

แต่สุดท้ายการเฝ้าหน้าจอเซอร์ฟเวอร์วันละกว่า 15 ชั่วโมงก็ได้ประโยชน์บ้างนิดหน่อย คือในที่สุดผมไปพบโดยบังเอิญว่าในเวลาที่ i/o สูงจนระบบมีปัญหานั้น แค่พยายามจะเขียนไฟล์เล็กๆลงใน SAN ก็ยังใช้เวลานานมาก และเมื่อ consultant ได้ลองเจาะเข้าไปดูในประเด็นนี้ ก็พบว่าการเขียนไฟล์ที่โดยปรกติจะใช้เวลาไม่ถึงหนึ่งในพันของวินาทีจะกลายเป็นหลายวินาทีหรือเกือบนาทีในเวลาที่ระบบมีปัญหา

ผลจากตรงนี้ทำให้สร้างความมั่นใจในระดับหนึ่งว่า ปัญหาน่าจะอยู่ที่ File System ค่อนข้างแน่นอน ไม่ใช่ที่ Storage หรือที่ Switch แต่ปัญหาก็คือ แล้วปัญหามันคืออะไรกันแน่และที่สำคัญกว่านั้นคือ “แล้วเราจะแก้ปัญหาได้อย่างไร”

ในช่วงนั้นเป็นเวลาที่ SAN ซึ่งเดิมผมคิดว่าสั่งเข้ามาโดยไม่จำเป็นเพราะวิเคราะห์ปัญหาผิดทางในช่วงแรกเข้ามาส่งมอบ พร้อมๆกับอุปกรณ์ต่อเชื่อมสำหรับเพิ่ม server เข้าไปใน cluster ซึ่งเราก็เลยได้ใช้โอกาสนี้ทำระบบที่มีเครื่องมากขึ้นโดยใช้ SAN ชุดใหม่นี้เป็นตัวใช้งานและกะว่าจะเก็บ SAN ชุดเก่าเอาไว้วิเคราะห์ปัญหา โดยสมมุติฐานในเวลานั้นคือ ปัญหาน่าจะมาจากเวลาที่มี loadมาก ซึ่งถ้ามีเซอร์ฟเวอร์มากขึ้น แต่ละเครื่องทำงานน้อยลง ปัญหาก็น่าจะหายไป ด้วยความโชคดีที่เราตัดสินใจ ย้ายเว็บโดยใช้วิธีเตรียมระบบใหม่แยกออกมาอีกระบบที่ใหญ่ขึ้น แล้วย้ายข้อมูลจากระบบเก่ามาที่ระบบใหม่แทนที่จะเพิ่มเครื่องเข้าไปใน cluster เดิม ซึ่งโชคดีอย่างไรจะเล่าต่อไป

หลังจากที่อัพระบบใหม่ขึ้นมาเราโล่งใจกันมากเพราะดูเหมือนเมื่ออยู่บนระบบที่มีจำนวนเครื่องมากขึ้นอาการมันหายไป เว็บทำงานได้เป็นปรกติดี ซึ่งเราทุกคนก็คิดกันว่าปัญหาคงจบแล้ว ทุกอย่างก็ดูสมเหตุผล คือเมื่อมีเครื่องมากขึ้นแต่ละตัวแบ่งงานกันไปทำโหลดของแต่ละตัวก็น้อยลง ปัญหาก็ดูจะถูกแก้ไข แต่แล้วเมื่อเวลาผ่านไปประมาณหนึ่งเดือนฝันร้ายมันก็กลับมาอีก เว็บเริ่มล่ม กระทู้เริ่มด๋อย มากขึ้นเรื่อยๆ และมันมาถึงจุดที่ผมคิดว่าคงไม่ใช่เรื่องเครื่องไม่พอแล้วละ สงสัยจะเป็นปัญหาอะไรสักอย่างกับตัว file system OCFS2 แน่เลย โดยในจำนวนโหลดที่เรามี ลักษณะโปรแกรมที่เราเขียนไว้ File System มันดูจะทำงานได้ประมาณ 1 เดือน ก่อนที่จะมีอาการผิดปรกติ โดยความผิดปรกติที่สังเกตุเห็นได้ชัดคือ i/o ทางฝั่ง write ซึ่งในเวลาปรกติใช้่แค่ 600-800 ครั้งต่อวินาทีจะพุ่งขึ้นไปถึง 10,000 ครั้งต่อวินาที ซึ่งในช่วงนั้นจะมีอาการที่เซอร์ฟเวอร์เขียนไฟล์ลง SAN ได้ช้ามาก จากที่เคยเขียนไฟล์เสร็จได้ในเวลาไม่ถึงหนึ่งในพันของวินาทีกลายเป็นค้างรอจนเกือบๆนาทีจึงจะเขียนได้ และในเวลานั้นจะเกิดอาการที่เป็นผลพวงจากที่ระบบไม่สามารถเขียนไฟล์ได้ตามมาอีกสารพัด ทั้ง CPU load สูง , IO wait สูง, เว็บอืด, กระทู้ด๋อย ฯลฯ

ตอนนั้นถึงเวลาที่เราคิดว่าคงจะต้องลาจาก OCFS2 แล้ว และตัดสินใจหันไปหา GFS2 ที่เป็น cluster file system ที่ฮิตที่สุด โดยคิดว่าถ้าคนทั้งโลกใช้กันได้เราก็น่าจะใช้ได้ แต่การณ์กลับกลายเป็นว่าเราหนีเสือปะจรเข้อย่างไรอย่างนั้น กล่าวคือเกือบจะทันทีที่เราย้ายไปใช้งาน GFS2 เราพบว่าเซอร์ฟเวอร์มีอาการโหลดสูงมากอย่างเห็นได้ชัด เพียงแต่ไม่ใช่ช่วงๆอย่าง OCFS 2แต่เกือบจะตลอดเวลา ซึ่งจริงๆเรื่องนี้ก็ตรงกับผลการทดสอบของเราเมื่อหลายเดือนก่อนหน้านั้นช่วงที่เปรียบเทียบระบบ Cluster File System เพื่อเลือกว่าจะใช้ตัวไหน แต่เวลานั้นเราคิดว่าเว็บช้านิดหน่อยก็ดีกว่าปล่อยให้กระทู้ด๋อย และต้องหยุดเว็บเป็นช่วงๆ และก็เตรียมที่จะเพิ่มเซอร์ฟเวอร์เข้าไปในระบบอีกครั้งเพื่อจะให้ระบบดีขึ้นต่อไป

ยังไม่ทันได้ทำอะไรมาก GFS2 ก็เกิดปัญหาขึ้น ปัญหาครั้งนี้หนักระดับระเบิดลงเลยครับ คือหลังจากให้ GFS2 ทำงานไปได้ไม่กี่วันยังไม่ทันได้พักหายใจกัน ก็เกิดอาการ File System Crash เลยครับคราวนี้ อาการหนักขนานที่ GFS2 ขึ้นเป็น Permanent IO Error อ่านข้อมูลได้บ้างแบบแปลกๆ แต่เขียนข้อมูลไม่ได้เลย สำหรับเราไม่มีทางเลือกมากนักนอกจากต้องตัดสินใจ Fallback ข้อมูลเป็นครั้งแรกในช่วงอายุของเว็บที่เปิดบริการมา 14 ปี และแน่นอนครับ เมื่อเจอระเบิดลงหนักขนาดนั้น เราก็เลยต้องเซย์กู๊ดบายกับ GFS2 กลับมาซบ OCFS2 อีกครั้งหนึ่ง

แต่อย่างน้อยในครั้งนี้ เราพอจะจับไต๋ได้แล้วว่า OCFS2 จะเป็น Cluster File System ที่ใช้งานได้ดี ให้ performance ที่ดี แต่ด้วย ปริมาณการใช้งาน หรือปริมาณเครื่อง หรือวิธีการเขียนโปรแกรม หรืออะไรสักอย่าง ฯลฯ ที่เป็นเราอยู่ในเวลานี้ ภายในช่วงเวลาประมาณ 30 วันอาการก็จะเริ่มเพี้ยนๆไป จากจุดนั้นมาเราได้พยายามสารพัดอย่าง ไม่ว่าจะคุยกับทีมที่สร้าง OCFS2 ขึ้นมาเพื่อให้ช่วยหา bug , ทดลองปรับเปลี่ยนตัวแปรต่างๆ, ยักย้ายถ่ายเทข้อมูลไปไว้ที่นู่นที่นี่ ฯลฯ โดยไม่ลืมว่าทุกๆ 30 วัน จะต้องปิดระบบเพื่อทำการก๊อปปี้ข้อมูลใหม่เพื่อให้ File System สามารถทำงานได้โดยไม่มีปัญหา (เดากันว่ามีผลคล้ายๆกับการทำ defragment บนเครื่อง PC) ซึ่งเป็นที่มาที่ท่านสมาชิกเห็นว่าเว็บจะมีการปิดเพื่อทำ File System Maintenance ประมาณเดือนละหนึ่งครั้งในทุกวันนี้

คำถามตอนนี้คือแล้วเราจะแก้ปัญหาตรงนี้อย่างไร การปิดระบบเพื่อก๊อปปี้ข้อมูลทุกๆ 30 วันไม่ใช่สิ่งที่ระบบคอมพิวเตอร์ทั่วๆไปเขาทำกันแน่นอน หลังจากที่เราได้คุยกับทีมที่สร้าง OCFS2 อยู่หลายเดือน ลองปรับหลายๆอย่างจนไม่รู้จะปรับอะไร เราเริ่มคิดว่าคงไม่ได้เห็นการแก้ปัญหาในเร็ววันแน่ และด้วยความที่ OCFS2 เป็น Open source ที่ใช้ฟรีการจะไปเร่งรัดหรือขอความช่วยเหลือก็คงอยู่ในวงจำกัด ดังนั้นสถานะการณ์ ณ เวลานี้คือเราตัดสินใจ ลงทุนกับ GPFS ซึ่งเป็น Cluster File System ของบริษัท IBM ที่อยู่ในตลาดมานานและน่าจะเป็น File System ที่สเถียรมากตัวหนึ่ง การลงทุนครั้งนี้เป็นเลขหลายหลัก หากถามว่าจะแก้ปัญหาได้ไหม ? จะมีปัญหาเหมือนเดิมไหม ? จะเกิดปัญให้ใหม่ขึ้นอีกหรือเปล่า ? ฯลฯ ก็ต้องตอบกันตามตรงครับว่า “ก็ไม่แน่” แต่ที่เราเชื่อคือด้วยความที่ไม่ใช่ Open Source ที่ดาวน์โหลดมาใช้ฟรี หากมีปัญหา การสนับสนุนก็น่าจะเป็นไปโดยรวดเร็วกว่าซึ่งน่าจะพาเราไปที่ต้นตอของปัญหาและสามารถแก้ปัญหาที่ต้นเหตุได้เร็วขึ้น และช่วงนี้คือช่วงที่รอเครื่องและ Cluster File System ตัวใหม่ส่งมอบและเตรียมการนำเข้าไปใส่ในระบบ ซึ่งระหว่างนี้ก็จะมีการปิดเว็บเพื่อก๊อปปี้ข้อมูลใหม่ประมาณเดือนละครั้งไปพลางๆ

จบการเล่าเรื่องที่ยาวที่สุดที่เคยเขียนมา และขอคารวะทุกท่านที่อ่านจบครับ ส่วนท่านที่อ่านไม่จบก็ไม่ต้องเสียใจครับ เพราะตัวผมถ้าต้องอ่านข้อเขียนนี้เอง ก็ยอมรับอย่างไม่อายเลยว่าคงจะอ่านไม่จบเหมือนกันครับ …. 🙂

( ลิ้งค์ของ คุยกับพันทิป#1 http://www.pantip.com/cafe/isolate/topic/M10890139/M10890139.html )

http://2g.pantip.com/cafe/isolate/topic/M11010997/M11010997.html
http://2g.pantip.com/cafe/guideline.html

การพัฒนาเว็บบอร์ดที่มีคนเข้าวันละล้านคน ยากกว่าการพัฒนาเว็บบอร์ดที่มีคนเข้าวันละหมื่นคนอย่างไร?
Pantip.com ก่อตั้งขึ้นตั้งแต่ปี พ.ศ. 2539 พี่วันฉัตรซึ่งเป็นผู้ก่อตั้งเว็บ ดาวน์โหลดโค้ด Guestbook ของ Matt’s Script Archive
http://www.scriptarchive.com/guestbook.html
มาปรับแต่งให้เป็นเว็บบอร์ด สถาปัตยกรรมของโค้ดตัวนี้เป็น Text File 100% โค้ดตัวนี้ทำงานได้ดีในวันแรกที่เปิดเว็บ จนหนึ่งปีผ่านไป มีคนเข้าเว็บวันละหลักหลายพันคน และมีการ Flood กระทู้เกิดขึ้น โค้ดตัวนี้ก็เริ่มแสดงปัญหาออกมาให้เห็น

คลิก Like สักนิด เป็นกำลังใจให้ผู้เขียนบทความครับ

โครงสร้างของเว็บบอร์ด Pantip ประกอบด้วยสองหน้าหลักคือ 1. หน้า Index เป็นหน้าที่แสดงหัวข้อกระทู้เรียงจากใหม่ไปเก่า ซึ่งก็คือห้องต่างๆ ในปัจจุบัน และ 2. หน้า Topic หรือหน้ากระทู้ ส่วนบนเป็นข้อความเจ้าของกระทู้ ถัดไปคือความคิดเห็นเรียงจากความคิดเห็นที่ 1 ขึ้นก่อน

หน้า Index เป็นไฟล์ที่มีข้อมูลหลายร้อยบรรทัด บรรทัดบนๆ เป็น HTML สำหรับแสดงเนื้อหา Above the Fold ของแต่ละห้อง บรรทัดถัดจากนั้นคือ HTML ของหัวข้อกระทู้ โดยที่ 1 บรรทัดเท่ากับ 1 กระทู้

เวลาที่มีคนตั้งกระทู้ใหม่เข้ามา ระบบจะเปิดไฟล์ Index ที่มีขนาดใหญ่ จากนั้นจะแทรกหัวข้อกระทู้ใหม่เข้าไป แล้วถึงจะปิดไฟล์ และถ้ามีคนเข้าไปตอบในกระทู้เก่า ระบบก็จะเปิดไฟล์ Index เช่นกัน ค้นหาบรรทัดที่มีกระทู้นั้นอยู่เพื่ออัพเดทตัวเลขจำนวนความคิดเห็นของกระทู้นั้น

ทีนี้หายนะมันเริ่มเกิดขึ้นเมื่อมีคนตั้งกระทู้ใหม่เยอะๆ ตอบกระทู้เยอะๆ และมีตัวป่วนเข้ามา Flood กระทู้เยอะๆ การแย่งกันอัพเดทไฟล์ Index ขนาดใหญ่เพียงไฟล์เดียว ทำให้เกิดอาการ “ด๋อย” ในที่สุด บ่อยครั้งที่จะพบว่าส่วน Above the Fold ของห้องหายไปหรือเละเทะ และบ่อยครั้งที่กระทู้มีการกระโดดหายไปเป็นก้อนๆ

ตอนที่ผมเริ่มเข้าไปทำ Pantip ในปี 2540 ก็หาวิธีแก้ปัญหานี้แบบชั่วคราวโดยใช้เทคนิค SSI เพื่อแยกส่วน Above the Fold กับส่วนหัวข้อกระทู้ออกเป็นสองไฟล์ หน้า Index ของแต่ละห้องจะมีแค่ HTML ของส่วน Above the Fold จากนั้นจะ Include ส่วนหัวข้อกระทู้ที่อยู่อีกไฟล์เข้ามา วิธีนี้ช่วยให้หน้า Index ด๋อยน้อยลง ถ้าด๋อยก็จะเกิดกับส่วนหัวข้อกระทู้เท่านั้น ซึ่งสามารถเขียนสคริปต์ซ่อมได้ง่ายกว่า

ในปี 2542 มีการยกเครื่องใหม่ให้เป็นเว็บ Pantip เวอร์ชัน 2 ในตอนนั้นเว็บ Pantip ย้ายกลับมาอยู่ในไทยแล้ว (โดน Hosting ต่างประเทศเชิญออกเพราะกินแบนด์วิธเขาเยอะมาก) ช่วงแรกที่ย้ายกลับมาไทยก็อาศัย Hosting ของ Internet Thailand แต่ต่อมาคนเข้าเว็บมากขึ้นเรื่อยๆ ก็เลยซื้อเซิร์ฟเวอร์ใช้เอง 1 ตัว (เป็นเครื่องประกอบที่ไม่มีแบรนด์) พอจะต้องยกเครื่องเว็บใหม่ ก็มานั่งคิดว่าจะใช้สถาปัตยกรรมแบบไหนดี

ตอนนั้นคนเข้าเว็บ Pantip วันละหลักหมื่นคน แต่เซิร์ฟเวอร์แบรนด์ดังในยุคนั้นราคาไม่ถูกเลย และงบโฆษณาออนไลน์ในไทยก็ยังไม่มากนัก ทำให้รายได้ของ Pantip มีไม่มาก การลงทุนซื้อเซิร์ฟเวอร์จึงเป็นเรื่องใหญ่ ส่วนทางฝั่งซอฟต์แวร์ PHP กับ MySQL เริ่มเป็นที่นิยมมากขึ้น เว็บต่างประเทศใช้กันเยอะ ถึงแม้ว่าตอนนั้นจะยังหาโปรแกรมเมอร์ไทยที่ใช้สองอย่างนี้เป็นได้ยากอยู่

Linux, Apache, MySQL, PHP

ผมตัดสินใจเปลี่ยนจากภาษา Perl ที่ดูยุ่งยากเหลือเกิน มาเป็นภาษา PHP ที่เข้าใจง่ายกว่า และเริ่มใช้ MySQL ซึ่งในตอนนั้นเป็นเวอร์ชัน 3 มาเป็นฐานข้อมูลหลักของเว็บ โดยที่ทั้งเว็บและฐานข้อมูลอยู่บนเซิร์ฟเวอร์เดียวกัน (ยังไม่มีเงินแยกเครื่อง)

หน้า Index เปลี่ยนจาก Text File มาเป็น MySQL ส่วนหน้า Topic ผมยังไม่มั่นใจว่า MySQL จะรับไหวหรือเปล่า เลยเก็บเป็น Text File แบบเดิม หนึ่งเดือนแรกผ่านไป ระบบของเว็บราบรื่นดี แต่พอเข้าเดือนที่สาม ปัญหาเริ่มเกิด เพราะปริมาณกระทู้ในระบบเพิ่มมากขึ้น โดยที่หน้า Index มีการ Join Table อยู่ ทำให้เว็บช้าลงเรื่อยๆ และขึ้นข้อความ Too many connections อยู่บ่อยๆ ผมพยายาม Optimize ในฝั่งของ MySQL ทั้งส่วนของ Query และส่วน Config ให้มากที่สุด แต่สุดท้ายก็ไปไม่รอด

การแก้ปัญหาในตอนนั้นก็เลยสร้าง Text File ของหน้า Index ขึ้นมาเพื่อใช้เป็น Cache โดยตั้ง Cron ให้ Query ข้อมูลจาก MySQL มาพ่นลง Text File ทุก 5 นาที เพื่อหลีกเลี่ยงไม่ให้ผู้ใช้เข้าถึง MySQL ตรงๆ แบบเรียลไทม์ ซึ่งก็ช่วยให้สถานการณ์ดีขึ้น แต่เวลาต่อมาคอขวดย้ายมาอยู่ที่ Cron Script เพราะต้อง Join ข้อมูลหลายแสนเรคคอร์ด สุดท้ายเลยตัดสินใจทำในสิ่งที่เสียดายมากๆ คือการลบกระทู้เก่าๆ ออกจากระบบ ทั้งนี้เพื่อให้จำนวนเรคคอร์ดใน MySQL ลดลง และยังช่วยลดพื้นที่ฮาร์ดดิสก์ด้วย (ในยุคนั้นฮาร์ดดิสก์ 1 GB ราคาหลายหมื่นบาท) ความจำเป็นที่จะต้องลบกระทู้เก่าออก กับความเสียดายกระทู้ดีๆ นำมาซึ่งฟีเจอร์ “เก็บเข้าคลังกระทู้เก่า” ที่ให้สมาชิกช่วยกันเลือกได้ว่าอยากเก็บกระทู้ไหนไว้ เมื่อถึงเวลาที่จะต้องลบกระทู้เก่าออก ระบบจะย้ายกระทู้ที่สมาชิกเลือกไว้ไปเก็บอีกที่

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

ตอนที่ Pantip มีผู้ใช้หลักแสนคนต่อวัน ปัญหากระทู้ด๋อยก็เริ่มเกิดขึ้น เป็นปัญหารูปแบบเดียวกับที่เคยเกิดกับหน้า Index ในยุคแรก แต่เปลี่ยนมาเกิดกับหน้า Topic แทน กระทู้รายงานสดรายการ Reality ที่มีหลายร้อยความคิดเห็น มีคนโหลดอ่านเยอะๆ จะเจอปัญหานี้อยู่ตลอด ทำให้กระทู้ Pantip มีจำนวนความคิดเห็นได้อย่างมากก็หลักร้อย แต่พอเริ่มแตะหลักพันก็จะเริ่มด๋อย

จนในที่สุดก็เกิดโครงการ Pantip 3G ซึ่งเป็นการยกเครื่อง Pantip เป็นเวอร์ชัน 3 ขึ้นมา ในยุคนี้ Pantip มี Server Rack 2 ตู้ สามารถวางเซิร์ฟเวอร์ได้หลายสิบตัว มีรายได้มากพอที่จะตัดสินใจเพิ่มเซิร์ฟเวอร์ได้ง่ายขึ้นกว่าสมัยก่อน MySQL เริ่มไม่มีอนาคตเมื่อถูก Sun Microsystems ซื้อไป และ Oracle มาซื้อ Sun อีกที ขณะที่ NoSQL เริ่มถูกพูดถึงมากขึ้น ซึ่งในที่สุดเราตัดสินใจใช้ MongoDB ด้วยเหตุผลว่าเรียนรู้ได้ไม่ยากนักเมื่อเทียบกับ NoSQL ตัวอื่นๆ และมีเว็บใหญ่ๆ อย่าง Craigslist, SourceForge, Foursquare ที่ใช้งานอยู่ ทำให้พออนุมานได้ว่าน่าจะเป็นระบบฐานข้อมูลที่มีอนาคตพอสมควร

MongoDB

โจทย์ของการพัฒนา Pantip 3G ท้าทายกว่าสมัยก่อนมาก เราอยากให้กระทู้ไม่ด๋อย และอยากให้ระบบสามารถเก็บกระทู้ไปได้ตลอดกาลโดยไม่ต้องลบกระทู้เก่าออก ในขณะที่เรามีคนเข้าเว็บวันละเป็นล้านคน เปิดเว็บใหม่มา 5 เดือน มีกระทู้ใหม่ 500,000 กระทู้ จำนวนความคิดเห็นอีกเป็นล้าน จำนวนรูปภาพที่สมาชิกอัปโหลดอีกหลายล้าน และทั้งหมดนี้เพิ่มจำนวนขึ้นเรื่อยๆ ทุกวินาที

การพัฒนาเว็บบอร์ดที่มีคนเข้าวันละล้านคนจึงไม่ได้มีแค่การพัฒนา Function ให้ใช้งานได้ถูกต้อง ตั้งกระทู้ได้ แสดงความคิดเห็นได้ เหมือนเว็บบอร์ดที่มีคนเข้าวันละหมื่นคน แต่ยังต้องดูเรื่อง Performance ว่าจะรองรับจำนวนผู้ใช้และปริมาณข้อมูลมหาศาลได้อย่างไร ต้องดูเรื่อง Scalability ว่าจะรองรับการขยายตัวในอนาคตได้อย่างไร และต้องดูเรื่อง Moderation หรือการพัฒนาฟีเจอร์สำหรับทีมงานดูแลเว็บให้สามารถดูแลกระทู้จำนวนมหาศาลได้อย่างราบรื่น

ดังนั้น ที่มีคนตั้งกระทู้ถามใน Pantip ว่า เขียน Website แบบ pantip กี่บาทครับ ก็ตอบได้ว่าถ้าจะทำเว็บบอร์ดที่มีแค่ Function ใช้งานได้ดี รองรับผู้ใช้ได้ประมาณหลักหมื่นคนต่อวัน แนะนำให้ใช้ SMF แล้วจ้างดีไซน์เนอร์กับโปรแกรมเมอร์มาช่วยปรับแต่งธีม ค่าใช้จ่ายหลักหมื่นบาทเอาอยู่ครับ แต่ถ้าจะเอาแบบ Pantip เป๊ะๆ เลย ทั้งในแง่ Function, Performance, Scalability, Moderation รองรับผู้ใช้ได้หลักล้านคนต่อวัน ก็ต้องใช้เงินหลักล้านบาทครับ

เว็บเหมือน Pantip ทำไม่ยากหรอกแต่ที่ยาก …
วันนี้เจอกระทู้น่าสนใจอย่างหนึ่งที่คนในวงการ IT ได้แชร์ต่อๆกันเยอะนั่นก็คือ เขียน Website แบบ pantip กี่บาทครับ ซึ่งอยากมาเขียนเล่นๆให้ฟังเหมือนกันและหลายๆจุดที่น่าสนใจในเนื้อหาของกระทู้นี้และคนที่นำเสนอความคิดเห็นภายนอกเหมือนกันครับ

ประเด็นที่ทำเว็บแบบ Pantip มันตีได้สองความหมายใหญ๋ๆคือ

ทำเว็บที่มี webboard การถาม – ตอบเหมือนกับ pantip ในปัจจุบัน
การทำให้ทั้งตัวเว็บน่าสนใจและมีจำนวน user เยอะๆเหมือน pantip ในปัจจุบันและรองรับการเติบโตในอนาคต
หากเป็นแบบข้อ 1 แล้วนั้นบอกเลยว่าทำค่อนข้างง่ายกว่ามากๆ พี่ Ford ได้อธิบายแล้วลองไปอ่านกันดูจ้า ทำเว็บบอร์ดมันไม่ยากหรอก มันยากที่มีคนเข้าหรือเปล่า? หากคนที่มีความสามารถการ Code ซักหน่อยก็สามารถทำตามได้เลยครับไม่ยากจริงๆ แต่หากอยากได้แบบ Design อะไรต่างๆเหมือนก็ยังพอทำได้อยู่ดีอาจจะต้องเพิ่มเงินเข้าไปอีกตามความเหนื่อยและเรื่องมากของผู้ว่าจ้างครับ 🙂

แต่หากเป็นข้อ 2 นั้นบอกได้เลยว่า ยาก!!!! คนส่วนใหญ่เข้าใจว่าทำ Website ต้นทุนถูก ใช่ครับมันถูกแต่ตอนเริ่มแรกเท่านั้น แต่ในความเป็นจริงมีอีกหลายๆเรื่องต้องดูแล จัดสรรอย่างมากมาย ก็ไม่แปลกอะไรที่หลายๆคน ในกระทู้จะตีราคาทั้งถูกและแพงตามประสบการณ์ที่ตัวเองได้เรียนรู้มาครับ

ทำไมถึงแพง ??? เนื่องจากการเรียนรู้ที่ต้องรองรับคนหลายๆแสนจนเกือบล้านที่เล่น Website บางคนทำเว็บมาหากไม่เคยเจอจริงๆจะไม่เข้าใจว่าทำไมถึงแพง Server ต้องวางเอง ค่าเรียนรู้ลองผิดลองถูกอีกล่ะ ? เทคโนโลยีใหม่ๆอีกล่ะ หากคุณทำเองหมดมันก็ไม่ได้หมายความว่าต้นทุนจะถูกลง เพราะว่ามันก็คือเอาเวลาของชีวิตคุณลงทุนไปอยู่ดีนั่นแหละ

แล้วบางคนทุกวันนี้ก็ยังไม่ทราบกันว่าทาง Pantip ไม่ได้ใช้ RDBMS นานแล้วครับตั้งแต่ทำอันใหม่ เราใช้ MongoDB กันซึ่งถามว่าทุกคนเป็นไหม ? ตอบเลยว่า ไม่ 555+ แต่ก็ต้องเรียนรู้กันซึ่งต้นทุนตรงนี้ในการเรียนรู้ก็ต้องลงทุนให้พนักงานมีความรู้อีกซึ่งมันไม่ง่ายเลยที่จะหาคนเรียนรู้ลองทำ เพื่อรองรับการขยายเพิ่มและรวดเร็วในการดึงข้อมูลอย่างที่เราๆท่านๆได้ใช้กันอยู่ทุกวันนี้ครับ

และสิ่งสำคัญที่สุดที่เรียกได้ว่าเขียนโปรแกรมช่วยไม่ได้เลยคือ การจัดการข้อมูลใน Pantip คุณคงเคยได้ยินมาอยู่แล้วว่าหลายๆคนนั้นกลัวการทำผิดกฎใน Pantip มากๆ กลัวถูกแบนบัญชี ซึ่งตรงจุดนี้ถือว่ายังไม่เห็นเว็บไหนทำได้ดีเท่า Pantip นะครับ การดูแลชุมชนเป็นอะไรที่สำคัญที่สุดของ Webboard เลยซึ่งหลายๆคนนั้น มองข้ามไป แต่ผมบอกได้เลยว่าการดูแลนั้นไม่ง่ายเลย ที่จะเข้าใจว่าคนไหน กำลังตั้งใจจะทำอะไรที่ผิดกฎหรือโจมตีแบบเนียนๆ หากไม่ใช่คนที่ดูแลมาอย่างยาวนานล่ะก็ยาก

เล่ามาซะเยอะสรุปไม่ได้ตอบคำถามเลย (ฮา) ส่วนตัวคิดว่าแพงแน่นอน และคิดว่าไม่ควรทำด้วยเพราะว่าจะมาแย่งรายได้ผม ( ไม่ใช่แหละ ) แต่เพราะการจะลงทุนทำเว็บควรจะเป็นแนวใหม่ๆหรือมีเอกลักษณ์เฉพาะตัวมากกว่าจะเอาเหมือนเขา ถ้าจะพูดในดูหล่ออีกนิดคือ “ขโมยอย่างศิลปิน” ดีกว่าครับ ( หาอ่านเอาเนอะ แอบโฆษณา ) คำตอบที่คุณควรจะถามตัวเองแต่แรกว่า “ทำไมคนอื่นจะย้ายจาก Pantip มาเล่นเว็บบอร์ดของคุณ” ถ้าหากคุณได้คำตอบของคำถามนี้ผมแนะนำให้คุณลงมือทำได้เลยครับ

เขียน Website แบบ pantip กี่บาทครับ
https://pantip.com/topic/30622000
http://macroart.net/2013/06/how-difficult-to-develop-forum-with-million-visitors-per-day/