大丈夫な負荷と大丈夫じゃない負荷について – WordPress Meetup in 松本#3発表資料
正直なところWordpressの会でその話する？って感じの内容なのですが、WordPressのシステム上、どうしてもDBがボトルネックになり負荷の影響をモロに受けやすいのです。そのため他のサイトより負荷を未然に推測し、サイトダウンを防ぐ。というところが重要なのかなと思って 、
アクセス負荷をどう考えるか。その導入としてアクセス負荷の掛かり方の種類と負荷の主な掛け方についてLTをしてきました。
超人気ブログの負荷とその他の比較
超人気ブログっていうと皆さん１，２こは思いつくんじゃないでしょうか？それくらい現在ではブログでの情報発信が盛んです。そしてそこで収入を得ている人もいっぱい居ます。（ぼくもそうなってみたい）
今回はそこを例にとってその他の負荷について理解を深めましょう(・ω・)ノ
いつもの自己紹介です。実はちょっとここに微妙な変化が生まれております。
LTではちらっとインスタグラムのアカウントも見せていました。
最近ではコンテンツ制作の他にも運用に力を入れています。この例では僕のアカウントがフォロワーを買わずに（笑）２０００人以上いるフォロワーについて自慢しました。（たまにはいいじゃないですか（笑））
「たった2ヶ月でインスタグラムフォロワーを２０人から２０００人に増やす」。なんてもの面白いネタになるかもですね(´ω｀)
例のごとく自己紹介です。（MAP）
今回は松本市で開催でしたので、ちょっと絞って表示しています。
チームメンバーというか、全部自分です。
デザインをやりながらフロントをやりながらバックエンドもやって運用もする。見ていて大変そうですね。
でも、だからこそちょっと気づくことがあります。今回もそんな話。
重いサイトはイヤ
重いサイトは誰だってイヤですよね。
SEOにだって響くから気をつけなさいと言われている人も居ますし、せっかく面白い記事なのに重くて次が読みたくなくなってきたら悲しいです。アフィリエイターの方はかなりの致命傷です。
最近地元の何万人も集まるイベントに行ってきたのですが、その時にそのイベントサイトがアクセス集中で繋がりませんでした。
イベントのサイトなのに当日見られないっていうのはとてもストレスです。イベントのスケジュールやニュースも載っているはずだったので、きっと「見る必要」があったんだと思います。
そんななか落ちてるっていうのはちょっと無責任極まりない感じがしますね。
そんなことを思い出しながらつぶやきました。
せめてアクセスが集中しそうだとあらかじめ予測できる場合は、
- トップページを一時的に静的HTMLに差し替える（ランディングページ化）
- CDNかます
- index.phpをいじって日時指定コード判定を埋め込む
- サーバを強化する
- そもそもサイトを見なくてもいいイベント運用を行う
なんてことが考えられます。
WordPressの構造上DBを読みに行くのは必然なので、StaticPressで全部。とはいかずともある程度DBコネクションを削減する方法はあったと思います。
負荷を減らすか、負荷を許容出来るようにするか、負荷を任せるか。リスクと一緒の考え方です。
来年もあるようですが、流石に同じことをやらかしては欲しくないですね。
小ネタ
ここに重いゲームもイヤと書いてあります。しかも一番上に。
実は自己紹介のところで、最近の趣味：ソーシャルゲームと書いてありました。次の次のスライドで速攻伏線回収します。
負荷と言ってもみんな同じものではありません。
どういう負荷の掛かり方があるのか。今回はそれがメインテーマでした。
それなりに特徴がありそうなものを５つほど上げてみました。
５番目は特にレアな話なのかも。
超人気ブログサイト
超人気ブログサイトのグラフです。
参考までに負荷が０の時を入れて見やすいようにしています。
今回は記事の投稿をきっかけにアクセス数が伸び、それによって負荷が上昇しているというのを表現しています。
ブログだけではなく、ニュースサイトやまとめサイトなどのキュレーションメディアもそうですね。
ブログの場合は更に検索からの流入や時間軸によっての変化もあるので、一概には言えないところですが、わかりやすく記事投稿基準に表現。
ブログをアップすればするだけアクセスがあり、負荷はどんどん増えていきます。
配信するコンテンツも増えていくのでキャッシュが追いつかないケースもあるので、なかなかCDNだけで安心？といわれると微妙なところです。真面目に設計を考えればそれこそ費用対効果を考えなくては行けないので、まぁ嬉しい悲鳴としておきましょう。
ちなみにキーボードで表現すると「～（波線）」でしょうか。
ソーシャルゲームサーバの負荷
伏線回収しました。
ソーシャルゲームサーバ。最近の趣味でソーシャルゲームをやってたりするのですが、その裏のサーバが気になってしまって・・・
あ、この処理結構負荷かかるな、とか敵１０体以上出てきてよく経験値とか蓄積できるよなとか、パーティ組んだら他の人の動きやエフェクトも通信で賄わないといけないという不夜城的な超高負荷サーバ群の例です。
このサーバたちは常にギリギリの運用で、いつもコストとにらめっこしています。つらいシステムの代表例でもあります。
が、それを解決するシステムとして「詫び石」という革命的なシステムがあるので、ユーザのクレームは少なくなります。
一時的に売上は減少するかもしれませんが、追加費用が発生するわけでもなく、ユーザ離れより全然良いです。むしろ撒き餌的な使われ方もするのでホント羨ましい解決手段ではあります。
ちなみにキーボードでいうと、「~（チルダ上付き）」です。
Yahoo砲の負荷
でましたYahoo砲です。
大体の高負荷といえばこちらを想像するのではないでしょうか。
いつもそんなにアクセス数が無いサイトが、YahooやTVで取り上げられた瞬間から一気にアクセス殺到。
とくにECサイトで起きやすい現象ですね。あとは宿やレジャーの予約もたまにこの砲撃を喰らいます。
こちらの影響は明白で、単純にチャンスロスです。せっかく売上を上げるチャンスだったのに、扉で詰まって注文が受け付けられないという。
さらにこちらの悲惨なところは「忘れられやすい」傾向が強いです。
一過性の負荷を受けてダウンしたサーバが復旧するころには、普段のアクセス数に戻ることが多いです。
そして、大体の方はまたいつ来るかわからない砲撃に備えて不安と期待と高いサーバとともに日々過ごすこととなります。。。
ちなみにキーボードで言うと「へ（ひらがなのへです）」うまく起動に乗れば「ノ」ですが。
うん。がんばろう。
色んな負荷を紹介したあとで小休止。
普段からアクセスのないブログには全く関係の無い話です。
コンテンツから頑張りましょう。（僕も含めて(ヽ´ω`) ）
ちなみにキーボードで言うと「＿（アンダースコア）」です。
番組連動の負荷
実はまぁ自分としてはこれが一番良いたかったのですが、
アクセスが０のサーバにほぼ垂直のグラフ描いてアクセスをさせるというものです。
番組連動だけではなく、イベントでの仕掛けやIoTのセンサー群なども当てはまることがあります。
要は普段は全く使わないけど、使うときは一気に使う。たぐいのものです。
こんなこと言っちゃってますね(´ω｀)
ちなみにキーボードで言うと「」（括弧閉じ）」です。
負荷の危険ボーダー
負荷が全部危ないというとそういうわけでもなくて、危険なボーダーというものが存在します。
スライドの通り１２｜３４５と分けられますが、これでも分かる通り、「急に」負荷がかかるものにはそれなりの対策が必要です。
実体験ベースで個人的意見でしかないですが、サーバレス設計もこれに当てはまります。
そんな一気にDocker立ち上がるような親切なサーバはありません。
負荷が正常か否かが大事
大体の負荷ってサーバ界隈からすれば「不正なアクセス」なんですよ。
いつも数万PVのアクセスがあるなかで、ちょっと１万PV増えたところでそこは正常とみなされることは多いです。
怖いのは数PVしかないのに、いきなり数万PV来るというところです。
単純にDDoSじゃないですかそれ。サーバからしたら例えサーバレスであっても不正なものとして遮断したくなります。
サーバレス構成の場合は、あらかじめこういう一過性の負荷があることをサーバ会社の担当の方に言うこと！！
一気にアクセスが来ても良い準備を整えるのが一番大事ですね。
普段のサイトにそこまで気を使ってますか？
サーバ会社からすれば、真のお客様でさえゴミデータなんですよ。
このあたりきっちりやっておかないと、サイトがゴミデータになります。
お客様がゴミデータってちょっとしたパワーワードなきがしたのでつぶやきました。
大体の負荷には耐えられるサーバもありますが、サーバの選定も事前準備のうちです。
出来ればサーバ担当者に予め「何時何分からどの国から何万アクセスあって、１アクセスあたり何Byte位来そう。だからこのAPIのリミットを緩和して、ELBを暖気しておいて欲しい。」
とここまで言えれば良いのですが、Yahoo砲みたいなものはわからないことの方が多いので、大体は力技（冗長構成）で凌ぎます。
サーバに正常なアクセスなのか、攻撃なのか見抜くのを期待しているのも（WAF）一つの手ですが、最後は推測し、未然に防ぐことを考える人間が必要です。そもそもそうじゃないとWAFとかELBとか暖気とかサーバレスとか静的HTMLとか、WordPressの連想からなかなか出てこないんじゃないかな。と思います。（個人的な感想です）
負荷を掛けてみよう！
いきなり何いってんだって話なのですが、強靭な盾を作るには、それを破る矛が必要になります。
だっていくら説明しても、「ホントにそれで落ちないの？」とか言われちゃうじゃないですか。
なので、負荷を想定したサーバを用意しながら並行して、負荷をかける手段も作ります。（一人でな＼(^o^)／）
あらかじめ負荷試験を行うことをサーバ会社の担当者に連絡して、許可をもらうこと！
大事なのでさっきも書いた似たフレーズをもう一度いいます。
負荷試験もただの攻撃に見られてしまったら、ゴミデータです。サーバに到達するまえに消されてしまうかもしれません。
最悪アカウント停止などもあり得るので、ちゃんと相談してくださいね。
Railgun
レールガンシステムです。
ちょっと中二病っぽいネーミングが気に入ってます（笑）
AWSというサービスを使って、EC2を用途に合わせていくつか用意。（おすすめはc4）Jmeterのテストケースを作って、一気に流すという構成です。
割と最近はスタンダードじゃないでしょうか。
昔某社が、自社のPCでJmeter動かしまくって、「サイトが見れません。サーバ落ちました？」「落ちてませんよ。自社のネットがいっぱいなのでは？」みたいなやり取りが合ったことがあります。自分のネットワークからは撃たないほうがいいです。
同じAWSであれば、VPC内や同じリージョンでやらないよう注意。出来るだけ本番の「インターネットアクセス」に近づけてテストを行いましょう。
レールガンというネーミングの通り、データをストレートに打ち続けるのですが、なにぶんブレが出てきてしまいます。
１００万件アクセスを実現するのに２分とか・・・毎度変わってきます。
だからといってEC2を増やし続けるのも費用が。ということで費用（電気代）がかなり掛かるのが難点ですが威力はそれなりにあります。
Genkidama
レールガンシステムはよくあるJmeterタイプの負荷試験です。
逐次アクセス方式なので、直角に近い負荷をかけようと思ったら、それこそEC2のスレーブが何台増やすかという問題に直面します。
そうなると１秒位の誤差が許されない連動系システムとしてはまだ、負荷が弱いです。
だからこそ、ほとんど最強クラスのgenkidamaシステムを開発しました。
こちらは企業秘密なので、詳しいお話はオフレコで。
ということで振り返り。
急激な負荷をかけるにはやはりそれなりのことが出来るサーバに限られてしまいますが、そうではなくても予測や準備は可能です。
ECサイトなどは極端かもしれませんが、ブログサーバダウンによる、広告収入もロスには変わりありません。
何よりせっかく見に来てくれた方が見られないというのは悲しいですよね。
自分のブログ。なんかちょっと重いなと思ったら、チラッと考えても良いかもしれません。
きみのWebは？どうですか？という問いかけでLTのスライド終了でした。
ちなみにこの写真は自分で撮影した夜景の諏訪湖と、月を加工して作ってみました。
いつも重いブログにイライラしていた方は、サーバ側の苦労も分かって少し優しく接してあげられるようになるかもしれませんね。
以上負荷についてのお話でした。
LT後は・・・
ちょっと延びてしまったので、反省ですね(´ω｀；)しかもちょっと良いところで（笑）
その後は懇親会があったのですが、僕は別件で帰りました。また行きたいです(´ω｀)
読んでいただきありがとうございます！