[AWS]AWS個人利用は高すぎるって話。

By | 2018年6月22日

 最近はずっとAWS漬けです。どうも、のなめです。

 話題のネタもだいぶ溜まってきているのにブログを放置し続けていました。
このままじゃアカンと思って、ブログを再開するついでに、今のWordPressをAWSに引っ越す作戦を立てました。

んで、その作戦をある程度実行してから、「これ、やっぱり無しだな」ってなったお話です。

 

きっかけ

 さて、ここに来ていただいている方は、AWSでWordPressを使う場合ってどんな構成が思い付きますでしょうか?

 AWSの入門書とか見ると、大体は「EC2インスタンスでWordPressを立ち上げよう!」とか、「EC2+RDSでWordPressを立ち上げる方法」とか「ECSでWordPressを立ち上げてみた」とかそんなことが書かれているんじゃないでしょうか?

 気のせいかもしれませんが、私が見てきたAWSの入門者向け書籍やサイトでは大体WordPressを立ち上げるんですよね・・・・。そのくらいAWSでWordPressを立ち上げるってのが人気なんですかね(笑)
データベースとの絡みとか含めてちょうどいい題材だったのかもしれません。

 だからこそAWSにブログを移してみようと考えたんですよね。ラズパイサーバーよく落ちるし遅いし・・・。

 

構成案

そして最初に考えた構成は、
EC2インスタンス+RDSでWordPressを構成
Elastic Load Balancer経由でSSL証明書貼り付け、ついでに監視
の2軸です。


イメージとしてはこんな感じですね。

 このブログは別に大規模な人気ブログって訳ではないので、何かの拍子にサーバーが落ちてもRoute53でアクセス不可を検知してS3にあるsorryページに飛ばしておけばいいかなという感じです。
(この図にRoute53抜けてるやん…。)

 さて、これの何が問題なのかというと・・・

タイトルに付けたとおりコストが結構高い!!

 ってことに気がついてしまったからですね・・。

 

簡易コスト計算

 AWSには1年間の無料期間がありますが、いったんはそれを無視して簡単にコストを計算してみます。
構成図の中でコストがある程度高いものは大きく分けて3つです。
・Amazon EC2 (+ EBS)
・Amazon RDS
・Elastic Load Balancing

さて、EC2はt2.microインスタンスで、RDSはdb.t2.microインスタンスで計算してみます。

●Amazon EC2のコスト

Amazonのドキュメントによれば、t2.microは1時間辺りで0.0152USDのようです。

すなわち
1日辺りは
0.0152 USD * 24 時間 = 0.3648 USD
1ヶ月辺りでは
0.3648 USD * 30 日 = 10.94 USD
これに加えてEBSの容量が8[GB]辺り1ドル/月くらいかかります。

●Amazon RDSのコスト

Amazonのドキュメントによれば、MySQLのdb.t2.microは1時間辺り0.052USDのようです。

すなわち
1日辺りは
0.052 USD * 24 時間 = 1.25 USD
1ヶ月辺りでは
1.25 USD * 30 日 = 37.5 USD
ただしWordPress程度の目的であれば、データベース自体はEC2インスタンスの中に用意したほうがコスト的にもいいかもしれませんね・・・。

●Elastic Load Balancingのコスト

Amazonのドキュメントによれば、ALBの利用料金は1時間辺り0.0243USDのようです。

すなわち
1日辺りは
0.0243 USD * 24 時間 = 0.583 USD
1ヶ月辺りでは
0.583 USD * 30 日 = 17.49 USD
AWSにサーバーをおく場合には、監視のためにも、SSL証明書を貼るためにもロードバランサーは使っておきたいですね。

 

結論として・・・

 もしもAWSの無料期間が終了してしまった場合には、月々のコストがおよそ8,000円ほどになります。8,000円もあればそこそこいいレンタルサーバーを借りて、SSL証明書も安いところで発行できちゃいますね・・・。
 ラズパイサーバーの場合はサーバー維持費は月々100円程度ですから、8,000円は高い高い・・・。

逆に言うと、1年間無料枠の制度はめちゃくちゃ大盤振る舞いだったんですねぇ・・・・(笑)

 

このブログの構成

 では、このブログは結局どうしたのかというと、CloudFrontを利用しました。
つまりオリジンサーバーはラズベリーパイのままで、各所にキャッシュサーバーを設けることでレイテンシーを防ぐことにしました。
CloudFront自身にも、オリジンサーバーにアクセスできなかった場合には別ページに飛ばすことを行えるため、ELBを使わずに済んでコストも抑えられた感じです。


構成はこんな感じです。

 万が一ラズパイサーバーが落ちてしまっても、キャッシュされている範囲であればユーザーに返答を返すことができます。
もしキャッシュされていないデータであれば、メンテナンスページが変わりに表示されます。

 Route 53でヘルスチェックを行っているので、万が一ラズパイサーバーが落ちてしまってもすぐに認知でき、対策が済むまではキャッシュとメンテナンスページでがんばり続けることができます。

 

そして高速化へ・・・

 CloudFrontを採用したことで、ラズパイサーバーのボトルネックであったサーバー返答の遅さが改善されました。
過去の記事では、ラズパイサーバーがあまりにも遅すぎるので試行錯誤してなんとかベンチマークの得点を上げていこうとしていましたが・・・。

【前回の対策前】
パソコン側:65点
スマホ側:47点

【前回の対策後】
パソコン側:77点
スマホ側:50点

【今回の対策後】
パソコン側:86点
スマホ側:76点

 このスコアはCloudFront上にキャッシュされていることが条件なのですが、CloudFrontを挟んだだけで大幅な得点上昇が見込めました。鯖落ちにも強くなったことも含めてだいぶモチベーションも回復したと思います。

 

おわりに

 いやいや、今日めちゃくちゃ朝早いし忙しいからブログ書いてる暇じゃねぇ・・・!!\(^o^)/

そして続きができました。
[AWS]CloudFrontを導入したときの話。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)