アーキテクチャレビューからコスト削減を考える②
投稿日: 2024/02/27
はじめに
こんにちは、園田です。
本記事は、「アーキテクチャレビューからコスト削減を考える①」の続きとなります。
第1回目を見ていないという方はこちらを参照ください。
アーキテクチャレビューからコスト削減を考える①
https://www.ctc-g.co.jp/solutions/cloud/column/article/78.html
「アーキテクチャレビューからコスト削減を考える①」では、以下のような順番でコスト削減を実施するお話を実施しました。また、アーキテクチャレビューでは「最適かどうか」は分からなくても、「良くない使い方はしているな」というのはある程度分かるという事を記載させていただきました。
- １．不要なサーバや過剰なスペックなどのサーバについての整理を実施する
- ２．テスト環境などについて常時起動が不要なものについては、停止を実施する
- ３．アーキテクチャレビューを実施し、使い方の見直しを実施する
- ４．常時利用するサーバについてはRI、もしくはSavings Plans（以下、SP）の購入を実施する
本ページでは実際に費用からわかるあまり良くないアーキテクチャについてみていきましょう。
ビリング（請求書）ちゃんと見てますか
お客様とお話をすると多くのお客様が、「ビリング（請求書）をあまり見ていないなー」と感じます。AWSの費用が高い・高くないを協議する前に、まず「何にコストがかかっているのかきちんと理解する」ことが必要です。
AWSではサービス単位、かつサービスの中の細かい単位で請求が出ています。
AWSのマネジメントコンソールにて「Billing and Cost Management」で請求情報が閲覧可能です。なお、リセラーからAWSから購入しており、「Billing and Cost Management」を閲覧できないというお客様は、同様の機能を持つツールをリセラーが用意しているはずなので、リセラーに確認しましょう。
なお、CTCから提供しているアカウントについてはHyperBillingというツールが利用可能です。
■HyperBillingについてはこちら
https://www.ctc-g.co.jp/solutions/cloud/solution/costmanagement/hyperbilling.html
■ビリング（請求書）の見方
「Billing and Cost Management」から左タグの「請求書」をクリックすると以下のようにサービス毎の費用が確認可能です。こちらの請求書については「＋」をクリックすることでより詳細な情報を閲覧することが可能です。
まずはどのようなサービスでどの程度費用が発生しているのかをきちんと確認しましょう。
当たり前ですが、利用金額が低いサービス（数ドル程度）に対してレビューしてもあまり意味がありません。金額が高い順に内容を見ていきましょう。
あまり良くないアーキテクチャのユースケース
それでは実際のお客様の利用環境を確認した際に出会ったユースケースを紹介しましょう。
■DynamoDBの費用が高い
DynamoDBの費用については、以下の通り「read capacity」および「write capacity」の利用料にて費用が決まります。
DyanamoDBの費用出力例
東京リージョンにおいて費用は以下の通りとなっています。（2024年2月現在）
プロビジョニングされたキャパシティの費用
- 書き込み：0.000742USD/WCU
- 読み込み：0.0001484USD/RCU
ちょっと分かり難いのですが、書き込みを10キャパシティに対し月額5ドル強ぐらいの費用が発生する。読み込み10キャパシティに対し月額1ドル強の費用が発生する。という大まかな認識でOKです。
ちなみにストレージは0.285USD/1Gになるため、100G利用時に28ドルぐらいとなります。ストレージが問題になることは無いので、あまり気にしなくて良いです。
この10キャパシティというのは1秒間に10回の書き込み、読み込みができると考えてください。（読み込み：1KB、書き込み：4KBまでの制限がつきます）
でこちらの費用は「プロビジョニングされたキャパシティ」の場合となり、あらかじめどれだけの書き込み、読み込みが発生するかを設計してあげる必要があります。過去はこのモードしかなかったのですが、最近はオンデマンドキャパシティの機能が出たため、ほぼすべてのお客様がオンデマンドキャパシティを使っているのではないでしょうか。
オンデマンドキャパシティについては必要に応じて、読み込み、書き込みのキャパシティを増減させてくれるという事で、事前の設計が不要となります。
その分費用が（オンデマンドキャパシティと同様の書き込み、読み込みをしようとすると）割高になっており、以下のような費用となっています。
オンデマンドキャパシティの費用
- 書き込み：100 万あたり 1.4269USD
- 読み込み：100 万あたり 0.285USD
これだとよくわかりませんね。結論から言うと、同じリクエスト数をこなすと単純計算で7倍オンデマンドの方が高いです。（1時間で100万リクエストの書き込みをこなす場合で計算。プロビジョンの場合、約0.2ドルとなりオンデマンドの1.4ドルの約7倍となる）
とはいっても上記は常時同じリクエストが来た場合の価格であるため、キャパシティがかなり上下するようなシステムではオンデマンドの方が良いと思います。
問題はプロビジョニングとオンデマンドの価格差ではなく、オンデマンドだと特にキャパシティを気にせず使えてしまう。という点です。大変便利な反面、使い方を誤ると価格が跳ね上がってしまいます。
例えば、DynamoDBのテーブルに対し、データの洗い替えで大量のデータ書き込みなどを行った場合、すぐに課金が跳ね上がってきてしまいます。
読み込みの方が金額が安いとはいえ、読み込みも同様です。
読み込みの費用が高額な場合はDAX（Amazon DynamoDB Accelerator）を検討しましょう。
一旦キャッシュに読み込ませることで、費用の削減が実施できる可能性があります。
なお、書き込みについてはどうしようもないので、仕組みそのものを変えてもらう必要があり、かなりの大手術となります（アプリの改修、またはDBをElastiCacheやDocumentDBに変更など）。
なお、バッチ処理で定期的に大量に書き込みをしているなどの場合は、処理の頻度を調整することで費用を削減できる可能性あります（もしくは特定タイミングだけ、キャパシティモードにして大量書き込みの費用を安くするなど）。
■CloudWatchの費用が高い
CloudWatchの費用については、基本以下の通りとなっています。
- CloudWatchでメトリクスを取りに行く費用（requested）
- CloudWatch logsのデータ出力費用（PutLogEvents）
- CloudWatch logsのストレージ費用
CloudWatchの費用出力例
CloudWatchで費用が掛かっているケースのほとんどは、「CloudWatch logsのデータ出力費用（PutLogEvents）」になります。
こちらはログをとりあえず出してる、のケースになると思いますが、1TBのログが出力された場合、約800ドル弱の費用となります。10TBとかログが出ると8,000ドルになってしまいます。
おそらくアプリ担当者がログを設定したことを忘れてしまっているケースもあると思いますが、CloudWatchログは手軽に使えてしまう反面、金額が上がってしまっても気が付かないケースがあるため、注意が必要です。（本当に大量のログ出力が必要なのであれば、別途、仕組みを検討しましょう。）
なお、ストレージ費用についてはCloudWatch logsのログの保持期間を定義し、無駄なログをため込まない様きちんと設定しましょう。
■VPCの費用が高い
基本VPCはほとんど費用が掛からないはずですが、インターフェイス型のエンドポイントを作った際は結構費用が発生してしまいます。
インターフェイス型のエンドポイントについては、0.014USD/時間（2024年2月現在）の費用が発生します。こちら基本はAZ冗長する形になると思いますので、月間約20ドル程度の費用となります。
これだけであれば特に問題は無いのですが、インターフェイス型のエンドポイントについてはサービス毎にエンドポイントが存在するため、利用するサービスが多くなればエンドポイントの金額も高くなってしまいます。
また、本番、検証、開発の3環境でエンドポイントがそれぞれ存在する、他のシステムのアカウントでも同じくエンドポイントが存在するといった場合、無視できない金額となってしまいます。（30アカウントがそれぞれ3つのエンドポイントを使っている場合、1800ドルになります）
このような使い方としている場合、NW管理アカウントを定義し、そのアカウントにエンドポイントを集約、各アカウントからはNW管理アカウント経由で接続するようなアーキテクチャに変更することを考えましょう。
別のアカウントに作成したエンドポイントについても、エンドポイント作成時に「プライベート DNS名を有効にする」のチェックを外し作成。およびエンドポイントを作成したアカウントにroute53のプライベートゾーンを作成し、他のアカウントに紐付けすることで利用が可能となります。
（当然リーチャビリティは必要となりますので、VPC間がTransit GatewayやVPC Peering等で接続されている必要があります。）
■EC2の費用が高い
EC2の費用が高い場合、「アーキテクチャレビューからコスト削減を考える①」で記載した通り、「不要なサーバや過剰なスペックなどのサーバについての整理を実施する」、「テスト環境などについて常時起動が不要なものについては、停止を実施する」を実施し、最終的にはRIやSPを購入するという形になります。
なお、細かい点になりますがストレージにgp2を使っているものがあれば、純粋にgp3に移行することで費用が20%削減可能です。（gp2→gp3は無停止で対応可能です。）
本来のアーキテクチャレビューではEC2で実現している機能をどのAWSサービスで対応可能かを検討する必要があるかと思いますが、費用からはそこまで分からないので対応は難しいですね。
サービス毎に請求の管理をしよう
きちんとAWSサービス毎に費用を見ることでよくないアーキテクチャ（費用がかかりすぎ）を見ることが出来ました。
基本的には請求を見て分析することを推奨しますが、そのような状況になった際に、もっと迅速に確認したいという要望もあるかと思います。
AWSでは各サービス毎に費用の閾値を設定し、閾値の金額を超えたらアラートを出すという事が可能です。管理者はアラートの受信をトリガーに請求情報を閲覧するという運用が実施できます。
なお、サービス毎にアラートを設定する場合、Organizationの親アカウントが必要となります。
■手順
- 1.Organizationの親アカウントにログイン
- 2.リージョンで「バージニア」を選択
- 3.Cloudwatchのサービスを選択
- 4.「アラーム状態」から「アラームの作成」をクリック
- 5.メトリクスの選択にて「請求」をクリック
- 6.「連結アカウントおよびサービス別」をクリック
- 7.設定したいサービスを入力し、「対象アカウント・サービス」にチェックを実施「メトリクスを選択」をクリック
- 8.「閾値を定義します」にてアラートを出したい金額を記載。「次へ」をクリック
- 9.アラーム状態時に、「既存のSNSトピック」を選択し、通知を実施したいメールアドレスを選択
- 10.任意のアラーム名を入力し「次へ」ボタンをクリック
- 11.「アラームの作成」ボタンをクリックし、アラームを作成
※基本、通常のCloudWatchと同様です。
以上で「アーキテクチャレビューからコスト削減を考える」は終了となります。
「請求書を見ることの重要性」、また意外と「コストからでも色々分かるんだな」という事が分かってもらえたかなと思います。
皆さんもきちんと請求書を見るようにしてください。また、次のブログでお会いしましょう。
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。
