Nginx + WordPress + AWS

NginxでWordPressを構築してみよう！

自己紹介

• 横井 公紀• https://www.facebook.com/kiminori.yokoi

• SIerに勤務しています。

• 主にAWSクラウドの活用提案・環境構築を行っています。

本日の内容

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

損させない長い前置き

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

2000年～2003年頃

• 無料ホームページサービスが主流• かつて使ったサービス (tripod)

2000年～2003年頃

• かつて使ったサービス (ジオシティーズ)

2000年～2003年頃

• かつて使ったサービス (使える.net)

2000年～2003年頃

• イラストサイト、テキストサイトブーム。

• HTMLを頑張って覚えた。

• CGIが動いて無料で使えるレンタルサーバをひたすら探した。

2000年～2003年頃

• レンタルカウンター、レンタル掲示板、ゲームCGIを借りて人集めした。

• 2chみたいな掲示板を作って人を集めようとした。

• ホームページランキングサイトに登録して上位を目指した。

• レンタルサーバの裏の仕組みは意識しなくても良かった。

2004年～2009年頃

• ブログサービスが主流• かつて使ったサービス (livedoor)

2004年～2009年頃

• ブログブーム。

• ブログのコメント機能がほぼ掲示板を兼ねるため、レンタルCGIがいらなくなった。

• 日付ごとに記事を書くという文化が定着した。

• 既存テンプレートを変更して独自のデザインを作った。

• ブログの裏の仕組みは意識しなくても良かった。

2010年～2013年頃

• ソーシャルページが台頭。

• 集客をいかに収益化するかということも考えるようになる。

• アフィリエイトが当たり前に。

2013年～2015年頃

• 2000年頃にホームページ作りに凝っていた学生が、社会に出て収入を手にする時期。

• 今まで出来なかった「有料サーバ」「独自ドメイン」などに手を出すためのハードルが下がりまくる。

どこまで作りこむか?

どこまで触りたいと思うか

• 静的HTML/CSSだけ– 既存の一般ブログサービスで十分できます。

• 動きのあるコンテンツ– JavaScript, PHPなど覚える必要があります。– CMSを使って拡張するなどの手段があります。

• ミドルウェア以下まで– コスト調整、パフォーマンスも思いのままに！

時は2016年

クラウド時代のサーバ構築

2 0 1 6 年

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

たくさんの選択肢と組み合わせ

×など

など

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

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

• 2003年頃: 物理PC/サーバにApacheを入れてDDNS

• 2011年頃:Apache on AWS EC2 の AutoScaling

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

現在の主流はクラウド活用

AWS東京リージョン

エンドユーザ

AZ-A AZ-C

・・・ ・・・WEB WEB WEB WEB

EC2

RDS(Master)

S3(コンテンツ用ストレージ)

EC2

画像等の静的コンテンツ

RDS(Slave)

CloudWatch(監視サービス)

サーバ構築の敷居を下げたAWS

• サーバ調達は、簡単操作で数分で完了

• CPU/メモリが足りなくても、プルダウンで選んで一瞬で増やせる

• ネットワークは、CIDRを入力してボタンを押すだけの楽々設定

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

それだけではない

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

訪れたのは価格崩壊の波

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

求められるスキルの色が変わった

• ただクラウドで作るだけではもうだめ– サーバ代は安くなる一方。普通に作った時の

ランニングコストは、もはやベースライン。

• クラウドで工夫して作るスキルが必要– どう作れば、よりコストメリットを得ること

ができるのか。– どう作れば、より可用性やセキュリティを高

めることができるのか。

時は巻き戻り

従来型のクラウドサーバ構築

2 0 1 2 年

LEGACY

従来型のクラウドサーバ構築

AWS東京リージョン

エンドユーザ

AZ-A AZ-C

・・・ ・・・WEB WEB WEB WEB

EC2

RDS(Master)

S3(コンテンツ用ストレージ)

EC2

画像等の静的コンテンツ

RDS(Slave)

CloudWatch(監視サービス)

AWSがサーバ構築の常識を変えた

• 仮想ロードバランサー (ELB)– ボタン一つで作成。

さらにボタン一つでサーバを接続。

• 自動スケールイン/アウト(AutoScaling)– 負荷が小さい時はサーバ1台– 負荷が大きい時はサーバX台 (X >= 2)

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

激変したWebサーバ構築

• パフォーマンスチューニングをAWS任せにすることができた– Apacheの設定を知らなくても、AutoScaling

に任せておけばサーバが勝手に増減して、リクエストを捌いてくれるのだから。

• バーチャルホストを考えるくらいならサーバをもう1台調達する方が楽になった– だって、そんなにお金かからないし。

ミドルウェアを軽視するように

Apacheの設定が分からなくてもAWSの機能でサーバが勝手に増え、

リクエストを捌いてくれる。

そして2016年の今

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

もっと安く運用できないか

※でも高可用性は欲しい

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

リソースを使わなければ安価

• サーバの起動時間– 短ければ短いほど安価

• サーバの台数– 少なければ少ないほど安価

• データ通信量– 少なければ少ないほど安価

自作サーバ(物理)時代のコスト

費用

期間

従来型クラウド時代のコスト

費用

期間

これからの時代のコスト

費用

期間

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

可用性

費用

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

可用性

費用

これからの時代の可用性

可用性

費用

つまりは

低コストで高可用性を目指せ

• AutoScalingは発動しないほうが良い– サーバ1台で捌けるリクエスト数が多ければ多い

ほど運用コストは下がります。

• サーバは低スペックであればあるほど良い– 安く運用できます。

• サーバと通信しないほうが良い– データ転送料もばかになりません。

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

新時代のクラウドサーバ構築

AWS東京リージョン

エンドユーザ

AZ-A AZ-C

WEB WEB

RDS(Master)

S3(コンテンツ用ストレージ)

画像等の静的コンテンツ

CloudWatch(監視サービス)

簡素になっている！

新時代に不要なもの

• ロードバランサ (ELB)– 動かすだけで費用が発生。ロードバランサ

からの通信(out)に費用が発生。

• 高スペックサーバ– 「CPU1コア、メモリ4GB」未満で

頑張ってみましょう。意外と行けます。

新時代に必要なもの

• Amazon S3等、Webサイト機能を持ったクラウドストレージ– 1GBあたり数円というレベルで使用できます。– Content-Encoding : gzip を付けられます。

• Amazon Route53– 月額170円くらい。ドメインも別に契約可。

新時代に必要なもの

• EC2 スポットインスタンス– 激安の殿堂。落とさないコツを押さえて使う。

• AWS CLI プログラミング技術– 「落ちたら上げる」は自動化しよう。

そして

の採用

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

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

Nginxとは?

• Webサーバになります。

• リバースプロキシサーバになります。

• ロードバランサになります。

• メールプロキシサーバになります。

Nginxとは?

• Webサーバになります。

• リバースプロキシサーバになります。

• ロードバランサになります。

• メールプロキシサーバになります。

いつNginxは誕生したのか？

• 誕生は2002年で、公開は2004年。日本でブログが全盛期になる前に既に存在していたのです。

• 最新版(1.9.11)は2016年2月に公開されました。

Nginxを管理する「Nginx, inc.」

• フリーでオープンソースなNginxですが、「Nginx, inc.」と呼ばれる法人によって管理され、公開されています。

• Nginxの開発、コンサル、有償サポートを提供しています。

公式ドキュメントが脆弱

• 検索すると、個人が「使ってみた」資料はたくさん存在している。

• 日本語のドキュメントは少ない！技術的な調査や裏取りをするには公式Wikiを頑張って訳すしかない。。。

Nginxが解決する「C10K問題」

• 「CLIENT 10000台 問題」

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

• 1スレッドで「イベントループ方式」

Nginxのリクエスト処理方式

クエリキューキュー取得

キューを処理

キュー待ち

レスポンスキュー

とにかく投げて処理

とにかくすごい

m3.medium たった1台で

このくらいは序の口。

！→

いける。まだまだいける。

！？→

むかしむかしは

• その昔は、多くのリクエストをスケーラブルに処理するために、AWSのAuto Scalingで頑張っていました。

• その結果、先の画像と同じくらいのリクエストを捌くことは、実は可能でした。

• 今のままでも良かった。良かったのです。

だがしかし！

「Auto Scalingはお金がかかる」という発想

• Auto Scalingのおかげで、最初から最悪の事態を見越してサーバを調達する必要がなくなり、サーバ調達コストが落ちました。

• しかし、そもそも論として「低スペックなサーバ1台で、スケールせず

大量のリクエストを捌く」ことができれば、もっとコストが落ちると思いませんか？

ならば実現できる

今日は入門編なので

触ってみよう

ON

シンプルな構成

AWS東京リージョン

エンドユーザ

AZ-A AZ-C

WEB WEB

RDS(Master)

S3(コンテンツ用ストレージ)

画像等の静的コンテンツ

CloudWatch(監視サービス)

前提条件

• AWSアカウントは作ってあるという体で説明します。

• OSはCentOS 7を使用します。EC2はm3.mediumを使用します。

• VPC (Subnet)、セキュリティ(SG、NACL)、RDS、S3の説明は必要最小限とします。

EC2から作ってみよう

EC2を作ってみよう

EC2を作ってみよう

AWSにおける「CentOS」

• 「EC2 Marketplace」から選択して、導入します。

• いかにも追加料金がかかりそうですが、標準のAWSリソースへの課金以外の追加料金は発生しません。

インターネット公開するには• 検証用であれば「パブリックIP」

(自動割り当てされるグローバルIP)• 本番用であれば「Elastic IP」

(固定グローバルIP)

EC2を操作するには

• 秘密鍵(pem)を使ってSSHで接続します。

インストールしてみよう

Nginxをインストールしてみよう

• 早速rootになってyumコマンドを打ちます。ところが・・・

標準リポジトリにNginxがない！

• CentOS7では、まだ標準のリポジトリにNginxが公開されていないようです。

• そこで公式「Nginx.org」のリポジトリをCentOSから認識できるようにします。

yumリポジトリを追加する

• rootユーザで以下コマンドを実行してください。

• コマンド– # yum install

http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

yumリポジトリを追加する

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

最低限の設定をする

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

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

phpをインストール

php-fpmをインストール

• NginxでPHPを動かすために必要

php-fpmを設定

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

php-fpmを設定

php-fpmを設定

php-fpmを起動

php-mysqlをインストール

• 「Wordpressあるある」を回避するため

• 存在しないことを確認しインストール

「php.ini」を編集

• 先ほどのphp-mysqlをインストール後実施

←コメントを外して有効化

起動

Nginxを起動

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

テスト用コンテンツ

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

表示された！

いよいよWordPressの

インストールです

WordPressを入手

WordPressを解凍・展開

以下略

WordPressを解凍・展開

以下略

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

表示された！

さくさく軽快表示

さらに速さを追求しよう

チューニングの勘所 (入門編)

• gzipでレスポンスを返すようにすると、データ通信量が減ります。

• よくアクセスされる静的ファイルには、必ずブラウザキャッシュが効くようにします。– エラーページはキャッシュしましょう。

チューニングの勘所 (入門編)

• 無駄なアクセスログを吐かないようにします。– 404はいらないと考えても良いでしょう。

• fastcgi cacheを有効化します。– php-fpmに処理を投げる前にキャッシュが

あれば返してくれます。

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

Nginxにしたけど早くならない？

• 全てのコンテンツが自サーバあるいは、ブラウザキャッシュが効いている他サーバから返されていますか?

• Google Chromeでもレスポンス速度を確認することが可能です。一度見てみましょう。

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

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

まさかのボトルネック

Adsenseは表示が遅い

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

• ページの読み込みが遅い時の対策に有効だったのですが、ページのほうが早くなってしまいました。。。

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

外部参照は少なくしよう

• Google Adsenseのように外部サーバを参照するコードはなるべく書かないようにします。

• ほとんど気にならない程度とはいえ、Nginxの効果を打ち消してしまいます。

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

EC2 (昨年12/20に移行)

全体

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

Before

After

Before vs After

• EC2利用料 $55.34 → $28.89– Auto Scalingしなくても負荷に耐えるため、

サーバ1台分の費用まで落ちた。– ロードバランサー(ELB)が不要になり

費用が落ちた。• データ通信料 $18.42 → $22.97– レスポンスが早くなり、ページ回遊数と

滞在時間が増えたためと推測。

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

ページが早く表示されることの意味

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

で大量の同時接続を捌く

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

まとめ

• Nginxを導入することによる期待効果は

– 数百・数千という大量の同時接続を処理することが可能

– これらの接続に対して高速にレスポンスを返すことが可能

– ランニングコストの削減、アクセス数の増加、コンバージョンの増加を実現

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

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

ON

END

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