누구나 알고 있듯이 Magento를 호스팅하는 것은 다른 PHP 응용 프로그램을 호스팅하는 것과는 다릅니다. 2013 년 Amazon Web Services 환경에서 Magento를 실행하는 것은 얼마나 가능합니까?
Magento와 함께 사용하는 것이 합법적 인 AWS 서비스의 조합은 무엇입니까? "제작소 (run of the mill)"상점의 현명한 기본값은 무엇입니까? (예, 알고 있습니다, 밀 상점이 없습니다)
어떤 것을 피해야합니까 (EBS?)?
이 설정을 얻는 데 몇 주 동안의 고통을 피하기위한 팁, 요령, 배포 전략이 있습니까?
답변:
2013 년부터 2013 년까지 AWS에서 Magento를 호스팅했습니다. 기존의 전용 또는 공유 호스팅이 아닌 클라우드 인프라를 사용하여 얻는 많은 것들이 AWS에만 국한되지는 않지만보다 쉽게 사용할 수있는 DevOps 주제에보다 관련이 있습니다. 그것의 사용.
최소 설치 공간은 별도의 AZ에 1 개의 ELB, 2 개의 EC2 웹 서버, 1 개의 다중 az RDS, 도메인에 대한 Route53 호스팅 영역이됩니다. 처음에는 ELB에서 고정 세션을 사용하여 세션 관리를보다 간단하게 유지할 수 있지만 트래픽이 증가함에 따라 미디어를 CDN (S3 및 CloudFront)으로 이동하고 개별 시스템에서 세션을 이동하고 싶을 것입니다.
내가 보지 않았지만 여전히 유망한 분야 : Magento 스택을 쉽게 배포하기위한 CloudFormation 스크립트, DynamoDB를 통한 주문 생성 오프로드 및 더 많은 체크 아웃 처리량을위한 작업자 대기열 최근에), Route53으로 대기 시간 기반 라우팅을 통해 다중 지역 존재를 설정합니다.
클라우드에 대한 전도자라고 생각합니다. AWS의 경우 c3.large는 프로덕션 웹 서버의 적절한 인스턴스 크기이지만 각 인스턴스 클래스 중 가장 작은 것부터 시작하여 성능을 측정하고 코드를 적절하게 확장하거나 최적화합니다. xhgui 지속적으로.
앵그리 버드 웹숍에서 이렇게하는 방법은 다음과 같습니다.
Magento Imagine 2012에서 영어 프레젠테이션.
Meet Magento # 6.12에서의 독일어 프레젠테이션
현재 독일어 "PHP Magazin"에는 6 페이지짜리 기사 (독일어)도 있습니다.
위에서 여러 번 연결된 Fabrizio의 프레젠테이션을 모두 읽은 후에는이 답변이 정말 최고의 답변이라고 생각합니다.하지만 더 많은 설명과 프레젠테이션에서 주요 아이디어를 추출 할 수 있다는 데 동의합니다 (특히 원래의 첫 번째 링크는 이미 이 업데이트를 게시 할 때까지 404입니다).
프레젠테이션에서 주요 개념에 추가 할 수있는 유일한 것은 AWS / 경쟁자 기술의 현대적인 발전이 약간의 조정을 제안한다는 것입니다. CloudFlare 오퍼 와 같은 무료 SSL 종료를 제공합니까 ? Route 53 DNS는 CloudFlares만큼 빠르거나 기능이 풍부하지 않으며 AWS는 비슷한 웹 애플리케이션 방화벽 또는 DDOS 보호 기능을 갖추고 있지 않으며 CloudFlare 제품에 모두 포함되어 있습니다 ...
Fabrizio의 원래 프레젠테이션을 개선 할 수있는 몇 가지 다른 방법이 있지만, 내가 대답 한 모든 StackExchange 게시물에서 알고있는 모든 것을 포기하면 훌륭한 컨설턴트가되지 않을 것입니다. 또한 최신 오퍼링 중 일부는 원래 프레젠테이션의 제안을 크게 변경하여 다른 옵션을 사용하여 AWS에서 더 많은 것을 짜낼 수 있더라도 여전히 뛰어난 성능을 제공합니다.
주요 개념 요약 :
병목 현상을 자세히 파악 하고 적절하게 최적화하십시오. 스택의 각 계층에는 특정 병목 현상 (대역폭, CPU, 데이터베이스)이 있으며 각 계층에서 병목 현상을 해결하려면 각 특정 도전 과제에 최적화 된 다른 솔루션이 필요하지만 실제로는 모든 수준에서 캐싱이 일반적인 요소이므로
모든 것을 캐싱 : 가능한 경우 AWS 시스템을 활용 (Elasticache for Redis / Memcache 유형 데이터 캐싱, Cloudfront for Caching 이미지, js 및 CSS 자산을 통해 최종 사용자에게 가장 가까운 CSS 및 CD 자산을 통해) 애셋을 활용하여 초기 자산 수준에 대한 서버 인스턴스 응답 속도 향상 CDN에서 요청을 캐싱합니다. 또한 CDN에 배포하기 전에 배포 시스템에서 압축 및 축소해야합니다.
자동 확장이 필수적입니다 . 수동으로 모니터링하고 반응 할 수있는 것보다 수요가 자주 그리고 빠르게 변경됩니다. 이러한 변화에 실시간으로 적응하려면 Auto-Scaling Groups와 같은 AWS에서 제공되는 자동화 도구를 사용하여이 작업에 가장 적합한 시스템을 가동시켜야합니다. AWS는 CloudFront CDN, Route 53 DNS, Elastic Load Balancer 및 S3 버킷에 대해이를 투명하게 처리하므로 EC2 인스턴스의 크기 조정 및 자동 조정, RDS 및 Elasticache 계층의 크기 조정 / 조정만으로 처리해야합니다.
자동화는이 모든 요소 를 효과적으로 연계 할 수있는 유일한 방법입니다 . 상호 관련된 여러 구성 요소 중 일부는 배포시 초기화해야하고 일부는 배포 직후에 최적화해야 최적의 성능을 위해 조정 된 시스템을 관리해야합니다. 캐시 지우기, 캐시 워밍, 이미지 처리 등을 위해 배치 및 시스템 자동화를 활용하는 것은이 많은 여러 하위 시스템을 관리하고 문제가없는 상태로 유지하는 유일한 방법입니다.
그러나 실제로는 테스트 자동화 없이는 불가능합니다 .이 많은 움직이는 부품을 사용하면 거의 모든 변화로 무언가가 깨질 수 있습니다. 그리고 Magento와 AWS의 개발에 따라 변경해야합니다. 그리고 종종 일어날 것 입니다. 따라서 변경 비용을 최소화하려면 단위 테스트에서 통합 테스트, 실제 테스트 환경에서 모방되는 실제 테스트 구성으로 시작된 실제 사이트의 Selenium 기반 기능 테스트에 이르기까지 모든 형태의 테스트를 완전히 구현하고 자동화해야합니다. 이제 모든 배포 프로세스를 자동화 한 것이 정말 기쁩니다.
약간 더 간단한 (!) 솔루션은 다른 VPS에서와 같이 설치하는 것입니다. 자세한 내용에 - 나는 최근에 내가 그것으로 인해 지역 인 새 시드니 DC에 집중했습니다 ... 지금은 몇 년 동안 무료로 이미지를 제공하고 한 http://www.greengecko.co.nz/magento_on_amazon_ec2 당신이 경우 관심이 있어요 한 번의 클릭으로 실제로 시작하는 고통이 전혀 없습니다. 자세한 내용은 브라우저를 인스턴스로 지정하십시오. 이것은 좋은 출발점을 만들 것입니다. 그러나 /etc/rc.local을 살펴보고 수정한다면 수정하십시오.
알아야 할 중요한 사항은 인스턴스의 전력이 매우 낮다는 것입니다. 분명히 앱에서 많은 돈을 버는 것이 이것을 향상 시키지만, 중간 규모의 작은 웹숍의 경우 중간 인스턴스는 절대적으로 최소입니다. 여러 코어를 얻는 것만으로도 실제로는 가장 작은 것이 가장 작습니다.
또한 Amazon 스토리지는 느립니다. 따라서 튜닝 데이터베이스, 메모리 백업 캐시 등 메모리에서 가능한 모든 것을 제공하는 것이 평소보다 훨씬 중요합니다.
일단 정렬하면 정상적으로 작동합니다. > 1 IP 주소를 원할 경우 VPC에서 실행해야하는 요구 사항은 실제로 성가 시며 (특히 시작할 때이 사실을 모르는 경우에!) 실제로 발생할 수있는 유일한 문제입니다.
플랫폼을 '즉석에서'확장하는 것은 간단합니다. 결국 유일한 병목 현상은 PHP에서 사용할 수있는 처리 능력의 양이되며 (비효율적 인 코드 제외!) 여러 개의 '엔진'을 병렬로 실행하는 것이 아마도 가장 간단한 옵션 일 것입니다. 필요한.
즐겨!
스티브
RDS Multi AZ, 2 개의 NGINX 최적화 서버, 2 개의 니스 서버 + ELB 및 동일한 니스 서버 (서로 다른 포트) SSL Nginx에서 실행 중입니다. 우리는 Elasticache를 사용하고 Magento의 세션 관리를 위해 DynamoDB를 곧 통합합니다. 우리는 S3와 Cloudfront도 사용합니다.
한달에 £ 700의 서버를 보유한 영국의 호스팅 회사와 재미있는 대화를 나 had습니다. 그들이하는 일은 슬레이트 아마존 AWS뿐입니다. Magento 스트립 백, 모듈 비활성화, 범주 수 기능 등을 포함한 모든 영역에서 올바른 설정 및 최적화를 통해 (NGINX 및 Varnish 서버를 데이터베이스 서버 앞에로드 밸런싱하도록 미세 조정했습니다).
현재 홈페이지, 카테고리, 제품 및 CMS 페이지 (니스 페이지)에서 초당 2400-3000 + 조회수를 얻을 수 있습니다. 니스 페이지가 아닌 경우 상점에 따라 초당 400-500 개의 요청을 처리 할 수 있습니다. 이제 RDS Multi를 Read와 함께 사용하고 있습니다.
또한 크론 및 관리자 트래픽을 실행하기 위해 Magento Admin을 자체 노드에 배치했습니다. http://administraton.mymagestore.com/admin
우리는 결코 되돌아 보지 않았습니다. 우리는 영국 최고 중 하나를 사용하고있었습니다.
거의 모든 기본 AWS 서비스를 사용하여 마 젠토를 작동시킬 수 있습니다. 가장 간단한 확장은 보안 구성을 위해 EC2를 Elastic IP 및 AWS VPC와 함께 사용하는 것입니다.
현명한 방법은 웹 서버 + 데이터베이스라는 두 가지 서버 배포를하는 것입니다. 웹 서버는 Magento + Nginx + PHP + 백엔드 캐싱 (Redis 또는 APC는 좋은 옵션)과 동일한 서브넷에있는 별도의 MySQL 서버를 포함합니다. 이러한 서버는 프라이빗 네트워크의 프라이빗 IP (VPC를 통해 구성)를 통해 서로 볼 수 있습니다. Nginx는 정적 파일을 매우 빠르게 제공 할 수있는 즉시 선택된 웹 서버입니다.
데이터베이스 서버는 모든 액세스에서 숨겨져 있어야합니다. 웹 서버는 포트 80 및 443에서 볼 수 있습니다. 웹 서버에 탄력적 IP를 할당 할 수 있습니다. 나중에 DNS (예 : AWS Route 53을 통해) 또는 AWS로드 밸런싱을 구성하는 것이 유용합니다.
언급했듯이 이러한 구성을 만드는 것은 어려울 수 있습니다. 따라서 Deploy4Me를 통해 설정 속도를 높일 수 있습니다. 언급 된 모든 보안, VM 및 네트워킹을 몇 분 안에 구성합니다.