re:Invent 2023: AWSとMuleSoftが語るWell-Architected活用と1200万ドルのコスト削減
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Scaling AWS Well-Architected best practices across your organization (ARC216)
この動画では、AWS Well-Architected ToolとFrameworkの活用方法を学べます。AWSのSamir KopalとIlana Morrisが、クラウドでの運用と管理を体系化する方法を紹介します。MuleSoftのMelissa Cazaletは、Well-Architectedを活用して1200万ドルのコスト削減を実現した事例を共有。40万台のEC2インスタンスへのライブパッチ適用や、Cloud Centralポータルでの日次コスト分析など、具体的な取り組みが紹介されています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS Well-Architected FrameworkとToolの誕生
きっと皆さんも、ベストプラクティスに従いたい、コスト効率が高く信頼性のあるシステムを構築したいと思いながらも、圧倒されたり混乱したり複雑に感じたりした経験があるでしょう。そんな時、解決策があるとしたらどうでしょうか？それが AWS Well-Architected Tool とフレームワークなのです。これらは、クラウドでの運用と管理の方法を体系化するのに本当に役立ちます。私は Samir Kopal です。同僚の Ilana Morris とともに、この旅にご案内します。では、始めましょう。
まず、Well-Architected の歴史について話しましょう。 Well-Architected はどこから来たのでしょうか？なぜ生まれたのでしょうか？2012年、私たちの人気サービスの1つでイベントが発生しました。残念ながら、一部のお客様に影響がありました。私たちは標準的な質問をしました。「誰が影響を受けたのか？何が起こったのか？どうすれば再発を防げるのか？」しかし、ある重要な質問がありました。「誰が影響を受けなかったのか？」これにより、システムに適切な冗長性を持っていた特定のお客様がこのイベントに対して耐性があったことがわかりました。
私たちは、これらの学びを他の皆さんと共有する必要性を認識しました。AWSとしての学びと、お客様からの学びがありました。そこで、ソリューションアーキテクトのグループを集めて、「何ができるだろうか？」と問いかけました。彼らが考え出したのが、現在 AWS Well-Architected Framework として知られているものです。2012年、これはホワイトペーパーとして発表されました。私たちはこのフレームワークを使って、これらのベストプラクティスについてお客様を教育し始めました。当時は4つのピラーがありました：セキュリティ、コスト最適化、パフォーマンス効率、信頼性です。
Well-Architected Frameworkの進化とLens Catalogの導入
これらのレビューを行い、お客様と話をする中で、アーキテクチャは孤立して機能するものではないことがわかりました。それと一緒に必要だったのは、人とプロセスでした。これが2016年に運用上の優秀性ピラーの導入につながりました。私たちのソリューションアーキテクトとアカウントチームは、これをお客様と一緒に使い始めました。また、進捗を文書化し測定する必要性も認識しました。そこで、ちょうど5年前の今日、2018年に AWS Well-Architected Tool が発表されました。AWS Well-Architected Tool、5歳の誕生日おめでとう！
私たちはフィードバックに基づいてツールの進化を続けました。最大の変更の1つは、ノートフィールドのサイズを大きくしたことでした。当時エンジニアリングリーダーだった私は、なぜ人々が自動化や他のものではなく、この機能を望んでいたのか不思議に思いました。その考えは覚えておいてください、後で戻ってきます。今日の環境では、アーキテクチャを設計し構築する際にサステナビリティを考慮することが非常に重要です。そのため、2021年にサステナビリティピラーを導入しました。
私たちは、新しいコンテンツやベストプラクティスが登場するたびに、さらに多くの機能を追加し続けています。クラウドに対する顧客の成熟度が高まるにつれて、必要とされるガイダンスも変化しています。フレームワークを継続的に進化させており、新しいコンテンツを含む新バージョンがまもなく登場します。後ほどのセッションで詳しく見ていきますが、統合ビューを確認する機能を追加しました。これらのベストプラクティスをスケールさせる方法を体験していただけるでしょう。
また、今週初めに「Lens Catalog」という新機能をリリースしたことを大変嬉しく思います。クラウドの状況が進化するにつれて、基本的なベストプラクティスだけでなく、業界や技術に特化した深い洞察の重要性が明らかになってきました。Lens Catalogでは、規制の厳しいヘルスケア業界におけるコンプライアンスを扱うヘルスケア業界レンズなど、さまざまなレンズを導入しています。コンプライアンスがアーキテクチャにどのような影響を与えるかをより深く掘り下げることができます。
Well-Architected Frameworkの構造と質問アプローチ
さて、AWS Well-Architected Frameworkとは何かについてお話ししましょう。私たちが確認したかったのは、顧客がこのコンテンツをどのように消化するかということです。考えてみてください。すべてのベストプラクティスが1ページにまとまっていたら素晴らしいと思う人はいますか？手を挙げている方がいますね。素晴らしいです。ただし、私たちはこれらを分類することを確実にしたかったのです。そこで、ピラーが適切な方法となりました。なぜピラーなのでしょうか？
組織を見てみると、セキュリティ、運用、予算などを担当するチームがあります。これらのピラーが重要になったのは、私たちがまとめたこれらのカテゴリーでコンテンツを消化できるようになったからです。ピラーには設計原則と呼ばれるサブカテゴリーがあります。例えば、観測可能性は詳細な概念を深く掘り下げる設計原則の1つです。また、セキュリティに関しては、インシデント対応やアイデンティティとアクセス管理もあります。これらの設計原則により、意味のある方法でコンテンツを消化することができます。
ここで「なぜ質問なのか？」と思われるかもしれません。Well-Architectedを会話にしたいからです。これは監査やチェックリストではありません。監査やチェックリストでは、同じ間違いを繰り返してしまう傾向があります。質問を使うことで、実際にチームを教育しているのです。私自身が助けられた質問の例を挙げましょう。Well-Architected Toolを構築していたとき、Well-Architected reviewを行うことにしました。Well-Architected Frameworkのエンジニアリングマネージャーとして、自分のシステムにはハイリスクはないだろうと思っていました。しかし、実際はそうではありませんでした。
私たちの会話の中で、「なぜリソースに名前をつけるのか？」という質問が出ました。私はその理由を知らないことに気づきました。そこで、自動命名を採用すればリソースをより適切に管理できるという結論に至りました。これを実装したところ、デプロイと保守が容易になり、リソース名の入力ミスや問題がなくなりました。これらは通常、コードレビューやデザインレビューでは出てこない事柄です。フレームワークは、このような重要な質問を促す会話を構築するように設計されています。そして、もちろんフレームワークの核心は、何をすべきか、どのようにすべきかを詳述するベストプラクティスです。
AWS Well-Architected Toolの機能と利点
AWS Well-Architected Toolについて話しましょう。フレームワークができた後、これらの事項をどのように追跡し、進捗を測定し、一貫した採用を確保するかを決める必要がありました。このツールは、質問とベストプラクティスを通じてリスクを特定するのに役立ちます。ベストプラクティスに従っているかどうかをチェックし、AWS Trusted Advisorチェックを通じて、リソース固有の情報を赤、黄、緑のステータス指標で提供するガイダンスが利用可能です。
このツールのもう一つの重要な機能は、決定事項とトレードオフを文書化する能力です。「なぜこの決定をしたのか？」と誰かが尋ね、「わかりません、これは3年前のことです」や「その決定をした人はもうここで働いていません」という回答があった会議に参加したことがある人はどれくらいいますか？Well-Architectedレビューを使えば、これらの決定を文書化し、将来の決定のための歴史的コンテキストを提供できるようになりました。これが、ツールのノートフィールドがとても重要だった理由です。
Well-Architected Toolは、ワークロードの健全性を追跡し改善することもできます。セキュリティ態勢やコスト管理について曖昧な回答をするのではなく、これらの側面を測定する方法が得られました。会話はより構造化され、「リスクに対処しましたか？プログラムによってリソースへのアクセスを管理していることは確実ですか？キーをローテーションしていますか？多要素認証を有効にしていますか？」といった具体的な質問に焦点を当てるようになりました。このツールの価値は、曖昧な議論から具体的で実行可能な洞察へと移行し、すべてのワークロードにわたって改善し、一貫して測定する能力にあります。コンテンツとツールが、すべてのワークロードにわたって何をするかについて触れてきました。
データ駆動型の意思決定とWell-Architectedメカニズム
しかし、それがもたらすのはデータです。私たちはみな、Amazonがデータ駆動型の企業であることを知っています。そのため、データを非常に重視しています。これらのトレードオフの決定、特定したリスク、そして実際に改善するための改善計画があれば、これらが一緒になったときにデータを使って情報に基づいた決定を下すことができます。
このツールがなかった頃のことを思い出してください。「これをやっているのか、やっていないのか」と尋ねていましたが、ポートフォリオ全体を見渡す人はいませんでした。データがあれば、それが可能になります。IT リーダーとして、データを見て「セキュリティリスクが全体的に存在することがわかりました。セキュリティキャンペーンを実施できますか？ お金を使いすぎています。ここで最適化できますか？ アーキテクチャを見直せますか？」と言えるようになります。これらの決定は、今やデータに基づいて行われるのです。
コンテンツ、ツール、そしてデータを組み合わせると、私が Well-Architected メカニズムと呼ぶものが得られます。今日の続きで、それが実際にどのようにスケールするかについて詳しく学びます。Well-Architected メカニズムを使えば、クラウドリソースをより構造化され、効率的な方法で管理・統制できるようになります。チームがワークロードの健全性を学び、測定し、改善することを可能にします。もはや「ワークロードの調子はどうですか？」という会話ではありません。医者に行ったときのことを考えてみてください。医者は単に「調子はどうですか？」や「気分は大丈夫ですか？」とは聞きません。診断を行い、「ここに問題があるようですね」と言います。
これらのデータ駆動型の会話が重要になるのは、推奨リソースに基づいているからです。AWS は AWS 内のイベント、お客様との経験、そして新機能のリリースからこれらのことを学んでいます。ベストプラクティスは常に変化する風景であり、このツールがその状況を把握する方法なのです。
では、実際にどのようにスケールするのか、その方法について Ilana に説明してもらいましょう。Ilana、お願いします。
組織全体でのWell-Architectedの標準化と課題
ありがとうございます。実際に「どのように」という話に入る前に、少し立ち戻って、お客様が何を考えているかを考えてみたいと思います。セッションの冒頭で見たビデオを思い出すと、コンプライアンスレポート、CCOE レポート、セキュリティレポートなど、さまざまな場所で追跡されているものについて話していました。私たちがよく受ける質問の一つは、「これらのベストプラクティスを組織全体でどのように標準化すればよいのか？」というものです。
私たちはまた、「ビジネスのコンテキストをレビューにどのように取り入れればよいでしょうか？エンジニアリングチームや開発チームが適切な成果とビジネスニーズに焦点を当てていることをどのように確認すればよいでしょうか？」といった質問を受けます。そして、「Well-Architected Toolのアーキテクチャのベストプラクティスだけでなく、社内のベストプラクティスにも従っていることをどのように確認すればよいでしょうか？」コンプライアンスや社内のセキュリティニーズなどについてです。これらはすべて、お客様が気にしていることであり、本日は、Well-Architected Toolを使用してこれらの質問にどのように答えることができるかをご説明します。
まず、AWS Management ConsoleでWell-Architected Toolを見つけることができます。ワークロードを定義することから始めます。 ワークロードを定義する際、ワークロードに関するメタデータをいくつか入力します。ワークロードの名前、説明、レビューする人、そしてレビューするワークロードのタイプに関するその他の情報をお聞きします。ワークロードを定義する際、少し後でアカウントIDやワークロードが実行されるアプリケーションIDを入力することができます。
Review TemplatesとLens Catalogによるスケーリング
これは重要です。なぜなら、これらのアカウント番号を使用してAWS Trusted Advisorをアクティブ化できるからです。Trusted Advisorをアクティブ化すると、レビューを開始した後、 リソースレベルのチェックを取り込み、AWS Well-Architectedのベストプラクティスと比較し、そのベストプラクティスに従っているかどうかを判断するための証拠を表示します。
私はすでにワークロードを定義しています。 ワークロードに入ると、先ほど説明したすべてのメタデータがWorkload Propertiesセクションに表示されているのがわかります。ベストプラクティスのレビューを開始する準備ができたら、Continue Reviewingをクリックして質問に答え始めることができます。
この会話をしているときに、お客様からよく聞かれるのは、「これをどのようにスケールさせるのか？」ということです。私たちには、クラウドで数千のワークロードを運用している大企業のお客様や、スケールアップしているお客様がいます。彼らは多くのデータを使用したいと考えています。例えば、認証と認可が組み込まれたセキュリティプラットフォームがあり、これがすべてのワークロードに適用されます。
このスケーリングの課題に対処するため、Review Templatesという機能があります。この機能は、さまざまな質問に回答を事前に入力できるテンプレートの作成を支援します。私はすでに、Well-Architected Framework、社内コンプライアンスのベストプラクティス用のカスタムレンズ、そしてSaaSレンズを含むレビューテンプレートを作成しました。
特に、SaaSレンズについては今週初めに公開したLens Catalogから来ているので、とてもワクワクしています。 このLens Catalogは、さまざまな業界や技術分野にわたる多様なレンズのコレクションです。先ほどヘルスケアレンズについて話しましたが、ご覧のように、サーバーレスレンズ、IoT、データレンズもあります。 これらはより具体的なトピックで、あなたのワークロードに最も関連性の高いものです。これにより、レビューをさらにカスタマイズすることができます。Well-Architected Frameworkを使用したWell-Architectedレビューを、含めたいカスタムベストプラクティスや、このカタログからの追加のレンズと共に行うことができるようになりました。 この機能は現在利用可能で、今週初めにリリースされました。
プロファイルを活用した優先順位付けとリスク管理
では、レビューテンプレートの質問にどのように回答するかをお見せしましょう。Well-Architected Frameworkについては、 ワークロードを定義する際のWell-Architectedレビューと非常によく似た体験になります。私はすでに運用上の優秀性の柱からいくつかの質問に回答しています。これらは、エンジニアリングチームが心配する必要のないベストプラクティスです。すでに対処されているからです。また、これらのベストプラクティスが選択された理由の文脈を提供するためにメモを追加することもできます。
このレビューテンプレートを共有したい場合は、Sharesセクションに移動します。 ここで、個別のアカウントまたはAWS組織とレビューテンプレートを共有できます。これにより、レビューテンプレートにアクセスできる人なら誰でも、そのテンプレートからワークロードを定義し、ベースラインからレビューを開始できます。一部の質問にはすでに回答が入力されているので、彼らは自分のワークロードに特有の部分に集中できます。
レビューテンプレートが既に添付されているワークロードに移動すると、私のレビューテンプレートにあった回答と同じものが 実際のワークロードにすでに入力されているのが分かります。これにより一貫性が促進され、チームが推測する必要がなくなります。このテンプレートを使用するすべてのワークロードで同じ回答を提供する責任を持つチームがいるのです。
このアプローチにより、中央チームは一貫したベストプラクティスを拡張できます。しかし、エンジニアとして、常にバランスを取るべき要件があることを理解しています。非機能要件、プロダクトマネージャーが設定する機能のデッドライン、コンプライアンスのニーズ、そして運用のベストプラクティスに従う必要があります。課題は、ワークロード全体で一貫性を維持しながら、これらすべての側面を効果的に管理することです。
ポートフォリオ全体のリスク管理と改善
私のエンジニアたちは通常、「どれを最初にやればいいですか？」と私に尋ねます。それに対する答えはありますか？
はい、あります。そしてこの質問をされると予想していました。開発ライフサイクルの異なる時点で、異なる優先事項に焦点を当てる必要があることは分かっています。新しい製品やサービスを立ち上げる場合、コストよりもセキュリティに重点を置きたいかもしれません。では、任意の時点でのワークロードレビューで最も重要なことを、実際にどのように優先順位付けするのでしょうか？答えは、プロファイルです。
プロファイルを使用すると、ワークロードレビューを行う際に、任意の時点で実際に重要なことにビジネスコンテキストを提供できます。クラウド導入の進捗状況、このワークロードが表すビジネス価値、現時点で最も重要な改善点などに関する短い質問リストに答えることができます。プロファイルを作成し、アクセスが必要な人と共有できます。
エンジニアリングチームが注力すべき優先事項を知る必要があるという話をしました。素晴らしいですね。プロファイルを作成し、それを彼らと共有します。そして彼らができることは、ワークロードに戻ってそのプロファイルを添付することです。これにより、注力すべき質問のリストが優先順位付けされます。Well-Architectedレビューに戻ると、優先順位付けされたリストを提供する特定のセクションが表示されます。
MuleSoftのWell-Architected導入事例：コスト削減から戦略的アプローチへ
さて、これで分かりましたね。私が添付したプロファイルに基づいて、今50の質問に集中する必要があります。これらの50の質問のうち、いくつかはレビューテンプレートによってすでに回答されています。つまり、エンジニアにとって一般的なベストプラクティスの一部がすでに記入されており、推測作業が省かれています。そして、あなたとビジネスにとって重要なことに基づいて、何に焦点を当てるべきかが分かります。なぜなら、そのプロファイルがあなたのワークロードに追加されたからです。
これは今のところ完璧です。ここで、リーダーシップが望むことと、実際にそれを実装する方法とを結びつけることができます。先ほど話したセキュリティキャンペーンのようなビジネスコンテキストを取り上げることができます。チームにセキュリティに焦点を当ててほしいとします。それはコンプライアンスに必要であり、監査に必要であり、特別な注意を払いたいものです。このプロファイルに記入して、セキュリティを最優先事項として特定し、これが適用されるすべてのワークロードと共有します。そうすることで、エンジニアチームに取り組んでほしい一連の事項の優先順位を付けたことになります。
これは素晴らしいですね。ここで一つ重要なのは、質問の優先順位を付けましたが、彼らはどうやって何に取り組むべきか知るのでしょうか？
そうですね、最も重要な部分です。実際に改善が行われることを確認したいですね。ここでご覧いただけるように、全体的なリスクがあります。これはワークロードレビューからのすべてのリスクです。しかし、優先順位付けされた質問に加えて、優先順位付けされたリスクも提供しています。つまり、18のリスクのうち、最初に本当に焦点を当てるべき12のリスクが分かるのです。
ここで重要なのは、プロファイルが「他のリスクに焦点を当てるな」とか「他の質問に焦点を当てるな」と言っているわけではないということです。それは、どこに最初に焦点を当てるべきかについて、優先順位付けされた決定を実際に行うのを助けているのです。つまり、「よし、これら12のリスクに焦点を当て、それを達成し、プロファイルの目標に合わせ、そして他のリスクにも戻って対処しよう」と分かるのです。
さて、エンジニアたちは今、「これらすべてをやるべきだ」というアプローチから、「ローンチに向けて取り組むべき10の項目がここにある」というアプローチに移行し始めています。そしてそれをマイルストーンとして保存しています。では、cloud center of excellenceのペルソナに戻りましょう。ここでポートフォリオビューを見ていますが、これはDevOpsエンジニアやエンジニアが適切な優先順位で作業を始められるワークロードには最適です。しかし、ポートフォリオを管理する中央チームとしては、どうでしょうか。先ほどの素晴らしい動画でご覧いただいたように、大規模なポートフォリオがあります。これをどう管理すればいいのでしょうか？1つのワークロードならうまくいきますが、マクロレベルでの全体像を見たいものです。
そう言っていただいて嬉しいです。お見せしたいと思います。 ポートフォリオ内のすべてのワークロードにわたるリスクを一目で確認できる統合ビューがあります。ここでは4つのワークロードがあり、 「ほとんどのリスクがセキュリティにある」ということがわかります。では、これは実際には何を意味するのでしょうか？どのように行動すればいいのでしょうか？ なぜセキュリティが全ワークロードの中で最もリスクが高いのでしょうか？
下にスクロールすると、「セキュリティピラーのサービスとアプリケーションのロギングを設定すれば、4つのワークロードのうち2つに適用される」ということがわかります。つまり、1回の改善で2つのワークロードに適用できるため、効率が上がるということです。このダッシュボードは、ポートフォリオ全体にわたって「リスクがどこにあり、どこに努力を集中すべきか」というマクロレベルの視点を提供します。
これは素晴らしいですね。リソースのスケーリングも同時に行えます。単に「ポートフォリオビューができました」というだけでなく、これを見て「組織全体でのリスクはどこにあるのか」を把握できます。
そして、それを見ると、4つ、6つ、8つ、10つ、あるいは何千ものワークロードに影響を与えるような対策があることに気づき始めます。それが優先事項となります。そこで小さなチームを作って、他の人のためにこの問題に取り組むことができます。アーキテクチャを構築したり、ツールを開発したりすることができます。
これは先ほどお話しした「データの側面」です。このデータは意思決定を行う上で重要になります。1つのワークロードや、2つ、あるいは自分が知っているチームだけに基づいて決定を下すのではありません。より広い視野で組織全体を見渡し、「どうすればよりコスト効率が良く、よりセキュアにスケールできるか？」あるいは「特定の項目のパフォーマンスをどう改善できるか？」を考えるのです。そして、あるワークロードで行ったことが、他のワークロードでも使用・再利用できることに気づくでしょう。これは素晴らしいことです。このような視点は非常に価値があります。
しかし、なぜ私たちの言葉を信じるべきなのでしょうか？そこで、MuleSoftとSalesforceのSoftware Engineering担当VPであるMelissa Cazaletさんをお招きして、彼らの組織がWell-Architectedをどのように活用してコスト削減を実現したかについてお話しいただきます。Melissaさん、ようこそ。
MuleSoftのクラウド運用モデルとWell-Architected Frameworkの統合
唯一足りないのは、かっこいい入場音楽ですね。昨日のキーノートで演奏していたビッグバンドに触発されて、今後のプレゼンテーションではぜひ取り入れたいと思いました。ご紹介ありがとうございます。Melissa Cazaletです。MuleSoftでソフトウェアエンジニアリングのVPを務めています。私はトラストに関するすべてを担当しています。これはSalesforceの用語で、セキュリティ、GRC、監督、サービスコスト、信頼性エンジニアリング、インシデント管理、問題管理などが含まれます。MuleSoftのセキュリティ、コンプライアンス、信頼性を確保する責任者です。私の仕事にはストレスや重圧は全くありません。冗談です。
では、MuleSoftについて少しご紹介します。MuleSoftは2006年に、ユーザーがアプリケーションとデータを簡単に統合できるようにするプロジェクトとして設立されました。2013年には、API設計、統合、セキュリティ、ガバナンスを提供する完全なライフサイクルAPI管理プラットフォームであるAnypoint Platformをリリースしました。2017年に株式公開を果たし、その1年後にSalesforceが67億ドルで買収しました。私たちは常にプラットフォームに新機能を追加しており、最近では、ロボティックプロセスオートメーション機能を追加したことを大変嬉しく思っています。これにより、従来のAPIベースの戦略が実現困難な場合でも、ユーザーが反復的なタスクやプロセスを自動化できるようになりました。
今日は、私たちのクラウド運用モデルについて詳しくお話しします。成熟したクラウド運用モデルを持つことは、組織全体でWell-Architectedをスケールするために非常に重要です。これを使用することで、トップダウンでWell-Architectedの文化を構築できます。このグラフィックを見ると、クラウド導入の段階が示されています。クラウドネイティブな組織であれ、オンプレミスからクラウド移行の旅を始めた組織であれ、多くの類似した行動や能力が必要になります。
私たちが発見したことの1つは、時間をかけて構築していくと、最終的に価値の実現が停滞し、アジャイルな方法でイノベーションを続ける能力が平坦になってしまうということです。これは、2022年4月に私たちが直面した状況でした。これはさまざまな理由で起こり得ます。混乱による回復力の問題や、パッチ適用のような手動で自動化されていないタスクにリソースを大量に費やしているかもしれません。あるいは、おそらく最も一般的で、私たちに最も影響を与えたのは、クラウドの消費コストが予算を超過し始めるポイントに達することです。
私たちにとって、これが重要な転換点となりました。2022年4月、年末までに予算を1200万ドルも超過しそうだということが分かったのです。これは本当に大きな「しまった！」という瞬間でした。もちろん、このような危機的状況では何をするでしょうか？
たくさんのチームを集めて、「よし、85の新しいコスト削減イニシアチブを立ち上げよう。今やっていることは一旦止めて、これを最優先事項にしなければならない」と言います。想像できるように、これはエンジニアリングチームにとって非常に混乱を招くものでした。1200万ドルを取り戻すために、コストに対処し、これらのコスト削減プログラムをどのようにロードマップに組み込むかを考えなければなりませんでした。私たちには、これらのシグナルをより早く受け取り、エンジニアがコスト管理プロセスに関与して適切な決定を下せるようにするために必要なモニタリングと可視性が単純に欠けていたのです。
そこで私たちは、「もっとプロアクティブにならなければならない」と決心しました。幸いなことに、私たちがこの問題に直面した最初の企業ではありませんし、確実に最後の企業でもありません。AWSとの強力なパートナーシップを活用して、どのようにしてよりプロアクティブになり、Well-Architected Frameworkを基盤とするクラウド運用モデルを作成できるかを考えることができました。
2022年にこの旅を進めていく中で、私たちには今後の戦略に大きな影響を与えるいくつかの重要な学びがありました。第一に、クラウドにおけるガバナンスが極めて重要だということに気づきました。スケーリングと成長、新しいサービスの導入に対処する際、これをどのように適切に管理するかを本当に考えなければなりません。第二の領域はコスト削減についてです。ここでの重要な学びには多くの側面がありました。その1つは、これが文化的な変化だということです。コストについて異なる考え方をし、より高度でプロアクティブな決定を下すための教育を人々に施す必要があります。
私たちは、チームに正確なデータを提供する必要があることに気づきました。アクショナブルなインテリジェンスを提供し、使いやすいセルフサービスモデルであることを確認する必要がありました。難しければ、エンジニアリングチームは確実に注意を払わないからです。最後に、長期的な運用効率が、私たちが望むように前進し、イノベーションを続けるための鍵であることを学びました。これを実現するために、私たちはクラウド運用モデルをWell-Architected Frameworkに固定し、いくつかのWell-Architectedの目標を設定することにしました。
この取り組みの最初のステップは、この分野で変革を推進するチームを作ることでした。ここで私たちはMuleSoft cloud oversight engineeringチームを立ち上げました。このチームは、適切なステークホルダーと関わり、エグゼクティブリーダーシップチームから賛同を得て、Well-Architected Frameworkを進めるにあたり、すべてのチームが同じページにいることを確認するためのものでした。このチームは、product management、platform and infrastructure、engineering service teams、security and compliance、financeなどのステークホルダーと関わり、私たちが行うすべてのことと、私たちが下すすべての決定が戦略的なビジネス目標に基づいていることを確認する責任があります。
同様に重要だったのは、AWSとの強力なパートナーシップを確保することでした。彼らは、成熟したクラウド運用モデルを構築する方法を教えてくれただけでなく、前述したように、それを自動化し、使いやすくする方法も教えてくれました。そうすることで、私たちのチームが本当にそれを推進できるようになりました。
クラウド運用モデルを考える際、私たちは4つの要素からなるモデルを考案しました。これを私たちはcloud oversight engineering frameworkと呼んでいます。すべては準備から始まります。これが最初のステップで、リーダーシップの賛同を得て、適切なビジネス目標に結びついていることを確認し、チームにとって最も重要なデータを決定してそれを可視化します。次にデータ強化の段階に移ります。私たちの場合、社内でdata lakehouseを開発しました。これは、AWS Toolingからすべてのコストデータと運用データを取り込み、強化し、Cloud Centralポータルを通じてチームに可視化するという段階の基盤となるものです。
そこから行動に移ります。必要なデータを決定し、可視化してチームに提供した後、「さて、それをどう使うか？」という段階に進む必要があります。私たちの場合、Trusted Advisorの推奨事項を使用し、それをモデルに組み込んで、チームがそれらを考慮し、各推奨事項に対してアクションを取れるようにしました。そこから、「よし、これこれのことをやった。影響はどうだった？これは成功だったのか？」と考えます。成功していれば、その成果を祝います。そうでなければ、「改善の機会は何か？」と考え、このモデルを行ったり来たりします。これは本当に継続的なサイクルなのです。
クラウドオペレーティングモデルをWell-Architected Frameworkに結び付けたと言いましたね。ここにそのピラーが見えます。6つのピラーがあります。私の紹介からお分かりかと思いますが、私はWell-Architected Frameworkのほぼすべてを運用しています。そのため、すべてのピラーが重要で、それぞれに優先順位を付けるべきです。しかし、現実的には全てを同時に優先することは不可能です。
ここに、過去18ヶ月間にこれらのピラーそれぞれに該当するプロジェクトの例をいくつか挙げています。すべてのピラーで同時に成熟度を上げることはできないということを覚えておいてください。この1年間は、Well-Architected Frameworkの前半に焦点を当て、多くの目標を達成した後に他の領域に移行する予定です。
私たちにとって最も重要なのは、目標に対してどのように実行しているかです。ここに示したのは、ピラーごとに、過去18ヶ月間に大きな成功を収めた最大規模のプロジェクトの一部です。最初に挙げた1200万ドルのコストオーバーランの例に戻ると、もちろん最初に焦点を当てたピラーはコスト最適化でした。クラウドの財務管理に集中しました。データレイクハウスを作成し、AWSのコストと使用状況データをデータレイクハウスに取り込むことで、分析インフラを全面的に見直しました。また、CloudWatchの使用を大幅に増やし、チームに運用の健全性の全体像を把握させました。これは大局的な視点から物事を理解するのに不可欠でした。
8ヶ月間にわたってコスト削減の取り組みを強力に推進し、最終的に1200万ドルのコスト削減を実現しました。これは戦術的な取り組みでしたが、私たちが本当に興味があるのは、戦術的なアプローチから戦略的なアプローチへの移行です。そうすることで、リアクティブモードに陥らないようにします。次の数枚のスライドでお見せする多くの取り組みは、そこにつながるものです。
他のピラーについては、運用の優秀性の面では、パッチ適用にAWS Systems Managerを導入しました。これにより、MuleSoftの主要な収益源であるCloudHub製品上で約40万台のEC2インスタンスにライブパッチを適用できるようになりました。これは、多くのホストに対する面倒な手動プロセスを自動化しただけでなく、セキュリティ態勢も大幅に改善したため、非常に重要でした。月1回のパッチ適用に制限されていた状況から、脆弱性が発見されるたびにパッチを適用できるようになりました。これにより、顧客の信頼を高め、セキュリティSLAを達成し、非常に効果的な結果を得ることができました。
私たちは人材にも多大な投資を行い、人材とそのスキルセットに焦点を当てています。信頼性の柱では、2日間のAWS School of Resiliencyセッションに参加しました。これは素晴らしい経験でした。信頼性やレジリエンシーの向上に苦労している方や興味がある方には、ぜひお勧めします。私たちにとって、これは2日間にわたってAWSの信頼性の専門家と深く掘り下げ、自社のカスタムワークロードを持ち込み、課題について議論し、MuleSoft特有のレジリエンシーアーキテクチャとパターンをどのように改善できるかを考える機会となりました。非常に価値のある経験で、私の最も優秀な15人のアーキテクトとエンジニアがこの問題に取り組む意欲に満ちて帰ってきました。
また、すべてのエンジニアのスキルギャップを特定するために、AWS Learning Needs Analysisのアンケートも活用しています。各チームがスキルに関する長いアンケートに答えるプロセスを経て、その後AWSと協力してギャップを特定し、優先順位をつけ、どのようなコンテンツを提供してもらえるかを決定します。このプロセスに私たちは大変期待しています。
最後に、サステナビリティの柱については、まもなくエンジニアリングマネージャーに炭素消費データを提供できるようになります。これにより、パフォーマンスとサステナビリティのバランスを取ることができます。サステナビリティはSalesforceの核となる価値観の一つなので、チームにこの情報を提供できることを心から楽しみにしています。
これが私たちにとって、すべてが一つにまとまるところです。これは、MuleSoft Cloud Centralポータルで、Well-Architected Frameworkに関して今日議論してきたすべての情報を、セルフサービスモデルで1つのダッシュボードに提供しています。AWSおよびTrusted Advisorの推奨事項と協力して、すべてのデータをこの1か所にまとめました。上部には資産インベントリがあり、特定のサービスの完全な資産プロファイルと、日々のすべての関連コストの概要が表示されます。これにより、コスト消費の細かなプロセスとパターンを見ることができます。このグラフィックの各要素をクリックすると、個々の資産レベルで詳細を深く掘り下げることができ、これは本当に素晴らしく、チームに力を与えるものです。
これらのパターンにより、エンジニアリングチームは不一致を特定し、目標に対する進捗を追跡できます。下半分には、AWS Well-Architected Frameworkの6つの柱が表示されています。これらはAWS Trusted Advisorから来ており、プレゼンテーションの前半で述べたWell-Architectedの目標に特化して調整されています。
私たちはこれらの各ピラーに対して特定の目標を設定しており、チームがそれらの目標に対してどの程度うまく実行しているか、そして改善の余地がどこにあるかを示すようにこれを調整することができます。最初の列を見ると、Operational Excellenceがあります。Asset taggingは今年、私たちにとって大規模なプロジェクトでした。MuleSoftの50万の資産すべてに対して、適切なAsset taggingの100%カバレッジを確保したいと考えていました。チームはここで進捗状況や改善が必要な領域を詳しく見ることができます。SecurityとCompliance、Reliability、Performance Efficiency、そしてもちろん非常に重要なCost Optimizationなど、他のピラーをカバーする推奨事項も見ることができます。先ほど述べたように、Sustainabilityのピラーはまもなく追加される予定です。
このCloud Centralポータルは高度に自動化されています。私たちはこれにAmazon Redshiftを活用しており、さらに自動化を強化する方法についてAmazonと協力して検討しています。チャットボット用のAmazon Lexや、インテリジェント検索のためのKendraの統合、さらには検索機能をさらに洗練し強化するための大規模言語モデルの統合方法も探っています。Well-Architected Frameworkの基本を運用化し、各ピラーの実行を簡潔な場所で管理できるようになったことに、私たちは本当に興奮しています。
MuleSoftのクラウド運用モデル成熟度と継続的改善プロセス
最後のスライドは、私たちのクラウド運用モデルの成熟度図です。これらのプロセスを進めていく中で、まずはWell-Architectedの目標から始めます。これは、特定の時点でのチームの成熟度と、目指すべき方向性を示すスナップショットです。そこから、インフラストラクチャデータとTrusted AdvisorのWell-Architectedの推奨事項を追加し、チームごとにCloud Centralポータルで提供します。チームは自分たちの状況をそこで確認できます。
そこから、チームはアクションを選択し、改善を行い、組織としての成熟度向上とクラウドコストの管理に対して責任を持つことができます。次に、これらのアクションが機能したかどうか、何を改善する必要があるかを判断します。改善を行い、このチャートの金色の線に沿って次のフェーズに移ります。これは継続的なプロセスです。目標の設定、実行、改善のそれぞれのフェーズを経て、次の成熟度レベルに移行していきます。
以上です。皆様、ありがとうございました。これがMuleSoftがどのように実装したかです。繰り返しになりますが、AWSとのパートナーシップに大変感謝しており、このプロセスを本当に自動化するのに役立ちました。
Well-Architectedのインパクトとマインドセット
これはすごいですね。皆さんはどう思いますか？クールでしたか？40万インスタンスというこの数字。これは膨大です。そして、今日お話ししたいポイントがここにあります：Well-Architectedを見ると、それは構造化された会話になるのです。彼らがどのように目標を設定し、その目標が実際のアクションに変換され、そして複数のものにスケールされたかを見てください。このグラフを見てください。Melissaが発表している間、私はちょうどこのグラフを見ていました。この日次コスト分析のグラフです。エンジニアにとって、これを見るのはどれほどクールでしょうか。
私たちには、レイテンシーについて語るこのようなグラフがあります。レイテンシーが上がった、あるいはどこかでスパイクがあるといった具合です。でも、コストを見てください。これが彼らに1200万ドルの節約をもたらしたのです。本当にクールな話ですね。共有してくださってありがとうございます。最後に、Well-Architectedはマインドセットだということをお伝えしたいと思います。単なるツールでも、単なるフレームワークでもありません。組織内にメカニズムを構築するために使用するものです。信頼性が高く、安全に運用されていることを確認し、そのコストを確認し、構築しているものがどれだけ持続可能かを確認するために使用します。あなたは影響を与えていますか？
以上で終わりです。本日はお時間を割いてご参加いただき、誠にありがとうございました。ここからは質疑応答の時間とさせていただきます。何かご質問がございましたら、どうぞお聞かせください。皆様、本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion