re:Invent 2024: AWSのGenerative AIでMicrosoft環境の運用最適化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Use generative AI to optimize cloud operations for Microsoft workloads (XNT312)
この動画では、AWSのGenerative AIサービスを活用してMicrosoftベースのクラウド運用を最適化する方法を解説しています。Amazon Q DeveloperやAmazon Bedrockを使用したInfrastructure as Codeの生成、AWS Systems ManagerとState Managerによる大規模な設定管理、Amazon QuickSightとAmazon Qを組み合わせたWindowsイベントログの分析と可視化など、具体的な実装例を紹介しています。また、AWS ConfigとSystems Managerインベントリを用いたガバナンス管理や、AWS Compute OptimizerによるWindowsライセンスの最適化など、運用管理のライフサイクル全体を通じてGenerative AIを活用する実践的なアプローチを詳しく説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのGenerative AIサービスとクラウド運用管理の概要
それでは始めましょう。クラウドの運用管理ライフサイクルについて考えるとき、どのようなフェーズが思い浮かびますか？まず最初にInfrastructure Provisioning（インフラストラクチャのプロビジョニング）があり、次にConfiguration Management（構成管理）があります。そして、必ずMonitoringソリューションを導入する必要があり、さらにガバナンスとコンプライアンスのニーズに確実に準拠するためのメカニズムも必要です。そして継続的にリソースの最適化を行って効率を高める必要があります。私はSiavash Iraniです。本日はSassan HajrasoolihaとRavindra Koriと一緒に、AWSのGenerative AIサービスを使用してMicrosoftベースのワークロードのクラウド運用を最適化する方法をご紹介します。しかし、その前にAWSのGenerative AIスタックがどのようなものか、簡単に見ていきましょう。
独自のモデルを構築してトレーニングしたい方のために、スタックの最下層では、それらのモデルを構築・トレーニングするための様々なハードウェア、ソフトウェア、プラットフォームを提供しています。スタックの上位にはAmazon Bedrockがあり、自分でモデルを構築することなく、主要なFoundation Modelにアクセスできます。Amazon Bedrockは、単一のAPIで主要なFoundation Modelにアクセスできます。下に示すように、Amazon、AI21labs、Anthropic、Cohere、Metaなどのモデルが利用可能です。様々なユースケースに合わせてモデルをカスタマイズでき、異なるタスクを自動化するためのワークフローやエージェントを自動化できます。もちろん、セキュリティ、プライバシー、安全性もサービスに組み込まれています。
さらにスタックの上位に行くと、アプリケーション内で事前に準備されたアプリケーションやAIアシスタントを利用したい場合は、ビジネスユーザー向けのAmazon Qがあります。Amazon Q Businessは、企業データに基づいてAIベースのチャットアシスタントを作成するのに役立ちます。分析作業には、Amazon Q for QuickSightを使用して、QuickSightで自然言語クエリを使用してさまざまなクエリを実行できます。そして開発者向けには、本日も多用するAmazon Q Developerがあり、コードの作成、生成、リファクタリングが可能で、セキュリティもAmazon Qに組み込まれています。また、JetBrains Rider、Visual Studio、Visual Studio Code、そして最近発表されたEclipseなど、主要なIDEの大部分と互換性があります。さらに、Amazon Q for ConnectやAmazon Q for Supply Chainなどの特殊なユースケース向けのサービスもあります。
Infrastructure as CodeとAmazon Qの活用
さて、クラウド運用管理の最初のフェーズであるInfrastructure Provisioning、つまりInfrastructure as Codeについて見ていきましょう。この用語は皆さんもご存知だと思いますが、これは単にインフラストラクチャをデプロイするためのコードのことです。様々な種類や規模があることは周知の通りです。コンパイル言語の一部として使用されるものもありますが、ほとんどはスクリプト言語の一部です。宣言的なものもあれば手続き的なものもあり、オリジナルベンダーから提供されるものもあります。多くのサードパーティやパートナーベンダーがこのようなコードを生成するためのツールやサービスを提供しています。ここで私たちが提案しているのは、すでに馴染みのあるこれらのツールや手法にAmazon QやAmazon Bedrockなどの Amazon Generative AIサービスを組み合わせることで、より良いコードを得られるということです。より良いとは、読みやすく、保守しやすく、デバッグやトラブルシューティングが容易で、機能の追加や削除が簡単であることを意味します。また、セキュリティ、パフォーマンス、コードの一般的な保守性に関するベストプラクティスにも従っています。
本日は多くの例をご紹介する予定ですが、それらの例に入る前に、これらの例をどこから得たのかについて少し背景をお話ししたいと思います。数ヶ月前、私たち3人がこのセッションのコンテンツを計画していたとき、個々のサイロで作業するのではなく、例を意味のあるものにし、良いストーリーを作るために共通のインフラストラクチャで作業する必要があることにすぐに気づきました。そこで、インフラストラクチャを作成することにしました。技術的な機能に関しては、かなり単純明快でした。
私たちのアーキテクチャの中核には、Provider Instanceと呼ばれるEC2インスタンスがありました。これは、Amazon CloudWatch、AWS Lambda、そして後にAmazon QuickSightなどのAWSサービスを使用して監視していたメインのインスタンスです。AWS Systems Managerのドキュメントやrun commandなどの機能を使用して、その周りに自動化を実装しました。また、デモの内容に応じて、Provider Instanceにサービスをリクエストして応答を受け取るだけのRequester Instanceも用意しました。
この構築にあたって、私たちはいくつかの基本ルールを設定しました。 Generative AIのセッションを開発していたため、VPCの作成のような比較的単純なタスクでも、これらのツールを自分たちで使用することにしました。Generative AIツールの使用が、私たちの全体的なプロセスを意味のある形で改善できるかどうかを確認したかったのです。私たちは全く新しいAWSアカウントから始めました。 その理由は、開発環境やテスト環境では、時間とともに当たり前のように使用しているインフラを構築し、それを忘れてしまうという経験が私たち全員にあったからです。VPC、VPCピアリング、IAMロールなどを一度設定すると忘れてしまい、後のすべての試行でそれらを使い続けることになります。
私たちは、すべての部分を徹底的に確認し、Generative AIツールをテストするために必要なものをすべてプロビジョニングしたいと考えました。 Microsoftに焦点を当てた専門家として、AWS PowerShellを主要なCLIとして選択しました。 また、ツールボックスをシンプルに保つことにしました。インフラストラクチャをコードとして生成するツールは多数ありますが、今回の実践では、AWS CloudFormationとWindows上のDSCという、ネイティブで利用可能なものに限定しました。 ほぼすべての作業を自動化で行うことを試みました。コンソールの使用は、自動化やコマンドラインが期待通りの動作をしているかを確認する場合のみとしました。このDevOpsの考え方を導入したのは、このプロセスを繰り返したり、別のアカウントで新たに開始したりする可能性を考慮する必要があったからです。再現性を確保するために、デプロイメントパイプラインの一部となるコマンドラインとコードのシーケンスが必要でした。
Configuration ManagementとSystems Managerの活用
技術的な観点から見ると、アーキテクチャは特に複雑ではありませんでした。興味深かったのは、それをデプロイすることにした規模でした。 AWSリージョンのマップを見ると、Providerは1つのリージョンにデプロイしましたが、 Requesterは世界中の多くのリージョン、具体的には29のリージョンにデプロイすることにしました。これにより58のRequesterインスタンスが配置されました。 これを行った理由は、デモでジオロケーションAPIを使用しており、実際のイベントに対するレポートのベンチマークの良いベースラインを確立するために、実際のログからの実データでそれらのAPIにフィードする必要があったからです。
AWSの専門家として、マルチリージョンのワークロードのデプロイは私たちにとって目新しいものではありませんでしたが、試験的なワークロードであってもこの規模で実装することは異なる経験でした。その過程で、いくつかの興味深いシナリオやストーリーに遭遇しました。この後のプレゼンテーションで見ていただく例の大部分は、このインフラストラクチャの構築または使用から得られたものです。この背景を踏まえて、デモに進みましょう。まずは理解しやすい内容から始めましょう。 AWS Toolkit for PowerShellを使用してAmazon EC2インスタンスを作成します。ここで見ていただいているのは、Visual Studio CodeでAmazon Q for Developerを有効にしたときのウェルカム画面です。プロンプトの入力準備ができています。私は単に「アクセス可能な各ゾーンにWindowsのEC2インスタンスを1つ作成するAWS PowerShellツールキットスクリプトを生成してください」と入力しました。プロンプトから受け取った応答の要素を見てみましょう。まず、これから得られるものの概要があり、次にコピー機能などの便利な機能を備えたコードの本体があります。下にスクロールすると、コードの各主要セクションが何を行うのかについての説明と概要が表示されます。
コードを実行する前後に必要な作業や、公開ドキュメントへの参照情報が記載されている部分まで、スクロールダウンしていくことができます。また、このプロンプトの後に論理的に続くと思われるフォローアップのプロンプトもいくつか示されています。
コードの品質について詳しく見ていきましょう。生成されたコードを見てみると、変数名は直感的で、コードの各セクションで何をしているのか、あるいは何をする必要があるのかを説明するコメントが付けられています。これらすべてがコードの可読性を高めています。この例では、フレームワークがtry-catchフレーズを使用したエラー処理など、コーディングのベストプラクティスに従って作成されています。フルタイムの開発者ではなくSystemAdministratorとしてスクリプトを書く場合には見落としがちな要素ですが、これらは長期的に見て、あなたや同僚がコードを再利用する際に役立つ優れたプラクティスです。
次の例は、AWS CloudFormationテンプレートの最適化です。ここにあるのは、単純にEC2インスタンスをデプロイするYAML形式のCloudFormationテンプレートです。中央の白い四角の中に表示されているのは、インラインコード提案というAmazon Qの機能です。カーソル周辺のコンテキストに応じて、コードの提案が表示され、それを承認するか、却下して自分でコーディングを続けるかを選択できます。また、コードの一部をハイライトして右クリックすると、Amazon Q用のコンテキストメニューが表示されます。それを展開すると、explain（説明）、refactor（リファクタリング）、fix（修正）、optimize（最適化）、そして汎用的なsend to prompt（プロンプトに送信）など、さまざまなオプションが表示されます。
MonitoringとPerformance：Windows環境でのCloudWatchとQuickSightの活用
この例では、テンプレートがWindows AMIのパラメータを受け取り、その特定のAMIからインスタンスを作成します。私はこの最適化について助けを求めています。最初の提案は、コードの可読性を高めるために説明を追加することです。default value（デフォルト値）の使用は重要です。なぜなら、現状ではAMI IDをスクリプトに渡さないと失敗してしまうからです。しかし、3番目の提案をよく見てみましょう：AWS Systems Manager Parameter Storeを使用することです。AWS CloudFormationは現在、Parameter Storeのインスタンスに問い合わせ、実行時に動的にパラメータの値を取得し、ワークロードのデプロイ時にそれを使用できる機能をサポートしています。私たちは公開されているParameter Storeのインスタンスをサポートしており、そこではWindowsエディションやLinuxエディション、基本的にAmazon AMIでサポートしているAmazonインスタンスの最新のAMI IDを常に取得することができます。
これは実際に良い提案なので、採用することにします。素晴らしいのは、すでにその改善点のコードが生成されていることです。貼り付けたい時にコードをコピーするだけです。ご覧の通り、インラインコード提案がデフォルトのAMI IDで起動しました。私はそれを使用せず、プロンプトからコピーしたコードを貼り付けます。これは2019インスタンス用なので、単純に2012に更新します。これで機能を失うことなくCloudFormationテンプレートができました。必要に応じてカスタムAMI IDを提供することもできますが、提供しない場合でも、Amazonリポジトリから最新のものが確実に取得できます。
私たちのフローの次のステップは、Configuration Managementです。Microsoft環境のConfiguration Managementについて考えると、認証情報の管理からサーバーの堅牢化、エージェントのインストール、役割や機能の設定、そしてWindowsのパッチ適用まで、様々なタスクが思い浮かびます。PowerShell、レジストリ、Microsoft Management Console、Group PoliciesといったWindowsの組み込みツールや、サードパーティのツールなど、現在お使いのツールは完全に問題ありません。
これらのツールは確かに優れていますが、AWS Systems Managerにはこれらのタスクを支援する様々な機能が備わっています。例えば、Run Commandを使えばWindowsとLinuxの両方のインスタンスで大規模にコマンドを実行でき、Session ManagerではリモートのPowerShellを通じてインスタンスへのインタラクティブなアクセスが可能です。そして、次のスライドで特に強調したいのが、Systems Managerの一部であるState Managerです。State Managerを使えば、オンプレミスやコーポレートデータセンターのインスタンス、あるいは他のクラウドプロバイダーのオペレーティングシステムもターゲットにできます。
State Managerは、大規模な設定の適用に特に有用です。他のConfiguration Managementツールと同様に、設定のドリフトを防ぐことができます。通常、これはシステムへの設定プッシュをスケジューリングすることで実現しますが、State Managerはこのスケジューリングをサポートしており、後ほど例でご覧いただきます。これらの設定がシステムに適用される方法は、Systems Manager Documentsと呼ばれるものを使用します。これらのドキュメントは、基本的にSystems Managerに対して、システムに何を適用したいかを指示するものです。これから、Amazon Qを使ってこれらのドキュメントを作成し、Systems Managerを使ってそれらの設定を大規模にシステムに適用する方法をお見せします。
今回選んだ例は、Microsoft Windowsインスタンスのプロトコルを無効化するというものです。ご存知の通り、TLS 1.2より低いバージョンは安全でないとされており、新しいオペレーティングシステムではデフォルトで無効化されています。この例では、Amazon Q Developerに、WindowsでTLS 1.2とそれより低いプロトコルを無効化するState Managerドキュメントの作成を依頼しています。わざと間違えて「and」を入れたことにお気づきください。TLS 1.2を無効化してしまうと、多くのシステムが機能しなくなる可能性があります。Amazon Qがどのように応答するか見てみましょう。まず最初に、TLS 1.2の無効化は推奨できないと述べ、代わりに、環境を運用可能な状態に保ちながら、安全でないものだけを無効化するため、TLS 1.2は有効のままにして、それより低いバージョンを無効化するState Managerドキュメントを推奨してくれます。
その後、State Managerドキュメントが提供されます。State Managerドキュメントは、YAMLフォーマットまたはJSONフォーマットで作成できます。この場合、ドキュメントが何を行うかの説明付きでYAMLフォーマットのドキュメントが提供されます。次に、このドキュメントをState Managerコンソールにコピーできます。ドキュメントが作成されたら、様々な方法でインスタンスやリソースをターゲットにできます。その一つが、大規模な設定適用におけるベストプラクティスの一つであるタグの使用です。タグを使用することは、これを実現する非常に効率的な方法です。例えば、ここではアプリケーションというタグキーとdemo appという値を追加しています。
このAssociationを作成してState Managerで適用すると、このタグを持つ現在の環境内のリソースに適用されるだけでなく、将来的な対応も可能です。つまり、同じタグを付けて今後構築するものにも、これらの設定が自動的に適用されるということです。また、Cronスケジュールに基づくスケジューリングを作成したり、コンソールを通じて設定できるレートスケジュールビルダーを作成して、システムに適用することもできます。では、この例でこれを行うメリットは何でしょうか？TLS自体に関して言えば、無効化の方法を調べていた時、Windowsで設定する必要のある様々なレジストリキーやグループポリシーが、アプリケーションやオペレーティングシステムごとに異なることがわかりました。しかし、この方法では、それらを自分で調べる必要がなく、自動的に作成してくれます。
2つ目のメリットは、State Managerドキュメントを使用しているため、必ずしもドメインの一部である必要がないということです。リソースがドメインの一部であってもワークグループの一部であっても、どちらの場合でも機能します。Associationによる設定の適用が失敗しても成功しても、State Managerを使用してレポートを受け取ることができ、クロスアカウント、クロスリージョンで実行できます。Systems Managerを使用すると、Systems Managerドキュメントをクロスアカウントで共有したり、単に他のリージョンにドキュメントをコピーしたりすることで、アカウントやリージョンをまたいでソリューションを実装できます。
例4に移りましょう。これまではSSMドキュメントを一から作成する方法を見てきましたが、既存のコードがあってそれをSSMドキュメントに変換したい場合はどうすればよいでしょうか？Generative AIがこの課題の解決に役立つかどうか見てみましょう。
Windows Event Logの自動分析とレポート生成
ここにPowerShellコードがあります。これが何をするコードなのかについては、次の例で説明します。私はAmazon Qに、このスクリプトをAWS Systems Managerドキュメントに変換するよう依頼しました。Amazon Qはプロセスを説明し、ドキュメントを生成し、コマンドラインを通じてデプロイする方法を教えてくれます。単なるコードのコピー＆ペーストだと思う方もいるかもしれませんが、重要なのは細部にあります。コードを並べて比較してみましょう。
このPowerShellをSSMドキュメント形式と互換性を持たせるために、コードにいくつかの修正を加える必要がありました。この例では、パラメーターセクションをPowerShellの本体から切り離し、SSMドキュメントの適切な位置に配置する必要がありました。さらに、画面右下を見ていただくと、PowerShell形式で使用されていた参照を、新しいSSMドキュメント形式に更新する必要がありました。私がこの例で特に気に入っているのは、エスケープ文字とデリミタの処理です。たった15行のPowerShellコードなのに、これだけ多くのエスケープ文字と修正が必要でした。これが何百行、何千行になった場合を想像してみてください。この例では行末のデリミタすべてを強調表示したわけではありませんが、Amazon Qを使用してこのタスクを実行することで節約できた時間は非常に価値があります。
「これはJSONフォーマットだけど、YAMLの方が簡単じゃない？」と思われる方もいるかもしれません。実は、私たちもそれを試しました。でも、YAMLでも同じような問題が発生したんです。それに、コードをコピー＆ペーストした後に壊れたYAMLを修正するのって、誰もが楽しいですよね？もちろん皮肉です。次の例ですが、これは新しいAWSアカウントで始めて良かったと思える例の1つです。そうでなければ、この問題に遭遇することはなかったでしょう - 最小権限の原則についてです。これは、システム内のエンティティに対して、必要最小限の権限のみを与えるという原則です。サイバーセキュリティの基本原則の1つで、IT分野のプロフェッショナルの皆さんは私以上によくご存じだと思いますが、この基本原則から逸脱することで、どれだけ多くのハッキングや侵入事例が発生しているかということです。
ワークロードをデプロイする際、通常はワークロードのベンダーが提供する必要な権限リストに依存し、彼らもこの原則に従って過剰な権限を要求していないことを期待します。しかし、ワークロードに付与すべき権限について適切なドキュメントがない場合、試行錯誤の実践に陥ってしまいます。AWSワークロードに話を戻すと、ポリシーのアタッチと削除を繰り返し、APIを試し、場合によってはCloudTrailログを監視して誰がどのAPIを呼び出し、成功したかを確認し、そこからポリシーセットを作成することになります。それでも、すべての可能性のあるシナリオを把握できているかどうかは確信が持てません。
では、このユースケースでGenerative AIが役立つかどうか見てみましょう。同じPowerShellスクリプトに戻ります。今回は、先に進むために、このスクリプトが何をするのかを知る必要があります。以前のアーキテクチャを覚えていれば、Providerインスタンスと、世界中に散らばった複数のRequesterインスタンスがありました。これらのRequesterがProviderに接続するためには、当然、それらのパブリックIPアドレスがProviderインスタンスのSecurity Groupに登録されている必要があります。私たちは意図的にこれらのRequesterインスタンスを動的に変更されるパブリックIPアドレスを持つように設定し、かつRequesterインスタンスをインターネット全体に公開したくありませんでした。そのため、当然ながら、世界中のこれらのRequesterインスタンスで何が起こっているかに合わせて、このSecurity Groupの許可されたIPアドレスリストを同期させる仕組みが必要でした。AWSの他の多くの機能と同様に、これを実現する方法は複数あります。私たちが選んだ方法は、Requesterインスタンス自体でコードを実行することでした。
このコードは、RequesterインスタンスのパブリックIPが変更されるたびに実行されます。適切なAPIを呼び出して、RequesterのSecurity Groupを更新できます。このコードはメタデータにアクセスし、Availability Zoneなどの情報を取得し、新しいIPアドレスをSecurity Groupに追加します。AWS APIを呼び出すには権限が必要で、EC2インスタンスでは、Instance Profileを通じて権限を取得します。これは新しいアカウントでInstance Profileがない状態だったため、作成する必要がありました。
これが私たちのプロンプトです - スクリプトを正常に実行するために、Instance Profileにどのような権限が必要かということです。コードを分析し、必要なAPIのリストと、それらが何をするのか、なぜ必要なのかの説明を提供してくれます。さらに、使用できるJSONポリシーも提供してくれます。コンソールでコピー＆ペーストする代わりに、PowerShellコマンドラインを通じてデプロイする方法についてヘルプを求めました。すると、別の信頼ポリシードキュメントとデプロイメント用の適切なコマンドラインを生成してくれました。
ご覧の通り、私にはInstance Profileがあり、そのポリシーを開くと、そのスクリプトを実行するために必要な権限のみが付与されています。実際、後にSecurity Groupから古いレコードを削除するためのクリーンアップスクリプトを追加した際に失敗したほど制限的でした - これは良いことです。なぜなら、最初にリクエストしていなかった権限を持っていなかったためです。適切なTrust Relationshipが設定されており、このRoleをInstance Profileとして使用することができます。これは、ドロップダウンにそのInstance Profile、つまりRoleがInstance Profileとして利用可能であることを示す最終的な確認です。
クラウドオペレーションライフサイクルの次のフェーズは、MonitoringとPerformanceです。ご存知かもしれませんが、「すべてのものは常に故障する」という有名な言葉があります。これは当社のCTOであるWerner Vogels氏の言葉で、ソフトウェアや分散システムにおいては、何かが常に間違う可能性があるため、構築したものは最終的に故障する可能性があるということを意味しています。何かが間違った時のために、システムを準備しておく必要があります。最も慎重に設計されたFault-tolerantアーキテクチャでも、すべての障害ポイントを防ぐことはできませんが、何か問題が発生した際に通知を受けられるよう、適切なMonitoringとLoggingシステムを確保する必要があります。
ガバナンスとコンプライアンス：AWS ConfigとSystems Managerインベントリの活用
堅牢なMonitoringを導入することで、Amazonでは問題が発生した際の検出、診断、解決に役立てています。Amazon CloudWatchは、クラウドでプロビジョニングされたApplicationとリソースのリアルタイムな可視性を提供するMonitoringサービスです。CloudWatch Metricsを使用すると、CPU使用率、ディスクの読み書き、ネットワークトラフィックなど、インスタンスレベルのメトリクスを特定し、インスタンスのパフォーマンスに関する情報を得て、それに応じたアクションを取ることができます。Amazon CloudWatch Logsを使用すると、インスタンスのログを収集、保存、分析できます。さらに、IISサーバーログやSQL Serverログなど、アプリケーションの動作に関する情報を提供するアプリケーションログにも拡張できます。
Monitoringを導入した上で、本日お見せしたいのは、Windowsイベントを可視化する方法です。リクエストとプロデューサーについて先ほど説明したのと同じアーキテクチャを維持しています。グローバル規模のイベントを実施していて、開発者やシステム管理者が世界中の異なる場所からログインしているシナリオを考えてみましょう。US Eastリージョンで実行されているWindowsインスタンスがあり、セッション開始から数分で、多くのユーザーがマシンに接続できないという報告が上がってきます。予想以上のトラフィックがあり、不正なユーザー名などの問題が指摘されています。Windows管理者として、最初にすることは、Windowsサーバーにログインし、Windows Event Viewerログを確認して、エラーメッセージを見つけ、それらのメッセージを理解することです。このようなシナリオで、次のようなクエリを実行できるダッシュボードやソリューションがあれば便利ではないでしょうか。
ここでは、Amazon Q を使用してIPアドレスを分析しています。これは、提供されたデータに基づいて複数のビジュアルを生成するGenerative AI機能を提供するためにAmazon QuickSightと統合されています。左上隅には、IPアドレスの総数とユニークなIPアドレスの数を示すクイックサマリーが棒グラフとともに表示されています。この情報はさらに拡張され、トラフィックが発生している特定の都市やリージョンを特定することができます。
このような形で、アクセス試行がどの都市から行われたのかを知りたい場合に役立つと考えています。例えば、レーダーチャートは異なる都市からの影響と、トラフィックの流入状況を示しています。同時に、地域や国に関する情報も提供しています。もう1つの拡張機能として、ユーザー名の表示があります。先ほど述べたように、 これらの開発者がどのようなユーザー名を使用しているのかを確認したい場合があります。これにより、トラフィックの発信元を示す地理空間チャートを含む追加情報が提供されます。
次の例をお見せする前に、 このソリューションを構築するために使用したアーキテクチャについて簡単に説明させていただきます。まず、Amazon EC2インスタンスがすべてのWindows Event LogをCloudWatch Logグループにプッシュします。そこから、データをAmazon S3バケットにプッシュします。これには2つの理由があります：将来の監査証跡のためにすべてのWindowsアクティビティを追跡することと、コスト効率を高めることです。次に、AWS Lambda関数がS3バケットからデータを取り込み、フォーマットして処理し、Amazon QuickSightで利用可能な形式で提供します。QuickSightでデータが利用可能になると、データセットが作成され、先ほどご覧いただいたように、開発者やWindows管理者が自然言語処理を使用してクエリを実行し、結果を得られるようにAmazon Qを使用しています。
次に説明したい例は、Windowsイベントの分析です。ほとんどのWindows管理者が認識しているように、 多数のWindowsサービスが実行されており、すぐには注意や優先順位が与えられないエラーメッセージが数多く存在します。これらのメッセージには、パフォーマンスの問題、設定の問題、セキュリティの脅威に関する情報が含まれていることがよくあります。何千台ものサーバーが稼働している大規模な環境では、各Windows Event Logを確認することは時間のかかる作業となります。
運用チームが毎朝このようなメールを受け取れたら便利ではないでしょうか？これは、 発生したエラーメッセージと影響を受けたインスタンスの簡潔な要約を提供します。異なるサーバー間で類似したエラーメッセージをグループ化し、インスタンスIDを提供し、各インスタンスで各エラーが何回発生したかを示します。また、優先順位付けに関する情報も提供します。先ほど見たエラーメッセージの中でも、 すぐに対応が必要ないものもあれば、即座の対応が必要なものもあります。このソリューションは、これらのエラーメッセージを自動的に識別し、どれが即座の対応を必要とするかを示します。また、問題が発生した理由を説明するRoot Cause分析も提供し、WindowsユーザーがMicrosoft記事を参照できるEvent IDも含まれています。
さらに、このメールには 解決手順に関する情報も含まれており、発生した問題を解決するためのステップバイステップの手順が提供されます。これらの手順は、特にWindows専門家ではない運用チームにとって非常に役立ち、ログインして発生した問題の解決を実施することができます。
また、参照用に元のエラーメッセージをログに保持しておきたいと考えています。私や専門家が必要に応じて相関関係を分析できるように、受け取ったエラーメッセージを保持しておきたいのです。これらのメッセージとアシスタントが提案するステップは非常に効果的です。
この解決策がどのように構築されたか、簡単に振り返ってみましょう。アーキテクチャは、CloudWatchロググループにログを送信するMicrosoft Windows Serverを実行しているWindows EC2インスタンスで一貫しています。 そこから、ログをS3バケットに送信し、Lambda関数で処理を行います。この解決策を構築するには2つのアプローチがあります。まず、CloudWatch Log Insightsの高度なクエリ機能を使用してロググループに対して直接クエリを実行し、指定した時間範囲に基づいてリアルタイムデータを取得することができます。そのデータを取得したら、それらのログをAmazon Bedrockに送信してレスポンスを受け取ります。レスポンスを受け取った後、Amazon SESに送信して見やすく整形し、運用チームに送信します。
強調したい重要な点の1つは、Amazon Bedrockで使用しているプロンプトです。私は、アシスタントがWindowsの管理者エキスパートであり、ログ分析を専門とするWindowsシステム管理者であることを指示する、チェーン・オブ・ソート・プロンプト技術を実装しています。 すべてのエラーメッセージを読み、システムへの影響に基づいて分類する初期分析を実行するよう依頼しています。また、メッセージを特定し、優先順位付けを行うようアシスタントに要求しています。これには、無視できるメッセージと即座の対応が必要なメッセージの判断、各メッセージの簡単な説明が含まれます。
この情報を収集した後、予防措置を可能にするために、サーバーで特定された各エラータイプの根本原因分析も要求しています。 さらに、管理者がサーバーで実行できるステップバイステップの解決手順と、必要に応じて要約と推奨事項も求めています。スライドの最後の行にあるWindowsエラーログに関して、Lambda関数はこれらの情報をすべて集約し、プロンプトの変数として渡して、すべてのコンテキストがそれらのエラーメッセージに関連付けられるようにしています。これら2つの例は、Amazon QとAmazon Bedrockを通じた生成AIの機能が運用の世界でどのように活用できるかを示しています。
フライホイールの次は、ガバナンスとコンプライアンスです。すべての組織には、遵守すべき特定の基準と規制があります。しかし、ガバナンスとコンプライアンスに取り組む前に、環境の適切なインベントリを維持する必要があります。 環境のインベントリ管理について話す際、印刷したりExcelスプレッドシートにエクスポートした瞬間に、それは古いものになってしまいます。環境のインベントリを維持するには動的な方法が必要です。Microsoftワークロードのインベントリ項目には、オペレーティングシステム、パッチレベル、ソフトウェアとアプリケーションのインストール、Windowsレジストリ、そしてSQLやWindowsオペレーティングシステムで特に重要なMicrosoftライセンスが含まれます。
リソース最適化とAWS Compute Optimizerの活用
AWS Systems Managerのインベントリ機能は、WindowsとLinuxの両方のシステムのインベントリを取得することができます。Systems Managerのインベントリ機能が、大規模な環境でどのようにインベントリ管理を支援できるのか見ていきましょう。 この例では、左側に3つのAWSアカウントがあり、各アカウントで2つのリージョンを使用し、それぞれ2つのインスタンスが稼働しています。これらのインスタンスはAWS Systems Managerインベントリを使用して、そのリージョンとインスタンスのインベントリを取得し、Systems Managerのリソースデータ同期に送信しています。リソースデータ同期は、リポジトリのようなものと考えてください。AWS Systems Managerインベントリは、オンプレミスのインフラストラクチャや他のクラウドプロバイダーでも利用でき、それらのインスタンスにインストールしてすべてのデータを取得することができます。
インベントリデータを取得すると、そのデータはAmazon S3にJSON形式で保存されるSystems Managerリソースデータ同期に保存されます。アカウント、ソサエティ、さまざまな設定に関する情報を含む多くのファイルが生成されます。 このデータは効果的にクエリを実行できるように構造化されています。
私はAmazon Athenaを使用してそのインベントリデータにクエリを実行し、Amazon QuickSightや他のサードパーティツールを使用してインベントリの内容を可視化することができます。 Amazon Q for QuickSightを使用すると、 QuickSightでそれらの情報を簡単にクエリすることができます。この例では、Microsoft Edgeというアプリケーション名とそのバージョンを持つインスタンスを表示するように単純に尋ねています。 レスポンスには、環境内のMicrosoft Edgeのすべてのバージョンとソサエティが表示されます。
次は構成変更の管理についてです。規制要件に準拠し続けるためには、構成変更や構成のドリフトに対処する必要があります。「テスト環境では動いていたのに - 何が起きたんだろう？何も触っていないのに」という言葉を聞いたことがある人も多いでしょう。構成変更は、ソフトウェアの更新、ユーザーによる変更、アプリケーションのインストール、セキュリティインシデントなどによって発生することがよくあります。構成変更に対処する最初のステップは、それらを発見し、非準拠のものを修正して意図した構成状態に戻すことです。
これは通常、コンプライアンスアズコードと様々なツールを使用して行われます。 ここで特に取り上げたいツールの1つがAWS Configです。先ほどAWS Systems Managerとそのインベントリ取得機能について説明しました。 AWS Systems Managerインベントリを使用して、クラウドシステムとオンプレミスインフラストラクチャの両方のインベントリを取得しています。 AWS Configには様々なルールが用意されています - AWS Configの事前定義されたルールを使用するか、環境内の異なるユースケースやコンプライアンス要件に対応するカスタムルールを作成することができます。これらのConfigルールは、Systems Managerインベントリを使用して取得したインベントリデータに対して実行できます。
これらの結果はAWS Consoleで確認することができ、変更に関する通知を受け取ることもできます。すべてのリソース設定の履歴、コンプライアンスに準拠していた時期、非準拠となった時期を確認でき、それらのデータを後で分析するためにエクスポートすることもできます。また、CloudWatchとの統合も可能です。非準拠項目が検出されると、AWS Configは AWS Systems Manager automationを呼び出すことができます。これはSystems Manager内のもう一つの機能で、AWSレイヤーやオペレーティングシステム内でさまざまなタスクを実行・自動化することができます。Systems Manager automationが呼び出されると、オンプレミスや様々なクラウドプロバイダー上のリソースをターゲットにして、意図した状態に準拠させることができます。
オペレーティングシステムで特定のアプリケーションを強制する例を見てみましょう。アンチウイルスソフトウェアを導入したり、特定のパッチレベルを維持したりするなど、私たちには特定の要件があります。 この例では、AWS Configに組み込まれている「required」というルールを使用しています。このルールはシステムに組み込まれており、存在を確認したいアプリケーションを指定するだけで良いのです。 私の場合、すべてのインスタンスがCloudWatch agentを使用してモニタリングされていることを確認したいので、入力としてAmazon CloudWatch agentを設定しています。Configルールを作成すると、実行までに数分しかかかりません。
実行後、非準拠項目を確認したいと思います。様々なAWSサービスを見ていくと、Generative AIは多くの異なるサービスに組み込まれています。Generative AIを組み込んでいないサービスはほとんどないと思いますが、AWS Configもその例外ではありません。ここでConsoleでは、このルールに対する非準拠リソースを表示するように単純に依頼しています。 AWS Configはそのためのクエリを生成し、すべてのリソースとそれらが準拠していないルールを表示します。
検出されたら、修正する必要があります。 修正方法には、手動修正と自動修復の2つの方法があります。この場合、Systems Manager automationドキュメントを呼び出してCloudWatch agentをインストールし、設定します。ちなみに、このドキュメントの作成にはAmazon Q developerを使用しました。そして、そのドキュメントを呼び出して設定を適用します。フライホイールの次のフェーズはリソースの最適化です。 移行を行ったり環境を構築したりする際には、常に環境を様々な観点から最適化する必要があります。コスト、パフォーマンス、耐障害性、セキュリティ、そしてWindowsやMicrosoftワークロードの場合はライセンスなどです。
長年使用されているAWS Trusted Advisorのような異なるツールには、これらの柱に対する様々なチェック機能が備わっており、最適化や提案を支援してくれます。AWS License Managerは環境内のライセンスの追跡と強制を支援し、AWS Compute Optimizerも様々なサービスにAIを組み込んでいる例外ではありません。 コンセプトとしては、AWS Compute Optimizerにオプトインすると、EC2インスタンス、Lambda関数、EBSボリューム、Auto Scalingなど、様々なリソースを最適化するための提案を得ることができます。
最近、Windowsライセンスを最適化するためのサポートをリリースしました。AWS Compute Optimizerを有効にしても、すぐには提案は表示されません。提案を行う前に、人工知能があなたのアプリケーションの動作を学習するのに時間がかかります。学習が完了すると、画面に表示されているようなさまざまな提案を確認できます。上部では、一部のインスタンスがプロビジョニング不足または過剰であることを示しています。最近、アイドル状態のインスタンスのサポートを発表し、環境内のアイドル状態のインスタンスを検出して、コスト削減やパフォーマンス向上のためにインスタンスタイプのダウングレードやアップグレードを提案できるようになりました。
右下に表示されているWindows SQLライセンスに関する新機能は、EnterpriseやStandard、Webなど、さまざまなエディションのSQL Serverを使用している場合に役立ちます。SQL Serverを使用する際は、ライセンスが提供する機能をすべて活用することが非常に重要です。すべての機能を使用していない場合、ライセンス料を支払っているだけで機能を活用できていないことになります。SQL Serverライセンスの最適化を有効にすると、SQL Server内で使用している機能を確認し、インスタンスのライセンスタイプに合わせてダウングレードやアップグレードの提案を行います。この例では、Enterprise機能をすべて使用していなかったため、コスト削減のためにStandardへのダウングレードが提案されています。
本日の内容をまとめますと、まずインフラストラクチャのプロビジョニングでは、Amazon Qを使用してCloudFormationドキュメントを作成する方法や、AWS Tools for PowerShellの使用方法をご紹介しました。設定管理では、Amazon QとAWS Systems Managerを使用して、グループポリシーやレジストリキーの編集を行うことなく、大規模な設定を適用するためのSystems Managerドキュメントを作成する方法をお示ししました。監視とパフォーマンスについては、RavindraがAmazon Qを使用してQuickSightでログを照会したり、Amazon BedrockとAmazon CloudWatchを使用して自動的にログを分析したりする方法をご紹介しました。
ガバナンスとコンプライアンスについては、AWS Configを使用して自然言語クエリで非準拠項目を確認したり、Amazon Q for QuickSightとAWS Systems Managerインベントリを使用して環境のインベントリを取得したりする方法をご紹介しました。リソースの最適化については、AWS Compute Optimizerを使用してコンピューティング環境をより効率的にする方法について説明しました。以上で本セッションを終了させていただきます。アンケートへのご記入をお願いいたします。質疑応答は廊下で承りますので、よろしくお願いいたします。皆様、ご参加ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion