การปรับขนาดเว็บแอปพลิเคชันของคุณ: ขั้นตอนพื้นฐาน

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

เพิ่มประสิทธิภาพ

Gearheart แนะนำให้ถามตัวเองด้วยคำถามต่อไปนี้:

• การสืบค้นฐานข้อมูลเหมาะสมที่สุดหรือไม่ (การวิเคราะห์อธิบาย การใช้ดัชนี)
• ข้อมูลถูกจัดเก็บอย่างถูกต้อง (SQL กับ NoSQL) หรือไม่
• ใช้แคชหรือไม่
• ไม่มีการร้องขอที่ไม่จำเป็นไปยัง FS หรือฐานข้อมูล?
• อัลกอริธึมการประมวลผลข้อมูลเหมาะสมหรือไม่?
• การตั้งค่าสภาพแวดล้อมเหมาะสมที่สุดหรือไม่: Apache/Nginx, MySQL/PostgreSQL, PHP/Python

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

มาตราส่วน

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

ความสามารถในการปรับขนาดมีสองประเภท: แนวตั้งและแนวนอน ความสามารถในการปรับขนาดในแนวตั้งหมายถึงการเพิ่มประสิทธิภาพแอปพลิเคชันโดยการเพิ่มทรัพยากร (CPU, หน่วยความจำ, ดิสก์) ภายในโหนดเดียว (โฮสต์) การปรับขนาดแนวนอนเป็นเรื่องปกติสำหรับแอปพลิเคชันแบบกระจายและหมายถึงการเพิ่มประสิทธิภาพแอปพลิเคชันโดยการเพิ่มโหนดอื่น

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

สถาปัตยกรรมประยุกต์

เว็บแอปพลิเคชันส่วนใหญ่จะเป็นแบบกระจายก่อน เนื่องจากสถาปัตยกรรมสามารถแบ่งออกเป็นอย่างน้อยสามชั้น: เว็บเซิร์ฟเวอร์ ตรรกะทางธุรกิจ (แอปพลิเคชัน) ข้อมูล (ฐานข้อมูล สแตติก)

แต่ละชั้นเหล่านี้สามารถปรับขนาดได้ ดังนั้น หากระบบของคุณมีแอปพลิเคชันและฐานข้อมูลอยู่ในโฮสต์เดียวกัน ขั้นตอนแรกควรแยกจากกันบนโฮสต์ที่ต่างกัน

คอขวด

ในการดำเนินการปรับขนาดของระบบ สิ่งแรกที่ต้องทำคือการพิจารณาว่าเลเยอร์ใดเป็น "คอขวด" กล่าวคือ ช้ากว่าส่วนที่เหลือของระบบ ในการเริ่มต้น คุณสามารถใช้ยูทิลิตี้เล็กน้อย เช่น top (htop) เพื่อประเมินการใช้ CPU/หน่วยความจำ และ df, iostat เพื่อประเมินการใช้ดิสก์ อย่างไรก็ตาม ขอแนะนำให้จัดเตรียมโฮสต์แยกต่างหากด้วยการจำลองโหลดการรบ (โดยใช้ AB หรือ JMeter) ซึ่งคุณสามารถสร้างโปรไฟล์แอปพลิเคชันโดยใช้ยูทิลิตี้ เช่น xdebug, oprofile และอื่นๆ คุณสามารถใช้ยูทิลิตี้เช่น pgFouine เพื่อระบุการสืบค้นฐานข้อมูลที่แคบได้ (แน่นอนว่าควรทำตามบันทึกจากเซิร์ฟเวอร์การต่อสู้)

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

การปรับขนาดฐานข้อมูล

ดังที่กล่าวไว้ข้างต้น คอขวดในแอพพลิเคชั่นสมัยใหม่มักเป็นฐานข้อมูล ปัญหาเกี่ยวกับมันมักจะแบ่งออกเป็นสองประเภท: ประสิทธิภาพและความจำเป็นในการจัดเก็บข้อมูลจำนวนมาก

คุณสามารถลดภาระงานบนฐานข้อมูลโดยแบ่งออกเป็นหลายโฮสต์ มีความยากลำบากในการซิงโครไนซ์ระหว่างกัน ซึ่งสามารถแก้ไขได้โดยการใช้โครงร่างหลัก/รองด้วยการจำลองแบบซิงโครนัสหรืออะซิงโครนัส สำหรับ PostgreSQL คุณสามารถใช้ Slony-I สำหรับการจำลองแบบซิงโครนัสและ PgPool-II หรือ WAL (9.0) สำหรับการจำลองแบบอะซิงโครนัส ในการแก้ปัญหาการแยกคำขออ่านและเขียน ตลอดจนสร้างสมดุลการโหลดระหว่างทาส คุณสามารถกำหนดค่าชั้นการเข้าถึงฐานข้อมูลพิเศษ (PgPool-II)

ความกังวลในการจัดเก็บข้อมูลจำนวนมากในกรณีของฐานข้อมูลเชิงสัมพันธ์สามารถแก้ไขได้โดยการแบ่งพาร์ติชั่น (“การแบ่งพาร์ติชั่น” ใน PostgreSQL) หรือโดยการปรับใช้ฐานข้อมูลบนฐานข้อมูลแบบกระจาย เช่น Hadoop DFS

คุณสามารถอ่านเกี่ยวกับโซลูชันทั้งสองได้ในหนังสือเกี่ยวกับการกำหนดค่า PostgreSQL ที่ยอดเยี่ยม

1.อย่างไรก็ตาม สำหรับการจัดเก็บข้อมูลจำนวนมาก ทางออกที่ดีที่สุดคือการแบ่งส่วน ซึ่งเป็นข้อได้เปรียบโดยธรรมชาติของฐานข้อมูล NoSQL ส่วนใหญ่ (เช่น MongoDB)

2. นอกจากนี้ ฐานข้อมูล NoSQL โดยทั่วไปจะทำงานได้เร็วกว่าพี่น้องตระกูล SQL เนื่องจากไม่มีโอเวอร์เฮดสำหรับการแยกวิเคราะห์/การปรับให้เหมาะสมของแบบสอบถาม การตรวจสอบความสมบูรณ์ของโครงสร้างข้อมูล ฯลฯ หัวข้อการเปรียบเทียบฐานข้อมูลเชิงสัมพันธ์และฐานข้อมูล NoSQL ก็ค่อนข้างกว้างขวางและสมควรได้รับ บทความแยกต่างหาก

3. สิ่งที่ควรค่าแก่การสังเกตต่างหากคือประสบการณ์ของ Facebook ซึ่งใช้ MySQL โดยไม่ต้องเลือก JOIN กลยุทธ์นี้ช่วยให้พวกเขาสามารถปรับขนาดฐานข้อมูลได้ง่ายกว่ามาก ในขณะที่ถ่ายโอนโหลดจากฐานข้อมูลไปยังโค้ด ซึ่งตามที่อธิบายไว้ด้านล่าง จะปรับขนาดได้ง่ายกว่าฐานข้อมูล

การปรับขนาดโค้ด

• ความซับซ้อนของรหัสการปรับขนาดขึ้นอยู่กับจำนวนทรัพยากรที่ใช้ร่วมกันที่โฮสต์ของคุณต้องการในการเรียกใช้แอปพลิเคชันของคุณ มันจะเป็นเพียงแค่เซสชันหรือคุณจะต้องแชร์แคชและไฟล์? ไม่ว่าจะด้วยวิธีใด สิ่งแรกที่ต้องทำคือการเรียกใช้สำเนาของแอปพลิเคชันบนหลายโฮสต์ที่มีสภาพแวดล้อมเดียวกัน
• ถัดไป คุณต้องตั้งค่าการโหลด/ร้องขอการปรับสมดุลระหว่างโฮสต์เหล่านี้ คุณสามารถทำได้ทั้งบน TCP (HAProxy), HTTP (nginx) หรือ DNS
• ขั้นตอนต่อไป Gearheart กล่าวถึงคือการทำให้ไฟล์สแตติก แคช และเซสชันเว็บแอปพลิเคชันพร้อมใช้งานในแต่ละโฮสต์ สำหรับเซสชัน คุณสามารถใช้เซิร์ฟเวอร์ที่ทำงานบนเครือข่ายได้ (เช่น Memcached) ในฐานะที่เป็นแคชเซิร์ฟเวอร์ การใช้ Memcached เดียวกันนั้นเป็นเรื่องที่สมเหตุสมผล แต่แน่นอนว่าบนโฮสต์อื่น
• ไฟล์สแตติกสามารถติดตั้งจากที่จัดเก็บไฟล์ที่แชร์บางส่วนผ่าน NFS/CIFS หรือใช้ FS แบบกระจาย (HDFS, GlusterFS, Ceph)

นอกจากนี้ยังสามารถจัดเก็บไฟล์ในฐานข้อมูล (เช่น Mongo GridFS) ซึ่งจะช่วยแก้ปัญหาความพร้อมใช้งานและความสามารถในการปรับขนาดได้ (โดยคำนึงถึงปัญหาการปรับขนาดฐานข้อมูล NoSQL ได้ด้วยการแบ่งกลุ่ม)

ประเด็นของการปรับใช้กับหลายโฮสต์ จะแน่ใจได้อย่างไรว่าผู้ใช้คลิก "อัปเดต" ไม่เห็นแอปพลิเคชันเวอร์ชันต่างๆ ทางออกที่ง่ายที่สุดในความคิดของฉันคือการแยกโฮสต์ที่ไม่ได้อัปเดตออกจาก config load balancer (เว็บเซิร์ฟเวอร์) และเปิดใช้งานตามลำดับเมื่อมีการอัปเดต คุณยังสามารถผูกผู้ใช้กับโฮสต์เฉพาะด้วยคุกกี้หรือ IP หากการอัปเดตจำเป็นต้องเปลี่ยนแปลงฐานข้อมูลอย่างมีนัยสำคัญ วิธีที่ง่ายที่สุดคือการปิดโครงการชั่วคราว