web-dev-qa-db-ja.com

Webサイトごとに1つのEC2インスタンス-EC2を使用してAmazonクラウド上の複数のWebサイトを管理します

私は複数のウェブサイトを管理しており、そのほとんどはWordPressに基づいており、すべてLAMPスタックに基づいています。すべてのウェブサイトをAmazonクラウドに移動しています。AWSは初めてで、計画は移動しています私の最小のウェブサイトから始めて、1つのウェブサイト。

私の質問は、すべてのサイトを1つのEC2インスタンスに配置するか、1つのWebサイトを1つの個別のインスタンスに配置する必要があるかということです。

誰もが従来のウェブホスティングのコンテキストで後者を間違いなく選択するので、これはおそらく愚かに聞こえます。私が前者について考えた理由は次のとおりです。

  • 再利用可能なLAMPスタック
    • LAMPスタックを使用して独自のAMIを生成し、さまざまなWebサイトで再利用できるようにすることはできますか？私がコミュニティAMIに行かない理由は、
      • どちらを使うべきかわからない
      • LinuxやLAMPスタックについてそれほど無知ではない人として、私は必要なものだけを手に入れたいと思っています。それ以上でもそれ以下でもありません。
  • コスト：すべてのサイトを1つの巨大なインスタンスに配置するのに対して、各サイトをより小さなインスタンスに配置します。そんなことはないと思いますが、聞いても害はないと思いました
  • 難易度複数のインスタンスの管理

スケーラビリティ

数か月後には、現在と比較して約3倍の計算能力が必要になると確信しています（新しいサイトが立ち上げられ、現在6つあり、それまでに10つあります。既存のサイトへのトラフィックは急速に増加しています）。とにかく、私が水平スケーリングに行くことにしたとしましょう。現在使用しているのと同じタイプの3つのインスタンスを使用しています。

それで、私のさらなる質問は、このシナリオが、サイトを分離するか、EC2インスタンスの1/1グループにすべてまとめるかの決定にどのように影響するかということです。

これはおそらく、私がまだ読んでいるAmazonクラウドの垂直スケーリングと水平スケーリングの違いに関係していることを私は知っています。これはおそらく仮想マシン/サーバーに関する知識と関係があります。私は完全に馬鹿ですが、必要に応じてさらに理解することを気にしません。しかし、これは私がAmazonクラウドについて進むべき方向に影響を与える可能性があるので、私はただ尋ねるべきだと思いました。私がこんなに怠惰なバンプだと思ったら、気軽に平手打ちをしてください。最初に宿題をする必要があります:)

すべての助けは大歓迎です！

免責事項：これをsuperuser.comまたはstackexchangeサイトに投稿する必要があるかどうかをお知らせください。ありがとう

amazon-ec2web-serveramazon-web-serviceswordpresslamp
7
ericn

まず、 S。Ostermann、et al、201 から取得したいくつかの生データ：

基本的なインスタンスの仕様：

+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
|   Name    |  ECUs   | RAM  | Archi |  I/O  | Disk | Cost  |    Reserve    | Reserved Cost |
|           | (Cores) | [GB] | [bit] | Perf. | [GB] | [$/h] | [$/y], [$/3y] | [$/h]         |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
| m1.small  | 1 (1)   | 1.7  | 32    | Med   | 160  | 0.1   | 325, 500      | 0.03          |
| m1.large  | 4 (2)   | 7.5  | 64    | High  | 850  | 0.4   | 1300, 200     | 0.12          |
| m1.xlarge | 8 (4)   | 15   | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
| c1.medium | 5 (2)   | 1.7  | 32    | Med   | 350  | 0.2   | 650, 1000     | 0.06          |
| c1.xlarge | 20 (8)  | 7    | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+

基本的なパフォーマンス/コスト分析：

+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
|    System     | Peak Perf. |   HPL    | STREAM | RandomAc. | Latency | Bandw. | GFLOP/ECU | GFLOPS/$ |
|               | [GFLOPS]   | [GFLOPS] | [GBps] | [MUPs]    | [µs]    | [GBps] |           |          |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
| m1.small      | 4.4        | 1.96     | 3.49   | 11.6      | -       | -      | 1.96      | 19.6     |
| m1.large      | 17.6       | 7.15     | 2.38   | 54.35     | 20.48   | 0.7    | 1.79      | 17.9     |
| m1.xlarge     | 35.2       | 11.38    | 3.47   | 168.64    | 17.87   | 0.92   | 1.42      | 14.2     |
| c1.medium     | 22         | 3.91     | 3.84   | 46.73     | 13.92   | 2.07   | 0.78      | 19.6     |
| c1.xlarge     | 88         | 51.58    | 15.65  | 249.66    | 14.19   | 1.49   | 2.58      | 64.5     |
| 16x m1.small  | 70.4       | 27.8     | 11.95  | 77.83     | 68.24   | 0.1    | 1.74      | 17.4     |
| 16x c1.xlarge | 1408       | 425.82   | 16.38  | 207.06    | 45.2    | 0.75   | 1.33      | 33.3     |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+

実際のパフォーマンスは通常、理論上のパフォーマンスの50％未満です。疑わしい可能性のある値の1つのセットは、c1.mediumの値であり、期待される結果（帯域幅など）と完全には一致しません。

一般的なワークロードのEC2の主なコストは、インスタンスのコストです。他のコスト（帯域幅、プロビジョニングされたストレージなど）は、通常、総コストの25％未満です。パフォーマンスが完全にスケーリングすることは期待できません。これは、上記のデータから明らかです。特に水平スケーリングに関しては、計算能力を追加すると効率が大幅に低下するようです。

上記を考慮し、生のコンピューティングパフォーマンス以外にも他の要因（I/Oパフォーマンス、メモリなど）があることを念頭に置いて、垂直スケーリングが最も経済的なアプローチであるのは当然のことです。

残念ながら、シナリオの経済性以外にも考慮事項があります。信頼性が鍵となります。単一のインスタンスでは、そのインスタンスに障害が発生すると、セットアップ全体が停止します。考えられる解決策の1つは、自動スケーリング（つまり、インスタンス数を1に維持すること）ですが、単一のインスタンスでも、特定のアベイラビリティーゾーンで発生する可能性のある問題が発生する傾向があります。

ある時点で、水平方向にスケーリングする必要があります。問題は、理想的な時間はいつかということです。私はおそらく次のことを提案します：-少なくともいくつかのインスタンスサイズを垂直方向にスケーリングします（t1.microから始める場合はさらに大きくなります）-データベースを別々のインスタンスに分離します（Webサーバーと同じようにスケーリングしないため）-少し冗長になるまで水平方向にスケーリングします-最大インスタンスサイズに達するまで垂直方向にスケーリングします-その後は水平方向にスケーリングします（最初は小さいインスタンスを使用する可能性があります）

手元の質問に戻る-インスタンスごと（またはインスタンスのセットごと）に単一のWebサイトを実行すると、常にコストが高くなります。固定費が高くなることに加えて（たとえば、単一のロードバランサーではなく、Webサイトごとに1つのロードバランサー）、インスタンスを効率的に利用できません（つまり、他のWebサイトがほとんどアイドル状態です。つまり、一部のインスタンスが過負荷になり、他のインスタンスがアイドル状態になっています）。ロジスティクスの観点から、問題は想像するほど悪くはないかもしれません-主な問題はすべてを独立して管理することです（これはいくつかの構成管理ツール（Puppet/Chefなど）で回避できますが、通常はステップではありませんセットアップが少し大きくなるまでかかります）。

一方、EC2インスタンスの制限の1つは、特定のインスタンスに割り当てることができるパブリックIPアドレスは1つだけであるということです（これは、特定のSSLセットアップに影響を及ぼします）。

あなたは確かにあなた自身のAMIを生成することができます-それは実際にはかなり標準的な方法です。私は通常 AmazonのLinux AMI で始まります。これは、オーバーヘッドが最も少なく（リソースが非常に簡単で、高速）、AWSで最もサポートされている（定期的に更新されるなど）ものであることがわかったためです。そして私は、他の人気のある選択肢であるDebian/Ubuntuディストリビューションよりも、RHEL/CentOSディストリビューション（AmazonのLinuxがベースになっている）を好みます。インスタンスをカスタマイズしたら、EBSボリュームのスナップショットを作成し、AMIを登録できます。スナップショットIDを、ルートボリュームのベースとなるイメージとして渡します。理論的には、独自のディストリビューションを構築する範囲でさえ、オペレーティングシステムをさらにカスタマイズできます（ただし、Amazonカーネルを使用します）。ただし、非常に特殊なユースケースがない限り、特に有益であるとは考えられません。 Wordpressを実行するための私の個人的な好みは、Varnish + Nginx + PHP-FPM（およびWordpressの場合はW3TC）です-リソースでは、通常のLAMPスタックよりもはるかに簡単です。

最後に、スケーリングにもう一度対処します。上で説明した問題の基本的な経済学を超えて、困難は複数のインスタンスを1つとして「表示」することに帰着します。これには、すべてのインスタンスが同じデータを提供することの確認、インスタンス間の負荷分散、PHPセッション）などの詳細の処理が含まれます。すべてのサイトが独自のセットで実行されている場合、実行はより困難になります。インスタンスの数-ただし、それほど大きな差はない可能性があります（AMIに機能を構成していることを願っています）。ただし、複数のインスタンスは、より複雑なシステムを意味し、監視する必要のあるものが多くなります（かなりの数があります）。特定のセットアップをスケーリングする方法の詳細が必要な場合は、このトピックに関するServerFaultに関するいくつかの質問（ this 、 this 、または this -） 、別の質問として質問してください）。

結論として-セットアップで個々のサイトを独自のインスタンス/クラスターで実行する必要がある場合を除いて（たとえば、非常に異なる構成/要件）、単一のインスタンス/クラスターで複数のサイトを実行する方が簡単です。規模が大きく、経済的で効率的であり、「クラウドコンピューティング」（つまり共有リソース）の精神とより一致しています。

参照：

10
cyberx86