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?
Odpowiedzi:
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.
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.
Oto jak to robimy dla sklepu internetowego Angrybirds:
Angielska prezentacja na Magento Imagine 2012.
Niemiecka prezentacja na Meet Magento # 6.12
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ęć :
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 ...
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
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
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.
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?
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
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.
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.