re:Invent 2024: AWSのResource Managementチームが語る運用効率化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Streamlining application management on AWS (COP328)
この動画では、AWSのResource ManagementサービスのSenior Product ManagerであるGrace KitzmillerとPaul Hoffmanが、AWS上でのアプリケーション運用の効率化について解説しています。Tagging、Resource Groups、Resource Explorerなどを活用したリソース管理の手法から、Application Operationsによるアプリケーション中心の運用方法まで、具体的な実装例を交えて説明しています。特に、AWS Systems Managerの新機能では、毎月4億5000万の固有ノードと25億の自動化スクリプトを処理する大規模な運用基盤について紹介し、SSM AgentやPatch Manager、Change Managerなどを統合した新しい管理エクスペリエンスの詳細が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Grace KitzmillerとPaul Hoffmanによるプレゼンテーションの概要
本日はご参加いただき、ありがとうございます。私はGrace Kitzmillerと申します。Resource ManagementサービスのSenior Product Managerを務めており、Tagging、Resource Groups、Resource Explorer、そしてApplication Operationsのポートフォリオを担当しています。本日は同僚のPaul Hoffmanも同席しています。私はSystems Managerのプロダクト部門に所属しており、Graceがアプリケーションに関するセクションを終えた後、Systems Managerがアプリケーションの運用にどのように役立つかについてお話しさせていただきます。では、まずGraceから始めさせていただきます。
本日は複数のトピックについてお話しします。まず、アプリケーションについて、そしてAWS上でのアプリケーションやリソースの監視、管理、運用をより簡単にする新機能についてご紹介します。その後、Paulが説明したように、後半ではSystems Managerの新機能と、Systems Manager Automationを使用してアプリケーション運用を効率化する方法についてお話しします。
AWSでのアプリケーション管理：TaggingからResource Explorerまで
まず、AWSでアプリケーションを実行している方は何人いらっしゃいますか？たくさんの手が挙がりましたね。 アプリケーションを稼働させるまでの道のりを思い出していただけるかと思います。最初は実験的に概念実証を行ったり、オンプレミスのアプリケーションをリフト＆シフトしたりしたかもしれません。AWS Marketplaceのテンプレートや、AWS Solutions Libraryのテンプレートを使用したり、AWS PartnersやAWS Professional Servicesと協力したり、あるいは独自のソリューションを開発したりしたかもしれません。お客様から伺うアプリケーション導入の方法は実に様々です。
AWS上でアプリケーションを作成する際、おそらく数千、数十万、あるいは数百万のリソースを作成することになったと思います。お客様からよく伺うのは、AWSでこれらのリソースを作成していると、関連性のない大量のリソースが集まっているような感覚になり、それらの監視、管理、運用に課題を感じることがあるということです。
お客様からは、より良い可視化と管理のためにリソースやアプリケーションを整理する最適な方法について、よくご質問をいただきます。セキュリティの調査結果をどのようにマッピングするか、効率的なトラブルシューティングや自動化にはどのようなツールを使用すべきか、コストの追跡と最適化をどのように行うかといった質問です。これは当然のことで、数千ものものを一度に把握するのは本当に難しいことです。AWSでは、リソースを整理するための様々なツールを提供していますので、運用面に入る前に、まずはこれらの組織構造について説明させていただきます。
まずはTaggingについてお話ししましょう。ここでTagsを使用している方はどのくらいいらっしゃいますか？同じくらいの数ですね。Tagsは、AWSのリソースにメタデータを追加するためのキーと値のペアです。私たちはTagsを、ビジネスインフラストラクチャとAWSインフラストラクチャを結ぶ意味的な架け橋として考えています。お客様からよく耳にするTaggingのユースケースには、部門、コストセンター、チーム、アプリケーションなどのTagsの追加があります。Taggingは主にコスト配分やセキュリティ・ガバナンスに使用されています。アプリケーションについては、開発、テスト、本番環境などの環境を識別したり、機能的なユースケースに基づいてリソースをマッピングしたりするためにTagsを使用していると、お客様から伺っています。すべてのストレージ、コンピュート、アラーム、監視リソースにTagsを適用するお客様もいれば、一時的なリソースに有効期限を設定してライフサイクル管理にTagsを使用するお客様もいます。また、リソースが公開、プライベート、機密データを扱うかどうかを示すデータ分類や、金融サービスやPHI規制の規制要件を表すためにもTagsが使用されています。
リソースにTagsを付けると、いくつかの違いが見え始め、異なるコレクションを作成し、並べ替えやフィルタリングができるようになり、リソースについて異なる視点で考え始めることができます。単なる1つの大きなコレクションではなく、ビジネスにとって重要なこれらのコレクションをどのように管理するかを考え始めることができます。しかし、お客様からは、Tagsは多くのユースケースをサポートしているものの、もう少し高いレベルの組織構造が欲しいという声がありました。
ここでResource Groupsの出番です。Resource Groupsは、指定したTagsのセットを持つリソースのコレクションです。1つまたは複数のTagsを選択してResource Groupを作成できます。また、Resource Groupsは、Tagsに加えて、さまざまな種類の自動化をサポートするためによく使用されるため、異なるリソースタイプを指定してTags内でサブセレクトすることもできます。特定のResource GroupやTagsのセットに対して自動化を設定することができ、この自動化についてはこの後Paulが詳しく説明します。
リソースをResource Groupに入れ始めると、よりリッチなコレクションを作成することができ、単なるTagging環境やTaggingのメタデータを超えて、インフラストラクチャが異なる形で形作られていくのを見ることができます。しかし、何千ものリソースを作成する中で、グループ化やTagging対象としたいリソースをどのように見つければよいのでしょうか？ここでAWS Resource Explorerの出番です。Resource ExplorerはAWSのリソースインベントリ、検索、発見サービスです。わずか数ステップの設定で無料で利用できます。単一のアカウントでも、組織全体でも有効化できます。
Resource Explorerをセットアップして、アカウント内のリソースのコレクションがインベントリ化されると、Resource Explorerコンソールを使用してキーワード、サービス、リソースタイプ、アカウント、リージョンで検索やフィルタリングができるようになります。また、検索APIやリソース一覧APIなど、プログラムでインベントリにアクセスできるAPIも用意されています。ここ数週間で新機能をいくつかリリースしましたので、デモを通じてそれらの機能をご紹介したいと思います。
Resource ExplorerとApplication Operationsの実践デモ
こちらがコンソールのホーム画面です。画面上部にResource Explorerをお気に入りとしてピン留めしています。では、Resource Explorerをクリックして、Resource Explorerコンソールを開いてみましょう。もし初めて使用される方は、どのような情報が見られるのか、素晴らしいプレビューが表示されます。コンソールが開くと、アカウント内のリソースの完全なリストが表示され、必要に応じてページ送りで全体を確認できます。そこから、興味のあるリソースのサブセットに絞り込む方法を検討できます。
この例では、ここに表示されている事前定義されたプロパティを使って検索してみたいと思います。既存のタグ付け戦略があり、AWSでDriverアプリケーションを実行しているので、「driver」という単語で始まるタグ値を持つリソースを検索したいと思います。24個のリソースが表示されていますが、すべてを見る必要はありません。実際にはEC2インスタンスだけを確認したいので、3つのインスタンスが表示されています。そのうちの1つをクリックすると、そのインスタンスの詳細情報が表示されます。過去14日間のコスト、Configのコンプライアンス状況、セキュリティの調査結果などを確認できます。さらに詳しく調べたい場合は、いずれかをクリックしてサービスコンソールに直接移動し、そのサービスが提供する完全な情報セットを確認できます。Configのコンプライアンス情報も利用可能です。1つのリソースがコンプライアンス違反であることが分かります。ここでも深くリンクして、そのリソースの修復アクションを開始できます。
次は関係性タブです。これはこの特定のリソースが他のリソースとどのように相互作用しているかを示すビューです。これはCloudTrailとConfigのイベントを表示するリソースタイムラインです。また、リソースに関連付けられたタグのコレクションや、リソース詳細ページで見つかるプロパティの完全なセットも確認できます。右側には、これらのリソースで利用可能なアクションが表示されています。
ここでアクションを実行してみましょう。EC2インスタンスのフィルターを解除して、このリソースセット全体を選択します。これで一括タグ付けアクションを実行できます。一括タグ付けまたは一括タグ解除が可能です。この例では、これが本番アプリケーションなので、このリソースのコレクションにStagingタグを追加したいと思います。このビューで、タグを設定してすべてのリソースを一度に更新できます。このビューでタグの追加や削除が可能です。また、このビューから直接エクスポートすることもできます。
EC2インスタンスで利用可能な機能に関連して、もう1つご紹介したい点があります。これらのリソースについて、CloudWatchとの連携が実現し、そのリソースに対して標準で用意されているCloudWatchメトリクスを表示し、完全なリストをスクロールして確認できるようになりました。カスタムメトリクスを設定している場合は、それらもこのビューに表示されます。これにより、AWSがリソースについて把握している情報の多くにアクセスできるようになり、それらすべてが1つのページで確認できます。5つや10つの異なるサービスを行き来する必要はなく、このビューから多くの情報を見つけることができます。
デモではかなり速く進みましたので、このスライドで新機能の全体像のスクリーンショットをお見せします。概要、リレーションシップ、Configコンプライアンス、タイムライン、そして新しいResource Explorerで利用可能なアクションセットが表示されています。デモではリソースリレーションシップグラフをさっと流してしまいましたので、ここでスクリーンショットを追加して、もう少しじっくりご覧いただけるようにしました。この特定のEC2インスタンスについて、このインスタンスが他のリソースとどのように相互作用しているかを視覚的に表現しています。
これまで、タグ付けやResource Groupsについて、そしてリソースグループを見つけて整理し、より簡単に管理・操作できるようにする方法について説明してきました。しかし、タグ付けやResource Groupsがあっても、お客様は実際の業務で使用している考え方に沿ってAWSを操作したいとおっしゃっています。私たちはアプリケーションを運用していますが、どうすればこのようなアプリケーション中心のAWSビューを実現できるでしょうか？そこで、アプリケーションとは何かについて考え直してみました。この会場で10人の方にアプリケーションとは何かを尋ねれば、おそらく10通りの異なる答えが返ってくるでしょう。
アプリケーションを定義し、AWS全体でアプリケーション中心のエクスペリエンスをサポートするための適切な構成要素を作るにあたって、私たちは非常に一般的な定義にすべきだと考えました。アプリケーションとは、ビジネスニーズを満たすためにグループとして運用されるリソースと関連メタデータの集まりです。アプリケーションという言葉の代わりに、ワークロード、プロジェクト、タスクなど、組織によって様々な呼び方があるかもしれません。しかし、アプリケーションは常に変化しています。最初に設計を行い、その後、構築、コーディング、テスト、デプロイを行い、最適化フェーズや運用フェーズに移行します。しかし、ビジネスが成功している場合、最も成功しているアプリケーションは常に変化しています。新しい要件が常に追加され、常にフィードバックを受けています。
時間とともにアプリケーションが進化するにつれて、そのアプリケーションの運用と管理の複雑さは増していきます。タグやResource Groupsがあっても、AWSで一度アプリケーションを定義し、多くのサービスで使用できる適切な構成要素について本当に考える必要があります。ここで登場するのがApplication Operationsです。Application Operationsは、いくつかの異なるコンポーネントによってサポートされています。
これらのコンポーネントには、アプリケーションを構成するリソースのコレクションを一元的に監視・管理するために使用できる構成要素と機能が含まれています。これらの機能により、複数のAWSサービスにまたがる、中央集中型でアプリケーション中心のAWS体験を提供・構築することができます。アプリケーションを一度定義すれば、AWSの様々なサービスで活用できるようになります。
アプリケーション中心のAWS体験：Application Operationsの詳細
このモデルはシンプルです - アプリケーションには、メタデータ、プロパティ、そしてリソースがあります。アプリケーションの実装に使用されるサービスには、AWS Service Catalog、Resource Groups、そしてAWS application tagが含まれます。AWS application tagは、AWSが管理するユーザー定義のタグで、これについては後ほど詳しく説明します。
仕組みはこのようになっています：まず、アプリケーションに名前をつけ、必要に応じて説明を加え、その他の属性を関連付けることで、アプリケーションを宣言または定義します。バックエンドでは、AWSがResource GroupとAppRegistryオブジェクトを作成します。また、固有のAWS application tagも生成されます。画面の下部では、タグキーとアプリケーションタグのキー値がどのように見えるかを確認できます。これはコンソールでの操作に限定されません。コンソールでの操作に焦点を当ててきましたが、アプリケーションの作成や操作は、コンソール、AWS CDK、API、CloudFormationやTerraformなどのInfrastructure as Codeを通じて行うことができます。
先ほどmyApplicationsダッシュボードについて触れましたが、そのスクリーンショットを後ほどお見せします。論理的には、現在このような形になっています。多数のサービスから生成されたインサイトを単一のページのダッシュボードビューに統合することで、アプリケーションのコスト、パフォーマンス、セキュリティ状態を理解し、アプリケーションの次のアクションを決定する上で重要な領域やホットスポットを特定することができます。
アプリケーションの構成要素により、タグ付けによって作成された未分化のリソースの集まりから、Resource Groupsによる組織構造の導入を経て、視覚化して管理できる形でインフラストラクチャを形作ることができるようになります。アプリケーション運用により、AWSのリソースを高機能で体系的に表示し、アプリケーションの運用を容易にすることができます。始めるには、コンソール、API、CDK、またはInfrastructure as Codeを使用できます。お客様からは、すでにタグ付け戦略に投資しているため、既存のタグを再利用する方法について質問を受けました。新しいアプリケーションを作成し、既存のアプリケーションを非常に簡単に組み込むことができます。
それでは、既存のアプリケーションを既存のタグを使ってAWSにオンボードする方法をデモでご紹介します。こちらがコンソールのホーム画面です。このシナリオでは、私は"logistics app"をタグキーとして設定し、すでにローディングアプリとシッピングアプリをAWS上のアプリケーションとして追加済みのお客様という設定です。この独自タグを使用するアプローチには、いくつかの前提条件があります - タグ付けのためのトラストポリシーとマネージドポリシーを作成する必要があります。また、アプリケーションのリソースに対するタグの追加や削除に合わせて自動的に同期されるよう、グループライフサイクルイベントも有効にしています。
Create Applicationボタンをクリックしました。コンソールでアプリケーションを作成する最初のステップは、名前を付けることです。オプションで、アプリケーションの説明と追加のタグを設定できます。説明と追加のタグを入力することができます。
もしご興味があれば、Attribute Groupsを追加することもできます。これはアプリケーションに追加のメタデータを付与する方法です。ここまでの設定が完了したら、Nextをクリックして、アプリケーションに追加するリソースを手動で検索するか、既存のタグを選択して使用するかを選べます。必要な権限やポリシー、グループライフサイクルイベントについて詳しく知りたい場合は、Learn Moreボタンをクリックしてドキュメントを確認できます。準備ができたら、アプリケーションページに戻り、タグ付けとアプリケーション作成に必要な権限を付与するロールをクリックします。
IAMコンソールに移動して、ロールに必要な設定を確認します。これにはカスタムトラストポリシーとタグ付けの権限が含まれます。現在では、必要なタグ付け権限の付与を簡単にする管理ポリシーが用意されています。ロールを選択したら、既存のタグキーを選択できます。この場合は、logistics appタグキーです。作成しているタグ値はdriver appで、これをオンボードしています。
次のページでは、確認が必要な場合にリソースをプレビューできます。リソースの詳細ページを見たい場合は、ディープリンクをクリックしてアクセスできます。リソースのプレビュー後、ステップ3のレビューと作成に進みます。ここでアプリケーションに入力した情報を確認し、CloudFormationスタックを選択した場合はスタックの更新が必要になる可能性があることを確認して、Create Applicationをクリックします。作成ボタンをクリックすると、アプリケーションダッシュボードの準備が開始されます。このダッシュボードは、作成直後なのでまだあまり情報が表示されていませんが、上部に作成成功のメッセージが表示されており、まもなくデータが表示されるようになります。
ここでは、すでにしばらく稼働している Loading アプリのダッシュボードに切り替えました。CloudWatch のメトリクスがビューに統合されているのがお分かりいただけると思います。Security Hub で生成されたアプリケーションリソースのセキュリティ調査結果の概要も表示されています。リソースのリストをフィルタリングして検索することもできます。 インスタンス管理やパッチポリシーの詳細といった DevOps 情報を確認することができます。このビューで CloudWatch メトリクスに直接アクセスでき、コストと使用状況のセクションではコストと使用状況の情報を追跡・管理することができます。
AWS Systems Managerによるクラウド運用の効率化
ダッシュボードのいくつかのコンポーネントについて、詳しくご説明させていただきます。まず、コストと使用状況のウィジェットです。 これは時間の経過に伴う傾向、アプリケーションのコスト、それらのコストに寄与する様々なリソース、予測コスト、そしてアプリケーションのコストを最適化するために検討できる節約の機会を表示します。次にコンピュートウィジェットですが、こちらは CPU 使用率のような主要なコンピュートメトリクス、Lambda の呼び出し回数や呼び出し失敗などの主要なメトリクスを表示します。これらのディープリンクをクリックすると、サービスコンソールに直接アクセスできます。
DevOps ウィジェットでは、パッチコンプライアンス、マネージドインスタンスのコンプライアンス、CloudWatch のアラートやアラーム、アプリケーションリソースの重大度の高い、または重大なセキュリティ調査結果を表示します。 最新のウィジェットの1つが、AWS Resilience Hub と統合されているレジリエンシーウィジェットです。これは選択可能な一連のレジリエンシーポリシーを提供し、レジリエンシースコアを生成して、RPO や RTO の目標にどの程度近づいているかを理解するのに役立ちます。
利用可能な節約の機会について、そしてアプリケーションダッシュボードからアプリケーションに対して意味のあるアクションを取るまでの流れについてお話ししました。 Shipping アプリのデモを見てみましょう。コストと使用状況のウィジェットでは、比較的小規模なアプリケーションですが、このアプリケーションで22ドルの潜在的な節約が特定されているのが分かります。
節約の機会のリンクをクリックすると、 EC2 インスタンスのコストを最適化するために検討できる様々なオプションを示すビューに移動します。最初のオプションを選択して、次に何が起こるか見てみましょう。それを選択すると、その EC2 インスタンスについての詳細情報が表示され、 右側を見ると、より詳しく知りたい場合は EC2 に直接アクセスするか、Compute Optimizer を確認するかのオプションがあります。
Compute Optimizerでは、もしこの機能をまだ使ったことがない方のために説明すると、3つの異なるオプションを確認することができます。これらのオプションを順に見ていくと、特定のインスタンスのサイズを変更してコストを削減する際のCPU使用率への予測される影響などを確認できます。ここで表示されている情報から、オプション3ではCPU使用率が上限に近づきすぎる可能性があるため、オプション2を選択することにしました。
このインスタンスをT3 microにリサイズしたいと考えています。このシナリオでは、私の会社はSystems Managerとそのオートメーション、そしてRunbookを頻繁に使用しており、インスタンスのリサイズに使えるRunbookが実際にあることを知っています。そこでSystems Managerに移動し、オートメーションをクリックして、オートメーションを実行し、リサイズインスタンスのRunbookを検索します。リサイズインスタンスのプロセスを開始するためにクリックすると、Runbookの詳細が表示されます。このRunbookが実行するワークフローの視覚的な表示を確認できます。また、独自のRunbookを作成する際に使用できるように、そのコードも確認することができます。
Runbookの実行ページに移動すると、リサイズしたいインスタンスを選択します。入力が必要な情報は、このインスタンスをどのインスタンスタイプにリサイズしたいかということだけです。その情報を入力して、実行をクリックすると、これは数分かかります。ここでは数分待つ代わりに数秒だけ待ちましょう。ページ上部に成功メッセージが表示されました。インスタンスは正常にリサイズされましたが、確認のためにアプリケーションダッシュボードに戻り、EC2インスタンスまでスクロールしてEC2コンソールに移動します。このコンソールは、アプリケーションダッシュボードページから来たため、アプリケーションの一部であるインスタンスだけにフィルタリングされています。ここで、先ほどリサイズを選択したインスタンスを確認できます。こちらを見ると、確かにT3 microにリサイズされていることがわかります。
最後のデモをもう1つご紹介します。うまくいくことを願っています。このデモでは、ダッシュボードが示すアプリケーションのセキュリティ上の問題について、何を確認すべきか、次に取るべき重要なステップは何かを考えてみたいと思います。これも見覚えがあると思いますが、今回はコスト最適化のウィジェットではなく、このアプリケーションの15件の重大なセキュリティ問題を見ていきます。Security Hubコンソールに移動すると、すべての問題が対象のアプリケーションに基づいてフィルタリングされており、これらの問題の1つがCVE脆弱性であることがわかります。これは少し気になるので、この問題をクリックして詳細を確認します。
スクロールダウンすると、関係するリソースや利用可能な潜在的な修復オプションなどの詳細情報が表示されます。これを見て、他の作業に取り掛かる前に、まずこのインスタンスを隔離して、トラブルシューティングと修復についてより詳しく調査したいと判断しました。そこでこのインスタンスIDをコピーします。これにも対応するRunbookがあります - インスタンス隔離用のRunbookを使いたいと思います。Systems Managerコンソールに移動しましょう。これも見覚えがあると思います。オートメーションをクリックし、インスタンス隔離のRunbookを検索します。このRunbookをクリックすると、詳細を確認することができます。
先ほどのRunbookと同様に詳細を確認してみましょう。インスタンスを隔離するためのワークフローと、Runbookの一部として実行される作業の詳細を確認することができます。Runbookを実行する準備ができたら、必要な情報はそのEC2インスタンスの識別子だけです。その識別子を入力して実行をクリックします。隔離プロセスが完了するまでに数分かかります。プロセスが完了すると、ページ上部に成功メッセージが表示されます。
以上で、アプリケーションの運用と、運用を効率化するためのリソースを整理する様々なオプションについての概要をお伝えしました。ここからは、AWS Systems Managerのエクスペリエンスとそれらの自動化について、より詳しく掘り下げていくために、Paulにバトンタッチしたいと思います。ありがとうございました、Grace。皆さんがどうかわかりませんが、この数日間たくさん歩き回っていたので、ステージに上がるためのあの数段の階段を見たとき、「ああ、この階段を上がれるかどうか」と思ってしまいました。ふくらはぎが小さな結び目のようになっていますから。
新しいSystems Managerエクスペリエンスのデモンストレーション
Amazonでは、常に1日目であるという考え方 - 常に貪欲に革新を追求する姿勢について多く語られています。しかし、必ず2日目が来るものです。アプリケーションやクラウドリソースがある場合、2日目が来れば、それらを運用し、修正し、パッチを適用し、バックアップを取る必要があります。そこでAWS Systems Managerの出番となります。Graceは既にSystems Managerができることの一部をお見せしましたが、私はそれらがどのように役立つのかについてより詳しくお話ししていきます。
クラウド運用へのアプローチには複数の方法があります。変更管理を行い、変更管理委員会による承認を確実に得る必要があるプロアクティブなアクションがあります。また、インシデントが発生し、トラブルシューティングと修正が必要な場合のリアクティブな状況もあります。セッションに接続し、何が起きているのかを把握し、問題の解決方法を特定する必要があります。これらすべてを構築するための基盤を持ち、タスクを自動化し、再現可能なプロセスを作成し、コンプライアンスを維持する必要があります。そしてこれらはすべてスケールする必要があります - 毎月4億5000万の固有ノード、毎月25億の自動化スクリプト。これがSystems ManagerがAWSのお客様のために行っていることです。私たちは膨大なスケールを効果的に処理しています。これは運用を効率的に実行し、トラブルシューティングと問題修復を迅速に行い、平均修復時間を短縮するために重要です。
Systems Managerの素晴らしい点は、タグを使用している場合でも、アプリケーションを作成した場合でも、Resource Groupを作成した場合でも、どのように物事を整理していても、Systems Manager内のすべてがそれと連携できることです。これらの属性を認識し、その上に構築することができます。多くの優れたツールがあります - 内部では、ツールと見なすものによって18個か21個かで議論しています。Quick Setupは、バックアップやインスタンス、エージェントのインストールなどを素早く設定するのに役立ちます。Inventoryは、リソースの属性とその使用方法を追跡するのに役立ちます。Run Commandでは、リソースにコマンドを実行できます。Parameter Storeは、情報を安全に保存して共有するための一元化された場所を提供します。State Managerは、アプリケーションと環境の状態を監視し、更新とパッチを通じてコンプライアンスの維持を支援することでコンプライアンスを処理します。Documentsでは、様々なリソース操作を自動化および複製することができます。
Inventoryでは、インベントリの追跡と管理に役立つ様々なデータを収集することができます。タスクを再度実行する必要がある場合、その情報を即座に利用できます。Run Commandを使えば、必要に応じてアプリケーションのブートストラップやインストールを行うことができます。例えば、インスタンスにアンチウイルスソフトウェアをインストールしたい場合、Run Commandを通じて実行できます。Parameter Storeはアプリケーションにとって非常に便利です。複数のアプリケーションで認証情報を使用する必要がある場合、それらの認証情報を保存し、アプリケーションへの入力として利用できます。また、これらの認証情報を暗号化して安全に保管することもできます。
State Managerには素晴らしい機能があります。条件に基づいて特定のアクションを実行できるState Manager Associationを作成できます。多くのお客様が実装している興味深い例として、アカウントまたは組織内のすべてのインスタンスにアンチウイルスソフトウェアがインストールされているかを毎日チェックするAssociationがあります。もしソフトウェアが存在しない場合、自動的にインストールされます。これは特に誰かが標準的なプロセスから外れた操作をした場合に役立ちます。標準のAMIを使用しているはずなのに、誰かが独自の判断で何かを行った場合でも、Inventoryで確認して対処できます。Documentsの機能では、JSONまたはYAML形式でアプリケーション、システム、リソース、グループを管理するための様々なアクションを定義できます。
もう一つのコマンドセットは、自動化と管理機能に焦点を当てています。自動化は多くのタスクにとって明らかに重要で、繰り返し可能なアクションを実行し、常に仕様通りに実行されることを保証します。Patch Managerは、脆弱性対策、アップデート、マイナーなシステムアップデートなど、パッチ適用が必要なすべての作業をサポートします。Change Manager、Change Calendar、Maintenance Windowsが連携して、必要な承認と組織化を提供します。環境に変更を加えたい場合、これらのツールによって、定義された時間枠内で、適切な承認を得て、指定された日に変更が行われることが保証されます。Distributorを使用すると、ソフトウェアアプリケーションやその他のコンポーネントをデプロイするためのパッケージを作成できます。
お客様がこれらのツールを使用するパターンには興味深いものがあります。Patch Managerがあるにもかかわらず、多くのお客様が代替アプローチとしてAutomationを使用してパッチをインストールしています。また、Automationを使用してバックアップを作成するお客様も見られます。データベースを静止させ、バックアップを実行し、目的の状態に復元するAutomationを作成できます。Patch Managerでは、脆弱性に対処しコンプライアンスを維持できます。Change Managerでは承認ワークフローを作成できます。例えば、新しいアプリケーションをインストールする際、Runbookを実行する前にマネージャーの承認を得る必要があります。Change Calendarは許可された変更ウィンドウ内でのみデプロイメントが行われることを保証し、Maintenance Windowsは特定の期間でのアクションを定義し、4時間の間に2〜3システムのみを処理するといったような量の制限を設定できます。
これらのツールはすべて素晴らしいのですが、課題の一つは、それぞれが独立したツールとして構築されていることです。Patch Managerは単独で動作し、Automationは一部のパッチ適用やその他のタスクを処理でき、Documentsやその他のツールは現時点ではかなり独立しています。私たちは、これらを統合して、タスクの実行方法とツール間の相互運用性に焦点を当てた、より統合されたエクスペリエンスを作り出したいと考えています。 2週間前、私たちは新しいSystems Managerエクスペリエンスをリリースしました。Systems Managerをまだ使用していない方は気づいていないかもしれませんが、これが統合に向けた私たちのスタート地点となります。まだご覧になっていない方は、
特に Systems Manager をご利用でないユーザーの方々向けに、ノード管理とアウトカムベースのタスク実行に焦点を当て始めました。これにより、アカウントや組織内の異なるリージョンにまたがるポートフォリオ全体を一覧できるようになりました。ノードへの接続も、別のツールに移動する必要なく、その場で直接実行できます。すべてが手元で完結するのです。デモでお見せする基本的な機能から始まり、今後さらに機能を拡張していく予定です。
Systems Manager 内で発見した問題の修復機能も追加しました。最初に焦点を当てたのは SSM Agent です。Systems Manager をご利用の方々はご存知の通り、SSM Agent が正しくインストールされ、適切に機能していなければ Systems Manager での作業は一切できません。Systems Manager には、SSM Agent の状態を簡単に確認し、問題の診断を行い、修復のためのRunbookを提供する機能を組み込みました。これが最初のハードルとなるからです。Systems Manager が認識して連携できる状態になれば、先ほどお話したような素晴らしい機能をすべて活用できるようになります。
では、以下のシナリオをご紹介します。皆さんAIに興味をお持ちなので、Amazon Q から始めましょう。Q を使って Windows 2016 を実行しているすべてのシステムについて問い合わせます。Q がそれらを見つけ出し、Systems Manager でその全体像を確認できることを教えてくれます。次に、SSM Agent が機能していない未管理インスタンスの問題を修復します。最終的に、Windows の最新バージョンへのアップグレードを担当するチームに提供できる、Windows 2016 インスタンスの完全なリストを取得します。
こちらがコンソールで、これが Q のインターフェースです。AWS コンソールがあり、右側に Q のインターフェースがポップアップして質問できるようになっています。 これが Q が見つけたすべてのインスタンスです。JSON で表示されているのが、それらのインスタンスの属性の詳細情報です。
現在表示されているのは Systems Manager の画面で、先ほどの画面で見つかったすべてのインスタンスを示しています。Systems Manager をご存知の方なら、お馴染みの従来のコマンドは下部にあり、より統合されたノードベースのエクスペリエンスを提供する新機能は左上に追加されていることがわかります。コマンドには、ダッシュボードとなる「Review Node Insights」、先ほど見たリストを表示する「Explore Nodes」、すぐにご覧いただける「Diagnose and Remediate」、そして設定機能があります。
こちらがダッシュボードです。 表示されている内容について説明させていただきます。様々なWidgetがあり、現在の状況を確認することができます。赤色で表示されているのが未管理のEC2インスタンス、緑色が管理下にあるインスタンスです。2番目のウィンドウには、全インスタンスのオペレーティングシステムの内訳が表示されています。Amazon Linux、Microsoft Windows、Ubuntuが使用されているのがわかりますね。
SSM Agentのバージョンと、管理されているノードの種類も表示されています。私たちが直面している課題は、Windows 2016インスタンスすべてをアップグレードすることなのですが、未管理ノードの中にもWindows 2016が存在する可能性があり、それがわかりません。そこで修復機能が役立つわけです。これを使えば、アップデートが必要なWindows 2016インスタンスの完全なリストを取得できます。
その方法をお見せしましょう。この領域にマウスを合わせると、診断というコマンドが表示されます。診断を実行すると、そのタブに移動し、状況を分析する機能が提供されます。では、新しい診断を実行して状況を確認してみましょう。診断を実行しています。診断の結果、17の影響を受けるノードが管理下にあることがわかりました。これは先ほどダッシュボードで表示された数と完全に一致します。VPCエンドポイントが不足していることが示されています。
ここでは、不足しているVPCエンドポイントの状況を確認しました。これが実際に問題を修正できるRunbookで、すべての詳細が記載されています。実行する場所を選択できます - すべての場所で実行するか、特定のアカウントで実行するか、または特定のリージョンで実行するかを選択できます。ここでは、特定のアカウントとリージョンを選択して実行します。これを保存して、VPCエンドポイントを修復する機能を実行していきましょう。
実行が完了しました。結果を確認すると、現在ではエンドポイントの100%が管理下にあることがわかります。7つのインスタンスが新たに追加されました - 以前は10個のWindowsインスタンスがありましたが、現在は17個になり、7つのWindows 2016インスタンスが新たに見つかったということです。これで、これら17個のWindows 2016ノードを確認し、レポートをExcelファイルにダウンロードすることができます。このレポートを開発チームやDevOpsの担当者に提供して、「これがアップグレードが必要なWindows 2016インスタンスの一覧です」と伝えることができます。
Systems Managerの利点と今後の展望
これから何が分かるでしょうか？ 実際に何が起きているのかについて、深い洞察が得られます。内部で何が起きているのかを確認し、問題を特定して解決することができます。新しく登場したAmazon Qを使って解決策を見つけることもできます。Systems Managerに関する質問をQにすれば、どこを見ればいいか分からなくても適切な場所に案内してくれます。下部に表示されているツールの中には、まだNode Management Experienceに移行していないものもあります。より成果重視の体験を提供できるよう、これらのツールも順次移行していく予定です。
Graceは、リソース、アプリケーション、Resource Groupsでできることについて多くを語りました。これらは環境の管理や、保有するリソースの管理、監視をサポートしますが、最も重要なのは、効率的かつ効果的にスケールアップできることです。AWSの各種ツールと組み合わせることで、複数のステップを踏む必要がなく、1回の操作で済むようになります。パッチの適用、アップデート、バックアップ、移行など、必要な作業を簡単に管理・実行し、詳細を確認することができます。Runbookやその他の機能を実行することで、DevOpsエンジニアやITオペレーターとしての作業がより効率的で効果的になります。
ここでよく使う例えですが、リソースやコンポーネント、アプリケーションという素晴らしいLEGOのピースを組み合わせ、その周りに構造を作り上げることで、非常に使いやすく、分かりやすく、扱いやすいものにすることができます。最後に、今日お話しした内容に関する情報源をいくつかご紹介します。アプリケーションの作成方法に関する情報や、Systems Managerに関する情報をご用意しています。先ほどのデモはかなり駆け足でしたが、最後のリソースには新しいSystems Manager Experienceのチュートリアルが含まれています。ぜひこれらすべてに目を通してください。AWSを使用する際の作業効率化に役立つ内容だと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion