いますぐ使う CloudFront

CloudFrontとは

台数不明で性能不明ですが、グローバルに配置された、キャッシュサーバー。

効果

CloudFrontをリバースプロキシキャッシュとして立ててみました。お問い合わせページなど動的ページを除いて、ほぼ全部のリクエストをCloudFrontが捌いてくれてます。

d0ff6181-11f1-d277-eee8-2d5999566133.jpg

※効果には個人差がございます

課金ポイント

  • 料金 – Amazon CloudFront | AWS

    • データ転送料金
    • キャッシュクリア料金
      • 1ファイル1回クリアが、月間1000回までは無料。以降は0.005 USD

        • リリースとかでこまめに大量のファイルをクリアすると、金かかる
        • キャッシュ有効期限は24時間。24時間ほっとけるならキャッシュクリア料金かからない

用語整理

  • ひとつのCloudFrontは「ディストリビューション」。

    • EC2やRDSが「インスタンス」と呼んだように。
  • キャッシュルールは「ビヘイビア」
  • キャッシュ元データを配信するサーバーを「オリジン」
    • ELB、EC2、S3、その他のサーバー
  • キャッシュクリアは「インバリデート」
    • 「無効化リクエスト」と書いてある文書もある

CloudFront の設置場所

CloudFront無しの構成

EC2のローカルディスクにすべてがあります。静的コンテンツ、動的ページ、すべてのアクセスを、EC2が捌く必要があります。ApacheとかNginxでキャッシュを効かせると、負荷は軽くなるかも。みたいな涙ぐましいノウハウがあったのです。

f65e1219-60fe-d83f-c483-73b133b04544.jpg

横に置く

昔のCloudFrontは、GETとHEADしか受け付けなかったため、JS/CSS/画像/添付ファイルなどを配信するS3を別立てにして、その手前にCloudFrontを置いていました。HTMLの実装では、cssとかjs、画像のタグに書くのリンクを xxxxxxxx.cloudfront.com にしておくことで、こうできます。図ではS3に置くことにしていますが、リリースでのCSSやJSの同期とか、何かと状況が複雑になりがちです。

40904824-cf46-b636-e04c-ee2462471b96.jpg

前に置く

CloudFrontの2013年10月のアップデート から、すべてのHTTPメソッドを受けてくれるため、ウェブアプリサーバーの手前に置くことができます。この場合は、静的コンテンツはCloudFrontのキャッシュでリクエストを捌き、動的ページはCloudFrontはスルーさせて、EC2で処理させます。

626b87d4-abd6-5ba8-6835-b3319f2722c0.jpg

今からやるなら「前に置く」構成

CloudFront無しの構成に導入するなら、断然「前に置く」構成です。

ウェブアプリのソース改修不要で、CloudFrontを適切に設定して配置するだけでOKなので、面倒がないです。

ただし、特定のページだけIP制限してたりすると、ApacheやNginxの設定を変更する必要があります。

とりあえずCloudFrontを立てる

必須項目だけ埋めて、あとで直せばOKです。

  • AWSコンソールにはいる
  • CloudFrontのページに行く
  • Create Distribution
    • Webを選ぶ(RTMPは動画配信とかに使う用)

      • Origin Settings

        • Origin Domain Name

          • ELBエンドポイントURL、BeanstalkエンドポイントURL、S3エンドポイントURL、EC2 DNS名など
          • IPアドレスでなければOK
      • Default Cache Behavior Settings
        • あとで変えるので放置
      • Distribution Settings
        • Alternate Domain Names(CNAMEs)

          • このディストリビューションに当てる予定のドメイン名。
          • 「前に置く」構成なら、これまでELBに当てていたドメイン名を指定。
          • 「横に置く」構成なら、空欄でOK
      • 他はあとで変えればOKなので放置
      • Create Distributionボタン押す
  • ディストリビューションは全世界に分散して立つのと、微妙にダサい仕様のため、しばらく時間がかかります

ビヘイビアの掟

  • ビヘイビアリストの上から順に評価されます。
  • Default (*)は、
    • 一番下から動かせません。
    • 削除できません。
    • どのビヘイビアにも当たらなかった場合のため存在します。
  • パスパターンにマッチしたら、そのビヘイビアだけに従って、キャッシュを見たり、オリジンにスルーしたりする
    • なので、ビヘイビアの上下の並び順は重要

ビヘイビアの設定方針

下記のどちらか。後からでも変更はできますが、どっちで行くかを考えるために、先に切り分けておくと良いです。

  • Default (*)を「キャッシュする」で書く。他のパスパターンは「キャッシュしない」で書く。
  • Default (*)を「キャッシュしない」で書く。他のパスパターンは「キャッシュする」で書く。

キャッシュしないページの設定

  • Path Pattern

    • 仮に http://hoge.example.com/contact/piyo.jpg みたいなとき

      • /contact/piyo.jpg
      • /contact/*.jpg
      • *.jpb
    • みたいに、そのキャッシュルールを適用するパスパターンを指定します。
  • Allowed HTTP Methods
    • 全部入りのを指定
  • Forward Headers
    • 「all」を指定
  • Object Caching
    • Customize
    • TTL(min, max, default)
      • ぜんぶゼロを指定
  • Forward Cookies
    • 「all」を指定
  • Query String Forwarding and Caching
    • 「forward all, cache based on all」を指定

キャッシュするページの設定

  • Path Pattern

    • 仮に http://hoge.example.com/contact/piyo.jpg みたいなとき

      • /contact/piyo.jpg
      • /contact/*.jpg
      • *.jpb
    • みたいに、そのキャッシュルールを適用するパスパターンを指定します。
  • Allowed HTTP Methods
    • GET,HEAD を指定
  • Forward Headers
    • 「Host」は必須。他にも必要なものがあれば追加。
  • Object Caching
    • Use Origin Cache Headers
    • Customizeにして、TTLを入れてもOK
  • Forward Cookies
  • Query String Forwarding and Caching
    • 「forward all, cache based on all」を指定

DNS設定

ビヘイビアふくめて、ディストリビューションの設定が完成したら、DNSの設定を書き換えます。

ディストリビューションには、「d1lxxxxxxxxx.cloudfront.net」のような、一意なドメイン名が発行されます。

Alternate Domain Names (CNAMEs)に入れたドメイン名のCNAMEとして、ディストリビューションのドメイン名を向けた、DNS CNAMEレコードを作成します。

動作確認

サイトにアクセスして、期待したとおりにビヘイビアが設定できているか、確認しましょう。

ChromeのデベロッパーツールのNetworkタブで、個々のファイルのレスポンスヘッダーに下記のようなのがあれば、CloudFrontを経由しています。

Via:1.1 41f313008af830d498dcb13814523bd7.cloudfront.net (CloudFront)
X-Amz-Cf-Id:xcP_6KiTFG_guNA9dRA-KOW6pg740-3mP1SvSrt2NqKGndWGPJKVuA==
X-Cache:Hit from cloudfront

X-Cacheに、キャッシュヒットしたかしてないかが記載されます。HitとMiss、ほかにもいくつかありますが、、、

  • X-Cache:Hit from cloudfront

    • CloudFrontにあるキャッシュが返っています
  • X-Cache:Miss from cloudfront
    • CloudFrontにキャッシュがなく、オリジンから返っています

HitとMissが想定と異なる場合は、ビヘイビアの調整が必要です。がんばりましょう。

その他、TIPS

制限、仕様

導入前に、CloudFrontというプロダクトの制限と仕様が、プロダクトの制限と仕様にマッチするのか、検討が必要です。

参考文書

続きを読む

AMIMOTO AMIを使ってAWSにWordPressをインストールする

2016年の春頃に書いてた下書きが出てきたのでとりあえず投稿する。

  • AMIMOTO HHVM AMIを選んでインスタンスを起動
  • 10分ぐらい待つ
  • Elastic IPを紐付ける
  • Elastic IPのアドレスにアクセス
  • インスタンスIDを入力してWordPressをインストール
  • Route 53から独自ドメインのAアドレスをElastic IPに設定 参考
  • SSHでインスタンスに接続$ ssh -i ec2.pem ec2-user@[Elastic IP]
  • $ sudo yum update
  • SFTPで接続してファイルを操作できるように$ curl -L https://raw.githubusercontent.com/amimoto-ami/run-httpd-as-ec2-user/master/run-httpd-as-ec2-user.sh | sudo bashを実行
  • TransmitでSFTPを設定。サーバ:Elastic IP、ユーザ名:ec2-user、パスワード:ec2.pem、リモートパス:/var/www/vhosts/[インスタンスID]/

SSLを設定

  • $ sudo openssl genrsa -des3 -out ./ssl.newpeace.vision.key 2048で鍵を生成
  • $ sudo openssl rsa -in /etc/nginx/ssl.newpeace.vision.key -out /etc/nginx/ssl.newpeace.vision.keyでパスフレーズを解除
  • $ sudo openssl req -new -key ./ssl.newpeace.vision.key -out ./ssl.newpeace.vision.csrで鍵を生成
  • 参考
  • ssl.globalsign.com.csrの内容を申請フォームに入力
  • SSL証明書を取得
  • SSL証明書をインストール
  • $ sudo vi /etc/nginx/ssl.newpeace.vision.crtで「証明書 SHA256」の内容をコピー
  • $ sudo vi /etc/nginx/dvcacert.cerで「中間CA証明書」の内容をコピー
  • $ sudo cat ssl.newpeace.vision.crt dvcacert.cer > ssl.newpeace.vision.pemで「証明書 SHA256」と「中間CA証明書」を結合(これできない。。)
  • $ sudo chmod -R 777 /etc/nginx/conf.d/でNGINXの設定ファイルに書き込み権限を付与
  • /etc/nginx/conf.d/ssl.default.confを作成して、
/etc/nginx/conf.d/ssl.default.conf
server {
    listen      443 default spdy ssl;
    server_name _;
    root        /var/www/vhosts/i-c3880266;
    index       index.html index.htm;
    charset     utf-8;

    ssl                       on;
    ssl_certificate           /etc/nginx/ssl.newpeace.vision.pem;
    ssl_certificate_key       /etc/nginx/ssl.newpeace.vision.key;
    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers               HIGH:!aNULL:!MD5;

を書く。

default.confcharset utf-8;の下にreturn 301 https://$host$request_uri;を追記

続きを読む

Bitnamiのロゴが邪魔!

AWSの「WordPress powered by Bitnami(HVM) 」AMIにてEC2インスタンスを立ち上げWordPressページにアクセスすると、ページ右下に以下のようなリンクが表示される。それを削除する方法。

スクリーンショット 2017-05-06 15.07.35.png

手順

① ターミナルでEC2インスタンスにアクセス。

 ※接続するためのコマンドがわからない方
 1, EC2コンソールにログイン。
 2, 左サイドバーの Instances をクリック

スクリーンショット_2017-05-06_15_18_47.png

 3, 上部の Connect ボタンをクリック。すると、コマンドが表示されるため、その通りに実行。

スクリーンショット_2017-05-06_15_12_57.png

② EC2インスタンスに接続できたら、以下コマンド実行。Bitnamiのロゴを非表示にする。

terminal
sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1

③ 次に、以下コマンド実行。Apacheを再起動する。

terminal
sudo /opt/bitnami/ctlscript.sh restart apache

④ 最後に、サイトにアクセスし非表示になっているか確認する。

実行後のターミナル

以下のようになっていれば大丈夫。

terminal
bitnami@ip-000-00-00-00:~$ sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1
bitnami@ip-000-00-00-00:~$ sudo /opt/bitnami/ctlscript.sh restart apache
Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Monitored apache
bitnami@ip-000-00-00-00:~$ 

以上
参考:http://kussuue.com/2016/06/wordpress_bitnami/

続きを読む

WordPressのサーバがメモリ不足で落ちたので、SWAP領域を追加して応急処置

はじめに

先日、ブログサイトとして運用していたWordPressのサーバがメモリ不足で落ちたので、実際にやった対処法をご紹介します。
原因は、深夜にヘッダー画像をアップロードしたり、切り取ったりを繰り返していたら、MySQLが死んだみたいです。

EC2 t2.microのインスタンスはWordPressのサーバに使用すると、ぎりぎり落ちるか落ちないかのスペックみたいですね。

# service mysqld status
mysqld dead but subsys locked

tail -100 /var/log/mysqld.log
// 一部抜粋
2017-02-07 16:41:15 17577 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2017-02-07 16:41:15 17577 [ERROR] Plugin 'InnoDB' init function returned error.
2017-02-07 16:41:15 17577 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-02-07 16:41:15 17577 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-02-07 16:41:15 17577 [ERROR] Aborting

インフラ構成

EC2 t2.microインスタンス1台構成
AmazonLinux
Apache2.2 MySQL5.5 PHP5.6

SWAPとは

ハードディスクなどの補助記憶装置を利用して使用可能なメモリ容量を増やすOSの機能の一つ。
ハードディスク上に「スワップファイル」あるいは「スワップ領域」と呼ばれる専用の保存領域を用意して、メモリ容量が不足してきたら現在使われていないプログラム(プロセス)を一時的にスワップファイルに書き出して消去し、占有していたメモリを開放する。メモリからハードディスクに退避する動作を「スワップアウト」(swap-out)、ハードディスクからメモリに書き戻す動作を「スワップイン」(swap-in)という。

http://e-words.jp/w/%E3%82%B9%E3%83%AF%E3%83%83%E3%83%97.html
より引用

作業内容

とりあえずMySQLの再起動を試しましたが、出来ず。

# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [FAILED]

freeコマンドで現在のメモリの仕様状況を確認します。

# free
             total       used       free     shared    buffers     cached
Mem:       1019280     560060     459220      54268       9936      96820
-/+ buffers/cache:     453304     565976
Swap:            0          0          0

SWAP領域の追加

ddコマンドで、SWAP用ファイルを作成する。
※中身が0で埋め尽くされた、1Gbyteのswapfile1という名前のファイルができます。

# dd if=/dev/zero of=/swapfile1 bs=1G count=1

パーミッションを設定

# chmod 600 /swapfile1

SWAP領域の作成

# mkswap /swapfile1
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=67eb1ae1-16bf-4ed2-9b4c-3808cd59f6d3

SWAP領域を有効化する

# swapon /swapfile1

freeコマンドでSWAP領域が適用されたことを確認

# free
             total       used       free     shared    buffers     cached
Mem:       1019280     949668      69612      54268       3052     481712
-/+ buffers/cache:     464904     554376
Swap:      1048572          0    1048572

MySQLの起動

# service mysqld start
Starting mysqld:                                           [  OK  ]

終わりに

最初MySQLが再起動出来なかった時、正直めっちゃ焦りました笑
なんとか原因がわかって、対処出来てよかったです。
SWAP領域を確保しておくだけで、ある程度の負荷には耐えられるようになるので、サーバのスペックを変更せずに対処出来てオススメです。

読んでいただきありがとうございました!

続きを読む