[セッションレポート]SUP311 | Optimizing with AWS Trusted Advisor and AWS Well-Architected Framework

AWS re:Invent 2023

さかもと

2023.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWS Trusted Advisorをもっと使いこなしたいと思っていまして探していたところ、 AWS Trusted Advisorを用いた最適化の話で、今の自分にとてもピッタリな内容であったために受講しました。

概要

Do you know how to identify areas of optimization in your cloud environment to operate more efficiently? Join this session to learn how you can accelerate optimization by using insights from AWS Trusted Advisor and the AWS Well-Architected Framework. Learn how to use AWS best practices to prioritize improvements based on the impact to your business. Hear firsthand how Georgia-Pacific effectively addressed workload resilience and cost-optimization challenges by implementing AWS best practices and utilizing Trusted Advisor.

セッションスピーカー

Stephen Salim Carlos Wiley

セッション内容

クラウドの最適化を技術的な解決ではなく、Trusted Advisorの設計方法など支援ツールのセッション

※セッションで取り扱っていた内容について - セッションで扱う最適化について - 最適化について、探索方法や調査方法また対象を決める方法 - Trusted Advisorを用いたガバナンスを向上させる設計方法について(ジョージア・パシフィック社)

状況によってクラウド最適化の範囲が異なる

クラウドの基盤の最適化やコスト最適化の場合もあればクラウド上で稼働していえるアプリケーションの最適化も含む場合がありセキュリティやオペレーションも含まれる場合もある。

【ECサイトやSaaSの可用性・耐障害性の遷移】.

マルチAZ：一つのでアベイラビリティゾーンで障害が起きた際にサービス停止の確率を下げるが、デプロイが失敗して、レプリカ自体に障害が発生した場合は防げない
ロードバランサのゾーンエンドポイントを利用してRoute53の設定を変更：デプロイ失敗などでレプリカ自体に問題がある場合にDNSから設定を断ち切るこれで最適化されたわけではない、DNSは設定変えても、即時で変わらない
Application Recovery Controllerを利用する Route53の設定に依存することなく、障害が起きているアベイラビリティゾーンのトラフィックを停止させることができる Application Recovery Controllerを実装する際に、運用上のオーバーヘッドが少なく追加コストもないため最適化される。

上記のように、時間が経過すると最適化してない場合がある。

EC2の例

2006年にEC2をリリースされた際はストレージがインタタンスにアタッチされていた。インスタンスを止めるとデータが消えていたため、アプリケーションは完全にステートレスにする必要があった。当時は他にサービスがなかったため、この構成が最適化だったその後、EBSが登場してデファクトとなりました。

他にもアウトバンドの通信やネットワークの考え方も今と昔で変わっている。つまり、最適化の文脈は継続して変わっている。主な原動力としては業界トレンド、ビジネス要件、新機能がある

Well-architected Framework

フレームワークとは

ワークロードの構築と運用を支援するためのハイレベルなベストプラクティスとガイダンスの集合体です。

【領域】.
運用、セキュリティ、信頼性、コスト、パフォーマンス、そして持続可能性など.

【効果】.
よく設計されたフレームワーク、柱構造、実際のフレームワーク構造そのものを使えば、あなたが望む分野の方向性を導くための礎石として使うことができます。

クラウド最適化

最適化にどのようにアプローチするかということです。最適化の機会を探すたびに、時間とリソースを費やす必要があります。そのため、取るべきアプローチは、継続的に文書化する必要があります。

基本的には、継続的な改善プロセスの一環として、継続的に行う必要がある。最も重要なことは、この文書化を行うすべてのサイクルにおいて、

文書化はビジネスの成果とした正当な理由として結びつけることが重要です。なぜなら、最終的に投資は正当化される必要があり、投資対効果を見極める必要があるからです。

そのためには以下3つが典型的なアクションである 1.ベストプラクティスを学ぶこと。

2つ目は、ベストプラクティスに照らし合わせて成果を計測・比較すること。最後の1つは、継続的に少しずつ改善していくことだ。

計測

さて、この測定を行う場合、仕事に対して調査を行う必要があるどのように組織を構成しているのか、どのようなプロセスを導入しているのか、どのような作業工程があるのかを調べます。

2つの典型的な手段や方法がある。 1. 自動化された探索で、これは基本的にAWSのツールを活用してシステム構成を理解し、スキャン見つけるものです。 2. 組織のステークホルダーとミーティングを行い、改善が必要なワークロードの周りの人々やプロセスを理解することです。

どの順番でやってもいいのですが、最も重要なのは、実際に結果を出すことです。

AWS Well-Architected Tool

ツールの意図はステークホルダーとの会話でより良いガイダンスを提供することだ。このツールは、ベストプラクティスに従って、質問ベースの優先順位付けを支援する優れた機能も提供している。コンソール・ベースのツールで、無料で利用可能。

【プロフィール機能】.
あなたがどのようなビジネスコンテクストに置くかによって、ステークホルダーに質問する必要がある質問の優先順位付けされたリストを作成します。

【レビュー・テンプレート】.
質問のいくつかを満たすことができる方法です。あなたの組織でランダム・ディスカバリーの実践をスケールさせたい場合、すでに実装できるもので対応ができて、スケールできるかもしれません。

Trusted Advisor　について

Steven(前スピーカー)が指摘したように、Trusted Advisorはリソース構成、リソース使用量、ワークロードアーキテクチャをスキャンして、 AWSでのデプロイの基礎となる特定のベストプラクティスと比較し、そのベストプラクティスに対して検出された偏差を提供するサービスだ。

Trusted Advisorのベスト・プラクティス・チェックは、47のサービスにまたがっており、逸脱の検出が必要なベスト・プラクティスの追加を発見するにつれて、さらに増え続けています。 AWSのビジネスサポートやそれ以上のレベルのサポートを受けている場合、

クラウド最適化のサイクルには3つの主要なフェーズがありますが、 Trusted Advisorがどのように機能するかによって、学習と測定のフェーズはすでにカバーされている。

ベストプラクティスからの逸脱を検出し、改善方法に関する推奨事項を提供する機能も提供します。それに加えて、修正のためにTrusted Advisorをカスタマイズして活用することができます。

インターフェイスであり、それを活用するために、トラステッド・アドバイザーと他のサービスとの統合を活用することができる。では、自動化された方法で信頼できるアドバイザーにアクセスする方法について説明しよう。

自動化された方法について見ていきましょう。 Amazon EventBridge integrationを使うと、 EventBridgeがアラートやイベントを受け取るたびにAWSのステップ関数を呼び出すことができます。

＜アクセスキー漏洩のインシデントの例（ExposedAccessKeys）＞.
この例では、このインシデント・レスポンスに対して、 Step Fuctionを呼び出してLambdaをトリガーし、IAMユーザに、公開されたキー・ペアを削除させることができます。、私たちはこの特定のソリューションをTrusted Advisor Toolsのオープンソース・リポジトリに追加しました。このQRコードから入手することもできますし、検索すればすぐに見つけることができます。

ExposedAccessKeys

Trusted Advisor Urgency

即座に行動するのか、重点を置いて行動するのか。ビジネスインパクトとは、もしあなたが行動を起こせば、あなたのビジネスにどのような影響を与えるか？その行動をより最適化することで、根本的なビジネスがどのように改善されるのか？

さて、これらの次元を1つずつ選んでいくと、Trusted Advisorは、信頼されるアドバイザーのステータスをチェックすることで、緊急性の次元を提供してくれる。

Trusted Advisorのステータスには3つのタイプがある。緑またはOK：何もアクションがない後に逸脱がないことを意味する。黄色ま他は警告：調査が必要であることを意味し、その後、どのようなアクションを取るか決定することになる。エラー：これは即時の対応または調査が必要であることを意味する。

Trusted Advisor launcher

ウェルアーキテクト・フレームワークには、各ベストプラクティスが、そのベストプラクティスに最適化されていない場合に、どの程度のリスクを伴うかについての詳細が記載されている。そしてこれらのスライドは、低、中、高の3段階になっている。この2つの側面がわかったところで、どうやってその情報を引き出せばいいのだろうか？昨年は、よく設計されたとトラステッド・アドバイザー・ランチャーを統合した。

AWS Trusted Advisor Priority

ところで、あなたのアカウントがエンタープライズサポートで導入されている場合、あなたはすでにあなたと協力する人々の専用のプールを持っています。

昨年、私たちはクラスター・アドバイザー・プライオリティを開始しました。 DIYを選んだり、自分で検討したくない場合は、専任のテクニカル・アカウント・マネージャー・チームに頼ることができます。彼らはあなたのミーティングに参加し、あなたの優先事項を理解しています。彼らは、最もインパクトのある提案をする方法を知っています。

また、複数のアプリケーションを所有するビジネス・ユニット・リーダー・レベルや、複数の部門を横断するCCIEチームであれば、組織内のアカウントを横断する組織レベルでこれらの結果を見ることができます。

しかし、DevOpsエンジニアやアプリケーション・アーキテクトのようなデュワー・レベルであれば、メンバー・アカウントや個々のアカウント・レベルでも見ることができ、コラボレーションも可能です。トラッキング・ダッシュボードでは、バーンダウン・チャートで最も影響力のある機会を表示し、その機会を利用して行動を起こし、より多くの機会を得ることができます。その行動をより頻繁に取ることができます。