ロードバランサーの背後にあるnginx
私は、Instagramがブログを通じて他の開発者とテクノロジーの実装を共有していることを発見しました。彼らは遭遇した問題に対していくつかの素晴らしい解決策を持っています。それらのソリューションの1つは、AmazonのElastic Load Balancerで、背後に3つのnginxインスタンスがあります。それらのnginxサーバーのタスクは何ですか？そして、Elastic Load Balancerのタスクは何ですか？また、それらの間の関係は何ですか？
免責事項：私はこれについての専門家ではなく、AWSエコシステムについて自分で学習しているところです。
ELB（Elasticロードバランサー）には、リクエストを受信して適切なサーバーにルーティングする以外の機能はありません。サーバーはnginx、IIS、Apache、lighttpdを実行できます。
実際のユースケースを紹介します。
1つのnginxサーバーで1つのwordpressブログを実行していました。このサーバーは、前述のように、静的コンテンツを提供するnginxと、同じサーバーで実行されているphpfpmへの.phpリクエストの「アップストリーム」を利用していました。このブログはテレビ番組で紹介されました。ユーザーがたくさんいて、サーバーはそれほど多くのトラフィックに対応できませんでした。最初の反応は、AMI（Amazonマシンイメージ）を使用してスピンすることです。 m1.heavyのようなより強力なインスタンスにサーバーのコピーをアップします。問題は、今後数日間でトラフィックが時間の経過とともに増加することを知っていたということでした。すぐに、さらに強力なマシンをスピンする必要があり、それはより多くのダウンタイムを意味します。代わりに、ELB（エラスティックロードバランサー）を起動し、DNSを更新して、ウェブサイトのトラフィックをサーバーに直接ではなくELBに向けるようにしました。ユーザーはサーバーのIPなどを知らず、ELBだけが表示されます。それ以外の場合は、Amazonのクラウド内で実行されます。ELBは、トラフィックがどのサーバーに送信されるかを決定します。 ELBと一度に1台のサーバーのみ（現在トラフィックが少ない場合）、または数百台のサーバーをオンにします。サーバーはいつでも作成してサーバーアレイ（サーバーグループ）に追加できます。または、Amazonコマンドラインを使用して新しいサーバーを生成してELBサーバーグループに追加するように自動スケーリングを構成することもできます。
Amazonクラウドウォッチ（別の製品であり、AWSエコシステムの重要な部分）は常にサーバーの状態を監視し、そのユーザーをルーティングするサーバーを決定します。また、すべてのサーバーの負荷が高くなりすぎていることも認識しており、（AMIを使用して）別のサーバーを生成するように命令するエージェントです。サーバーに大きな負荷がかかっていない場合、サーバーは自動的に破棄されます（または停止されますが、思い出せません）。
このようにして、常にすべてのユーザーにサービスを提供することができ、負荷が軽い場合は、ELBと1つのnginxサーバーしかありませんでした。負荷が高いときは、必要なサーバーの数を（サーバーの負荷に応じて）決定させます。最小限のダウンタイム。もちろん、同時に購入できるサーバーの数に制限を設定することもできます。そのため、支払うことができる金額に対して請求されることはありません。
ほら、Instagramの人たちは次のように言っています-「以前は2台のnginxマシンとそれらの間でDNSラウンドロビンを実行していました」。これは、ELBと比較して非効率的なIMOです。 DNSラウンドロビンは、各要求を異なるサーバーにルーティングするDNSです。したがって、最初にサーバー1に移動し、次にサーバー2に移動します。 ELBは実際にサーバーのヘルス（CPU使用率、ネットワーク使用率）を監視し、それに基づいてどのサーバートラフィックに向かうかを決定します。違いがわかりますか？そして、「このアプローチの欠点は、マシンの1つを廃止する必要がある場合にDNSが更新されるのにかかる時間です」と述べています。 DNSラウンドロビンはロードバランサーの一種です。ただし、1つのサーバーが機能しなくなり、このサーバーをサーバーグループから削除するためにDNSを更新する必要がある場合、ダウンタイムが発生します（DNSが全世界に更新されるまでには時間がかかります）。一部のユーザーは、この不良サーバーにルーティングされます。 ELBを使用すると、これは自動的に行われます。サーバーの状態が悪い場合、それ以上トラフィックを受信しません。もちろん、サーバーのグループ全体の状態が悪く、自動スケーリングの設定がない場合を除きます。
そして今、Instagramのメンバー：「最近、AmazonのElastic Load Balancerの使用に移行しました。背後には、スワップインとスワップアウトが可能な3つのNGINXインスタンスがあります（ヘルスチェックに失敗すると、自動的にローテーションから外されます）。」.
私が説明したシナリオは架空のものです。実際にはそれよりも複雑ですが、解決できないことは何もありません。たとえば、ユーザーがアプリケーションに画像をアップロードする場合、サーバーグループ上のすべてのマシン間で一貫性を保つにはどうすればよいでしょうか。 Amazons3などの外部サービスに画像を保存する必要があります。 Instagramエンジニアリングに関する別の投稿–「写真自体はAmazon S3に直接送信され、現在、数テラバイトの写真データが保存されています。」ロードバランサーに3つのnginxサーバーがあり、すべてのサーバーが画像のリンクがS3を指すhtmlページを提供している場合は、問題はありません。イメージがインスタンスにローカルに保存されている場合–それを行う方法はありません。 ELB上のすべてのサーバーには、外部データベースも必要です。そのため、AmazonにはRDSがあります–すべてのマシンが同じデータベースを指すことができ、データの整合性が保証されます。上の画像では、RDSの「レプリカの読み取り」を確認できます。これはRDSの負荷分散方法です。現時点ではそれについてはよくわかりません。ごめんなさい。
これを読んでみてください： http://awsadvent.tumblr.com/post/38043683444/using-elb-and-auto-scaling
宜しくお願いします。
ブログエントリを指摘していただけますか？
ロードバランサーは負荷を分散します。 Webサーバーの状態（応答時間など）を監視し、Webサーバー間で負荷を分散します。より複雑な実装では、トラフィックが急増した場合に新しいサーバーを自動的に生成することができます。もちろん、サーバー間に一貫性があることを確認する必要があります。たとえば、同じデータベースを共有できます。
したがって、ロードバランサーがヒットし、サーバーの状態に応じてトラフィックをルーティングするサーバーを決定すると思います。 。 Nginxは、同時ユーザーに多くの静的コンテンツを提供するのに非常に優れたWebサーバーです。動的ページの要求は、cgiを使用して別のサーバーにオフロードできます。または、nginxを実行する同じサーバーでphpfpmを実行することもできます。 。多くの可能性。私は今携帯電話を使っています。明日はもう少し書くことができます。宜しくお願いします。
パーティーに遅れていることは承知していますが、Istagramブログ投稿でELBの背後にあるNGINXインスタンスを使用することは、説明されているように高可用性ロードバランサーを提供することだと思います ここ 。
NGINXインスタンスは、ブログ投稿でWebサーバーとして使用されていないようです。その役割について、彼らは次のように述べています。
次は、リクエストを処理するアプリケーションサーバーです。 Djangoon Amazon High-CPUExtra-Largeマシンを実行しています
そのため、ELBは、高可用性を提供していなかったNGINXインスタンス間のDNSラウンドロビンを使用した古いソリューションの代わりとして使用されます。