スキップしてメイン コンテンツに移動

さくらの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. リバースプロキシ(キャッシュプロキシサーバ)はVarnishじゃなくて最近はNginxベースのcloudflare-nginx使ってますよ。これは、httpヘッダのServerで確認できたり、CloudFlare側で502 Bad Gatewayとか起きるとわかります。確認してみて下さい。

    返信削除

コメントを投稿

このブログの人気の投稿

さくらのクラウドでマストドンのインスタンスをサブドメインで作る

タイトルに「の」と「で」が多すぎますが気にせずいきますこんばんは。

さくらのクラウドで、いま話題のMastodon(マストドン)のインスタンスを作成してみました。
Mastodonは普通にソースを展開して自分で普通にセットアップする方法や、Docker-composeを用いた方法などがありますが、さくらのクラウドでは、スタートアップスクリプトを用いて、管理画面から必要な項目を入力、スクリプトを選択するだけで簡単に立ち上げることができるようになっています。

さくらのクラウドのMastodonスタートアップスクリプト 実は少し前にこの方法で立ち上げたりもしていたのですが、本当に簡単でサクサクできてもの自体は30分程度で完了します。
管理者ユーザーを作成するには、通常のユーザー登録と同じ手順で画面からユーザーを作成後、一度コンソールからログインして、mastodonユーザーで下記のコマンドを実行する必要があります。

# su - mastodon % cd ~/live % bundle install % RAILS_ENV=production bundle exec rails mastodon:confirm_email USER_EMAIL=登録時のメールアドレス % RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=作成したユーザーID mastodon:confirm_email でメール受信確認をスキップして承認済みに、mastodon:make_admin で指定したユーザーを管理者に設定します。

これでインスタンス管理者として様々な操作をGUI上から行えます。

同類の記事は恐らく既にたくさんあるので、詳しい作り方に関してはそちらを参考にしてください。

気になるところが 上記のさくらのクラウドニュース内で記載されているMastodonスタートアップスクリプトでの構築方法に関する記事内で、一つ気になるところがありました。
それが
※サブドメイン(例:mstdn.example.com)には対応していません。 という記述部分です。

つまり、このスタートアップスクリプトを利用した場合、サービス専用のドメインを用意する必要があります。
既存のドメインをなるべく利用したい場合には向…

ブログを移転しました(WordpressからBloggerへ)

現在のこのブログを作ってから、長年自前サーバ(VPS)上で動かしていたWordpressで公開し続けてきました。
Wordpressは自由度もあり、カスタマイズ性もあり、また自前での場合はドメインもサーバ設定カスタマイズすら自由で、自分の行いたいようにいじることができました。

しかし、サーバ側のスペックや他の開発サービスとの兼ね合いなどもあり、人が滅多に来ないブログとは言えブログ自体の重さを感じておりました。
そのため、ここ最近はブログ用に別途VPSを借りて高速Wordpressとして売り出されているKUSANAGIを利用して公開したりもしていましたが、所詮趣味ブログであり、特に収益を上げるために書いたり(所為アフィリエイト)と言うことをしているわけでもなく、記事も頻繁に書くほどではなかったので、コスパの問題も出てきました。

そこで以前から計画していたBloggerへの移行を行い、ようやく公開作業が完了出来ました。使いやすさなどを考えると、はてなブログなどを利用するのが恐らく賢明だと思いますが、あれこれしようとすると有料プランで運用する必要があり、どうするかな、というところで悩みました。(VPSに比べれば月額は明らかに安いですが)

Bloggerは日本ではあまりユーザーが多くないように思えますが、ブログホストサービスとしての歴史は長く、またGoogleに買収されてからも安定して稼働しているので、こちらに移行しようと考えました。

Wordpressからの移行はそれほど大変ではないようで、それなりに大変でもありました。

記事やコメントの移行については簡単で、Wordpressの管理画面から「設定」→「エクスポート」で出力されるXMLを保存し、http://wp2blogger.info/ などのサイトへアップロードすることで、Blogger用XMLフォーマットに変換してくれるので、それをBloggerに取り込めば大体終了です。

問題は記事内で使用している画像です。外部サイトから読み込んでいる場合であればそのままでも行けるかも知れないですが、独自にアップロードしていた画像はすべてBloggerへアップロードし直す必要がありました。
またアップロード後も、元のファイル名でのURLにはならず、それぞれGoogleドライブ内で割り当てられているファイル名に変換されるので、一…

PHPで相対パスから絶対URL(URI)を作成する

HTMLページをパースしてURLを取り出す処理を書いていたのですが、ページ内のリンクなどが全部絶対URLで記述されていれば非常に楽なのですが、現実としてそうでもなく、ページによっては相対パスで書かれていたりして、正規表現で偏にリンクからURLを抜き出すだけではうまくできませんでした。

そこで少しググってみたら

PHPで相対パスから絶対URL(URI)を作成する|PHPプログラムメモ|プログラムメモ

という記事を発見!おぉ、これは便利!
と思って使わせてもらおうと思ったのですが、いくつかテストしてみて、相対パス処理で不備があるなーと思ったところがあったのでちょっと改良させてもらいました。

37~38行目は正直いらない気がしたのですが、 PHP 5.3 のCLIでWindows上でテストした際に、なぜか \/ (アルファベットのVではなく、\ と / ) で出力されたのが気になったので、無駄かもしれないけどあえて記述。
あと $parse の初期化もここまでする必要ないけど、念のためNotice対策を…w

相対パスから絶対URLする関数

< ?php
/**
* 相対パスから絶対URLを返します
*
* @param string $base ベースURL(絶対URL)
* @param string $relational_path 相対パス
* @return string 相対パスの絶対URL
* @link http://blog.anoncom.net/2010/01/08/295.html
* @link http://logic.stepserver.jp/data/archives/501.html
*/
function createUri( $base = '', $relational_path = '' ) {

$parse = array (
'scheme' => null,
'user' => null,
'pass' => null,
'host' => null,
'port' => null,
'path' => null,
'query' => …