アパッチとNginx。 一本の鎖でつながっている

Apache と Nginx の組み合わせが Timeweb に実装される方法

多くの企業にとって、Nginx + Apache + PHP は非常に典型的かつ一般的な組み合わせであり、Timeweb も例外ではありません。 ただし、それがどのように実装されているかを正確に理解することは興味深く、役立つ場合があります。

アパッチとNginx。 一本の鎖でつながっている

もちろん、そのような組み合わせを使用するかどうかは、お客様のニーズによって決まります。 Nginx と Apache は両方とも特別な役割を果たし、それぞれが特定の問題を解決します。

基本設定 アパッチ Apache 自体の設定ファイルで実行され、クライアント サイトの設定は、 .htaccess ファイル。 .htaccess は、クライアントが Web サーバーのルールと動作を個別に構成できる構成ファイルです。 この設定は、彼のサイトに特に適用されます。 たとえば、Apache 機能のおかげで、ユーザーは同じ PHP バージョン内で動作モードを mod_php から mod_cgi に変更できます。 リダイレクト、SEO のための最適化、便利な URL、PHP のいくつかの制限を設定できます。

nginx トラフィックを Apache にリダイレクトするプロキシ サーバーとして、また静的コンテンツを提供する Web サーバーとして使用されます。 また、アクセス権を分離するなど、ユーザーのデータを保護できる Nginx 用のセキュリティ モジュールも開発しました。

ユーザーがクライアントの Web サイトにアクセスしたと想像してみましょう。 まず、ユーザーは静的コンテンツを提供する Nginx にアクセスします。 それは瞬時に起こります。 次に、PHP をロードする際に、Nginx はリクエストを Apache に転送します。 そして、Apache は PHP と連携してすでに動的コンテンツを生成しています。

Timeweb の Apache と Nginx バンドルの機能

当社の仮想ホスティングは、Apache と Nginx の 2 つの主要な運用スキームを実装しています。 共有と専用.

共有スキーム

このスキームはほとんどのユーザーに使用されます。 これは、そのシンプルさとリソースの集中性によって区別されます。共有スキームは使用するリソースが少ないため、料金が安くなります。 このスキームによれば、サーバーは XNUMX つの Nginx を実行し、すべてのユーザー要求と Apache の複数のインスタンスを処理できるようになります。

共有スキームは長い間改善されてきました。徐々に欠点を修正してきました。 ソースコードを変更せずに実行できるのが便利です。

アパッチとNginx。 一本の鎖でつながっている
共有スキーム

専用スキーム

専用はより多くのリソースを必要とするため、顧客にとっての料金はより高価になります。 専用スキームでは、各クライアントは独自の個別の Apache を取得します。 ここのリソースはクライアント用に予約されており、排他的に割り当てられます。 仕組み: サーバー上には複数のバージョンの PHP があります。 バージョン 5.3、5.4、5.6、7.1、7.2、7.3、7.4 をサポートします。 したがって、PHP のバージョンごとに独自の Apache が起動されます。

アパッチとNginx。 一本の鎖でつながっている
専用スキーム

安全地帯。 Nginx でのゾーンのセットアップ

以前は、Nginx の場合、多くの共有メモリ ゾーン (ゾーン)、つまりドメインごとに XNUMX つのサーバー ブロックを使用していました。 この設定ではサイトごとに個別のゾーンが作成されるため、多くのリソースが必要になります。 ただし、Nginx 設定では、ほとんどのサイトは同じタイプであるため、モジュール内のマップ ディレクティブを使用することで XNUMX つのゾーンに配置できます。 ngx_http_map_module、対応関係を指定できます。 たとえば、サイトへのパス、PHP バージョン、ユーザーなどの変数を指定する必要があるゾーン テンプレートがあります。 これにより、Nginx設定の再読み込み、つまりリロードが高速化されました。

この構成により、RAM リソースが大幅に節約され、Nginx が高速化されました。

リロードが機能しません!

共有スキームでは、Web サイトの設定を変更するときに Apache をリロードする必要がなくなりました。 以前は、クライアントがドメインを追加したり、PHP バージョンを変更したりする場合、Apache の強制的なリロードが必要でした。これにより、応答が遅れ、サイトのパフォーマンスに悪影響が生じていました。

動的構成を作成することでリロードを排除しました。 おかげで mpm-itk (Apache モジュール)、各プロセスは別個のユーザーとして実行されるため、セキュリティ レベルが向上します。 このメソッドを使用すると、ユーザーとその document_root に関するデータを Nginx から Apache2 に転送できます。 したがって、Apache にはサイト構成が含まれておらず、それらを動的に受信するため、リロードは必要なくなります。

アパッチとNginx。 一本の鎖でつながっている
共有スキーマ構成

ドッカーはどうでしょうか?

多くの企業がコンテナベースのシステムに移行しています。 タイムウェブは現在、そのような移行の可能性を検討中です。 もちろん、どの決定にも長所と短所があります。

否定できない利点に加えて、コンテナ システムはユーザーに提供するリソースが少なくなります。 Timeweb では、説明したホスティング スキームのおかげで、ユーザーは RAM に制限がありません。 コンテナ内よりも多くのリソースを受け取ります。 さらに、ユーザーはさらに多くの Apache モジュールをロードしている可能性があります。

Timeweb は約 500 の Web サイトを支えています。 私たちは大きな責任を負い、複雑なアーキテクチャに対して即座に不当な変更を加えません。 Apache と Nginx の組み合わせは信頼性が高く、実績があります。 私たちは、独自の構成を通じて最大のパフォーマンスを達成しようと努めています。

多数のサイトを高品質かつ高速に運用するには、Apache と Nginx のテンプレートと動的構成を使用する必要があります。 これにより、多数の同様のサーバーを簡単かつ迅速に管理できます。

出所: habr.com

コメントを追加します