เมื่อใดที่เริ่มคิดเกี่ยวกับความยืดหยุ่น [ปิด]

ฉันมีปัญหาตลก แต่ก็แย่มาก ฉันกำลังจะเปิดตัวแอพ (iPhone) ใหม่ มันเป็นเกมแบบเล่นพร้อมกันหลายคนที่ทำงานบนแบ็คเอนด์ที่กำหนดเองของฉัน แต่ฉันกลัวที่จะเปิดตัว

ด้วยเหตุผลบางอย่างฉันคิดว่ามันอาจกลายเป็นสิ่งที่ยิ่งใหญ่และความนิยมของมันจะทำลายฐานข้อมูล MySQL + เซิร์ฟเวอร์เดี่ยวที่โดดเดี่ยวของฉัน

ในมือข้างหนึ่งฉันคิดว่าถ้ามันเพิ่มขึ้นฉันควรเตรียมพร้อมและมีโครงสร้างพื้นฐานที่ปรับขนาดได้แล้ว

ในทางกลับกันฉันแค่รู้สึกอยากจะนำมันออกไปสู่โลกและดูว่าเกิดอะไรขึ้น

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

ฉันชอบที่จะได้ยินความคิดเห็นเกี่ยวกับเรื่องนี้จากผู้เชี่ยวชาญหรือผู้ที่มีประสบการณ์เกี่ยวกับเรื่องนี้ ขอบคุณ!

จริงๆแล้วมันเป็นตัวเลือกที่ง่าย

ตอนนี้คุณมีผู้ใช้งานไม่มากและความสามารถในการปรับขยายนั้นไม่ใช่ปัญหา

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

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

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

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

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

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

สมมติว่าเซิร์ฟเวอร์ของคุณมีการเรียงลำดับของ web-based interface บางอย่างที่คุณสามารถจำลองมากของผู้ใช้โดยใช้เครื่องมือเช่นApache JMeter เรียนรู้วิธีการใช้เครื่องมือจากนั้นเริ่มทดสอบความเครียดด้านหลังของคุณ คุณควรจะเรียนรู้ได้มากพอที่จะรู้ว่าขีด จำกัด ของระบบของคุณคืออะไร จากนั้นคุณสามารถรวมข้อมูลนั้นกับจำนวนผู้ใช้ที่คุณมีและจำนวนเฉลี่ยที่ทำงานในครั้งเดียวเพื่อตัดสินใจว่าจะขยายเวลาเมื่อใด

TL; DRคุณควรคิดถึงความสามารถในการปรับขยายได้ก่อนที่จะเขียนโค้ดบรรทัดแรก

สิ่งแรกก่อน Scalabilty! = การเพิ่มประสิทธิภาพ

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

• ตรวจสอบให้แน่ใจว่ามีการเขียนโค้ดเพื่อปรับขนาด ฉันเคยเห็นโครงงานมากมายที่ไม่ต้องคิดเพิ่ม ผลลัพธ์เป็นโค้ดเบสที่จะไม่ขยายขนาดโดยไม่คำนึงถึงฮาร์ดแวร์ที่คุณขว้างมาหรือมีราคาแพงในการขยาย
• กำหนดกลยุทธ์การขยายของคุณ มีแผนเกี่ยวกับวิธีการสนับสนุนผู้ใช้ทั้งหมด คุณมีฐานข้อมูล MySQL, คุณจะทิ้งมันหรือทำคลัสเตอร์หรืออย่างอื่น กลยุทธ์เช่น sharding ต้องใช้ความสุขุมเพราะวางข้อกำหนดในสถาปัตยกรรม การรวมกลุ่มน้อยลง คุณสนับสนุนเซสชันหรือไม่และเซสชันจะตอบสนองอย่างไรกับเซิร์ฟเวอร์ส่วนหน้าหลายเครื่อง คุณจะต้องใช้เซสชันที่ติดหนึบในตัวโหลดบาลานเซอร์ของคุณหรือไม่
• คิดออกกลยุทธ์การใช้งาน คุณจะใช้ AWS เพื่อปรับขนาด คุณสามารถใช้ประโยชน์จากผลิตภัณฑ์หรือบริการใด ๆ ที่ทำให้คุณสามารถขยายขอบเขตแบบไดนามิกได้หรือไม่? นอกจากนี้ยังเกี่ยวข้องกับการทำความเข้าใจค่าใช้จ่ายของคุณ

แต่ดูเหมือนว่าคุณมี codebase อยู่แล้ว คำถามตอนนี้คือเมื่อใดที่จะเริ่มปรับขนาด สิ่งนี้ขึ้นอยู่กับรหัสของคุณอย่างสมบูรณ์

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

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

ในตำแหน่งของคุณฉันอาจปล่อยเป็น "เบต้า" และจัดการความคาดหวังของผู้ใช้ ด้วยวิธีนี้ฉันจะเอาผลิตภัณฑ์ออกมาและดูว่ามันแผ่ออกไปอย่างไร

ดังนั้นมีสองครั้งที่คุณควรคิดเกี่ยวกับความยืดหยุ่น

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

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

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

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

จากคำอธิบายของคุณดูเหมือนว่ามีสองผลลัพธ์ที่เป็นไปได้:

• เกมดังกล่าวล้มเหลวและคุณไม่สนใจ
• เกมนี้ประสบความสำเร็จและแบ็กเอนด์ของคุณจะไม่สามารถจัดการกับภาระได้และผลลัพธ์จะล้มเหลว

อืมม

นี่คือคำถามที่ถามตัวเอง:

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

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

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

อย่างน้อยทำการทดสอบโหลดเฉพาะกิจตามที่อธิบายโดยไบรอัน

วิธีการที่รุนแรงมากขึ้น

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

จากนั้นก้าวแรกของการปรับให้เหมาะสม ตัดสินใจเลือก SLA สำหรับเซิร์ฟเวอร์ของคุณ: เช่นการโทร 10% ที่แย่ที่สุดด้วยเวลาแฝงที่น่ารำคาญและ 1% การโทรด้วยเวลาแฝงที่ใช้ไม่ได้ ด้วยข้อ จำกัด เหล่านี้คุณสามารถใช้การทดสอบโหลดเพื่อค้นหาจำนวนผู้ใช้ที่เซิร์ฟเวอร์ของคุณสามารถรองรับได้

การทดสอบทรูพุตอย่างแท้จริงโดยไม่ต้องวัดเวลาแฝง (หรืออย่างน้อยที่สุดด้วยตนเองโดยใช้เซิร์ฟเวอร์ในระหว่างการทดสอบโหลด) นั้นไม่มีประโยชน์เพราะมันไม่ได้บอกคุณว่าตัวเลขปริมาณงานที่วัดได้ส่งผลให้ผู้ใช้ได้รับประสบการณ์

การนำเสนอที่ดีมากเกี่ยวกับการวัดเวลาในการตอบสนองโดย Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

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

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

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