AWSのマイクロインスタンスは月間PVいくらまで耐えられるのか?

カテゴリー 時を加速させるプライベート★ライフ

どうも、白戸です。

 

最近、当ブログのサーバーが落ちまくるという現象が続き、とてつもなく寛大なメルマガ読者のみなさまから都度、ご連絡をいただいおりました。

「ブログにつながりません」

「ページを開こうとするとタイムアウトするんですけど」

「サーバー落ちてますよ」

ほんと、ありがとうございました。すみません。

 

最初はサーバー(EC2インスタンス)再起動で一時的に直るのに任せてごまかしていたんですが、だんだん落ちる頻度が増え、手動ではやっていられなくなったので恒久対応を行いました。

 

今日は、復旧の経緯と、AWSの無料版マイクロインスタンスが「どこまで使えるか」についてまとめました。これから、独自サーバを使ってWEBサイトを立ち上げようとしている方、すでに運営中の方に、参考にしていただければと思います。

 

「ブログのサイトがダウンしています」

 

私も元はSEの端くれ。インフラの専門家ではなかったけど、うちの母親よりはITのことに詳しいという自負がありました。

わからないなりに、サーバに繋がらなくなるたびにnginx( Apachの代わりに使ってるミドルウェア?)のログを調べたり、Wordpressのデバック機能をONにしてみたり(※)、画像ファイルのサイズをひとつひとつ小さくしてみたり、DBの設定を変えてチューニングまがいのことをしてみたりと、何百時間もかけて対応しました。

※wp-config.php 内の以下のfalseをtrueに変更するだけでOK。再起動は不要。

define('WP_DEBUG', false);

 

しかし、なにか新しい変更を加えるたびに、レスポンスは悪化し、落ちる頻度も増え、しまいにはWordpressが完全に修復不可能なまでに(レイアウトはめちゃめちゃ、ダッシュボードからの外観変更が一切できなくなり、テーマの再インストールもできず、画像データは消えた。地獄かよ)ぶっ壊れたりしました。

しかもアラーム通知設定もなにもしていなかったため、サーバーが落ちるたびに読者のみなさんにご指摘をいただく始末。最悪ですね。

 

全く理解できないままエラーメッセージを検索し、英語で書かれた全く理解できない難解なシステムコマンドを延々実行するはめになりました。セットアップやメンテナンスでエラーが発生するたびに、何時間もリサーチとトラブルシューティングに追われました。

結局、EC2インスタンスを作り直し、EBS(Elastic Block Store)の半年前のスナップショットをアタッチし、なんとか今の状態まで復元しました。(DBをRDSに切り離しておいて本当に良かった。皆さんも、気をつけたほうがいいですよ)

 

原因はOutOfMemory、解決策はt2.microを卒業すること。

以下は、AWSについて多少なりとも知っている方に向けて書きます。

 

まず、「ブログにアクセスしようとすると、タイムアウトする」というのが今回の問題でした。だらだら私の試行錯誤について述べても意味がないので、最終的にわかった原因と解決方法だけ述べます。

 

問題:「ブログにアクセスしようとすると、タイムアウトする」

原因:EC2のt2.microインスタンスでOutOfMemoryErrorが発生(シスログで確認)

解決方法:インスタンスタイプを「t2.micro」から「t2.small」に変更する

これだけ!

なんとまぁ、、、私が費やした時間は無駄以外の何物でもなかったわけですが、これは私がAWSのインスタンスについてよく理解していなかったことと、どケチで金欠だったせいなので誰かを殴って罵るわけにはいかないのです。もしやるとしたら自分で自分を殴るしかありませんが、痛いしバカみたいなので実際にはやりません。

 

EC2のt2.microはどこまで耐えられるのか?

これからAWSの無料枠を使ってWEBサイトを立ち上げようとしている方のために、ここで具体的な数字を出しておきます。

この「ブログにアクセスしようとすると、タイムアウトする」という問題が頻発し始めたのは、「そろそろ月間PVも2万を超え始めたな」という頃。

ブログを立ち上げてから1年と3ヶ月が経過していました。だいたい、常時、10人前後の人がサイトにアクセスしている、というレベル。

 

 

なお、このサイトはAWS(Amazon Web Service)のEC2+RDSで構築しており、マイクロインスタンス(最も小規模のサーバー)なら1年間無料で使えるということで、EC2ではt2.micro(無料)、RDSではdb.t2.micro(無料)を使っていました。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-11-09-22-21-15

なので、「DBもEC2インスタンスに乗せちゃってます!」という場合はもっと早くに限界がくると思われます。t2.microはあくまで無料版・お試し版であり、検証、実験で使ってみてるというのが公式に推奨されている使い方ですので、まぁ、その通りですね。公式をなめたらダメですね。

 

 

問題は純然たるスペック不足

さて、「ブログにアクセスしようとすると、タイムアウトする」という問題が最初に発生した時、元SEの端くれであった私は、ブログのEC2インスタンスのインスタンスタイプがt2.micro(無料版)であったことを思い出し、「たぶん、スペックが足りないんだろうな」と当たりはつけていました。(これは見栄とかじゃなく。ほんとに)

 

 

タイムアウトの原因は、DB側(DBのメモリ不足でもDB接続数の上限を超えた等)ではなく、EC2側のシスログに出ていたOutOfMemoryErrorが原因でした。(これがわかったのが散々Wordpressを破壊し尽くした後だったのが非常に悔やまれます)

ちょっと調べればたくさん記事が出てくるのですが、t2.microにはスワップ領域がありません。だからちょっと負荷がかかるとすぐOutOfMemoryになっちゃうのです。

 

ただ、だからと言ってスワップファイルを作って暫定対応!というのはあまりお勧めしません。スワップファイルを作れ、という記事は山ほど出てきたので私もやってみたのですが、散々時間がかかった挙句、結局、問題は解決しませんでした。

やはりそもそものスペックが足りていないのだという現実にきちんと向き合うべきです。特に、今後もアクセス数を伸ばしていきたいと考えているなら、なおさらです。

 

では今回、たかがOutOfMemoryErrorになぜこれほど対応が難航したのかというと、私がどケチで金欠だったからなのです。もっと正確に言うと、実は1年が経過した時点で(その頃は特に問題もなく順調に稼動していた)t2.microのリザーブドインスタンスを購入していたからなのです。

リザーブドインスタンスってなんぞ?

リザーブドインスタンスというのは、その名の通り、「予約済み(リザーブド)」のインスタンスのことで、簡単にいうと「全額前払いしたら安くするよ」というもの。

AWSに限らずクラウドコンピューティングというのは、つまり、物理的なサーバーを個人ではなく会社(AWSの場合はAmazon)が所有していて、お金を払って一部を借りてWEB上で使わせてもらう、という仕組みです。これが、一般的なクラウドの使い方で、いわゆる「オンデマンド」ですね。

 

「オンデマンド」というのは「リザーブド」の反対語と考えてもらえれば良く、要するに「使った分だけお金を支払ってくださいね」というもの。だから、初期費用は安く済むし、「最初、ちょっとどれくらいの規模が必要なのか見積もりが難しい」という場合、とりあえずオンデマンドで初めて、感触を見てからスケーリングを流動的に変えていけるというメリットがあります。

対して、「リザーブド」はこれくらいのスペック・規模が必要なのはわかっているから、最初にドーンと買っちゃう(予約する)というもの。もちろん、オンデマンドのように不要になったからすぐ破棄する、ということはできないのですが(厳密にいうとマーケットに出品はできるがここではややこしくなるので割愛)、AWSの場合、1年分の前払いで25%OFF、3年分だと50%OFFになるのです。

だから、途中でやめたり大規模なスペック変更の予定がないなら、リザーブドの方が圧倒的にお得なのです。

 

t2.microのリザーブドインスタンスを購入したけどt2.smallに変更したい場合

 

インスタンスタイプの変更(t2.micro→t2.small)はとても簡単にできるので、たった一度、AWS管理コンソール上で試してみればよかったのですが、私はリザーブドインスタンスについて誤解しており、変更したらt2.microのリザーブドインスタンスが無駄になると思い込んでいたので、なんとかt2.microのままで問題を解決しようとしました。

その結果、スワップファイルを作ったり消したりインスタンスを完全に破壊したりDBを一から作り直したりチューニングしたりと、さんま一尾を手に入れるために近所のスーパーを素通りしてヘリでオホーツク海まで飛ぶくらいの無駄な回り道をしたわけです。

 

結局、これまでこの問題にかけた時間と労力と精神的ストレスに比べたら、t2.microのインスタンス1個にかかったお金(約3万円)が無駄になるくらいどうってことないと半ば朦朧としながら思い至り、インスタンスタイプを変更してみました。

すると、ピタッと、まるで魔法みたいに、サーバーの不調が治りまして。こうして、いつでも快適に繋がるように復活したわけです。

 

しかも、問題のリザーブドインスタンスも、全く無駄にはなりませんでした。私はt2.microとt2.smallはスペックの違う完全に別のマシンというイメージを持っていたのですが、違いました。

簡単に言うと、

t2.micro ×2 = t2.small

なのです。

つまり、t2.microのリザーブドインスタンスをt2.smallのリザーブドインスタンスに変更したかったら、t2.microのリザーブドインスタンスをもう一個購入すればいいのです。いやぁ、うまくできてますね。

よくよく考えたら、リザーブドインスタンスを買ったらもう拡張できないってんじゃ、たしかにクラウドの意味ないですもんね。不便すぎますもんね。天下のAmazon様がそんなしょっぱいサービスするはずないですよね。すみません。

 

 

 

まあ、そんなこんなで問題は無事解決し、私のt2.microのリザーブドインスタンス(3年分)も無駄にならずに済みましたとさ。めでたしめでたし。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です