AWSの超コスパ術 – EC2編②低コスト裏技集

とらくらのインフラエンジニア、ばっしーです。

前回は、EC2のインスタンスタイプの選び方を解説しました。もちろんそれだけで完璧なわけではないのですが、基礎的な選択の方法はお判りいただけたかと思います。

今回は、利用するインスタンスタイプが決まった後、利用後でも構いません、どのように利用料金を下げることが出来るかを考えていきます。インスタンスタイプを決める前の方が自由度が高いのでお勧めです。

いくつかのコスト削減案を示しますが、実際は様々な条件があって適用できない場合も多いと思いますので、そういう場合にも、もちろんセービングプランやリザーブド・インスタンスは利用できますので、そちらもご検討ください。

この記事では、どちらかというと正攻法ではない、飛び道具をご紹介します。

コスト削減の考え方

EC2以外のサービスで実現できないか

この記事は、EC2を利用することを前提に記載はしていますが、EC2というサービス自体がそもそも仮想サーバーのレンタルなので、サーバーを24時間365日利用すると、当然そのコストは大きくかかかってきます。そのため、第一のコスト削減につながる検討課題としては、そもそも「本当にEC2でなければならないか」をもう一度考えるというものです。

もし自社で作成しているWebサービスなどであれば、その選択肢は大いにアリでしょう。むしろ検討しないことが、プロセスとしておかしいとも言えます。

しかし、EC2の使用目的が、例えば市販のWindows向けソフトウェアを利用すると決まっていた場合には、絶対にEC2でしか動かすことが出来ません。もちろんWorkspacesでも利用できるかもしれませんが、コスト的にメリットが出るかは不明ですし、コストアップになることもあります。

また、オンプレミスのサーバーやPCを利用するという手段もあるでしょう。24H365D動かす必要があるけれど、耐障害性の要求が低いものは、クラウドではなくオンプレミスの方がコストメリットが大きいかもしれません。

EC2の課金体系をもう一度おさらい

EC2の課金の大前提は「時間単価」×「稼働時間」で決まります。

そのため、安価に利用するには「時間単価」もしくは「稼働時間」のどちらか、もしくは両方を下げるしか方法はありません。では、それぞれの方法を考えていきましょう。

EC2の時間単価を下げる方法

「セービングプラン」や「リザーブド・インスタンス」とか、「そんな方法あったら苦労しないよ」と思いますよね。その通りです。そのため、それ以外の方法を考えてみます。

単価自体は変わりませんので、インスタンスタイプを変更します。「サイジングした結果なので、変更してはダメなのでは？」はい、そうかもしれません。でも、ちゃんと問題なく動くかもしれません。クラウドへの移行では、サイジングはもちろん事前に行いますが、それよりも小さなインスタンスで動かすことを前提に考えるのも一つの方法です。

一般的に、アプリケーションで指定されている「動作環境」や「推奨環境」は、利用者側が極端な低スペック環境で動かしてアプリベンダーへ問い合わせがいかないように、安全を見て記載されていることが多いです。

オンプレミスの時代には、ハードウェアを購入してしまって「想定していたよりも少し動きが遅かった」なんてことになったら大変です。もしも予算があればまだ良い方で、見積もりを取って、購入申請をして、承認されたら発注して、納期を待って、システムを休日に停止させて、スペックを増強して…など、途方もない手間がかかります。そのため、（絶対はありませんが）絶対にそうならないために、あらかじめ多めの予算を申請して、過大な投資を行うのが常です。

しかし、クラウドでは、当然ながら予算はある程度大きなものを想定しておきますが、その予算内で可能な限り低いスペックで動かして節約する、というのがクラウドを最大に有効活用する予算措置の考え方です。

[経験則]サイジングの違和感

ちょっと話がそれますが…
一般的にクラウドへ移行する前は、オンプレミスの物理もしくは仮想サーバー、またはレンタルサーバーで動作している場合が多いと思います。そういった移行前のサーバースペックは、移行後のインスタンスサイズのサイジングに非常に有用となります。しかし、AWSへの移行を実施してみると、大抵は、サイジングで仮定したスペックよりもさらに高速にシステムが動作する場合が多かったです。

より小さなインスタンスタイプを選択してみる

あらかじめサイジングしておいたインスタンスタイプで正常動作することが確認出来たら、ワンサイズ小さなインスタンスタイプで動作させてみます。それでも全く問題なく動作する場合には、さらにもうワンランク小さなインスタンスタイプで動作させてみることも視野に入れてみてください。

経験上、Windowsサーバーはメモリー容量が4GBを下回ってしまうと、「まともに起動しない」、「動作が極端に遅い」などの事象が発生する場合もあるため、下限は「t3.medium」までと考えた方がいいでしょう。ですが、過去にお客様自身で「t3.small」に変更しても全く問題がなかったので、t3.smallで運用を続けているという例もありました。

インスタンスのシリーズを変更する

メモリー容量とCPUコア数の関係をうまく利用して、パフォーマンスを大きく下げずに「時間単価」を下げる方法もあります。

例えば、データベース（DB）が動作する場合など、メモリー容量に余裕があるとパフォーマンスが上がる場合があります。そのような場合には、メモリー容量をキープしたまま、CPUコア数を削減することで、コスト削減することが可能です。

この例を具体的に考えてみると、以下のようになります。

インスタンス名	時間単価	vCPU	メモリ
m5.xlarge	0.248 USD	4	16 GiB
r5.large	0.152 USD	2	16 GiB

どうでしょう。約40%のコストダウンになりました。

このように、インスタンスタイプの差を熟知することで、パフォーマンスを下げずにコストを下げることが出来ます。

シリーズ変更のコツ

上の例では、データベースの動作について記載しましたが、利用するアプリケーションやその使い方によって適切なスペックは異なってきます。そのため、インスタンスタイプを小さくしたときに運用してみて、遅いと感じた時にどこがボトルネックになっているかを把握することが、コスト削減にはとても大切です。

大抵は、以下のどれかに当てはまると思われます。

• メモリー容量
• CPU使用率
• ディスクI/O
• ネットワークI/O

メモリー容量だったら「メモリー最適化インスタンス」のRシリーズ、CPU使用率だったら「コンピューティング最適化インスタンス」のCシリーズを使用します。

ディスクI/Oが頭打ちだったら「EBSプロビジョンド IOPS SSD」を使用します。なお、その場合には以下のページを参考にインスタンスタイプも選定する必要があります。「最大帯域幅 (Mbps) 」「最大スループット (MB/秒､128 KiB I/O) 」「最大 IOPS」といった詳細情報がインスタンスタイプ別に記載されていますので、ディスクパフォーマンを優先する場合には、その数字が大きいもので、安価なインスタンスタイプを選択するといいでしょう。

Amazon EBS 最適化インスタンスを使用する

他にも、ソフトウェアのライセンスが仮想コア数に対して必要になるソフトウェアを利用しているお客様が、処理速度は極力下げずにコア数を下げるため、z1dシリーズという、CPUのクロック周波数が最大4.0GHzにも達するインスタンスタイプを選択したこともありました。

インスタンスタイプの詳細を知る

このように、様々な特色のあるインスタンスタイプを選択するためには、各インスタンスタイプについて知る必要があります。そのためには、以下のような資料が役に立つでしょう。

Amazon EC2　インスタンスタイプの選び方ガイド（AWS Summit Tokyo 2019の資料）
この資料は2019年のものですが、とても分かりやすく、シリーズや世代、各特殊インスタンスについて解説されています。

Amazon EC2 インスタンスタイプ
こちらはAWS公式ページです。最新の情報を確認することもクラウドを扱う仕事としては、とても大切なファクターです。

EC2の稼働時間を下げる方法

さて、次は「時間単価」×「稼働時間」の「稼働時間」を考えていきましょう。

これは単純明快で「インスタンスを利用する時間をどこまで削減できるか」になります。

24H×365D動かすと8,760時間の稼働になりますが、たとえば、業務時間にしか使わないソフトウェアであれば、朝9時に起動して夕方18時に停止、月～金の9時間だけ動かすことであれば、2,340時間の稼働だけなので、コスト的には約1/4になります。

そして、電源のOff/Onを手作業で実施するのは面倒なので、自動化してしまえばいいでしょう。

Cloud Watch Eventによる「曜日・時間起動」で、平日朝にAPIを自動コールすることが可能です。電源のOFFもAPIでもいいですが、OSの動作的にはOSの機能で自動電源OFFを実施したほうが良いかもしれません。Windows OSの場合には、タスクスケジューラーで設定可能ですね。

他にも…

サーバーを統合してインスタンスの台数を減らす方法や、WindowsからLinuxに変えたり、MS SQLやORACLEからOSSのMySQLやPostgreSQLなどに変更して、高額なライセンス代を低減させる方法などもあります。もちろんDBを変更する場合は、動作するソフトウェアが自社での開発というのが条件となるかと思います。

他にも様々な工夫でコストを抑える方法がありますので、皆さんも視野を広く持って、色々な角度から考えてみてください。

外部の専門家による簡易コンサルティングをご希望の場合には、初回検討は無償で対応いたしますので、是非お声がけください。

お問合せは下記まで。

テクニカルエージェント　-　お問合せ