...
ウェブホスティングのロゴ

ApacheとNginxでリバース・プロキシを設定する：サーバー・アーキテクチャを最適化する方法

リバースプロキシは、安全で高性能かつスケーラブルな方法で最新のウェブアプリケーションを提供する効果的な方法を提供します。このガイドでは、Apache または NGINX を使ってリバースプロキシを設定する方法を、具体的な設定と最も重要な機能の比較を含めて、順を追って説明します。

中心点

  • リバースプロキシ 入ってくるリクエストを一元的に管理し、バックエンドシステムを保護します。
  • NGINX スピード、シンプルな設定、モダンなアーキテクチャが印象的
  • アパッチ 柔軟なモジュール構造で、既存のインフラに最適
  • ロードバランシング 複数のサーバーで均等な負荷分散が可能
  • SSLオフロード パフォーマンスの向上と証明書管理の簡素化

基本：リバースプロキシは何をするのか？

A リバースプロキシ は外部リクエストと内部サーバとの間のインターフェイスを表す。クライアントのリクエストを適切なバックエンドサーバに転送する。フォワードプロキシとは異なり、クライアントを保護するのではなく、内部サーバーのアーキテクチャを緩和します。このアーキテクチャにより、より高いセキュリティ、集中管理、拡張性の向上が保証される。さらに、キャッシング、SSLターミネーション、認証などの機能を一元的に実装することができます。

NGINXをリバースプロキシとして設定する

NGINX は、最も一般的なリバースプロキシ・ソリューションのひとつである。私は、速いレスポンスタイムと無駄のない設定システムが必要なときに好んで使っている。必要な設定はわずか数ステップで完了する。

インストール後、簡単なサーバー設定でリバースプロキシ機能を有効にします。例えば、アプリケーションサーバーをNGINX経由で8080番ポートで外部から利用できるようにすることができます：

サーバー
   listen 80；
   サーバ名 example.ja；

   location / {
      proxy_pass http://127.0.0.1:8080;
      proxy_set_header Host $host；
      proxy_set_header X-Real-IP $remote_addr；
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for；
      proxy_set_header X-Forwarded-Proto $scheme；
   }
}

このセットアップを、以下のシンボリックリンクで転送する。 サイト有効 そして リロード をNGINXライブから削除しました：

sudo ln -s /etc/nginx/sites-available/example.ja /etc/nginx/sites-enabled//.
sudo systemctl reload nginx

負荷分散には アップストリーム-ブロック。これらは複数のターゲットサーバーを定義し、その間にデータを均等に分散させる。

Apacheをリバースプロキシとして設定する

仝 Apache HTTPサーバー 特にApacheがすでに生産的に使われている環境では、そのモジュール設計に納得がいく。私は、きめ細かなコントロールや既存のコンフィギュレーションを維持したい場合に、リバースプロキシとしてのApacheを高く評価している。セットアップは2つの重要なモジュールを有効にすることで行われる：

sudo a2enmod proxy proxy_http

私は適切なバーチャルホストにフォワーディングコマンドを挿入する：

<バーチャルホスト *:80
    サーバー名 example.com
    プロキシパス / http://127.0.0.1:8080/
    プロキシパスリバース / http://127.0.0.1:8080/
</VirtualHost

最終的なリロードは、コンフィギュレーションをアクティブにする：

sudo apache2ctl configtest
sudo systemctl reload apache2

オプションで mod_proxy_balancer NGINXに似たバランシング・セットアップを実現することもできる。

NGINX + Apache: ハイブリッド型

多くのプロジェクトで、私は両方のシステムを混ぜて使っている。これは フロントエンドとしてのNGINXは静的なデータを極めて迅速に配信し、動的なリクエストはApacheに転送する。Apacheは8080などのポートで内部的に実行され、NGINXは80または443（HTTPS）ポートでパブリックリクエストを受け付けます。

私はよくこの構成を ワードプレスホスティングApacheは.htaccessとの互換性によりメリットがありますが、NGINXはスピードを保証します。また、ファイアウォールルールにより、NGINXからApacheへの接続のみを許可することで、セキュリティを向上させることもできます。

リバースプロキシ・アーキテクチャの機能的利点

その使用は、私に毎日具体的な利益をもたらしてくれる。リバースプロキシがあれば、中心的な仕事をより効率的にこなすことができる。負荷がピークに達しているコンステレーションや、繊細なアプリケーションには特に恩恵があります。

これらには次のようなものがある：

  • スケーリング 負荷分散あたり
  • セキュリティ機能 IPフィルター、DDoS防御、認証など
  • SSL終端処理の一元化 HTTPS インフラの簡素化
  • 高速コンテンツ キャッシング
  • URIまたはホスト名に基づく柔軟なルーティング

パフォーマンス比較：ApacheとNGINX

多くのプロジェクトを経験した後では、この概要のおかげで、どのツールがどのような状況で理にかなっているかを判断しやすくなった。その違いは、操作中にはっきりとわかる：

特徴 NGINX アパッチ
パフォーマンス 非常に高い 頑丈だが、高負荷に弱い
構成 明確で直接的 モジュラー・アーキテクチャによる柔軟性
リバースプロキシのサポート 標準装備 モジュールで制御可能
SSLオフロード 効率的 コンフィギュレーションで実現可能
静的コンテンツ 非常に速い まれに最適
互換性 新しいウェブ技術に最適 PHPと.htaccessに最適

設定のための実践的なヒント

私の日々の実践の中で、いくつかのヒントが何度も証明されている：セキュアなポート80と443を使用すること。 ファイアウォール経由でバックエンドポートをブロックすること。すべての設定を コンフィグテスト-コマンド。

また、SSL暗号化を一貫して実装する必要があります。証明書の自動更新が可能なLet's Encryptを使用することをお勧めします。これにより、データストリームが暗号化されずに送信されることがなくなります。

モニタリングと信頼性

リバースプロキシのアーキテクチャは、ヘルスチェックやロギングと完璧に組み合わせることができる。fail2ban、grafana、prometheusのようなツールは、モニタリングとロギングに役立つ。 プロトコル分析.また、ステータスのエンドポイントを有効にして、遅延が大きい場合のアラートも設定しています。

生産システムでは集中監視が必須である。これにより、ダウンタイムを最小限に抑え、迅速な介入が可能になる。

レビューと使用上の推奨事項

リバースプロキシとしてNGINXとApacheのどちらを使うかは、目的、既存のツール、希望する機能によって異なります。私はNGINXを静的コンテンツ用の高性能なフロントエンドとして使い、Apacheはバックエンドの強力なロジックで全体を補完するのが好きだ。組み合わせることで、プロジェクトはセットアップと運用において最大の効率を達成する。

使い始めるには、ポート80とローカル・バックエンド間の単純なリバース・プロキシで十分なことが多い。ロードバランサー、SSLターミネーション、認証などの機能は後から追加することができる。セキュリティと監視には常に気を配ること。大規模なセットアップの場合は、DockerコンテナやKubernetesなどのソリューションを使い、内部ルーティングで補う。

高度なセキュリティとパフォーマンスのヒント

特に、重要なアプリケーションを公衆インターネット上で提供する場合、拡張セキュリティレイヤーが不可欠です。バックエンドポートのブロックに加え、アプリケーションレベルで特定のIPレンジを明示的に認可することが望ましい。これにより、内部ネットワークに到達する前に潜在的な攻撃ベクトルを減らすことができます。

特に効果的なのは 追加のセキュリティ・ヘッダ 好む コンテンツ・セキュリティ・ポリシー, X-フレームオプション 或いは X-Content-Type-Options.リバースプロキシにこれらを設定することで、各アプリケーションを個別にカスタマイズする必要がなくなります。例えば、NGINX では サーバー-ブロック：

add_header X-Frame-Options SAMEORIGIN；
add_header X-Content-Type-Options nosniff；
add_header X-XSS-Protection "1; mode=block"；

同様の設定は mod_headers を統合します。これらのヘッダーは、クリックジャッキングやMIMEタイプのスニッフィングなど、多くの攻撃シナリオを排除します。また、いわゆる 弱い暗号 そして SSLv3接続 既知の脆弱性を保護するためである。

パフォーマンスに関しては、GzipやBrotli圧縮を利用する価値があります。これらの機能を有効にすることで、クライアントはより少ないデータを受け取ることができます。これは、特にCSSやJavaScriptファイルのような静的コンテンツの読み込み時間にプラスの効果をもたらします。

高スループットのためのキャッシュ・オプション

リバースプロキシの大きな利点は、統合されたキャッシュです。NGINXとApacheは、頻繁にリクエストされるリソースをメモリまたはハードドライブに保存する異なるアプローチを提供します。これにより、アプリケーションサーバーの負荷が大幅に軽減されます。

NGINXでは プロキシキャッシュ機能 例えばこんな感じだ：

proxy_cache_path /var/cache/nginx keys_zone=my_cache:10m；
サーバー
    listen 80；
    サーバー名 example.com；

    location / {
        proxy_cache my_cache；
        proxy_pass http://127.0.0.1:8080;
        add_header X-Cache-Status $upstream_cache_status；
    }
}

このメカニズムは、以下のキャッシュメモリを作成する。 /var/cache/nginx に設定します。特定のMIMEタイプやディレクトリをより長くキャッシュするように、きめ細かい指示を設定できます。クライアントが同じリソースを再度リクエストするとすぐに、NGINXはキャッシュから直接このリクエストを提供します。これにより、ページのロードが高速化され、バックエンドへのリクエスト数が削減されます。

アパッチは以下を提供する。 mod_cache そして mod_cache_disk 同等のメカニズムである。利点のひとつは キャッシュ有効-ディレクティブを使って、どの URL やディレクトリをキャッシュに残すかを定義できます。例えば、ログインフォームのような機密性の高い部分はキャッシュされないようにし、静的な画像は長期的にキャッシュに残すことができます。

ヘルスチェックと高可用性

フェイルセーフを求めるのであれば、バックエンドサーバーの故障や過負荷を自動的に認識できるようにする必要がある。これはまさに 健康チェック 便利です。NGINXでは nginxプラス または追加モジュールを使用して、アプリケーションのステータスを継続的に照会する拡張ヘルスチェック機能をインストールできます。サーバーに障害が発生した場合、NGINXは自動的にトラフィックを他の利用可能なサーバーにリダイレクトします。

Apache は mod_proxy_hcheck そして mod_watchdog.Apache が特定のターゲットの成功かエラーコードをチェックする間隔を設定します。対応するHTTPステータスに到達しない場合、ホストは一時的にプールから削除されます。特に大規模なインストールでは、ロードバランシングとヘルスチェックをターゲットに分散するために、HAProxy のようなロードバランサとの組み合わせを推奨します。

真の 高可用性 さらに、フェイルオーバーやクラスタの設定を使うこともできる。ここでは、2つ以上のリバースプロキシインスタンスが並列に実行され、 Keepalived または Corosync 経由の仮想 IP (VIP) アドレス指定は常にアクティブな プロキシにトラフィックを向ける。一つのインスタンスに障害が発生すると、クライアントのリクエストを 中断することなく、もう一つのインスタンスが自動的に引き継ぐ。

SSLとHTTP/2に最適化された設定

ここ数年、特に暗号化に関しては多くのことが起きている。 HTTP/2 は、1つのTCP接続を介して複数のリソースを並行して転送するオプションを提供し、待ち時間を大幅に短縮します。ApacheとNGINXの両方がHTTP/2をサポートしていますが、通常はSSL暗号化接続（HTTPS）経由のみです。そのため、バーチャルホストが適切に設定されていることを確認してください：

サーバー
    listen 443 ssl http2；
    サーバ名 example.com；
    ssl_certificate /etc/letsencrypt/live/example.de/fullchain.pem；
    ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem；

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

また、最新の暗号スイートを設定し、SSLv3のような古い暗号化プロトコルをオフにすることも忘れないでください。例えば Apache では、これは <VirtualHost *:443>-のようなエントリーを持つコンフィギュレーション：

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrderオン

さらに OCSPステープリング これは、SSL証明書の有効性をサーバー上に直接キャッシュします。そのため、訪問者は外部の認証局への追加リクエストを回避することができ、パフォーマンスが向上し、個人情報が外部に漏れるのを防ぐことができます。

コンテナ環境への統合

NGINXもApacheも、DockerやKubernetesのようなコンテナ環境で優れた運用が可能です。典型的なシナリオは、アプリケーションごとに1つのコンテナが実行され、追加のコンテナがリバースプロキシとして動作することです。これは、新しいアプリケーション・コンテナが開始されるとすぐに動的に設定できます。

そこで、次のようなツールを使用する。 nginx-proxy 或いは トラフィック これは、コンテナを自動的に認識し、適切なルートを定義する。しかし、高度に動的な環境は、自己設定されたNGINXまたはApacheコンテナで作成することもできる。Kubernetesでは イングレス・コントローラーこれは、クラスタからのトラフィックを分散するために、デプロイシナリオに応じてNGINXまたはHAProxyを使用します。

コンテナ内でのカプセル化により、アプリケーション間の分離をきれいに維持し、リバースプロキシやロードバランシング機能を柔軟に拡張することができる。さらに、必要に応じて古いコンテナ・バージョンを再アクティブ化するだけで、ロールバックをより簡単に実行できる。

移行戦略とベストプラクティス

現在、モノリシックなサーバアーキテクチャを運用している場合、リバースプロキシ構造に徐々に切り替える価値があることが多い。単一のアプリケーションをNGINXまたはApacheの背後に置き、特にロギング、エラー分析、セキュリティの面で最初の経験を積むことから始めることができます。その後、他のサービスを移行していきます。

どのポートからどのバックエンドにアクセスできるかを事前に正確に計画しておく。開発環境、ステージング環境、本番環境のプロファイルを別々の設定ファイルに入力し、個別にオン・オフできるようにする。これにより、設定ミスのリスクを最小限に抑えることができます。

もうひとつのベストプラクティスは、すべての設定をコードとしてマッピングすることだ。Gitのようなバージョン管理システムを使うことで、変更をより簡単に追跡し、問題が発生した場合に素早くロールバックできるようにする。これは、特にチームに複数の管理者がいる場合には不可欠です。

バックアップと復旧計画

どんなに優れたセットアップでも、障害やセキュリティ事故から完全に保護できるわけではない。そのため、バックアップとリカバリーのコンセプトは必須です。設定ファイルのスナップショットを定期的に作成し、SSL証明書とDNSの設定がバックアップされていることを確認してください。クリティカルなシステムについては、同じネットワーク内で常時利用可能ではない別のバックアップ・ストレージを使用することをお勧めする。こうすることで、ランサムウェア攻撃やハードウェアの不具合によるデータ損失を防ぐことができる。

リストア処理中に、プロキシ設定をリストアした後にすべてのサービスが正しく実行されているかどうかをテストするべきである。新しい証明書が必要であったり、更新されたDNSエントリが欠けていたりすることがよくある。明確に文書化されたチェックリストにより、リストアプロセスははるかに速くなり、ダウンタイムが少なくなります。

展望とさらなる最適化

リバースプロキシが安定したら、より高度なトピックに集中することができる。ウェブアプリケーションファイアウォール(WAF)を実装するのも一つの方法です。 ModSecurity またはNGINXの専用モジュールです。WAFは、既知の攻撃がアプリケーションに到達する前に、プロキシレベルで直接阻止するのに役立ちます。このステップは、クロスサイトスクリプティング（XSS）、SQLインジェクション、マルウェアアップロードのような頻繁に発生する攻撃に対して特に価値があります。

ピーク時のボトルネックを特定するために、トラフィックを綿密に監視しましょう。grafanaやprometheusのようなツールは、CPU使用率、メモリ、帯域幅のようなメトリクスを監視するのに役立ちます。単一のリバースプロキシが限界に達していることに気づいたら、水平スケーリングまたはクラスタリングについて考える時だ。

最終的には、このような絶え間ない最適化とモニタリングの改善によって、シンプルなリバースプロキシが、お客様のアプリケーションに対する可用性の高い、高性能なインターフェイスに変わります。キャッシング、セキュリティの最適化、柔軟なアーキテクチャの相互作用を通じて、インフラストラクチャを徐々に専門化し、顧客と開発者に安定した高速なウェブ体験を提供することができます。

現在の記事