読者です 読者をやめる 読者になる 読者になる

大量の PUSH 通知前に AutoScaling で EC2 インスタンスを増やしておきたかったので試作コード紹介

こんにちは。最近暑いですね。
今年の夏休みと秋休みはどこの山で登山しようかと悩んでいる今日この頃です。暑いですね。痩せそうです。そんな暑いなか熱いシステム開発に生きる漢、そう菊池です。こんにちは。今書いててちょっと痩せました。先週の記事はデザイナーの菊池でしたが、今週はエンジニアの菊池が担当しています。

さて、スマホアプリのバックエンドに AWS 使っている方も多いのではなかろうかと想像している今日この頃です。みなさんいかがお過ごしでしょう。外は暑いですね。
Android_robot

そしてスマホアプリの運営と言えば、欠かせないのが PUSH 通知。iOS でいうところの APN。Android でいうところの GCM。そう通称 PUSH 通知です。 「(とても魅力的なすごい)イベントやるから全ユーザーに PUSH 通知送ろう!」
「 んー、ちょっと休眠ユーザー起こすために PUSH 送って見るか」 

などなど、昨今の PUSH 通知は少々乱用気味な感もありますが、それなりの効果があるので手放せないツールのひとつですよね。便利に使えばユーザーと運営と良い関係が築けるものと信じています。

さて、そんな PUSH 通知ですが、さくっと全ユーザーに PUSH 通知すると返す刀でユーザーから大量のトラフィックが押し寄せて来ちゃいますよね。何の準備もしてないと、軽くサービスダウンしてしまったりしませんか!!!

『PUSH 通知は寄せては返す波のよう、返す波音がサーバーダウンのアラームみたいに聞こえるな』と唱っている人がいました。ちなみに僕です。

大量 PUSH 通知後のトラフィックは、通常運用時の数十倍になったりするので、常時 PUSH 通知後の大量トラフィックに対応した分のインスタンス動かしておくとサーバー代がもったいない。地球温暖化の原因になりかねません。最近暑いのはこれが原因でしょうか?!

「いやいやいやいや、大丈夫。大丈夫っす。AWS には AutoScaling ってのがあって、サーバーの CPU 使用率とか見て自動でインスタンス増やしますから。自動でスケールしますよ。なんてったってエラスティックですからね!ハハハハハハ」

僕も最初はそのつもりだったんです。ちなみに↑と言っていたのは僕ですけどね。

AutoScaling は設定すると動くんですが、AutoScaling でアラーム検知してインスタンス数が変更されて、サーバー起動して(しばらく待って、ここでローカルにデプロイさせたりするとそれも待ち時間に追加)、ELB のヘルスチェックが OK になって、実運用に追加されました!ゴール!やったー!

となるまで、結構時間が掛かっちゃうんですよね。
起動し終わった頃には... 手遅れでした。みたいな悲しい時間を過ごすことに。(そのうちさくっとコンテナ上げて瞬時に対応!という風にしたいものです)

Rails プロジェクトでインスタンス起動時にデプロイして、そこで assets:precompile しちゃったりすると数分は待ちますよね。とはいっても、デプロイするたびに AMI 作って設定変更するのもしんどいんです。

Rails?早いよね。プロトタイプ作成、その後の機能追加、そこそこの規模まで気持ちよく書けるし。でも結構デカくなると Typo ぐらい教えてくれよーって気持ちになるよね。でもオイラ負けないよ!』
ちなみに僕の好きな戦法は棒銀です。

ということで、ポイントをまとめると
ここまで書いたら気がつきますよね。

AutoScaling であらかじめインスタンスを増やしてから、PUSH 通知送ればいいじゃないか!

ということをやってみたので紹介したいと思います。

次回予告:「大量の PUSH 通知前に AutoScaling で EC2 インスタンスを増やしておきたかったので試作コード紹介(実装編)」

それではみなさん、冷たいものを食べ過ぎておなかを冷やさないように、ご自愛下さい。
近いうちに実装編の記事を公開するので、よろしくお願い致します。

菊池