個人のブログ用に WordPress サイトを構築するのに適切な EC2 のインスタンスタイプを考えてみる

本記事のゴール

これまで、AWS 上で Amazon EC2 (EC2) のインスタンスを立ち上げ、WordPress をインストールし個人のブログサイトを構築する手順を説明してきました。

今回は、EC2 のインスタンスタイプに着目し、WordPress サイトを個人のブログ用途で構築するにあたり、どのインスタンスタイプが適切か、考察してみます。

なお、本記事では厳密なスループットを定義した上でのキャパシティプランニング等はスコープ外とします。商用、ミッションクリティカルなサイト構築であれば、必要に応じて負荷試験をお願いします。昨今では wrk や gatling 等、便利なツールがたくさんあると思いますので。

結論ファーストで・・・

今回の考察では、a1.medium、m6g.medium もしくは r6g.medium を個人の WordPress 用の インスタンスタイプに選びます。理由は以下のとおりです。

• T シリーズのように、CPU の利用に制限 (いわゆるクレジットモデルと呼ばれるもの) がない
• WordPress 運用であれば micro サイズ程度で十分
• T シリーズを除いた場合、最も安いのは a1.medium、メモリが 4 GB のインスタンスタイプの中で最も安いのは m6g.medium、メモリが 8 GB のインスタンスタイプの中で最も安いのは r6g.medium

以下、考察を詳細に説明します。

WordPress のデフォルトの設定値を見る

まず、WordPress を使って個人のブログサイトを運営するのに必要なメモリ容量を考えます。

ヒントは、WordPress の設定値にありました。WordPress がインストールされたディレクトリ (本サイトの手順では /usr/share/nginx/html) 配下の、/wp-includes/default-constants.php を見ます。すると、

...
// Define memory limits.
if ( ! defined( 'WP_MEMORY_LIMIT' ) ) {
        if ( false === wp_is_ini_value_changeable( 'memory_limit' ) ) {
                define( 'WP_MEMORY_LIMIT', $current_limit );
        } elseif ( is_multisite() ) {
                define( 'WP_MEMORY_LIMIT', '64M' );
        } else {
                define( 'WP_MEMORY_LIMIT', '40M' );
        }
}

if ( ! defined( 'WP_MAX_MEMORY_LIMIT' ) ) {
        if ( false === wp_is_ini_value_changeable( 'memory_limit' ) ) {
                define( 'WP_MAX_MEMORY_LIMIT', $current_limit );
        } elseif ( -1 === $current_limit_int || $current_limit_int > 268435456 /* = 256M */ ) {
                define( 'WP_MAX_MEMORY_LIMIT', $current_limit );
        } else {
                define( 'WP_MAX_MEMORY_LIMIT', '256M' );
        }
}
...

このように、デフォルトでは一般閲覧用に、シングルサイトであれば 40 MB、マルチサイトであれば64 MB、さらに管理画面用に 256 MB 程度しか与えられていないことがわかります。これらのことから、WordPress で個人のサイトを運営するにはメモリは多くてもせいぜい 1 GB ぐらいあれば十分であることがわかります。

この前提を踏まえて Amazon EC2 のインスタンスタイプを見ると、無料枠が準備されている t2.micro などは、メモリが 1 GB 用意されており、サイズ感としては適切であるように見えることがわかるかと思います。

T2 / T3 インスタンスタイプの罠

無料枠があったため、筆者は t2.micro に飛びつきました。ただ、これが罠であった (適切に EC2 のインスタンスタイプについて理解できていなかった) ことがわかりました。

t2.micro が所属する T2 シリーズ、T3 シリーズ、AWS Graviton2 採用の T4g シリーズ等の T シリーズでは、クレジットモデルと呼ばれるものを採用しております。AWS サイトにも、CPU クレジットについて何かが制御される旨記載があります。別記事を見ると、T シリーズでは一定時間ごとに CPU クレジットが供給され、この供給量を上回る CPU クレジットを消費した場合に、利用が制限され動作が不安定になる、とのことでした。これは、いくら個人用とはいえ外部公開するためのサーバーには向かない特性です。

実際に、筆者は最初 t2.micro で運用していて t2.small に変更、再度 CPU クレジットが枯渇し (一時的に t3.small に変更) たため本格的なインスタンスタイプ変更を決意したのでした。

せっかくですので、CPU 使用率が (意図せず) 急激にあがり CPU クレジットが枯渇した CloudWatch メトリクスをご覧に入れたいと思います。


5/1 の夜一時的にバーストして (CPU 使用率 100% に張り付いて)、5/2 長期間 CPU 使用率が 100% に張り付いたことがわかります。

同様に、CloudWatch メトリクスで CPU クレジットの残量も確認していきます。

5/2 に、CPUクレジットが枯渇していることがわかります。実際、5/2 に WordPress サイトにアクセスできなくなりました (5/2 は t3.small にインスタンスタイプを変更してその場をしのぎました)。

sar コマンド等で詳細を追おうとも思ったのですが、結果サーバが落ちておりログに残っておらず、ここで追跡調査は断念・・。

T シリーズでないとすると、どのインスタンスタイプ？

T シリーズについては、t2.micro に無料枠がある、nano、micro、small と小さいインスタンスタイプが選べるという点で魅力的なインスタンスタイプだったのですが、このクレジットモデルのために T シリーズの利用継続はここで諦めました。

T シリーズを除いた場合に、インスタンスタイプを価格の照準で並べてみます (2021/5/5 時点、価格昇順上位 10 件のみ抜粋)。

最も安い a1.medium、メモリが 4 GB のインスタンスタイプの中では最も安い m6g.medium、メモリが 8 GB のインスタンスタイプの中では最も安い r6g.medium あたりが良さそうです。

Let’s resize!, が、しかし・・・

インスタンスタイプの変更は、通常、まずはインスタンスを停止して・・・

インスタンスが「停止済み」になったことを確認したら、

「アクション」→「インスタンスの設定」→「インスタンスタイプを変更」で、インスタンスタイプが変更できます。

が、今回起動させているのは t2.micro (実際は紆余曲折あり t3.small) の x86 64アーキテクチャのもので、m6g.medium のような arm 64 アーキテクチャのものではありません。そのため、インスタンスタイプを変更しようとしても以下のようなエラー画面になるかと思います。

なので、残念ながらここでサイトの作り直しが確定です・・。悲しいですが、a1.medium は AWS Graviton プロセッサ、m6g.medium / r6g.medium は AWS Graviton2 プロセッサの最新チップセット搭載ということで、溜飲を飲むことにします・・。また、過去記事もこれに合わせて書き換えようと思います。

ネクストアクション

2021/5/5 時点で、WordPress サイト引越し中です。ですので、記事の執筆としては少し毛色を変えて、EC2 インスタンスを構築したときの初期設定についてでも書いていこうかと思います。Google Analytics の導入について書き進めたいと思います！