【Nginx応用講座 第3回】マイクロサービス時代のルーティング。gRPC、WebSocket、認証プロキシ（auth_request）の統合

「ただのWebサーバー」から、「APIゲートウェイ」へ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、WAF（ModSecurity）を導入し、アプリケーションを攻撃から守る鉄壁の要塞を構築しました。
これで「守り」は完璧です。

さて、ここからは「攻め」のインフラ構築です。
2026年の今、Webシステムはモノリシック（一枚岩）な構造から、マイクロサービス（機能ごとの小さなサービスの集合体）へと移行しています。
そこでは、チャット機能には「WebSocket」、サービス間通信には高速な「gRPC」、そして認証は「共通のID基盤」といった具合に、適材適所で様々なプロトコルが使われます。

本記事では、gRPCのロードバランシング設定、WebSocket特有のヘッダー処理とタイムアウト管理、そしてNginxの隠れた最強機能である auth_request モジュールを使った認証基盤の構築について、実例を交えて解説します。

---

第1章：次世代プロトコル「gRPC」をルーティングする

gRPCは、Googleが開発したRPC（Remote Procedure Call）フレームワークです。
JSONの代わりに「Protocol Buffers」というバイナリ形式を使い、HTTP/1.1の代わりに「HTTP/2」をベースに通信します。
これにより、REST APIよりも圧倒的に高速で軽量な通信が可能になります。

なぜNginxが必要なのか？

gRPCはHTTP/2を使用するため、多くのロードバランサー（L4）では中身を見ることができません。
Nginxはバージョン1.13.10からgRPCをネイティブサポートしており、L7レベルでのルーティングやロードバランシングが可能になりました。

gRPCの設定手順

通常の proxy_pass ではなく、grpc_pass ディレクティブを使用します。

nginx.confの設定例：

http {
    # gRPCバックエンドの定義
    upstream grpc_backend {
        server 192.168.1.101:50051;
        server 192.168.1.102:50051;
    }

    server {
        listen 443 ssl http2; # HTTP/2が必須！
        server_name grpc.example.com;

        # SSL証明書設定（省略）
        ...

        location / {
            # gRPCリクエストを転送
            grpc_pass grpc://grpc_backend;
            
            # タイムアウト設定（gRPCは長時間接続が多いので長めに）
            grpc_read_timeout 300s;
            grpc_send_timeout 300s;
        }
    }
}

プロの注意点：暗号化あり(grpcs)となし(grpc)

• grpc://: Nginxとバックエンド間を「平文（非暗号化）」で通信します。これを「h2c (HTTP/2 Cleartext)」と呼びます。社内LANなど、バックエンドがTLSを持たない場合に適しています。
• grpcs://: Nginxとバックエンド間も「TLS暗号化」して通信します。ゼロトラストネットワークなど、内部通信も暗号化したい場合に使用します。

---

第2章：リアルタイム通信「WebSocket」の罠と対処法

チャットアプリや通知機能で使われるWebSocket。
これはHTTPで接続を開始し、途中でプロトコルを「アップグレード」して、永続的な双方向通信（TCPコネクション）を確立する仕組みです。

Nginxでの設定のポイント

Nginxはデフォルトでは、バックエンドへの接続をHTTP/1.0で行い、Connection ヘッダーを削除してしまいます。
WebSocketを通すには、明示的にヘッダーを書き換える必要があります。

nginx.confの設定例：

http {
    # Upgradeヘッダーの値を動的に決定するマップ定義
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    upstream websocket_backend {
        server 192.168.1.201:3000;
    }

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

        location /ws/ {
            proxy_pass http://websocket_backend;

            # 【重要】HTTP/1.1を使う
            proxy_http_version 1.1;

            # 【重要】Upgradeヘッダーを中継する
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;

            # 【最重要】タイムアウト設定
            proxy_read_timeout 3600s;
            proxy_send_timeout 3600s;
        }
    }
}

タイムアウト設定の罠

通常のHTTPリクエストは数秒で終わりますが、WebSocketは繋ぎっぱなしです。
しかし、Nginxの proxy_read_timeout のデフォルトは60秒です。
つまり、「60秒間通信がないと、Nginxが勝手に切断する」という事態が起きます。
チャットアプリで「しばらく黙っていると切断される」原因の9割はこれです。
タイムアウトを長く設定するか、アプリ側でPing/Pong（心拍確認）を実装して定期的に通信を発生させる必要があります。

---

第3章：認証ロジックを分離する「auth_request」

マイクロサービスにおいて、各サービス（商品管理、注文、ユーザー設定…）ごとに認証コードを書くのは非効率であり、セキュリティリスクも高まります。
Nginxの auth_request モジュールを使えば、リクエストがバックエンドに届く前に、「認証専用サービス」に問い合わせを行い、OKが出た場合のみ通すことができます。

仕組み（フロー）

1. クライアントが /private/ にアクセス。
2. Nginxはバックエンドに行く前に、内部的に /auth へサブリクエストを投げる。
3. 認証サービスがトークンを検証する。
   • OKなら 200 OK を返す。
   • NGなら 401 Unauthorized を返す。
4. Nginxは結果を受け取る。
   • 200なら、本来のバックエンドへリクエストを流す。
   • 401なら、クライアントにエラーを返して終了。

設定例：共通認証基盤の構築

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

    # 保護されたAPI
    location /api/ {
        # 認証を有効化
        auth_request /auth_verify;

        # 認証サービスから受け取ったユーザーIDをバックエンドに渡す
        auth_request_set $user_id $upstream_http_x_user_id;
        proxy_set_header X-User-ID $user_id;

        proxy_pass http://app_backend;
    }

    # 内部用：認証サービスへのサブリクエスト
    location = /auth_verify {
        internal; # 外部からは直接アクセス不可
        proxy_pass http://auth_service:8080/verify;
        
        # リクエストボディは送らない（ヘッダーだけで検証）
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
    
    # 401エラー時のリダイレクト（ログイン画面へ）
    error_page 401 = @error401;
    location @error401 {
        return 302 https://example.com/login;
    }
}

---

第4章：APIゲートウェイとしての統合構成例

これまでの要素を組み合わせた、マイクロサービス時代の「APIゲートウェイ」の完全な構成例です。

http {
    # WebSocket用マップ
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    # バックエンド定義
    upstream rest_backend { server 10.0.1.10:80; }
    upstream grpc_backend { server 10.0.1.20:50051; }
    upstream ws_backend   { server 10.0.1.30:3000; }
    upstream auth_backend { server 10.0.1.99:8080; }

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

        # 共通認証設定
        auth_request /_auth;
        auth_request_set $user_id $upstream_http_x_user_id;

        # 1. REST API
        location /api/v1/ {
            proxy_pass http://rest_backend;
            proxy_set_header X-User-ID $user_id;
        }

        # 2. gRPCサービス
        location /org.example.Greeter/ {
            grpc_pass grpc://grpc_backend;
            grpc_set_header X-User-ID $user_id;
        }

        # 3. WebSocketチャット
        location /chat/ {
            proxy_pass http://ws_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_read_timeout 3600s;
        }

        # 内部認証エンドポイント
        location = /_auth {
            internal;
            proxy_pass http://auth_backend/verify;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
        }
    }
}

たった一つのNginx設定ファイルで、異なるプロトコル、異なるサービスを束ね、認証を一元管理する。これが「APIゲートウェイ」の威力です。

---

まとめ：Nginxは「インフラの通訳者」である

お疲れ様でした！
今回は、マイクロサービス時代に必須となる3つの高度なルーティング技術を学びました。

今回の重要ポイント：

• gRPCは grpc_pass を使い、HTTP/2を有効にする。
• WebSocketは Upgrade ヘッダーの中継とタイムアウト延長が必須。
• auth_request を使えば、認証ロジックをアプリから分離（サイドカーパターンの先駆け）できる。
• これらを統合することで、Nginxは強力なAPIゲートウェイになる。

これで、開発チームからの「gRPC使いたい」「チャット入れたい」という無茶ぶりにも、「任せとけ！」と即答できますね。

しかし、要件はさらに複雑になるかもしれません。
「特定のユーザーだけ別のサーバーに飛ばしたい」「リクエストボディの中身を書き換えたい」「認証トークンを動的に検証したい」。
設定ファイル（conf）の記述だけでは限界が来る時があります。

次回、第4回は「Nginxをプログラマブルに。Lua言語（OpenResty）による動的処理と機能拡張」です。
Nginxの中にスクリプト言語「Lua」を組み込み、設定ファイルだけでは不可能な「複雑なロジック」を爆速で実行する魔術的なテクニックを伝授します。
インフラエンジニアの常識を覆すディープな世界へようこそ。お楽しみに！