最近ブログのアクセスが増えてからWordPressの動作遅くない？
そうなんだよね。前は大丈夫だったんだけど、一時的にスパイクすると表示が遅くなっちゃうね。
なんかいい方法ないの？
色々あるけど、できればあんまりお金をかけたくないな…
Amazon Lightsailが遅い問題
ブログをAmazon Lightsailで運用している人！
はい、僕です。
あんまりAWSでブログ運用している人ってそんなにいないと思います。
有名なレンタルサーバーだとエックスサーバーなどがよく使われているからです。
Amazon Lightsailの良い所
なんと言っても「安い」ことです！
月額500円くらいでWordPress立てられますからね。
エックスサーバーだと、同じ条件で2,000円くらいかかってしまいますので4分の1の料金です。
Amazon Lightsailの課題
Amazon Lightsailの一番の悩みどころは「パフォーマンス」です。
具体的に挙げると以下の点に問題があります。
Amazon Lightsailの課題１：月額500円にする場合のスペック
月額500円だと、1コアCPU・512MBメモリというかなり貧弱なスペックになります。
数人程度のアクセスなら問題無いですが、数十人以上の同時アクセスには耐えられるスペックではありません。
Amazon Lightsailの課題２：バーストパフォーマンスインスタンスしかサポートしない
簡単にいうと、LightsailのCPUは常に100%使えるわけではありません。
常に利用可能なCPU利用率のベースラインが決まっています。
ベースラインを超えると、バーストが始まり、バーストクレジットを使い始めます。
バーストクレジットを使い切ってしまうと、一気にCPUのパフォーマンスが低下してしまうので要注意です。
Amazon Lightsailの遅さをAWSでカバーする
確かに、Amazon Lightsailは遅いです。
それは、スペックの問題やバーストクレジットの問題があるからです。
それにしても、Amazon Lightsailの安さは魅力的ですよね。
では、どのようにAmazon Lightsailをカバーしていくのか説明します。
Amazon Lightsailをカバーする方法１：Amazon CloudFront
Amazon CloudFrontは、WordPressのコンテンツの一部をキャッシュし、Amazon Lightsailの代わりに配信してくれるサービスです。
このようなサービスは一般的に「CDN」と呼ばれています。
Amazon CloudFrontを利用することで、AWSサービスと親和性の高いコンテンツ配信効率の向上を実現する事ができます。
よくある質問：どんなコンテンツをキャッシュしてくれるの？
Amazon CloudFrontは全てのコンテンツをキャッシュしません。
Amazon CloudFrontは画像・JavaScript・CSSといった静的コンテンツをキャッシュします。一方で、PHPファイルやDBといったユーザリクエスト内容や状況によって頻繁に切り替わる動的コンテンツはキャッシュしません。（しないというより、しない設定にするという言い方の方が正しいです）
静的コンテンツはAmazon Lightsailが転送する必要が減るため、パフォーマンス向上とAmazon Lightsailへの負荷低減ができるようになります。
よくある質問：Amazon CloudFrontの料金は？
問題は、Amazon CloudFrontを使うのにどのくらいの料金がかかるか。
ここは少し複雑ですが、ブログであれば気にする必要ありません。
Amazon CloudFrontには3つの課金対象があります。
- インターネットへのリージョンデータ転送アウト (GB 単位): $0.114
- オリジンへのリージョン内データ転送アウト (GB 単位): $0.060
- HTTPS メソッドのリクエスト料金 (1 万件あたり): $0.012
例えばブログページあたり1MBだとして、それが1万件リクエストある場合。
(0.114+0.060)×10,000×0.001+0.012=$1.752
200円くらいです。（安！）
Amazon Lightsailをカバーする方法２：コンテンツデータをAmazon S3にオフロード
Amazon CloudFrontでは、静的コンテンツをキャッシュしてAmazon Lightsailを経由せずに配信することが可能という話をしました。
今度は、その静的コンテンツをそもそもAmazon Lighsailに置くのやめよう！
そういう話になります。
Amazon CloudFrontの問題
Amazon CloudFrontも、キャッシュコンテンツが使えれば処理を効率化できます。
でも、ここには課題があります。
それは、どれだけのキャッシュをヒットさせるかということです。
Amazon CloudFrontにはキャッシュサーバーとなる「エッジロケーション」が何千か所も存在し、国内だけでも数百箇所あります。
なので、誰が、どこからアクセスしてくるかによってキャッシュを使える確率がかなり変動してしまうのです。
Amazon S3で静的コンテンツをAmazon Lightsailから引き離す
キャッシュにヒットしなかったリクエストはAmazon Lightsailに転送されてしまいます。
それを回避するため、静的コンテンツはAmazon S3にオフロードします。
そうすることで、100%の確率でAmazon Lightsailにリクエストされないようにすることができるのです。
静的コンテンツをAmazon S3に同期する方法
とはいえ、今までAmazon Lightsailにあった静的コンテンツをAmazon S3に移行するのは大変ですし、何か変更がある毎に同期しないといけないのは大変ですよね。
それを解決してくれるWordPressのプラグインがあります。
W3 Total Cacheというプラグインは、静的コンテンツを自動的にAmazon S3にオフロードしてくれるんです。
これはまだ試したことが無いのですが、検証完了したら報告します。
Amazon Lightsailをカバーする方法３：バイトコードキャッシング
バイトコード？
バイトコードは直接コンピュータが認識できるプログラムだよ。
WordPressはPHPというプログラミング言語で動作しています。
この言語は「スクリプト言語」のため、プログラムを動作する毎にコンピュータが認識できるバイトコードに変換する必要があるのです。
つまり、3つ目の方法は、このバイトコードを予め生成した状態のものを保持することで処理負担を軽減させるということです。
WordPressでバイトコードキャッシングする方法
WordPressを動作させるPHPは「OPcache」という仕組みがあります。
OPcacheがバイトコードキャッシングを実現してくれるんです。
ただ、こちらはLightsailをお使いの場合はデフォルトで有効になっています。
こういう手法もあるということだけ覚えておいてくださいね。
よくある質問：スクリプト言語と他の言語の違いとは？
この観点でいえば、プログラミング言語は2つの種類があります。
一つはスクリプト言語、もう一つはコンパイラ言語です。
これらの大きな違いは、「バイトコードを生成するタイミング」です。
コンパイラ言語は予めバイトコードを生成するコンパイルを行っているのに対して、スクリプト言語はサイトを閲覧された段階でコンパイルされます。
ですので、スクリプト言語の方が一般的に処理が遅いのです。
まとめ
色々やり方があるのは分かったけど、技術的な話ばっかりでよくわかんなかったよ。
そうだね。Amazon CloudFrontとかAmazon S3とかを使うとなると、どうしても技術的な知識が必要になってきちゃうね。
なんか良い方法ないの？
今後具体的な方法は記事にしていくつもりだから、それを待ってて欲しいかな。
はーい
今回は以上です。
最後まで読んでいただきありがとうございました。
