1.はじめに
2.対策
- 2.1 継続的なコスト最適化施策
  - Ⅰ. AWS Trusted Advisorの活用
  - Ⅱ. AWS Cost Explorerの活用
- 2.2 実際に実施した事例の紹介
3.コスト最適化を行う上で注意点
4.まとめ
参考

1.はじめに

NTTドコモ情報システム部の内田と申します。私の担当システムはエンドユーザ向けのサイトをAWS上で5年以上提供しておりますが、運用していく過程で継続的なコスト削減を行う機会があり、学びを得ることができました。

本稿では、クラウドやAWSへのシステム移行をこれから考えている、すでに活用している、かつクラウドの利用料を気にしているといった悩みを持ったエンジニア向けに具体的なコスト対策事例と学びについて共有します。

2.対策

2.1 継続的なコスト最適化施策

担当システムでは以下2点を定期的に行い、サービス運用フェーズでも継続的なコスト最適化を図っています。

Ⅰ. AWS Trusted Advisorの活用

Enterpriseサポートを契約することで、AWSのベストプラクティスに沿ったコスト最適化の提案がダッシュボードで通知されます。具体的には以下のような項目を指摘してくれます。

＜指摘項目の抜粋＞

Amazon RDSのアイドルDBインスタンス
Amazon RDSリザーブドインスタンスの購入推奨
AWS Well-Architected Frameworkのリスク事項
非アクティブなVPCインターフェイスエンドポイント
低使用率のAmazon EC2インスタンス
関連のないElastic IPアドレス
使用率の低いAmazon EBSボリューム

Trusted Advisorはコスト最適化以外にもセキュリティや可用性などの面でも有用であり、AWS上でのリソースのライフサイクル管理に役立ちます。

Ⅱ. AWS Cost Explorerの活用

AWS Cost Explorerでは、AWSのコストの使用量を可視化して確認・分析できるサービスで、担当システムでは月ごとにVPCやRDSなどといったサービス毎の料金をダッシュボードで確認し、料金増加の原因を特定して対処しています。AWS Trusted Advisorのチェックで十分ではないかと思われますが、AWS Trusted AdvisorはあくまでAWSが提供している標準的な基準に対しての評価のため、別途システムの規模やトラフィックの特性に応じた分析が必要です。

近年では、Amazon Q Developerの精度と利用範囲が広がっており、コスト分析にも活用しております。具体的にはプロンプトにて「過去 3ヶ月間のサービス別のコスト内訳は?」といった質問を投げることでコストの集計結果を表やグラフ形式で確認することや「”AWS の請求額を下げるにはどうすればよいですか」という質問を投げることで改善箇所とコスト最適化にあたって推奨事項を受け取ることができます。

2.2 実際に実施した事例の紹介

ここでは、前述した運用フェーズにて実施した施策のうち具体例を２つ紹介いたします。

Ⅰ. AWS Trusted Advisorの活用し対処した事例

最新のインスタンスクラスの活用
EC2をはじめとしたリソースは、インタンスクラス「CPUやメモリ、ネットワーク設定」を最適化することが重要となります。インスタンスクラスは内部で使用しているCPUプロセッサの種類によっても分かれており、最新のプロセッサを採用したインスタンスクラスは通常、性能面で優れておりトータルでの費用も安価になる傾向があります。
AWS Trusted AdvisorではDBインスタンスをはじめとして最適化の余地があるリソースに対して、通知&提案をしてくれます。　特にAWS RDSやAWS Auroraは、他サービスに比べ元の時間単価が高く効果が大きいため、担当システムではAWS Trusted Advisorの提案も活用し、定期的に最新のインスタンスクラスに変更を行っております。

Ⅱ. AWS Cost Exploreの活用し対処した事例

需要増に伴うアーキテクチャーの見直し

システムの需要に合わせてアーキテクチャーを見直すことはコスト最適化の観点としても重要となります。実例として、Lambdaの利用量が想定超過したことを早期検知したケースがありました。そのケースでは、アプリケーションの初期開発時に業務特性、コスト含む非機能要件踏まえ、Lambda採用していたものの、リリース後に需要予測の前提が乖離し、想定よりコスト高になっていることを検知しました。早期に検知できたことで、アーキテクチャーをECSコンテナに見直しを行い、コストはもちろんのこと、結果的にサービス観点としてもアプリケーションの応答速度の低下に対して早期対応することができました。

3.コスト最適化を行う上で注意点

自身の経験上、コスト最適化には運用フェーズでの継続的な改善が不可欠ですが、継続的な改善を行うためには初期設計時での準備も重要になります。担当システムにて現在の運用に至るまでの反省点とそれらを踏まえて初期設計の事前準備での注意事項を以下に記載致します。

＜反省点＞

初期設計でのコスト最適化に注力しすぎて、運用フェーズでの考慮がおろそかになっていた
- 需要予測に基づく初期設計でのコストシミュレーションと、サービスイン後では乖離が発生するケースはよくあります。運用フェーズでの改善よりも初期設計での対策に注力しがちですが、現実的には前述した事例のように初期設計だけでコスト最適化を充足することは難しいです。運用フェーズでの継続的な改善をどのように行っていくのかをあらかじめ定義にしておくことが重要であり、サービスイン後に想定との乖離があった場合の不要コスト損失を最小に留めることができます。
長期運用にあたっての外部要因によるコスト最適化対応への考慮がおろそかになっていた
- 様々な外部要因がございますが、1番はAWSが提供するサービスのアップデートや新機能の導入、仕様変更、サービス終了に伴う対応となります。上記はコスト最適化だけの話ではないですが、AWSのマネージドサービスを利用している以上は影響を受けることを避けられません。数年前にはコスト観点でベストプラクティスだったものが、仕様変更や新サービス登場によって変わってしまい、システム構成を大きく見直ししたという事例を経験したこともあります。継続的なチューニングを行えるよう初期構築時は準備しておくことが継続的にコスト最適化を行うためには重要となります。

＜継続的なコスト最適化にあたっての初期設計での注意事項＞

運用フェーズでのコスト最適化のワークアラウンドを明確にする
誰がどのような周期で利用料をチェックするかを明確にする
Trusted Advisorは原則有効化する
- Trusted Advisorはコスト最適化以外にもセキュリティや可用性の観点でのAWSのベストプラクティスに　沿わないリソースの特定やチェック項目の最新化もAWSが自動で実施してくれるので運用負担の軽減になる。コストとも相談だが、検証用の環境でも有効化しておくと、初期構築時でのコスト含めた非機能観点での考慮漏れや検証用の不要なリソースの削除漏れなどに非常に役に立つ。
Cost Exploreを有効活用する
- Cost Exploreではサービス別、アカウント別、リージョン別等のフィルタで毎時 / 日次 / 月次単位の料金推移をグラフで参照可能だが、あらかじめリソースにTagを付与しておけばTagごとの分計が可能である。複数サイトやサービスを提供している場合などはあらかじめTagの設計を行っておくことを推奨する。また、あらかじめコストのしきい値を設定しておけば、コストが超過した際にメール通知なども行ってくれるため、こちらも有効化することを推奨する。
継続的なチューニングに強くなるようなシステム設計を行う
動的にチューニングしてくれるフルマネージドサービスを積極活用するフルマネージドのサービスはスペックの自動拡張が提供されているものが多く、AWS内で冗長構成がとられておりスペック変更時のエンドユーザへの影響を最小で済むものが多い。
拡張方法としてなるべくスケールアップ・ダウンよりもスケールアウト・インを採用し、チューニングの負担を減らすためAuto Scalingやサーバレスをはじめとした自動拡張が有効なサービスを積極的に活用する
- AWSサービスの特性上、スケールアップ・ダウンは変更に伴う影響が大きくなりやすい傾向があり、EBSなど一部のAWSサービスは不可逆の場合があり制約が多いため、スケールアウト・インでかつ自動拡張できるAWSサービスの方がチューニングしやすい。
ELBでのラウンドロビンやRoute53でのDNSラウンドロビンなどを活用し負荷分散および冗長構成が取れるようにする、またAmazon SNSやAmazon SQSなどのサービスを活用して疎結合な構成にする
- サービスレベルの高いシステムではシステム変更時にエンドユーザへの影響がボトルネックになることが多いため、あらかじめ疎結合かつ可用性の高い構成をとっていればチューニングやアーキテクチャーの見直しを行いやすい。