re:Invent 2023: AWS Cloud Intelligence Dashboardsでコスト最適化とFinOps導入
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Optimize cost and performance and track progress toward mitigation (ARC319)
この動画では、AWS の Principal Technical Account Manager である Yuriy Prykhodko が、Cloud Intelligence Dashboards の活用方法を紹介します。コスト効率と運用パフォーマンスの最適化、FinOps の導入、そして組織全体でのクラウド財務管理について詳しく解説します。Dolby Laboratories の事例を交えながら、CUDOS ダッシュボードやデータ転送の最適化など、具体的な改善策を学べます。エンジニアの皆さんにとって、コスト意識の高い文化づくりのヒントが満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
FinOpsとCloud Intelligence Dashboardsの紹介
みなさん、ご来場いただきありがとうございます。この re:Invent で発表された新しいサービスや機能について、皆さんも私たちと同じくらい興奮していて、帰ってからすぐに試してみたいと思っていただけたら嬉しいです。ここで皆さんに質問があります。AWS で workload を実行する際、最もコスト効率の良い方法で実行していると、どれくらい自信を持っていますか？あるいは、もっと自信を持ちたい、常に最新の状況を把握したいと思う方は手を挙げてください。なるほど、ありがとうございます。コストは単なる数字ではありません。それは私たちの決定、優先順位、そして複雑な世界で価値を最適化する能力を反映しているのです。
私は Yuriy Prykhodko と申します。AWS の Principal Technical Account Manager で、Cloud Intelligence dashboards framework の創設者の一人であり、リーダーの一人です。本日は JR さんと Mike さんと一緒にステージに立てることを大変嬉しく思います。 こんにちは、JR Storment です。FinOps Foundation の Executive Director を務めています。私たちは、クラウドの価値を管理する人々のためのコミュニティに焦点を当てた、クラウド中立の組織です。教育、トレーニング、そして Yuriy が後ほど触れる FinOps specification のような標準化を行っています。そして私は Mike Graff です。サンフランシスコを拠点とする Dolby Laboratories の Infrastructure Architecture Director を務めています。
クラウドコスト管理の重要性と課題
さて、始めましょう。今日は、workload のコスト効率と運用パフォーマンスを最適化し、追跡する方法についてお話しします。 グローバルなクラウド支出が増加しているのは驚くべきことではありません。そのため、急速に増加する支出を管理することが組織にとって最優先事項になっているのも当然です。実際、今年は10年ぶりに、クラウド支出の管理が、組織が直面する最大の課題としてセキュリティを上回りました。同時に、多くの顧客は、組織全体でクラウドの財務管理と FinOps の規律を成功裏に導入・採用することが、ビジネスを推進し、収益を成長させるのに役立つと認識しています。
コストは氷山のようなものです。 見えているのは氷山の一角に過ぎません。本当の課題は、その下にある要因を理解し、水面下にある重要な部分を形作る情報に基づいた決定を下すことにあります。AWS やクラウド上の workload を見てみると、セキュリティや信頼性、パフォーマンスなどのアーキテクチャの詳細はすべてコストに反映され、その逆も然りです。workload のコストの詳細と洞察を深く理解することで、Well-Architected の全ての柱にわたって多くの最適化の機会を見つけることができます。
クラウドでは、コストは運用指標です。 パフォーマンスや可用性と同じように。そして、それはスケーラブルな指標です。ビジネスの成長と規模に伴い、顧客にサービスを提供するためにより多くのインフラが必要となるため、クラウドの使用量は自然に増加します。私たちが確認したいのは、ビジネスと顧客数が AWS の請求額よりも速く成長することです。そのため、workload が単に高性能で耐障害性があるだけでなく、コスト効率も良いことを確認する必要があります。しかし、コスト効率は前月より支払いが少ないということではありません。コスト効率とは、クラウドへの投資から最大のビジネス価値を得ることなのです。
単に前月のAWS請求書と比較するだけでは、ここでは機能しません。コストも変動する指標だからです。そして、オペレーショナル・エクセレンスの観点から、どんな指標も、ビジネスの目標や成果に結びついていなければ意味がないことを私たちは知っています。これはコストにも当てはまります。インフラ自体のコストではなく、ビジネスドライバーやビジネスユニットあたりのコスト、例えば顧客あたりのコストや取引あたりのコストを測定することで、ビジネスドメインに応じて、ワークロードのクラウド使用量をそれらのワークロードが提供するビジネス価値と関連付けることができます。
クラウドワークロードの最適化戦略
クラウドでは、すべてのアーキテクチャの決定が購入の決定でもあります。そして、ワークロードのアーキテクチャを改善し、クラウドワークロードのビジネス価値を最大化する方法はたくさんあります。インスタンスの適切なサイジングを行い、最も適切でコスト効率の良いインスタンスを、例えばGravitonベースのインスタンスなどのタイプや、サイズで選択し、インスタンスのサイズをCPUやメモリの使用率に合わせることができます。また、弾力性を向上させ、必要な時だけリソースを使用することもできます。
需要に合わせてスケールさせます。例えば、「本当に開発環境やテスト環境を24時間365日稼働させる必要があるのか？それとも、インスタンスのスケジューリングのようなものを実装して、必要のない時にこれらのワークロードをオフにできないか？」と自問してみてください。また、アイドル状態のリソースやインフラの無駄を特定して排除することもできます。私たちが持っているデータによると、約30%のワークロードがこのカテゴリーに該当します。これは最適化の機会の宝庫です。
ベースラインを最適化したら、スポットインスタンスのような割引レートのある価格オプションを検討したり、Savings PlansやReserved Instancesでワークロードをカバーしたりすることができます。ストレージを最適化したり、イベントドリブン設計やサーバーレスワークロードのようなよりクラウドネイティブなパターンにアーキテクチャを変更したりすることもできます。つまり、完全に最適化された状態に到達し、使用量が増加しても単位コストを削減する方法はたくさんあるのです。しかし、どのようなコスト最適化の機会があるか、そしてエンジニアリングチームや技術リーダーがそれらの機会をどれだけ効果的に活用しているかを理解することは、規模が大きくなるほど難しくなります。したがって、それを達成するためには、人、ツール、プロセスを一体化させる必要があります。
FinOpsの概念と組織への導入
そこで、コスト意識の高い文化を実現するための手段としてFinOpsが登場します。FinOpsは、エンジニアリング、プロダクト、技術、ビジネスのチームを結集させ、データに基づく支出の意思決定を協力して行うことで、ビジネス価値を最大化するクラウド財務管理の規律です。簡単に言えば、皆さんはおそらくDevOpsについて、「作ったものは自分で運用する」つまり運用に責任を持つという概念をご存知でしょう。FinOpsも同じです。作ったものは自分で運用し、ワークロードのコスト効率に責任を持ちます。そして、コストを管理下に置くこと、つまりコストの予測可能性に責任を持つのです。
FinOpsはセキュリティと同様に、財務チームだけでなく全員の責任です。優れた可視性とコスト意識から始まり、これがチームと全てのステークホルダーを最適化の機会へと導きます。そして、これらの最適化の機会に基づいて行動し、ワークロードを最適化し、ワークロードの最適化から学んだベストプラクティスを運用ガイドライン、アーキテクチャブループリント、リリース準備プレイブックに組み込みます。つまり、すでにAWSにデプロイされているワークロードを最適化すると、将来のワークロードはレビューステージやリリース準備評価ステージで最適化され、すでに最適化されFinOps対応の状態でクラウドに投入されるのです。
FinOpsはプロジェクトや期間限定の活動ではなく、組織内の全てのステークホルダー間での継続的な改善と協力のアプローチであることを理解することが非常に重要です。J.R.さんに、FinOpsについてもっと詳しく、そしてFinOpsを導入した企業で見られる業界のトレンドについて話していただきたいと思います。
FinOpsの業界トレンドとベストプラクティス
ありがとうございます、Yuriy。Yuriyが先ほど言及したことで、少し要約されていると思ったのは、アーキテクチャの決定は全て購買の決定だということです。FinOpsについて考える際に重要なのは、これが技術的な分野というよりも、特にエンジニアリングチームと財務チーム内での文化的な変革だということです。多くの場合、人々がこの分野を見始めるとき、「FinOpsを使ってお金を節約しよう、請求額を削減しよう」と考えます。コスト最適化はその一部ですが、ビジネス価値の部分がより重要です。なぜなら、多くの場合、これらのアーキテクチャの決定を使って、いつどこに投資するかを決定するからです。時には投資を増やし、時には減らすこともあります。
私たちは毎年、State of FinOpsという調査を実施しており、現在4回目を迎えています。'22年にデータ収集を行っていた時は、経済の下降期でした。そのため、無駄を削減し、最適化されていないアーキテクチャを排除する側面が大きく跳ね上がりました。しかし、ここ1年ほどで、Yuriyが話していた単位経済性の側面が大きく増加しています。つまり、取引価値や顧客あたりのコストをどのように改善するかということです。
現在コミュニティで見られる最高の事例を紹介しますが、素晴らしい事例は多数あります。私たちは毎年FinOpsXという年次カンファレンスを開催しています。6月にSan Diegoで開催されます。昨年のカンファレンスの基調講演者の一人で、Adobeでクラウドを担当しているRich Steckという方がいます。彼はこのカンファレンスにも参加しています。彼はAdobeがFireflyをローンチした経緯を共有しました。FireflyはAdobeのAI搭載製品です。Fireflyは本質的に
AdobeのFirefly開発におけるFinOpsの活用事例
Adobeはこの製品を構築するためにより多くのエンジニアリングリソースが必要だと気づきました。彼らがこの製品を設計した方法は、クラウドから大規模なコスト削減を行うためのリーダーシップの支援を得ることでした。彼らは財務部門と協力して、この全く新しい製品を構築し、立ち上げるプロジェクトの資金調達にかかるコストを算出しました。中央の効率化チームが削減の機会を見つけ、個々の製品チームにコストエンジニアを配置し、それらのチームが設計上の決定を行い、最適化の領域を見つけ、コストを削減しました。
単に利益率を上げようとするのではなく、彼らはそのコスト削減を、リーダーシップと財務部門の支援を得て、Adobe Fireflyを構築し立ち上げた全く新しいエンジニアリングチームの資金調達に活用することができました。彼はこれについて話しませんでしたが、公開企業なので、Firefly立ち上げ後の株価を見ると、大きく上昇しているのがわかります。これは、単にコストを削減するだけでなく、そのコストを取り、イノベーションに投資するために、現実世界でFinOpsを使用した素晴らしい例でした。そして、これこそがまさにFinOpsの本質なのです。
このリストの一番上は、FinOpsの基本原則バージョンと緩やかに相関していますが、組織の整合性です。組織内の異なる人々 - 財務チーム、リーダーシップ、エンジニアリングチーム、調達チーム、ソーシングチーム - をどのように集めて、アーキテクチャの変更、クラウドへの投資、またはリソースの変更についてより良い決定を下すための会話をするかということです。コストの可視性と認識の部分は、FinOpsのマズローの欲求階層の中核として十分に強調しきれません。上位では経済性の最適化を目指すかもしれませんが、その全ての基礎にあるのは、私たちのコストがどこにあるかを理解することです。
これは12年間、FinOpsにおいて最も困難な課題でした：タグ付け、ラベリング、リンクされたアカウント、プロジェクト、またはサブスクリプションを通じてコストがどこに向かっているかを理解し、個々のチームがより良い決定を下すための明確なKPIとパフォーマンス追跡を生成できるようにすることです。適切なタイミングと適切な方法でエンジニアリングチームにデータを提供することで、データ駆動の意思決定が促進されます。確かにコストと使用の最適化の要素はありますが、最終的には、時間とともに起こる文化的シフトについての会話を再設定したいのです。
FinOpsの組織的実装と文化的変革
繰り返しになりますが、FinOpsは一度きりの取り組みではありません。これは広範な組織的サポートと経営陣のサポートを必要とするものです。よく聞かれる質問の一つは、「この取り組みに経営陣の関心を引くにはどうすればいいですか？」というものです。もっと良い答えがあればいいのですが、結局のところ、これは通常、エンジニアリング組織内のチャンピオンから始まり、この分野に関心を持ち始めます。しかし、文化的規律とプロセスのより大規模な実装は、最終的には請求額が十分に大きくなり、組織の規模に応じてCFO、CIO、またはCEOがそれに関心を持ち、プロセスを実装し始めるときに実現します。
私たちはこの取り組みを約4年間続けてきました。多くの作業は文化的な変革ですが、同時にチームに理解してもらうための教育も行っています。FinOps認定を受けている方は何人いますか？素晴らしいですね。数年前にFinOpsについて知っている人がいるか尋ねたときは、誰も手を挙げませんでした。今では増えているのを見るのは嬉しいことです。しかし、その認識を広め、チームに認定を受けてもらい、教育を行うことの根底には、次のフェーズがあります。それは最終的に、FinOpsのプロセスを進行中のエンジニアリング分野にどのように統合していくかということです。
この1年で見られたトレンドの1つは、FinOpsがエンジニアリング組織の一部になったことです。ここで言うのは、反応的なコスト最適化ではなく、実際にコストに関連する変更を各スプリントに組み込むための時間を費やすことです。アーキテクチャの決定段階でコストの話をする、いわゆる「シフトレフト」（申し訳ありませんが、またバズワードを使ってしまいました）を行うのです。つまり、コストを別のパフォーマンス指標として見ているのです。エンジニアリングチームは当初、コストに関して抵抗を示すことがよくあります。なぜなら、スケーラビリティ、信頼性、期限、パフォーマンスなど、他にも気にかけることがたくさんある中で、さらに別の心配事として捉えられるからです。しかし、本当に考えてみると、コストを別の一流の効率性指標として再定義することで、より革新的になれる新しい制約として導入できるのです。この機能を、この時間内に、このコスト制約の中で提供できますか？
しかし今では、非常に興奮することに、1、2ヶ月前にニュースで見た方もいるかもしれませんが、クラウドプロバイダーがこの実践をリードし始めているのを目にしています。Yuriyさん、あなたとステージに立ち、FinOpsについて話すことができて、どれほど嬉しいか言葉では言い表せません。これは、AWSが歴史的に深く踏み込めなかったことです。AWSは昨年、FinOps Foundationに加入しました。そして、Yuriyさんに感謝の言葉を述べたいと思います。彼はこの取り組みの大きな支援者でした。
Yuriyさんが構築したCUDOSダッシュボードは、現在、エコシステム内で人々が使用するトップツールの1つとなっています。ここで重要なのは、チームにコストの可視性を提供し、各チームにとって意味のある方法でそのデータをカスタマイズする能力を持つことです。エンジニアリングチームが途中でより良い決定を下せるように、そのデータを彼らの作業の流れに組み込むことが重要なのです。
FinOpsに適した唯一のツールというものは存在しません。FinOpsの現状調査によると、企業は平均して約4.1個のツールをFinOpsの実践に使用しています。およそ97%が何らかのクラウドネイティブツールを使用し、65%が何らかのプラットフォーム観測ツールを使用しています。そして、最も急成長している分野の1つがカスタマイズ可能な自社開発ツールです。適切な仕事に適切なツールを組み合わせることが重要です。FinOpsの実践には約18の異なる機能があります。コスト最適化だけでなく、予測、組織の整合性、チャージバックなど、多くの領域があります。どのアプローチを選んでも、適切な方法でデータを入力することが重要です。
AWSのCloud Intelligence Dashboardsの詳細
さて、ここからはYuriyがAWSが提供するツールについて少し話をしてくれると思います。ありがとう、JR。私は非常に興奮しています。FinOps Foundationに参加したことについて、まったく同感です。これは、コミュニティや顧客により近づき、FinOpsの課題を大規模に解決するためのものです。私たちはすでに、FOCUSの仕様、つまりFinOps Open Cost and Usage Specificationへの貢献を始めています。これは、クラウドのコストと使用状況について、誰もが簡単に理解できるようにすることを目的としています。
AWSでのFinOpsの旅がどのようなものか見てみましょう。組織内にFinOps practitionerの専任ロールがある方は手を挙げてください。もしなくても心配する必要はありません。FinOpsはあなたにも関係があります。専任のFinOps practitionerの役割がない場合、共有責任を持つ誰かがその役割を担うこともあります。FinOps practitionerは、組織内で変革を推進し、組織の整合性を支援し、可視性とコスト意識を向上させ、エンジニアが行動を起こせる点を強調し、継続的な改善の習慣を構築する人です。
AWSはFinOps practitionerのために多くのツールを提供しています。通常、FinOps practitionerの旅は、コストの可視性と詳細情報への入り口となるAWS Cost Explorerのようなサービスから始まります。また、AWS Budgetsを有効にして、支出と使用量の境界と管理を設定することもできます。次に、Savings PlansとReserved Instanceの推奨事項を使用して、利用可能な購入オプションをより良く理解することができます。AWS Compute Optimizerを使用して、リサイジングの推奨事項をより深く掘り下げることができます。これは誰でも無料で利用できるサービスです。Compute Optimizerを是非ご覧になることをお勧めします。
EnterpriseまたはBusinessサポートレベルの場合、AWS Trusted Advisorを使用してアイドル状態のリソースの可視性を得ることができます。Cost and Usage Reportsからのリソースレベルの洞察とデータマイニングをより深く行うには、AWS Cost and Usage Reports、またはCost and Usage Reports 2.0のリリース後に呼ばれるようになったAWS Data Exportを有効にすることができます。
クラウドにおけるコストも分散化された指標であるというのが現実です。コストとFinOpsに関しては、多くの利害関係者がそれぞれの目標と要件を持っています。 財務部門や調達部門は、より良い可視性と、より正確な予算策定と予測を必要としています。彼らは、企業が所有する複数のAWS organizationを含む、すべての事業体にわたる統合レポートを必要としています。エンジニアリングリーダーは、アプリケーションや環境ごとの支出についてより良い可視性を必要としています。プロダクトオーナーは、成功するビジネスケースを構築するために、機能ごとの支出、顧客ごとの支出、取引ごとの支出などを知りたいと考えています。経営陣は、収益あたりの支出、組織の利益率、全体的なビジネスの成長を注視しています。
興味深い事実は、単位コストを計算するためには、顧客数や収益などのビジネスメトリクスとAWSのデータを一緒に結合する必要があるということです。コストを割り当てるには、コストセンター、事業部門、部署などの組織の分類法をAWSのデータと組み合わせて、コストを正確に割り当てる必要があります。
もう一つの課題は、すべての利害関係者がAWS consoleにアクセスしてサービスを利用できるわけではないということです。一部の利害関係者は、すべてのアカウントではなく、特定のグループのアカウントからのコストと使用状況データにのみアクセスする必要があります。ここには明らかなパターンが見られます。それは、すべての利害関係者のニーズに合わせて調整可能な協調的な環境が大きく求められているということです。そこでは、全員がデータ駆動の意思決定のために協力して作業することができます。
Cloud Intelligence Dashboardsの機能と利点
これを支援するために、私たちはCloud Intelligence Dashboardsフレームワークを作成しました。 これは、Amazon QuickSightのオープンソースでカスタマイズ可能なダッシュボードのコレクションです。すべての顧客は、Well-Architectedラボ、ガイド、CloudFormationテンプレートに従って自分のアカウントにデプロイし、セルフサービスツールとして使用することができます。このQRコードをスキャンして、Cloud Intelligence Dashboardsのエントリーポイントをブックマークすることができます。主な特徴を強調したいと思います：これらをデプロイすると、データとすべてのリソースは組織内、つまりあなたのAWSアカウント内に留まります。第三者とデータを共有する必要はなく、非常に安全です。ダッシュボードは、コストと使用状況データについて、包括的で実用的な洞察と詳細なリソースレベルの詳細を提供します。これらのダッシュボード自体の使用に対して料金は発生しません。基盤となるサービスの使用に対してのみ料金が発生しますが、これは第三者ツールと比較するとほんのわずかです。
Cloud Intelligence Dashboardsをより詳しく見てみましょう。これらのダッシュボードをアカウントにプロビジョニングしてデプロイすると、 先ほど話したすべてのサービスがデータソースに変わります。これらはS3 bucketにデータの配信を開始します。また、Amazon Athenaのテーブル定義とビューも取得します。つまり、これらすべてを最適化データレイクに変換するのです。また、このデータレイクを可視化するためのダッシュボードのコレクションも最初から用意されています。 意思決定者をデータにより近づけ、有用な情報を調査するのに必要な時間を最小限に抑えることで、最適化のためのアクションに時間を費やすことができます。
QuickSightのネイティブ機能を活用することで、組織内の任意のステークホルダーとダッシュボードを共有できます。彼らはAWSコンソールにアクセスする必要さえありません。また、QuickSightのロールレベルのセキュリティ機能を使用して、特定のステークホルダーに対して、彼らが必要とする、または所有するアカウントやデータへのアクセスのみを提供することができます。Cost and Usage Reportsを基に構築された基本的なダッシュボードをデプロイすることができます。これらのダッシュボードは、コスト効率のKPIや、CUDOSダッシュボードによる詳細な洞察など、支出と使用状況の最も重要な部分にすぐにアクセスできるように構成されています。
また、AWS Compute Optimizer、AWS Cost Anomaly Detection service、AWS Trusted Advisorなどのサービスからの推奨事項の可視化を提供するダッシュボードもデプロイできます。複数のpayerアカウントにわたるこれらの推奨事項をすべて1か所に集約できます。リソースレベルの粒度やリソースレベルの推奨事項を確認するために、アカウントやリージョンを切り替える必要はありません。すべてが1か所にまとまっています。すでにCloud Intelligence Dashboardsを使用しているお客様がおり、すぐに使用できる可視化をダッシュボードで提供するというこのコンセプトとアプローチは非常にうまく機能しています。
私たちはAWSのコストだけでなく、さらに先に進んでいます。最近、Azure用のCloud Intelligence Dashboardをリリースしたことを嬉しくお知らせします。これにより、他のクラウドプロバイダーのコストと使用状況データを取り込み、AWSの支出と使用状況と一緒にAmazon QuickSightで可視化できます。また、Sustainability Proxy Metrics Dashboardもリリースしました。これにより、サステナビリティホワイトペーパーで言及し、追跡を推奨しているプロキシメトリクスを可視化できます。さて、実際の動作を見てみましょうか？
KPIダッシュボードとCompute Optimizerダッシュボードの活用
では、KPIダッシュボードに移ります。FinOps実践者や、例えばテクノロジーリーダーとして、私と組織にとってどのような最適化の機会があるか、何を追跡できるかを見たいと思います。そこで、このKPI goalsタブに移動し、お客様から学んだ、通常追跡される基本的なKPIのコレクションを見ることができます。
これらのKPIから始めることをお客様にお勧めしています。なぜなら、組織で何を追跡し、何を最適化できるかについてのヒントを実際に提供してくれるからです。例えば、Amazon EBSの場合、最もコスト効率の良いボリュームタイプであるgp3ボリュームに移行できます。Amazon RDSの場合、ワークロードをGravitonに移行する可能性があります。あるいは、アイドル状態や未使用のリソースの最適化について話すなら、1年以上経過したEBSスナップショットの量を減らすことができるかもしれません。各KPIについて、状況に応じて独自の目標を設定できます。
KPI trackerタブに移動すると、過去数ヶ月間の目標に向けた進捗状況を追跡できます。明確に方向性が見えるようになっています。KPIダッシュボードで私が最も気に入っているのは、設定した目標を達成した場合に得られる潜在的な節約機会も提示していることです。これにより、最も影響力のあるものや、労力は少ないものの十分な最適化の節約機会を提供するものに焦点を当てて、最適化に向けたアクションの優先順位をつけることができます。
このダッシュボードを、リソースを所有し実際に最適化アクションを行う必要があるエンジニアリングチームと共有できます。Amazon QuickSightでこのダッシュボードを共有すると、彼らは全く同じビューを開いて見ることができます。例えばEBSタブに移動して、最適化のための追加のコンテキストを得ることができます。例えば、gp3への移行の進捗状況を時系列で確認できます。彼らは最適化アクションとこの進捗が、インフラストラクチャユニットコストやデータ1ギガバイトあたりのコストにどのような影響を与えるかを見ることができます。この場合、gp3への移行によってEBSの1ギガバイトあたりの平均コストを削減できたことがわかります。
次に、現在のgp2のコストとgp3での潜在的な節約を含む、リソースの詳細を持つすべてのボリュームのビューがあります。これにより、エンジニアはリソースの優先順位をつけ、迅速に影響を与えるためにどこから始めればよいかを知ることができます。サイズ変更の推奨事項についてはどうでしょうか？Compute Optimizerダッシュボードでは、サイズ変更の推奨事項の統合ビューが1つの場所にまとめられており、時系列で追跡できます。EC2、Lambda、EBSボリューム、Auto Scaling groupsのサイズ変更による節約機会を見ることができます。
データをAmazon S3に統合しているため、ここで履歴コンテキストを得ることができます。時系列での節約機会の量を見ることができ、現在の進捗を前月の進捗と比較できます。これは、どこに向かっているかを理解するのに非常に強力です。また、リソースの所有者やエンジニアリングチームのメンバーであれば、ここにある各サービスのタブを使用してこのダッシュボードをインタラクティブに操作できます。例えば、オーバープロビジョニングされたインスタンスを選択し、焦点を当てたいアカウントを選択できます。残りのビジュアルは、選択に基づいてインタラクティブにフィルタリングされます。
最適化できるインスタンスのリストが、節約機会順に並んでいます。EC2インスタンスのいずれかを選択すると、サイズ変更のオプションと推奨事項が表示され、推定される節約機会、現在および予測されるメモリとCPU使用率、さらにこのインスタンスの状態の履歴コンテキスト（最近オーバープロビジョニングされたのか、それともしばらく前からなのか）が表示されます。また、AWS Compute Optimizerサービスが提供する過去の期間のAmazon CloudWatchメトリクスも得られます。これらはすべて、データ駆動の意思決定のための追加のコンテキストを提供することを目的としています。
AWS Trusted Advisor ダッシュボードも使用できます。このダッシュボードでは、アイドル状態のリソースに関する推奨事項が提供されます。コスト最適化タブでは、アイドル状態の RDS インスタンス、アイドル状態のロードバランサー、または未使用の Amazon Redshift クラスターに関するインサイトとリソースレベルの詳細を確認できます。ここでも、時間の経過に伴うトレンドとリソースレベルの詳細が表示されます。各クラスターについて、接続がなかった日数、最初にフラグが立てられた日時、最後にフラグが立てられた日時、クラスターごとの推定節約額などを確認できます。
Trusted Advisor ダッシュボードには、セキュリティ、耐障害性、パフォーマンスなどの異なるタブもあります。このダッシュボードを他のステークホルダーと共有して、これらの推奨事項を活用してもらうこともできます。他のすべてのサービスについてはどうか、そしてそれらをどのように把握するかと疑問に思われるかもしれません。ここで、CUDOS ダッシュボードをご紹介したいと思います。
CUDOSダッシュボードの詳細と活用例
CUDOS ダッシュボードは、当社で最も人気のあるダッシュボードの1つです。高レベルの概要を提供する3つのエグゼクティブタブから始まる同様のコンセプトを持っています。例えば、請求サマリーは財務チームに人気があるかもしれません。これは、請求額、償却後の支出、そして1つの場所ですべての節約額と割引を提供するためです。さらに、複数の支払者アカウントや複数の組織からのデータを統合できるので、所有するすべての組織にわたる統合レポートを見ることができます。
例えば、Reserved Instance と Savings Plan のサマリーでは、節約の機会をどのように活用しているか、それらによってどれだけ節約しているか、未使用のコストがあるかなどのインサイトを得ることができます。また、組織の Savings Plan と Reserved Instance をリンクされたアカウントごとにチャージバックするのに役立つビジュアルも見つかります。アカウントの月ごとの最も重要な変更をより深く掘り下げたい場合は、インタラクティブな月次トレンドタブに移動できます。ここでは、サービスごと、アカウントごとの差異や上位の変動と下位の変動に関するインサイトと詳細が表示されます。
月次トレンドのテーブルビューに深く掘り下げて、パーセンテージの差や絶対値でソートすることができます。そして、任意のサービスに焦点を当て、インタラクティブに選択できます。例えば、RDS を選択すると、どのアカウントで RDS のコストが増加したかをワンクリックで確認できます。次に、特定のアカウントにズームインするためにアカウントを選択できます。ここでは、リージョンごとや API オペレーションごとの支出など、他の次元も確認できます。ここで明確に見えるのは、システムオペレーション製品ファミリーでの増加です。
これは何でしょうか？見てみましょう。システムオペレーションを選択し、下までスクロールすると、リソースIDごとの日次支出を示すビジュアルが表示されます。 コストの大部分を生成しているリソースを特定することができました。それはRDSクラスターです。これを選択すると、使用状況の詳細が表示されます。30億IOPSが発生し、実際に6,500ドルの支出を生み出したことがわかります。 わずか数回のクリックで、高レベルのインサイトやトレンドからリソースレベルの詳細まで辿り、最大のコスト発生源を特定することができました。
CUDOSダッシュボードの使用を開始する際、最初の3つのタブだけを使用して、高レベルのコストと使用状況の詳細を把握することができます。しかし、各サービスについてより多くの推奨事項を得たい場合は、compute、storage、S3などの他のタブを使用できます。すべてを網羅するのは難しいでしょうし、Mikeがデータ転送について話す予定ですが、 AI/MLタブの例を一つお見せしたいと思います。今週、みなさんは生成AIについて聞いたことがあると思います。 AI/MLタブでは、Amazon SageMakerなどのサービスの詳細を提供しています。SageMakerの支出と使用状況の異なる次元と内訳を見ることができ、 モデルのトレーニングにスポットインスタンスを活用しているかどうかなども、リソースレベルの詳細と粒度まで確認できます。
数週間前、ここにAmazon Bedrock Summaryというセクションを追加しました。これにより、 Marketplaceでサードパーティからモデルを購入しているか、Amazonの基盤モデルを使用しているかに関わらず、Bedrockの支出と使用状況の統合ビューを見ることができます。プロビジョンドスループットを活用しているか、オンデマンド推論を使用しているかなど、価格モデル別の内訳を確認できます。 そして、運用インサイトもリソースレベルまで提供しており、モデルごとの支出データを表示し、特定のモデルを選択してその使用状況のインサイトに焦点を当てることができます。このように、わずか数回のクリックで、日々の支出と使用状況を把握することができます。これらの新しいサービスの採用を開始する際、自信を持ってコストと使用状況を監視し、追跡することができます。
これらはすべて、Cloud Intelligence Dashboardsをデプロイすれば、すぐに利用できます。しかし、ダッシュボードをカスタマイズできると言いましたね。そこで、カスタマイズして構築できるものの一例をお見せしましょう。 プロダクトオーナーとして、CUDOSダッシュボードをデプロイし、カスタマイズしました。可能性の一端をお見せします。
ここに追加のタブを作成しました。 ビジネスユニットコストです。QuickSightに日次のトランザクション数を取り込みました。例えば、FinTech事業を行っているとして、 収益をもたらすトランザクションを処理しています。そして、日次のトランザクションと日次のAWS支出を結合することで、同じビジュアルでコストとトランザクション数の両方を確認できます。ここで、ある時点でビジネスが成長していますが、コストは抑制されていることがわかります。これは最適化の努力の結果かもしれませんし、他の要因かもしれません。しかし、これは私たちのビジネスにとって何を意味するのでしょうか？
では、トランザクションあたりのインフラコストも計算できるようになりました。これにより、最適化の取り組みが実際にトランザクションあたりのコストを平均以下に抑えるのに役立っていることがわかります。さらに、予測を立てて、これらのユースケースを拡張することもできます。これが、Cloud Intelligence Dashboardsでできることであり、組織内のあらゆるステークホルダーのビジネスニーズに合わせてダッシュボードを調整できるのです。これは非常に強力です。ここで、Dolbyにおける FinOps の導入と、Cloud Intelligence Dashboardsが運用の改善やワークロードのアーキテクチャの改善にどのように役立っているかについて、Mikeに話してもらいたいと思います。
DolbyにおけるCloud Intelligence Dashboardsの導入と効果
ありがとう、Yuriy。先ほど申し上げたように、私はMike Graffです。Dolby Laboratoriesのリードインフラストラクチャアーキテクトを務めています。Dolbyをご存じない方のために説明しますと、私たちは約60年前に先駆的な冒険家Ray Dolbyによって設立されたエンターテインメント技術企業です。Ray が1965年にDolbyを設立した当時、映画やテレビは1チャンネルの音声しかありませんでした。そしてレコードプロデューサーは、ほんの数トラックの音声しか持っていませんでした。それ以来、エンターテインメントの音を改善するために起こったことの多くは、Rayに直接さかのぼることができます。彼の技術革新だけでなく、アーティストに与えた影響も含めてです。
設立以来、私たちのミッションは、革新的な研究と工学によって視聴覚の科学を革命的に変えることでした。私たちはクリエイターに物語を高める力を与え、ファンに忘れられない体験を提供しています。私たちのイノベーションの歴史は1960年代に始まりました。カセットプレーヤーを覚えている方なら、そこにあった小さなDolbyボタンを覚えているかもしれません。そのボタンを押すと、テープの音が素晴らしくなりました。覚えていない若い方は、隣の人に聞いてみてください。そして80年代には、映画体験を大幅に向上させたDolby Surroundを発表しました。そして今日も、Dolby AtmosとDolby Visionという画期的な技術で、高品質なエンターテインメントの基準を設定し続けています。
Dolbyは3年以上にわたってCost Intelligence Dashboardsを使用しており、最初の導入ではYuriyが先ほど話していたCUDOSダッシュボードに焦点を当てました。CUDOSは、私たちが好む最上位レベルの支出の可視化を幅広く提供し、さらにYuriyが先ほどデモンストレーションしたように、特定のサービス領域やリソースを深く掘り下げる機能も備えていると感じました。そして最も重要なのは、ユーザーがそのデータをセルフサービスで利用できることでした。彼らは自分で必要な情報を取得し、興味のある部分だけを見て、残りをフィルタリングできます。最後に、CUDOSは利用可能な豊富な可視化機能により、ダッシュボードをカスタマイズする能力を私たちに与えてくれました。現時点では、実際に複数のカスタマイズされたCUDOSバージョンを環境内に展開し、異なるサービスチーム向けにターゲットを絞っています。彼らは基本的に興味のあるタブを持ち、残りを削除できます。
CUDOSや他のダッシュボードへのアクセスをどのように提供しているのでしょうか？私たちはすでにAWS Identity Centerユーザーで、AWS ConsoleへのSSOアクセスを提供していました。QuickSightとIdentity Centerの統合により、非常に簡単になりました。基本的に、ユーザーをActive Directoryグループに追加するだけで、AWS SSO ConsoleにQuickSightボタンが表示されるようになります。これにより、支払いアカウントへのコンソールアクセスを与えることなく、QuickSightへのアクセスを提供できるようになりました。これは避けたいことでした。さらに、Yuriyが話したロールレベルのセキュリティについてですが、基本的にロールレベルのセキュリティを使用してユーザーがアクセスできるデータを制御できます。AWSアカウントをQuickSightのグループにマッピングし、そのQuickSightグループにユーザーを割り当てます。そうすることで、ログイン時にアクセス権のあるアカウントのコストデータのみが表示されるようになります。
これらの機能により、Dolby内の数十の異なるクラウドチームにこのサービスを拡大することができました。現在、約100人のファイナンスおよびエンジニアリング担当者が毎日これらのダッシュボードを活用しています。では、どのようにしてこれらを周知しているのでしょうか？
新しいクラウドユーザーのオリエンテーションにダッシュボードを含めています。クラウドアカウントが付与されると、これらのダッシュボードの内容と活用方法について研修を行います。さらに、新しいダッシュボードや既存ダッシュボードの新機能は、私が作成する社内クラウド開発コミュニティのメールニュースレターや、この情報を掲載するTeamsチャンネルを通じて展開しています。最後に、Cloud Center of Excellenceを通じて、ダッシュボードへのアクセス方法、使用方法、最大限に活用するための調整方法を説明する一連のセルフペーストレーニングビデオを作成しました。
導入方法と使用方法についてお話ししましたので、これらのツールをエンジニアリングチームに提供することでどのようなメリットが得られたかの例をいくつか紹介させていただきます。まず最初に取り上げたいのは、インターネットデータ転送です。これはアカウント関係者にとってしばしば大きな懸念の種となりますが、AWSのコストの中でも最も不透明な領域の1つでもあります。Cost Intelligence Dashboardのデータ転送可視化機能を使用することで、ユーザーは転送タイプ別のデータ転送コストを確認したり、データ転送支出の具体的な詳細を掘り下げて調べたりすることができます。多くの場合、環境のアーキテクチャ改善点を見つけるのに役立ちます。そこで、その一例をお話しします。
Amazon EC2上でDatabricksを使用しているチームがありました。ご想像の通り、Amazon S3にデータを送信する際に大量のデータ転送が発生します。ご存知かもしれませんが、EC2からS3にデータを送信する際、デフォルトではパブリックインターネットを経由してパブリックS3エンドポイントにアクセスします。少量のデータ転送であれば気づかないかもしれませんが、このチームのように大量のデータを転送する場合、月額7,000ドルものNATゲートウェイ料金が発生してしまいました。
では、どのように解決したのでしょうか？AWSが提供するAmazon S3ゲートウェイエンドポイントというコンストラクトを導入しました。これは基本的にVPC内にネットワークエンドポイントを配置し、S3との間のすべてのトラフィックをパブリックインターネットではなく、そのエンドポイントにルーティングするものです。つまり、VPC内に留まるわけです。パブリックインターネットを経由しないためより安全で、通常は高速、そして大幅にコストを抑えることができます。この場合、5分の設定変更で年間84,000ドルのコスト削減を実現しました。
次に、AZ間トラフィックについて話しましょう。通常、インターネットトラフィックほどコストに大きな影響はありませんが、それでも注意すべき点です。 一部のアーキテクチャでは、AZ間トラフィックは予想され、正常なものです。例えば、複数のアベイラビリティゾーンにまたがってKubernetesクラスターをデプロイしている場合、そこでアクティビティが発生するのは当然です。しかし、AZ間トラフィックが不適切なアーキテクチャや設定ミスの兆候である場合もあります。私たちのケースでは、あるチームがNATゲートウェイをデプロイしていました。
彼らは優良なAWSカスタマーとして、高可用性を確保するためにNATゲートウェイを2つ、各アベイラビリティゾーンに1つずつデプロイしていました。各アベイラビリティゾーン用のルートテーブルがあり、それぞれのNATゲートウェイを指していました。しかし、おっと、2つ目のNATゲートウェイが1つ目と同じAZにデプロイされてしまいました。つまり、AZ2からのすべてのトラフィックをAZ1にあるNATゲートウェイに送るルートテーブルができてしまったのです。意図は良かったのですが、 結果は意図したものとは少し違ってしまいました。
では、どう修正すればいいでしょうか？AZ1にある2つ目のNATゲートウェイを削除し、AZ2に新しいNATゲートウェイをデプロイし、ルートテーブルを更新します。これは10分ほどで修正できますが、 大幅なコスト削減につながる可能性があります。 最後に、ダッシュボードをベストプラクティス推進にどう活用できるかについてお話しします。Yuriyさんは、KPIダッシュボードとgp3ボリュームについて話しました。gp3は2020年のre:Inventで発表されましたが、基本的にgp2と同じパフォーマンスを得られながら、通常20%低いコストでgp3ボリュームを使用できます。変更は簡単で、設定を変えるだけで、バックグラウンドでライブ更新されます。
しかし、まだ実際に変更を行っていない一部のチームでは採用率が低いことがわかりました。そこで、KPIダッシュボードを活用してこの変更を促進することにしました。Yuriyさんが話したように、すべてのチームのボリュームの少なくとも80%をgp3にするという目標を設定しました。そして、KPIダッシュボードの可視化機能を使って、変更した場合にどれだけの金額を節約できるか、個々のボリュームベースでどれだけ節約できるかを正確に示すことができました。これを利用して、クラウドチーム間の競争、ゲーミフィケーションの取り組みを推進しました。下のスクリーンショットを見ると、Team Aは素晴らしい成績で、ボリュームの98%がgp3になっています。Team Bはまだ少し改善の余地がありますね。
では、Dolbyでは次にダッシュボードをどのように活用していくのでしょうか？私たちはIT部門内で、自社のワークロードに対する適切なサイジングの議論を促進するために、Compute Optimizer Dashboardを使用してきました。そして、先ほど話したマーケティング的なアプローチ、つまり人々に教育し、ビデオを作成し、宣伝することで、Dolbyの残りのチームにもこれを広げていく計画です。このダッシュボードを直接エンジニアの手に渡すことで、彼らが自分たちのコンピューティングワークロードを改善できる具体的な領域を見つけやすくなると考えています。具体的なインスタンスの適切なサイジングの推奨事項を得て、それらの変更を実施した場合にどれだけの金額を節約できるかを正確に把握できるのです。
さらに、ほとんどの企業と同様に、Dolbyは持続可能性に非常に注力しています。クラウドで稼働する部分が増えるにつれ、そのワークロードの炭素排出量を理解したいと考えています。現在、ネイティブのAWSコンソールにある炭素排出量ツールの機能はやや限られており、私はその製品チームに多くのフィードバックを提供してきました。そのため、持続可能性ダッシュボードを試して、持続可能性に関する議論にどのように役立つかを確認したいと思っています。繰り返しになりますが、エンジニアの手に委ねるのです。先日のFinOpsミーティングで何人かと話しましたが、エンジニアは時としてコストよりも持続可能性を重視することがあると思います。なぜなら、コストは結局のところ会社のお金ですが、私たちには子供がいて、家族がいて、未来を望んでいるからです。ですから、持続可能性は今後のFinOpsの議論を大きく動かすことになると思います。
コスト意識の高い文化への移行戦略
以上が私の話です。皆さんにとって有用で、自分の環境に持ち帰れるものがあったことを願っています。では、Yuriyに戻します。
ありがとう、Mike。Cloud Intelligence Dashboardsを使えば、データ駆動型の意思決定のための協調的な環境を構築し、組織内のあらゆるステークホルダーと共有することができます。そして、彼らはそれをビジネスニーズに合わせてカスタマイズし調整することができます。Mikeが示した例からもわかるように、コストの可視化によって、高可用性やパフォーマンスなど様々な面で最適化の機会を特定し、アーキテクチャをより良いものに改善することができます。つまり、Cloud Intelligence Dashboardsを使えば、組織をコスト意識の高い文化へと導く次のステップに備えることができるのです。
ここで少し時間を取って、組織をコスト意識の高い文化に導くための次のステップについて議論したいと思います。Mike、あなたはどう思いますか？
そうですね、私が今話したように、これらのダッシュボードを直接エンジニアの手に委ねることで、彼らの設計上の決定がコストにどのように影響するかを理解するのに役立つものになると思います。つまり、単に事後的なものではなく、より積極的に、自分たちの決定がどのように影響しているかをすぐに確認できるようになるのです。そして、あなたが話したように、FinOpsのレビューをアプリケーションのライフサイクルの一部にすることです。それは包括的なプロセスの一部であり、単に事後的に行われるものではありません。J.R.、あなたはどう思いますか？
サステナビリティのテーマについてもう少し掘り下げたいと思います。今年のトレンドとして、特にカーボンデータをFinOpsの考慮事項に取り入れる動きが見られました。エンジニアリングとファイナンスが協力してビジネス成果を達成するという点も素晴らしい例です。これはコスト削減だけの話ではありません。多くの場合、カーボン排出量、コスト、納期を並べて測定し、比較検討する必要があります。昨晩、foundationのミートアップで話をしました。ちなみに昨晩のことで、何日も前のことではありません。re:Inventでは時間が飛ぶように過ぎていきますね。
HSBCのNatalie Daleyと話をしていたのですが、彼女は自社の取り組みにカーボンを統合し、デプロイ時にエンジニアにコスト影響とカーボン影響の感覚を与えようとしているそうです。そうですね、多くの場合、エンジニアリングチームのモチベーションが高まっています。もう一つ興味深い側面は、一部のチームで非常に高度な最適化プラクティスが行われているにもかかわらず、組織内にそのスキルセットやノウハウがあるのに、新しい製品機能の開発に注力するあまり、他のチームにはそれが適用されていないことがあるということです。
Yuriyは、エンジニアやファイナンスの手元にデータを届ける方法や、focusのようなツールが共通の用語を整理しようとしている点について多く語りました。最も効果的なのは、そのデータを適切な形式で提供し、全員がそれについて話す方法を教育することで、自分たちで意思決定ができるようにすることです。Cloud FinOps本の共著者であるMike Fullerは、Atlassianでのfinops運用について、ファイナンスチームとエンジニアリングチームの前に適切なデータを置き、自分がその場にいなくても彼らが自分たちで状況について話し合えるようになったときに最も成功を感じたと言っていました。多くの場合、中央のFinOpsチームが存在しますが、それは支援的な役割です。
リーダーシップの点は非常に重要です。先ほど述べたように、リーダーシップのサポートを必ずしもエンジニアリングで作り出せるわけではありません。組織や経済の適切な要因が揃うのを待つ必要があります。しかし、適切なレポーティングと戦術で組織を成功に導く体制を整えることはできます。これは成功事例や成果について語っています。
あなたの話から感じ取ったテーマの一つは、エンジニア間でゲーミフィケーションを行ったり、適切な人々にデータを提供したりすることについて多く語っていたことです。ここには内部マーケティングの大きな側面があります。プラクティスやベストプラクティスの構築を支援し、普及させるだけでなく、「このチームはコスト削減を実現した」「より効率的になった」「カーボンを改善した」といったことに人々を興奮させる必要があります。単に「新機能をリリースした」や「このチームはレイテンシーを削減した」といった通常の成果だけでなく。それらも重要で不可欠ですが、コスト面での成果も称賛する必要があります。
エンジニアリングリーダーシップのサポートを得るための重要な部分は、CTOやCIOに「そうだね、これは今やあなたの仕事の重要な部分だ。そして、組織のレビューに取り入れて、ダッシュボードやメトリクスがコストだけでなく、他のすべてを反映していることを確認しよう」と言ってもらうことです。私の立場から付け加えると、最初に述べたことを振り返って、FinOpsのメトリクスをエンジニアがレビューし追跡する、ただの別の運用メトリクスとして扱うことです。実際にFinOpsの機会を探すためのツールと適切な可視性を提供し、最適化できるリソースと共にこれらの最適化の機会を彼らの目の前に置くことで支援します。これにより、レビューの労力を最小限に抑えつつ、最適化に向けたアクションを取る時間をより多く与えることができます。
まとめと今後の展望
次は何でしょうか？皆さんにCloud Intelligence Dashboardsをデプロイし、自分の環境で試してみて、コスト意識の文化に入っていただきたいと思います。その上で何かを構築したい場合は、ダッシュボードのカスタマイズ方法、ビジネスユニットのコストビューやビジュアルの作成方法を学び、そして構築したものを私たちに見せていただければと思います。皆さんのフィードバックをお聞きし、Cloud Intelligence Dashboardsを使ってどのように拡大した使用量を最適化し、FinOpsフレームワークに入ることができたかをお聞かせいただければ幸いです。
ありがとうございました。ここのステーション近くで質問をお受けしたいと思います。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion