この記事をシェアする

網元を t2.micro に移行して通常運転を1ヶ月行ったので、ざっくりとおすすめの設定とPVや料金の関係性を書いてみたいと思います。

あくまでも私の場合ですので、PV数(転送量)や記事数、更新頻度によって異なりますので目安としてお考えください。

AWSの料金体系(EC2、S3、Route53、MarketPlace)

AWS の Billing & Cost Management にログインします。
左側の「請求書(Bills)」で月毎に料金の明細を確認できます。
「要約」でAWS サービス料金とAWS Marketplace 料金それぞれの合計金額が表示され、「詳細」でその内容を表示しています。

Billing and Cost Management

AWS Marketplace 料金

AWS Marketplace 料金 では 網元HVM版の利用料が請求されています。
ここはインスタンスのタイプと利用時間によって異なります。
t2.micro であれば 1時間あたり $0.005 ですので、1ヶ月30日(720時間)で計算すると $3.6 となります。
(複数のインスタンスを起動したり、インスタンスタイプが異なれば変わります)

AWS サービス料金

EC2、S3、Route53 の利用料金になります(上の写真ではAWS SNS(Simple Notification Service)も記載されていますが無料範囲で収まっているので割愛します)。

EC2(Elastic Compute Cloud)

http://aws.amazon.com/jp/ec2/pricing/

  • インスタンスの利用料(タイプとリージョンによって単価は異なる)
  • EBS
  • データ転送(別枠として Data Transfer に記載)

それぞれの従量課金となります。

Ruote53

http://aws.amazon.com/jp/route53/pricing/

  • ホストゾーン(ドメイン数)
  • クエリ(DNS参照数)

それぞれの従量課金となります。

S3(Simple Storage Service)

http://aws.amazon.com/jp/s3/pricing/

  • ストレージ(容量)
  • リクエスト(参照数)

それぞれの従量課金となります。

料金で支払いの多いもの

請求で一番の比率を占めているのが EC2のインスタンス利用料金、その後に網元利用料金、データ転送料金、Route53、S3の順番です。
グラフを見れば一目瞭然ですが、EC2で6割以上を占めます。

円グラフ


網元とt2.microインスタンスのおさらい

ここで網元とt2.microインスタンスについておさらいします。

網元

WordPress はデータベースを必要としますが、網元の場合は EC2 インスタンスの中にデータベースを入れています(Amazon RDS を利用していない)。
また、表側にアクセスがあった場合は Nginx のリバースプロキシーキャッシュを使う事で表示する時間を短くしています。

このため、記事更新時などデータベースへのアクセスが多い時は CPU 使用量が高くなります。
また、HVM版からは SSD を利用するようになったので以前より管理画面など高速化されていますが、その分 EBS の利用単価は若干上がっています。

t2.micro(T2ファミリー)

T2ファミリーの特徴としてバーストと CPU クレジットがあります。
網元+T2ファミリーでバーストするのはどういう状況かというと、

  • データベースへのアクセスが多い
  • PHPで処理してる
  • NetworkOut が多い

となります。

バーストが頻繁に起こって CPU クレジットの残高が常に減るような状態であれば、インスタンスのスケールアップ(=単価も上がる)した方が良いでしょう。
この辺については以前記事を書きましたのでご覧ください

CPU負荷とネットワークアウト

ここでこのブログが入っている7月下旬〜8月上旬のインスタンスの Cloud Watch(CPU使用量:緑、CPUクレジット使用量:オレンジ、CPUクレジット残高:青)と Google アナリティクスの PV を比較して見ます。

cpu1

pv1

PV数では日によってさほど数値が変わらない(時間帯による上下はあるが日単位では同じような山)なのに、極端にCPU消費の多い時がありました。

画像に書き込んでしまいましたが、この日(7/30)はブルートフォースアタックが多く Bot がログイン画面に頻繁にアクセスしていました。(当然トラッキングしていないページなのでPVは残らない)。
また WordPress にログインを記録するプラグイン「Crazy Bone」を入れているため、不正なログインに関しても逐一データベースに記録するのでCPUの負荷が高かったのだと思われます。

8/1には管理画面へのIPアドレスによる制限をかけたので、以後はCPU使用量、NetworkOutともに落ち着いています。

また9/10に小さいながら Gunosy砲を受けたのですが、そのときのPV(セッション)と Cloud Watch(CPU使用量、NetworkOut)を比較した画像がこちらです。

cpu2

pv2

記事執筆時の1:00〜5:00まではCPU使用量(グラフ青)は多いですが、NetworkOut(=PV、グラフオレンジ)自体は低く、記事公開後の特に14:00〜17:00にかけてPVは多くてもCPU使用量が低くなっている事が見て取れます。
(PVのグラフは、オレンジが平常時(前日)、青が記事更新後のPvです)

これは記事執筆時はデータベースへの書き込みが多く、閲覧時はNginxリバースプロキシキャッシュで表側を表示し負荷が低くなっているためです。


CPUにもお財布にも優しそうなエコな設定

リザーブドインスタンス

ブログのように永続的に起動しているインスタンスであればリザーブドインスタンスにすれば単価を安くする事が出来ます。

http://aws.amazon.com/jp/ec2/purchasing-options/reserved-instances/

注意点などはこちらのスライドを参考にしてください

網元HVM版に移行

t1.micro など旧世代のインスタンスを使っているのであれば t2.micro などの新しいインスタンス、すなわち網元HVM版に移行しましょう

ダッシュボードへのアクセス制限

前述したようにCPU負荷が高い状態が続けばインスタンスをスケールアップする事になるので、余計は負荷がかからないようにします。

まず、ダッシュボードへのアクセスを制限します。これはセキュリティの観点からも行う事をおすすめします。
かつ、プラグインではなく WordPress が起動する にIPアドレスやBasic認証で制限してしまう方が良いでしょう。

重たい画像(ファイル)を外部におく

このブログは画像が少ないのですが、写真ブログなど高解像度の画像を多く使う場合はCDNや、Flickr などの外部サービスを使う事をおすすめします。外部サービスにおく事でEC2インスタンスからの NetworkOut が減ります。
また、WordPress の場合一つの画像に対してアップロード時に複数のサイズの画像を生成します。どんどんファイルをあげているといつの間にかディスクフルという状況にもなるのでこれを避ける事にもなります。

テーマやプラグインを見直す

テーマに関しては好みもあったり自作する場合もあるので、一概におすすめする事は出来ませんが、画像を軽くしたりアイコンフォントを使ったり工夫はできると思います。
Font Awesome はCDNを利用できるのでEC2インスタンスからの NetworkOut が減ります。

また、よくある css や js の Minify(圧縮)ですが、元がテキストファイルなので gzip 圧縮転送すれば十分小さくなるため、余りメリットはありません。

プラグインに関しても好みはあるので一例として。

ブログだと関連記事やアクセスランキングのプラグインが人気だと思いますが、プラグインによってはデータベースに頻繁にアクセスするものもあります。

関連記事プラグインでは 「WP Simple Related Posts」 はタグやカテゴリでの一致や任意の記事を関連させつつ、将来的にAWS Kinesisを利用して関連記事を抽出します(作者よりこの部分は 「予定」 だそうです)。

また 「Simple GA Ranking」 はランキング自体をGooleアナリティクスのデータを参照し、APIを利用して表示します。

いずれも重たい処理は WordPress 外部に任せているのが特徴です。


このブログのインスタンスの利用料金など

最後にこのブログを運用しているインスタンスの利用料金やPV数などを提示しますので参考にどうぞ。

このブログの設定など

前提条件として私の利用しているのインスタンスの情報などを書いておきます。
なお、AWS無料枠の権利は終了しています。

AWSの利用サービス

EC2
網元HVM版+t2.micro オンデマンドインスタンスにバーチャルホストで3つのWordPress
EBS
Amazon EBS General Purpose (SSD) volumes 10GB
S3
主にこのブログの画像(絡新婦利用)とWordOnsen in 福島飯坂(2013)の永代供養
Route53
2ドメインのDNSサーバー(gatespace.jp と wbsendai.com)

WordPressの永代供養については StaticPress をご覧ください。

WordPressの設定

メインブログのみ。投稿自体の画像少なめ。

PVなど

同一インスタンスで3つのWordPressを運用していますが、メインブログ以外は余りPVや更新頻度も低いのでほとんどおまけです。

gatespace.jp
このブログ。1日平均450PV程度。平日は500前後、休日は200前後。たまに Gonosy 砲や SNS 砲が来ることもある。記事数75。
theme.gatespace.jp
テーマデモ用。検索エンジンがサイトをインデックスしないようにしているためアクセスがない日の方が多い。更新はしない。
2014onsen.wbsendai.com
イベント用。執筆時点で作成したばかりなのでPVはほとんど無い。

Gonosy 砲などの突発的なアクセスですが、直近で1日で1000PV(t2.micro)、旧インスタンスで2500PV(t1.micro)などありましたが、バーストすらしませんでしたので裁けるPVは まだ余裕がある ようです。
(推定ですが、1000PVあった日でもCPU使用量3%を超えてませんから、3倍ぐらい多くても裁けるように思います)

おいくら

2014年9月の請求です。(月末で確定したので修正しました)
実際にはテストで複数インスタンスを起動していたので、t2.micro 1インスタンスの場合と異なります。

項目 料金
AWS Marketplace(AMIMOTO (HVM)利用料) $3.63
AWS サービス料金 $20.03
(内訳)
Data Transfer(データ転送量) ($1.85)
Elastic Compute Cloud(EC2) ($15.80)
Route 53 ($1.06)
Simple Storage Service(S3) ($0.06)
消費税 ($1.26)
合計 $23.66(およそ2,574円)

ちなみに t1.micro 時の2014年6月以前は平均して$24〜$25の請求だったので若干お安くなりました。


金額だけ見れば某社の VPS(SSD)プランや某社のクラウドの方が安いわけですが、この辺はリザーブドインスタンスにすればもう少し金額が安くなるのかなぁ、と思います。

一概に金額だけでサービスの善し悪しを決められませんが(VPSで一から自分でサーバーを作れとか無理ゲーです)、参考になれば幸いです。

この記事をシェアする