今回の内容は長文になりすぎてしまったため、結論だけ先に書く。業務サービスとか、シビアなものには さくらの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を利用中のユーザーさんは、突然のアクセス制限にはご注意くださいね、ということで。
次に同じ目に合うのは、あなたかもしれませんよ・・・。
View Comments
はじめまして
さくらのVPS ローカルネットワークについてググっていたのですが、
「さくらのVPSは突然制限かけられて激重になるから要注意」
こちらのタイトルについつい覗いてしまいました。
結論からいいまして、同感のひとことにつきます。
さくらのVPSを計4契約しているのですが、二年ほど前にも重たくなったことで
サポートに問い合わせして、結局のところ解決することなくうやむやにされた経緯が
ありましたので、諦めてはおりましたが、今年になってから別の4Gタイプのプランで
問題が出ましたので、仕方なく問い合わせしましたが、数回の電話のやり取りの末
もちろん例のごとくメールでの調査依頼もしました。
最後の最後に言われたことは、共有サーバであることに変わりはありませんので
それらを保証するサービスではないことで、現状渡しのサービスと言われました。
あくまでも今年に入ってから重たくなっているので共有のユーザーの利用状況に
問題があることは明白なので、対応をして下さいと伝えてもホストサーバに異常が
確認されないので、これ以上の対応は出来ないとはっきり言われました。
契約して利用している側が、結局泣き寝入りをいなければならない、さくらには
ほとほとあきれ返りました。
通常のレンタルスタンダードプランから結構長い付き合いでしたので、信頼していただけに
残念でたまりません。
似たような思いをされている方がいたことを知り、愚痴のようなコメントになりましたが
ご容赦下さいませ。
某S社や大手電話会社系とかの中に居た事がある人です。
どの程度の負荷で制限を掛けているかについては明確に私からはお答できませんが、
この使い方（殊更2Gプランにおいて）は制限されても仕方がないと言えます。
(CPUリソースにはまだ余裕はありますが、I/Oが酷すぎます)
VPSで割り当てられるvCPUコアも、実際のCPUコアと等価ではない事はご存知でしょうか。
さくらはまだ良心的な方ですが、1vCPU = 1/20CPUコア以下と思われる会社もざらにあります。
そのような集積のお陰で、オンプレと比較してずいぶん安価にサーバーを調達出来るのです。
2Gでこのようなリソースの使い方をすること自体が問題なのです。
恐らくwordpress等を使われている程度だとは思いますが、それなら尚更です。
MySQLをいちいち丸ごとdumpする必要は果たしてあるのでしょうか？スナップショットで十分でしょう。
大規模システムの運用・開発をしていると、いかにして効率化するか、リソースを節約するかに心血を注いでいます。
安価に大量のリソースを調達しやすくなり、そして湯水のごとく使える環境に慣れ、
恵まれ過ぎて感覚が麻痺してしまっているのではないでしょうか。
しかし自由なリソース利用を認めてしまうと他の方が必要とするリソースまで消費してしまうのです。ご理解ください。
もう少し、軽量化、高速化、効率化といった観点から使い方を見直してみてください。
CMSもコアから書きなおしたりアドオンを活用して計量化、効率化、高速化を詰めれば
5-10万PV/Dayクラスのデータベースサイトあたりまでなら
レンサバスタンダードプランでもギリギリ（503がちらほら出始めるレベル）運営出来ますよ。
コメントいただきありがとうございます。同様のコメントを複数回いただいていておりましたが、その多くがSPAMに分類されており、通知メッセージが届かず反映が遅くなり申し訳ございません。(当サイトのコメント欄はブログ開始時より承認制を取らせていただいており、手動で反映いたしております)
Disk I/O的に負荷が大きいという点について、本職の方からのご意見、大変参考になります。当時のCMS環境(WordPressではありません) では、当該CMSのみではあるものの、mysqldumpとファイルバックアップを毎日行っておりましたので、そのような使い方はさくらのVPS 2Gでは厳しい使い方である、というご見解だと理解させていただきました。(vCPUに関しては、クラウドなどで等価ではない設定があることは存じております)
また、CMS自体の負荷についても言及いただいておりますが、こちらに関しましては、そもそもかなり軽量のCMSを利用していたことと、制限がかかったタイミングならびに当時のアクセスログ解析の結果から、直接の原因ではないものと考えております。
プロバイダーに代表される、インフラ回りの現場を経験していなかった私の技術力不足ということで、今後のVPS利用の際に関しては、低負荷で効率的な運用ができるよう心がけたく存じます。私自身のポリシーとして、バックアップデータの汎用性を重視しており、VPSだけではなく、レンタルサーバー等への移転の可能性も考えてバックアップ体制を構築しておりましたので、効率や負荷については二の次となっておりました。ご教示いただいたスナップショットなどにつきましては、今後参考にさせていただきます。
ただ、この記事での本題は、さくらのVPSが行う利用制限のあり方についてであり、手動の制限・自動の解除は本当に正しく行われるのか、リソースの制限はどの程度のレベル(厳しさ) で行われているのか、リソース制限対象ユーザーの公平性(常時高い負荷のユーザーと、突発的に数分程度の高負荷が発生したユーザーを一律で規制するのはどうなのか)、制限があったことを何らかの方法で通知できないか(通知がなければ私のように原因追及に苦労する羽目にもなりかねませんし)、といった部分を問題提起しております。その点はご理解いただければと存じます。
あわせて、他社のVPSサービスではさくらのVPSと同様のcronを回しても、現時点において制限がかかったことはないため(もちろん気づいてないだけかもしれませんが)、さくらのVPSのリソースリミットは特別厳しいのではないか(ホストマシンの性能差・マージンの取り方かもですが)、という疑問があったため、このような記事内容となっております。
もちろん、私の技術力不足におけるサーバーへの過負荷がいいことだとは思っておりませんので、今後より効率的なバックアップや処理内容を考えたいと思います。この度は大変参考になるご意見をいただきまして、ありがとうございました。
(2015/04/14・いただいたコメント内容に対しての返信に漏れがございましたので、追記ならびに一部内容を修正しました)
さくらインターネットの利用6年目にして、始めてIOPS制限を喰らいました。
当時のメールをそのまま載せて頂きありがとうございます。「手動で制限をかけている可能性が高い」との情報が非常に助かりました。
私もネットワーク系ですが、上記NEの方の意見には賛成できかねます。
さくらのVPSはKVMベースで動いているのでsnapshot取得は非常に困難です。また、そもそも私たちユーザに与えられているコンソールにsnapshotなんてボタンはありません。
NEの方はmysqldumpは不要だと言いますが、私は6年以上、日次でmysqldumpによるバックアップを行っていましたが、IOPS制限にひっかかった事はありません。6年目にして初めて制限にひっかかりました。サーバを引っ越しした直後に制限に抵触したので、おそらく乱暴な同居人が居たのでしょうね。
正直、今回の対応は不公平感がいなめません。さくらインターネットさんから納得できる回答がもらえなかったら、別業者に乗り換える予定です。
コメントいただきありがとうございます。
この記事を公開してからずいぶん時間も経ち、サーバースペックの向上やストレージのSSD化も進みましたので、さくらのVPSで私が経験したような制限を食らうこともなくなったのではないかと考えておりましたが、まだ同様の制限は行われているのですね。貴重な情報、ありがとうございます。
先にコメントをいただいたNE様のご意見については、例えばLVMを利用したスナップショットなどを想定されていたのかもしれませんね。ただ、LVMのスナップショットも比較的重い処理のようで、やはりホスト側で用意されているスナップショットと比べると、負荷低減という観点からは難しいのかなと感じました。
(参考情報) LVMによる自動バックアップを構築するも、遅いのでボツ
http://nabe.blog.abk.nu/0450
私が利用しておりますGMOクラウドVPSも、DDoSを食らったユーザーを追い出すような対応をしているという話も聞きますし、なかなか廉価でサポートもいいVPSというのは難しいのでしょうが、少なくともさくらインターネットには、制限を掛けるなら掛けるで、公平なやり方というものを考えて欲しいとは思いますね。もちろん、一律のリソースリミットが公平と一概に言えない場合もありますので、難しい面があるのかもしれませんが・・・。
余談ですが、ネットワーク的にやや遠くてもよければ、Contabo VPS M SSDが安い割にスペックが高いですね。私も一つ契約していますが、同じ会社のHDD VPSよりはレスポンスがよく(最高でDisk速度は700MB/secほど出たことも)、4コアCPU・12GB RAM(guaranteed)・300GB 100% SSD(スナップショットも1つ取れます) で月額8.99ユーロは、日本ではあり得ない金額でした。
https://contabo.com/?show=vps
通りすがりですが、私も10台ほど用途に合わせて契約していますが
私は24時間動作させているシステムがあり、私の中ではこのシステムはVPSでは知らせるのは激重だろうなと思っています。しかし常に最新情報である必要から、この部分はどうしても切れません。
が、主さんの負荷グラフを見ると、激重と自負している私のサーバー状況より重い作業をされているように見えます。
CPUもピーク時で200ちょっと超えるぐらいなので。
で、crondailyの件も、主さんのように勘違いしている人がほんと多いのですが、3時〜6時ぐらいは、インターネットを利用する人が減るため、多くのシステム管理者がこの時間帯にバックアップ作業等を自動で走らせるようにしています。
よってこの時間帯のVPSはたいへん重たくなるため、リソースを共有しているという仕様上制限を取らざるを得ません。
この記事を冷静に見て、月1000円程度のものに求めすぎてるなぁ、そんな気がしました。
コメントいただきありがとうございます。
示唆に富んだご意見、大変参考になりました。
その上でまず申し上げたいことは、この記事の本題といたしましては、ユーザーのVPSにリソースリミットをかける際のさくら側の対応が妥当かどうか、という点であることはご理解いただきたく存じます。(記事タイトルがやや扇情的であるため、その点が伝わりづらくなっているかとは存じますが……)
リソースリミットをかけられた際の負荷につきましては、高いサーバー負荷であるということを(他の方のコメントもいただいたこともあり) 理解しており、その点につきましては反省しきりです。
その上で、ご指摘いただきました、
> CPUもピーク時で200ちょっと超えるぐらいなので。
という部分につきましては、おそらく匿名様が使われているVPSの状況かと存じますが、私の利用していた当時の状況でも、週間グラフにあります通り、リソースリミットがかかった当日以外は100前後の値で推移しております。リソースリミット当日に限って、なぜか値が跳ね上がっていることが不可解ではありますが(cronの内容変更はしておりません)、毎日リソースリミットがかかるような処理を行っていたとはやや考えづらい状況でした。
とはいえ、それを含めても(何らかのイレギュラーまたはさくら側のリソースモニターの表示の問題であったとしても) 高い負荷であったとは考えられますので、それをもって私の処理内容は悪くない、などと申し上げるわけではありません。
crontabにつきましても、その時間帯のユーザーアクセス数減少に伴い、バッチなどを回すのに都合が良いことから、そのような時間帯に自動実行されることは存じ上げておりますが、VPS上だとその常識が通用しない点につきましては、私の考えが浅かったことと存じます。
しかしながら、さくら側で簡便に利用できるcron.dailyを使うな、とも取れる返信をいただきましたので、それならその旨を事前に告知して欲しかったかな、という思いがあり、当記事の記述となった次第です。(VPSではcron.dailyなどは使用してはいけない、ということは世間一般の常識と言えるまでには浸透していないのではないかと存じます)
また、1000円程度で利用できるVPSに、過大な期待を抱いていたのは私の落ち度と存じますし、リソースに気を使って利用するべきなのは仰る通りではあるのですが、1000円のVPSにどの程度までの処理をさせることが妥当なのか、という点については個々人によって考え方に違いがあるでしょうし、例えばこの記事の流れを読んだ方の中には、1000円で使えるVPSではWebサイトのデータバックアップとmysqldumpをcron.dailyで回すのにすら気を使わないといけないのか、という感想を持たれる方もいらっしゃるかもしれません。
そのような疑念を払拭するためにも、私としてはさくらや他の業者も含め、リソースリミットの目安開示や、HDDのクォータのようなソフトリミット・ハードリミットのような処理を(可能であれば) お願いしたいと考えているところです。
長文の返信となり、失礼いたしました。