Skip to content

jiramot/fungjai-infrastructure

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

9 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Hello Fungjai infrastructure :)

 

 

จุดเริ่มต้นของปัญหา :(

​ ย้อนกลับไปเมื่อปี 2014 สมัยเริ่มต้นพัฒนาเวปฟังใจ โดยตอนนั้นเราเลือกที่จะทำ MVP ด้วย Grails frameworks ด้วยความที่ทีมเราถนัด JAVA อยู่แล้วทุกคน บวกกับ 2 ใน 3 ของทีมพัฒนาเคยใช้ Grails อยู่แล้วในตอนนั้น

ซึ่งหน้าตา stack ของเรามีประมาณนี้

  • Grails

  • Steaming engine

  • Glassfish

  • MySQL

​ ในสมัยนั้นเราต้อง build war file จากนั้นอัพโหลดไปยัง App serv (Glassfish) ที่เช่าอยู่บน VPS ในไทยที่มี ram อยู่ 2GB ซึ่ง ณ ตอนแรกก็สามารถใช้งานได้เป็นอย่างดี เพราะว่าในช่วงเริ่มต้นจำนวนผู้ใช้งานยังไม่มากนัก

 

เมื่อต่อเดือนเรามีการฟังเป็นล้านครั้ง :)

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

  • ram เต็ม

  • Mysql บวม เนื่องจากเราออกแบบที่จะเก็บ Transactions ของการฟังลงใน Database ณ ตอนเริ่มต้น

  • แล้วถ้า VPS พัง เครื่องพังหละ เพลงทั้งหมดของเราจะหายไปหมดเลยหรอ

​ ซึ่งในตอนนั้นในทุกๆคืน เราจะต้องคอย restart VPS ของเรา และทุกๆครั้งที่เรานึกได้ เราก็จะต้องคอย Backup เพลงของเราทั้งหมดด้วย

ปัญหายังคงอยู่กับเราด้วยความเคยชิน จนดูเหมือนเราจะเริ่มทนกับมันไม่ไหว

 

แก้ปัญหาด้วยซื้อเครื่องใหม่

แน่นอนสิ่งแรกที่เรานึกถึงเพื่อแก้ปัญหา Resource ก็คือเครื่องใหม่ คราวนี้ก็มาถึงคำถามต่อมาว่าเราจะไป Cloud เหมือน Startup คนอื่นๆหรือไม่?

ไม่ใช่ว่าเราไม่อยากใช้ Cloud เหมือนคนอื่น แต่ทำไมเราเลือกที่จะทำทั้งหมดเอง

โจทย์ของเราคือ

  • เราเป็นเวปบริการฟังเพลงออนไลน์ ถ้าหากเราไปใช้ Cloud ก็จะทำให้เราเปลืองค่า Bandwidth มาก

  • Cloud ทั้งหมดอยู่ใกล้ที่สุดคือสิงคโปร์ แน่นอนเราต้่องการการฟังเพลงเร็ว ลูกค้าของเราอยู่ภายในประเทศเป็นส่วนใหญ่

  • ถ้าใช้ CDN ซึ่งกำลังจะมี CDN ในไทย ก็ยังแพงอยู่ดี

​ ดูเหมือนตัวเลือกมีไม่มากนัก จึงเป็นที่มาว่า ทำไมเราเลือกที่จะตั่ง Co-location ใน Data center ในไทย

 

จุดเริ่มต้นของ co-location

  • เราเลือกที่จะเช่า co-location 1/4 rack เพราะว่าเราต้องการที่จะเพิ่มเครื่องได้ในอนาคติ

  • เราซื้อ IP ยก class เพราะว่า เราต้องการทำ Gateway, Netmask ของเราเอง เนื่องจากเราคิดว่ามัน Secure กว่าการไปใช้ Netmask เดียวกันคนอื่น ซึ่งเค้าจะสามารถ Scan network ได้

  • เราซื้อจัดการแบ่ง IP ออกเป็น 2 วง คือ Public network และ Private network ด้วย Managed switch ของ cisco ซึ่งแน่นอน เราทำไม่เป็นหรอก (vlan)

ทำไมไม่ Backup เพลงด้วยการทำ Raid

​ ถึงเราจะมี Hardware raid แต่เราไม่ใช้ Hardware raid เพื่อทำ raid 1 เพิ่อแก้ปัญหาการ Backup ไฟล์เพลงได้อย่างไร ณ จุดนี้เราเชื่อว่าหลายๆคน ซึ่งก็เหมือนเราตอนแรก คงจะเลือก raid 1 หรือ 5 หรืออะไรก็ตามเพื่อจะใช้ Raid ในการ Backup ข้อมูล

“Disk ที่เอามาใช้ raid มันมาจากผู้ผลิตล็อตเดียวกัน ถ้ามันพังไปลูกหนึ่ง ลูกที่เหลือก็คงใกล้ๆพังแล้วหละ” -- คำพูดนี้มาจากหัวหน้าเก่าที่ผมเคยทำงานสมัยจบใหม่ๆ (Throughwave Thailand)

​ และแน่นอนเมื่อ Disk พัง Raid หลุด แล้วเราไปพยายาม Rebuild raid ใหม่ disk ลูกที่เหลือก็จะพังแล้วเราจะไม่เหลืออะไรเลย

​ เราเลือกที่จะใช้ Network drive แทน เพื่อจะทำการ sync volume ระหว่างเครื่อง เราเลือกใช้ GlusterFS และแน่นอน ผมจึงต้องขอเงิน CFO เพื่อซื้อ Server เป็นจำนวน 2n+1 เพื่อจะทำให้ทุกอย่างเป็น cluster โดยสมบูรณ์

  พอจะเดากันได้ สำหรับ startup จนๆของเรา การซื้อ server 3 ตัวคงจะเป็นไปได้ยาก เราจึงได้มาแค่ 2 ตัว เอาละ 2 ตัวก็ 2 ตัว เราจะทำยังไงกับมันดีละทีนี้

 

เริ่มต้นแก้ปัญหา Resource กันดีกว่า

​ ถึงตอนนี้ เรามี server 2 ตัวแล้ว เราต้องการทำ cluster ทุกอย่างของเราเป็น 2 ชุด หน้าตา stack โดยเริ่มแรกของเราเป็นประมาณดังนี้

  • HAproxy
  • Jetty เพื่อรัน war
  • GlusterFS
  • Nginx เพื่อทำ static file พวกรูป
  • Steaming engine
  • Jenkins
  • Gitlab
  • MariaDB with Galera cluster
  • ทั้งหมดอยู่บน CentOS ซึงเราใช้ VMware ESXi ในการแบ่ง VM โดยใช้ Ansible ในการ deploy ทุก service

ตอนต่อไป การมาของ Mobile App >>

Analytics

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published