アーキテクチャレビューからコスト削減を考える①

投稿日: 2024/02/07

はじめに

こんにちは、園田です。

AWSを利用しているお客様から思った以上にコストがかかっているので、コスト削減のために、リザーブドインスタンス（以下、RI）を提案して欲しいという話を良く貰います。
とはいえ、RIを利用した場合の割引率は最大75%となっていますが、実際には40%程度の割引が一般的と思われます。これはそもそもRIを購入するお客様が大体「1年、全額前払い」で購入されるためです。
またOSがWindowsなどのライセンス費用が発生するものについては更に割引率が低くなってしまいます。

なので、あまりRIを購入したからコストがすごく下がるかというとそういったものではありません。それよりきちんとアーキテクチャの見直しを行い、無駄なインスタンスを省く、過剰なスペックなものを適正なものにする。などの対応を実施したほうが有用と考えます。
コスト削減時にアーキテクチャの見直しを実施する記事があまり無いなー、と思ったので本ブログに記載したいと思います。

なお、RIの仕組み自体は本ページの最後に記載したいと思います。

コスト削減をしたい時に実施すべきこと

コスト削減を実施したい時、基本は以下のような順序で実施するのが一般的です。

１．不要なサーバや過剰なスペックなどのサーバについての整理を実施する
２．テスト環境などについて常時起動が不要なものについては、停止を実施する
３．アーキテクチャレビューを実施し、使い方の見直しを実施する
４．常時利用するサーバについてはRI、もしくはSavings Plans（以下、SP）の購入を実施する

「１」、「２」、「４」はシンプルですが、「３」については色々細かく見ていく必要があります。まずはできる所からということで「１」、「２」を実施しましょう。
対応は簡単です。

不要なサーバや過剰なスペックなどのサーバについての整理について

過剰スペックのサーバについては、「Trusted Advisor」にて確認が可能です。
Trusted Advisorの「コスト最適化」→「使用率の低い Amazon EC2 インスタンス」から「↓」ボタンをクリックすると一覧のダウンロードが実施可能です。

Trusted Advisorの「使用率の低い Amazon EC2 インスタンス」については、「直近 14 日間」のチェックにて、「1 日あたりの CPU 使用率が 10% 以下、およびネットワーク I/O が 5 MB 以下」が「4 日以上あった場合」に出力されます。
実際のデータの中には「14 日間の平均 CPU 使用率」、および「14 日間の平均 Network I/O」の値がありますので、参考にしてください。

このリストに上がった仮想サーバについてはスペックの再検討を実施したほうが良いでしょう。もちろんアプリケーションやミドルウェアの制限でスペックを変更できない場合もあると思いますが、サーバ自体は過剰スペックであることを認識したほうが良いかと思います。

EC2に限らずAWSでは基本インスタンスタイプを上のものに変更すると、「スペックが倍=費用も倍」となります。逆に言うと、スペックを下げると費用は半額になります。そのため、サーバのスペックが余った状態というのはコスト上すごく勿体ないというのをきちんと意識しましょう。

なお、RDSについては、「Amazon RDSアイドル状態のDBインスタンス」からダウンロードが可能です。こちらは、「DBインスタンスへの接続が過去7日間なかった」ものが表示されます。「1週間接続が無い≒使ってない」なのでそのような対象はスナップショットを取って削除してしまって問題ないと思います。おそらく、テスト環境で普段使わないインスタンスなどだと推測されます。

なお、EBSもゴミが出来てそのままのパターンも多いので、不要な物は削除しておきましょう。EC2の画面からの「Elastic Block Store」→「ボリューム」をクリック後、画面上のボリュームの「▲」マークをクリックしましょう。画像のように「使用可能」となっているものはどこのEC2にも割り当てされていない基本ゴミとなりますので削除しましょう。

また、結構前から使っている環境ではボリュームがgp2になっているものも多いと思います。
gp2の費用が0.12ドル/1G、gp3が0.096ドル/1Gとなるため（2024年1月時点の東京リージョンの値段）、gp3にすると純粋にコストが20%削減されます。また、ストレージの容量にもよりますが、小さいボリュームの場合、IOPSもgp3の方が優秀ですので、基本gp3に変更して問題ありません。
変更も無停止で実施が可能ですので、変更することを推奨します。

※gp2、gp3の比較はこちら
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-plan-storage-compare-volume-types.html

テスト環境などについて常時起動が不要なものについては、停止を実施する

AWSは起動時間に応じて費用が発生します。仮にテスト環境で平日9:00-17:00のみ動いていれば問題ない、という場合は1日8時間×20日の160時間の稼働時間という事になり、常時起動の場合と比較して約1/4（常時起動は24時間×30の720時間）のコストとなります。

ただ、手動で停止・起動するのは手間がかかります。こちらはAWSのサービスを利用して自動化してしまいましょう。（以前は自動化のため、lambda等を作成が必要でしたが2024年2月現在は、すべてAWSの標準サービスにて実現可能です）

EventBridgeスケジューラによる停止・起動について

以下の順番で、実施します。

１．IAMロールの作成（EventBridgeスケジューラが利用するIAMロールの作成）
２．EventBridgeスケジューラ作成
- Cronベースによる日時指定
- インスタンスIDによる対象指定

という形になります。まずはIAMロールを作成しましょう

１．IAMロールの作成（EventBridgeスケジューラが利用するIAMロールの作成）

IAMのページから「ロールを作成」をクリック
「カスタム信頼ポリシー」を選択し、カスタム選択ポリシー欄に以下を記載

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "scheduler.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
  }

「許可ポリシー」にて、カスタム選択ポリシー欄に以下を記載
「AmazonEC2FullAccess」（実際にはFullAccessでなくてOKだが一旦FullAccessを選択（本来はEC2のStop、StartのみでOK））
ロール名（「EC2-StopStart-roll」とします。）を記載し、「ロールを作成」をクリック

２．EventBridgeスケジューラ作成

AWSマネジメントコンソールで「eventBridgescheduler」を入力
eventBridgeschedulerをクリック

「スケジュールを作成」をクリック

スケジュール名に任意の名称（今回は、「EC2Stop-1800」とします）を入力し、「スケジュールのパターン」のスケジュールの種類を「Cronベースのスケジュール」を選択。EC2を18時に停止をさせるため、「分：0」、「時間：18」、「曜日：?」、それ以外は「*」を入力します。これでこのスケジュールは毎日18:00に実行される形になります。

また、フレックスタイムウィンドウを15分にして「次へ」をクリックします。
（平日のみというのであれば、「0」、「18」、「?」、「*」、「MON-FRI」、「*」という形になります。詳細は以下を参照。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/services-cloudwatchevents-expressions.html

ターゲットAIPにて「すべてのAPI」をクリック。検索画面で「ec2」を入力すると「Amazon EC2」が出力されるので、クリック

検索画面で「stop」を検索すると「StopInstances」が出力されるので、クリック
（「start」を検索すると「StartInstances」が出力されます。他にも便利なAPIがあるので探してみてください。）

入力に以下のように記載し、「次へ」をクリック
複数台、サーバがある場合、以下のようにインスタンスIDを記載します。

  {
    "InstanceIds": [
        [" i-07cfd1fa377c9aa62 "," i-027d877c1d69738be"]
    ]
  }

次のページで基本デフォルトのまま「アクセス許可」にて「既存のロールを使用」をクリック
作成していた「EC2-StopStart-roll」を選択し、「次へ」をクリック

内容を確認し、「スケジュールを作成」をクリック
以下のように作成できれば完了です。

ちなみにこのやり方ですが、いちいち対象となるインスタンスIDを記載する必要があり正直運用には適していないです。ただ、その場合、タグで対象を選択するようLambdaを作成したりなどある程度カスタマイズが入ってしまいます。
今回はあくまで簡単に実施することを最優先にしていますのでご了承ください。

という訳でようやく本来お話ししたかった「アーキテクチャレビューを実施し、使い方の見直しを実施する」という所まできました。早速やっていきましょう。

アーキテクチャレビューを実施する

早速アーキテクチャレビューを実施していきたいと思いますが、そもそも「レビューってどうするの？」という話があるかと思います。
そもそもアーキテクチャレビューについては「やりたいこと」があって、それを実現させるために「どのようなサービスを使えばよいか（効率的か）」というものかと思います。なので本来、「なにをしたいか」、「どんなふうに使っているか」が分からないと本来レビューは出来ません。

ただ、AWSの場合、課金の情報を見ればどのような使い方をしているかがある程度見えるので、「最適かどうか」は分からなくても、「良くない使い方はしているな」というのはある程度分かってしまいます。

という訳で、さっそく課金情報を見に行きましょう。AWSでは「Billing and Cost Management」のサービスで課金情報が見られます。AWSのリセラーからAWSを購入している場合、同様のサービスがリセラーから提供されているはずなので、確認してみましょう。
なお、CTCの場合はHyperBillingというツールにてAWS標準ツールより詳細な分析が可能です。

「Billing and Cost Management」のサービスから「請求書」をクリック
「Amazon Web Services Japan G.K. サービス別料金」にサービス毎の費用が閲覧可能です。

また、サービスの「＋」ボタンをクリックすることで詳細の閲覧が可能です。
（ちなみに本画像については、私の個人アカウントの画像となるため、あまり金額は高くありません。）

請求書の画面からはインスタンス単位での詳細は見ることはできませんが、逆にある程度まとまっているので分析はしやすいです。

例えば本画像であれば、EC2のストレージにgp3、io2を使っていることが分かります。
これまでAWSのストレージは基本gp2でしたが、現状より安くて性能の良いgp3がリリースされていますので、gp2→gp3にするだけでコストが20%削減できます。

長くなってしまったので、次回に実際の細かいアーキテクチャの指摘については次回に実施したいと思います。

では「アーキテクチャレビューからコスト削減を考える②」にてお会いしましょう

ミニコラム

リザーブドインスタンス（RI）の仕組みのお話し

リザーブドインスタンス（RI）の仕組みについては結構ややこしいので、きちんと理解しているユーザは少ないのではないでしょうか。
ちょっとここでRIについて整理しておきましょう。

RIの基本（動作）

１．RIは利用チケットの購入となり、どれかのサーバに紐付けるものではない
２．AZ指定を実施したものは起動保証型となり、AZを指定しないRIと異なる

RIの基本（費用）

特定のサーバ（EC2、RDSなど）について、1年、または3年分の利用をコミットすることで、通常利用の3割～6割引き程度の価格で利用が可能となります。
なお、1年より3年のほうが、値引き率が大きいです。ただし利用がなくなった場合も支払いが発生するため、リスクを避けるため1年の利用を推奨します。（3年使う計画が明確にあるのであれば、購入して問題ない）

削減効果が大きいもの
期間：3年 > 1年
支払い形態：全額前払い > 一部前払い > 前払いなし
OS：フリーOS ＞ Window > RHEL

「１．RIは利用チケットの購入となり、どれかのサーバに紐付けるものではない」については、RIは出来る限りチケット（権利）使い切ろうと努力するアーキテクチャになっています。そのため、特定のサーバに対してRIを購入するという事はできません。また、基本はアカウント内での利用となります。（Organization単位の適用も可能ですが、ややこしいので一旦アカウント単位とします）

例えば「m5.large」のEC2のRIを購入した場合、アカウント内のどこかの「m5.large」サーバにRIが適用されます。そのため、同アカウントに無いに複数システムが存在し、システム担当者が費用支払いをするというルールになっていた場合、費用面での問題が発生します。

「２．AZ指定を実施したものは起動保証型となり、AZを指定しないRIと異なる」についてはRIは以下の2通りの購入方法が存在します。

AZ指定なし購入
フリーOSの場合、インスタンスファミリー、およびOSが一緒であれば、極力チケットを使い切るよう努力するアーキテクチャとなっています。
そのため、インスタンスタイプを変更してもRIが無駄にならないという柔軟性がありますが、半面、購入したRIに対し「起動保証」は実施されません。

AZ指定ありの購入
購入したインスタンスタイプに対し「起動保証」が実施されます。
ただし、AZの変更や、インスタンスタイプの変更はできません。
（変更自体は可能であるが、その場合RIの対象から外れてしまうため、オンデマンド費用が発生してしまう）

こちらは起動保証をとるか、柔軟性を取るかの選択があるため、慎重に検討する必要あります。（なお、どちらのパターンも金額には変更ありません。）

以上、簡単なRIの説明となります。
読んでもらって分かると思いますが、なかなかRIはややこしいです。値引き率は悪くないのですが個人的にはSavings Plansの「Compute Savings Plans」の方がシンプルで使いやすいとは思います。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。

お問い合わせ

【著者プロフィール】

園田　一史（そのだ　かずし）

伊藤忠テクノソリューションズ株式会社　クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS（キュービックオンエーダブリューエス）」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年～2023年APN Ambassadorに選任。