この記事はNGINXのブログにも掲載されています。 NGINXで読む>
従来、ウェブ開発とホスティングは主にLAMPスタックを使用して行われていました。LAMPは Lの略です。 inux（オペレーティングシステム）、 A pache（ウェブサーバー）、 M ySQL（データベース）、および P HP（プログラミング言語）、エンタープライズサイトの運営に使用されたコアコンポーネント。
Webスタックとロードバランサーの俊敏性が向上し、ビジネスニーズによってパフォーマンスと安定性が向上するにつれて、ApacheHTTPサーバーを軽量で拡張性の高い代替手段であるNGINXに置き換えることがますます一般的になっています。 NGINXを使用すると、スタックはLEMPとして知られるようになります– L inux、（ e ）NGINX、 M ySQL、 P HP。
Atlantic.Netは、ストレージ、ホスティング、マネージドサービスなどのさまざまなソリューションを提供しています。 VPSホスティングプラットフォームにはワンクリックのLEMPオプションがあり、スタックを30秒以内に起動して実行できます。 DockerからNGINXを実行することを好む人のために、Dockerを備えたLinuxとWindowsの両方のクラウドサーバーがあります。また、NGINXの設定についてサポートが必要な場合や必要な場合にマネージドサービスを提供します。
NGINXは、Webサーバーとしてだけでなく、リバースプロキシおよびロードバランサーとしても頻繁かつ堅牢に使用されます。集中ログクラスターの負荷分散ソリューションを調査した後、NGINXを使用することにしました。 NGINXをさまざまな容量で使用することで、フロントエンドサーバーとバックエンドサーバーの両方で高可用性を実現しながら、非常に小さなフットプリントを維持します。これはすべて、NGINXのRAMとCPUの使用効率のおかげです。
NGINXのどの特定の機能が最も役立つかという点で、特に強力なのは、TCP / UDPプロキシと負荷分散、アクセス制御、および3ウェイSSLハンドシェイクです。このブログ投稿では、これらの各機能の使用方法について説明します。
NGINXストリームを使用した集中ログの負荷分散
監査とセキュリティのためにログを提供する必要性が高まっているため、Atlantic.Netは、HTTPトラフィックだけでなく、syslogにも適切なプロキシと負荷分散ソリューションを探していました。 Syslogは通常、ユーザーデータグラムプロトコル（UDP）形式で送信されるため、HTTPだけでなくUDPも処理できるものが必要でした。
これは、NGINXのstream モジュールは、UDPトラフィックのロードバランシングを可能にするため、機能し始めました。負荷分散では、ネットワークトラフィックを効率的に分散するために、多数のバックエンドサーバーを使用しています。用語が示すように、目的はワークロードを均等に分散することです。
次のスニペットでは、syslogメッセージをネットワークインフラストラクチャからログバックエンドに送信しています。
...
stream {
upstream networking_udp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass networking_udp;
}
}
... Filebeatログを安全に送信する次の例に示すように、ストリームはSSLoverTCPでも適切に機能します。
...
upstream filebeat_tcp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 ssl;
ssl_certificate /etc/nginx/ssl/certs/cert.pem;
ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
proxy_pass filebeat_tcp;
proxy_ssl on;
proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
proxy_ssl_protocols TLSv1.2;
proxy_ssl_session_reuse on;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
... ご覧のとおり、NGINXはUDPおよび伝送制御プロトコル（TCP）トラフィックのプロキシと負荷分散が可能です。
リバースプロキシと負荷分散の使用は、UDPまたはTCPを介して通信しているサービス、データベース、またはプログラムがある場合に役立ちます。基本的なレベルでは、これらのメソッドは、NGINXによって管理されているように、同じサービス、データベース、またはプログラムインスタンスが複数のアップストリームサーバーで実行されている場合に関連します。 Atlantic.Netでは、NGINXのリバースプロキシも利用しています。これは、重要なバックエンドサービスに難読化の追加レイヤーを提供し、オーバーヘッドがほとんどないためです。
アクセス制御
一元化されたログを保護するためのもう1つの重要なステップは、データの削除を防ぐことでした。さらに、アクセス制御リスト（ACL）は、IPアドレスに基づいてトラフィックを制限するのに非常に役立ちます。私たちの目的のために、内部管理ネットワークからのみログデータへのアクセスを許可したかったのです。
NGINXは、ここで見られるように、どのような種類のHTTPアクションをどこから実行できるかを非常に正確に描写する方法を提供します：
...
server {
listen 9200;
client_max_body_size 20M;
location / {
limit_except GET POST PUT OPTIONS {
deny all;
}
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
location ~* ^(/_cluster|/_nodes|/_shutdown) {
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
}
... NGINXは、リクエストがプロキシを通過した後に発信元IPアドレスを確認できるようにする透過IP機能もサポートしています。この機能は、ログの発信元を追跡するのに役立ちます。 NGINXを使用すると、このタスクが非常に簡単になります：
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... スリーウェイSSLハンドシェイク
NGINXは、集中ログのSSLハンドオフの両側をクリーンに処理します。この実装は、内部サーバーと顧客サーバーの両方がNGINXと安全に通信できることを意味するため、非常に重要です。ログに記録される各サーバーには、双方向SSL通信用の独自の証明書があり、脆弱性をさらに軽減します。次に、NGINXは、SSLを介して内部ネットワークを介してロギングサーバーにデータを安全に送信します。安全な送信をサポートするすべてのエンドツーエンド通信には、合計で3つのSSL証明書が含まれます。 （推奨される3ウェイSSLセットアップについては、集中ログとNGINXストリームの負荷分散の2番目の構成スニペットを参照してください）。
NGINXの展望とテスト
さまざまな個人や組織が長年にわたってNGINXを賞賛しており、NGINXから彼らが言及しているのと同じ追加のメリットを経験しています。
NodeSourceのソフトウェアエンジニアであるChrisLeaは、ApacheとMicrosoft Wordを比較しており、どちらのアプリケーションにも非常に多くの機能がありますが、通常はほんのわずかしか必要ありません。 Leaは、必要な機能を備えており、かさばらず、パフォーマンスがはるかに優れているため、NGINXを好みます。
ベンチャーキャピタル会社BVCapitalのThomasGieselmanによると、資金を提供した組織のいくつかは、サーバーをNGINXに変更することでスケーリングに関連する問題を修正しました。 Gieselmanは、NGINXを、急速な成長をより簡単にし、より多くの組織が利用できるようにするものと見なしています。
Linux Journalは、Apacheベンチマークソフトウェアabを使用して、簡単なテストを実施しました。 、ApacheをNGINXと比較します（それぞれバージョン2.2.8と0.5.22）。プログラムのtop およびvmstat 2台のサーバーが同時に稼働しているときにシステムのパフォーマンスをチェックするために使用されました。
テストでは、静的コンテンツサーバーとしてNGINXがApacheよりも高速であることが示されました。 2つのサーバーはそれぞれ最適に動作し、同時実行数は100に設定されています。1秒あたり6500のリクエストを処理するために、Apacheは17 MBのメモリ、30％のCPU、4つのワーカープロセス（スレッドモード）を使用しました。 1秒あたり11,500リクエストというはるかに高速なクリップで処理するには、NGINXに必要なメモリは1 MB、CPUは15％、ワーカーは1人だけでした。
ボブ・イッポリトは、ピーク時に月間1億4000万人のユニークユーザーがいるゲームプラットフォームMochi Mediaを設立しました。そのため、彼は高性能の需要をよく理解しています。 Ippolitoは、2006年に、1台のサーバーで1日あたり数千万のHTTPリクエスト（つまり、1秒あたり数百）のリバースプロキシとしてNGINXを使用するテストを実行したと述べました。
NGINXサーバーがピーク容量に達したとき、FreeBSD（UNIXベースのオープンソースOS）であるセットアップで約10％のCPUと15MBのメモリを消費しました。同じパラメータを使用して、Apacheは1000個のプロセスを生成し、大量のRAMを大量に消費しました。ポンドは過剰なスレッドを作成し、さまざまなスレッドスタックに400MB以上を使用しました。より多くのCPUがわずかに必要であり、1時間あたり20MBを超えてリークしました。
NGINXでAtlantic.Netを試す
Atlantic.Netでは、これらのさまざまな関係者によって説明されているように、NGINXで同様のパフォーマンスの向上が見られました。また、上記の特定の機能の恩恵を受けています。現在Apacheまたは別のWebサーバーを使用している場合は、NGINXを試して、スケーラビリティと増え続けるスピードのニーズをより適切に処理するのに役立つ同様の改善が得られるかどうかを確認することをお勧めします。今すぐクラウドサーバーでNGINXをテストしてください。