今回の内容は長文になりすぎてしまったため、結論だけ先に書く。業務サービスとか、シビアなものには さくらのVPS はやめておいた方がいい(そういったものには普通使わないだろうけど)。利用可能リソースを明記している会社のサービスか、SLAを明記しているサービスにすること。
業務で利用しているVPSに、突然制限をかけられて対応に苦労することを考えるなら、高くてもリソースの制限が明確な Linode とか、SLAをうたってる GMOクラウドVPS 、Amazon EC2 等がいいのではないかと思われる。
私の場合もミッションクリティカルと言うほどではないにしろ、社内グループウェアと外部向けのWebサービスに利用していたサーバーにおいて、突然リソース制限が掛かってしまったため、非常に焦った。せめて制限をするならするで同時に自動メール送信を行うなど、ユーザーに対する連絡は欲しかった。(これがなかったせいで、乗っ取られたことも考えてログ総ざらえする羽目になり、1日徹夜したんだぜ・・・)
どうしても予算がなくて高いサービスを使えないという場合であっても、そういったサポート体制を前提にサービスを選ばなければ、最後に泣くのは技術者たる自分である。サポート対応に定評があり、自分も信じていただけに裏切られた感が強いが、さくらインターネットには、今後もよりよいサービスに向けた改善を行ってもらいたい。
なお、今回の事例は事実に基づき記載しているが、この内容は個人としての感想を述べただけのものであり、さくらインターネットのサービス運用・体制を批判・非難するものではなく、私の所属する会社を代表した意見として記載したものではない。
・・・以上、一応会社が絡む話なので免責事項も記載してみました。
スポンサードリンク
プライベートでも、現在このブログは(2013年3月時点で) さくらのVPS 2G(大阪) で運営しているけれど、こちらは会社で借りてる さくらのVPS 2G(大阪) での話。
早朝8時半過ぎに yum update を実施すると(色々あってメンテ時間が朝にずれ込んだのです)、無茶苦茶重い。アップデートサーバーからの返答待ちだけで数分かかるとか、信じられないレベル。(アップデート完了までは2時間程度かかった)
初めはプロバイダのせいとか、DoSでも受けてるのかとか、クラックされて乗っ取られて踏み台にでもされたのかとか( 過去の改ざん事件 のトラウマが蘇ったよ)、真っ青になりつつクソ重くなっていたSSHのコンソールからログ確認したり、別サーバーに待避してた過去ログチェックしたり、メールで届く logwatch の内容を確認したりしても、あやしい痕跡はなし。
ここに至って、さくらのVPS自体があやしいんじゃね ? となって、Ping打ったり、hdparm -t /dev/vda とかやったりすると、Ping応答までに900msec、hdparmの結果に至っては 1.5MB/sec とか、信じられないほど遅くなっていた。
つい最近もトラブルがいくつかあったみたいなので、もしかしたらホスト側の不具合かなーと思い、問い合わせを投げると以下のような内容のメールが届いた。
お客様の仮想サーバが収容されるホストサーバについて確認いたしました
ところ、ホストサーバにて高負荷が発生いたしましたため、一部の負荷の
高い仮想サーバに対し、一時的な制限を実施しておりました。お客様の仮想サーバも対象に含まれておりましたが、現在は制限は解除
されております。お手数ではございますが、状態をご確認くださいますよう
お願いいたします。なお、今後の負荷状況によりましては、再度制限を実施する可能性がござい
ます。リソースを共有しているサービスでございますため、何卒ご理解賜り
ますよう、お願いいたします。
制限だと!? 自慢じゃないが、月間PVが1万程度しかない(涙) 弱小サービスなのに!?
何かこの文面どこかで見たなーと思って検索したら、見事に同じ症状を食らった方がいらっしゃった。
【さくらVPS】ブログのレスポンスが遅かった理由が判明
http://blog.malrone.info/archives/4269
ほぼ内容一緒じゃん・・・テンプレなのかよ、これ。テンプレ化されてるのだとしたら、どれだけ頻繁に重くなったり制限かけたりしてんだよ怖えーな、と思ったが、万一こちらの問題で相当な負荷を掛けているのだとしたら対処しないと迷惑がかかるので、MuninとさくらのVPSのリソースモニターを使って調べてみた。
Muninの方は、Evernoteでクリップしたはずが、データがうまく取れなくてログが流れてしまったので、当日のさくらのVPSのリソースモニター画像と、1週間分のリソースモニター画像をキャプチャした。(問題発生は03月25日)
プロバイダ業務に詳しい方がいたらアドバイスをいただきたいが、これは制限されるに値するほどの負荷なんだろうか。cron.daily でトータル百数十MB程度のバックアップと数MB程度のMySQLダンプ作成(それらをgzip化)、その後そのバックアップを遠隔地に転送しているため、早朝の時間帯はそれなりの負荷がかかっているが、トータルで見ると負荷は大きくないように見える。
yum update を行った08時30分過ぎのデータは負荷が高まっているが、これはCentOS自体のアップグレードがあったため。しかし、そのアップデート時点でクソ重かったので、このアップデートが制限の引き金を引いたわけではないようだ。
コメント欄より、1MB/secを越えるDISK I/O負荷は、このクラスのVPSに対しては非常に高い負荷であり、制限対象になってもおかしくないとの ご指摘をいただきました 。他の情報も検索いたしましたところ、こちらのサイト様の情報 に、負荷がMB/sec単位となった場合は、サーバー負荷が高まっている旨の記載がございました。
この例だけをもって、さくらのVPSの負荷リミットが1MB/secだとは断言できませんが、少なくとも1MB/sec以上の負荷がかかった場合に、制限がかかる可能性は高いと言えそうです。
しかしながら、本記事の趣旨としましては、さくらのVPSのリソース制限方法ならびにその妥当性についての問題提起が主であり、また運用中に突発的な負荷として一時的に短時間Disk I/O負荷が高まることはある(上記左のグラフ・8時30分頃に実施したCentOSバージョンアップ時は、制限がかかったとき以上の負荷が同じくらいの時間発生した) ことから、同様の制限を受ける可能性があるユーザーは少なくないと考えられますため、元記事の修正は行わず、ここに追記いたしました。
もちろん、そういった不可避の事情があった場合はともかく、Cronで定期実行するような処理についてはサーバー負荷をできる限り少なくするべきであり、その点において私の行っていたバックアップ手法には不備があったものと存じます。改めて負荷の少ない定期バックアップ手法について、別記事にてまとめる予定です。
このことが気になったため、再度どの程度の負荷があったら制限されるのか、リミット値があるならどの程度まで許容範囲なのかを聞いたところ、以下のような返答があった。
お客様にご提示可能な明確な数値はございませんが、以下の場合に
原因となる仮想サーバに制限を行わせていただく可能性がございます。・仮想サーバが収容されるホストサーバのCPUやI/O負荷が明らかに
高くなった場合
・同居している仮想サーバのユーザよりパフォーマンスが非常に悪い
との連絡があった場合ディスクI/O負荷の高い上位の仮想サーバより順に、制限の対象となり
ますが、ホストサーバの負荷状況の変化や同居している仮想サーバの
状態により制限を行う際の基準や方法、実施時間なども様々でござい
ます。
明確に数値として出せる規制値はない(もしかして規定してない?) が、VPSホストのCPUやI/O負荷が高くなった場合に、ディスクI/Oが高いユーザーから順に規制している、ということらしい(CPU負荷が高いユーザーは放置なの?)。この返答では何も分からないに等しいし、会社に対しての報告もできやしないので、再度以下のような内容を問い合わせた。
クォータでも仕込んでいて(KVMにユーザークォータがあるのかどうかは知らないけど)、ソフトリミットやハードリミットを元に一定以上の負荷で制限がかかるようになってるのか、それともその瞬間の負荷が高いユーザーを狙い撃ちにしているのか。
手動なら自分が対象になったのも理解できるが、トータルの負荷は低いのにそれってひどくない? 恒常的に負荷の高いユーザーを一律リミット掛けてリソースの空きを作る方が公平だよね? って、書いてて思ったけど、これプロバイダがP2Pの規制をかける際に使う理由と同じだな・・・。なるほど納得(笑)。
手動の制限なら手動解除という気もするけど、自動的な制限かもしれないという事もまだ可能性としては残っていたので(あの文面からは99%無いなーとは思っていたが)、これも聞いてみた。
一番聞きたかったのはこれ。リソースモニターの画像も添付して質問してみた。
それについての返答が27日に届いたので記載すると、
1. VPSの制限は手動で行っているのか、それとも自動なのか。
さくらのVPSの制限につきましては、手動にて行っております。
ホストサーバの負荷が上昇した際、ディスクI/O負荷の高いサーバに対し、
制限を実施を行っております。また、ホストサーバの負荷状況により、仮想サーバの制限を行う件数等
異なるものとなります。
2. 制限からの復帰は自動なのか、いちいちサポートに連絡しないといけないのか。
制限の解除につきましては、自動解除となります。
また、自動的解除される前にお客様からご連絡いただければ手動にて解
除を行うことも可能でございます。そのため、弊社サポートへの問い合わせを行わない限りは制限が解除され
ないということはございません。
3. ディスクI/O負荷による制限とメールにあるが、制限を受けるほどの負荷が今回発生していたのか。
ホストサーバの負荷が発生しておりましため、収容仮想サーバのディスクI/O
負荷状況を確認しましたところ、お客様の仮想サーバが含まれておりました。他の仮想サーバの相互影響のため、通常快適に動作している仮想サーバも一時
的に動作が重くなる場合もございます。特に深夜3:00から5:00の間、仮想サーバのCRON設定が集中していることに
より、高負荷が発生しやすいものとなります。このことから、お客様にて上記時間帯にてCRON設定等を行われていました場合
は、上記時間を避けていただければと存じます。
という返答だった。まとめると、
という感じだろうか。しかしこれにも疑問はある。
1は予想通りだからいいとしても(不公平感はあるから本当はよくはないけど)、2の制限は自動で解除されるという部分。手動で制限かけて解除のみ自動って、ミスが多くなりそうなオペレーションだよね。現に上記した同じような目に合ってる方は、制限が解除されなくて、問い合わせした結果発覚したわけだし。本当にミスなく自動で負荷が下がったら解除されるの? 私、気になります!
また、自動解除されるとして、それはいつなのか。負荷が下がったらという曖昧な答えだけど、厳密なリソースによる制限ではなく手動制限(制限値も教えてくれないし) なのに、そんなアナログな基準で自動で制限解除されますと言われても信用できないんですが・・・。自動で制限解除するよー、ただし1ヶ月後な!!(まさに外道 AA略) とかってオチだったら、業務になりません。
3番目は cron.daily 全否定な訳ですが、つまりcron.daily使うなって事がさくらインターネットの公式見解なんでしょうか。cron.dailyは負荷集中を避けるために、実行時間をある程度ランダム化しているはずなんですが(この辺りうろ覚えなので間違っていたらご指摘ください)、時間決め打ちしたらその方が他のユーザーとバッティングして、ひどいことになりそうな気が・・・。
あとバックアップを日中に取るわけにも行かないし、他のユーザーの方もバッチ処理などで、どうしても深夜帯にI/O負荷が高くなる処理を行うのは避けられないと思うんですが、だからといって目に付いたユーザー狙い撃ちは不公平感がありすぎです。一律のリミットならまだ納得もできるのに・・・。
ということで、そういうことを再度質問メールとしてお送りしましたが、その返答を待ってるうちに書きたいことを忘れそう&もうこれ以上何を聞いても無駄かなーという気もしたので、ひとまずブログにまとめました。
結論は最初に書いたので、ここでは簡単にまとめますが、個人的にはいただいたメールにあった一文
また、負荷の高い仮想サーバの特定方法や制限方法等について社内で検討させて
いただきます。
に期待したいと思いますが、それが実施されるのがいつになるのかは分からないので、さくらのVPSを利用中のユーザーさんは、突然のアクセス制限にはご注意くださいね、ということで。
次に同じ目に合うのは、あなたかもしれませんよ・・・。
スポンサードリンク
当サイトのコメント欄は承認制となっております。また、日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)
8 Responses to さくらのVPSは突然制限かけられて激重になるから要注意