AWS Well-Architected フレームワークを活用したコスト最適化への取り組み

DSOC Infrastructure Group の大澤です。
新型コロナウイルスの影響でマスクが品薄になっていますね。花粉症なので最近は常にマスクしているのでマスクがないと辛いです。幸いにも災害対策で備蓄していたマスクがあったのでそれでなんとかしのいでいます。

最近「Cloud Cost Optimization Engineer」というロールになりました*1。Cloud Cost Optimization Engineer を日本語にすると「クラウドコスト最適化エンジニア」でそのままなのですが AWS や GCP といったクラウドコストを最適化するための取り組みや仕掛けをしていくのが主な役割となります。このロールを名乗り出る前からクラウドコストの最適化を進めてきましたが、改めてロールを立ち上げることで私が取り組んでいることを明確化することが目的です。SRE のようなメジャーな肩書が見つからず、国外でジョブオファーをいくつか見つけたのでそのまま名乗らせていただくことにしました。

AWS のコストを最適化するにあたって、闇雲に手をつけるのではなく、まずは AWS のベストプラクティスに則るのが最善だと思っています。AWS が公開している AWS Well-Architected（W-A）フレームワークの柱の1つである「コスト最適化」でコスト最適化に関するベストプラクティスが述べられています。本記事ではこれまで取り組んできたことと W-A フレームワーク「コスト最適化」のベストプラクティスを照らし合わせて紹介します。

AWS Well-Architected フレームワークとは

AWS Well-Architected（W-A）フレームワークを一言でいえば、AWS でシステム構築する際のベストプラクティスを集結したガイドラインといったところでしょうか。AWS ソリューションアーキテクトが長年にわたってさまざまなビジネス分野やユースケースを設計してきたその経験則に基づいて作られたものです。あくまで「設計の原則」であって具体的な設計や実装について触れられていません。AWS サービスを活用したり組織を改善していくことでベストプラクティスに近づけていきます。

ホワイトペーパーが公開されていて、W-Aフレームワークの設計原則やベストプラクティスを学ぶことができます。また、ホワイトペーパーに記載されている質問に回答していくことで自社のシステムがベストプラクティスにしたがっているかを照らし合わせることができます。すべての項目でベストプラクティスにしたがう必要はなく、照らし合わせることによって自社のシステムのリスクや改善点を知ることができる方が重要です。

W-Aフレームワークでは5つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化）が定義されています。本記事では5つ目の「コスト最適化」について取り上げます。

「コスト最適化」の質問と取り組み

「コスト最適化」における質問を一部引用し、私たちの取り組みについて紹介します。

[COST 2] 使用状況とコストをどのようにモニタリングしますか?

AWS Cost Explorer や AWS Cost and Usage Report を活用し AWS 請求データを収集・可視化しています。また、コスト配分タグでプロダクトやチーム別のコストを分けています。BI ツールである Redash を利用した可視化については前回の記事をご参照ください。

buildersbox.corp-sansan.com

日々のレポートや請求アラートに AWS Budgets を活用しています。レポーティングは日次で Slack に通知するようにしています。各 AWS アカウントの利用金額と予測値を照らし合わせて予算額を超えないかをチェックしています。

f:id:ohsawa0515:20200227202525p:plain

[COST 3] 不要なリソースをどのように削除しますか?

AWS Trusted Advisor で使用量の少ない EC2、ELB、RDS などのリソースを定期的にチェックしています。また、EC2 を定期的に棚卸して不要な EC2 インスタンスを削除しています。
用途が不明になっているリソースについては AWS CloudTrail や AWS Configで証跡を辿り担当者（リソースの作成者）の特定・利用有無の確認をしています。

[COST 4] サービスを選択するとき、どのようにコストを評価しますか?

DSOC では新しいプロダクトや機能をリリースするとき、マネージドサービスを利用できないかを最初に検討します。マネージドサービスを活用することでサーバの運用保守にかかる時間的・金銭的コストを削減でき、ビジネス効果を高めるための開発に集中できるからです。AWS は多くのマネージドサービスが出ており、マネージドサービスの種類は年々増え続けています。

AWS サービスを選定するにあたって、総保有コスト（TCO）を意識します。TCO はある設備などの資産に関する、購入から廃棄までに必要な時間と支出の総計*2のことです。サービス選定するときや設備するときは初期コスト（設備を購入するなど）に着目しがちですが、保守運用や、設備・システムのメンテナンス、人件費などのランニングコストも意識しなければなりません。TCO はそれらをトータルに含めた費用です。EC2 よりもマネージドサービスの方が時間あたりの料金が高いかもしれませんが、ランニングコストを下げる可能性があるため、TCO の観点で見ればコストをおさえることができます。

また、ワークロードの特性にあった AWS サービスを選択することを意識しています。銀の弾丸となる AWS サービスはありません。たとえば、コストと運用負荷を下げたいという目的でサーバレスの AWS Lambda を採用することは良いのですが、明らかに AWS Lambda には向かない、もしくは AWS Lambda にすることで AWS コストが激増してしまうケースもありえます。
私は AWS サービスを選定をするときに必ずコストの見積りをするようにしています。見積り結果と得られる成果と比較して費用対効果として十分かどうかを判断する材料を用意します。たとえば、名刺データ入力システム（GEES）では名刺1枚をデータ化するコストを KPI にしています。データ入力を自動化する機能をリリースするときに、機能にかかるコスト（AWS サービスの金銭的コストと運用コスト）とデータ化のコスト（機能リリースでどのぐらいコストが下がるのか）を比較し判断します。

[COST 5] リソースタイプとサイズを選択する際、どうすればコスト目標を達成できるでしょうか?

[COST 6] コストを削減するには、料金モデルをどのように使用したらよいでしょうか?

事前にリソース見積りをするものの、実際のワークロードでは必要なリソース量が異なる場合があります。監視 SaaS サービス Datadog で EC2 や RDS のリソース負荷や ELB などのメトリクスを収集、モニタニングしています。また、AWS Compute Optimizer で「プロビジョニング不足」「過剰プロビジョニング」の EC2 インスタンスをチェックし最適なインスタンスサイズを決定しています。

EC2 のコスト最適化のために、オンデマンド/リザーブドインスタンス（RI）/Savings Plans/スポットインスタンスを使い分けています。以前は RI をすべての EC2 インスタンスに適用していましたが、最近はスポットインスタンスの利用を拡大し RI の割合を下げています。Windows Server のように従来の RI では柔軟性が効かないインスタンスの場合は Savings Plans を利用しています。

[COST 7] データ転送料金についてどのように計画していますか?

DSOC は AWS と GCP のマルチクラウドを採用しており、クラウド間のネットワーク転送料金について注意を払っています。AWS NAT Gateway はフルマネージドでとても便利ですが、データ転送コストが高いため、GCP とのデータ転送には VPN を採用しています。また、S3、DynamoDB などのサービスでは VPC Endpoint によって NAT Gateway を経由しないことでデータ転送コストをおさえています。
現在の課題は AWS NAT Gateway のコストが未だに高いことです。今後は VPC フローログを分析して AWS NAT Gateway の高コストの要因を調べていきます。