さくらのVPSを使いながら行ったウェブサイトの3つの負荷対策

久しぶりのブログ更新になります。
色々と書きたいこともあったけど、サボってます。(継続中)

少し前の日記に書いたのですが、このブログおよび僕が公開しているいくつかのウェブページについては、基本的にさくらのVPS 512を利用しています。
512は最低プラン(初期からあるプラン)でメモリが512MBしかない環境です。そんな環境なのもあり、以前にTwitterのアカウントが商標権問題で変更せざるを得なくなった話を書いた際に、ありがたい事(?)に/.Jに取り上げられたり、はてブも300近いブックマークをもらったりするほどのアクセスとなりました。

当時、記事を公開した日の朝には、はてブやTwitterなどで話題に上げられ、アクセス増からサーバが高負荷状態となり、記事の閲覧が出来ない状態が続いていたりもしました。このときはmysqlやApacheの再起動を繰り返してみたりするも、あまり効果を発揮できず、最終的にはサーバを再起動させたように覚えています。

この時以降、こんなしょぼくれた個人サイトやブログでも、ある程度はサーバ負荷対策やキャッシュをしっかりしておかなければなと思い、いくつか対策を行ってきました。
これはサイトを運営する上で、サーバやサービスを落としてはいけないという下手な使命感のようなのもありますが、自分自身ウェブ系エンジニアを名乗るとして、それだけのことが出来ていないことが恥ずかしくもあったためです。


長い前置きとなりましたが、そんな僕が現在まで行ってきた大量アクセス時の負荷対策をいくつか挙げていきます。



Wordpressのキャッシュプラグインのインストール
WP Super Cache


おいおい、そこかよというツッコミも聞こえてきそうですが、当時、僕はこのプラグインを入れたつもりだったのですが、実際には入っていない状態となっていました。
そのため、記事のリクエスト時に毎回データベースに接続が行われ、データベースへの接続も、要求処理も原因し、結果過負荷となり、ページを表示出来ない状況に陥っていました。
その後このプラグインを正しくインストールして設定することで、ページのキャッシュが有効化され、大量アクセスが発生してもデータベースへの負荷をかけることなくページを表示できる様になりました。
なので、このプラグイン一つをとっても大量アクセスに対しては劇的に変わるため、これはWordpressでサイトやブログを運営するにはほぼ必須だなと実感しました。


Apacheからnginxへ
nginx
php-fpm

今まではApache + phpモジュールという、ウェブサイト構築ではごくごく一般的な構成を取ってきました。しかし、この構成は設定も楽で、管理もしやすく、TIPSも大量にあるため運用するにはとても最適なのですが、大規模アクセスとなるとApacheのメモリ消費量や負荷が目立つようになってきます。また、Apacheの中にphpへの処理が組み込まれるような形となる(具体的には異なりますが)ため、php側の処理にApacheが引きずられることとなり、phpの処理が関係ない部分まで応答が返せなくなるケースにまで至ることがあります。

そこで、メモリやCPUリソースの消費量も少なく、高速にリクエストされたコンテンツを処理して配信することができると話題のnginxを導入してみました。
これを導入することでメリットがあるのは、複数のウェブサーバとアプリケーションサーバで構築された中規模以上の環境でのリバースプロキシとしての利用や、画像などの静的コンテンツを大量に配信するサービスだと思います。

普通のウェブサービスの場合は、運用のし易さの面からも、ある程度の規模なら今までのApache + phpでもなんら問題ないと思います。
僕がこれを導入したのは、負荷対策と言うよりどちらかというと、最近のCGM系コンテンツやUGC系サービスサイトでよく見かけるようになってきたと言う技術的な流行が気になったというところと、個人的な実験的な要素が濃いです。

このnginxはApacheに比べて格段に動作が軽いのと、phpなどのスクリプトはfastcgiとして基本的に切り離していること、細かなところでカスタマイズができること、機能的にもApacheにはない、高速配信のためのキャッシュの仕組みがいくつか設けられていることなどのメリットもあります。
ただし、現時点ではまだまだ新しいサーバで、日本国内における運用系の情報は圧倒的に少ないですが、開発も活発で、また後発のプロダクトと言うこともあり、先発のApacheをはじめとしたサーバのいいところを取り入れて行っていると思い、今後も期待が出来そうかなと思います。
こちらの機能や導入についての詳細は、いくつかのブログで既に書かれているので、そちらを参照してみてください。


CDNの利用
CloudFlare

僕はCDNと聞くと、Akamaiなどを利用した、それこそ大規模なサイトでのコンテンツ配信をイメージしていたのですが、そのCDNを個人のウェブサイトにも簡単に、しかも無料で導入することができました。それがこのCloudFlareです。

CloudFlareは、ウェブサイトを丸ごと、cloudflareが持つCDN上にキャッシュとして持ち、配信してくれます。
簡単なイメージ的には、キャッシュプロキシが入る感じです。

これの導入方法は少々敷居が高いものの、至って簡単で、CloudFlareでアカウントを登録した後、サイトのドメインのDNSをCloudFlareの提供するDNSサーバに切り替え、DNSの設定をするだけ。簡単です。

メリットとしては、

  • キャッシュプロキシとなってくれるため、サイトに一切手を入れず、丸々をキャッシュしてくれるため、導入が楽

  • 高機能なDNS機能もフリーで提供される

  • ほぼ静的なページを大量のアクセスを捌くのに、追加サーバ導入コストを抑えられる

  • 簡易アクセス統計機能付き(リクエスト回数など)

  • キャッシュプロキシだけど、Google Analyticsなどの外部アクセス解析機能などにもしっかり対応

  • リクエストを弾きたいIPなども制御できる

  • これらがすべて無料(ただしある程度以上の規模は利用不可?)

といったところ。
上記を管理するコントロールパネルのUIのよく出来ていて、簡単かつ気持ちよく設定できます。
ぶっちゃけ、CDN機能を使わずに、高機能なDNS機能だけ使わせてもらうことも可能。最近対応していましたが、以前はVALUE-DOMAINのフリーDNSではIPv6には対応していませんでしたが、CloudFlareではIPv6にも対応されていました。

逆にデメリットとしては、

  • ドメイン単位での導入が前提なので、そもそもドメインを持っていないと利用できない。

  • ドメインのネームサーバ変更を必要とするため、サブドメイン毎に複数サービス運用している場合に、一部のサービスだけ利用を試してみるといった利用がしづらい(設定すれば可能だが…)。

  • サーバプログラム内でユーザのIPアドレス毎に制御を行っている場合、そのまま利用できない(一部参照先ヘッダの変更など、プログラムの書き換えが必要)

といったあたりでしょうか。


ちなみに、自分のサーバへのリクエストログには、CloudFlare経由の場合、すべて米国にあるCloudFlareのIPからの接続が残ります。
余談ですが、CloudFlareのキャッシュプロキシサーバは
varnishを利用している最近はnginxベースのものになったようです。
(コメントをいただきましたたくさんありがとうございます)




以上、3つとなります。他にも出来ることはあると思いますが、まずはこれでひとまずと思っています。
というのもあれ以降、大量のアクセスが舞い込むようなことが無いため、これでどれほどの効果が上がるかがまだ検証できていない状態です。


#本当は別のことを書こうと思っていたのに、気付いたらまったく違う内容で書き上げてしまっていたというオチ。

最近作ったアプリの話

先日、コナミ社の提供している コナステ のダウンロードコンテンツゲームを1クリックで起動できるアプリを作り、公開した。 Ks Game Launcher  ( Github ) 作った理由として、インストール時に作成されたショートカットをクリックするとブラウザが起動し、ログインし...