WordFes Nagoya 2016 セッションにて発表 [Point] ・WordPressは、KUSANAGI (nginx) on AWS 構成 ・502対策に CloudWatch Logs と SQS による、自己復旧システムを導入 ・本構成により、低コスト化 & 高利益化を実現

1. KUSANAGIを触ってみた
Presented by WordFes Nagoya 2016
-実際に運用してみて-

2. 自己紹介
• 横井 公紀
• https://www.facebook.com/kiminori.yokoi
• Sierに勤務しています。
• 主にクラウド(AWS, Azure)の
活用提案・環境構築を行っています。

4. まず取り急ぎ
理解しておいてほしいこと

5. IoT時代の到来
2 0 1 6 年

8. あらゆる情報が
インターネットに集まる時代

9. 集まった情報は
どうなる？

10. 常時、分析され可視化される

11. 可視化されたデータは
どうなる？

12. みんなが見に来る
！！→

13. リアルタイムに情報を集め
リアルタイムに見せる基盤が必要

14. WordPressなら
プログラム
XMLRPC

15. WordPressなら
プログラム
XMLRPC
API サービス
自動
自動
自然事象
SENSOR
自動

16. IoT時代には高性能が求められる
プログラム
XMLRPC
API サービス
自動
自動
自然事象
SENSOR
自動
非常に多くのリクエスト
非常に多くのセッション
非常に多くのデータ
さらにリアムタイム更新

17. リアルタイムに大量のデータを
素早く表示させたい
でもコストはかけたくない
★ニーズ

18. そこで
KUSANAGI

19. KUSANAGIとは

20. KUSANAGIとは
私は非常に残念です。解散しない道はなかったのでしょうか。
ちなみに「どんないいこと」と「セロリ」が好きです。

21. KUSANAGIとは
三種の神器の一つ。草薙剣（くさなぎのつる
ぎ）、草那芸之大刀（くさなぎのたち）の異名
である。熱田神宮の神体となっている。三種の
神器の中では天皇の持つ武力の象徴であるとさ
れる。
「草を薙いだ剣」
ヤマトタケルが伊勢神宮でこれを拝受し、東征
の途上の駿河国で、この神剣によって野火の難
を払い、草薙剣の別名を与えた。この説は広く
知られているが、日本書紀では異伝とされてい
る。現在の静岡県には、焼津、草薙など、この
神話に由来する地名が残る。 Wikipediaより!
ということは、熱田神宮にあるってこと?

22. KUSANAGIとは

23. KUSANAGIとは
• はやい
• やすい
• うまい

24. KUSANAGIとは
• はやい
• やすい
• うまい

25. KUSANAGIとは
• はやい: 素速い応答
• やすい: 利用は無償
• うまい: チューニング

26. KUSANAGIは速い

27. 実際に
運用した例

28. 今のWordPress環境
AWS東京リージョン
エンドユーザ
AZ-A
WEB WEB S3
(動的変更
コンテンツ用
ストレージ)
画像等の
静的コンテンツ
CloudWatch
(監視サービス)
AWS Labmda
(自動記事
投稿用)
AWS Labmda
(データ取得用)
WEBサービス

29. 以下モデルを具現化したもの
プログラム
XMLRPC
API サービス
自動
自動
自然事象
SENSOR
自動

30. (参考) 昔のWordPress環境
AWS東京リージョン
エンドユーザ
AZ-A AZ-C
・・・ ・・・WEB WEB WEB WEB
EC2
RDS
(Master)
S3
(コンテンツ用
ストレージ)
EC2
画像等の
静的コンテンツ
RDS
(Slave)
CloudWatch
(監視サービス)

31. 何が
変わったのか

32. ランニングコストが落ちた

33. EC2 (昨年12/20に移行)

34. 全体

35. 確実にコストが落ちている

36. Before

37. After

38. Before vs After
• EC2利用料 $55.34 → $28.89
– Auto Scalingしなくても負荷に耐えるため、
サーバ1台分の費用まで落ちた。
– ロードバランサー(ELB)が不要になり
費用が落ちた。
• データ通信料 $18.42 → $22.97
– レスポンスが早くなり、ページ回遊数と
滞在時間が増えたためと推測。
• 広告クリック率は0.25% → 0.64%に！

39. 従来型クラウド時代のコスト
費用
期間

40. これからの時代のコスト
費用
期間

41. なんと
応答速度が・・・

42. !!!!??!?!?!?

43. そんな！KUSANAGIにしたけど
早くならないなんて！
• 全てのコンテンツが自サーバあるいは、
ブラウザキャッシュが効いている
他サーバから返されているか?
• Google Chromeでレスポンス速度を
確認することが可能でした。
一度見てみたところ・・・

44. 多くはキャッシュから返ります

45. ワースト3を見てみましょう

46. まさかのボトルネック

47. Adsenseは表示が遅い
• Google Adsenseの「非同期コード」を
使うと、他のHTMLコードの読み込みを
待たずに読み込むことができるため、
多少早まりますが、Nginxを極めると、
このオプションを使用しても
広告の表示のほうが遅い場合があります。
• ページの読み込みが遅い時の対策に
有効だったのですが、ページのほうが
早くなってしまいました。。。

48. 自サーバだけで
完結していなければ
ならない (大前提)

49. 外部参照はできる限り少なく
• Google Adsenseのように外部サーバを
参照するコードはなるべく書かないようにし
ます。
• ほとんど気にならない程度とはいえ、
KUSANAGIの効果を打ち消してしまいます。

50. ページが早く表示されることの
意味
出展:ページ表示2秒でイライラし始め、3分の1は「もういいや」となる,
安田英久, ITMediaビジネスオンライン, http://bizmakoto.jp/makoto/articles/1005/19/news005.html

51. 速度以上に
悩まされたのが…

53. 502それは破滅の始まり
• 3週間に1度くらいの頻度で出現
• 厄介なことに原因がよくわからない (調査中)
– KUSANAGI固有ではなくnginxの事象か？
– 色んなログを見ても明確に特定が難しい。
– アクセスログを見ると前触れ無く突然に
502が出現している。
• 一度出現すると502のまま復旧しない
– 個人運営ゆえ、ユーザ様からの連絡に気づかず
24時間以上放置したことも…
– 放置すると「閲覧不可である状態」のキャッシュが
残ってしまう？

54. 眠れない夜。君のせいだよ。
早朝帯とはいえ3時間止まり、約400ユーザ様が
閲覧できず。

55. 502を
やっつけろ！

56. I will give you all my love.
2 0 1 6 年 6 月

57. 502オート自己復旧システム
CloudWatch Logs
SQS
502検知で
キュー発砲
定期的にポーリング
キューがあれば、
キューを消してEC2を再起動
access.logを監視

58. CloudWatch Logs画面

59. Amazon SQS画面

60. 管理者への連絡はメール(SES)で

61. 障害による影響は極小的に
閲覧不可時間帯を約3分に縮め、
数字が若干落ちる程度までに。

62. 再起動時には以下も実行
• KUSANAGIキャッシュの削除
– KUSANAGI高速化の最大の恩恵である
キャッシュも、再起動前の変な状態のものが
残らないように、全て削除します。
• 念のためパッチ当て
– もしかしたらセキュリティホールかも？の不安。
– 自動でyum –y update を実行します。

63. これで一安心！

64. なお障害発生時、管理者は・・・
この仕組みがなかったら、本日私はここにいなかったかもしれません。

65. 緊急時の窮地を救う

66. まとめ
• KUSANAGI(nginx)を導入することによる
期待効果は
– 数百・数千という大量の同時接続を
処理することが可能
– これらの接続に対して高速にレスポンスを
返すことが可能
– ランニングコストの削減、アクセス数の増加、
コンバージョンの増加を実現

67. まとめ
• KUSANAGIは、AWSと組み合わせることで
安価・安全に運用できる
– 502発生による閲覧不可問題の対策には
AWSのマネージドサービスの組み合わせが有効
– AWSのマネージドサービスは殆どコスト不要
– CloudWatch × SQSで、502の影響時間を
極小化することが可能

68. 上手く使って
最速の頂きと
最高の利益を

69. THE BEST
OF
COMBINATION

70. ON

71. 提 供
フィクションなので、金銭の授受はありません

72. 提 供
フィクションなので、金銭の授受はありません

73. 提 供
フィクションなので、金銭の授受はありません

74. END
ご静聴ありがとうございました。