18

その Instagram で、テクノロジの実装をブログを通じて他の開発者と共有していることがわかりました。彼らは、遭遇した問題に対して優れた解決策をいくつか持っています。彼らが持っているソリューションの 1 つは、その背後に 3 つの nginx インスタンスがある Amazon の Elastic Load Balancer です。これらの nginx サーバーのタスクは何ですか? また、Elastic Load Balancer のタスクは何ですか? また、それらの関係はどのようなものですか?

4

3 に答える 3

47

免責事項: 私はこれに関する専門家ではなく、AWS エコシステムについて自分で学習中です。

ELB (Elastic Load Balancer) には、リクエストを受信して​​適切なサーバーにルーティングする以外の機能はありません。サーバーは、Nginx、IIS、Apache、lighthttpd などを実行できます。

実際の使用例を紹介します。

1 つの WordPress ブログを実行している 1 つの Nginx サーバーがありました。このサーバーは、私が言ったように、静的コンテンツを提供し、同じサーバー上で実行されている phpfpm に .php リクエストを「アップストリーム」する Nginx によって強化されていました。ある日まで、すべてがうまくいっていました。このブログはテレビ番組で紹介されました。私には大量のユーザーがいて、サーバーはそれほど多くのトラフィックに追いつくことができませんでした. 私の最初の反応は、AMI (Amazon マシン イメージ) を使用して、m1.heavy のようなより強力なインスタンスでサーバーのコピーを起動することです。問題は、今後数日間で時間の経過とともにトラフィックが増加することを知っていたことです。すぐに、さらに強力なマシンを回転させる必要があり、それはより多くのダウンタイムとトラブルを意味します。代わりに、ELB (エラスティック ロード バランサー) を起動し、DNS を更新して、Web サイトのトラフィックが直接サーバーではなく ELB を指すようにしました。ユーザーはサーバーの IP などを知らず、ELB だけを見て、他のすべては amazon のクラウド内で行われます。ELB は、トラフィックが送信されるサーバーを決定します。ELB と一度に 1 つのサーバーのみ (トラフィックが少ない場合) または数百のサーバーを使用できます。サーバーはいつでも作成してサーバー アレイ (サーバー グループ) に追加することができます。また、自動スケーリングを設定して新しいサーバーを生成し、Amazon コマンド ラインを使用してそれらを ELB サーバー グループに追加することもできます。

ELB とオートスケーリング

Amazon クラウド ウォッチ (別の製品で AWS エコシステムの重要な部分) は、サーバーの状態を常に監視し、そのユーザーをどのサーバーにルーティングするかを決定します。また、すべてのサーバーの負荷が高くなりすぎていることも認識しており、(AMI を使用して) 別のサーバーを生成するように命令するエージェントでもあります。サーバーに大きな負荷がかからなくなると、サーバーは自動的に破棄されます (または停止しましたが、覚えていません)。

このようにして、常にすべてのユーザーにサービスを提供できました。負荷が軽いときは、ELB と 1 つの Nginx サーバーのみを使用していました。負荷が高いときは、必要なサーバーの数を (サーバーの負荷に応じて) 判断させます。最小限のダウンタイム。もちろん、同時に支払うことができるサーバーの数などに制限を設定できるため、支払うことができる以上の請求が発生することはありません.

ご覧のとおり、Instagram 関係者は次のように述べています。「2 つの Nginx マシンとそれらの間で DNS ラウンドロビンを実行していました」。これは、ELB と比較して非効率的な IMO です。DNS ラウンド ロビンは、各要求を別のサーバーにルーティングする DNS です。したがって、最初はサーバー 1 に移動し、2 番目はサーバー 2 に移動します。ELB は実際にサーバーの HEALTH (CPU 使用率、ネットワーク使用率) を監視し、それに基づいてどのサーバー トラフィックが流れるかを決定します。違いがわかりますか？「このアプローチの欠点は、マシンの 1 つを廃止する必要がある場合に DNS を更新するのに時間がかかることです。」DNS ラウンド ロビンは、ロード バランサーの一種です。ただし、1 つのサーバーが失敗し、DNS を更新してこのサーバーをサーバー グループから削除する必要がある場合は、ダウンタイムが発生します (DNS が全世界に更新されるまでに時間がかかります)。一部のユーザーは、この悪いサーバーにルーティングされます。ELB を使用すると、これは自動的に行われます。サーバーの状態が悪い場合、それ以上のトラフィックは受信されません。もちろん、サーバーのグループ全体の状態が悪く、自動スケーリングの設定がない場合を除きます。

そして今、Instagram のスタッフは次のように述べています。「最近、Amazon の Elastic Load Balancer を使用するようになりました。その背後には 3 つの NGINX インスタンスがあり、スワップインとスワップアウトが可能です (ヘルスチェックに失敗した場合は、自動的にローテーションから除外されます)。」.

私が描いたシナリオはフィクションです。実際にはそれよりも複雑ですが、解決できないものは何もありません。たとえば、ユーザーがアプリケーションに画像をアップロードする場合、サーバー グループ上のすべてのマシン間で一貫性を維持するにはどうすればよいでしょうか? Amazon s3 などの外部サービスに画像を保存する必要があります。Instagram エンジニアリングに関する別の投稿では、「写真自体は、現在数テラバイトの写真データを保存している Amazon S3 に直接送信されます。」. ロードバランサーに 3 つの Nginx サーバーがあり、すべてのサーバーが画像のリンクが S3 を指す HTML ページを提供している場合、問題はありません。イメージがインスタンスにローカルに保存されている場合、それを行う方法はありません。ELB 上のすべてのサーバーには、外部データベースも必要です。そのため、Amazon には RDS があります。すべてのマシンが同じデータベースを指すことができ、データの一貫性が保証されます。上の画像では、RDS の「リード レプリカ」を確認できます。これは、RDS の負荷分散方法です。現時点ではあまり詳しくありません、すみません。

これを読んでみてください：http://awsadvent.tumblr.com/post/38043683444/using-elb-and-auto-scaling

于 2013-10-06T18:36:01.220 に答える
0

ブログのエントリを指摘していただけますか？

ロードバランサーは負荷を分散します。Web サーバーの状態 (応答時間など) を監視し、Web サーバー間で負荷を分散します。より複雑な実装では、トラフィックが急増した場合に新しいサーバーを自動的に生成することができます。もちろん、サーバー間に一貫性があることを確認する必要があります。たとえば、同じデータベースを共有できます。

したがって、ロードバランサーがヒットし、サーバーの状態に応じてトラフィックをルーティングするサーバーを決定すると思います。. Nginx は、同時ユーザーに大量の静的コンテンツを提供するのに非常に優れた Web サーバーです。動的ページのリクエストは、cgi を使用して別のサーバーにオフロードできます。または、nginx を実行する同じサーバーで phpfpm も実行できます。. 多くの可能性。私は今携帯電話にいます。明日はもう少し書けます。よろしくお願いします。

于 2013-10-05T23:03:19.563 に答える