2016年3月12日に開催された「WordBench Nagoya」2016年3月度勉強会にて発表した資料になります。 (JAWS DAYS 2016行けなくて申し訳ありません)

1. Nginx + WordPress + AWS
NginxでWordPressを
構築してみよう！

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

4. 本日の内容
は、ここからの内容で回収していますが、
この流れは無視してください。

5. 損させない
長い前置き

6. 個人的主観で語る
WEBサイト構築の歴史

7. 2000年～2003年頃
• 無料ホームページサービスが主流
• かつて使ったサービス (tripod)

8. 2000年～2003年頃
• かつて使ったサービス (ジオシティーズ)

9. 2000年～2003年頃
• かつて使ったサービス (使える.net)

10. 2000年～2003年頃
• イラストサイト、テキストサイトブーム。
• HTMLを頑張って覚えた。
• CGIが動いて無料で使えるレンタルサーバ
をひたすら探した。

11. 2000年～2003年頃
• レンタルカウンター、レンタル掲示板、
ゲームCGIを借りて人集めした。
• 2chみたいな掲示板を作って人を集めようとした。
• ホームページランキングサイトに登録して
上位を目指した。
• レンタルサーバの裏の仕組みは
意識しなくても良かった。

12. 2004年～2009年頃
• ブログサービスが主流
• かつて使ったサービス (livedoor)

13. 2004年～2009年頃
• ブログブーム。
• ブログのコメント機能がほぼ掲示板を兼ねるため、
レンタルCGIがいらなくなった。
• 日付ごとに記事を書くという文化が定着した。
• 既存テンプレートを変更して独自のデザインを
作った。
• ブログの裏の仕組みは意識しなくても良かった。

14. 2010年～2013年頃
• ソーシャルページが台頭。
• 集客をいかに収益化するかということも
考えるようになる。
• アフィリエイトが当たり前に。

15. 2013年～2015年頃
• 2000年頃にホームページ作りに
凝っていた学生が、社会に出て収入を
手にする時期。
• 今まで出来なかった「有料サーバ」
「独自ドメイン」などに手を出すための
ハードルが下がりまくる。

16. どこまで
作りこむか?

17. どこまで触りたいと思うか
• 静的HTML/CSSだけ
– 既存の一般ブログサービスで十分できます。
• 動きのあるコンテンツ
– JavaScript, PHPなど覚える必要があります。
– CMSを使って拡張するなどの手段があります。
• ミドルウェア以下まで
– コスト調整、パフォーマンスも思いのままに！

18. 時は2016年

19. クラウド時代のサーバ構築
2 0 1 6 年

20. 自作サーバも
クラウドで！

21. たくさんの選択肢と組み合わせ
×
など
など

22. いままでは
どうしていたのか

23. 自作サーバ上Web構築の変遷
• 2003年頃:
物理PC/サーバにApacheを入れてDDNS
• 2011年頃:
Apache on AWS EC2 の AutoScaling

24. 自作サーバ上Web構築の変遷

25. 現在の主流はクラウド活用
AWS東京リージョン
エンドユーザ
AZ-A AZ-C
・・・ ・・・WEB WEB WEB WEB
EC2
RDS
(Master)
S3
(コンテンツ用
ストレージ)
EC2
画像等の
静的コンテンツ
RDS
(Slave)
CloudWatch
(監視サービス)

26. サーバ構築の敷居を下げたAWS
• サーバ調達は、簡単操作で数分で完了
• CPU/メモリが足りなくても、
プルダウンで選んで一瞬で増やせる
• ネットワークは、CIDRを入力して
ボタンを押すだけの楽々設定

27. 素人でもサーバ構築が可能に

28. それだけではない

29. 素人でも高可用性のある
サーバ構築が可能に

30. 訪れたのは
価格崩壊の波

31. 下がりまくるランニングコスト

32. 求められるスキルの色が変わった
• ただクラウドで作るだけではもうだめ
– サーバ代は安くなる一方。普通に作った時の
ランニングコストは、もはやベースライン。
• クラウドで工夫して作るスキルが必要
– どう作れば、よりコストメリットを得ること
ができるのか。
– どう作れば、より可用性やセキュリティを高
めることができるのか。

33. 時は巻き戻り

34. 従来型のクラウドサーバ構築
2 0 1 2 年
LEGACY

35. 従来型のクラウドサーバ構築
AWS東京リージョン
エンドユーザ
AZ-A AZ-C
・・・ ・・・WEB WEB WEB WEB
EC2
RDS
(Master)
S3
(コンテンツ用
ストレージ)
EC2
画像等の
静的コンテンツ
RDS
(Slave)
CloudWatch
(監視サービス)

36. AWSがサーバ構築の常識を変えた
• 仮想ロードバランサー (ELB)
– ボタン一つで作成。
さらにボタン一つでサーバを接続。
• 自動スケールイン/アウト
(AutoScaling)
– 負荷が小さい時はサーバ1台
– 負荷が大きい時はサーバX台 (X >= 2)

37. それはもはや4年も前のこと

38. 激変したWebサーバ構築
• パフォーマンスチューニングを
AWS任せにすることができた
– Apacheの設定を知らなくても、AutoScaling
に任せておけばサーバが勝手に増減して、
リクエストを捌いてくれるのだから。
• バーチャルホストを考えるくらいなら
サーバをもう1台調達する方が楽になった
– だって、そんなにお金かからないし。

39. ミドルウェアを軽視するように
Apacheの設定が分からなくても
AWSの機能でサーバが勝手に増え、
リクエストを捌いてくれる。

40. そして2016年の今

41. 我々はクラウドに
詳しくなりすぎた

42. もっと安く
運用できないか
※でも高可用性は欲しい

43. クラウドに慣れ
気づいたこと

44. リソースを使わなければ安価
• サーバの起動時間
– 短ければ短いほど安価
• サーバの台数
– 少なければ少ないほど安価
• データ通信量
– 少なければ少ないほど安価

45. 自作サーバ(物理)時代のコスト
費用
期間

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

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

48. 自作サーバ(物理)時代の可用性
可用性
費用

49. 従来型クラウド時代の可用性
可用性
費用

50. これからの時代の可用性
可用性
費用

51. つまりは

52. 低コストで高可用性を目指せ
• AutoScalingは発動しないほうが良い
– サーバ1台で捌けるリクエスト数が多ければ多い
ほど運用コストは下がります。
• サーバは低スペックであればあるほど良い
– 安く運用できます。
• サーバと通信しないほうが良い
– データ転送料もばかになりません。

53. そんなに都合良く
いくものなのか？

54. 新時代のクラウドサーバ構築
AWS東京リージョン
エンドユーザ
AZ-A AZ-C
WEB WEB
RDS
(Master)
S3
(コンテンツ用
ストレージ)
画像等の
静的コンテンツ
CloudWatch
(監視サービス)

55. 簡素になっている！

56. 新時代に不要なもの
• ロードバランサ (ELB)
– 動かすだけで費用が発生。ロードバランサ
からの通信(out)に費用が発生。
• 高スペックサーバ
– 「CPU1コア、メモリ4GB」未満で
頑張ってみましょう。意外と行けます。

57. 新時代に必要なもの
• Amazon S3等、Webサイト機能を持った
クラウドストレージ
– 1GBあたり数円というレベルで使用できます。
– Content-Encoding : gzip を付けられます。
• Amazon Route53
– 月額170円くらい。ドメインも別に契約可。

58. 新時代に必要なもの
• EC2 スポットインスタンス
– 激安の殿堂。落とさないコツを押さえて使う。
• AWS CLI プログラミング技術
– 「落ちたら上げる」は自動化しよう。

59. そして

60. の採用

61. Q: なんと読むのでしょうか?

62. A: エンジン(engine) エックス(x)

63. Nginxとは?
• Webサーバになります。
• リバースプロキシサーバになります。
• ロードバランサになります。
• メールプロキシサーバになります。

64. Nginxとは?
• Webサーバになります。
• リバースプロキシサーバになります。
• ロードバランサになります。
• メールプロキシサーバになります。

65. いつNginxは誕生したのか？
• 誕生は2002年で、公開は2004年。
日本でブログが全盛期になる前に
既に存在していたのです。
• 最新版(1.9.11)は
2016年2月に公開されました。

66. Nginxを管理する「Nginx, inc.」
• フリーでオープンソースなNginxですが、
「Nginx, inc.」と呼ばれる法人によって
管理され、公開されています。
• Nginxの開発、コンサル、有償サポート
を提供しています。

67. 公式ドキュメントが脆弱
• 検索すると、個人が「使ってみた」資料
はたくさん存在している。
• 日本語のドキュメントは少ない！
技術的な調査や裏取りをするには
公式Wikiを頑張って訳すしかない。。。

68. Nginxが解決する「C10K問題」
• 「CLIENT 10000台 問題」
• ハードの性能は問題なくても、
クライアントの数が多くなりすぎると
サーバがパンクしてしまう。
– サーバ側でプロセスが足らなくなる。

69. • 1スレッドで「イベントループ方式」
Nginxのリクエスト処理方式
クエリキューキュー取得
キューを処理
キュー待ち
レスポンスキュー
とにかく投げて処理

70. とにかくすごい

71. m3.medium たった1台で

72. このくらいは序の口。
！→

73. いける。まだまだいける。
！？→

74. むかしむかしは
• その昔は、多くのリクエストを
スケーラブルに処理するために、
AWSのAuto Scalingで頑張っていました。
• その結果、先の画像と同じくらいの
リクエストを捌くことは、
実は可能でした。
• 今のままでも良かった。良かったのです。

75. だがしかし！

76. 「Auto Scalingはお金がかかる」
という発想
• Auto Scalingのおかげで、最初から
最悪の事態を見越してサーバを調達する
必要がなくなり、サーバ調達コストが
落ちました。
• しかし、そもそも論として
「低スペックなサーバ1台で、スケールせず
大量のリクエストを捌く」
ことができれば、もっとコストが落ちると
思いませんか？

77. ならば実現できる

78. 今日は入門編なので
触ってみよう

79. ON

80. シンプルな構成
AWS東京リージョン
エンドユーザ
AZ-A AZ-C
WEB WEB
RDS
(Master)
S3
(コンテンツ用
ストレージ)
画像等の
静的コンテンツ
CloudWatch
(監視サービス)

81. 前提条件
• AWSアカウントは作ってあるという体で
説明します。
• OSはCentOS 7を使用します。
EC2はm3.mediumを使用します。
• VPC (Subnet)、セキュリティ(SG、NACL)、
RDS、S3の説明は必要最小限とします。

82. EC2から
作ってみよう

83. EC2を作ってみよう

84. EC2を作ってみよう

85. AWSにおける「CentOS」
• 「EC2 Marketplace」から選択して、
導入します。
• いかにも追加料金がかかりそうですが、
標準のAWSリソースへの課金以外の
追加料金は発生しません。

86. インターネット公開するには
• 検証用であれば「パブリックIP」
(自動割り当てされるグローバルIP)
• 本番用であれば「Elastic IP」
(固定グローバルIP)

87. EC2を操作するには
• 秘密鍵(pem)を使ってSSHで接続します。

88. インストール
してみよう

89. Nginxをインストールしてみよう
• 早速rootになってyumコマンドを
打ちます。ところが・・・

90. 標準リポジトリにNginxがない！
• CentOS7では、まだ標準のリポジトリに
Nginxが公開されていないようです。
• そこで公式「Nginx.org」のリポジトリ
をCentOSから認識できるようにします。

91. yumリポジトリを追加する
• rootユーザで以下コマンドを
実行してください。
• コマンド
– # yum install
http://nginx.org/packages/centos/7/noarch
/RPMS/nginx-release-centos-7-
0.el7.ngx.noarch.rpm

92. yumリポジトリを追加する

93. もう一度Nginxをインストール

94. 最低限の設定をする

95. サンプルのホストを追加する

96. 必要なものを
入れていこう

97. phpをインストール

98. php-fpmをインストール
• NginxでPHPを動かすために必要

99. php-fpmを設定
• www.confに最低限の設定をします。

100. php-fpmを設定

101. php-fpmを設定

102. php-fpmを起動

103. php-mysqlをインストール
• 「Wordpressあるある」を回避するため
• 存在しないことを確認しインストール

104. 「php.ini」を編集
• 先ほどのphp-mysqlをインストール後実施
←コメントを外して有効化

105. 起動

106. Nginxを起動

107. 試しに
コンテンツを
置いてみよう

108. テスト用コンテンツ

109. 果たして
表示されるのか？

110. 表示された！

111. いよいよ
WordPressの
インストールです

112. WordPressを入手

113. WordPressを解凍・展開
以下略

114. WordPressを解凍・展開
以下略

115. 果たして
表示されるのか？

116. 表示された！

117. さくさく軽快表示

118. さらに速さを
追求しよう

119. チューニングの勘所 (入門編)
• gzipでレスポンスを返すようにすると、
データ通信量が減ります。
• よくアクセスされる静的ファイルには、
必ずブラウザキャッシュが
効くようにします。
– エラーページはキャッシュしましょう。

120. チューニングの勘所 (入門編)
• 無駄なアクセスログを吐かないように
します。
– 404はいらないと考えても良いでしょう。
• fastcgi cacheを有効化します。
– php-fpmに処理を投げる前にキャッシュが
あれば返してくれます。

121. 一通りやったけど
あまり早くならないよ

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

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

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

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

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

127. 自サーバだけで
完結するのが
一番速いということか

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

129. どのくらい
安くなったのか

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

131. 全体

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

133. Before

134. After

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

136. は
訪問者離れを
食い止める

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

138. で大量の同時接続を捌く

139. で高速にレスポンスを返す

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

141. 裏側の仕組みを知るって
大事だな。。。

142. 今日から早速
試してみよう

143. ON

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