AIが翻訳した投稿です。
durumis AIが要約した投稿
nginxはオープンソースで、ウェブサーバーまたはウェブプロキシサーバーとして広く利用されています。
適切に設定すれば、静的コンテンツを効率的に配信できます。
その中でも、いくつかの主要な設定を記録したいと思います。
ウェブサイトを読み込む際、ウェブサーバーからJavaScript、画像、HTML、CSSなど、無数のファイルを受け取ります。
この時、これらのコンテンツをそのまま配信するのではなく、gzip圧縮を利用することで、転送されるデータ量を大幅に削減できます。
つまり、これを実装することで
- データ量が減り、帯域幅を節約できます。
- サーバーリソースを節約できます。
- ユーザーにとって、実際の読み込み速度が向上します。
一方で、サーバーはコンテンツに応答する前にgzip圧縮を実行する必要があるため、サーバーのCPU使用率が高くなる可能性があります。
どの種類のファイルを圧縮するか、圧縮率はどの程度にするか、どのくらいの大きさのファイルを圧縮するかなど、運用レベルに適用する前にテストが必要です。
以下は、gzipに関するいくつかの設定です。
gzip on; # gzip圧縮を設定します。 gzip_vary on; # ヘッダーにVary: Accept-Encodingを追加します。 gzip_proxied any; # nginxをプロキシサーバーとして使用する場合は、バックエンドから受信した応答を圧縮します。（プロキシされたリクエストに対する圧縮） gzip_min_length 256; # 256バイト以上のファイルのみ圧縮 gzip_comp_level 5; # 1～9の圧縮レベルを設定します。値が大きくなるほどCPU使用率が増加します。5は約50％圧縮します。 gzip_types text/plain text/css text/xml application/json application/javascript; // 圧縮するコンテンツの種類を設定します。
* gzip_varyは、クライアントがgzipをサポートする場合とサポートしない場合に、コンテンツを圧縮版と非圧縮版でそれぞれ送信できるように指示します。（クライアントのリクエストヘッダー（Accept-Encoding）に応じて、異なるバージョンのコンテンツが提供される可能性があることを示します。）
nginxはクライアントにレスポンスを送信する前に、レスポンスをバッファーに保存します。
ウェブサーバーがクライアントにレスポンスを送信する際、クライアントの速度が遅い場合、サーバーはデータの送信を待ち続ける必要があります。（ネットワークボトルネック）
この時、サーバーリソースを継続的に使用しているため、これを解決するためにバッファーを使用して、クライアントの処理速度に関係なくレスポンスを一時的に処理します。これにより、以下の利点があります。
- サーバー負荷の最適化
- ネットワークボトルネックの軽減
location / { proxy_pass サーバーURL;
// プロキシバッファー設定 proxy_buffering on; // バッファーを有効にします。 proxy_buffer_size 4k; // バッファーのサイズを設定します。（主にヘッダーが入ります。） proxy_buffers 8 4k; // 各接続に対するバッファーの数とサイズ（4KBの8個） proxy_busy_buffers_size 8k; // クライアントにレスポンスを送信する際に使用できる最大バッファーサイズ }
※ バッファーサイズを大きくしすぎると、テキストストリーミングなどのリアルタイムデータ転送が遅延する可能性があるため、必ずテストが必要です。特に近年AI関連サービスが多く登場していますが、テキストストリームが機能しない場合は、この設定を必ず確認しましょう。
workerはクライアントのリクエストを処理するプロセスであり、サーバーのCPUコアごとにいくつ持つかを設定できます。
httpは一般的にリクエスト-接続-レスポンス-接続終了ですが、複数回のリクエストに対して接続するリソースを削減するために、クライアント接続を維持できます。これがkeep alive設定です。
worker_processes auto; # 使用可能なCPUコア数に応じて自動設定 worker_connections 1024; # 各workerが同時に処理できる接続数 // keep-alive設定 keepalive_timeout 65; keepalive_requests 100; server { listen 80; location / { proxy_pass サーバーURL; } }
上記2つをまとめる理由は以下の通りです。
使用しているサーバーのコア数が4つの場合、理論上可能な接続数は1,024 * 4 = 4,096です。
(リソースやトラフィック環境によって正確ではない場合があります)
4,096個のクライアントが同時接続し、65秒間すべてのkeepaliveを占有している場合、
4,097番目のユーザーが接続しようとすると、接続できなくなるため、レスポンスが遅延する可能性があります。
したがって、auto scalingなどによってサーバーリソースが安定していると仮定した場合、イベント時にレスポンス遅延が発生する場合は、上記の設定が間接的に影響を与える可能性があります。
proxy bufferなどの設定の一部は、リクエストURLごとに適用できます。
* keep-aliveなどの設定の一部はHTTP/Serverレベルで適用されるため、ブロックごとに設定できません。
server {
listen 80;
server_name example.com;
// 基本パスの処理(/) location / { proxy_pass サーバーURL; // バッファリング設定 proxy_buffering on; proxy_buffers 8 16k; proxy_buffer_size 32k; proxy_busy_buffers_size 64k; } // /testパスの処理 location /test { proxy_pass サーバーURL2; // バッファリング無効化 proxy_buffering off; // バッファリングを無効化（レスポンスをすぐに送信） } }
上記の設定により、ウェブパフォーマンスを最適化できます。様々なテストケースを考慮して十分にテストを行い、サーバーパフォーマンスを最適化しましょう！
* サーバーのダウンタイムなしに変更された設定のnginxを適用できるため、非常に安定しています。
2024年9月6日
2024年4月25日
2024年9月4日
2024年4月3日
