NGINXでPHP 7のパフォーマンスを最大化する方法（第1回）：Web配信とキャッシュ

NGINX | 2016年2月26日

はじめに – NGINXをPHPと組み合わせて使用する方法

PHPは、サーバーサイドWebアプリケーションの作成に最も広く利用されており、市場シェアは約80%です。（ASP.netが大きく離れて2位、Javaはさらに大きく離れて3位です。）

PHPの世界には数多くのPHPフレームワークがあり、特に人気が高いものとしてLaravel、Phalcon、Symfony 2が挙げられます。また、PHPは、WordPressやDrupalなどの一般的なコンテンツ管理システム（CMS）の基盤でもあります。（Drupalの最新リリースであるDrupal 8には、Symfony 2との大規模な統合が含まれています。

そして今、PHPチームは新バージョンの「PHP 7」をリリースします。PHP 5の登場から10年以上を経てのリリースです。この間、Webの利用とWebサイトに対する要求は、ともに飛躍的に増大しました。PHPはその急速な成長に貢献してきましたが、PHPが実現した成長そのものによって、PHPの限界も浮き彫りになっています。

PHPは一般に強力で柔軟性が高い一方、パフォーマンス上の問題を抱えやすいと見られています。PHPベースのサイトは、トラフィック量が数回倍増しただけで、容易に「限界に達する」ことがあります。サイトがビジネス上または運用上の目標を達成し始めた矢先に、トラフィック量が増えるたびにクラッシュするようになります。

非常に多くのPHPベースのアプリケーションでは、比較的簡単な変更だけでパフォーマンスを改善できました。たとえば、memcachedなどのツールを使用したキャッシュ、データベースのチューニング、NGINX Open SourceおよびNGINX Plusによるリバースプロキシと負荷分散です。NGINXはアプリケーションの応答性を大幅に向上させ、ユーザー数とトラフィック量の桁違いの増加に対応できるよう支援してきました。

このブログ記事は、PHP 7を使用するWebサイトのパフォーマンスを最大限に高める方法を解説する全2回シリーズの第1回です。今回は、PHP 7へのアップグレード、WebサーバーソフトウェアとしてのNGINX Open SourceまたはNGINX Plusの導入、URLの書き換え（リクエストを適切に処理するために必要）、静的ファイルのキャッシュ、動的ファイルのキャッシュ（アプリケーションキャッシュまたはマイクロキャッシュとも呼ばれます）に焦点を当てます。

次回のブログ記事では、サーバーを追加して実施できる対策に焦点を当てます。具体的には、リバースプロキシサーバーの追加、複数のアプリケーションサーバーへの移行、複数サーバー間の負荷分散、負荷分散時のセッション維持への対応、SSL/TLSや関連するHTTP/2プロトコルなどのセキュリティプロトコルの終端について説明します。

PHPが限界に達する理由

PHPアプリケーションが限界に達するのはなぜでしょうか。その理由は、あらゆるアプリケーションサーバーソフトウェアが限界に達する理由と同じです。ユーザーからリクエストを受けると、PHPと、その実行基盤であるWebサーバーソフトウェアは、いくつかの処理を行う必要があります。

リクエストを解析する。まずWebサーバーソフトウェアが、次にPHPが、リクエストを受信、解析、処理するためのプロセスを起動する必要があります。たとえばApache HTTP Serverは、JPEGファイルの取得のような単純なものでも、ネストされたCSSリクエストの処理のような複雑なものでも、データリクエストごとに処理用のリソースを割り当てます。これらにはすべて、時間、システムリソース、メモリ割り当てが必要です。リクエストの処理を開始する前にOSやPHP、またはその両方が多数のライブラリを読み込む必要がある場合、メモリ割り当ては非常に大きくなることがあります。
補助プロトコルを処理する。SSL/TLSやHTTP/2を使用している場合、Webサーバーソフトウェアはリクエストをデコードする必要があり、この処理には時間がかかる可能性があります。
リクエストを処理する. PHPは、リクエストの処理に必要なリソースを集約する必要があります。そのために、データベースへの複数回の呼び出し、インターネット経由での外部サービスの呼び出し、複雑な内部処理が必要になる場合があります。
リクエストに応答する。PHPは、リクエスト元にHTTPレスポンスとして返送できるよう、処理結果をWebサーバーソフトウェアに返す必要があります。WebサーバーソフトウェアとPHPはどちらも、リクエストを最初に受信してから最終確認が完了するまで、リクエストごとにアクティブな専用スレッドを実行している点に注意してください。

物理サーバー、仮想マシン、クラウドサーバーインスタンスのいずれにとっても、リクエストごとにこれだけの処理を行うのは大きな負荷です。物理環境か仮想環境かを問わず、サーバーマシンの物理メモリを使い切ると、パフォーマンスが低下しやすくなります。その後、新しいリクエストが届くたびに、サーバーは処理中のセッションをディスクへページングし始めます。また、ファイルリクエストの完了を待つことで待機状態が発生し、ページングがさらに増加します。ごく限られたしきい値を超えると、ページング処理とデータリクエストが処理能力を圧迫し、パフォーマンスが悪化の一途をたどります。その結果、ユーザーは長時間待たされ、場合によってはセッションが強制終了されることもあります。

パフォーマンスの問題への対処

PHPのパフォーマンス上の障壁は克服できますが、そのためには相互に補完し合う複数の対策が必要です。各対策は、ほかの対策と組み合わせて実施できます。主な対策は次のとおりです。

ハードウェアの増強で問題に対処する。メモリの増設、さらなるメモリの増設、ディスクの高速化、データベースサーバーの分離、コンテンツ配信ネットワーク、スループット容量の拡大など、ハードウェアに頼る方法は、パフォーマンス問題に手早く対処する手段です。こうした方法により、稼働時間を維持したり、パフォーマンスを直線的に拡張したりできる場合があります。
PHPとアプリケーションコードの改善。新しいバージョンのPHPや新しいフレームワーク、改善されたアプリケーションコードは、パフォーマンスの大幅な向上に役立ちます。新しいハードウェアに追加投資することなく、パフォーマンスを2倍、さらには4倍に高めることも可能です。
サーバーソフトウェアの改善。ほとんどのWebサーバーとPHPは、処理中の各リクエストに専用のリソースを割り当てます。NGINXサーバーソフトウェアは、リソースを占有することなく受信したリクエストを順次処理し、サーバーのリソース使用量を最小限に抑えます。
マルチサーバー構成。リバースプロキシサーバーを導入すると、インターネットからのリクエストを処理し、1台以上のアプリケーションサーバーに分散（負荷分散）できます。リバースプロキシサーバーでは、ファイルのキャッシュ、SSL/TLSやHTTP/2などのプロトコルの終端、複数のアプリケーションサーバーの管理も行えます。アプリケーションサーバーが1台だけの場合でも、そのワークロードの大部分をオフロードできます。サーバーを追加した場合も、負荷分散により、特定のサーバーに割り当て分を超える負荷が集中することはありません。

これらの手順は、特定の順序で実施する必要はありません。たとえば、ApacheをWebサーバーとして引き続き使用し、アプリケーションサーバーをPHP 7にアップグレードしない場合でも、既存のサーバーの「前段」にリバースプロキシとしてNGINXを導入するだけで、パフォーマンスが向上し、複数のアプリケーションサーバーを並列に運用できるようになります。

どのような方法を選ぶにせよ、覚えておくべき重要な点は、現在のアプリケーションコードをほとんど、あるいはまったく変更せずに、パフォーマンスを数倍に高め、さらには処理能力を10倍規模に拡大できるということです。こうした大幅なパフォーマンス向上をすでに実現した事例や、現在実現に取り組んでいる事例について、引き続きご覧ください。

注記：これらのブログ記事では、マルチサーバーによる最適化については詳しく取り上げません。データベースサーバーを分離し、コンテンツ配信ネットワーク（CDN）を利用することで、アプリケーションサーバーの負荷を軽減し、パフォーマンスを大幅に向上させることができます。このような変更は、ここで説明するアプリケーションおよび実装の改善とは別個のものであり、並行して実施できます。

ヒント1 – PHP 7にアップグレード

PHP 7へのアップグレードを早めに行う最大の理由はシンプルです。メモリ使用量の削減によって大幅に向上するアプリケーション速度です。PHP 7は、以前のバージョンのPHPと比べて2倍高速で、メモリ使用量も大幅に少ないとされています。（速度とメモリ使用量のいずれも、実際の効果は環境によって異なります。）

端的に言えば、応答時間はWebアプリケーションにとって極めて重要です。高速なWebアプリケーションは、メモリ使用量も少ないため、ページスワッピングとそれに伴うパフォーマンス問題が発生する可能性を低減し、次の3つの効果をもたらします。

ユーザーの満足度が高まり、サイトを訪れて、記事を読む、製品情報を入手する、乗合タクシーを呼ぶ、空き部屋を借りる、商品を購入するといったタスクを完了する可能性が高まります。つまり、そもそもサイトやアプリを作成した目的を達成しやすくなります。
特定のサーバーで、ユーザーの増加による速度低下や、最悪の場合は停止に陥るリスクを抑えながら、より多くのユーザーに対応できるようになります。破綻を先延ばしにできるのは、いつでも良いことです。
サーバーに過剰な負荷をかけて稼働を停止させるハッカー攻撃に対し、サーバーの脆弱性を低減します。今日では誰もが攻撃の標的になりますが、脆弱な対象ほど攻撃の頻度が高く、手口も激しくなります。そのため、脆弱性を低減することで、飛躍的に大きな効果が得られる可能性があります。

これらはいずれもアップグレードすべき十分な理由であり、総合的に見れば、アップグレードしない手はないように思えます。また、明確なパフォーマンス向上が見込めない場合でも、多くの問題を解決するために、まず「最新バージョンへのアップグレード」が推奨されます。では、なぜ誰もがすぐにアップグレードするわけではないのでしょうか。

xkcdが描くアップデート

理由は単純です。古いコードには手を加えたくないものですし、それにはもっともな理由があります。古いアプリが十分に機能しており、開発者にとって古いアプリをアップグレードするよりも新しいアプリを作成する方が良い成果につながるのであれば、その古いアプリは変更されないまま、非常に長い間使われ続ける可能性があります。（現在のWebサーバーやアプリに変更を加えず、NGINXを使用してアプリのパフォーマンスを向上させる方法については、このシリーズの2つ目のブログ記事をご覧ください。）

ただし、可能であれば、パフォーマンス向上への取り組みはPHP 7へのアップグレードから始めるのがより効率的です。特にテストを省略せず、最後まで完了できる十分な時間を確保してから着手してください。

PHP 7へのアップグレードに必要な作業を見ていきましょう。

式の評価方法の変更。PHP 7で一部の式が正しく評価されるように、式の記述方法を変更する必要がある場合があります。（または、慎重を期してすべてのPHPサーバーを一度にアップグレードしない場合は、PHP 5.6とPHP 7の両方で正しく評価されるように変更する必要があります。）可変変数または可変プロパティを使用している場合は、両方のPHPバージョンで同じように評価されるよう、コードを修正する必要があります。
構文の変更。PHP 7はASPタグやscriptタグをサポートしていません。switch文に複数のdefaultケースを含めることはできません。（ここでは、論争のあるswitchとif-then-elseの比較については触れません。）
非推奨機能の削除。さまざまな機能PHPの各5.xバージョンで非推奨となった機能は、今や死んだオウムよりも完全に息絶えています。PHP 7ではまったく動作しません。こうした機能がコードに含まれており、すべて削除しようとしても削除しきれなければ、Cyber Monday前夜の午後11時59分には、ショッピングカートのコードが確実に機能しなくなるでしょう。
新機能。PHP 7には、古いコードをアップグレードする人にとって魅力的な新機能が数多く追加されていますが、コードのクリーンアップ時に新機能を追加する場合は注意が必要です。新機能はたいてい優れたものです。そうでなければ追加されていないでしょう。しかし、自分や他者が原因のバグを招きやすく、PHPがさらにアップグレードされると、将来的な修正が必要になる可能性もあります。
一般的なコードレビュー。コードに手を加えたときはもちろん、コードファイルを開いただけで変更したかどうか確信が持てない場合でも、ファイル全体、特に変更した箇所を必ずレビューする必要があります。
テスト。すべてを常にテストする必要があります。何らかの変更を加えた場合は、すべてを再テストする必要がありますが、それでもすべてのバグを発見できるとは限りません。適切に実装されたDevOps環境であれば、このテストは比較的容易になる可能性があります。しかし現時点では、そのような理想的な環境を実現できているケースはごくわずかです。

Engine Yardのこちらの「ブログ」では、これらの問題の大半について、分かりやすい例を紹介しています。

PHP 7へのアップグレードを進める場合は、PHP 7の新機能を活用し、コード全体、または少なくとも重要な機能について、パフォーマンスを全面的に見直して改修することをご検討ください。ご自身とチームのスキルを高めるうえで、これ以上の方法はありません。また、今行う変更、レビュー、テストは、今後何年にもわたって役立つ可能性があります。最適化されたコードは、最適化された環境で実行することで大きな効果を得られるため、このブログ記事で紹介しているその他のパフォーマンス改善策も最大限に活用できます。

そのため、アプリケーションコードに手を加えずにパフォーマンスを向上させる目的でNGINXを導入するサイトは多いものの、思い切って移行を進めることをお勧めします。移行に役立つさまざまな情報を利用することも、自ら移行作業に取り組むこともできます。PHP公式サイトには「PHP 7移行ガイド」があり、O’Reillyからは「PHP 7アップグレード実践ガイド」が提供されています。

ヒント2 – NGINX Open SourceまたはNGINX Plusを選択

NGINXは、1億4,000万を超えるWebサイトで稼働しているソフトウェアです。その中には、アクセス数上位10,000サイトの半数も含まれます。（この測定では、単一サーバー構成のサイトではWebサーバーを、複数サーバー構成のサイトではリバースプロキシサーバーを検出しています。）Webサーバーとしては、NGINX Open SourceとNGINX Plusのどちらもすぐにパフォーマンスを向上できます。ほかのソフトウェアを実行するサーバーが過負荷に陥り、スラッシングが発生している場合などには、最大10倍の向上が見込めます。リバースプロキシサーバーとしては、どちらも複数の専用サーバーを使用できるため、必要な規模までデプロイメントをスケールアウトできます。

PHPとApacheはいずれも、処理中の各リクエストにリソースを割り当てます。どちらか一方または両方が多数のライブラリを読み込む必要がある場合、リクエストごとの起動時間とメモリ使用量が大幅に増える可能性があります。WebサーバーソフトウェアをNGINXに移行すると、この問題をサーバーレベルで解消できます。NGINXの機能を使用して、静的ファイルの配信などの処理をWebサーバーに、各種キャッシュ、プロトコル終端、負荷分散などの処理をリバースプロキシサーバーにオフロードすることで、PHPが担う処理を最小限に抑え、アプリケーション処理を簡素化、高速化できます。

サイトでカスタムまたは独自のApacheモジュールを使用している場合、それらのモジュールを置き換えるまでは、ApacheをNGINXに置き換えられない可能性があります。簡単な回避策があるかどうかをNGINXに確認してください。ない場合は、変更に必要な時間と工数を見積もります。

NGINXの採用を決定したら、NGINX Open SourceとNGINX Plusのいずれかを選択できます。NGINX Open Sourceと比較したNGINX Plusの主な機能は次のとおりです。

Precompiled code. NGINX Plus is distributed in compiled form, including popular libraries and dynamic modules that you can add and remove on the fly. (NGINX Open Source is available as both compiled and uncompiled code.) You can make a wide range of configuration changes without restarting the server.
サポート。NGINX Plusには、NGINXのエンジニアに直接問い合わせることができるサポートパッケージが含まれています。
監視と管理。DevOpsに適したツールにより、サービスレベル契約（SLA）を満たせるよう、サーバーの安定稼働を支援します。

リバースプロキシサーバーとして、NGINX Plusにはさらに次の利点があります。

負荷分散。どちらのバージョンのNGINXも基本的なHTTP負荷分散をサポートしていますが、NGINX Plusでは、より高度なアルゴリズムとTCP負荷分散も利用できます。
セッション維持. NGINX Plusは、ロードバランシングに加えて、より高度なセッション維持機能を提供します。これは、PHPアプリケーションサーバーにとって特に重要となる場合があります。
監視と管理。マルチサーバー環境では、NGINX Plusの監視と管理が備えるあらゆる機能を活用できます。また、より複雑な実装では、プリコンパイル済みコードとサポートの価値も最大限に高まります。

NGINX Open SourceとNGINX Plusは、どちらもコンテンツキャッシュとマイクロキャッシュ（別名「アプリケーションキャッシュ」）をサポートしています。Webサーバーでのキャッシュは、アプリケーションサーバーの負荷軽減に役立ちますが、両方の機能が同じ物理マシンまたは仮想マシンインスタンスを共有することに変わりはありません。リバースプロキシサーバーでキャッシュを使用すると、アプリケーションサーバーデバイスの処理負荷を大幅に軽減できるため、パフォーマンス面でより大きなメリットが得られます。

NGINX Open Sourceソフトウェアは、nginx.orgから直接ダウンロードできます。また、同サイトではコミュニティサポートも利用できます。NGINX Plusの単一サブスクリプションを開始するには、30日間の無料トライアルに登録するか、オンラインで購入してください。複数インスタンスのバンドルについては、NGINX営業部門までお問い合わせください。

ヒント3 – Apache設定をNGINX構文に変換

WebサーバーソフトウェアをApacheからNGINXに移行する際には、いくつかの変更が必要です。詳しくは、記事（sitepoint.com）をご覧ください。

設定ファイルを作成または変換する。設定コードを変更し、ApacheではなくNGINXが設定に使用するファイルを指定します。
読み取り／書き込み権限を変更する。Webサイトのルートディレクトリ内のファイルに対してCRUD操作（作成、読み取り、更新、削除）を実行できる権限をアカウントに追加します。
有効な検索パターンを指定する。locationブロックを追加し、リクエストの処理中にNGINXが試行できるパターンと試行できないパターンを指定します。
.htaccess設定コードを置き換える。Apacheの設定情報は通常、.htaccessファイルまたは静的設定ファイル（たとえば、mod_rewriteディレクティブ）に記述されています。これらを、NGINX設定ファイル内の該当する設定に置き換えます。例については、F5のブログをご覧ください。

これらの変更を行うことでNGINXに慣れ、このブログ記事のPart 2で説明する、より複雑なサイトの最適化に備えることができます。ただし、こうした構成変更に伴う作業量やサイト運用上のリスクが許容できない場合でも、ご安心ください。コアWebサーバーソフトウェアをApacheからアップグレードすることなく、したがってWebサーバーの構成ファイルを変更することなく、Part 2で説明するマルチサーバーアーキテクチャを実装できます。

ヒント4 – 静的ファイルのキャッシュを実装する

静的ファイルとは、少なくともWebサーバーの観点では、頻繁に変更されないファイルのことです。通常、JPEGやPNGなどの画像ファイル、CSSやJavaScriptなどのコードファイルが含まれます。これらのファイルをアプリケーションサーバーまたは別のデータベースサーバーに配置すると、そのリクエストをアプリケーションコードで処理する必要があり、リクエストの生成と処理に伴うあらゆるオーバーヘッドが発生します。その結果、アプリケーションサーバーがより重要な処理に集中できなくなり、物理メモリが過負荷となって、新しいリクエストによって処理中のリクエストがディスクへページアウトされる状態に近づく可能性があります。

静的ファイルのキャッシュは、NGINXの中核機能です。Webサーバーまたはリバースプロキシサーバーに実装できます。

NGINX Webサーバーで静的ファイルをキャッシュすると、アプリケーションサーバーの負荷が軽減され、メモリのオーバーヘッドを大幅に抑えながら、ファイルをより高速に取得できます。ただし、ファイルの取得には引き続き同じ物理サーバーまたは仮想サーバーインスタンスが使用されるため、サーバーのプロセッサーはアプリケーションの実行以外のタスクにも対応する必要があります。
NGINXリバースプロキシサーバーはWebサーバーとは別のマシンまたはインスタンスで稼働するため、静的ファイルをキャッシュしてもアプリケーションサーバーのリソースを消費しません。これにより、アプリケーションサーバーはアプリケーションの実行だけに専念できます。

NGINXで静的ファイルのキャッシュを実装するには、大きく分けて3つの手順があります。

検索対象のルートディレクトリを指定する。
リクエストの処理。
応答速度の最適化。

リバースプロキシサーバーを介さないNGINX Webサーバーでは、通常の意味でのキャッシュは行いません。代わりに、X-Accel-Redirectヘッダーを使用して、静的ファイルへのリクエストをWebサーバーにリダイレクトするだけです。アプリケーションサーバーにはリクエストが届かないため、すべてのリソースをアプリケーションへのリクエストに充てることができます。リバースプロキシサーバーを使用する場合は、静的ファイルをキャッシュします。そのため、アプリケーションを実行する物理サーバーまたは仮想サーバーインスタンスは、静的ファイルへのリクエストの処理には一切関与しません。

応答速度を最適化する例として、次の設定スニペットでは、NGINXがオペレーティングシステムのsendfileシステムコールを使用できるようにします。これにより、ファイルを中間バッファーにコピーする必要がなくなり、ファイル転送の手順を1つ省略できます。

location /mp3 {    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

NGINXで静的ファイルのキャッシュを設定する方法について詳しくは、「NGINX Plus管理者ガイド」を参照してください。

ヒント5 – マイクロキャッシュを実装する

紛らわしいことに、マイクロキャッシュにはさまざまな呼び方があり、アプリケーションキャッシュや、単にキャッシュとも呼ばれます。NGINXでは、このようなファイルの有効期間が短いことを強調するために、マイクロキャッシュという用語を使用しています。

ユーザーがコメントを投稿できるブログ記事ページがあるとします。新しい訪問者がページを開いたときや、既存のユーザーが自分または他のユーザーの新しいコメントを確認するためにページを更新したときには、常に最新のコメントを表示したいと考えるでしょう。この場合、誰かがページにアクセスするたびにページを新たに生成するのがよさそうです。

しかし、「毎回」となると負荷が大きくなる可能性があります。ページへのアクセスが1秒に1回なら、アクセスのたびにページを新たに生成するのは合理的です。しかし、そのページへのアクセスが1秒に10回、100回、1,000回に増え、さらにサイト内の他のすべてのページへのアクセスも加わると、アプリケーションサーバーが過負荷になる可能性があります。最新のコンテンツを提供しようとした結果、誰もコンテンツをすぐに受け取れなくなってしまいます。

マイクロキャッシュとは、ページを一度生成し、そのキャッシュ版を短時間（たとえば1秒から数秒）だけ有効にする仕組みです。キャッシュ版の有効期限が切れると、次のリクエストを契機に新しいページが生成され、その直後のリクエストにはキャッシュ版が返されます。これは静的ファイルと同じ動作ですが、はるかに短い時間単位で行われます。

この画像は、サイト内でマイクロキャッシュ可能なコンテンツを探す場所を示しています。F5のOwen Garrettによる「マイクロキャッシュに関するブログ記事」からの引用です。

多くの動的コンテンツはマイクロキャッシュに適しています

マイクロキャッシュの優れた点は、アプリケーションサーバーの負荷軽減が最も必要なタイミングで処理を肩代わりしながら、ユーザーへの悪影響をほとんど、あるいはまったく生じさせないことです。その有用性から、一部のシステムには標準で組み込まれています。Drupalでは、堅牢な組み込みのマイクロキャッシュ機能が不可欠と考えられているため、Drupalの世界ではマイクロキャッシュを単に「キャッシュ」と呼びます。

しかし、Drupalのソリューションにはやや不十分な点があり、同様のソリューションも例外ではありません。アプリケーションサーバーの処理は減りますが、構成、実装、ファイル配信を管理するのは依然としてDrupal（より一般的にはPHP）です。NGINXでマイクロキャッシュを使用すると、アプリケーションサーバーが担うのは、マイクロキャッシュで指定された頻度で新しいページを生成する処理だけになります。その他のリクエストはアプリケーションサーバーに届かないため、キャッシュヒット時にデータを保存したり取得したりする必要もありません。

NGINX Plusなどのツールを使用してサイトを監視すると、マイクロキャッシュが有効なページを確認できます。次の設定スニペットでは、ステータスコードが200 OKのレスポンスに対して、1秒間のキャッシュ期間を設定します。

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

第1部のまとめ

このPHPブログ記事の第1部では、シングルサーバーソリューションとキャッシュに焦点を当てます。キャッシュはシングルサーバー構成でも効果的ですが、リバースプロキシサーバーを組み合わせることで、さらに高い効果を発揮します。第2部では、リバースプロキシサーバーのメリットと、PHPアプリケーションを中心としたマルチサーバー構成について説明します。

NGINX Plusをお試しいただくには、今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。