これは、2 週間足らずで AWS のコストを 80% 削減した方法の物語です。 AWS は開発者のためのお菓子屋です 紹介から始める必要があります。私たちは 2018 年以来、すべてのプロジェクトで AWS を使用しており、奇跡をもたらしてくれました。私たちは完全に分散したチームであり、世界のどこかに独自のデータセンターを持つことには問題があります。 AWS からリソースを借りる方がはるかに簡単で、資本支出をすべて省略できます。 AWS の問題は、開発者が基本的に財務部門の承認を必要とせずにあらゆるリソースを作成できることです。従来のデータセンターでは、これは当てはまりません。追加のサーバーを購入するには、店舗から請求書を受け取り、財務部門に料金の支払いを依頼する必要があります。 つまり、基本的に、問題の根本は、AWS では、開発者が必要なときに必要な量のリソースを購入できるということです。 AWS のコストを削減するために何をしましたか? 当社は大企業ではないため、AWS のコストはすべての AWS アカウントで月額 7,000 ドルより少し高い程度です。また、PROD スタンドの費用はお客様が負担するため、当社が主催するのは DEV スタンドと QA スタンドのみであることにも留意してください。私たちのリソースのほとんどは、個々の開発マシン、テスト データベース、および Kinesis Firehose、Sage Maker などの研究プロジェクト用のさまざまなカスタム リソースです。そのため、分類、構造化、予測、制御が難しいランダムなリソースが大量にあります。 では、AWS のコスト削減にどのように取り組んだのでしょうか? 、Cost Explorer の調査を開始し、最も高価なアイテムを特定しました。 まず 過去 4 か月間稼働していたビットコイン ノードが見つかりましたが、追加のプロビジョニング速度を備えた大容量 SSD が必要なため、月額 600 ドルの費用がかかりました。私たちはビットコイン序数について小規模な調査を行いましたが、マシンは削除されませんでした。 解決策: ボリュームをアーカイブし (月額 6 ドルかかります)、VM を終了しました。 節約: 月額 594 ドル 月額 531 ドルの Nvidia Tesla GPU マシンを見つけました。私たちはこれを今日に至るまで生成 AI の実験に使用しています。私たちはテキストをビデオに生成する独自のアプリを構築することを考えているので、このマシンが必要です。 解決策: ボリュームをスポット インスタンスに移動しました。 節約: 月額 360 ドル 最も高価ではありませんが、最も驚くべき発見は、PROD のロールアウトを「最初から」テストするために Terraform スクリプトをデプロイした未使用リージョンの 1 つで、デモ PROD スタンドを削除するのを忘れたことです。 節約: 月額 340 ドル。 小さなアイテムがたくさんあります。 解像度: さまざまです。 節約: $1700/月 、インスタンスを特定するために可能な限りすべての移動を開始しました。これは簡単な手順です。個々のマシンの場合は、マシンをシャットダウンし、ボリュームを切り離し (マウント パスを忘れずに書き留めてください)、その後マシンを終了する必要があります。次に、新しいスポット インスタンスを作成します (AMI に関係なく、CPU アーキテクチャが以前のボリュームと互換性があることを確認してください)。スポット インスタンスが作成されたら、新しいボリュームをデタッチし (忘れずに削除してください)、元のマシン上にあったのと同じマウント パスに前のボリュームをアタッチします。 Beanstalk 環境の場合、これはより簡単です。スポット インスタンスのみを利用するように容量設定を変更するだけです。 2 番目に 節約: $1000/月 、未使用の S3 バケットをクリアしました (大量のストリーミング データを蓄積するいくつかの自動取引ボットを実行しました)。また、完全に時代遅れで役に立たなくなる取引データを 1 年以上保存しないように、複数の S3 バケット内のデータの自動削除を設定します。 3 番目に 節約: 月額 300 ドル 、いくつかのリソースを縮小しました。消費されている CPU と RAM を確認し、継続的な使用率が 50% 未満であることが判明した場合は、レベルを下げます。 4 番目に 節約: 月額 300 ドル (オンデマンド インスタンスではさらに 3 倍) 、個々のマシンに自動シャットダウンを設定します。さまざまなタイプのタスク用に複数のラムダ関数を作成しました。1 時間非アクティブな状態が続いた後に SageMaker Jupyter VM をシャットダウンする、個々の VM をシャットダウンする、DEV および QA は誰も作業していない夜間の期間を表します。これらのラムダ関数は、毎日 Cloudwatch イベントで実行されます。プロセスを容易にするために、DEV および QA スタンドを有効にするラムダもあります。 5 番目に 節約: $500/月 また、さらなる節約のためにいくつかの小規模なソリューションを実装しましたが、この記事では取り上げません。 これまでのところ、月々の請求額 7,000 ドルのうち約 5,500 ドルを節約できました。これは全費用の約 80% です。 AWS にお金を使いすぎていることは知っていましたが、これほど高額であるとは知りませんでした。年間で約 66,000 ドルの節約になります。 組織はクラウドコストの最適化にどのように取り組んでいますか? クラウド コストの最適化に関する私たち自身の経験を経て、クラウド コストを注意深く追跡することがいかに重要であるかを理解しました。基本的に、クラウド コストの最適化により、節約されたお金をマーケティングに投資すれば、ビジネスを促進するのに十分なコストを節約できます。あるいは、それを配当金として受け取って、新しい車を買うこともできます。その金額は大きく、それを使ってできることはたくさんあります。 クラウドのコスト最適化が絶対に必要な取り組みであることは論外ですが、企業はどのように取り組んでいるのでしょうか。最も単純なものから最も高度なものまで、クラウド廃棄物管理を実装する方法を考えてみましょう。 1. 仮想マシンのみを購入する 可能な限り最も伝統的な方法で問題に対処することもできます。 AWS が提供する無数の可能性を否定し、開発者が EC2 マシンを購入することを制限するだけです。 ＳＱＳ？いいえ、DynamoDB ですか?いいえ。EC2 仮想マシンを使用して、そこにすべてをインストールするだけです。 長所: EC2 VM のタイプごとに定額料金があるため、支出を非常によく予測できます。 開発者は、利用可能なマシンに必要なソフトウェアを詰め込みます。従来の物理的なオンプレミス データセンターと同様に、費用の効率性が向上します。 短所: 自動スケーリングのメリットを逃してしまう 開発者はすでにあるものを実装することに時間を無駄にしています 自動的に適用されるソフトウェアの自動アップデートを見逃してしまう 全体として、GoDaddy でホスティングをレンタルするかのようにクラウドを使用するのは良い戦略ではありません。 2. すべてのリクエストを確認する 開発者にリソースの使用と拡張を許可するが、コストを管理する特別な部門と交渉する必要がある場合はどうなるでしょうか?開発者にはリソースを購入/拡張する独自の権利はありませんが、特別な人にリソースの購入/拡張を依頼することができます。 開発者が Kinesis Firehose エンドポイントを必要としているとします (そう、おそらく聞いたこともないサービスについて言及しました)。開発者にとって、自分が望むことをコントローラーに説明するのは簡単な作業でしょうか?そして、開発者はスケーリングの背後にある理由も説明し、おそらくそのアーキテクチャの選択が適切であり、コスト管理の観点から無駄ではないことを証明する必要もあります。 具体的な例を挙げてみると、このようには機能しないことがわかります。コスト管理チームが専門家で構成されている場合にのみ機能します。 そしてそれは氷山の一角にすぎません。ここで次のことを考えてみましょう。 アーキテクチャの変更により不要になったリソース 開発者が仕事を辞め、個々の開発目的に使用していたリソースを削除しなかった ビジネスの問題を避けるためにリソースを迅速に拡張する必要がある緊急時 長所: 開発者は AWS が管理するリソースの利点を最大限に活用できます。 出費はしっかりとコントロールされている 短所: クラウドの無駄は、削除されなかった不要なリソースから発生する可能性があります コスト管理チームには高度な AWS の知識が必要です 官僚主義レベルはビジネスに損害を与える可能性がある 3. FinOps チームを雇う より高度な方法は、支出を管理する AWS の専門家を実際に見つけて雇用することです。 AWS が提供するツールを使用して、すぐに支出を管理できます。それは次のとおりです: コストエクスプローラー タグ付けサブシステム 予約済みインスタンス 貯蓄計画 コストの異常 もっともっと これらのツールはユーザーフレンドリーではなく、その使い方を知っている十分な教育を受けた担当者が必要です。ただし、実際にクラウド コストの制御を開始することはできます。このアプローチには、ツールや高度なスキルを持った作業者だけでなく、十分に活用されていないリソースの定期的なチェック、縮小とクリーンの手順など、チームが作業するためのフレームワークも必要です。 基本的に財務を意識したアプローチを持つ DevOps チームは FinOps と呼ばれます。 長所: 開発者は AWS のフルパワーを活用できます 開発者の官僚的なオーバーヘッドが小さい 財務チームは、プロジェクトごと、チームごとなど、さまざまな側面で支出を完全に制御できます。 開発者は意識的にリソースを消費します 短所: 高度な教育を受けたスタッフが必要ですが、ほとんどがまだ存在していないため、トレーニングする必要があります 人的要因の影響を受けやすい 反応時間は検査間の期間と同じくらい速く、未使用の EC2 マシンは 1 ～ 2 週間以上稼働し続けることができます。 4. クラウド廃棄物管理ソフトウェアを使用する FinOps チームの雇用 (または独自の成長) を真剣に考えたら、Infinops などのサードパーティのクラウド コスト最適化ソフトウェアも検討する必要があります。これは、24 時間年中無休で働く自動的な FinOps チームのメンバーであり、人的ミスの影響を受けません。このようなソフトウェアは、クラウドを自動的に制御して、十分に活用されていないリソースや、次のような他の既知の保存方法を管理します。 スポットインスタンスの使用 予約済みインスタンスの使用 QA 環境での OpenSearch クラスターの数の削減 夜間の個人 VM の無効化 Jupyter を使用した高価な SageMaker VM の自動シャットオフ 等 システムは常に変更をスキャンされているため、これらのヒントはすべて自動的に提供されます。そして、そのようなアドバイスにより できます。これは通常、年間で少なくとも数万ドルの節約を意味します。 、月額料金の最大 80% を節約 長所: FinOps チームにとって優れたツール 初心者の FinOps を最適化テクニックで支援します 人的要因を軽減します リソース消費の定期的なレビューを強制します タグ、ライフサイクル管理などを強制します 複数の AWS アカウントを一度に追跡できるようにする 短所: 独自のコストがかかる（通常は節約できるコストよりはるかに少ない） 、AWS のコスト管理は難しい場合があると言いたいと思います。同社の 80% の節約は、適切に行動すれば支出を削減できることを示しています。リソースに制限を設定する場合でも、承認を取得する場合でも、専門家チームや自動ツールを使用する場合でも、出費を注意深く監視することが重要です。結局のところ、クラウドの使用は、コストを高めることではなく、物事を簡単にすることを目的としている必要があります。 結論として
