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

初めてはてブホッテントリに入って分かったこと。

約1ヶ月前の先月末(2011年1月30日)、僕がこの記事を書いたことにより、僕が今までに経験たことがないことが起こった。

280を超えるはてブ数、そしてTwitterからの大量のアクセスだった。

今までそれほどの注目を集めるようなことをしたことがなかった僕は、この事態に驚きつつも、それだけの注目を受けたことに少しばかり嬉しさがあった。
しかしその反面で、ウェブサイトを運営するに辺り、やってはいけないことに直面する。

アクセス集中によるサーバの過負荷と、それによる接続障害

接続障害と書くと少々大げさな気もするが、要はサーバが大量のアクセスを捌ききれなくなり、応答を返せなくなってしまっていた。
ブログの記事を書いたのが深夜。と同時にTwitterとFacebookにその記事を流した。
しばらく様子を見ていたものの、特にいつもと変わらない状況であったため、そのまま眠りについた。

そして翌朝、目が覚めるとブログが表示できない。そう、いつの間にか注目を浴びることとなっていた。
正直どのタイミングから、どのタイミングでそんなに人が流れてきていたかは分からないが、おそらくはTwitterだろう。
ブログ投稿時には、他にもいくつかのブログフィードにPingを送っていたのでそちらからかもしれない。

で、そんなことより朝出勤前から繋がらない。
これでは仕方が無いので、まずは状況を確認。別なサーバに設置していたmuninと、ターミナルからSSHでサーバに入り、重い中どうにかtopコマンドやfreeコマンドなどで状況を確認。Load Averageがひどいことになっている。さらにSWAPが発生しまくっていたことから、メモリSWAPが原因でLAが高くなり、繋がらなくなったとわかる。
まず原因として一番はApache、そしてMySQL。なのでとりあえずこの2つを再起動し、状況が治まってきたことを確認し、まずは出勤した。

稼働環境

現在のこのブログ及び僕が運用しているいくつかのウェブサイトは、すべて同一の環境下で動いてる。
その環境とは…

サーバ: さくらのVPS
CPU: Core2 Duo 2.4GHz (/proc/cpuinfo の情報に基づく)
メモリ: 512MB
サーバOS: CentOS 5.5
ブログシステム: Wordpress 3.0.4_ja
HTTPD: Apache 2.2.x
PHP: 5.3.x
MySQL: 5.1.5x

上記がすべて1つの仮想マシン上で稼動している。


結果

結果的にはWordpressが参照するDBへの同時接続が多くなり、(またMySQLの設定も動作環境に適していなかった)接続が溜りったことにより(?)SWAPが大量に発生し、LAが上昇するという事になっていたようだ。
また、キャッシュ機構はMySQL側にもPHPにもWordpressにもそれぞれ有効にしていたが、それでも足りなかったか、Wordpressのキャッシュ機構を適切に設定出来ていなかったため、急激なアクセス増に対して一気に許容範を超え、負荷が上昇することが、その日のうちに度々発生していた。

一番まずかったのは、その日は仕事中のこともあり、接続できない状態を分かりつつもしばらく対応できない状態が2時間ほど続いたとき、さてサーバにログインし、Apacheの再起動を…と思っていると、ログイン出来ない。それどころか繋がらない(応答しない)。
muninのグラフを見てもチョチョ切れでもはや計測不能。ただし負荷がかかっていることはその前後にかろうじて観測できたグラフから確認できていた。

さくらのVPSの管理画面からシリアルコンソールでつなごうとしても反応がない。仕方が無いのでサーバマシン(仮想)を強制再起動しました。その後再起動をし、無事事無きを得ました。

完全に個人用途で趣味のため、大したウェブサービスが乗っているわけじゃないものの、仕事柄なのか少し焦りました。
あと、別に広告貼ってたりしてるわけじゃないけど、せっかくのアクセスが機会損失になるのも嫌だし、なによりブログを見に来てくれているにもかかわらずつながらなくて見れないのはやっぱり失礼ですしね。




TwitterにURLを流して気付くこと

これはアクセスログをリアルタイムに見ていて気づいたこと。
時間帯も影響するかもしれないが、TwitterにURLを流した瞬間に、まず多数のURL収集ボットがやってくる。
今回深夜にURLを流した際はそれほど来なかったが、以前日中に流してみたときは、ドッと複数のURL収集ボット?がやってきた。それらはおそらくUserStreamを常に監視してURLが流れてくるとその先をクロールし、情報を取得してくるのだろう。

さらに誰かがRTした瞬間に、急激にアクセスが集中する。RTされたタイミングで多くの人がアクセスするのと、自動的にリンク先URLを巡回するクライアント(短縮URLの展開機能?)やボットによってたくさんのアクセスが本当に短時間で集中することになる。
これらによって本当に何度も処理仕切れなくなって応答を返せなくなっていた。

なにが言いたいかというとTwitter怖い。


結論

スラッシュドットジャパンにも紹介されたりもしましたが、今回においてはスラッシュドット効果よりもはてブ効果と、何よりTwitterによる瞬間的なTwitter効果が怖かったです。

そんなわけで、ブログというものはそれ専門で運用している外部のサービスにおいて運用していた方が、安全安心だなと思った次第でした。
(この間のはたまたま集中しただけなので、多分このブログはしばらく動かさないと思います。)

コメント

このブログの人気の投稿

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

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

さくらのクラウドで、いま話題の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' => …