เมื่อช่วงต้นเดือนที่ผ่านมา Blognone มีงานเสวนาที่ไม่ได้ประกาศภายนอก โดยเชิญผู้ร่วมงานเป็นกลุ่มตัวแทนของผู้ดูแลเว็บขนาดใหญ่จำนวนหนึ่ง เช่น Sanook.com, Kapook, MThai, ไทยรัฐ, Thaitrend, Tarad.com, และ Pantip.com ทั้งหมดได้ร่วมพูดคุยกันถึงประสบการณ์ปัญหาต่างๆ ที่เคยเจอมาว่าในการทำเว็บที่ใหญ่ขึ้นเรื่อยๆ เคยเจอปัญหากันอย่างไร และมีประสบการณ์การแก้ไขกันอย่างไรมาแล้วบ้าง
คนแรกคือคุณเชิดศักดิ์ โชครวมชัย รองประธานอาวุโสฝ่ายปฏิบัติการเครือข่ายจากเว็บสนุก ได้เล่าถึงกระบวนการการปรับตัวของเว็บในแต่ละระดับเป็น 7 ระดับ นับแต่การทำเว็บแบบเน้นฟีเจอร์อย่างเดียว ไล่ไปจนถึงระดับที่อาจจะไม่มีใครที่เรารู้จักเคยเจอโหลดในระดับเดียวกันมา ก่อน ประสบการณ์เหล่านี้จะแสดงให้เห็นว่าเมื่อเราสามารถผ่านระดับที่ความยุ่งยาก ต่างๆ ไปได้ เราจบพบในช่วงที่ระบบสามารถขยายออกไปได้อย่างมีประสิทธิภาพ แต่ในสุดท้ายแล้วหากเว็บยังคงเติบโตด้วยความเร็วสูง เราจะพบปัญหาที่ต้องสร้างความรู้ด้วยตัวเอง ปัญหาใหม่ๆ เช่น พลังงาน, ผู้ใช้จากหลายประเทศทำให้ต้องใช้งาน CDN, ไปจนถึงกระบวนการจัดการกระบวนการทำงานและการจัดการคน
[URL=“http://www.youtube.com/watch?v=tRA6EKDu_kc”]<a href=“http://www.youtube.com/watch?v=tRA6EKDu_kc” target="_blank" rel=“nofollow”>
//youtu.be/tRA6EKDu_kc
คุณโดม เจริญยศ เล่าถึงกระบวนการดูแลเว็บ Kapook และ TVPool โดยเล่าถึงประสบการณ์การเลือกเทคโนโลยี เช่น การเลือกของ Rackspace โดยปัจจัยสำคัญของการเลือกเทคโนโลยี คือ “เอาอยู่” เขาเล่าถึงการใช้ PHP ที่ใช้งานได้ดีแม้อาจจะต้องใช้หน่วยความจำสูงสักหน่อย และการเลือกการทำเครื่องเสมือนด้วย OpenVZ แต่ยังหาแนวทางใหม่ๆ เช่น Lua บน Nginx และกำลังหันไปใช้ docker มาแทนเครื่องเสมือนแล้วรันผ่านพอร์ตอย่างเดียว
ทางฝั่ง MThai เข้ามาเล่าถึงการพัฒนาแอพพลิเคชั่นที่โหลดหนักที่สุดนั่น คือ “lotto” (ตรวจหวยออนไลน์) ทาง MThai ใช้ Wordpress และเคยใช้ TotalCache มาก่อน แต่สุดท้ายต้องพัฒนาปลั๊กอินของตัวเองเพื่อให้ความต้องการ สร้างไฟล์ static ขึ้นมา และเมื่อมีการอัพเดตก็ปรับไฟล์ static ใหม่อีกครั้ง เป็นแนวทางที่ MThai เลือกต่างออกไปจากผู้ให้บริการรายอื่นๆ ที่พัฒนาแอพพลิเคชั่นเองทั้งหมด
เว็บไซต์ไทยรัฐออนไลน์ โดยคุณ สิริชัย มีมุทา ผู้จัดการฝ่ายวิจัยและพัฒนาได้มาเล่าถึงปัญหาแอพพลิเคชั่นที่พบมา ปัญหาหลักคือฐานข้อมูล ทางไทยรัฐจึงพยายามให้โค้ดต้องยุ่งกับฐานข้อมูลน้อยที่สุด เพราะปัญหาหลายครั้งก็ไม่ใช่ปัญหาจากโหลดภายนอกแต่เป็นโปรแกรมเองที่ไม่ได้ ทดสอบบนโหลดที่หนัก
[URL=“http://www.youtube.com/watch?v=Xxa-95qKX6o”]<a href=“http://www.youtube.com/watch?v=Xxa-95qKX6o” target="_blank" rel=“nofollow”>
//youtu.be/Xxa-95qKX6o
บริการถัดไปเป็นบริการที่เราอาจจะไม่ได้ใช้ “เว็บ” โดยตรง เพราะเป็นระบบ 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
