リバースプロキシ vs ロードバランサー: Nginxでの使い分け

「リバースプロキシ」と「ロードバランサー」という言葉を同じ意味で使っているのを聞いたことがあるでしょう。しかし、Nginxを設定する際には、その違いを知ることが重要です。インフラストラクチャの設計、SSLの処理、アプリケーションのスケーリング方法に影響を与えるからです。

このガイドでは、混乱を解消します。それぞれが何をするのか、どちらをいつ使うべきか、そしてNginxで明確かつ実践的な例を用いて設定する方法を学びます。

リバースプロキシとは？

リバースプロキシは、クライアントとバックエンドサーバーの間に位置します。クライアントのリクエストを受け取り、適切なバックエンドに転送し、レスポンスを返します。クライアントがバックエンドと直接通信することはありません。

一般的な用途：

• SSLターミネーション：プロキシでHTTPSを処理し、バックエンドはHTTPのみを扱います。
• キャッシュ：静的アセットやAPIレスポンスを保存し、バックエンドの負荷を軽減します。
• セキュリティ：バックエンドの詳細を隠し、リクエストをフィルタリングし、DDoSを緩和します。
• 圧縮：クライアントに送信する前にGzipやBrotliでレスポンスを圧縮します。

Nginxは、Node.js、Python（Gunicorn/uWSGI）、Java（Tomcat）などのアプリケーションサーバーの前段にあるリバースプロキシとしてよく使用されます。

ロードバランサーとは？

ロードバランサーは、受信トラフィックを複数のバックエンドサーバーに分散します。主な目的は、可用性、スケーラビリティ、フォールトトレランスを向上させることです。

主な機能：

• トラフィック分散：ラウンドロビン、最小接続数、IPハッシュなどのアルゴリズムを使用してリクエストを分散します。
• ヘルスチェック：異常なサーバーへのトラフィック送信を自動的に停止します。
• セッション維持：必要に応じて、ユーザーを同じバックエンドに固定します。

ロードバランサーは、ハードウェア（F5、Citrix）またはソフトウェア（Nginx、HAProxy、クラウドLB）で実現できます。Nginxのupstreamモジュールは、それを有能なソフトウェアロードバランサーにします。

リバースプロキシ vs ロードバランサー：主な違い

実際には、ロードバランサーは特殊なリバースプロキシです。Nginxを含む多くのツールは、両方を同時に実行できます。

リバースプロキシを使うべき場合

以下の場合にリバースプロキシを使用します：

• 単一のバックエンドサーバーを提供するが、SSL、キャッシュ、圧縮が必要な場合。
• 1つのIPの背後で、異なるパスやサブドメインに複数のアプリケーションをホストする場合。
• バックエンドを直接公開せず、セキュリティ層を追加する場合。

例：ポート3000で実行されるNode.js APIで、NginxがHTTPSを処理し静的ファイルを提供する場合。

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/nginx/ssl/api.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/api.example.com.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

ロードバランサーを使うべき場合

以下の場合にロードバランサーを使用します：

• 高いトラフィックを処理するための複数のバックエンドサーバーがある場合。
• 高可用性が必要な場合—1つのサーバーが故障しても、他のサーバーが引き継ぎます。
• ローリングデプロイやブルーグリーンデプロイを行う場合。

例：ラウンドロビンを使用してNginxの背後に3つのNode.jsインスタンスを配置する場合。

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Nginxはリクエストを均等に分散します。ヘルスチェックやその他のパラメータを追加して、動作を微調整できます。

Nginxで両方の役割を組み合わせる

ほとんどの実際のセットアップでは、Nginxをリバースプロキシとロードバランサーの両方として使用します。例えば：

upstream app_servers {
    least_conn;
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:3000 backup;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/nginx/ssl/app.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/app.example.com.key;

    location /static/ {
        root /var/www/static;
        expires 30d;
    }

    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

ここでは、NginxがSSLを終端し、静的ファイルを提供し、ヘルスチェックを備えた3つのアプリサーバー間で負荷分散を行います。

Nginxをリバースプロキシ/ロードバランサーとして使用する際のベストプラクティス

• 適切なヘッダーを設定する：バックエンドが元のクライアントを認識できるように、常にHost、X-Real-IP、X-Forwarded-Forを渡します。
• HTTP/2を有効にする：パフォーマンス向上のために、listenディレクティブにhttp2を追加します。
• バッファとタイムアウトを調整する：アプリの動作に基づいてproxy_buffer_size、proxy_read_timeoutを調整します。
• ヘルスチェックを使用する：Nginx Open Sourceにはパッシブチェックがあり、Nginx Plusはアクティブチェックを提供します。
• 賢くログを取る：デバッグのためにアップストリームの応答時間を記録するカスタムログフォーマットを使用します。

Nginxのログを分析することは、ボトルネックを特定するために重要です。Nginx Log Analyzerのようなツールは、アクセスログを解析し、遅いアップストリームやエラーを迅速に特定するのに役立ちます。

FAQ

Nginxはリバースプロキシとロードバランサーの両方になれますか？

はい。NginxはSSLを終端し、コンテンツをキャッシュし、複数のバックエンドにリクエストを同時に分散できます。upstreamブロックがバックエンドプールを定義し、proxy_passディレクティブがリクエストを転送します。

バックエンドサーバーが1つだけの場合、ロードバランサーは必要ですか？

必ずしも必要ではありません。リバースプロキシだけでもSSL、キャッシュ、セキュリティを処理できます。しかし、複数のバックエンドを持つロードバランサーを追加すると可用性が向上します—1つのサーバーが故障しても、他のサーバーがトラフィックを処理できます。

Nginxはどのようにしてリクエストを送信するバックエンドを選択しますか？

デフォルトでは、Nginxはラウンドロビンを使用します。least_conn（最小接続数）、ip_hash（クライアントIPに基づくスティッキーセッション）、またはhash（カスタムキー）などのディレクティブで変更できます。

Nginxのセットアップを最適化する準備はできましたか？まず、無料のNginxログパーサーでログを分析し、パフォーマンスの問題を発見して設定を微調整しましょう。