小規模ブログ環境でリザーブドインスタンスへの変更時のコスト削減例

このエントリーをはてなブックマークに追加
Pocket
LINEで送る

コスト削減目的で使用中の各インスタンスをリザーブドインスタンスへ変更している時に、「そういえば、プライベートで使っている環境もオンデマンドインスタンスのままになっていたっけ」と思い出したので、節約の為にリザーブドインスタンスに変えてみたら、当ブログのような小規模な個人ブログ環境でもこんなにコスト削減できました！という一例の紹介です。
仕事では神経質なぐらい気にするのに、対象がプライベートになると気にしなくなるのは悪い癖ですね。
今回を機に反省して改善します。

今回の目的

身も蓋もないですが、今回の目的は以下の一つだけです。

（プライベートで使用する）お金を節約したい


尚、プライベートで使っている環境とすると少し範囲が広くなってしまう事もあり、変更前後のビフォーアフターを比較し易くする意味で、今回は当ブログに関係するリソースにスコープを絞ってコスト削減を行います。

当ブログの環境と変更前の利用料金

コスト削減を実施する前に、変更前の状態がどうなっているか？の確認です。

当ブログが動いている環境

まず初めに、当ブログが動いている環境の紹介です。
文字で書くと長くて分かり辛い為、図にしてみたのが以下の構成図になります。

よく見るオーソドックスな構成で、特に補足も要らないと思うので割合します。

変更前の利用料金

次に、現状で利用料金が発生しているものと、それらの今回の変更前の料金です。

  1. EC2

    2. ブログを動作させる環境として必要な仮想サーバインスタンス。
    初期の無料枠利用の名残で、インスタンスタイプはt3.micro（無料枠期間はとっくに切れていたので、t3系が出た時にt3に変更）を使用しています。
    リザーブドインスタンスに変更してみましたという記事の対応前の状況になるので、もちろんオンデマンドインスタンスです。

    また、可用性を落とさずに規模拡大時にも対応可能にする為に、AMIから複製したEC2をELB配下に追加するだけでいつでもスケールアウト可能にしていますが、一台で十分な規模のブログなので、もう一台のインスタンス（冗長化後のテスト用に作成）は停止させており、稼働台数は一台です。
    AZ障害などを考えて本来は複数AZに冗長化させておくべきだと思いますが、個人ブログという事もあってそこまでの稼働率は求めていない為、コストを重視して一台で動かしています。

    東京リージョンでEC2のオンデマンドインスタンスのインスタンスタイプがt3.microを、月30.5日計算で算出すると月額料金は以下になります。

    0.0136 * 24 * 30.5 = $9.9552/Month
    EC2 オンデマンドインスタンス 料金表

  2. EBS

    3. EC2インスタンスのディスクとして必要なブロックストレージ。
    I/Oの頻度、要求パフォーマンスが高いインスタンスでもないので、ボリュームタイプは汎用SSD（gp2）で、サイズもデフォルトの10GBです。

    gp2の10GBだとMAXまで使用しても$1.2/Monthにしかならないのと、今回の変更で利用料金の変動がない為、EBSの利用料金は除外する形で進めます。

    EBS 料金表

  3. RDS

    4. ブログの記事や設定などを保存する為に必要なデータベース。
    データベースエンジンは、MySQL（せっかくAWS環境で動かしているので暇を見付けてAuroraに変えたい…）で、インスタンスタイプは最小のdb.t3.microを使用しています。
    EC2と同じく変更前なので、オンデマンドDBインスタンスです。

    また、マルチAZにはしていない（本来はするべきですが、上記に同じく稼働率よりもコスト重視）ので、インスタンスの稼働台数も一台です。

    東京リージョンでRDSのオンデマンドDBインスタンスのインスタンスタイプがdb.t3.microを、月30.5日計算で算出すると月額料金は以下になります。

    0.026 * 24 * 30.5 = $19.032/Month
    RDS for MySQL オンデマンドDBインスタンス 料金表

  4. ELB

    5. インターネットからのアクセスを負荷分散させたり、SSL証明書のアタッチ、EC2に届くリクエストをELB経由のインターナル通信だけに制御するなどの用途で必要なロードバランサー。
    HTTPリクエストが対象の為、バランサの種類はALBを使用。

    主に上記EC2の欄で書いた可用性担保目的で使用していますが、アクセスが増えるなど現構成で運用するのが厳しくなるまではインスタンス一台構成のまま増やす予定がないので、スケールアウト対応を取るまでは主な目的の負荷分散が意味をなしておらず、一旦消しておいた方が良いかも。。。
    ELB配下で冗長化構成にした際の稼働確認は済んでいるのと、構成変更の作業が、EC2のサブネットをパブリックサブネットに変えてセキュリティグループで0.0.0.0/0からのhttp/httpsアクセスを許可するぐらいなので、すぐに元の現構成に戻せるのも一旦消した方が良いと判断した理由です。

    東京リージョンでALBを月30.5日計算で算出した月額料金が以下になります。
    LCUの料金は使用量により変動するのと、額が微額の為、LCUの利用料金は除外する形で進めます。

    0.0243 * 24 * 30.5 = $17.7876/Month
    Elastic Load Balancing 料金表

  5. Route 53

    6. 取得したドメイン名でブログにアクセスさせる為に必要なDNS。
    画像表示用のCloudFrontにもカスタムドメインを使用していますが、ブログ本体と同じドメインのサブドメイン（cdn.masakimisawa.com）として画像も表示させている為、HostedZoneは一つです。

    Route 53の料金体系はHostedZone単位になっており、Hosted Zone一つにつき$0.5/Monthしか料金が発生しないのと、今回の変更で利用料金の変動がない為、Route 53の利用料金は除外する形で進めます。

    Route 53 料金表

  6. CloudFront

    7. 記事画像を保存しているS3の前段に置く、キャッシュ用途で必要なCDN。
    記事や画像、アクセス数などから微額にしかならないのと、今回の変更で利用料金の変動がない為、CLoudFrontの利用料金は除外する形で進めます。

    CloudFront 料金表

  7. S3

    8. 記事画像の保存/参照に必要なストレージ。
    上記CloudFrontに同じくこの規模ではほぼ料金が発生しないのと、今回の変更で利用料金の変動がない為、S3の利用料金は除外する形で進めます。

    S3 料金表

現状発生しているコストはこれぐらいで、EC2、RDS、ELBの三つが大半の為、今回はこの三つを変更してコスト削減していきます。

変更前の利用料金
  $9.9552/Month EC2
+) $19.032/Month RDS
+) $17.7876/Month ELB
  $46.7716/Month ALL

厳密には上記の他にドメイン取得/更新でも料金が発生していますが、今回は割合します。

機能用件

次に、今回の変更に対する機能用件です。
達成必須な内容はもちろんですが、コストは削減したいけどここだけは最低限担保したいという変更不可な制約などが以下になります。

  1. 変更前と比較したコストの削減

    2. 今回の目的でもあり、当たり前な内容ですね。
    どれぐらい減らしたいかの具体的な目標値は決めていませんが、変更前が結構お金がかかっていたのもあり、減らせるだけ減らしたいのが本音ですw

  2. 常時閲覧可能

    3. アクセスの少ない夜間帯はインスタンスを停止させるなどでコスト削減する方法もありますが、Webに公開するブログという位置付けの為、基本的には常時稼働でいつでも閲覧可能な状態を維持するのは担保したいです。

  3. データベースが外出しされている

    4. リソースを増やすだけでいつでもスケールアウト可能な高可用性な構成は維持しておきたい為、データベースをEC2インスタンス内部に持たせるのは避けて、外部に外出ししておく構成は維持しておきたいです。

実施/結果確認

前提の説明が終わったので、早速コストを減らす対応の実施と、それぞれの対応でどれだけ減らせたかを見ていきます。

1. EC2のコスト削減

まずはEC2からです。
EC2のコスト削減は、インスタンスの課金タイプをオンデマンドからリザーブドインスタンスに変更する形で行います。
スポットインスタンスの方が削減額が大きいですが、機能用件に常時閲覧可能になっている事が含まれている為、同機能用件を満たした上でコスト削減が可能なリザーブドインスタンスを選択します。

EC2のリザーブドインスタンス購入は、マネジメントコンソールからEC2の管理画面に移り、サイドメニューのリザーブドインスタンス選択後、「リザーブドインスタンスの購入」を選択します。

検索フォームが出てくるので、それぞれ以下のように入力します。

  • プラットフォーム

    • Amazon Linux2のAMIから作ったインスタンスなので、Linux/UNIX を選択。

  • テナンシー

    • ホストは通常の共有型なので、デフォルト を選択。

  • 提供クラス

    • OS（Amazon Linux2）やインスタンスファミリー（t3）を変更する事はまずないので、割引率が高い スタンダード を選択。
    スケールアウトで台数を追加する事はあるかもしれませんが、その場合は追加したインスタンスが常時起動必須な場合のみ新しくリザーブドインスタンスを購入で対応予定

  • インスタンスタイプ

    • t3.micro を選択。

  • 期間

    • （更新が止まる事はあっても）ブログを閉じる事はないと思うので、割引率の高い 12ヶ月-36ヶ月 を選択。

  • お支払方補

    • 一括で支払いたいので、割引率の高い 全前払い を選択。

検索ボタンを押すと結果が一件だけ出てくるので、カートに入れて先に進みます。

内容の確認画面が表示されるので、問題なければ注文ボタンを押すと完了です。

これでEC2インスタンスにリザーブドインスタンスの割引が適用されます。
リザーブドインスタンスの適用は、インスタンス毎の設定などは不要で、購入したリザーブドインスタンスの内容に合致するインスタンスに自動で適用されます。
t3.microのリザーブドインスタンスを一つ購入すれば、t3.nano2台に対してリザーブドインスタンスの割引を適用させる事も可能など柔軟性のある適用が可能で、権利を買うという感覚です。

また、反映されるまで多少タイムラグがありますが、コストエクスプローラのレポートからRI Utilizationを選択する事でリザーブドインスタンスが正しく適用されているかの確認が可能です。

EC2のリザーブドインスタンス適用時の割引額は公式サイトで確認可能ですが、オンデマンドインスタンスと比較すると以下のように大幅なコスト削減が可能です。

t3.smallのスタンダード/3年/全前払いとオンデマンドの比較
  オンデマンド リザーブドインスタンス 削減額/率
月額 $9.9552 $3.7222
134/36で計算 		-$6.233（額）
-63%（率）
年額（1年） $119.4624 $44.4666
134/3で計算 		-$74.9958（額）
-63%（率）
年額（3年） $358.3872 $134 -$224.3872（額）
-63%（率）

2. RDSのコスト削減

RDSのコスト削減です。
RDSのコスト削減も、EC2と同じくインスタンスの課金タイプをオンデマンドからリザーブDBドインスタンスに変更する形で行います。

RDSのリザーブドインスタンス購入は、マネジメントコンソールからRDSの管理画面に移り、サイドメニューのリザーブドインスタンス選択後、「リザーブドDBインスタンスの購入」を選択します。

入力フォームが出てくるので、それぞれ以下のように入力します。

  • 製品の説明

    • DBエンジンは、mysqlを選択。

  • DBインスタンスのクラス

    • db.t3.microを選択。

  • マルチAZ配置

    • マルチAZにはしていないので、いいえを選択。

  • 期間

    • （更新が止まる事はあっても）ブログを閉じる事はないと思うので、割引率の高い 3年 を選択。

  • 提供しているタイプ

    • 一括で支払いたいので、割引率の高い 全前払い を選択。

  • リザーブドID

    • ブログ用のリザーブドインスタンスの為、blodrdsri と入力。

  • DBインスタンスの数

    • インスタンス台数は1台なので、1 を入力。

入力が完了したら、次へで先に進みます。

内容の確認画面が表示されるので、問題なければ注文ボタンを押すと完了です。

これでRDSインスタンスにリザーブドDBインスタンスの割引が適用されます。
EC2と同じく、リザーブドDBインスタンスの適用にインスタンス毎の設定などは不要で、購入したリザーブドDBインスタンスの内容に合致するインスタンスに自動で適用されます。
db.t3.microは最小サイズなのでより小さなサイズの複数台インスタンスに分割して割引を適用させる事はできませんが、考え方はEC2と同じで柔軟性のある適用が可能で、権利を買うという感覚です。

また、リザーブドDBインスタンスが正しく適用されているかの確認も、EC2と同じくコストエクスプローラのレポートから可能です。

RDSのリザーブドDBインスタンス適用時の割引額は公式サイトで確認可能ですが、オンデマンドインスタンスと比較して以下のように大幅なコスト削減が可能です。

db.t3.small * 1の全前払い/3年とオンデマンドの比較
  オンデマンド リザーブドDBインスタンス 削減額/率
月額 $19.032 $9.3055
335/36で計算 		-$9.7265（額）
-51%（率）
年額（1年） $228.384 $111.6666
335/3で計算 		-$116.7174（額）
-51%（率）
年額（3年） $685.152 $335 -$350.152（額）
-51%（率）

3. ELBのコスト削減

ELBのコスト削減です。
ELBのコスト削減は、純粋に使用していたELBを削除するだけなので、作業時に行った手順だけ完結に書いていきます。

  • ELB配下のEC2が所属するサブネットをパブリックサブネットに変更

    • インターネットからのアクセスをEC2が直接受ける（ELBを介さない）形になる為の変更です。
    対象のサブネットのルートテーブルにIGWを追加します。

  • EC2にアタッチするセキュリティグループのインバウンド設定をインターネットからのアクセスを許可するように変更

    • 同じくEC2がインターネットからのアクセスを受ける形になる為の変更。
    インバウンド設定で、HTTPとHTTPSの0.0.0.0/0を追加して、ELBにアタッチしたセキュリティグループからの許可を外します。

  • Route 53の紐付けをELBからEC2に変更

    • ブログURLへのアクセス時に、ELBではなくEC2に向き先を変える為のDNS設定変更です。
    Route 53のAレコードをELBからEC2にアタッチしたEIPに変更します。

  • ELBのターゲットグループからEC2を削除

    • ELB配下からEC2を外す為の変更です。
    ELBのリソース削除を行えばELB経由でEC2にリクエストは飛ばなくなりますが、整理の意味で不要になった設定は削除しておく事を推奨します。

  • ELBのリソース削除

    • 最後にELBのリソースを削除して完了です。

以上の簡単な作業で構成変更がすぐにできる為、アクセス数増加時などスケールアウト対応が取りたくなった場合は、上記手順で行った変更を元に戻せばいつでもELBを介した高可用性な構成に戻す事が可能です。

ELBのbefore/afterに関しては利用額が0に減った変更になりますが、変更前と比較して以下のように大幅にコスト削減が実現できています。

ELBのコスト削減額
  変更前 変更後 削減額
月額 $17.7876 $0 -$17.7876
年額（1年） $213.4512 $0 -$213.4512
年額（3年） $640.3536 $0 -$640.3536

今回の対応で削減できた総コスト削減額

最後に、今回の対応結果のまとめです。

月額利用料金

46.7748(before) – 13.0277(after) = $33.7471(削減額)

1ドル107円での計算で考えた場合、約3600円の削減です。
率で見ても約72%の削減と大幅なコストカットが実現できています！

年額（1年）利用料金

561.2976(before) – 156.1332(after) = $405.1644(削減額)

日本円にすると約43000円の削減！！（率は月額と同様）
美味しいご飯を食べに行けますね。。。w

年額（3年）利用料金

1683.8928(before) – 469(after) = $1214.8928(削減額)

日本円にすると約130000円の削減！！！（率は月額と同様）
13万円で買える物。。。MacBook Airが買えますねw

という事で、小規模なブログ環境でもリザーブドインスタンスを導入するなどコスト削減をちゃんと対応対応すると、これだけお金を節約することができました！というコスト削減例が以上になります。
皆さんも是非コスト削減してみてください！

このエントリーをはてなブックマークに追加
Pocket
LINEで送る