AWS利用の最適化に従事してます、鈴木(@szk3)です。
最適化といってもいろいろありますが、ここ最近はAWSにおけるコスト削減についていろいろと行ってきました。
LIFULLのアカウント数は100を超えます。それらのアカウントに対し、約240以上のコスト削減案を立案し180件以上の施策を完了させてきました。
今回は、この新型コロナの影響で先行きが不透明な中、AWS利用費用を見直したいという方のために、 実体験に基づいたAWSコスト最適化の流れと考え方をシェアしたいと思います。
コスト削減の流れ
いろいろとやってきましたが、コストを削減する流れはどれも同じです。
- 現状を知る
- ソリューションを選ぶ
- 実行する
めちゃくちゃシンプルですね。
ひとつづつ見ていきましょう。
現状を知る
コストを削減するにあたり、最も重要なのはどこにコストが掛かっているかを知ることです。
「無い袖は振れない」ので、 CostExplorer を使い、どこにコストがかかっているのかを特定するのが最初の作業です。
CostExplorerについてはこちらの資料が参考になります。
www.slideshare.netまずは、コスト高のサービスを軸にピックアップします。
この時、画面右側フィルターの「料金タイプ」から、自分たちでどうにもできないものと、コスト削減対象になりえない項目を除外しておきましょう。 具体的な項目としては、「サポート料金」、「税金」、RIやSavingsPlansなどの「前払い料金」などです。
次に、サービスごとに絞り込んで行きます。
ひとつのサービスでフィルターし使用タイプでグループ化して、サービスのどこにコストが掛かっているのかを明らかにします。
この時のポイントは、使われ方でコストが変動するサービスは最適化に時間がかかるケースが多いので、 リソースのプロビジョニング次第でコントロールできそうな使用タイプで絞り込みあたりをつけていきます。
例えば、「EC2 その他」サービスでフィルタし、「使用タイプ」でグループ化した場合、 DataTransfer-Regional-Bytesより、EBS:VolumeUsage.gp2 や EBS:SnapshotUsage のほうが、手っ取り早くコスト削減できる可能性が高いです。
また、調査内容は、どこかにチケット化(タスク化)しておくことをおすすめします。 いますぐ対応できなくても、後日対応できる可能性もあるので、ネタとしてストックしておきます。
この作業により、コスト削減候補のリストが出来あがります。
このリストは、のちのち考慮する最適化のしやすさや削減コスト想定額などを軸にして、優先順位を決定するのに役立ちます。
ソリューションを選ぶ
さて、コスト削減候補のリストができあがりましたので、今度はどのように対応するかを検討していきます。
コスト削減の原理原則もシンプルです。
- 不要なリソースは、停止・削除する
- 必要なリソースは、適切に使う
- 適切なリソースは、コスト最適化オプションでコスト削減する
これだけです。
不要なリソースは、停止・削除する
運用あるあるですが、昔から運用しているAWSアカウントには、削除漏れ・賞味期限切れのリソースが残ってしまうパターンがあります。
例えば、数年前に取得したスナップショットやEBSなど、現在利用しても要件を満たさないリソースが存在しているケースが多々あります。 また、RDSの手動バックアップと自動バックアップが重複していたりと、役割がかぶっているものなどは運用ルールを見直すことで重複リソースを削除することが可能です。
S3などは、大量のログがあるものの、特に利用されることも無いのに、標準のストレージクラスで保存していないかなどを確認しましょう。 ライフタイムを設定することで、古いオブジェクトを削除したりGlacierなどのストレージクラスに変更することでコストを抑えることが出来ます。
これらは、組織変更や担当者が変わることで、リソース管理の責務がルーズボールになっているパターンがあるので見落としがちです。
また、開発環境も意外と見落としがちです。 試行錯誤の残骸が削除されず、不要なリソースとして残っているケースがあります。
また開発環境であればリソースを24h/365dで使わないこともあります。 EC2やRDS は Instance Scheduler を使うと簡単に起動・停止設定をすることができます。
CloudFormationを使って簡単にプロビジョニングでき、インスタンスの起動や停止をタグで管理します。 仕組みもシンプルですし、夜間・土日に停止しておくだけで、かなりのコストを削減することが可能です。
これらのリソースの調査で、削除・停止できそうなものが見つかったら、コスト削減案としてストックしていきます。
これらの”不要そう”なリソースは、「持ち主」や「背景」を紐解くのに時間がかかる反面、不要となれば削除するだけなので最も簡単にコストを削減できます。 （先走って勝手に削除するのはNGですのでご注意を。）
必要なリソースは、適切に使う
使っているリソースが、「適切に使えているか？」を確認しましょう。
具体的には、リソースごとにCloudWatch メトリクスなどで、適切に利用できているかを見ていきます。
EC2であれば、適切なサイジングは AWS Compute Optimizer を利用するのがおすすめです。 過去のメトリクスを分析し、過剰にプロビジョニングされたEC2を、変更リスクとともに新しいインスタンスタイプを提案してくれます。
こちらのYoutubeで、 Compute Optimizer のイメージを確認できます。 youtu.be
また、必要に応じて、カスタムメトリクスなどで、メモリやディスクも見ておきましょう。 確認した結果、改善の余地があればインスタンスタイプの変更やダウンサイジングを計画します。
EC2の場合、最新世代のインスタンスタイプに変更するが望ましいのですが、古いインスタンスの場合、ディストリビューションによっては Nitro世代に変更できないこともありえます。 さくっとNitro世代に変更できそうな場合は、このタイミングで変更してしまうのがいいでしょう。
また、AutoScalingグループを確認し、インスタンスを過剰にスケールさせてないかも合わせて確認しましょう。
これらの対応は、地味ですがコスト最適化オプション購入の前処理として重要な作業になります。
適切なリソースは、コスト最適化オプションでコスト削減する
リソースの最適化が一通り完了したら、いよいよコスト最適化オプションでコスト削減を行います。
ただ、コスト最適化オプションと言っても様々なものがあります。
たとえば、EC2に対しては Reserved Instance(RI) や SavingsPlans など 年間利用を約束し割引する購入オプションがあります。 24h/365dで利用が固定されているEC2は、こういったオプションで最適化し、Auto Scaling などで一時的に利用するEC2には、スポットインスタンスが最適です。
いまは、1 つの Auto Scaling グループ内で、オンデマンドインスタンスとスポットインスタンスのフリートを簡単に混ぜることが出来るので、RI/SavingsPlans + Spot Instance の構成でまんべんなくコスト削減することが可能です。 docs.aws.amazon.com
ちなみに、EC2のコスト最適化オプションといえば、以前はRIが主流でしたが最近のトレンドは SavingsPlans を利用することです。 SavingsPlansはRIと比較して、アーキテクチャ変更に対する柔軟性が高いのが特徴です。
www.slideshare.net
SavingsPlansのコミット金額は、若干取っつきづらいかもしれませんが、Cost Explorerからコミット推奨金額が参照できます。
また、RIといえば、EC2, RDS はすぐに想起できますが、ElasticSearch Service にも対応しています。他にも、ElastiCacheのリザーブドキャッシュノードや、DynamoDBのリザーブドキャパシティなど、サービスによって呼び名は違えど、年間利用を約束することでコストを削減できるオプションがありますので、忘れずに検討しましょう。
実行する
最後は、ただ実行するだけです。
ただし、自分で対応できる場合はよいのですが、自分で手を出せないアカウントに対してはアカウントの管理者にお願いして作業してもらう必要があります。
なので、お願いする側としては、費用対効果の金額試算、稟議の文章テンプレ化、進捗のヒアリング、ステークホルダーの洗い出しなど、さまざまなアプローチで作業をサポートできると良いと思います。 「こうあるべき」と正論を振りかざすのではなく、相手の立場になり同じ方向に向けて一緒に最適化していくような丁寧なコミュニケーションを心がけています。
また、残念ながら費用対効果やさまざまな制約により、現時点では最適化できないという判断になったとしても「できなかった」という判断と理由が資産になります。 全てのコスト最適化がスムーズに実行されるわけではありませんが、「あえてしなかった」という判断もひっくるめて、ひとつづつ完了させていくことに、大きな意味があると思います。
まとめ
以上、実体験に基づくコスト最適化の流れと考え方を紹介しました。
ただ、コスト最適化はこれが全てではありません。上記以外にも、コスト削減できる方法はいろいろ存在します。
例えば、レスポンスタイムなどを許容できるような場合であれば、利用料金が安いUS Eastリージョン利用の検討したり、 アーキテクチャの変更なども、コスト削減の可能性を大いに秘めています。
ただ、変更の振り幅とそれにかかる人的コストは比例しやすいのも事実ですので、バランスを見て判断するのが良いでしょう。
AWS Well-Architected フレームワークの 5 本の柱のひとつに「コスト最適化」があります。 こちらを参考に、自分たちにとってコスト効率のよい形を目指して行きたいですね。 wa.aws.amazon.com
今回はあえて流れや考え方にフォーカスしました。 サービスごとの具体的な手法についてはまた別の機会にシェアできればと思います。
繰り返しになりますが、コスト削減の原理原則はシンプルです。
- 不要なリソースは、停止・削除する
- 必要なリソースは、適切に使う
- 適切なリソースは、コスト最適化オプションでコスト削減する
いまできることから着手し、費用対効果の高い順に対応していく。
当たり前だけど、これが一番確実で素早くコスト削減に寄与すると信じています。
ご自身の環境に照らし合わせ、お役に立てば幸いです。
