DominixZ : Live Smart & Geeky

ถึงวันนี้ก็เป็นเวลาหลายปีแล้วที่ผมได้มาจับด้านเว็บเป็นอาชีพจริงๆนับย้อนไปตั้งแต่ปี 2 จนมาถึงตอนนี้ปี 2011 ก็เป็นเวลา 5 ปีแล้วที่ได้ทำอาชีพนี้ โดยต้องบอกก่อน ว่าผมไม่เคยได้จับระบบใหญ่ ไม่เคยเจองานที่ Hit Limit ของสถาปัตยกรรม จนกระทั่งมาทำงานๆหนึ่งที่เรียกว่า “บอทเว็บ” แน่นอน OBVOC ไม่ใช่งานบอทเว็บ ตัวแรกของผม แล้วแต่ละตัวก็ไม่เคยเจอ Limit จนกระทั่งเอามาใช้งานจริง ทำแบบ Commercial จริงๆ แล้วทำให้รู้ว่าจริงๆ สิ่งที่เราคิดว่าดีตอนแรกมันอาจไม่ดีถึงตอนหลังก็ได้ เลยอยากจะมาถ่ายทอดความรู้กับนักพัฒนาหรือใครก็ตามที่ กำลังจะทำเว็บขนาดใหญ่หรือมี Transaction สูงๆแล้วก็เป็นสาเหตุว่าทำไมผมถึงต้องพัฒนาก้าวไปอีกขั้นด้วยเทคโนโลยีที่พึงมาในปัจจุบัน โดยสาเหตุที่เจอมากับตัวก็คือ

1. เงินทุนที่่มีอย่างจำกัดทำให้เรามี Server ขนาดเล็กกว่าที่ Application เราต้องการสมมุติว่าคุณมี RAM อยู่ 1GB แล้วเป็น Shared CPU แต่คุณต้องการทำ Fulltext , การวิเคราะห์และคำนวณเพื่อนำมาทำสถิติ ซึ่งใช้ CPU 100% เกือบตลอดเวลา ดังนั้นปัญหาแรกคือ “ทรัพยากร” อย่ามีน้อยเกินไปกับขนาดตัว App แต่อย่่างว่าใครจะไปรู้ต้องลองทำๆไปแล้วเดียวถึงจะรู้เอง
2. ทดลองกับข้อมูลจำนวนมากๆ ปกติแล้วเราทำเว็บไซต์จะทำกับข้อมูลจำนวนน้อยๆก่อน แล้วสิ่งที่คุณจะเจอปัญหาก็คือ เมื่อมันถึงจุดๆหนึ่งที่ RAM ไม่พอพักข้อมูลของคุณใน MySQL (Database) อื่นๆระบบคุณจะช้าขึ้นไม่ต่ำกว่า 5x-20x ทำให้จากเว็บดีๆของคุณช้าในทันที โดยผมบอกได้เลยว่าปัญหานี้ไม่จำเป็นต้องทำตั้งแต่เริ่ม แต่สิ่งที่ควรทำคือหาเลขนี้ให้ได้ “อัตราการโตของข้้อมูลจริงต่อวัน” ให้เก็บข้อมูลสัก 30 วันคุณจะรู้อยู่่สองเลขก็็คือ Database โตขึ้นต่อวันเท่าไร และค่าเฉลี่ยต่อ 30 วันเท่าไร แล้วให้คุณไปหาอีกเลขหนึ่งที่สำคัญก็คือ “ฐานข้อมูลโตจากวันแรกจนถึงวันที่  30 คิดเป็นกี่ %” แล้วลองทำนายดูว่าอีก 90 วันข้างหน้ามันจะมีข้อมูลเท่าไร ซึ่งแบบนี้คือวิธีคิดง่ายๆ เรื่องจริงมันไม่ง่ายที่จะเดาแบบนี้เพราะมีเรื่อง Marketing มาเกี่ยวข้องด้วย
3. พอเราหาอัตราการโตข้อมูลเจอแล้ว สิ่งที่คุณควรจะทำต่อไปก็คือ “ทดลองด้วยจำนวนข้อมูลที่ทำนายไว้อีก 90 วันหรือมากกว่านั้น” โดยถ้ามั่นใจแล้วว่า Feature ไม่เปลี่ยนแปลง ผมขอแนะนำว่าให้ทดสอบแบบ Stress Test หรือทำให้สุดไปเลยคือ Insert ข้อมูลเข้าไปเรื่อยๆแล้วลอง Test ระบบว่าระบบเราเริ่มช้า ให้จดเลขนั้นไว้ไม่ว่าจะเป็นจำนวน Record หรือ Database Size แล้วลองนำกลับมาคำนวณดูโดยใช้เลขเดิมที่เรามีโดยคราวนี้เราจะหาว่า “จะใช้ระยะเวลาเท่าไรถึงจะถึงข้อมูลจำนวนที่ทำให้ช้า” โดยวิธีก็คือ ให้เอา      จำนวนข้อมูลที่ทำให้ช้า / อัตราการโตข้อมูลจริงเฉลี่ยต่อวัน  โดยถ้าอยากให้แม่นกว่าเดิมให้เอาอัตราการเติบโต (%) ไปหารอีกทีก็จะได้ข้อมูลแบบหยาบๆมาพอดูได้ว่า อีกกี่วันถึงเวลาที่เราต้องเปลี่ยนแปลงวิธีคิดกับการเข้าถึงฐานข้อมูล ถ้ามันเป็นเวลานานเป็นปีแล้วละก็ชั่งมันไปก่อนไม่ต้องทำอะไร แต่ให้รับรู้ไว้้แล้วจดว่ามันจะช้าเมื่อไร
4. เว็บไซต์มีหลายด้านแต่ด้านไหนจะสำคัญกว่าใครขึ้นอยู่กับแต่ละ Application โดยตัวแปรสำคัญที่ผมคิดว่าสำคัญจริงๆ ก็คือ CPU , RAM , อัตราความเร็วนในการเขียนข้อมูล , อัตราความเร็วในการอ่านข้อมูล , Bandwidth ขาเข้า-ขาออก , Webserver request per sec , Network Latency (ผมใช้ Firebug ดู)
5. เรื่องการทำ Fulltext Search กับ Reverse Index เนื่องจากผมต้องมีการทำการค้นหาข้อมูล เหล่านี้จากบอทที่เก็บมาได้ก็ผมข้อเท็จจริงหลายอย่างว่า การทำ Reverse Index นั้น sure กว่าเยอะว่าจะค้้นหาเจอ แต่มีข้อเสียคือเราไม่รู้ว่าเขาจะหาด้วยคำอะไร จนกว่าจะมีการใส่ข้อมูลเข้ามา ซึ่งถ้าให้ระบบไปทำ Reverse Index ทันที ณ ตอนนั้นก็คงช้า ดังนั้นคุณต้อง Weight เอาดังนี้
   • Like นั้นช้า แต่ข้อมูลที่อยากจะหานั้นตรงกับความต้องการมากกว่า เมื่อข้อมูลมีมากๆนั้นวิธีนี้จะช้าขั้นเทพก็ว่าได้
   • Fulltext Search โดยเท่าที่ผมใช้มา มันค่อนข้างได้ผลประมาณ 70-80% เลยทีเดียวสำหรับภาษาไทย (ผมใช้ MySQL MyISAM fulltext) แต่อย่างว่า ถ้าอีก 20% นั้นเป็นสิ่งที่ลูกค้าผมต้องการหา แต่ดันหาไม่เจอเขาจะพอใจรึเปล่า ? ดังนั้นวิธีนี้คือ Speed มาก่อน , Coverage 70-80% แล้วจะช้าเมื่อเริ่มมี Complex Search เช่น ค้นหาข้อมูลที่มีคำว่า “โดม” หรือ “วโรดม” หรือ “ทศนิยม” หรือ “อื่นๆ” และไม่มีคำว่า “ทดสอบ” แบบนี้เป็นต้น
   • Reverse Index ข้อเสียคือไม่สามารถทำให้ค้นหาทันทีได้หรือจะต้องทำ Index ด้วยตัวเองก่อนนั้นเอง วิธีนี้ก็ใช้ Server Side Script ช่วยอย่่าง PHP เอาข้อมูลที่มีมาวิเคราะห์ว่ามี “คำนี้” ไหมเสร็จแล้ว Save ความสัมพันธ์ระหว่างข้อความกับ Keyword ถ้ามีคนค้นหาด้วย Keyword นั้นพอดีคราวหลังก็จะดึงข้อมูลขึ้นมาได้แล้ว แต่ข้อเสียมีเยอะมากคือถ้าจะทำ Complex Search นั้นเราจะต้องทำตัว Translate จาก Search Query มาเป็น SQL Query ซึ่่งเสียเวลา
   • Fulltext ผสม Reverse Index วิธีนี้ได้ผลดีที่สุด โดยใช้วิธีการ Union Query กันผลที่ได้คือมีความถูกต้องสูง สามารถค้นหาได้ทันที แต่ก็ไปตายที่ Complex Search อยู่ดี
6. ควรจะรู้จัก CAP Theorem ซึ่งเป็นหัวใจที่ต้องเลือกว่าจริงๆ แล้วระบบเราต้องการแบบไหน ซึ่งตรงส่วนนี้ถ้ามีประสบการณ์จะเข้าใจความสำคัญในการเลือก CAP โดยทำให้เราก้าวไปเป็น Web Developer อีกขั้นหนึ่งโดยจะเข้าใจคำว่า “one size doesn’t fit all”
7. อย่ามองข้าม Script Automation และ Alert สองเรื่องนี้ถือว่าเป็นสิ่งที่ทำให้ชีวิตของคนเขียน Program สบายและมีความสุขได้ ถ้าขาดส่วนนี้ไปงานจะเยอะขึ้นเรื่อยๆ จนเราปวดหัวเลยทีเดียว โดย Automation ให้ได้มากที่สุดเท่าที่เราทำได้ ทั้ง Log ข้อมูล , Backup ข้อมูล , Process ข้อมูล ฯลฯ เท่าที่คอมพิวเตอร์จะทำได้ ผมมั่นใจว่าถ้าการเขียนครั้งหนึ่งสามารถแก้ปัญหาหนึ่ง ที่คุณต้องใช้เวลา 10 นาที – 30 นาทีทำต่อครั้งนั้นถือว่าคุ้มค่ามากเพราะ มันคงไม่เกิดเพียงแค่ครั้งเดียวเป็นแน่แท้ ! แล้วคุณก็เอาไปใช้กับระบบอื่นได้อีกด้วย อีกอันที่สำคัญคือระบบ Alert คุณเบื่อไหมที่ต้องค่อย Monitor อะไรบ้างอย่างบ่อยๆทั้งๆที่เรื่องมันไม่ได้เกิดตลอดเวลา เช่น ระบบกำลังจะ Memory หมด , CPU หมด , มี Process บางตัวใช้ CPU เกิน 80% แล้ว Log ฯลฯ ซึ่งเรื่องราวนี้ขึ้นอยู่กับว่าคุณต้องการให้มันเป็น Automation หรือ Alert
8. Backup Backup Backup โดย Backup ที่ว่านี้คืออย่า Backup เฉพาะในเครื่องเดียวกัน ให้มีการกระจายข้อมูลไปที่อื่นด้วย หรือนำมาเก็บไว้ในเครื่องตัวเอง เพราะข้อมูลเป็นสิ่งสำคัญที่สุดของเว็บถ้ามันหายไป เว็บเราก็คงเหมือนเริ่มใหม่กันเลย ดังนั้นอย่าลืม Backup ไม่ว่าจะด้วยวิธีการไหน แต่ผมแนะนำ Incremental Backup แต่ถ้ามันทำได้ยาก ก็แนะนำว่า Backup ทั้งหมดไปเถอะดีกว่าหายครับ

จบแล้ว 8 ข้อโดยจริงๆยังมีอีกมาก แต่เรื่องเหล่านี้เป็นเรื่องที่ผมเจอตอนทำ OBVOC เลยอยากจะนำมา Share ให้ฟังกันครับ