หมายเหตุ mk มาถึงตอนนี้เราคงเห็นกันชัดว่า cloud computing คืออนาคตของการประมวลผลขนาดใหญ่ แต่สิ่งที่บ้านเรายังขาดแคลนมากคือประสบการณ์ ความรู้ความเชี่ยวชาญในการสร้างแอพพลิเคชันบนกลุ่มเมฆ (ยังไม่ต้องพูดถึงการสร้าง cloud infrastructure แบบ AWS หรือ Azure ที่ต้องใช้ทรัพยากรเยอะกว่านั้นมาก)

ปัจจัยหนึ่งคงเป็นเพราะบ้านเรายังไม่ค่อยบริการออนไลน์ที่มีโหลดเยอะๆ จนถึงขั้นว่าไปรันบนกลุ่มเมฆแล้วคุ้ม โชคดีว่าบริการบล็อกสำหรับจัดการความรู้ GotoKnow ที่พัฒนาและดูแลโดย Usable Labs ของมหาวิทยาลัยสงขลานครินทร์ เพิ่งเปลี่ยนระบบจากการดูแลเซิร์ฟเวอร์เอง มาเป็นรันจากกลุ่มเมฆ (ในที่นี้คือ AWS และ Heroku) เลยขอนำเบื้องหลังการย้ายระบบมาเผยแพร่ต่อครับ

ประสบการณ์ของ GotoKnow ถือว่าล้ำค่ามาก เพราะเป็นระบบขนาดใหญ่ที่มีผู้ใช้เยอะมาก (จาก สถิติ TrueHits อยู่ประมาณอันดับ 60 มี UIP: 59,065, PV:135,706)

ในอดีต GotoKnow เคยพบปัญหาเรื่องผู้ใช้เพิ่มจำนวนขึ้นจนจัดการระบบเซิร์ฟเวอร์ได้ยากขึ้นมาก ประกอบกับแกนหลักคือ ดร.ธวัชชัย ปิยะวัฒน์ (อ่านบทสัมภาษณ์ใน Blognone) ประสบปัญหาด้านสุขภาพ ดังนั้นจึงตัดสินใจย้ายระบบจากการดูเซิร์ฟเวอร์เอง มาเป็นการรันบนกลุ่มเมฆเพื่อลดปัญหาในการดูแล ซึ่งก็ประสบความสำเร็จด้วยดี และบันทึกบทเรียนเอาไว้ที่ AAR: เมื่อ GotoKnow ขึ้นไปอยู่บนก้อนเมฆ

ผมขอบทความนี้มาลงใน Blognone ต่อเพื่อเผยแพร่ความรู้และบทเรียนเรื่องกลุ่มเมฆในวงกว้าง ซึ่งอาจารย์ธวัชชัยก็แนะนำด้วยว่าเพิ่งเปิดบริการ Class.in.th เป็น SaaS ด้านการเรียนการสอนอีกตัว ที่รันอยู่บน AWS/Heroku แบบเดียวกับ GotoKnow ใครสนใจก็เข้าไปลองเล่นกันได้ครับ

AAR: เมื่อ GotoKnow ขึ้นไปอยู่บนก้อนเมฆ

โดย ดร. ธวัชชัย ปิยะวัฒน์ (ต้นฉบับจาก GotoKnow)

ไม่น่าเชื่อว่า GotoKnow ในปีนี้ย่างเข้าปีที่เจ็ดแล้วนะครับ ในทางเทคนิคแล้ว GotoKnow เป็นเว็บไซต์ที่เกิดขึ้นแล้วตกเป็น "the victim of its own success" (เหยื่อของความสำเร็จของตัวเอง) โดยตลอดมาครับ

ในการให้บริการเว็บไซต์ GotoKnow นั้น ปัญหาใหญ่ที่สุดทางเทคนิคคือการให้บริการเครื่องแม่ข่ายของระบบให้ได้เพียงพอต่อการใช้งาน ซึ่งเพิ่มขึ้นอย่างก้าวกระโดดอย่างต่อเนื่อง โดยล่าสุด GotoKnow เริ่มเข้าไปแตะสู่อันดับหลักสามสิบกว่าๆ ของประเทศหลายครั้งต่อเดือน จากการจัดอันดับของ TrueHits.net (ซึ่งอันดับเว็บไซต์นี้โดยปกติเปลี่ยนแปลงเพิ่มขึ้นลดลง 10-20 อันดับทุกวัน)

ถ้า GotoKnow เป็นเว็บไซต์ขององค์กรธุรกิจ เรื่องปัญหาทางเทคนิคของความสำเร็จนี้จะไม่มีปัญหาเลย เพราะความสำเร็จคือสิ่งที่องค์กรธุรกิจต้องการ อีกทั้งแหล่งทุนทางธุรกิจนั้นมีมากมหาศาลหลากหลายแหล่ง

แต่ GotoKnow ไม่มีนโยบายเปลี่ยนแปลงตัวเองไปในทิศทางธุรกิจ ที่ผ่านมา พวกเราที่ดูแลเว็บไซต์ยังอยู่ใน research lab เล็กๆ ชื่อ UsableLabs ในสถานศึกษาต่างจังหวัดอย่างมหาวิทยาลัยสงขลานครินทร์ และยังมุ่งในทิศทางของการศึกษาเป็นหลัก

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

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

หลังจากผมมีปัญหาสุขภาพ เรื่องนี้ยิ่งยากขึ้นอีก เพราะความสามารถในการทำงานของผมทดลงอย่างมาก ผมคงต้องเลือกทำเฉพาะสิ่งที่ทำได้ไม่ยากนักเท่านั้น

ปัญหาทางเทคนิคในการให้บริการเครื่องแม่ข่ายสำหรับเว็บไซต์ที่มีการใช้งานสูงเช่น GotoKnow ที่ผมวาดฝันว่าวันหนึ่งจะประกาศได้ว่า "คนไทยทำได้" แต่วันนี้ถ้าแค่ "ทำได้" ก็คงเพียงพอ (คำประกาศตั้งใจที่แท้จริงคือ "คนไทยต่างจังหวัดก็ทำได้" สะท้อนถึงความแตกต่างของโอกาสทางการศึกษาระหว่างกรุงเทพฯ กับต่างจังหวัด)

ด้วยเหตุนี้ผมจึงเริ่มย้าย GotoKnow ไปอยู่บน "ก้อนเมฆ"

"ก้อนเมฆ" ในที่นี้คือ Cloud Computing ซึ่งคือรูปแบบการให้บริการ "ทรัพยากร" อันได้แก่กลุ่มเครื่องบริการเว็บ กลุ่มเครื่องบริการการประมวลผล กลุ่มเครื่องบริการไฟล์ กลุ่มเครื่องบริการฐานข้อมูล กลุ่มเครื่องบริการการส่งอีเมล และบริการอื่นๆ สำหรับการให้บริการเว็บไซต์ โดยผู้ให้บริการดูแลจัดการทรัพยากรเหล่านั้นอย่างเบ็ดเสร็จสมบูรณ์ จนในมุมมองผู้ซื้อบริการแล้ว เสมือนว่าทรัพยากรนั้นใช้ได้อย่างไม่มีข้อจำกัด โดยมีวิธีการคิดค่าบริการแบบ "จ่ายตามการใช้งานจริง" (pay-as-you-go) (อ่านรายละเอียด Cloud Computing จาก Wikipedia)

ตัวอย่างเช่น Amazon Simple Storage Service (Amazon S3) ซึ่งเป็นบริการแรกที่ผมใช้ในการเริ่มต้นย้าย GotoKnow ขึ้นก้อนเมฆ

แต่เดิม GotoKnow จัดเก็บไฟล์ในเครื่องแม่ข่ายหลักและสำรองซึ่งการจัดการยุ่งยากไม่น้อย (ก่อนหน้าได้รับทุน Digital KM นั้นจัดเก็บอยู่ในเครื่องความสามารถต่ำและความจุต่ำกว่าสี่เครื่อง ยุ่งยากกว่ามาก) พอย้ายไป Amazon S3 เราสามารถให้บริการไฟล์ "ไม่จำกัดปริมาณ" แก่ผู้ใช้ได้จริงๆ โดยค่าใช้จ่ายที่เกิดขึ้นนั้นก็จ่ายตามปริมาณข้อมูลที่เก็บจริงๆ อีกด้วย

ยิ่งกว่านั้นเรายังใช้บริการ Amazon CloudFront ซึ่งเป็นบริการ Content Delivery Network (CDN) อันได้แก่บริการเครือข่ายความเร็วสูงของ Amazon ที่มีอยู่ทั่วโลกเพื่อให้บริการไฟล์ไปยังผู้ใช้ได้เร็วที่สุด อธิบายง่ายๆ CDN คือระบบ "ทางด่วนข้อมูล" นั่นเอง เมื่อมีผู้ใช้ download ไฟล์จาก GotoKnow ไฟล์นั้นจะขึ้นทางด่วนของ Amazon ไปยังเครื่องของผู้ใช้ แทนที่จะไปตามทางอินเทอร์เน็ตสาธารณะธรรมดา แน่นอนว่าไฟล์ย่อมไปถึงได้เร็วกว่า

ปัจจุบันเราจ่ายค่าบริการ Amazon S3 อยู่เดือนละประมาณ $100 ดอลลาร์ แต่จ่ายค่า Amazon CloudFront ประมาณ $1,000 ดอลลาร์ ลองคำนวนปริมาณข้อมูลของ GotoKnow ดูนะครับ

การย้ายไป Amazon S3 และ Amazon CloudFront ประสบความสำเร็จประมาณ 95% เพราะยังมีไฟล์ที่ตั้งชื่อเป็นภาษาไทยหรือตัวอักษรอื่นๆ มีปัญหาในการแสดงผลอยู่บ้าง ไฟล์ทั้งหมดถูกย้ายไปเรียบร้อยไม่มีปัญหาครับ แค่มีปัญหาเรื่องการแสดงผลเท่านั้นเอง หากผู้ใช้ท่านใดเห็นไฟล์เก่าๆ ของตัวเองมีปัญหาการแสดงผลก็แจ้งมาได้นะครับ

ต่อจากนั้นผมย้ายส่วนการให้บริการเนื้อหาของเว็บ ซึ่งประกอบด้วยส่วนหลักๆ คือ ส่วนบริการเว็บ ส่วนบริการการประมวลผล และส่วนบริการฐานข้อมูล

ส่วนบริการเว็บและส่วนบริการการประมวลผลนั้น เนื่องจากซอฟต์แวร์ของ GotoKnow พัฒนาโดยใช้เทคโนโลยี Ruby on Rails ซึ่งมีผู้ให้บริการ "ทับทิมใส่รางบนก้อนเมฆ" (Cloud Computing for Ruby on Rails Applications) รายใหญ่ๆ อยู่สองรายคือ Heroku กับ EngineYard ซึ่งผมตัดสินใจเลือกใช้บริการจาก Heroku ซึ่งมีบริการที่ครบวงจรและสะดวกกว่า ซึ่งเป็นการตัดสินใจที่ไม่ผิดเพราะปัจจุบัน Heroku เติบโตและมีบริการใหม่ๆ เพิ่มเติมอีกมาก อีกทั้งยังสะดวกในการใช้งานมากขึ้นเรื่อยๆ

การย้ายมายัง Heroku นั้นง่ายดายเหมือนปอกกล้วยเข้าปาก จนไม่มีอะไรเป็นประเด็นให้เล่า ของเขาดีจริงๆ ขอบอก และหลังจากย้ายมา Heroku แล้วก็เหมือนยกภูเขาออกจากอกผม (แล้วเอาก้อนเมฆมาใส่แทน) ในตอนนี้ไม่ว่า GotoKnow จะมีการใช้งานมากแค่ไหนผมก็ไม่หวั่น ผมเพิ่มและลด "dyno" (หรือหน่วยให้บริการการประมวลผลเปรียบเสมือนเครื่องแม่ขายหนึ่งเครื่อง) ได้เพียงเสี้ยววินาที

นอกนั้นบริการเสริมอื่นๆ ของ Heroku (และบริษัทพาร์ทเนอร์ของเขา) ก็สะดวกมาก อาทิเช่นระบบการส่งอีเมล ซึ่งก่อนหน้านี้ต้องดูแลเครื่องแม่ข่ายสำหรับส่งเอง ปัจจุบันใช้บริการของบริษัท SendGrid ไม่ต้องกลัวว่าใครจะมาเจาะระบบอีเมลเพื่อส่ง spams อีกแล้ว

ตอนนี้การใช้งาน GotoKnow จะมากแค่ไหนผมก็ไม่น่าห่วงอีกต่อไป ไม่มีต้องตื่นมากลางคืนเพื่อ tune up เครื่องแม่ข่ายอีกแล้ว

แต่สิ่งที่น่าหวั่นคือค่าบริการ แม้เราจะจ่ายตามการใช้งานจริงเป็นรายชั่วโมง แต่การใช้งานรายชั่วโมงของเราก็ไม่ได้น้อย อย่างเดือนที่แล้วเราต้องจ่าย Heroku ประมาณ $3,500 ดอลลาร์

เมื่อคิดเป็นเงินแล้วดูจะปริมาณมาก แต่ในความเป็นจริงแล้วไม่มาก หากคิดในทางเลือกอื่นที่เราต้องซื้อเครื่องแม่ข่ายเองและต้องจ้าง network engineer ที่มาติดตั้งดูแลระบบให้ได้เหมือนของ Heroku ต้นทุนต้องแพงกว่านี้ไม่น้อยกว่าสองสามเท่าแน่ๆ

ก่อนหน้านี้ค่าใช้จ่ายต่างๆ ดูเหมือนถูกกว่านี้ เพราะผมสวมหมวก network engineer เอง ตอนนี้จะให้ทำอย่างนั้นอีกคงไม่ไหวครับ

ส่วนท้ายสุดที่ย้ายขึ้นก้อนเมฆคือส่วนบริการฐานข้อมูลนั้นเป็นส่วนที่ซับซ้อนกว่าเพื่อน

เนื่องจากเราใช้ MySQL มาก่อนทำให้เราไม่สามารถใช้ PostgreSQL ที่ Heroku ให้บริการได้ ทำให้เราต้องใช้ Amazon Relational Database Service (Amazon RDS) ซึ่งคือบริการ MySQL บน Cloud Computing นั่นเอง

ส่วนฐานข้อมูลเป็นปัญหาคอขวดของ GotoKnow มาตลอด แต่เราแก้ไม่ได้เพราะจะยุ่งยากเรื่องการซื้อเครื่องแม่ข่ายใหม่

คราวนี้พอมาใช้ Amazon RDS ผมก็เริ่มต้นทำการขยายศักยภาพฐานข้อมูลทันที เพราะจะเพิ่มหรือลดเครื่องแม่ข่ายทำได้อย่างใจเพราะเครื่องแม่ข่ายเป็นเครื่องแบบเสมือน (virtual machine)

การขยายศักยภาพฐานข้อมูลนั้นมีสองวิธี คือขยายออกด้านข้าง (ใช้เครื่องแม่ข่ายหลายเครื่องช่วยกันประมวลผลเป็น cluster -- อ่านเพิ่มเติม MySQL Cluster ที่ Wikipedia) หรือขยายออกด้านบน หรือการใช้เครื่องแม่ข่ายที่ศักยภาพสูงขึ้น

ในทางทฤษฎีการขยายออกด้านข้างหรือการใช้ MySQL Cluster นั้นดีที่สุด เพราะสามารถขยายได้ไม่จำกัด แล้ว Amazon RDS ก็ออกแบบให้การเพิ่ม ReadReplica ทำได้ง่ายมาก แน่นอนครับ ผมเลือกใช้วิธีนี้ ซึ่งก็ได้ผลดีทีเดียว

จนกระทั่งผู้ใช้เริ่มแจ้งว่า "ข้อมูลหาย!!"

สักพักก็บอกใหม่ว่า "ไม่หาย แต่เมื่อกี้มันไม่เห็นมี..."

ยิ่งใช้บริการ MySQL Cluster ทำงานนานขึ้นเรื่อยๆ ปัญหานี้ก็ยิ่งเพิ่มมากขึ้นเรื่อยๆ

ปัญหานี้คือปัญหา "data latency" หรือปัญหาข้อมูลในเครื่องแม่ข่ายใน cluster ปรับปรุงไม่เท่ากัน (non-realtime) ยิ่งใน cluster มีเครื่องหลายเครื่อง ปัญหาก็จะยิ่งควบคุมยาก

ผมหาวิธีแก้อยู่นานก็ยังหาทางออกไม่ได้ ยิ่งหาก็ยิ่งเจอว่าคนอื่นก็เจอปัญหา data latency เยอะเหมือนกัน เป็นจุดบอดของ Amazon RDS ที่ Amazon เองก็หาทางแก้อยู่ ปัญหาเองก็ซับซ้อนทั้งฝั่ง Amazon และฝั่ง MySQL ก็โทษกันไปมา

สุดท้ายไม่มีทางเลือก ผมตัดสินใจ "ขยายออกด้านบน" แทน หรือการใช้บริการเครื่องแม่ข่ายที่มีศักยภาพสูงเพียงเครื่องเดียวให้บริการฐานข้อมูลครับ

หลังจากใช้ database server ศักยภาพสูงตัวเดียวแทน cluster แล้ว ทุกสิ่งทุกอย่างก็คืนสู่ความสงบ GotoKnow ก็สามารถให้บริการได้เต็มที่ไม่ว่าปริมาณการใช้งานจะมากแค่ไหนก็ตาม

ที่น่าเจ็บใจคือ Amazon RDS นั้น เขาให้บริการสองแบบ คือ "จ่ายตามใช้งานจริงรายชั่วโมงทั้งหมด" (On-Demand DB Instances) ซึ่งแพง หรือ "จ่ายค่าจองก่อนเพื่อลดราคารายชั่วโมง" (Reserved DB Instances) ซึ่งแบบหลังนี้คำนวนแล้วจะคุ้มกว่าเยอะมาก และผมก็จ่ายเงินซื้อ reserved instances เพื่อทำ cluster ไปเรียบร้อยแล้ว ก่อนจะเจอปัญหา data latency

แต่นั่นละครับ ไม่มีใครตัดสินใจถูกร้อยเปอร์เซนต์ โดยเฉพาะการตัดสินใจด้านเทคโนโลยี ได้แค่นี้ก็ดีหนักหนาแล้ว และหมายความว่าผมต้องหาทางเอา cluster กลับมาใช้ใหม่หลังจากมีทางออกเรื่อง database latency แล้ว ก็เป็นเรื่องที่ท้าทายให้ทำกันต่อไป

ในวันนี้ Cloud Computing คือเทคโนโลยีการให้บริการ "ทรัพยากรออนไลน์" ที่ดีที่สุดและจะดีขึ้นเรื่อยๆ ในอนาคตครับ เครื่องแม่ข่ายที่เป็นเครื่องจริงๆ นั้นเป็นเทคโนโลยีในอดีตไปแล้วครับ

ในตอนนี้ยังไม่มีผู้ให้บริการ Cloud Computing ในประเทศไทย แต่ผมเชื่อว่าอีกไม่นานก็คงมี และแน่นอนครับ GotoKnow รอคอยที่จะ "กลับเมืองไทย" อีกครั้ง

ส่วนผมในตอนนี้ผมลืมไปแล้วครับว่าการบริหารจัดการเครื่องแม่ข่ายทำอย่างไร ผมปลดตำแหน่ง network engineer ออกจากท้ายชื่อตัวเองได้อย่างมีความสุขครับ

ขอบคุณก้อนเมฆทุกๆ ก้อน ขอบคุณทุกๆ คนที่สร้างเทคโนโลยี Cloud Computing ให้ใช้งานได้สะดวกเช่นนี้ และที่สำคัญที่สุดขอบคุณผู้ใช้ทุกๆ ท่านที่ใช้งาน GotoKnow ตลอดมาไม่ว่าในวันที่ระบบช้าหรือวันที่ระบบเร็วครับ