サーバーの世界では、安かろう悪かろうは大体合ってます。
低価格の共用レンタルサーバなどは、利用できるリソースが限定されていたりと、性能的には高いサーバに比べて低いケースが多いです。
しかし、concrete5の様なCMSを動作させるインフラには、色んな種類の物があります。
最近は、パブリッククラウドと呼ばれる仮想化環境がとても人気で、Amazonを筆頭にMicrosoftやIBM、Oracle、ニフティやさくらインターネットなど様々な企業がこぞって参入しています。
こういったクラウド上のインフラサービスは、従量課金制をとっている事が多く、「使った分だけお支払い」なので上手に使うと低コストで高いパフォーマンスを期待できるというのが各社の売り文句になっています。
でも...
どうなの?実際のトコ。
本当に安いの?
何か経験上そんなに安くない気がするんだけど...
AWS(Amazon Web Service)とかのクラウドって高いの?安いの?
このベンチマークを取ろうと思ったキッカケがこれです。
AWSなどのクラウドコンピューティングの環境は、月額固定ではなく使った分だけの従量課金性ですが、従量課金性のサービスと同様に24h365で使うと高いイメージがありました。
友人のクラウドに詳しいエンジニアに色々話を聞くと、オートスケーリングとか、今まで面倒だったとこをクラウドサービスは自動でやってくれて凄い楽でメンテコストが安いよ!と。
しかもうまく使うと、常に複数台構成でアクセス捌いているより全然安いよ!と。
そもそも、こういったインフラの仮想化技術が発展した背景には、余ったマシンリソースを有効活用し、サービスにかかる費用を下げる事にありました。zenとか出始めの頃にいじってました。懐かしいなぁ
でも、実際費用の方は今はどうなんでしょう?
AWSとかのクラウドって速いの?遅いの?
AWSとかのクラウド環境は仮想化環境です。
つまり、裏でオンプレミスな実サーバとかストレージとかスイッチとかがワンワン唸っているわけなんですね。
しかも、中小企業では手の届かない様な超高速な機器を組んでいるわけです。
この高級なリソースを間借りできるので速いよ!って聞いていました。
確かに速そう。最近は仮想化の技術も進歩し、オーバーヘッドも気にしないで良いくらいのレベルになっているそうです。
でも、実際どうなんですかね?本当に仮想化のオーバーヘッドって気にしなくても良いくらいなのでしょうか?
一昔前にはストレージの性能や不具合でパフォーマンスが落ちたり、サービスに障害が出たりしてましたが、今はどうなんでしょう?
また、割り当てられるリソースでどれくらいのパフォーマンスが出るのでしょうか?
concrete5の様なCMSを動かすとどうなんだろう?
僕が聞くクラウドの費用対効果を大きくうたっている事例には、スマホゲームとか、アプリ関連が多い印象がありました。
確かに、イベント等で短期間にアクセスが集中する様なゲームのサーバには向いている気がします。
「CMSをクラウドで動かすとこんなに速く安くなりました!」という話は、チラホラしか聞いた事がありません。
Webサイトで瞬間的にアクセスが増大するケースって、実はそんなに多くないと思います。
有名な企業が何かやらかしたり、テレビで紹介されたりすると、波動砲が飛んでくるという話はちょいちょい聞いていました。
安定したアクセスのある、PHPで動作する動的なCMSを動かすとどれくらいのスピードがいくらで出るのでしょう?
試してみないとわからない > ベンチマーク取りました。
1時間動かしたらいくら?とか、1ヶ月いくら?という事ではなく、僕らのクライアントが求めているのは、
「必要としている性能を最も安価に提供できるのはどれか?」
なので、費用を基準としたちょっと変わったベンチマークを取ってみました。
要は、 一定のアクセスが集中した時に1アクセスを何円で処理できるか?を調べます。
ただ、500円のサーバの1アクセスと、30万円のサーバの1アクセスでは、性能に明らかな差があるので比較になりません。
仮に月額費用が同じくらいなら、どれが一番多く処理できるか?という事を調べました。
ベンチマーク条件
月額費用 | 15,000円程度の環境を構築 |
---|---|
検証対象 | AWS、さくらのVPS、さくらの専用サーバ |
検証方法 | シンプルにトップページに対してabテスト。 ab -n100 -c100を5回実施しReq/sの平均値を取得 |
OS | CentOS7, AmazonLinux (AWS) |
ミドルウェア | PHP7.0.0(ソースからコンパイル)、MySQL 5.7.9、Nginx 1.9、php-fpm(fastcgi) |
アプリケーション | concrete5 Ver.5.7.5.4 |
という比較条件で、3つ環境を作りました。
台数 | CPUコア数 | メモリ量 | ディスク | 月額費用 | |
---|---|---|---|---|---|
AWS | 1 | 2 | 7.7GB | SSD 20GB | 16,745円(1$125円で計算) |
VPS(さくら) | 1 | 8 | 16GB | SSD 50GB | 15,552円 |
実サーバ(さくら) | 1 | 12 | 16GB | SSD 256GB | 15,120円 |
PHP7は出たばかりだったので、これも性能を試したくソースからコンパイルしました。
意外にハマったのがMySQL 5.7.9。デフォルトのsql_modeが変わっていて、concrete5のコードでは動きませんでした。(詳しくはコチラ)
MySQLとphpの接続、nginxとphp-fpmの接続もsocketにして、それぞれの環境をできるだけチューニングしました。
RDSを使わなかったのは、この金額ではRDSを使うよりも1台のVPCでWeb、DB両方動かした方が速いだろうという判断からです。
結論から言うとここはもう少しインスタンスのサイズや種類を考えたかったのですが、残念ながら時間切れでした。
PHPのチューニング
PHPに関しては、PHP7の素の性能を知りたいという事もあり、あまり特別な事はしませんでした。
実施した内容は主に以下の通りです。
- opcacheの設定
- 余計なエクステンションをロードしない
- ソースからコンパイル
- 割当メモリの最適化(最小限に)
- php-fpmとnginxとの接続をsocketに
- エラーやログの設定(出力無し)
効果が大きかったのは、やはりopcache。APCの時からお世話になってます。
MySQLのチューニング
今回はMySQLに一番時間をかけました。
経験上、ボトルネックになりやすいのが、ファイルのIOとDBだからです。
新しいバージョンのMySQL 5.7.9を使用するという事もあり、各種パラメータをしらみつぶしにあたり、パフォーマンスに関係ありそうなパラメータをいじくりました。
結果、大半が性能にはほぼ関係ありませんでした。
今回の検証対象のWebサイトは、concrete5のデフォルトのサンプルコンテンツが入ったWebサイトです。DB上のデータ量やレコード数は少量で、バッファやキャッシュの容量をいじくってもかえって遅くなるケースが殆どでした。
おそらく、メモリ確保の時間の方がかかってしまったのではないかと思います。
最終的に効果が大きかったのは
- クエリキャッシュON
- スレッドキャッシュを増やす
でした。特にクエリキャッシュは効果大。
他のパラメータは、それぞれはもう誤差の領域でしたが、そこはチリが積もればなんとやら。頑張って最適な設定を割り出しました。
Nginx+php-fpmのチューニング
本番環境等であれば、gzip圧縮や、HTTP2の設定とかで速くなると思うのですが、今回はシンプルなabなので、余計な事はさせずにシンプルに。
fastcgiのキャッシュ周りも設定してみましたが、concrete5は動的なCMSなので、キャッシュの設定によっては操作や表示に支障が出てしまいました。
また、concrete5のフルページキャッシュとほぼ同等のスピードが出たので、ここはconcrete5とOSのファイルキャッシュに任せました。
今回実施したのは主に
- どうせab -n100 -c100しか来ないので、最初からどーんと100立ち上げておく
です。
幸いMySQLでは大してメモリを必要としていません。CPU、メモリ共に使い切っちゃいましょう。
ベンチマーク結果
それではお待ちかねの計測結果です。
AWS | |
---|---|
VPS | |
実サーバ |
キャッシュALL OFF | キャッシュ全てON | 全てON+フルページキャッシュ強制 | 静的HTML | |
---|---|---|---|---|
AWS | 8.7 Req/s | 17 Req/s | 490 Req/s | 492 Req/s |
VPS | 15 Req/s | 25.3 Req/s | 545 Req/s | 未測定 |
実サーバ | 47 Req/s | 87 Req/s | 535 Req/s | 534 Req/s |
面白い結果になりました。
キャッシュはconcrete5のキャッシュになります。「フルページキャッシュ強制」というのは、1回もDBにアクセスせず、ページ単位の出力結果をconcrete5側で強制的にキャッシュしておく機能です。
参考までにまったく同じ内容のHTMLファイルを作成し、同条件で計測してみたのが、一番右の列の数字です。
フルページキャッシュを強制すると、ほぼ静的HTMLと同じ速度が出ます。
面白いことにフルページキャッシュを強制すると、誤差の範囲とはいえVPSが実サーバよりも速いという結果になりました。
通常のconcrete5のキャッシュを全てONにすると実サーバだと、
87リクエスト×60秒×60分×24時間×30日=225,504,000アクセス
捌ける事になります。
実際には1つのページで1リクエストではなく、jsやcss、画像ファイルなどがロードされますし、ページ毎に処理速度も違うので、おおよそ月間1千万PVくらいの処理能力でしょうか。
さて、この1リクエスト当たり何円だったか?です。
僕らが知りたいのはここです。
キャッシュALL OFF | キャッシュ全てON | 全てON+フルページキャッシュ強制 | |
---|---|---|---|
AWS | ¥1,924.71 | ¥985.00 | ¥34.17 |
VPS | ¥1,036.80 | ¥614.70 | ¥28.54 |
実サーバ | ¥321.70 | ¥173.79 | ¥28.26 |
金額で表すと面白いですね。
キャッシュが全てOFFになっていると、VPSは実サーバの約3倍、AWSに至っては約6倍の費用がかかります。
しかし、キャッシュを全て有効にするとAWSで5.7倍、フルページキャッシュ強制だと1.2倍まで差が縮まります。
キャッシュALL OFF | |
---|---|
キャッシュ全てON | |
フルページキャッシュ強制 |
キャッシュALL OFF | キャッシュ全てON | 全てON+フルページキャッシュ強制 | |
---|---|---|---|
AWS | 5.98倍 | 5.67倍 | 1.21倍 |
VPS | 3.22倍 | 3.54倍 | 1.01倍 |
やっぱり実サーバ最強だった
やはり単純なマシンパワーでは実サーバが最強でした。
VPSはもう少し費用対効果が高いかな?と思っていたのですが意外とそうでもなく、AWSはRDSを使わないで1台構成で使うとやはり性能的なコストパフォーマンスは出せないようです。
AWSも静的だとグっと安い
しかし、AWSもコア数やメモリ量が少ない(コア数は実サーバの1/6!)のに静的なページになるっとグッと早くなります。
システム全体としての性能はやはり凄い様です。
おそらく、コア数やメモリ量が同じ環境でベンチ取ったらAWSが一番速いのでしょう。
まとめ:concrete5に適した費用対効果の高いサーバを選択するコツ
今回、単純な価格ベースのマシンパワーでは予想通り実サーバが一番でした。
しかし、共用サーバ、専用サーバ、VPS、クラウドそれぞれ特性があり、ユーザー側で必要なメンテナンスも変わってきます。
今回の様なroot権限付きの実サーバなどは、自由にチューニングでき、性能を引き出しやすいですが、その分チューニングの知識や継続したメンテナンスが必要です。
また、ハードウェアが変わらないという事は、今は早くても数年経過すると最新のハードウェアを使う仮想環境の方が速くなるケースもあります。
後で複数台構成にしたいと思っても、ホスティング会社によってはサーバを追加することができず、契約仕直しでサーバ移動ということもあります。
その点、クラウドなどの仮想環境では簡単にサーバを追加することができます。今ではサーバだけでなく、スイッチなどのネットワーク機器も仮想的なものを利用することができます。
運用にかかるコスト(人的コスト)も含めて考えないといけない
実際にサーバを運用していくと単純な価格だけでは決められません。
実サーバは自由にチューニングできるのですが、その分ミドルウェアのメンテナンスも自分たちでやらないといけません。
サーバが使っているソフトウェア全ての脆弱性に常にアンテナを張り、適切なメンテナンスを継続するのはなかなかにコストがかかります。
それを自社でやるか?ホスティング会社にお願いするか?または外部の運用会社に依頼するか?でコストが変わってきます。
こういったメンテナンスや運用保守に関わる費用は、概ねサーバの利用料金より高額になるケースが多いです。
なので見えづらい運用保守費用をちゃんと算出して、明確にすることが必要です。
それ以外にも検討事項としては、データの保全性やシステムの稼働率、いろいろな項目があります。
concrete5はサイト運営と密接に関わったCMSです。そのため運営体制やサイトの性質、今後のマーケティングプラン等を考慮し、様々な視点からそれぞれのサービスを比較検討するする必要があります。
頻繁に更新されず、コンテンツ作成者が少ない場合は、サーバのマシンパワーはそこまで必要ではないので、マシンパワーは低くてもミドルウェアの保守が必要ないサーバを選択するのが良いでしょう。
また、ミドルウェアのバージョンや設定も性能に大きく関係するので、そう言った知識も必要になります。
結論から言うと、単純なマシンパワーと価格だけでインフラを選択してはいけないという事です。
今回測定したベンチマークのデータなどを参考にしながら、総合的な判断が必要になります。
そんなインフラの知識無いから選べないよ!という方へ
弊社ではインフラ、concrete5、Webサイトの運営に精通した専門家がいます。
ぜひ弊社のconcrete5インフラコンサルティングサービスをご利用ください。
貴社に最適なインフラ構成をご提案いたします。