By: mk 
on 21 June 2010 - 15:00
Tags:
ตอนนี้ Facebook กลายเป็นเว็บไซต์ขนาดใหญ่ที่สุดของโลก มีผู้ชมเดือนละ 570 ล้านครั้ง มีคนมาดูภาพบน Facebook วินาทีละ 1.2 ล้านครั้ง แต่อัตราการล่มของ Facebook กลับน้อยมาก (โดยเฉพาะเมื่อเทียบกับ Twitter)
เว็บไซต์ Royal Pingdom จึงได้นำเสนอซอฟต์แวร์ที่ Facebook ใช้ทำเซิร์ฟเวอร์ว่ามีอะไรบ้าง? Facebook ทำอย่างไรจึงรองรับผู้ชมจำนวนมหาศาลนี้ได้
โดยภาพรวมแล้ว Facebook ยังใช้เทคโนโลยี LAMP เช่นเดียวกับเว็บไซต์ทั่วไป แต่ในรายละเอียด Facebook กลับพัฒนาซอฟต์แวร์ของตัวเองขึ้นมาอีกมากมาย
ซอฟต์แวร์ที่ Facebook ใช้ มีดังนี้
- Memcached เป็นตัวกลางระหว่างเว็บเซิร์ฟเวอร์กับฐานข้อมูล เพื่อไม่ให้ต้องเรียกข้อมูลบ่อยครั้ง Facebook มีเซิร์ฟเวอร์ Memcached หลักหลายพันตัว ซึ่งน่าจะมากที่สุดในโลก
- HipHop for PHP ตัวแปลภาษา PHP เป็น C++ เพื่อประสิทธิภาพที่ดีกว่า (อ่านข่าวเก่าประกอบตามลิงก์)
- Haystack ระบบเก็บภาพประสิทธิภาพสูง ตอนนี้มีภาพถูกเก็บอยู่ 8 หมื่นล้านภาพ
- BigPipe เว็บเซิร์ฟเวอร์ที่ให้บริการเฉพาะ "บางส่วนของเพจ" (ตัวอย่างที่ชัดเจนคือ Facebook Chat)
- Cassandra ฐานข้อมูลแบบกระจายตัว (อ่านข่าวเก่าเรื่อง NoSQL)
- Scribe ระบบจัดการ log file
- Hadoop ระบบ MapReduce
- Hive ระบบที่ใช้ SQL กับ Hadoop
- Thrift ตัวกลางสำหรับภาษาที่ใช้พัฒนาอันหลากหลาย
- Varnish ตัวเสริมประสิทธิภาพของ HTTP
นอกจากนี้ยังมีเทคนิคอื่นๆ อีกมาก เช่น การทดสอบโค้ดเฉพาะผู้ใช้บางกลุ่ม, การแอบรันระบบใหม่โดยไม่ให้ผู้ใช้รู้ เพื่อเป็นการทดสอบในสภาวะการณ์จริง รายละเอียดอ่านกันได้ตามลิงก์ครับ
ที่มา - Royal Pingdom
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
อยากรู้ว่าใครเป็นคนคุมบังเหียนการใช้เทคโนโลยีทั้งหมดของ Facebook ถึงได้ตัดสินใจว่าตัวไหนจะใช้ตัวไหน หรือพัฒนาเองด้วยจัง
I will change the world, to the better day.
ผู้ใช้มั๊งครับ ;)
อันไหนคนใช้งานเยอะ ก็ต้องตัดสินใจสร้าง script ที่ดีกว่าขึ้นมาสักชุด เพื่อแยกงานไปอีก process นึง และสร้างความเสถียรให้มากที่สุด ตามความนิยม ลดงานระยะยาวแบบศูยน์กลางได้ด้วย
my blog
ยิ่งใหญ่จริงๆเว็บนี้
もういい
น่าสนใจดี
มีแหล่งข้อมูลเพิ่มเติมอีกที่หากใครสนใจ Highscalability tag Facebook
แฟนพันธุ์แท้สตีฟจ็อบส์ | MacThai.com
โอ้ว Varnish จริงๆด้วย
มือถือผมมี facebook integration มันทำงานได้เร็วมาก พอๆ กันที่กัวมันมากอยู่เหมือนกัน
ใช้เป็นกรณีศึกษาในห้องเรียนเกี่ยวกับการจัดการเทคโนโลยีได้ดีเลยนะเนี่ย
ทีมงานคงแน่นประสบการณ์มากกว่าทีมของทวิตเตอร์ด้วยนะครับเนี่ย
รู้สึกจะแอบรันโปรแกรมจริงนั่นล่ะครับ
ก่อนหน้านี้เวลาผมเข้า gmail บน Android แล้วคลิกที่ link ของเมล์ facebook ที่เตือนว่ามีใครส่งข้อความหาเราบ้าง
ปกติมันจะเด้งไปหน้า facebook ปกติ ซึ่งมันไม่เหมาะกับหน้าจอของโทรศัพท์
มาวันนี้ก็กดอีก แต่มันก็เด้งไปที่หน้า touch.facebook.com.... แล้วก็ใช้งานได้สะดวกเลยทีนี้
โอ๊ะ เปลี่ยนตอนไหนเนี่ย เงียบๆ นิ่มๆ เลย
เป็นกรณีตัวอย่างสำหรับงานใหญ่ๆ เลยนะครับ
โดยเฉพาะเว็บประกาศผล Admission ควรเอาอย่าง มาก!
ล่มให้เด็กมันด่ากันได้ทุกปี :3
เอาไปลง google app engine จบ !!
แฟนพันธุ์แท้สตีฟจ็อบส์ | MacThai.com
gae มันมี limit ครับ แว้บเดียวก็เต็มแล้ว
แต่ก็เห็นมีนะครับที่แอบเอา static file ไปฝากไว้กับ gae
ใช้ EC2 Extra Large เลยครับ!!!!
ว่าแต่ เว็บประกาศผล ทำเป็นกระจายไปหลายที่ แต่สุดท้ายก็เข้าที่เซิร์ฟเวอร์กลางอยู่ดี ไม่รู้ให้เด็กมึนหัวเล่นทำไม (อย่างน้อยระบบรายงานผล O-NET ก็เป็นอย่างนี้แหละ แถมเป็น Java อีก ช้าเข้าไป)
"Java ช้า" นี่ระวังโดนยำนะครับ :P
+1 ถ้าผมจำไม่ผิดคนมีส่วนเกี่ยวข้องกับเว็บประกาศผลนั้นก็อยู่แถว ๆ นี้ :P
5555+ ปลงกับเวปรัฐบาลของไทยละ
Siros ฝากมาบอกครับ 570 billion page views per month
billion แปลว่า พันล้าน
ต้องแปลว่า เดือนละ 5 แสน 7 หมื่น ล้านครั้งครับ
อลังการการวางระบบมาก
ไม่รู้จักเลยซักอย่าง แต่นึกถึง เวบPantip ขานั้นล่มประจำ
ทีมงานช่วยเอาไป C and D ด้วยเถอะ
สุดเลย วางแผนดีมาก
อ่านผ่านๆแล้วอาจจะรู้สึกว่ามันเป็นการเลือกเอาซอฟต์แวร์ server มารัน แต่จริงๆแล้วหลายตัว Facebook พัฒนาขึ้นเองในแบบ Distributed Computing บางตัวก็ออกเป็น Open Source ด้วยอย่าง Thrift เข้าใจว่าถ้าเว็บทั่วๆไปจะเอามาใช้นั้นทำได้ แต่จะมี overhead สูงอย่างไม่จำเป็น (ประมาณว่า แทนที่จะเป็น PHP + SQL ง่ายๆ กลายเป็นต้องเขียนโปรแกรมแบบ Parallel หรือ Multi-thread เองตั้งแต่แรก)
ผมคิดว่าที่น่าสนใจคือ กระบวนการที่นำมาสู่การตัดสินใจเปลี่ยน component แต่ละตัว เขาตัดสินใจยังไง และมีแผน roll out ยังไง เพื่อรองรับให้ทัน
แล้วจะเรัยกว่า LAMP อยู่ไม๊...
LAMP ครับ มีครบ เพียงแต่โมเยอะมาก