「ブログ記事内にある画像ファイルの表示速度が遅い…」
そんな方に向けて本記事では、Amazon Web Services(以下、AWS)が提供しているIAMを使ってユーザーを作成後、S3の画像ファイルを、CloudFrontを経由して表示速度を改善。
さらに、WordPress(以下、WP)プラグインのWP Offload Media Liteを使い、WPにアップロードした画像ファイルを、自動でCDN配信する方法を4つに分けてご紹介します。
構成
対象
- WPを使っている
- 弱いスペックの共用サーバを借りている *1
- Lazy Loadで画像ファイルの遅延読み込み設定をしていない
- ホテルレビューや解説記事など1記事に.pngや.jpg画像を50枚~100枚以上使う(画像サイズによる)
- 共用サーバで月間100万PV以上のサイトを運営している
- AWSのサービスとシームレスな連携をしてみたい
*1 Xserverやmixhostなどの共用サーバは、スペック的に問題はないですが、他ユーザーの(WEBサーバの混雑やシステム障害による)影響を受けるサーバなので、検討する余地があります。
メリット
- 画像を外部サイトから配信してサーバのリソース(負荷)を軽減
.mp3、.mp4、.gif、.wavなどの音声や動画などの重いファイルを、S3上に置いて運営サイトで配信ができる - 画像ファイルの表示スピードが高速化
CloudFrontを経由して画像をキャッシュさせる - サーバのディスク容量の削減
容量が2/3くらいまできているサーバには良いかも
デメリット
- S3は従量課金制
ストレージ容量やリクエスト数などが多ければ多いほど課金される
おおざっぱな目安ですが、月間100,000PV = 10円~100円程度
画像ファイルのディレクトリ
S3 + CloudFront + WP Offload Media Liteの設定する前は、yuichi.co直下のwp-contentディレクトリにあるuploadsに画像ファイルがアップロードされました。
https://blog.yuichisato.net/wp-content/uploads/2017/12/oyama-station-exit-south.jpg
本記事の手順に従って、WP Offload Media Liteをインストールし、S3の画像ファイルをCloudFront経由すると、imgタグのsrc属性がCloudFrontのサブドメイン階層から配信されます。
https://blog.yuichisato.net/wp-content/uploads/2019/05/cat.jpg
1. AWSのIAMを取得
- AWSサービスのフォームにIAMと入力してクリック
- ユーザー
- ユーザーを追加
- ユーザー名を適当に作成→プログラムによるアクセスにチェックを入れる→次のステップへ
- グループの作成
- グループ名を適当に作成→ポリシーフィルタ右隣のフォームにAmazonS3FullAccessと入力→ポリシー名のAmazonS3FullAccessを選択→グループの作成
- 作成したグループ名を選択→次のステップ:タグ
- 次のステップ:確認
- ユーザーの作成
アクセスキーIDとシークレットアクセスキーが作成されます。.CSVでダウンロードして保存しておけば、キーを無くさずに済みます。
IAMキーは、キーを生成したときのみ表示。タブを消してしまったり、ブラウザの不具合で表示できなくなったりした場合は、IAM画面トップから、
ユーザー→ユーザー名→認証情報→アクセスキーの生成
これで、再度キーIDとシークレットキーを生成できます。
2. S3でバケットを作成
- S3
- バケットを作成する
- 適当なバケット名→リージョンをアジアパシフィック(東京)→作成
バケットが作成されました。
バケット名は、既に第三者が作成している名前を付けることができませんので、世界で1つだけのバケット名を考えて入力しましょう。
作ったバケット名の左側にあるチェックボックスにチェック→パブリックアクセス設定を編集する
上記権限項目のチェックを全て外して、保存ボタンをクリック。
*2 既にチェックが外してあるかと思いますが、この権限を保存しないと、WP Offload Media LiteとS3を紐づけることができません。
フォームに確認と入力し、確認ボタンをクリック
アクセス権がオブジェクトは公開可能(S3に入っているファイルが誰でもWEB上で閲覧できる状態)に設定されました。
3. S3で作成したバケットをCloudFront経由で配信
- ホームからCloudFrontと入力してクリック
- Create Distribution
- Get Started
オリジン設定では、オリジンドメイン名をS3で作成したバケット名を選択すると、オリジンIDが自動で生成されます。
デフォルトキャッシュ動作設定の閲覧者ポリシーで、Redirect HTTP to HTTPSを選択。
下にスクロールして、Create Distributionボタンを押します。
IDとドメイン名(サブドメインから始まるcloudfront)、オリジンが生成されます。ステータスは進行中なので、10分ほど待機すると、
デプロイが完了です。
- Distribution Settings
- Domain Name
に、記述されているxxxxxx.cloudfront.netをコピーして、メモ帳でもなんでもいいので貼り付けておきましょう。
4. WP Offload Media Liteをインストールして設定
- プラグイン→新規追加
- 検索フォームにWP Offload Media Liteと入力→今すぐインストール
- インストール中なので待機
- 有効化
- プラグインの有効化に成功
- 設定→Offload Media
WP Offload Media Liteでは、S3とDigitalOceam、Google Cloud Storageサービスを選べます。
Amazon S3で設定したので、Amazon S3と、Define access keys in wp-config.phpを選択して、Nextボタンを押します。
と、設定が成功したアラート画面が出力されますが、Offload Mediaの設定は次に進んでいません。
ここで、IAMで取得したアクセスIDとシークレットアクセスキーを、使用しているWPのwp-config.phpにコピペします。
コピペする場所は、wp-config.phpの中でしたら基本的にどこでも構いません。
筆者の場合は、一目見てわかる箇所が良いので、WPの認証用ユニークキーを生成したNONCE_SALTの下に記述しました。
define('NONCE_SALT', 'hoge'); define('DBI_AWS_ACCESS_KEY_ID', 'アクセスID' ); define('DBI_AWS_SECRET_ACCESS_KEY', 'シークレットアクセスキー' );
コピペして保存後、
NEXTボタンをクリックすると、バケット名を選択できる画面に遷移します。
バケット名が指定されていません
とアラートで指摘されますが、無視します。
Browse existing bucketsをクリックして、
create-bucket-s3(S3で作ったバケットを選択)→Save Selected Bucket
設定が保存されました。
と、アラートが画面上に出力され、設定が成功したと同時に、S3の画像が配信できるようになりました。
このとき、1行少なかったり、キーが正しくないと、
wp-config.phpのファイルを確認してください。定義されているアクセスキーの1つが欠けているか正しくないかどちらかです。
S3のパブリックアクセス設定の権限が正しくないと、
バケットへのアクセスが拒否されました。このバケットへの書き込みアクセス権がないです。 ユーザーに正しいアクセス許可が与えられていない可能性があります。 権限を正しく設定する方法については、クイックスタートガイドをご覧ください。
*2 S3のパブリックアクセス権限のチェック項目が最初から外れていたので、てっきり設定済みかと思っていたら間違いです。
保存していない設定と同じ状態だったので、上記のような赤いアラートが出力されました。
メディアライブラリに写真をアップロードして閲覧可能か確認
WPのメディアで画像ファイルをアップロードして、S3に画像を閲覧できるかどうかを確認してみましょう。
- メディア→新規追加
- 適当な画像ファイルを選択してアップロード
- 編集
s3…から始まるファイルURLにアップロードできており、閲覧ができる状態になっています。
CloudFrontに紐付ける
- Custom Domain(CNAME)をON→CloudFrontで生成されたcloudfrontのサブドメインURLをコピペ
- Force HTTPSをON
- Save Changes
S3をCloudFrontに紐づけることができました。
Rewrite Media URLsは、運用しているサーバではなく、S3やCloudFrontのCDNから配信されるようにURLを書き換えるか否かという意味です。
上記の設定はONにしているので、CloudFront(CDN)から配信されています。
Force HTTPSは、HTTPSを矯正するという意味なので、ONに設定済み。
Remove Files From Serverは、
- ON:画像をサーバ上に残さないでS3にアップロード
- OFF:画像をサーバ上に残してS3にアップロード
サーバ上に残しなくない人は、ONを選びましょう。
CloudFrontを経由して配信しているかを確認
先ほどメディアライブラリにアップロードした手順を参考に、
- メディア→新規追加
- ファイルをアップロード
- 編集
の手順で確認します。
成功です。
ちなみに、先ほどS3に猫画像を上げた際に生成されたファイルのURLが、CloudFrontに変わっています。先述したRewrite Media URLsで設定済みです。
WP Offload Media Liteの特徴
WP Offload Media Liteの無料版と有料版の特徴は、
- 無料版:メディアライブラリにアップされている画像をS3に移行することは不可能
- 有料版:メディアライブラリにアップされている画像をS3に移行することは可能
なので、新規メディア立ち上げの場合は、無料版を選択しましょう。
メディアに画像ファイルを既にアップロードをしていて、画像をS3へ移行したい場合は、有料版をおすすめします。
プラン | 詳細(画像アップロード数の制限) | ライセンス価格 |
---|---|---|
ブロンズ | 2,000 | $69 |
シルバー | 6,000 | $99 |
ゴールド | 20,000 | $199 |
プラチナ | 40,000 | $249 |
アダマンチウム | 100,000 | $399 |
500k | 500,000 | $799 |
アルティメイト | 無制限 | $1,199 |
有料プランの詳細表です。アップロードする画像ファイルの数により、価格が違ってきます。
どうしても無料版を利用したい場合は、公開済み記事に追記する際、公開している記事内の画像を一旦ダウンロードして、再度メディアにアップし、S3に書き換えるようにすれば無料版で済みます。
注意点として有料版は、
- 画像ファイルが大きなサイズでも、リサイズしても、1ファイルとしてカウント
- ライセンスは1年間有効
- 上限に達する前は、アップグレードを促す通知がWPのダッシュボードに表示
- 制限に達しても、重要な機能は継続して使える
- ライセンスをアップグレードしないと、必要性のない機能が無効になる
無料版なら2,000ファイル以上アップしても、ライセンスアップグレードを促す通知はされません。あくまで、既存ファイルをS3に移行するときに有料版が必要となります。
配信をやめたい場合
- プラグイン
- WP Offload Media Liteを停止
で、画像ファイルのURLは元に戻ります。
S3とCloudFrontは、従量課金制なので、使わなければ無課金なので安心です。削除しなくても問題ございません。
IAMは、無料で利用できます。
AWS
・AWS Identity and Access Management (IAM)
・Amazon S3
・Amazon CloudFront
プラグイン
・WP Offload Media Lite
・Pricing for WP Offload Media (formerly WP Offload S3) – Delicious BrainsP
参考
・S3に置いたメディアをCloudFrontから配信する
・WP Offload S3 プラグインでwordpressの画像をS3にアップロード
・Integrating AWS S3 & Cloudfront With WordPress
コメント