Uruchamianie Magento w środowisku AWS

54

Hosting Magento, jak wszyscy wiedzą, nie przypomina hostowania innych aplikacji PHP. Jak wykonalne jest uruchomienie Magento w środowisku Amazon Web Services w 2013 roku?

Jakie magiczne połączenie usług AWS ma sens w przypadku Magento? Jakie poziomy są inteligentnymi ustawieniami domyślnymi dla sklepu z „uruchomieniem młyna”? (tak, wiem, nie ma sklepów młynów)

Których (EBS?) Należy unikać?

Jakieś wskazówki, porady, strategie wdrażania, aby uniknąć tygodni bólu podczas konfigurowania?

Alan Storm
źródło

Odpowiedzi:

44

Prowadziłem Magento na AWS w 2011 r. Do 2013 r. Wiele rzeczy, które zyskujesz na korzystaniu z infrastruktury chmurowej zamiast tradycyjnego hostingu dedykowanego lub współdzielonego, bardziej szczegółowo opisano w temacie DevOps, które nie są wyłączne dla AWS, ale są łatwiej dostępne dzięki jego użycie.

  • Pełna i elastyczna kontrola planowania wydajności - zwiększaj skalę przed wydarzeniami marketingowymi, umożliwiaj dynamiczne udostępnianie za pomocą Elastic Beanstalk, zmniejszaj zakres w okresach niskiej głośności, rozwijaj witrynę w ciągu kilku tygodni, zburz ją i wyrzuć.
  • Łatwo konfiguruj środowiska programistyczne / testowe / pomostowe i replikuj zmiany między nimi.
  • Hostuj strony administracyjne na osobnym hoście.
  • Używaj DynamoDB do zarządzania sesjami i ElastiCache do buforowania bez ponoszenia dodatkowych kosztów operacyjnych, uważaj jednak ElastiCache obecnie nie działa w VPC.
  • używaj ELB do równoważenia obciążenia, ale uważaj, jeśli żądania zajmą więcej niż 60 sekund, zostaną one nieakceptowane zakończone
  • Używaj AmazonSES do wysyłania e-maili (teraz jeszcze łatwiejsze dzięki zwykłemu SMTP), chociaż nadal istnieją luki w narzędziach do śledzenia odrzuceń / skarg
  • Użyj AmazonS3 do hostowania multimediów i Cloudfront dla CDN.
  • Niższy koszt operacji dla bazy danych za pośrednictwem RDS, który oferuje przywracanie w czasie, automatyczne przełączanie awaryjne, automatyczne kopie zapasowe i automatyczne aktualizacje.
  • Zarządzanie DNS jest bardzo łatwe w Route53, ale ogólnie zalecane w celu ułatwienia mapowania poddomen w celu równoważenia obciążenia.
  • VPC, aby umieścić wszystkie maszyny w swojej prywatnej sieci, aby mieć bardziej szczegółową kontrolę i ujawnić dostęp według własnego uznania za pośrednictwem własnych tuneli VPN.
  • Łatwe pomiary wydajności i ostrzeganie (oprócz użycia pamięci i użycia dysku) za pośrednictwem CloudWatch i SNS

Minimalny ślad to 1 ELB, 2 serwery EC2 w osobnych sieciach AZ, 1 RDS z wieloma serwerami az, strefa hostowana Route53 dla domeny. Początkowo możesz używać lepkich sesji na ELB, aby uprościć zarządzanie sesjami, ale wraz ze wzrostem ruchu będziesz chciał przenieść media do CDN (S3 i CloudFront) i sesje poza poszczególnymi komputerami.

Obszary, których nie szukałem, ale wciąż są obiecujące: skrypty CloudFormation ułatwiające wdrażanie stosu Magento, odciążanie tworzenia zamówień za pośrednictwem DynamoDB i kolejki robocze w celu zwiększenia przepustowości transakcji (ktoś już rozpoczął projekt, aby to zrobić za pośrednictwem MongoDB na jednym z hackathonów ostatnio) i konfigurowanie obecności w wielu regionach za pomocą routingu opartego na opóźnieniu za pomocą Route53.

Chyba jestem ewangelistą chmury. Specyficzne dla AWS, c3.large są przyzwoitym rozmiarem instancji dla produkcyjnych serwerów WWW, ale zacznę od najmniejszej z każdej klasy instancji i zmierzę wydajność i skaluję lub optymalizuję kod według własnego uznania, dlatego polecam wszystkim xhgui stale.

Ralph Tice
źródło
Sugerowałbym raczej nie używać RDS dla bazy danych. Magento nie ma żadnej kontroli nad optymalizacją serwera. Istnieje biała księga, którą Magento opublikował na temat strojenia stosu, który pokazuje szczegóły dotyczące strojenia MySql. Zasadniczo, jeśli planujesz skalować lub oczekujesz maksymalnej prędkości, musisz uruchomić własny serwer bazy danych.
davidalger
3
@davidalger Przepraszamy, ale to okropna rada. Musisz przeczytać o grupach parametrów bazy danych i ich wykorzystaniu. aws.amazon.com/rds/faqs/#34 Ponadto, buforowanie lub optymalizacja kodu przynoszą znacznie większy wzrost wydajności niż cokolwiek, co można zrobić z bazą danych, chyba że koncentrujesz się całkowicie na procesach kasowych, w takim przypadku powinieneś github.com/magento-hackathon/MongoDB-OrderTransactions
Ralph Tice
3
Z pewnością skorzystałbym z RDS. Co najwyżej tracisz możliwość tworzenia funkcji systemowych, to wszystko. Jest wysoce zoptymalizowany, wysoce dostępny i można rozpędzić repliki za pomocą kilku kliknięć. Korzyści znacznie przewyższają wszelkie potencjalne wady.
philwinkle
Co z EBS (Block Storage)? Dlaczego nie uwzględniłeś tego również w konfiguracji? Jaki jest zalecany sposób synchronizacji katalogu multimediów w wielu EC2?
Dayson
1
@Dayson Dobre pytanie. Magento jest dość ciężkie we / wy, nawet podczas delegowania zarządzania sesjami i pamięcią podręczną do systemów buforowania pamięci. Dlatego warto rozważyć EBS. Obecnie nie korzystamy z AWS, ale działamy w naszym środowisku Magento na stosie o wysokim dostępie z równoważeniem obciążenia, w którym miałbyś ten sam problem z pamięcią CMS jak katalog / media. 2 miesiące temu zamontowaliśmy NFS na naszych serwerach WWW i dowiązaliśmy symbolicznie nasze katalogi / home / user (gdzie przechowywane są wszystkie dane internetowe) do tego punktu montowania. Z POV użyteczności jest genialny. Jeśli chodzi o wydajność, może nadal używać drobnych poprawek.
Jaap Haagmans
30

Oto jak to robimy dla sklepu internetowego Angrybirds:

Angielska prezentacja na Magento Imagine 2012.

Niemiecka prezentacja na Meet Magento # 6.12

Obecny niemiecki „PHP Magazin” ma także 6-stronicowy artykuł (w języku niemieckim) z pewnymi szczegółami

Po przeczytaniu wszystkich prezentacji Fabrizio połączonych wielokrotnie powyżej, myślę, że ta odpowiedź jest naprawdę najlepsza, choć zgadzam się, że mogłaby użyć więcej wyjaśnień i wyciągnąć kluczowe pomysły z prezentacji (zwłaszcza, że ​​pierwszy link już miał do czasu opublikowania tej aktualizacji było 404).

Jedyne, co chciałbym dodać do kluczowych pojęć w prezentacjach, to to, że nowoczesne postępy w technologiach AWS / konkurenta sugerują pewne poprawki ... jak na przykład fakt, że Cloudfront obsługuje teraz gzip dla poprawy wydajności CDN, chociaż nie jest tak szybki jak i daje to bezpłatne zakończenie SSL, takie jak oferty CloudFlare . Ich DNS trasy 53 nie jest tak szybki ani bogaty w funkcje jak CloudFlares, a AWS nie ma porównywalnej zapory sieciowej ani ochrony DDOS, z których wszystkie są zawarte w ofercie CloudFlare ...

Istnieje kilka innych możliwych sposobów ulepszenia oryginalnej prezentacji Fabrizio, ale nie byłbym dobrym konsultantem, gdybym rozdawał WSZYSTKO, co znałem na każdym stanowisku StackExchange, na które odpowiadałem, prawda? Ponadto niektóre z najnowszych ofert znacznie zmieniłyby sugestie w oryginalnych prezentacjach, z których wszystkie STILL oferują świetną wydajność, nawet jeśli można by wycisnąć więcej z AWS przy użyciu różnych opcji.

Podsumowanie kluczowych pojęć :

  1. Poznaj swoje wąskie gardła : i odpowiednio zoptymalizuj. Każda warstwa stosu ma określone wąskie gardła (przepustowość, procesor, baza danych), a rozwiązanie wąskich gardeł na każdej warstwie wymaga innego rozwiązania zoptymalizowanego dla każdego konkretnego wyzwania, chociaż tak naprawdę buforowanie jest wspólnym elementem na każdym poziomie, co prowadzi do ...

  2. Cache All The Things : Wykorzystaj systemy AWS tam, gdzie to możliwe (Elasticache do buforowania danych typu Redis / Memcache, Cloudfront for Caching obraz, zasoby js i css najbliższe użytkownikom końcowym za pośrednictwem CDN) i Varnish do przyspieszenia odpowiedzi instancji serwera na początkowy poziom zasobów żądania buforowania z CDN. Pamiętaj też, aby skompresować i zminimalizować w swoich systemach wdrażania PRZED wdrożeniem w sieciach CDN

  3. Automatyczne skalowanie jest niezbędne : Zapotrzebowanie zmienia się często i szybciej niż można monitorować i reagować ręcznie. Dostosowanie się do tych zmian w czasie rzeczywistym wymaga użycia narzędzi automatyzacji dostępnych w AWS, takich jak Grupy skalowania automatycznego, aby rozdzielić elementy systemu, które najlepiej nadają się do tego zadania. AWS obsługuje to w sposób transparentny dla CloudFront CDN, Route 53 DNS, Elastic Load Balancers i S3 Buckets, musisz sobie z tym poradzić, dostosowując rozmiar i automatyczne skalowanie dla instancji EC2, a po prostu dostosowując rozmiar / strojenie dla poziomów RDS i elasticache

  4. Automatyzacja jest jedynym sposobem skutecznego powiązania tego wszystkiego : przy tak wielu powiązanych ze sobą komponentów, z których niektóre muszą zostać zainicjowane w czasie wdrażania, niektóre bezpośrednio po wdrożeniu, zarządzanie systemem dostrojonym pod kątem optymalnej wydajności wymaga automatyzacji. Wykorzystanie wdrożenia i automatyzacji systemów w celu czyszczenia pamięci podręcznej, ocieplania pamięci podręcznej, przetwarzania obrazu itp. To jedyny rozsądny sposób zarządzania wieloma różnymi podsystemami i utrzymywania ich naoliwionej i wolnej od problemów.

  5. Ale tak naprawdę nawet to nie jest możliwe bez automatyzacji testów : przy tak wielu ruchomych częściach coś pęknie przy prawie każdej zmianie. Będziesz musiał się zmienić, aby nadążać za rozwojem Magento i AWS. I tak się stanie CZĘSTO . Aby zminimalizować koszty zmian, wszystkie formy testowania muszą być zarówno wdrożone, jak i zautomatyzowane w pełni - od testów jednostkowych przez testy integracyjne po oparte na Selenium testy funkcjonalne rzeczywistej lokalizacji uruchomione w rzeczywistych konfiguracjach testowych, które naśladują środowisko produkcyjne. Teraz NAPRAWDĘ cieszysz się, że zautomatyzowałeś wszystkie procesy wdrażania, prawda?

fbrnc
źródło
2
głosowanie za bycie wiązką linków
Ralph Tice
9
@RalphTice Mógłbym być tutaj w mniejszości, ale wiele linków jest w porządku, szczególnie gdy są one tak istotne jak fbmc. Nie wszyscy chcą umieszczać swoje treści w domenie publicznej / creative-commons, upuszczając je w odpowiedzi StackExchange.
Alan Storm
4
@AlanStorm Nie mam na myśli, że wszyscy powinni głosować za odrzuceniem, ponieważ jest to garść linków, ale po prostu wyjaśniam, dlaczego zdecydowałem się głosować za darmo. Wolę dostawać treść niż linki do treści, gdy wchodzę na stronę SE, i używam SE, aby w szczególności unikać treści wideo i treści w języku innym niż angielski.
Ralph Tice
3
Samotny link jest uważany za kiepską odpowiedź (patrz często zadawane pytania ), ponieważ sam w sobie jest bez znaczenia, a zasoby docelowe nie są gwarantowane w przyszłości . Lepiej byłoby zawrzeć tutaj istotne części odpowiedzi i podać odnośnik.
j0k
2
Pierwszy link wydaje się już nie istnieć. Prawdopodobnie może to zastąpić: slideshare.net/aoemedia/angrybirds-magento-cloud-deployment
ermannob
4

Nieco prostszym (!) Rozwiązaniem jest instalacja, tak jak na każdym innym VPS. Od kilku lat oferuję darmowy obraz ... ostatnio skoncentrowałem się na nowym Sydney DC, ponieważ jest lokalny - więcej szczegółów na http://www.greengecko.co.nz/magento_on_amazon_ec2, jeśli są tym zainteresowani. Praktycznie zero bólu na początek - jedno kliknięcie i jesteś tam. Skieruj przeglądarkę na instancję, aby uzyskać więcej informacji. To będzie dobry punkt wyjścia - ale zajrzyj i zmodyfikuj /etc/rc.local, jeśli zamierzasz na nim bazować.

Ważne jest, aby zdać sobie sprawę, że instancje są dość słabo zasilane. Oczywiście włożenie dużej ilości pieniędzy w aplikację poprawia to, ale nawet dla umiarkowanie małego sklepu internetowego średnia instancja jest absolutnym minimum, aby uzyskać wiele rdzeni, a naprawdę duża jest najmniejsza niezbędna.

Ponadto pamięć Amazon jest wolna. Z tego powodu jeszcze ważniejsze niż zwykle jest dostarczanie wszystkiego, co możliwe, z pamięci: strojenie baz danych, pamięci podręcznych zabezpieczonych pamięcią itp. Jest niezbędne.

Gdy już to posortujesz, wszystko będzie dobrze. wymóg uruchomienia w VPC, jeśli chcesz> 1 adres IP, jest naprawdę denerwujący (szczególnie, jeśli nie zdajesz sobie z tego sprawy, kiedy zaczynasz!), i naprawdę jedyny problem, z którym się spotkasz.

Łatwo jest rozwinąć platformę „w locie” - ostatecznie jedynym wąskim gardłem staje się ilość mocy obliczeniowej dostępnej dla PHP (nieefektywny kod!), A jednoczesne uruchamianie wielu „silników” jest prawdopodobnie najprostszą opcją - włączenie dodatków do Internetu, gdy niezbędny.

Cieszyć się!

Steve

Steve Holdoway
źródło
VPC jest teraz domyślnie dla nowych kont AWS. aws.typepad.com/aws/2013/03/…
Ralph Tice
4

Pracujemy na RDS Multi AZ, dwóch zoptymalizowanych serwerach NGINX, 2 serwerach lakierniczych + ELB i na tych samych serwerach lakierniczych (inny port niż lakier) SSL Nginx. Używamy Elasticache i bardzo szybko integrujemy DynamoDB do zarządzania sesjami Magento. Używamy również S3 i Cloudfront.

Miałem interesującą rozmowę z brytyjską firmą hostingową, z którą mamy serwer za 700 £ miesięcznie. Wszystko, co robią, to łupek Amazon AWS. Z prawidłową konfiguracją i optymalizacją we wszystkich obszarach, w tym z usuwaniem Magento, wyłączaniem modułów, funkcją zliczania kategorii itp. Itp. (Dostroiliśmy NGINX i serwery lakiernicze, aby siedzieć przed serwerem bazy danych, który równoważy obciążenie).

Obecnie możemy uzyskiwać 2400 - 3000+ odwiedzin na sekundę na stronach głównych, kategoriach, produktach i CMS (strony z lakierami). Strony inne niż lakierowane, możemy przetwarzać od 400 do 500 żądań na sekundę w zależności od sklepu. Używamy teraz RDS Multi z odczytami.

Umieszczamy także Magento Admin na swoim własnym węźle, aby uruchamiać crony i ruch administracyjny. http://administraton.mymagestore.com/admin

Nigdy nie oglądaliśmy się za siebie. Korzystaliśmy z jednego z najlepszych brytyjskich hostów, niezależnie od tego, czy są to bardzo drogi gospodarze.

Boju
źródło
1
Uważaj - sesje administracyjne nie będą działać z DynamoDB ze względu na ich rozmiar. Sprawdziłbym dokładnie - DynamoDB zwiększył maksymalny rozmiar przedmiotu z 64 KB do 256 KB, ale wciąż może nie być wystarczająco duży. Obejrzałem to, używając sesji plików, ponieważ miałem tylko jeden węzeł administracyjny i wiele węzłów interfejsu użytkownika, dlatego wdrożyłem osobny plik local.xml dla interfejsu administracyjnego kontra interfejs WWW.
Ralph Tice
2

Możesz użyć prawie wszystkich podstawowych usług AWS, aby uruchomić swoje Magento. Najprostszym scenariuszem byłoby użycie EC2 z Elastic IP i AWS VPC do konfiguracji bezpieczeństwa.

Inteligentnym sposobem jest wdrożenie 2 serwerów: Serwer WWW + Baza danych. Serwer WWW zawiera Magento + Nginx + PHP + buforowanie zaplecza (Redis lub APC to dobra opcja) oraz osobny serwer MySQL w tej samej podsieci. Serwery te mogą być widoczne dla siebie za pośrednictwem prywatnego adresu IP w sieci prywatnej (skonfigurowanej przez VPC). Nginx jest serwerem z wyboru, gdy tylko może superszybko dostarczać pliki statyczne.

Serwer bazy danych powinien być ukryty przed jakimkolwiek dostępem. Serwer WWW będzie widoczny na portach 80 i 443. Możliwe jest przydzielenie Elastycznego IP do serwera WWW. Później przydaje się konfiguracja DNS (na przykład poprzez AWS Route 53) lub równoważenie obciążenia AWS.

Jak wspomniałeś, taka konfiguracja może być uciążliwa. Możesz więc przyspieszyć konfigurację za pomocą Deploy4Me. Skonfiguruje wszystkie wspomniane zabezpieczenia, maszyny wirtualne i sieć w ciągu kilku minut.

Pavel Korsukov
źródło