【AlmaLinux 9】Apache中級者講座 第4回：リバースプロキシ構築とmod_proxyによる負荷分散の実践

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の「Apache中級者講座」、折り返し地点となる第4回のテーマは、「リバースプロキシ」と「ロードバランシング（負荷分散）」です。

これまでは「1台のApacheサーバーをいかに強化するか」に焦点を当ててきました。しかし、どれほどMPMをチューニングし、WAFで守りを固めても、物理的なハードウェアの限界（CPUやメモリ、帯域）は必ずやってきます。
大規模なWebサービスや、止まることが許されない基幹システムでは、複数のサーバーを組み合わせて1つの巨大なシステムとして見せる「スケールアウト」の技術が不可欠です。

本記事では、AlmaLinux 9上でApacheをリバースプロキシとして動作させ、複数のバックエンドサーバーへリクエストを賢く振り分ける高度な設定手順を解説します。

---

1. リバースプロキシの基本概念と導入メリット

まず、「プロキシ（代理）」という言葉を整理しましょう。通常のプロキシ（フォワードプロキシ）は、組織内からインターネットへ出て行く通信を代理します。対してリバースプロキシは、インターネットからのリクエストを受け取り、背後にある適切なサーバーへ転送する役割を担います。

なぜリバースプロキシを挟むのか？

フロントにApacheをリバースプロキシとして置くことで、以下のような「プロの運用メリット」が得られます。

• 負荷分散（ロードバランシング）: 複数のサーバーにリクエストを分散し、システムの処理キャパシティを向上させます。
• セキュリティの向上: バックエンドのサーバー（DBサーバーなど）をプライベートネットワークに隠し、直接インターネットに晒さないようにできます。
• SSLオフロード: SSLの暗号化・複合化処理をフロントのApacheに集約し、バックエンドサーバーの負荷を軽減します。
• キャッシュの集約: 複数のサーバーに対するリクエストを1箇所でキャッシュし、応答速度を高速化します。

---

2. AlmaLinux 9での mod_proxy 基本設定

AlmaLinux 9の標準的なApache構成では、必要なモジュールは既にインストールされていますが、ロードされているか確認から始めましょう。

2-1. モジュールの確認

httpd -M | grep proxy

proxy_module, proxy_http_module, proxy_balancer_module などが表示されれば準備OKです。

2-2. シンプルな転送設定

例えば、フロントのApache（example.com）に来たリクエストを、内部にある別のサーバー（192.168.1.50）へ転送する最も基本的な設定です。
/etc/httpd/conf.d/proxy.conf を作成します。

sudo vi /etc/httpd/conf.d/proxy.conf

<VirtualHost *:80>
    ServerName example.com

    # プロキシ設定
    ProxyPass / http://192.168.1.50/
    ProxyPassReverse / http://192.168.1.50/

    # セキュリティ上の理由でフォワードプロキシ機能はオフにする
    ProxyRequests Off
</VirtualHost>

ProxyPassReverse が重要です。これがないと、バックエンドサーバーが発行したリダイレクト（Locationヘッダ）がクライアントにそのまま届いてしまい、内部IPが露出したりリンク切れが起きたりします。

---

3. mod_proxy_balancer による本格ロードバランシング

ここからが本題です。複数のバックエンドサーバーを束ねて、1つのグループ（バランサー）として定義します。

<Proxy "balancer://mycluster">
    # サーバー1（重み1：標準）
    BalancerMember http://192.168.1.51 loadfactor=1
    # サーバー2（重み2：ハイスペックなサーバーには多めに割り振る）
    BalancerMember http://192.168.1.52 loadfactor=2

    # 分散アルゴリズムの指定
    ProxySet lbmethod=byrequests
</Proxy>

<VirtualHost *:80>
    ServerName example.com
    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/
</VirtualHost>

3-1. 主要な分散アルゴリズム（lbmethod）

• byrequests: リクエスト数に応じて均等に（重みに従って）分配します。最も一般的です。
• bytraffic: 転送バイト数（トラフィック量）に応じて分配します。大きなファイルのダウンロードが多い場合に有効です。
• bybusyness: 現在処理中のリクエストが最も少ないサーバーへ優先的に割り振ります（Least Connection）。

---

4. ヘルスチェック（死活監視）とフェイルオーバーの設定

ロードバランシングを運用する上で最も恐ろしいのは、「故障しているバックエンドサーバーにリクエストを送り続けてしまうこと」です。
Apacheには、バックエンドの応答を自動監視し、異常があれば切り離す機能が備わっています。

<Proxy "balancer://mycluster">
    # retry: 失敗してから再試行するまでの秒数
    # status=+H: ホットスペア（普段は使わず、全サーバー全滅時にのみ稼働）
    BalancerMember http://192.168.1.51 loadfactor=1 retry=60
    BalancerMember http://192.168.1.52 loadfactor=1 retry=60
    
    # 予備サーバー（バックアップ）
    BalancerMember http://192.168.1.99 status=+H
</Proxy>

4-1. セッション維持（Sticky Session）

ログインが必要なWebアプリケーションの場合、同じユーザーのリクエストは常に同じサーバーへ送る必要があります（セッションが切れてしまうため）。

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
ProxyPass / balancer://mycluster/ stickysession=ROUTEID

---

5. AIを活用したバックエンドサーバーの異常検知

リバースプロキシを運用していると、フロントのログ（access_log）には、バックエンドからの応答コードが記録されます。
「最近、特定のバックエンドサーバーだけ503エラーや応答遅延が多い気がする…」という予兆をAIで見逃さないようにします。

5-1. AIプロンプト：バランサーログの傾向分析

%b（送信バイト数）や %D（処理時間：マイクロ秒）を含めたカスタムログをAIに読み込ませます。

あなたはインフラ監視のスペシャリストです。
以下のApacheリバースプロキシのログ（LTSV形式またはカスタム形式）を分析し、以下の課題を解決してください。

【ログに含まれる情報】
・アクセスされたバックエンドサーバーのIP
・ステータスコード
・処理にかかった時間（ミリ秒）

【依頼事項】
1. 特定のサーバーにおいて、他のサーバーと比較して応答時間が20%以上遅延している傾向はありますか？
2. 5xxエラーが発生している場合、その共通点（特定のURLパス、特定の時間帯）を特定してください。
3. リソースの限界が近いと思われるサーバーを特定し、その根拠を述べてください。
4. バランサーの「loadfactor」をどのように調整すべきか提案してください。

【ログデータ】
（ここにログを貼り付け）

AIはこのデータから、「192.168.1.52 は午後3時台に画像リサイズ処理で極端に応答が低下しているため、この時間帯だけ負荷を減らすべき」といった、人間の直感では気づきにくい「サイレント障害」の予兆を教えてくれます。

---

総まとめ：止まらないシステムをデザインする

第4回の講座、お疲れ様でした。

mod_proxy を使いこなすことで、Apacheは単なるWebサーバーから、強力なインフラ制御タワーへと進化します。複数台構成は最初は複雑に見えますが、「1台をメンテナンス中に止めても、サイトは動き続ける」という安心感は、一度味わうと元には戻れません。

今回学んだリバースプロキシ構成は、次回の「SSL/TLSチューニング」や、その先の「キャッシュ戦略」の土台となります。

次回、第5回「SSL/TLSの極限チューニングとHTTP/2・HTTP/3対応」では、セキュリティと速度を両立させる最新の暗号化プロトコル設定について解説します。暗号化はサーバー負荷が高い処理ですが、これもApacheの力で最適化していきましょう！