大規模な効率：AWSコスト最適化の物語
公開: 2022-07-22私は最近、暗号通貨分析プラットフォームを立ち上げました。これは、毎日のユーザー数が少ないことを期待しています。 ただし、人気のあるYouTubeユーザーがサイトを参考にしてレビューを公開すると、トラフィックが急速に増加してサーバーが過負荷になり、プラットフォーム（Scalper.AI）にアクセスできなくなりました。 私の元のAWSEC2環境には、追加のサポートが必要でした。 複数のソリューションを検討した後、AWSElasticBeanstalkを使用してアプリケーションをスケーリングすることにしました。 物事は見栄えが良く、順調に進んでいましたが、請求ダッシュボードのコストに驚かされました。
これは珍しい問題ではありません。 2021年の調査によると、ITおよびクラウドの意思決定者の82％が不要なクラウドコストに遭遇しており、86％はすべてのクラウド支出の包括的なビューを取得できるとは感じていません。 Amazonはドキュメントで追加費用の詳細な概要を提供していますが、価格設定モデルは成長するプロジェクトにとって複雑です。 理解しやすくするために、関連するいくつかの最適化を分析して、クラウドのコストを削減します。
AWSを選んだ理由
Scalper.AIの目標は、暗号通貨ペア（取引所で取引するときに交換される資産）に関する情報を収集し、統計分析を実行し、暗号トレーダーに市場の状態に関する洞察を提供することです。 プラットフォームの技術的構造は、次の3つの部分で構成されています。
- データ取り込みスクリプト
- Webサーバー
- データベース
取り込みスクリプトは、さまざまなソースからデータを収集し、それをデータベースにロードします。 AWSサービスの使用経験があったので、EC2インスタンスを設定してこれらのスクリプトをデプロイすることにしました。 EC2は多くのインスタンスタイプを提供し、インスタンスのプロセッサ、ストレージ、ネットワーク、およびオペレーティングシステムを選択できます。
スムーズなアプリケーション管理が約束されているため、残りの機能にはElasticBeanstalkを選択しました。 ロードバランサーはサーバーのインスタンス間で負荷を適切に分散し、自動スケーリング機能は負荷を増やすために新しいインスタンスを追加する処理を行いました。 更新の展開は非常に簡単になり、わずか数分で完了しました。
Scalper.AIは安定して動作し、ユーザーはダウンタイムに直面しなくなりました。 もちろん、サービスを追加したことで支出が増えると予想していましたが、予想をはるかに上回りました。
どうすればクラウドコストを削減できたでしょうか
振り返ってみると、私のプロジェクトでのAWSサービスの使用には多くの複雑な領域がありました。 AWS EC2の一般的な機能（バースト可能なパフォーマンスインスタンス、アウトバウンドデータ転送、エラスティックIPアドレス、終了状態と停止状態）の操作中に発見した予算の最適化について検討します。
バースト可能なパフォーマンスインスタンス
私の最初の課題は、成長するプロジェクトのCPU消費電力をサポートすることでした。 Scalper.AIのデータ取り込みスクリプトは、ユーザーにリアルタイムの情報分析を提供します。 スクリプトは数秒ごとに実行され、暗号交換からの最新の更新をプラットフォームに提供します。 このプロセスを繰り返すたびに数百の非同期ジョブが生成されるため、サイトのトラフィックが増えると、処理時間を短縮するためにより多くのCPUパワーが必要になります。
4つのvCPUを備えたAWSが提供する最も安価なインスタンスa1.xlargeは、その時点で月額75ドルの費用がかかりました。 代わりに、2つのvCPUとそれぞれ1GBのRAMを備えた2つのt3.microインスタンス間で負荷を分散することにしました。 t3.microインスタンスは、a1.xlargeのコストの5分の1で、必要なジョブに十分な速度とメモリを提供しました。 それにもかかわらず、私の請求額は月末に予想していたよりもまだ大きかった。
理由を理解するために、Amazonのドキュメントを検索して、答えを見つけました。インスタンスのCPU使用率が定義されたベースラインを下回ると、クレジットが収集されますが、インスタンスがベースラインの使用量を超えると、以前に獲得したクレジットを消費します。 利用可能なクレジットがない場合、インスタンスはAmazonが提供する「余剰クレジット」を使用します。 クレジットを獲得して使用するこの機能により、AmazonEC2は24時間にわたってインスタンスのCPU使用率を平均化します。 平均使用量がベースラインを超えると、インスタンスはvCPU時間あたりの定額料金で追加料金が請求されます。
データ取り込みインスタンスを数日間監視したところ、コストを削減することを目的としたCPUセットアップが逆のことを行っていることがわかりました。 ほとんどの場合、私の平均CPU使用率はベースラインよりも高かった。
私は最初、いくつかの暗号ペアのCPU使用率を分析しました。 負荷が小さかったので、成長の余地は十分あると思いました。 （暗号ペアが少ないほど多くのCPUパワーを必要としないため、データの取り込みに1つのマイクロインスタンスのみを使用しました。）しかし、洞察をより包括的にし、データの取り込みをサポートすることを決定した後、元の分析の限界に気づきました。何百もの暗号ペアの場合-クラウドサービス分析は、正しい規模で実行されない限り、何の意味もありません。
アウトバウンドデータ転送
私のサイトの拡張のもう1つの結果は、小さなバグのためにアプリからのデータ転送が増加したことです。 トラフィックが着実に増加し、ダウンタイムがなくなったため、ユーザーの注意をできるだけ早く捉えて保持する機能を追加する必要がありました。 私の最新のアップデートは、暗号ペアの市況がユーザーの事前定義されたパラメーターと一致したときにトリガーされる音声アラートでした。 残念ながら、コードを間違えたため、オーディオファイルが数秒ごとに何百回もユーザーのブラウザに読み込まれました。
影響は大きかった。 私のバグは私のウェブサーバーからオーディオダウンロードを生成し、追加のアウトバウンドデータ転送を引き起こしました。 私のコードの小さなエラーにより、請求額は以前の請求額のほぼ5倍になりました。 （これだけが結果ではありませんでした。バグによりユーザーのコンピューターでメモリリークが発生する可能性があるため、多くのユーザーが戻ってくるのをやめました。）
データ転送コストは、AWSの価格急騰の30％以上を占める可能性があります。 EC2のインバウンド転送は無料ですが、アウトバウンド転送料金はGBごとに請求されます（Scalper.AIを構築した場合はGBあたり0.09ドル）。 難しい方法を学んだので、アウトバウンドデータに影響を与えるコードに注意することが重要です。 可能な場合はダウンロードやファイルの読み込みを減らす（またはこれらの領域を注意深く監視する）ことで、高額な料金から保護されます。 EC2からインターネットへのデータ転送の料金はワークロードとAWSリージョン固有のレートに依存するため、これらのペニーはすぐに加算されます。 多くの新しいAWSのお客様には知られていない最後の警告：異なる場所間でのデータ転送はより高価になります。 ただし、プライベートIPアドレスを使用すると、同じリージョンの異なるアベイラビリティーゾーン間での余分なデータ転送コストを防ぐことができます。
ElasticIPアドレス
Elastic IPアドレス（EIP）などのパブリックアドレスを使用する場合でも、EC2のコストを下げることができます。 EIPは、動的クラウドコンピューティングに使用される静的IPv4アドレスです。 「エラスティック」部分とは、EIPを任意のEC2インスタンスに割り当てて、停止するまで使用できることを意味します。 これらのアドレスを使用すると、アドレスをアカウント内の別のインスタンスに再マッピングすることで、異常なインスタンスを正常なインスタンスとシームレスに交換できます。 EIPを使用して、ドメインのDNSレコードを指定し、EC2インスタンスを指すようにすることもできます。
AWSは、リージョンごとにアカウントごとに5つのEIPしか提供しないため、リソースが限られており、非効率的な使用でコストがかかります。 AWSは、追加のEIPごとに低い時間料金を請求し、月に100回を超えてEIPを再マッピングすると追加料金を請求します。 これらの制限を下回ると、コストが削減されます。
状態の終了と停止
AWSには、実行中のEC2インスタンスの状態を管理するための2つのオプションがあります。終了または停止です。 終了するとインスタンスがシャットダウンされ、そのためにプロビジョニングされた仮想マシンは使用できなくなります。 接続されているElasticBlockStore（EBS）ボリュームはすべて切り離されて削除され、インスタンスにローカルに保存されているすべてのデータが失われます。 インスタンスの料金は請求されなくなります。
インスタンスの停止も同様ですが、わずかな違いが1つあります。 アタッチされたEBSボリュームは削除されないため、データは保持され、いつでもインスタンスを再起動できます。 どちらの場合も、Amazonはインスタンスの使用に対して課金しなくなりましたが、終了する代わりに停止することを選択した場合、EBSボリュームは存在する限りコストが発生します。 インスタンスをすぐに再アクティブ化する予定がある場合にのみ、インスタンスを停止することをお勧めします。
ただし、インスタンスを停止するのではなく終了した場合でも、月末にAWSの請求額を拡大できる機能があります。EBSスナップショットです。 これらは、AmazonのSimple Storage Service（S3）に保存されているEBSボリュームの増分バックアップです。 各スナップショットには、以前のデータを使用して新しいEBSボリュームを作成するために必要な情報が含まれています。 インスタンスを終了すると、関連するEBSボリュームは自動的に削除されますが、スナップショットは残ります。 S3は保存されているデータの量に応じて課金されるため、すぐに使用しない場合は、これらのスナップショットを削除することをお勧めします。 AWSは、CloudWatchサービスを使用してボリュームごとのストレージアクティビティを監視する機能を備えています。
- AWSコンソールにログインしているときに、左上の[サービス]メニューからCloudWatchサービスを見つけて開きます。
- ページの左側の[メトリクス]折りたたみメニューで、[すべてのメトリクス]をクリックします。
- このページには、EBS、EC2、S3などの利用可能なメトリックを含むサービスのリストが表示されます。 [ EBS]をクリックしてから、[ボリュームごとのメトリック]をクリックします。 （注： EBSオプションは、アカウントにEBSボリュームが構成されている場合にのみ表示されます。）
- [クエリ]タブをクリックします。 エディタビューで、コマンド
SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeIdをコピーして貼り付け、[ファイル名を指定して実行]をクリックします。 （注：CloudWatchは、固有の構文を持つSQLの方言を使用します。）
CloudWatchは、円グラフ、線、棒、積み上げ面グラフ、数値など、ストレージアクティビティを分析するためのさまざまな視覚化フォーマットを提供します。 CloudWatchを使用して非アクティブなEBSボリュームとスナップショットを特定することは、クラウドコストを最適化するための簡単なステップです。
あなたのポケットに余分なお金
CloudWatchなどのAWSツールは、クラウドのコストを監視するための適切なソリューションを提供しますが、さまざまな外部プラットフォームがAWSと統合されて、より包括的な分析が可能になります。 たとえば、VMWareのCloudHealthなどのクラウド管理プラットフォームは、傾向分析、異常検出、コストとパフォーマンスの監視に使用できる上位の支出領域の詳細な内訳を示しています。 また、CloudWatch課金アラームを設定して、チャージが過剰になる前にサージを検出することをお勧めします。
Amazonは、サーバー、データベース、ハードウェアのメンテナンス作業をAWSチームに委任するのに役立つ多くの優れたクラウドサービスを提供しています。 クラウドプラットフォームのコストはバグやユーザーエラーのために簡単に増加する可能性がありますが、AWSモニタリングツールは開発者に追加の費用から身を守るための知識を提供します。
これらのコストの最適化を念頭に置いて、プロジェクトを軌道に乗せる準備が整い、その過程で数百ドルを節約できます。