クラウドネイティブアーキテクチャへの道のりシリーズ #6: コスト可視性の向上とコスト最適化のための再設計

このブログシリーズは、eコマース企業を例に、クラウドネイティブなアーキテクチャへの道のりにおいて課題となる点の解決について説明しています。第1回目から5回目までのブログでは、パフォーマンスや可用性、セキュリティ体制の改善に触れており、第6回目となるこのブログでは、その後にECプラットフォームのユーザー数が10倍以上に増加し、収益に対して運用コストが釣り合わなくなった状況を考えることとします。

これに対処するため、AWS の利用料をよりよく把握し、コスト削減を見極めるための計画を立てます。具体的には、コストの可視性を向上させ、コスト最適化のための再設計を行い、コスト管理対策を適用することで、イノベーションを促進しながら投資収益率を向上させる方法を紹介します。

Cost Explorer によるコスト改善点の洗い出し

AWS Cost Explorerを使用し、以下の改善点を確認します。

コストの可視性を向上させ、FinOps のカルチャーを確立する:
- タグ付けされていないリソースの可視性・コスト分析を提供する
- 共有 AWS リソースのコストを可視化する
- 粗利益に対する理解を深める
サービスコントロールポリシー ( SCP ) を使用してコストを管理する
データ転送のコストを最適化する
ストレージコストを削減する:
- コストに適した S3 ストレージクラスを使用するようにオブジェクトを更新する
- Amazon EBS gp3 ボリュームを適用する
コンピューティングコストを最適化する:
- 未使用リソース、低利用率リソースを調整する
- 最新世代の Graviton インスタンスに移行する

それでは、これらの改善点に関して詳しく説明していきます。

コストの可視性を向上させ、FinOps のカルチャーを確立する

タグ付けされていないリソースの可視性・コスト分析を提供する

クラウドで発生する費用の透明性を高め、可視化し、エンジニアリングチームがそれを最適化し、改善を続けていくといった FinOps のカルチャーのチーム内への浸透を深めるために、タグ付けされていないリソースも可視化するといったことが考えられます。

例えば、CloudZero 社の SaaS サービスを使用すると、AWS アカウントの利用料の分類を自動化し、チームにコストに関するインサイトを確認することができます。このサービスでは、利用料を様々なカテゴリに分類するために、AWS リソースに付けたタグの情報だけでなく、各リソースのメタデータもインポートして使うことができます。

共有 AWS リソースのコストを可視化する

CloudZero では、 CostFormation と呼ばれるサービス固有の言語によって、 Dimensions と呼ばれるグループを定義することができます。これによって開発、テスト、本番といった個々の環境を定義した上で、それぞれの AWS リソースのタグ情報に基づきコストを紐付けたり、共有するリソースについては、ルールを使ってコストを分配して紐付けたりすることができます。

粗利益に対する理解を深める

顧客への価値提供と、AWS 利用料の増加にどのような相関があるのかを理解するために、「Unit Metric – The Touchstone of your IT Planning and Evaluation」のブログのガイダンスが参考になります。例えば「EC での 1 注文あたりの AWS 利用料」といった値を評価していくことで、コスト KPI に関する貴重なインサイトが得られ、ビジネスの粗利益をよりよく理解することができます。

サービスコントロールポリシー ( SCP ) を使用してコストを管理する

「Control developer account costs with AWS CloudFormation and AWS Budgets」のブログのガイダンスに従って、 SCP を使用してコストを管理し、各OU のメンバーアカウントのユーザーやロールがアクセスできる AWS サービス、リソース、個々の API アクションを制御します。

コストを管理する SCP の適用は、例えば図 1 のようになります。図は、右からサンドボックス（Sandbox）、開発・検証（Workload SDLC）、本番（Workload PROD）のOUとなっています。

SCP-3 がアタッチされたサンドボックスの OU では、billing の設定変更はできません。また、EC2 を利用する場合のインスタンスタイプを制限し、4xl までの汎用インスタンスとします。
SCP-2 がアタッチされた開発・検証の OU では、4xl より大きい EC2 インスタンスへのアクセスを制限します。また、しきい値以上の AWS 利用料になると、Slack チャネルにアラートが送信されます。
SCP-1 がアタッチされた本番の OU では、指定された AWS リージョン外のオペレーションを制限します。また、メンバーアカウントが組織から離れることも制限します。

図 1. SCP を適用して個々の環境のコストを管理する

データ転送のコストを最適化する

Cost Explorer レポートを確認した際、データ転送が AWS コストの主要なカテゴリを占めている場合、例えば CloudZero のネットワーキングに関するサブカテゴリディメンションを使用して内訳の確認ができます。具体的には、アウトバウンドの通信、アベイラビリティーゾーン（ AZ ）間の通信、NAT ゲートウェイや S3 アウトバウンドなどのコストに関するインサイトが得られます。

さらなるインサイトを得るために、 AWS Well-Architected コスト最適化ラボのガイダンスを使用して、 Amazon QuickSight で一時的なデータ転送ダッシュボードのセットアップも行えます。これにより、同一リージョンの Amazon EC2 と Amazon S3 間のトラフィックに対する NAT ゲートウェイ料金や、開発環境とテスト環境の AZ 間データ転送、NAT ゲートウェイの AZ 間データ転送などの情報を可視化できます。

図2は、NAT ゲートウェイの料金を削減するために、S3パブリックエンドポイント(点線)の代わりに Amazon S3 Gateway エンドポイント(実線)を使用した方法を示しています。また、RDSのリードレプリカを作成し、開発環境とテスト環境にて AZ 間のデータ転送を減らす方法も考えられます。

図2. AZ 間や AWS サービスへのデータ転送

ストレージコストを削減する

コストに適したS3ストレージクラスを使用するようにオブジェクトを更新する

Cost Explorer レポートを確認した際、すべてのオブジェクトが Amazon S3 の標準ストレージクラスを使用している場合、クラス変更によるコスト最適化が考えられます。そのために、「Amazon S3 cost optimization for predictable and dynamic access patterns」のブログのガイダンスを参考に、 Amazon S3 Storage Lens を使用してストレージの使用状況とアクティビティの傾向を可視化することができます。

Amazon S3 プレフィックスの GET リクエスト数、ダウンロードバイト数、および取得レートから、一定期間にデータセットがアクセスされる頻度とデータセットへのアクセス頻度が分かります。動的なデータアクセスパターンを持ったデータを S3 標準低頻度アクセスに保存すると、不要な取り出し料金が発生する可能性があるため、Amazon S3 Intelligent-Tiering に移行することが考えられます。また、アクセス頻度の低いオブジェクトについては、Amazon S3 のライフサイクルポリシーを作成して、オブジェクトを Amazon S3 の標準低頻度アクセス、 Amazon S3 1 ゾーン低頻度アクセス、または Amazon S3 Glacier ストレージクラスに自動的に移行するすることができます。

Amazon EBS gp3 ボリュームを適用する

「re:Invent talk on Optimizing resource efficiency with AWS Compute Optimizer」の講演のガイダンスを参考に、30 %以上オーバープロビジョニングされた EBS ボリュームを特定できます。AWS Compute Optimizer は、 AWS アカウントのすべての EBS ボリュームについて、VolumeReadBytes、VolumeWriteBytes、VolumeReadOps、VolumeWriteOps などの使用パターンとメトリックスを自動的に分析し、gp2 から gp3 ボリュームへの移行に関する推奨事項を提供してくれます。

また、「migrate your Amazon EBS volumes from gp2 to gp3 blog post」のブログは、ワークロードのベースラインスループットと IOPS 要件を特定し、コスト削減計算ツールを使用してコスト削減を計算し、gp3 に移行する手順を提供するのに役立ちます。

コンピューティングコストを最適化する

未使用リソース、低利用率リソースを調整する

AWSに Instance Scheduler をデプロイすることで、開発やテスト、運用開始前の環境における Amazon EC2 および Amazon Relational Database Service ( Amazon RDS ) リソースのさらなるコスト最適化ができます。これにより、週全体の 168 時間ではなく、週 40 〜 60 時間分の料金を支払うだけで済むため、64 〜 76 ％のコスト削減が可能になります。

コスト最適化のための負荷テスト

オーバープロビジョニングを回避し、アプリケーションが本番環境に移行する前にリソースのボトルネックを特定するために、CI / CD パイプラインに負荷テストを含めます。そのために、 Serverless Optimization Workshop を使用して、別の AWS アカウントに負荷テスト環境をセットアップしました。その負荷テストの一環として、 EC2 インスタンスを使用するよりも大幅に削減されたコストで、必要な規模で本番トラフィックをシミュレートすることができました。

結論

このブログでは、Cost Explorer の結果が、コスト管理と最適化の改善点を特定するのにどのように役立つかについて説明しました。 CloudZero を使用してコストの可視性を向上させる方法と、SCP を使用してコスト管理対策を適用する方法について説明しました。また、データ転送コスト、ストレージコスト、コンピューティングコストを少ない労力で節約する方法についても説明しました。

このシリーズの他のブログ

翻訳はソリューションアーキテクト小宮山裕樹が担当しました。原文はこちらです。

サービス	元のインスタンス	1時間あたりのオンデマンド料金(バージニア）	変更後のインスタンス	1時間あたりのオンデマンド料金(バージニア）	コスト削減
Amazon RDS (PostgreSQL)	r5.4xlarge	1.008	r6g.4xlarge	0.8064	20.00%
Amazon ElasticCache	cache.r5.2xlarge	0.862	cache.r6g.xlarge	0.411	52.32%
Amazon OpenSearch (データノード)	r5.xlarge.search	0.372	r6g.xlarge.search	0.335	9.95%

Amazon Web Services ブログ