へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

AWSでEC2のCPU使用率が100%になってSSHログインできなくなった場合の1つの対処法

gunicornというPython WSGI HTTP Serverがあって、それのワーカー数は、通常1とか3、多くてもまぁ10くらいにするんだけど
ノリで誤って3000にして再起動してしまい、当然ながらくっそ重くなった。

「重くなったワロス」と思っていたのだが、CPU使用率がほぼずっと100%になり、SSHログインができなくなった。

$ ssh [target-ec2-instance]

をやると、Operation Timed outが出続ける状態。

とりあえず本番サーバではないので、焦ることもなく、数時間放置したらなんとかなってるといいなと祈ったのだが、当然のようになんともなってなかったので改善することに。


ひとまずAWSで再起動をかけたのだが、何も変化しない。このへんで焦り始める。
その後いろいろググってここが一番マシだった。

https://forums.aws.amazon.com/message.jspa?messageID=678388

ここで、Have you tried restarting or stop/starting your instance?と書いてあったので、restartなんてとっくにしたわボケという思いを抱きながらも、restartとstop/startって変わんねえよなと思いつつも「まあとりあえずやってみるか」と考えを改めて、EC2を停止してみることに。

停止するとEC2についてるVPCへのClassic Linkとかは剥奪されるよとか出てきたので、わざわざ剥奪しなくてもいいじゃんと思いつつも了承。
VPC外にあるEC2から、VPC内に入っているRDSに接続したいのでこのClassic Linkとかいうのを使っている)

stopすると、しっかり停止しはじめる。

全然restartと挙動違うやん……と悪態をつくも無事前進したのでホッと一息。

みなさんもRestartがうまくいかない場合はStop and Startをしましょう。

EC2がStoppedになったのを見て再起動。わくわくしながら見守る。

再起動が終わったあと

$ ssh [target-ec2-instance]

をしてみたのだが、状況変わらず。ふぁ?と思ったので、とりあえず、1万回ぐらいSSHログインさせることに。

たとえCPU使用率が高くても、たくさんやれば1回ぐらいは成功してくれるだろ!!!!!!!的なノリ。
戦いは数だよ

あと、~/.ssh/configで、ServerAliveInterval 12000 ぐらいにして(なんのいみもなかった)

$ for i in `seq 100`; do ssh [target-ec2-instance] "sudo lsof -i:8000 | awk '{print \$2}' | xargs -n 1 sudo kill -9"; done

(この'{print \$2}'の、$の前の\大事。ここで時間食った。)
これを100ウィンドウで同時実行。

しかしなにもおこらない。

えーまだCPU使用率高いのかな?これ詰んだなと思ってEC2のモニタリングを見に行くと、CPU使用率がほぼ0%になっている。

そしてよくみるとElastic IPが外れていた。そりゃ失敗するわ。
インスタンスを停止するとElastic IPも外れるんですね(白目)
しらなかったナァ。ぼくの1時間を返せ。だいたいこんだけで1時間も使ってるとか死にたい。

Elastic IPをつけ直してSSHログインすることに。

SSHログインはできるようになった。ばんじゃーい。

早速おばかなコードを直してサーバを再起動。ちなみに再起動時に1万回SSHログインするやつが処理を邪魔してたので全部killした。

Classic Linkもつなぎ直す

サーバが立ったのを確認してURLを入力して接続するもつながらない。
「ははーんElastic ロードバランサーだな?お前もStopのときにやられたクチか?」とあたりをつける。
(学習能力高い)

案の定OutOfServiceになっていたのでインスタンスの付け直し。InServiceになる。

これでDone。やっふぉおおおおお!


適当にサーバいじると困ることの典型例でした。
ワーカー数3000ってなんだよ……サーバ死んで当たり前だろ……
わかってしまえば簡単な対処法だった。わからなかったのはたぶんノイズが多すぎたせい。



あとAWSのElasticっていうのようやく意味わかった。
あれは普通はElasticじゃないもの(サーバとかロードバランサとかIPアドレスとか)をElasticにしてるから、Elasticってついてるんですね。エラーが出やすい(Errostic)とかじゃなくて。
だからEC2は、Computer + Elasticみたいに考えればよくて、ElasticなところをAWSで管理できる!マジ最高!ってことなわけで、それでみんなAWS使ってるんやでって感じなんですね。

なに当たり前なこと言ってんだって話だけど、でもこれわかってないと、Computer部分がおかしいのかElastic部分がおかしいのかがわからなくて、わからなすぎてハゲる状態になるので、明確にピンと来たのよかった。
だいたいComputerが悪いんだけど、Computer知らないとElasticでComputer部分が覆い隠されてしまうので、最終的にEC2が悪そうに見えるという感じ。

でもAWSはComputer部分に関しては何も悪くない。AWSマジ偉すてぃっく。

もぅマヂ無理。インフラ勉強しよ…

※書くのがめんどくさいのでEC2インスタンスのこともEC2、RDSインスタンスのこともRDSって言ってます。EC2って書いてあるのがEC2というサービスかEC2インスタンスのどちらかなのかは、文脈で判断してください。