対LINE砲戦の行方〜そして、衝撃の結末へ〜

LINE砲への対策で具体案は何一つとして書いてないから技術的なことを知りたい人はLetsブラウザバックをおねがいしますぜ！

さて、先月急遽組み込まれた案件で「LINE砲」に耐えるインフラ環境を用意するというものがあった。

LINE砲という単語は誰が作った言葉なのかわからないけど、LINEでプッシュ通知が送られてユーザが一斉にアクセスするような現象を言う模様。今回自分たちにかせられた目標が１分間3.5万アクセスに耐えるだったっけな…なんか途方も無い数値を出されて誰もが「いや、そんなアクセスないだろ」と疑問に思ったのだけどまぁガタガタ言わず負荷試験の費用やら環境代ももらったので実施するというのが前提。

弊社で管理しているほとんどの案件ではサーバは冗長化提案しろよ！と思うのだけどawsでEC2（Web)が１台、データベースにRDSを１台という構成ばかり。たまに複数台とNFSサーバとRDSという組み合わせもあるけど、希少。

今まで大規模キャンペーンをやったとしても瞬間的なアクセスがそこまで多いものはなかったので自分たちとしても前代未聞の挑戦…果たしてどこまで耐えられるのか！？という眠れない一週間の備忘録。

 ■負荷試験の前提

大規模サイトを構築する上で欠かせないのは負荷試験。特に前例がない規模のアクセスが課題だったので過去の事例から「このスペックのEC2をざっくりX台用意すりゃいいだろ」が通用しない。しかも今回のクライアントの場合、過去に一度キャンペーンが走った際にサイトが落ちており営業担当がリアル土下座に追い込まれているので”二度目はない”。

その前提でまずキャンペーンサイトへの動線を洗い出さなきゃいけないのだけど、それが今回はもうぼろぼろ。当初やっていた負荷試験が覆り意味がなくなり本番数日前にJmeterのシナリオを修正するはめになった。事前に動線についてはDoneを取る必要があると思ったし、メールベースでもなんでもいいけど証拠を残さないとインフラの不手際になってしまう。

同様に想定されるアクセス数も正しいのか裏を取る必要もある。１分３万アクセスの環境と１分９千アクセスの環境では用意するサーバの台数も当然違うし万単位のアクセスの場合、２万と３万でも全然違ってくる。ここは事前に裏付けを取る必要があった。

その上で機械屋っぽく言えば安全率を考慮して２倍、今回は３倍負荷まで耐えられる想定での環境構築をすることになった。

■Jmeterは期待通りの動作をしているか

Jmeterを使った経験が全然なくほぼ１から勉強。Mac miniのローカルにJmeterを入れて負荷試験を行おうと思っていた。この案件の１週間前にはそれで試験を行っていたわけだが、それはせいぜい1000アクセス/１時間でWordPressサイトが落ちなきゃいいの確信を取るものであり全然余裕だったし、Jmeterも期待の動作をした。

今回は違う。

結論からいえば大規模サイトを想定した負荷試験はMac（PC）のローカルからJmeterでは行えない。というよりMacがフリーズしてしまい試験にならない。メモリ８GBのMacBook AirなどではMacがOut of Memoryになってしまう。自分のMac miniはメモリ16GBを積んでいるが、それでもJmeterは動かなくなった。そもそも単一IPからAWSのELBへの大量アクセスを行った場合、期待通りにアクセスが振り分けられない可能性がある模様（アクセスログを見ていれば分かるんだけどね）。そのため、大規模サイトを試験するときはAWS上にでもJmeter環境を構築するのが筋らしい。

AWSへの環境構築および試験はこの方のブログが参考になりました。

dev.classmethod.jp

■AWS環境故の注意

AWS利用者でこのようなサイトを構築するのであれば当然ながらELBは必須になる。

このELBを使う環境に対してとんでもない負荷試験をするような場合、事前に「ELBの暖気運転（Pre-warming）申請」が必要になる。これは「この日にこれくらいのアクセスが見込まれるから予め耐えられるようにELBをスケールしといてね」とお願いするもの。これを行わないとどれだけ負荷を掛けようとしても一定のリクエストまでしか捌けずエラーになる。これを忘れており、延々負荷をかけていたものの必ず決まったアクセス数になるとERRORになったことから「もしや！」と疑われ、結果暖気を申請したら解消された。そこまで大規模じゃないサイトばかり構築しているので頭の片隅からも抜け落ちていたという話。

暖気申請はAWSサポートから実施

・予想されるピークリクエスト数（リクエスト/秒）

・上記の根拠

・予想されるピーク時１リクエストあたりのリクエストサイズ＋レスポンスサイズ

・Pre-warmingが必要となる時間（開始・終了時間）

※XX日0-24時とかざっくりでもOK

・HTTPSの利用有無

・HTTPSを利用する場合のHTTPとの割合（％）

・利用するAZ

・バックエンドinstanceでのKeep-Alive設定の可否

・イベント当日までにEC2を増やすか？増やす場合は何台か？

・トラフィックパターン（どのくらいの期間でどのくらいトラフィックがあがるか）

・ユースケース

ざっくりこれを伝えてAWS側に暖気を準備してもらう。エンジニアをアサインしないといけない関係で急がせてもすぐにはできないので間１日以上は余裕を持ったほうがよい（最近、なんかAWSのサポート対応が遅い気がするんだよなぁ…）

暖気の注意点としては申請するELBに利用している各アベイラビリティゾーン（AZ）に必ず１台は起動しているEC2がないといけない。ELBはあるけどEC２がSTOPしているとかあまり例はないかもしれないけれど、弊社では費用節約のため本番ELBには１台しかEC2がattachされておらず、もうひとつのAZに配置されていたEC２が存在しなかったため本番の暖気申請が直前まで通らなくてドキドキした。

負荷試験環境も申請した時点では費用節約ですべてのEC2を停止にしていてAWSサポートよりSTARTしないと暖気できないと注意された。

今回Jmeter環境をスポットインスタンスで構築したが、このスポットインスタンスを使うのも初で難儀した。構築は難しいことじゃないけれど、入札なので自分が使っている額より高い金額で入札されると問答無用でEC2が消えてしまう。Jmeterクライアントが２０台とかあった時期があり、このときにすべてのinstanceが消えたときは正直泣けた。Jmeterなので一度AMIを取得すれば復元は用意だが、この起動する、すぐに料金があがり落ちる！やっと不人気なEC2を見つけて安定して起動したと思ったら今度はJmeter Server用EC2が落ちるとかを延々繰り返し半日くらいまともに作業ができない日があった…後半はぶちぎれてJmeter環境でスポットインスタンスを使うのをやめた…

そして各種上限値問題。AWSはそのサービスを無制限に使えるわけではなく、VPC EIP（固定IP）であればデフォルトは10個までしか取得できないようになっている。その制限緩和のお願いをAWSに行う必要がある。この緩和は大抵の場合半日程度で行われた。EIP上限緩和はけっこう頻繁に行うので頭の片隅にあったのだけどEC2ががが

よくある質問 - Amazon EC2 | AWS

EC2に上限値があるのは知っていたけど、どうもVolum側にも制限値がありデフォルト20TiBだった模様。さすがに最大稼働時にはEC2だけで60台以上もあったのでそれくらいはいっちゃったんだろうね…ハマったorz...EC2が制限値に引っかかると起動させてもなぜかSTOPになるという謎現象になるので、なぜかこうなる場合は制限値を疑おうという話。

EC2の環境を稼働させるだけでも大忙しだった罠...orz

■AWSに掛かった金額は弊社的には過去最大ｗ

通常時はEC2は開発環境を入れても２台。RDSが本番/開発で２台。これだと月によって変動はするけど月＄1,000くらいで運用できている。

今回はRDSだけでもタイプをMulti-AZでdb.r3.largeを２台（一時期負荷試験用も同サイズ）を使った。このRDSがとにかくやばい…

２月の７日間でRDSだけで先々月分のAWSトータル費用の２倍以上になっている罠。。。

合計金額はわずか６日で$7200超えだ。昨年１２月まではトータル$1000くらいで運用できていたことを考えれば如何に凄いことかお分かりいただけるはず。

■プライベートじゃ試せないけどなかなか勉強させてもらえた

一週間稼働させただけでMT09クラスのバイクが変えてしまい、おそらく１ヶ月運用したらブルターレどころかクルマが買えてしまう金額も個人で運用することはまず無理で、EC2の台数が６０台を越えるような環境を作ったのも初。本番環境でもWeb３２台＋NFSを作ったのも初で、普段作る環境とはまるで違うものを作ることになったわけで…クライアントから費用は貰えたので人のお金で壮大な負荷試験を行えた。

大規模環境の構築は「トーチカ」だと思う。一方的に向かってくる相手から陣地を守り切れる、つまりサイトが落ちない、正常し続けられれば勝利とする。攻撃ではないのでトーチカという表現に違和感はあるのだけど、１分３万アクセス想定は弊社にとれば前代未聞…ゲーム会社とかその手の大規模サイトを常に運用するところは凄いねぇ…改めて自分たちでその環境を作って感じた。

■で、耐え切ったの？

世の中、結果がすべて。大規模サイト運用ノウ・ハウがない弊社にとっては初のお祭り。なので社内は朝からバタバタだった。

LINE砲発射時刻を前に社内のシステム・インフラはざわついていた。

Google Analyticsを前に動向を見守り、AWSのマネコンやNEWRELICを開きつつドキドキしてた。

１０分前

「社内のネットワークが死んだあああああああ」

ま　さ　か　の　社　内　イ　ン　フ　ラ　の　死　。

みんなだいすきYAMAHAのRTX1200シリーズは絶賛稼働中だ、問題はない。

オフィスには有線LAN、無線LAN、動画用専用線の３本が独立して引かれているが有線と無線だけが死んでいた。ルータも違うのに同時に死ぬってことはまずありえない。NTT側でのトラブルか？でも専用線は生きている…

プロバイダか！

プロバイダの障害でしたorz...

なんでこのタイミングで死ぬのよ…orz...

気がつけばLINE砲の発射時刻を過ぎていた（LINE砲側はみんなに任せて社内インフラ復旧に向けて動いていたので自分はそれを見逃した）

ざわつく社内…まさか…？

LINE砲は来ませんでした（ぉ

LINE砲来なかったんだよおおおおおお　(´；ω；｀)ﾌﾞﾜｯ

何を言っているのかわからねぇと思うが、オレにも分からn...

言えることは１つ、発射時刻になっても誰のスマホにもプッシュ通知は来ず、TLにキャンペーン情報が静かに流れただけだった罠。。。

そして…

「最初からプッシュ通知はないという話でした」（by営業

燃え尽きたね…燃え尽きたさ…

プッシュ通知がなく、TLにひっそり流れただけじゃ分間３万アクセスなんてまずない…リアルタイムアクセスでも最大５００人程度だった。。。

どうもクライアントは最初からプッシュ通知をする予定はなかったようなのだけど、伝え間違えておりプッシュ通知があることになっていたらしい。

つまり来るはずのないイベントに備えて２週間…最後の一週間はほぼ徹夜でみんな頑張ったわけだ。。。巨大トーチカ建設したのに終戦しましたとか、爆撃は遥か彼方の別な地方に起きました的な？

それを聞いた時のみんなの絶望感というか喪失感半端ないorz...

当時のシステム・インフラチームのトレンド用語は「帰って寝るわ」だったのは間違いない。LINE砲の１時間前までアプリのチューニングなどで耐えきろうとしたシステムチームの皆さんまじお疲れ様でした…という感じ。

結局、大規模サイトは実戦を経験しないままその１時間後には廃棄され、その日の深夜には２台構成に戻されていた。旧日本軍の幻の兵器を開発した技術者ってこういう気持ちなのかもしれないけど、理論上は最強でどんなアクセスにも耐えられるだろうという環境を使わずにterminateするときの気持ちはなんとも言えないものだった。。。

でも耐えて見せたかったなぁ…

みんな当時の朝まで環境つくりに精を出したし、前述の１時間前まで「まだできることはあるのではないか」と考え続けてくれていたわけなんだし、それを実戦で使って耐えた・耐えられなかったの結果を出せれば大規模サイト運用のノウ・ハウが溜まったはず。練習試合ばかりで本番に挑めないことは気持ちとしては悲しい物があるよね。

とはいえやっぱり勉強にはなっていて、散々使ってきたAWSでもまだ知らないことはあるなぁという気持ちにもなり負荷試験のノウ・ハウもある程度溜まってきた。精神的にも肉体的にも追い込まれた一週間だったけど、得るものはそれなりにあったということで。。。

というわけで！

ジ◯ジ◯ぉおおおオレはクルマを買うぞぉおおおおお！！

そうでもしなきゃいろいろやっていられませんｗ

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)