AWS環境でのMagentoの実行

誰もが知っているように、Magentoをホストすることは、他のPHPアプリケーションをホストすることとは異なります。2013年にAmazon Web Services環境でMagentoを実行することはどの程度実現可能ですか？

Magentoで使用するAWSサービスの魔法の組み合わせはどのような意味がありますか？「ランオブザミル」ストアのスマートデフォルトはどのレベルですか？（はい、私は知っています、工場の店はありません）

どれを避けるべきですか（EBS？）

このセットアップを得るための数週間の苦痛を避けるためのヒント、トリック、展開戦略はありますか？

2011年から2013年までAWSでMagentoをホストしていました。従来の専用または共有ホスティングではなくクラウドインフラストラクチャを使用することで得られる多くのことは、DevOpsのトピックでより適切に説明されています。その使用。

• キャパシティプランニングの完全かつ柔軟な制御-マーケティングイベントに先立ってスケールアップし、Elastic Beanstalkを使用して動的プロビジョニングを有効にし、少量の期間にスケールダウンし、数週間でサイトをスピンアップし、破棄して破棄します。
• 開発/テスト/ステージング環境を簡単にセットアップし、それらの間で変更を複製します。
• 別のホストで管理ページをホストします。
• セッション管理にDynamoDBを使用し、追加のオペレーションオーバーヘッドが発生しないキャッシュにElastiCacheを使用します。ただし、ElastiCacheは現在VPCで機能しないことに注意してください。
• ロードバランシングにはELBを使用しますが、リクエストが60秒以上かかると、それらが異常終了することに注意してください
• Eメールの送信にAmazonSESを使用します（通常のSMTPでさらに簡単になりました）。ただし、バウンス/苦情を追跡するためのツールにはまだギャップがあります
• メディアのホスティングにはAmazonS3を、CDNにはCloudfrontを使用します。
• ポイントインタイムリストア、自動フェイルオーバー、自動バックアップ、および自動アップグレードを備えたRDSを介したデータベースアクティビティの運用コストの削減。
• DNS管理はRoute53では非常に簡単ですが、一般にサブドメインをロードバランサーに簡単にマッピングするために推奨されます。
• VPCは、すべてのマシンを独自のプライベートネットワークに配置して、よりきめ細かな制御を行い、独自のVPNトンネルを介して適切と思われるアクセスを公開します。
• CloudWatchとSNSを介した簡単なパフォーマンスメトリックとアラート（メモリ使用量とディスク使用量を除く）

最小フットプリントは、ドメインのELB 1つ、独立したAZのEC2 Webサーバー2つ、マルチAZ RDS 1つ、Route53ホストゾーンになります。最初は、ELBでスティッキーセッションを使用してセッション管理を簡素化できますが、トラフィックが増加するにつれて、メディアをCDN（S3およびCloudFront）に移動し、個々のマシンからセッションを切り離します。

見たことがないがまだ有望な領域：Magentoスタックのデプロイを容易にするCloudFormationスクリプト、DynamoDBを介したオーダー作成のオフロード、チェックアウトスループットを向上させるワーカーキュー最近）、およびRoute53を使用したレイテンシベースのルーティングを介したマルチリージョンプレゼンスの設定。

私は一種のクラウドの伝道者だと思います。AWSに固有のc3.largeは、実稼働Webサーバーのまともなインスタンスサイズですが、各インスタンスクラスの最小のものから始めて、パフォーマンスを測定し、必要に応じてコードをスケールアップまたは最適化します。xhguiは常に。

これは、Angrybirds Webショップで行う方法です。

Magento Imagine 2012での英語プレゼンテーション。

Meet Magento＃6.12でのドイツのプレゼンテーション

現在のドイツ語の「PHP Magazin」には、詳細が記載された6ページの記事（ドイツ語）もあります。

上記のファブリツィオのすべてのプレゼンテーションを何度も読んで、この答えは本当に最高のものだと思いますが、より多くの説明とプレゼンテーションからの主要なアイデアの抽出を使用できることに同意します（特に最初の最初のリンクが既にこの更新を投稿するまでに404で送信されました）。

プレゼンテーションの重要な概念に追加する唯一のことは、AWS /競合他社の技術の最新の進歩がいくつかの調整を提案するということです... CloudfrontはCDNパフォーマンスの向上のためにgzipをサポートしているという事実ですが、CloudFlareが提供するような無料のSSL終了を提供しますか。Route 53 DNSはCloudFlaresほど高速でも機能も豊富ではありません。また、AWSには同等のWebアプリケーションファイアウォールまたはDDOS保護もありません。これらはすべてCloudFlare製品に含まれています...

Fabrizioの元のプレゼンテーションを改善する方法は他にもいくつかありますが、答えたStackExchangeの投稿で知っていたすべてを手放した場合、私は良いコンサルタントにはなりません。さらに、最新の製品のいくつかは、元のプレゼンテーションの提案を大幅に変更しますが、異なるオプションを使用してAWSからさらに絞り込める場合でも、すべてが優れたパフォーマンスを提供します。

重要な概念の要約：

1. ボトルネックを詳細に把握し、適切に最適化します。スタックの各層には特定のボトルネック（帯域幅、CPU、データベース）があり、各層のボトルネックを解決するには、特定の課題ごとに最適化された異なるソリューションが必要ですが、実際にはキャッシュはすべてのレベルで共通の要素であり、...

2. すべてのものをキャッシュする：可能な場合はAWSシステムを活用します（Redis / Memcacheタイプのデータキャッシュ用のElasticache、CDNを介してエンドユーザーに最も近いイメージ、js、およびcssアセットをキャッシュするCloudfront）および初期アセットレベルへのサーバーインスタンス応答を高速化するためのワニスCDNからのリクエストをキャッシュします。また、CDNに展開する前に、展開システムで圧縮と最小化を行ってください。

3. オートスケーリングは不可欠です：需要は、手動で監視および対応できるよりも頻繁かつ迅速に変化します。これらの変更にリアルタイムで適応するには、Auto-Scaling GroupなどのAWSで利用可能な自動化ツールを使用して、このタスクに最適なシステムの断片をスピンアップする必要があります。AWSはこれをCloudFront CDN、Route 53 DNS、Elastic Load Balancer、およびS3バケットに対して透過的に処理します。EC2インスタンスのサイズ変更と自動スケーリング、およびRDSとElasticache層のサイズ変更/調整だけで処理する必要があります

4. 自動化は、これらすべてを効果的に結びつける唯一の方法です。相互に関連するコンポーネントが非常に多く、その一部は展開時に初期化する必要があり、一部は展開直後に、最適なパフォーマンスのために調整されたシステムを管理するには自動化が必要です。キャッシュクリア、キャッシュウォーミング、画像処理などの展開とシステム自動化を活用することは、この多くの異なるサブシステムを管理し、十分に油を塗って問題のない状態に保つ唯一の合理的な方法です。

5. しかし、それでもテストの自動化なしでは不可能です。このように多くの可動部分があると、ほとんどすべての変更で何かが壊れます。また、MagentoとAWSの開発に遅れをとらないように変更する必要があります。そして、それらは頻繁に起こります。したがって、変更のコストを最小限に抑えるには、ユニットテストから統合テスト、実稼働環境を模倣する実際のテスト構成で起動された実際のサイトのSeleniumベースの機能テストまで、すべての形式のテストを実装および完全に自動化する必要があります。すべての展開プロセスを自動化できたことが本当にうれしいです。

少しシンプルな（！）ソリューションは、他のVPSと同じようにインストールするだけです。私は今、数年のための無料の画像を提供してきた...最近私が原因それがローカルであることに新しいシドニーDCに集中している-の詳細http://www.greengecko.co.nz/magento_on_amazon_ec2をあなたの場合それに興味があります。実質的に痛みはありません-ワンクリックでそこにいます。詳細については、ブラウザでインスタンスを指定してください。これは良い出発点になります-ただし、それに基づいて構築する場合は、/ etc / rc.localを調べて変更します。

重要なことは、インスタンスの電力がかなり低いことです。明らかにアプリに多額のお金を投入することでこれが改善されますが、中規模のWebショップであっても、複数のコアを取得するためだけに中程度のインスタンスが絶対最小値であり、実際に必要なのは本当に大きいことです。

また、Amazonストレージは低速です。そのため、メモリから可能な限りすべてを提供することは、通常よりもさらに重要です。データベースの調整、メモリバックアップキャッシュなどは必須です。

並べ替えが完了すると、正常に機能します。1つ以上のIPアドレスが必要な場合にVPCで実行するための要件は本当に面倒です（特に、開始時にこれを認識していない場合！）、実際に遭遇する唯一の落とし穴です。

プラットフォームを「オンザフライ」で拡張するのは簡単です-最終的に唯一のボトルネックはPHPで利用可能な処理能力の量になり（非効率なコードは別です！）、複数の「エンジン」を並行して実行することがおそらく最も簡単なオプションであり、必要。

楽しい！

スティーブ

RDSマルチAZ、2つのNGINX最適化サーバー、2つのワニスサーバー+ ELB、および同じワニスサーバー（ワニスとは異なるポート）SSL Nginxで実行しています。Elasticacheを使用し、Magentoのセッション管理にDynamoDBをすぐに統合します。S3とCloudfrontも使用します。

1か月あたり£700のサーバーを所有している英国のホスティング会社と興味深いチャットをしました。彼らが行うのは、スレートAmazon AWSだけです。Magentoのストライピング、モジュールの無効化、カテゴリカウント機能などを含むすべての領域での正しいセットアップと最適化により（ロードバランスを行うデータベースサーバーの前にNGINXおよびVarnishサーバーを微調整しました）。

現在、ホーム、カテゴリ、製品、およびCMSページ（ニスのページ）で1秒あたり2400-3000 +ヒットを取得できます。ワニス以外のページでは、ストアに応じて1秒あたり400〜500のリクエストを処理できます。現在、RDS Multi with Readsを使用しています。

また、Magento Adminを独自のノードに配置して、cronと管理トラフィックを実行します。 http://administraton.mymagestore.com/admin

振り返ることはありません。私たちは、英国の最高の1つを使用していました。すべてが非常に高価なホストです。

ほぼすべての基本的なAWSサービスを使用して、magentoを機能させることができます。最も簡単なシナリオは、セキュリティ設定にElastic IPおよびAWS VPCでEC2を使用することです。

スマートな方法は、Webサーバー+データベースの2つのサーバーを展開することです。Webサーバーには、Magento + Nginx + PHP +バックエンドキャッシング（RedisまたはAPCが適切なオプションです）および同じサブネット内の別のMySQLサーバーが含まれます。これらのサーバーは、プライベートネットワークのプライベートIP（VPC経由で構成）を介して相互に表示できます。Nginxは、静的ファイルを超高速で配信できるようになるとすぐに選択されるWebサーバーです。

データベースサーバーは、すべてのアクセスから隠されるべきです。Webサーバーはポート80および443で表示されます。ElasticIPをWebサーバーに割り当てることができます。後でDNS（AWS Route 53経由など）またはAWSロードバランシングを設定すると便利です。

あなたが述べたように、そのような設定をすることは苦痛でありえます。そのため、Deploy4Meを使用してセットアップを高速化できます。上記のすべてのセキュリティ、VM、およびネットワークを数分で構成します。