ใช้ Magento ในสภาพแวดล้อม AWS

โฮสติ้งวีโอไอพีอย่างที่ทุกคนรู้ไม่เหมือนการโฮสต์แอพพลิเคชั่น PHP อื่น ๆ เป็นไปได้อย่างไรที่จะใช้ Magento ในสภาพแวดล้อมของ Amazon Web Services ในปี 2013

การผสมผสานบริการ AWS แบบใดที่ใช้งานได้ดีกับ Magento ระดับอัจฉริยะสำหรับร้านค้า "run of the mill" คืออะไร (ใช่ฉันรู้ว่าไม่มีร้านค้าโรงงาน)

ควรหลีกเลี่ยงอันไหน (EBS?)

เคล็ดลับกลวิธีกลยุทธ์การปรับใช้เพื่อหลีกเลี่ยงความเจ็บปวดหลายสัปดาห์ในการตั้งค่านี้

ฉันกำลังโฮสต์ Magento บน AWS ในปี 2011 จนถึง 2013 หลาย ๆ สิ่งที่คุณได้รับจากการใช้โครงสร้างพื้นฐานคลาวด์แทนที่จะเป็นโฮสติ้งแบบดั้งเดิมหรือแบบโฮสติ้งที่แชร์กันนั้นมีความเกี่ยวข้องมากขึ้นภายใต้หัวข้อ DevOps ซึ่งไม่ได้ จำกัด เฉพาะ AWS การใช้งาน

• การควบคุมการวางแผนกำลังการผลิตของคุณอย่างสมบูรณ์และยืดหยุ่น - ขยายขอบเขตกิจกรรมทางการตลาดเปิดใช้งานการจัดเตรียมแบบไดนามิกผ่าน Elastic Beanstalk ลดขนาดในช่วงที่มีปริมาณน้อยหมุนไซต์ในสองสามสัปดาห์ฉีกมันทิ้งแล้วโยนทิ้งไป
• ติดตั้งสภาพแวดล้อม dev / ทดสอบ / การจัดเตรียมได้อย่างง่ายดายและทำซ้ำการเปลี่ยนแปลงระหว่างกัน
• โฮสต์หน้าผู้ดูแลระบบของคุณบนโฮสต์อื่น
• ใช้ DynamoDB สำหรับการจัดการเซสชั่นและ ElastiCache สำหรับแคชโดยไม่มีค่าใช้จ่ายในการดำเนินการเพิ่มเติมระวัง ElastiCache ไม่ทำงานใน VPC ในขณะนี้
• ใช้ ELB สำหรับการทำโหลดบาลานซ์ แต่ระวังถ้าคำขอใช้เวลานานกว่า 60 วินาทีพวกเขาจะถูกยกเลิกอย่างไม่สุภาพ
• ใช้ AmazonSES เพื่อส่งอีเมล (ตอนนี้ง่ายยิ่งขึ้นผ่านทาง SMTP ทั่วไป) แม้ว่าจะยังมีช่องว่างในเครื่องมือสำหรับการติดตามการตีกลับ / การร้องเรียน
• ใช้ AmazonS3 สำหรับโฮสต์สื่อและ Cloudfront สำหรับ CDN
• ลดค่าใช้จ่ายในการดำเนินงานสำหรับกิจกรรมฐานข้อมูลผ่าน RDS ซึ่งมีคุณสมบัติในการคืนค่าเวลา, failover อัตโนมัติ, การสำรองข้อมูลอัตโนมัติและการอัพเกรดอัตโนมัติ
• การจัดการ DNS นั้นง่ายมากใน Route53 แต่โดยทั่วไปแนะนำเพื่อความสะดวกในการจับคู่โดเมนย่อยเพื่อโหลดบาลานเซอร์
• VPC จะทำให้เครื่องทั้งหมดของคุณอยู่ในเครือข่ายส่วนตัวของตัวเองเพื่อให้สามารถควบคุมได้ละเอียดยิ่งขึ้นและเปิดเผยการเข้าถึงตามที่คุณเห็นว่าเหมาะสมผ่านอุโมงค์ VPN ของคุณเอง
• ตัวชี้วัดประสิทธิภาพที่ง่ายและการแจ้งเตือน (นอกเหนือจากการใช้หน่วยความจำและการใช้ดิสก์) ผ่าน CloudWatch & SNS

การปล่อยน้อยที่สุดจะเป็น 1 ELB, 2 EC2 webservers แยก AZs, 1 multi-az RDS, Route53 โฮสต์โซนสำหรับโดเมน เริ่มแรกคุณสามารถใช้เซสชันที่ติดหนึบบน ELB เพื่อให้การจัดการเซสชันง่ายขึ้น แต่เมื่อปริมาณการใช้เพิ่มขึ้นคุณจะต้องย้ายสื่อไปยัง CDN (S3 & CloudFront) และปิดเซสชันของเครื่องแต่ละเครื่อง

พื้นที่ที่ฉันยังไม่ได้ดู แต่ยังมีแนวโน้ม: สคริปต์ CloudFormation สำหรับการปรับใช้ Magento stack ได้ง่ายขึ้นการสร้างคำสั่งการถ่ายสินค้าผ่าน DynamoDB และคิวผู้ปฏิบัติงานเพื่อการชำระเงินที่รวดเร็วยิ่งขึ้น (มีคนเริ่มโครงการนี้แล้ว เมื่อเร็ว ๆ นี้) และตั้งค่าการแสดงตนหลายภูมิภาคผ่านการกำหนดเส้นทางตามเวลาแฝงด้วย Route53

ฉันคิดว่าฉันเป็นผู้เผยแพร่ศาสนาสำหรับกลุ่มเมฆ เฉพาะ AWS, c3. large เป็นขนาดอินสแตนซ์ที่เหมาะสมสำหรับ webservers ที่ใช้งานจริง แต่ฉันจะเริ่มด้วยขนาดที่เล็กที่สุดของคลาสอินสแตนซ์แต่ละคลาสและวัดประสิทธิภาพและขยายขนาดหรือเพิ่มประสิทธิภาพโค้ดตามที่คุณเห็นว่าเหมาะสมxhguiอย่างต่อเนื่อง

นี่คือวิธีที่เราทำกับเว็บช็อป Angrybirds:

การนำเสนอภาษาอังกฤษที่ Magento Imagine 2012

การนำเสนอภาษาเยอรมันที่ Meet Magento # 6.12

ภาษาเยอรมันปัจจุบัน "PHP Magazin" มีบทความ 6 หน้า (ภาษาเยอรมัน) พร้อมรายละเอียดบางอย่าง

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

สิ่งเดียวที่ฉันจะเพิ่มให้กับแนวคิดหลักในการนำเสนอคือความก้าวหน้าที่ทันสมัยในเทคโนโลยี AWS / คู่แข่งจะแนะนำการปรับแต่งบางอย่าง ... เช่นความจริงที่ว่า Cloudfront สนับสนุน gzip สำหรับการปรับปรุงประสิทธิภาพของ CDN ในขณะนี้แม้ว่าจะไม่เร็วเท่าหรือ จะให้การเลิก SSL ฟรีกับคุณเช่นเดียวกับข้อเสนอของCloudFlare Route 53 DNS ของพวกเขายังไม่เร็วหรือมีฟีเจอร์มากมายเช่นเดียวกับ CloudFlares และ AWS ก็มี Web Application Firewall หรือการป้องกัน DDOS ที่เทียบเท่ากันทั้งหมดนี้รวมอยู่ในข้อเสนอ CloudFlare ...

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

สรุปแนวคิดหลัก :

1. รู้ถึงปัญหาคอขวดของคุณอย่างใกล้ชิดและปรับปรุงให้เหมาะสม แต่ละระดับของสแต็กมีคอขวดเฉพาะ (แบนด์วิดท์, cpu, ฐานข้อมูล) และการแก้ปัญหาคอขวดในแต่ละชั้นต้องการโซลูชันที่แตกต่างกันที่ปรับให้เหมาะกับความท้าทายแต่ละอย่างโดยเฉพาะแม้ว่าการแคชจริง ๆ

2. แคชทุกสิ่ง : ใช้ประโยชน์จากระบบ AWS หากเป็นไปได้ (Elasticache สำหรับการแคชข้อมูล Redis / Memcache, Cloudfront สำหรับการแคชอิมเมจ, js และ css สินทรัพย์ใกล้กับผู้ใช้ปลายทางผ่าน CDN) และวานิชเพื่อเร่งการตอบสนองของอินสแตนซ์เซิร์ฟเวอร์ระดับสินทรัพย์ ร้องขอการแคชจาก CDN นอกจากนี้อย่าลืมบีบอัดข้อมูลให้เล็กสุดในระบบการปรับใช้ของคุณก่อนที่จะปรับใช้กับ CDN

3. การแปลงสัญญาณอัตโนมัติเป็นสิ่งสำคัญ : ความต้องการเปลี่ยนแปลงบ่อยและเร็วกว่าที่คุณสามารถตรวจสอบและตอบสนองด้วยตนเอง การปรับตัวให้เข้ากับการเปลี่ยนแปลงแบบเรียลไทม์นั้นจำเป็นต้องใช้เครื่องมืออัตโนมัติที่มีอยู่ใน AWS เช่นกลุ่มปรับขนาดอัตโนมัติเพื่อหมุนชิ้นส่วนของระบบที่เหมาะสมที่สุดสำหรับงานนี้ AWS จัดการสิ่งนี้อย่างโปร่งใสสำหรับ CloudFront CDN, Route 53 DNS, Elastic Load Balancer และ S3 Buckets คุณต้องจัดการโดยปรับขนาดและปรับขนาดอัตโนมัติสำหรับอินสแตนซ์ของ EC2 และเพียงปรับขนาด / ปรับแต่งสำหรับชั้น RDS และ Elasticache

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

5. แต่จริงๆแล้วมันก็เป็นไปไม่ได้หากไม่มีการทดสอบระบบอัตโนมัติ : ด้วยชิ้นส่วนที่เคลื่อนไหวได้นี้จะมีบางสิ่งบางอย่างแตกหักเกือบจะเปลี่ยนแปลง และคุณจะต้องเปลี่ยนเพื่อให้ทันกับการพัฒนาใน Magento และ AWS และสิ่งเหล่านั้นจะเกิดขึ้นบ่อยครั้ง ดังนั้นเพื่อลดค่าใช้จ่ายในการเปลี่ยนแปลงให้น้อยที่สุดการทดสอบทุกรูปแบบจำเป็นต้องมีทั้งการใช้งานและแบบอัตโนมัติอย่างเต็มรูปแบบตั้งแต่การทดสอบแบบหน่วยการทดสอบแบบบูรณาการไปจนถึงการทดสอบการทำงานที่ใช้ซีลีเนียม ตอนนี้คุณดีใจที่คุณเป็นแบบอัตโนมัติทุกขั้นตอนการปรับใช้ใช่ไหม

โซลูชันที่เรียบง่ายกว่า (!) เพียงแค่ติดตั้งเช่นเดียวกับ VPS อื่น ๆ ฉันได้รับการเสนอภาพฟรีสำหรับไม่กี่ปีนี้ ... เมื่อเร็ว ๆ นี้ผมได้ความเข้มข้นในซิดนีย์ใหม่ DC เพราะมันเป็นท้องถิ่น - รายละเอียดเพิ่มเติมได้ที่http://www.greengecko.co.nz/magento_on_amazon_ec2ถ้าคุณ เราสนใจสิ่งนั้น ความเจ็บปวดเป็นศูนย์เริ่มต้นเพียงคลิกเดียวและคุณอยู่ที่นั่น ชี้เบราว์เซอร์ของคุณที่อินสแตนซ์สำหรับรายละเอียดเพิ่มเติม สิ่งนี้จะทำให้เป็นจุดเริ่มต้นที่ดี - แต่มองหาและแก้ไข /etc/rc.local หากคุณต้องการสร้างมัน

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

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

เมื่อคุณได้เรียงลำดับแล้วมันก็ใช้ได้ ความต้องการที่จะทำงานใน VPC ถ้าคุณต้องการ> 1 ที่อยู่ IP นั้นน่ารำคาญจริงๆ (โดยเฉพาะถ้าคุณไม่ตระหนักถึงสิ่งนี้เมื่อคุณเริ่มต้น!) และ gotcha เท่านั้นที่คุณจะเจอ

มันง่ายที่จะขยายแพลตฟอร์ม 'ในทันที' - ในที่สุดคอขวดเดียวจะกลายเป็นจำนวนพลังการประมวลผลที่มีให้กับ PHP (ไม่มีโค้ดที่ไม่มีประสิทธิภาพ! จำเป็น

สนุก!

สตีฟ

เรากำลังเรียกใช้ RDS หลาย AZ เซิร์ฟเวอร์สองตัวที่ปรับให้เหมาะสมของ NGINX, เซิร์ฟเวอร์วานิช 2 ตัว + ELB และบนเซิร์ฟเวอร์วานิชเดียวกัน (พอร์ตอื่นไปยังวานิช) SSL Nginx เราใช้ Elasticache และในไม่ช้าเราจะรวม DynamoDB สำหรับการจัดการเซสชันของ Magento เราใช้ S3 และ Cloudfront ด้วย

ฉันมีการแชทที่น่าสนใจกับ บริษัท โฮสติ้งจากสหราชอาณาจักรเรามีเซิร์ฟเวอร์£ 700 ต่อเดือนด้วย สิ่งที่พวกเขาทำคือกระดานชนวน Amazon AWS ด้วยการตั้งค่าและการเพิ่มประสิทธิภาพที่ถูกต้องในทุกพื้นที่รวมถึงการถอด Magento กลับ, ปิดการใช้งานโมดูล, ฟังก์ชั่นการนับหมวดหมู่และอื่น ๆ

ขณะนี้เราสามารถรับชมได้ 2,400-3,000 ครั้งต่อวินาทีในหน้าบ้านหมวดหมู่ผลิตภัณฑ์และหน้า CMS (หน้าวานิช) ไม่ใช่วานิชเพจเราสามารถประมวลผลคำขอ 400 - 500 ต่อวินาทีขึ้นอยู่กับร้านค้า ตอนนี้เรากำลังใช้ RDS Multi พร้อมอ่าน

นอกจากนี้เรายังวาง Magento Admin บนโหนดของตัวเองเพื่อเรียกใช้ crons และดูแลการรับส่งข้อมูล http://administraton.mymagestore.com/admin

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

คุณสามารถใช้บริการ AWS พื้นฐานเกือบทั้งหมดเพื่อให้วีโอไอพีของคุณทำงานได้ ฉากที่ง่ายที่สุดคือการใช้ EC2 กับ Elastic IP และ AWS VPC สำหรับการกำหนดค่าความปลอดภัย

วิธีที่ชาญฉลาดคือการปรับใช้เซิร์ฟเวอร์ 2 ตัว: เว็บเซิร์ฟเวอร์ + ฐานข้อมูล เว็บเซิร์ฟเวอร์รวม Magento + Nginx + PHP + แบ็กเอนด์แคช (Redis หรือ APC เป็นตัวเลือกที่ดี) และเซิร์ฟเวอร์ MySQL แยกต่างหากในซับเน็ตเดียวกัน เซิร์ฟเวอร์เหล่านี้สามารถมองเห็นซึ่งกันและกันผ่าน IP ส่วนตัวในเครือข่ายส่วนตัว (กำหนดค่าผ่าน VPC) Nginx เป็นเว็บเซิร์ฟเวอร์ที่เลือกทันทีที่สามารถส่งไฟล์คงที่เร็วสุด

เซิร์ฟเวอร์ฐานข้อมูล shoud ถูกซ่อนจากการเข้าถึงใด ๆ เว็บเซิร์ฟเวอร์จะปรากฏบนพอร์ต 80 และ 443 เป็นไปได้ที่จะจัดสรร Elastic IP ให้กับเว็บเซิร์ฟเวอร์ หลังจากนั้นจะมีประโยชน์ในการกำหนดค่า DNS (เช่นผ่าน AWS Route 53) หรือการทำโหลดบาลานซ์ของ AWS

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