みなさん、こんにちは!
ブリュの公式ブログ.netにお越しいただきまして、ありがとうございます。
このサイトでは、ITについて特化したサイトを運営しています。
皆さんはレンタルサーバーを選ぶときに技術的側面を見て選んでいますか?
実は、レンタルサーバーの長所・短所は、ウェブサーバーの種類、PHP動作モードの種類などの技術的な側面からある程度の分類が可能です。
よって、技術的な部分に関しての理解があれば、サーバーのスペックを眺めるだけでおおよその特徴が理解できるようになるので、他人のブログを読まなくても、自分の力でレンタルサーバーを選べるようになるんです。
いろんなサイトでレンタルサーバーの性能について語られていますが、
- 速い!
- 遅い!
- 安定感がある!
など、根拠を示しているサイトは皆無。
そんなレンタルサーバーの技術的な側面について、詳細を解説します。
目次
サーバーの三層構造
サーバーは一個に見えていますが、実際には三層構造となっています。
三層構造とは、
- ウェブサーバー
- アプリケーションサーバー
- データベースサーバー
のことです。
サーバー全体のイメージ図は次のようになります。
なんで三層構造などという面倒な構造になっているのかというと、拡張性を高めるためです。
例えば、より高性能なものや故障などによって、サーバーの動的処理の部分だけを交換したくなった場合を考えてみましょう。
もしも3層構造になっていなければ、サーバー全体の交換が必要になり、コストがかかってしまうため、手軽に高性能化できなくなります。
一方の三層構造を利用していれば、アプリケーションサーバーのみを交換し、ウェブサーバーとデータベースサーバーは、そのまま既存のものを利用することができます。
そのため、ウェブサーバー、アプリケーションサーバー、データベースサーバーの接続部分には一定の規格があり、すべての製品が、その規格に沿って設計しなければなりません。
この三層構造の導入によって、インターネットの速い進化を実現しているとも言えます。
ウェブサーバー
パソコンでアクセスするのがウェブサーバーであり、リクエストを返してきます。
WordPressでいうならばFTP接続できているのがウェブサーバーの領域ということになります。
ファイルやフォルダを置いており、基本的に動的処理は行いません。
画像やHTMLなどの静的なコンテンツの送信を行い、またアプリケーションサーバーの実行結果であるPHPなどの動的コンテンツの結果を送信する際に活躍します。
動的処理に関してはアプリケーションサーバーに依頼します。
この依頼するときの、アプリケーションサーバーの制御方式のことを、PHPの動作モードといいます。
ウェブサーバーとPHP動作モードを混同している方が多いので、この点には注意です。
アプリケーションサーバー
アプリケーションサーバーは、ウェブサーバーからの指令を受けてPHPなどの動的処理を実行するサーバーです。
アプリケーションサーバー単体では動くことができず、ウェブサーバーからの指令によって動作します。
アプリケーションサーバーは動的処理を実施する際に、必要となる情報をデータベースサーバーに問い合わせます。
WordPressでいうなら、記事内容が該当します。
データベースサーバーに格納されている記事内容を参照しながら、動的にページを作成していくのがアプリケーションサーバーの仕事です。
データベースサーバー
データベースサーバーは、アプリケーションサーバーが動作する際のデータを提供します。
WordPressでいえば、PHPMyAdminでアクセスしている部分がデータベースサーバーとなります。
データベースサーバーはアプリケーションサーバーからの情報の要求に対して高速に応答する必要があるので、高性能なほどサーバー全体の動的処理性能は高くなります。
データベースサーバーの内容に基づいてアプリケーションサーバーが動的にページを生成し、結果をウェブサーバーが送り返すことで、やっとウェブページが見れるということになります。
ウェブサーバーとPHP動作モードの一覧
さて、ここでクローズアップするのは、ウェブサーバーとPHP動作モードです。
ウェブサーバーは、
- Apache
- Nginx
- LiteSpeed
があり、組み合わせたものとして、
- Nginx+Apache
があります。
一方でPHP動作モードには、
- CGI版
- FastCGI
- モジュール版
- LSAPI
があります。
何がどのように優れているのかについて説明していきます。
ウェブサーバーの種類とメリット・デメリット
さて、ここからはウェブサーバーの違いについて紹介をしていきます。
レンタルサーバーにおいて実用されているウェブサーバーには大きく分けて、
- Apache
- Nginx
- Nginx+Apache
- LiteSpeed
があります。
これらの違いについてみていきます。
Apache
Apacheは標準的なウェブサーバーの基準といえます。
後発のNginxやLiteSpeedは、基本的にApacheのデメリットを補う形で設計がされています。
Apacheの最大の特徴は、Apache自身がPHPを処理できることです。
すなわち、モジュール版PHPが実行できます。
モジュール版PHPであれば、ウェブサーバーでPHPの動的処理を行うので、アプリケーションサーバーが不要になります。
Apacheのデメリットとしては、アクセスが増えると同時にプロセスが生成され、メモリも消費していき、アクセス集中時にサーバーダウンが生じやすいことです。
下の図は、アクセスがあるごとにメモリを消費していくのをイメージしています。
これでは、メモリが足りなくなったらサーバーが極端に遅くなったり、最悪の場合にはサーバーダウンになります。
そのため、同じメモリであってもより多くのアクセスを処理できるようにと、後述のNginxが開発されました。
Nginx
NginxはApacheのC10K問題を解決するために開発されました。
C10K問題とは、海外のとある企業のホームページで生じた問題であり、
- C:クライアント
- 10K:1万人
という意味であり、1万人の同時アクセスがあるとApacheのサーバーがダウンするという意味です。
Apacheの時と同じメモリで、1万人の同時アクセスに耐えるために開発されたのがNginxです。
Nginxでは、限られたメモリで可能な限り多くのリクエストを処理しようとします。
下のイメージ図では、一部のメモリを使って、数多くのリクエストを処理するイメージを描いています。
Nginxでは、限られたメモリで数多くのリクエストを処理するために、複数のリクエストを交互に処理するアルゴリズムが組み込まれています。
具体的には、Nginxで処理する際に、動的処理の部分はアプリケーションサーバーに依頼します。
この依頼している間、Nginxでは何もやることがないのでその処理を中断し、次の処理を行います。
そして、アプリケーションサーバーからの応答があると、先ほどの処理に戻り、続きを処理します。
こうして、限りあるメモリで断続的な処理を行い、より多くのリクエストの処理を行うのがNginxになります。
なお、Nginxのデメリットとしては自分自身でPHPを実行できない点です。
かならずアプリケーションサーバーでPHPの動的処理を行います。
そのため、Nginxでモジュール版PHPを実現することは不可能になります。
Nginx+Apache
NginxとApacheは組み合わせて使われることが多いです。
ApacheはPHPの処理を行うことができ、NginxはApacheの負荷を軽減することができます。
また、Nginxの弱点であったPHPを実行できないという点においても、Apacheを採用していることからモジュール版動作も可能になります。
お互いの長所を生かしあえるのが、Nginx+Apacheのサーバーです。
なお、Nginx+Apacheのサーバーの場合、前段に置かれるNginxのことをリバースプロキシといいます。
リバースプロキシは、Apacheの負荷を抑えるだけではなく、複数のサーバーに負荷分散を行うことも可能です。
このリバースプロキシの技術により、IPアドレス的には一個のサーバーに見えても、実際にはリバースプロキシの後ろでは複数のサーバーが稼働しているなんてことも可能になります。
LiteSpeed
LiteSpeedは、Apacheの完全互換となっており、開発の思想としてはNginx+Apacheと似たようなものです。
それならばLiteSpeed自体はどんなメリットがあるサーバーなのかということになりますが、この点については、NginxやApacheと比較する形で、後ほど紹介していきます。
とりあえずウェブサーバーの紹介はここまでにして、次にPHP動作モードの紹介をします。
PHP動作モードの種類とメリット・デメリット
PHP動作モードには、
- CGI版
- FastCGI
- モジュール版
- LSAPI
があります。
CGI版
CGI版はPHPの基本的動作です。
アクセスがあるたびに
- プロセスの生成
- 処理
- プロセスの終了
を行います。
CGI版PHPの最大の難点は、毎回毎回プロセスの生成を行うことです。
よって遅いのが難点であり、解決策として後述のFastCGIが開発されました。
FastCGI
FastCGIは、CGI版PHPをベースとし、アクセスがあれば処理完了後にも一定時間プロセスを維持します。
これによって、次のアクセスが来た際に、プロセスの生成の時間を省くことができ高速化できます。
FastCGIのデメリットとしては、アクセスが少ない場合にはプロセスを維持していても、次のアクセスがあったときにはすでにプロセスが破棄されている可能性があるということです。
こうなると結局はCGI版PHPと同じように、毎回毎回プロセスの生成から行うことになるので、FastCGIのメリットを全く生かせていないことになります。
モジュール版
モジュール版はApacheで可能なPHPの動作モードです。
上記のCGI版やFastCGIと大きく異なる点としては、CGIやFastCGIが動的処理をアプリケーションサーバーで処理を行うのに対し、モジュール版PHPはウェブサーバーで動的処理を一括処理します。
よってプロセスは常に保持されている状態となります。
言い換えるなら、いつアクセスされてもFastCGIの最適な状態と同等になるといえるでしょう。
ウェブサーバーと一体化しているモジュール版PHPには、そもそも起動や終了という概念がありません。
モジュール版PHPが終了するときは、ウェブサーバー自体が停止した時であり、サーバーにアクセスできる状態においては常にスタンバイ状態になっています。
モジュール版PHPの良いところは、アクセスが途絶えても、FastCGIのように極端に遅くはならず、速度が一定している点です。
逆にデメリットとしてはユーザー単位でのプロセスの制御が難しいというところです。
FastCGIの場合にはユーザー単位でのプロセス制御が可能なのですが、モジュール版PHPはウェブサーバーと一体化している関係上、ユーザーごとにプロセスの細かい制御を行うのが難しい点です。
また、モジュール版PHPはウェブサーバー自体で動的処理を行う関係上、Nginxでは実現できない動作モードです。
Nginxでは動的処理は必ずアプリケーションサーバーで行う必要があり、モジュール版という概念がそもそも存在しません。
LSAPI
LSAPIはFastCGIと似た動作をするPHP動作モードになります。
動作の説明においてはFastCGIと同じになるので違いを説明しにくいのですが、FastCGIよりもコンテンツを表示する動的処理に向いている動作モードです。
FastCGIよりもチューニングの幅が広いということもできるでしょう。
FastCGIと比較したときのLSAPIの最大の特徴はキャッシュが強力であることであり、WordPressのような、
- ヘッダー
- サイドバー
- フッター
のデザインが常に固定の場合であれば、実行結果をキャッシュしてしまうので、FastCGIよりも圧倒的に高速になります。
キャッシュをうまく利用することでLSAPIの高速性能を最大限に生かせるという表現で問題ないでしょう。
逆にLSAPIのデメリットとしては、キャッシュが効きすぎるのでウェブサービスには向きません。
例えば、アクセスカウンターを設置している場合には、アクセスがあるたびにカウントアップを行うのでリアルタイムの更新が必要になります。
したがって、FastCGIでも問題なく動作したアクセスカウンターをLSAPIに移動させた場合、LSAPIでは妙な部分でキャッシュが効き、正常動作をしなくなる可能性が高いです。
よって、
- キャッシュが効いてほしいならLSAPI
- キャッシュがあまり効いてほしくないならFastCGI
がいいといえます。
WordPressのような、パーツごとにキャッシュが効いてほしいならLSAPIで、ウェブサービスのようにリアルタイムの更新が必要ならFastCGIということです。
なお、LSAPIはLiteSpeed専用のPHP動作モードのようなイメージを持つ方が多いのですが、LiteSpeed社が開発したというだけであり、NginxやApacheでLSAPIを選択することも可能です。
PHP動作モードとしてLSAPIを選べることは、LiteSpeedの専売特許ではないということも、しっかりと覚えておいてください。
NginxとLiteSpeedはどちらが速いのか?
ここからは具体的な話になります。
NginxとLiteSpeedの場合で、どちらも同じスペックで同じPHP動作モードを採用した場合に、どちらが早いのかという点についてみていきましょう。
NginxとLiteSpeedはスレッドレベルでの違いがある
例えばですが、NginxとLiteSpeedのそれぞれを同じPHP動作モードであるLSAPIで動かしたとしましょう。
この場合、NginxとLiteSpeedはスレッドレベルでの違いがあるということで、基本的な考え方は似ています。
結論としては、単発の処理においてはマイクロ秒(10万分の1秒単位)での差はあるのですが、それ自体に大きな意味があるわけではありません。
一方、レンタルサーバーとして商品となるレベルまで、サーバーにプラグインなどを詰め込んで動作させた場合には、圧倒的にLiteSpeedのほうが高速になります。
言い換えるなら、NginxとLiteSpeedの差は本当にわずかなのですが、小さい差が積み重なって、最終的にLiteSpeedが速くなる。
また、処理に関しても全体として最適化されているのはLiteSpeedとなります。
Nginxには致命的なデメリットがある
また、そもそもの話となるのですが、Nginxでは.htaccessを利用できません。
既存のウェブサーバーの多くがApacheであり、Apacheからの入れ替えとしてNginxを採用すると、.htaccessが利用できなくなってしまいます。
これはNginxの最大のデメリットであり、Apacheとの互換性が全くないのが、より導入を難しくしています。
その点、LiteSpeedはApacheの完全互換なので、Apacheで動作する.htaccessなどはそのまま利用できることになります。
Nginxでも.htaccessを利用できるのはなぜ?
なお、エックスサーバー をはじめとするNginxを採用しているレンタルサーバーは.htaccessを利用できると公式サイトに書いています。
しかし、これはNginxをリバースプロキシとして採用しているだけであり、ウェブサーバー本体、つまりはFTP接続でファイルをアップロードしている領域はApacheになります。
だから、nginxでも.htaccessを利用できるのではなく、ウェブサーバー本体がApacheだから、.htaccessを利用できると考えるほうが正解なのです。
要は、先ほどウェブサーバーの種類で説明したNginx+Apacheに該当するわけです。
ApacheとLiteSpeedの違いは?
次にApacheとLiteSpeedの性能差について説明していきます。
Nginx+Apacheのサーバーは結局Apacheと同じ
先にApacheとLiteSpeedを比較する上での前提条件を書いておきたいのですが、Nginx+Apacheのサーバーも結局はApacheという部分です。
リバースプロキシとしてNginxでApacheの負荷を減らしていることは事実ですが、動的処理に関してはApacheが行うので、結局のところサーバーの本来の性能としてはApacheと同等ということになるのです。
何を言いたいのかというと、ConoHa WINGもエックスサーバー もApacheであり、Nginxだから速いと書いているサイトはすべて間違いだってことです。
ApacheとLiteSpeedにLSAPIを組み合わせたら?
さて、ApacheとLiteSpeedのそれぞれに、LSAPIを組み合わせるとどうなるかを考えていきましょう。
具体的なレンタルサーバー名で説明するのであれば、
- MixHost (LiteSpeed+LSAPI)
- ConoHa WING(Nginx+Apache+LSAPI)
ならば、どっちが速いのか?ということになります。
結論としましては、ApacheとLiteSpeedの違いは、速さというよりは、他人の影響を限りなく受けにくいのがLiteSpeedになります。
先ほど説明しましたように、NginxはApacheの欠点を補うように設計がされました。
よって、LiteSpeedは、Nginx+Apacheの欠点を補うように設計がされています。
したがって、Apacheでは難しかったユーザー単位でのリソースの切り分けを、LiteSpeedは簡単に行えるということになります。
言い換えるのであれば、よりVPSに近いのがLiteSpeedといえます。
VPSとは仮想専用サーバーのことであり、物理的なサーバー本体は共用でも、空間そのものは完全に隔離されているようなサーバーのことです。
MixHost のLiteSpeedの場合には、Apacheと比較して、よりVPSに近いレンタルサーバーということになります。
Mixhostのスペックにおいて、CPUやメモリに関して一人当たりの割り振りが明記されているのも、LiteSpeedのなせる業ということですね。
Apacheのレンタルサーバーで一人当たりの割り振りを明記しているレンタルサーバーは、ほぼ存在しません。
ウェブサーバーとPHP動作モードのまとめ
ここまでの話をまとめます。
ウェブサーバーの性能のまとめ
まずはウェブサーバーの性能についてまとめます。
- Apache
- Nginx
- Nginx+Apache
- LiteSpeed
のそれぞれのサーバーにおいて、
- 高負荷時の安定性
- ユーザー単位の切り分け
- 全体としての最適化
についての比較表を書けば、次のようになります。
Apache | Nginx | Nginx+Apache | LiteSpeed | |
高負荷時の安定性 | 低い | 高い | 高い | 高い |
ユーザー単位の切り分け | 難しい | 難しい | 難しい | 容易 |
全体としての最適化 | 良い | 悪い | 良い | 良い |
PHP動作モードの性能のまとめ
次に、PHPの動作モードの性能についての比較結果をまとめます。
- CGI
- FastCGI
- モジュール
- LSAPI
のそれぞれのPHP動作モードにおいて、
- 単発アクセスの速度
- 連続アクセスの速度
- キャッシュの効き具合
- (相対的に)向いている用途
- (相対的に)向いていない用途
の指標でまとめれば、次の表になります。
CGI | FastCGI | モジュール | LSAPI | |
単発アクセスの速度 | 遅い | 遅い | 高速 | 遅い |
連続アクセスの速度 | 遅い | 高速 | 高速 | 最高速 |
キャッシュの効き具合 | 低 | 低 | 低 | 高 |
向いている用途 | ウェブサービス | ウェブサービス | ウェブサービス WordPress |
WordPress (Best) |
向いていない用途 | WordPress (CGIはそもそも遅い) |
WordPress (LSAPIの方がBetter) |
— | ウェブサービス (キャッシュが強いため工夫が必要) |
※連続アクセス時とは、目役として月間2万PV以上です。
※連続アクセス時のPV数の目安はユーザー単位であり、ドメイン単位ではないです。これは手持ちのサイトの合計PV数が2万PV以上であれば、LSAPIの効果を十分に発揮できるという意味になります。
代表的なレンタルサーバーのウェブサーバーとPHP動作モード一覧
代表的なレンタルサーバー会社のウェブサーバーとPHP動作モードについてまとめます。
それぞれのリンクでレンタルサーバー会社にジャンプできるので、実際に公式サイトでいろいろ見比べてみてください。
なお、レンタルサーバーの性能に関してはすべて総合性能で決まります。
ウェブサーバーやPHP動作モードが優れていても、
- メモリの大きさ
- 一台のサーバーに割り振るユーザーの数
- ほかのユーザーの影響
- 回線速度
- アプリケーションサーバーの性能
- データベースサーバーの性能
など、複合的な要因によって決まるので、レンタルサーバーに対して盲目的な信者になるのではなく、必ず無料お試し期間を利用して速度を確かめてください。
Apache | Nginx | Nginx+Apache | LiteSpeed | |
CGI | スターサーバー ※ | — | — | |
FastCGI | コアサーバー | — | エックスサーバー | — |
モジュール | ヘテムル | 実現不可 | さくらのレンタルサーバ | — |
LSAPI | — | — | ConoHa WING | MixHost |
※スターサーバーについては、公式サイト上のサーバー仕様でウェブサーバーがNginxと表記されているので、本来であれば.htaccessを利用できません。
※しかし、スターサーバーでは.htaccessは利用できるとのことなので、公式サイト上に明記されていないだけで、実際にはNginx+Apacheの構成の可能性があります。
どうでしょう。
ウェブサーバーの比較表とPHP動作モードの比較表から、ご自身にあった組み合わせを考えれば、上記の表から最適なレンタルサーバー会社が見つかるはずです。
ご自身にあったレンタルサーバー会社がどこなのか、はっきりしてきたのではないでしょうか?
まとめ
ここまで、レンタルサーバーの選び方において、レンタルサーバーに採用されている技術的側面、具体的には、
- ウェブサーバー
- PHP動作モード
に焦点を当てて解説をしてきました。
ここまで説明をすべて理解していただければ、次回以降、レンタルサーバーはご自身の頭の中で考えられると思います。
すべてにおいて優れているレンタルサーバーは存在せず、技術というものはすべてがトレードオフの関係で最適なものはありません。
高額なサーバーが最適なわけでもなく、サーバー運営のどこにコストをかけているのかによっても価値観は変わります。
同価格のサーバーでも、
- サポート体制がよく人件費にコストがかかっているのか
- 速度に優れ最新のサーバーを導入しているのか
- 安定運用のために信頼性にコストをかけているのか
など、やはりサーバー自体の色が出てきます。
様々なレンタルサーバーに触れてみて、ご自身で納得できる、最良のサーバー選びを楽しんでください。
以上、レンタルサーバー選びについて、参考になれば幸いです。