re:Invent 2024: AWSが大規模リソース運用を効率化する方法を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Operating your fleet of resources at scale is easier than you think! (COP325)
この動画では、AWSのIntelligent Ops Productsグループに所属するOren Nachmanが、大規模なリソースフリートの運用について解説しています。架空の企業Baniluxの事例を通じて、小規模から大規模へと成長する過程での運用の課題と解決策を具体的に示しています。AWS Systems Managerが月間4億5000万以上のノードを管理し、CloudWatchが毎月11,000兆以上のメトリクス観測を行うなど、AWSの圧倒的なスケールでの運用実績を紹介しながら、インテリジェンスを活用した調査機能や、VPCエンドポイントの自動デプロイなど、具体的な運用改善の手法を説明しています。特に新しく導入されたCloudWatch Investigationsの機能を用いた問題調査の効率化や、Systems Managerの新しいエクスペリエンスについて、実際のデモを交えながら詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSエキスパートによる大規模運用セッションの開始
皆様、CO 325「リソースフリートのスケールでの運用 - 思ったより簡単です」へようこそ。私はOren Nachmanです。お会いできて嬉しく思います。私はAWSのIntelligent Ops Productsグループに所属しており、ソフトウェア製品やツールの開発を行っています。私たちの目標は、運用を楽しいものにする製品、サービス、ツールを作ることです。本日は、私が開発したサービスをお客様の環境に導入するお手伝いをしているSenior Specialist Solutions ArchitectのErik Weberと一緒に発表させていただきます。
本日のアジェンダについてご説明させていただきます。まず、確実な運用への道のりについてお話しします。その過程で念頭に置いておくべきことや、よくある落とし穴、そしてそれをどのように改善できるかについて説明します。次に、事例として架空の企業Baniluxについてご紹介します。その後、日々の運用を全体的に改善するために、運用上のミスをどのように改善できるかについてお話しします。最後に、重要なポイントをまとめて締めくくります。
Baniluxの事例：クラウド環境の成長と運用の課題
re:Inventも終盤に差し掛かっていますので、まずは皆様に気兼ねなくお答えいただきたいと思います。 これからいくつか質問をさせていただきますので、該当する方は挙手をお願いします。ご安心ください、誰が手を挙げたかは報告しません。まず、管理対象ノードのパッチ適用に複数の異なるシステムを使用している方はいらっしゃいますか？ ツールを使用せず、手動でパッチを適用している方は？ トラブルシューティングや日常的な運用タスクで、まだ管理対象ノードに直接接続している方はいらっしゃいますか？
ノードのインベントリを持っていない方、あるいはノードが実際にどこにあるのかよく分からないという方はいらっしゃいますか？私たちは良好な把握状況を持っていて、起動される全てのインスタンスを把握しています。 最後に、ソフトウェアライセンスを手動で追跡している方はいらっしゃいますか？監査が来たときに驚かないようにしたいですよね。ライセンスが実際にどこで使用されているかを確認する必要があるとき、面倒なプロセスを経験されているお客様を何社も存じ上げています。
これを「気兼ねのないゾーン」としているのは、私たち自身がこれらの過ちの全てを経験してきたからです。完璧な運用への道のりに終わりはありません。私たちはこれら全てを経験し、そこから教訓を得てきました。他の人の教訓や苦労話から学ぶ面白さは、同じ失敗を繰り返さなくて済むことにあります。本来なら必要ないはずなのに、時にはRDPやSSHでサーバーに接続したり、ライセンスの追跡を見失ったりすることもありましたが、それら全てから学んできました。これらの経験は、私たちが構築し提供するサービスの多くの基盤となっています。
Baniluxをご紹介させていただきます。Baniluxは架空の顧客企業です。ここで誰かの名指しで恥をかかせるつもりはありません。私自身は別として。これはバナナをテーマにした照明会社です。そのため、バナナと照明が出てくるわけです。クラウドとオンプレミスの両方を使用するハイブリッド企業で、オンプレミスのサーバーの一部は実際にここで稼働しています。
Baniluxがどのように発展してきたかについてお話ししましょう。最初は、オンプレミス環境にいくつかのサーバーがありました。ここに示されているように、VMの規模は十分でした。 ビジネスの拡大に伴い、オンプレミス環境にさらに多くのVMを追加していきました。 エンドユーザーにより良い可用性を提供するためにクラウドへの展開が必要だと気付き、単一のアカウント、単一のリージョンでEC2インスタンスの展開を始めました。 この2つの環境にまたがる様々なノードの管理は、それほど大変ではありませんでした。しかし、ビジネスの成長に伴い、オンプレミスのサーバーが増え、エンドユーザーへの接続性や可用性を向上させるため、より多くのリージョンでの展開が必要になりました。
さらに拡大を続けました。 オンプレミスと3つの異なるリージョン、単一のAWSアカウントという構成で、運用の負荷は増えましたが、まだ何とか対応できる程度でした。しかし、より多くの製品やアプリケーションを採用し始めると、複数のアカウントやリージョンへの展開が必要になりました。現在では、 何百ものアカウントを持つ大規模な環境となっています。管理対象リソースのインベントリ情報の把握や、これらのリソースに対するリモート操作の実行がより困難になってきました。このような運用は頭痛の種となっていますが、後ほど、これらを改善する方法について詳しく学んでいきます。
AWSの基本的なビルディングブロックを活用した運用の最適化
では、Orenさん、この拡大についての経験をもう少し詳しく教えていただけますか？ 私Orenが、ここでDevOpsエンジニア、システムエンジニア、 あるいは自分のコードを自分で運用する開発者としての役を演じさせていただきます。Baniluxでの初期には、コードを書いて、各サーバーに個別にSSH接続してデプロイしていました。サーバーの数が少なかったためです。当時は、かなり洗練された方法だと思っていました。パッケージを作成してカスタムYum Repoに公開し、最新のパッケージを参照するようにRepoを設定する方法を文書化していました。
時間とともにホストの数が増え、たとえ並列実行スクリプトを使用しても、すべてのホストにSSH接続してデプロイするのに時間がかかるようになり、時々ミスも発生するようになりました。成長に伴い、機能を分割することにしました。開発チームとDevOpsチームを作り、DevOpsチームは文字通り、多くのマシンに対して手動で並列SSH接続を行っていました。私一人では対応できなくなっていたからです。インフラの成長に伴い、DevOpsチームも拡大し、サーバー100台に対して10人、200台に対して20人というような、何か魔法の公式に従って人員を増やしていきました。
結局のところ、人間はスケールしないので、採用できる人数にも限界があり、このやり方ではスケールしません。DevOpsチームが私たちに言ってきました。「優秀な開発エンジニアとDevOpsエンジニアを雇ったのに、私たちは手作業だけをやっているんです。CI/CDを使って、きちんとやりましょう」と。 この時点で、私たちは完成したと思いました。コードをビルドしてパイプラインに投入し、自動テストを実行し、さらに異なるマシンに自動でデプロイされ、何か問題が起きた時にはロールバックする機能まであるなんて、素晴らしいと思いました。
私たちは、DevOpsがこのような開発インフラに注力することで完了したと考えていました。開発者たちはビルドを行っていましたが、次は運用面の課題が出てきました。 スケーラブルな方法でシステムをマシンにデプロイできるようになりましたが、まだプロダクション環境があり、それは成長し続けています。Ericが言ったように、それはオンプレミスや自社のデータセンターだけでなく、クラウドにまで広がっています。 そうなると、プロダクションホストにアクセスしなければならない理由が次々と出てきました - パッチ適用、障害のデバッグ（私のコードにバグなんてないはずですが...まあ、すべてのバグは私の責任です）、CI/CDの失敗のデバッグ、サービスの監視などです。
プロダクションサーバーにアクセスする理由がどんどん積み重なっていきました。私はそれらをすべて図に描こうとしましたが、私の絵の才能は明らかに素晴らしすぎます。 この時点で、もはやスパゲッティ状態になってしまいました - プロダクション環境にアクセスする必要がある理由を数え上げるのが多すぎて手に負えなくなりました。 私たちが見つけた解決策は、AWSが提供している基本的なビルディングブロックを活用することでした。これによって、プロダクション環境にアクセスする必要がある理由の大部分を解消できました。
今日は、そのことについて詳しく見ていきましょう。ビルディングブロックを見ると、私たちがよく知っている4つの主要なものがあります。 これらのサービスが最近リリースした新機能についても見ていきます。基本的なレベルでは、ログ、メトリクス、アラーム、ダッシュボードを提供するCloudWatchがあります。そして、大規模なノード管理を提供するSystems Managerがあります。
Systems Managerの素晴らしい点は、ノードがどこにあるかを気にしないことです。 EC2インスタンスであろうと、ここステージ上にあるこれらのボックスの1つであろうと関係ありません。コンプライアンスのためのConfigがあり、 そしてもちろん、最も見過ごされがちな運用ツールであるCloudTrailがあります。CloudTrailについて人々と話すとき、多くの場合、誰が何をいつしたのかを特定して責任を追及するための監査について話します。しかし、責任追及なしでも同じことができます。私たちは責任追及ゲームはしませんが、運用のために使用できます。何か問題が発生したとき、私が最初に確認する場所の1つがCloudTrailで、何か変更があったかどうかを確認します。その後、CodeBuild、Lambda、CloudFormationを確認するかもしれませんが、CloudTrailは私たちがよく見過ごしている素晴らしい出発点を提供してくれます。後ほど、これがCloudWatchにどのように統合されているかを見ていきます。
大規模運用の自動化：タイミングと重要性
このような素晴らしい環境を整えていても、まだ人の目による監視が必要な部分が残っています。完璧ではないのです - 運用は常に改善を続けていく旅なのです。私たちの運用の一環として、信号機システムを採用しています。想像の通り、信号機は標準的な色を使用しています。緑は正常な状態を示します。現在、このパイナップルが示すように、すべて正常です。デモなので縁起でもないことは言いたくありませんが、このデモの間ずっと緑のままであることを願っています。もし何か問題が発生したら、遠慮なく指摘してください。なぜなら、実際のお客様がこのシステムを使用しているからです。黄色は、サービスに問題があることを示します - サービス自体は稼働していますが、何かしら問題がある状態です。そして、サーバーがオフラインの場合は赤になり、これはシステムがダウンしていてお客様がサービスにアクセスできない状態を意味します。
それでは、大規模運用の最適化について話しましょう。大規模運用の最適化について話す際、これは私たちが歩んできた道のりの一部です。私たちというのは、AWSやAmazon、そしてより小規模なBaniluxの両方を指します。私たちが注目する大きな入力が2つあります。これは単純化して言っていますが、実際にはたくさんの副次的な入力がこれらに流れ込んでいます - それはデータと、インテリジェンスです。ここでのデータは非常に重要です。AWSが標準で提供しているデータソースを見てみると、何も設定しなくても、すべてのリソースに対する大量のログ、メトリクス、CloudTrailログ、CloudWatchログ、そして有効にしていればConfigがあります。
そのデータと、実際に必要なデータを理解するためのインテリジェンスを組み合わせます。インテリジェンスは、必ずしも現在話題のAIやML特有のものを指すわけではありません。私たち人間もインテリジェントであり、重要な場面で使える賢いクエリをいくつか用意しておくだけでも役立つことがあります。しかし最終的には、データやインテリジェンスについて心配する必要はありません。それは準備段階の話です。本当に必要なのは自動化です。それが理想的な最終状態です - それはInfrastructure as Codeであり、実際の自動化です。誰かが深夜2時にサーバーの障害対応のために起きなければならない時、Wikiのどこかにある手順を手動で追っていくのではなく、例えば自動化ドキュメントを実行できるようにしたいものです。最小限の入力で、適切なガードレールのもと、自動的に処理されることが望ましいのです。
ただし自動化には問題があります。ここで私から皆さんにお伝えしたいのは、いつ自動化を始めるべきかが分からないということです。最初の段階では、ここにある2つの小さなデバイスだけです。それを自動化する必要はありません - テーブルの下に隠れているキーボードですべてできます。自動化のコストは低いですが、投資収益率も低いのです。そして規模が大きくなるにつれて、それらのスクリプトもある程度は一緒にスケールします。少し面倒になりますがスケールします。さらに成長を続けると、以前は数分で済んでいたことが数時間かかるようになります。しかしその時点で、自動化するには数日かかると考えると、それを正当化できるかどうか迷ってしまいます。
開発者やエンジニアとして、どの時点であっても、私たちはすべてを自動化したいと考えます。手動でクリックするのが面倒で、手作業で行うよりも自動化に時間をかけてしまった経験は間違いなくあります。それはある意味では問題ありません。なぜなら、ある時点でクリック作業が増えすぎて、自動化のコストが上がり始め、人間はそれに追いつけなくなるからです。人間にはクリックできる速度の限界があります。そのため、どこかでバランスを見つける必要があります。そして、各個人、システム、サービス、企業によって、早すぎる自動化と遅すぎる自動化の間のどこかにそのバランスポイントが存在するのです。
これは特にStartupにとって重要なバランスです。私はStartupと多く関わっていますが、強調している重要なポイントの1つは、できるだけ早い段階で反復作業を自動化することの重要性です。それは大きな見返りをもたらすからです。 ある時点で、自動化とスケールでのテストに数ヶ月の作業が必要になり、それは単に機能しなくなります - 手遅れなのです。 このような状況は避けたいものですが、その方法は自動化を適切に導入することです。
パッチ適用やログの収集、SSHアクセスを必要としない安全なコマンドの実行など、自動化が必要です。このアプローチにより、誰かがSSHでログインしてrootアクセスを取得したり、EC2インスタンスのIAMロールにアクセスしたりする心配がなくなります。代わりに、自動化システムを通じて実行できるコマンドが制限されます。 結局のところ、自動化はそのスパゲッティアーキテクチャを解消する鍵となり、それは全ての人にとって不可欠です。
「私たちは自動化するには小規模すぎる」という声をよく耳にしますが、興味深いことに、これは通常エンジニアではなく、時間を投資したくないリーダーシップから出てくる意見です。エンジニアとしての私たちの役割は、上層部を説得することです - 私はこのトピックに非常に情熱を持っており、誰とでも議論する用意があります。リーダーとしての私たちの役割は、規模に関係なく全ての人に利益をもたらすため、スタッフが自動化を実装する十分な時間を確保できるようにすることです。 ある時点で運用とコンプライアンスの要件が発生しますが、自動化しようとしているものが何であれ、すでに準備されたスクリプト群があることになります。
AWS Systems Managerの新機能：管理と可視性の向上
では、AWSがサービスの提供以外にどのように関わってくるのか見ていきましょう。あなたの journey がどの段階にあるか、また規模の大小に関わらず、小規模企業であれ大規模エンタープライズであれ、AWSはそのスケールでお客様のニーズに応えます。 スケールの規模感をお伝えすると、Amazon CloudWatchは毎月11,000兆（より分かりやすく言えば11クアドリリオン）以上のメトリクス観測を行っており、これは1秒あたり42億の観測に相当します。AWS Systems Managerは、AWSであれ、オンプレミスであれ、他のクラウドであれ、毎月4億5,000万以上のユニークな管理ノードを管理しています。 AWS Configは毎月90億以上のコンプライアンスチェックを記録し、 AWS CloudTrailは1日あたり8,500億のAPIイベントを監査しています。
つい2週間ほど前、AWS Systems Managerはこれらのリソースを管理するための新しいエクスペリエンスを立ち上げました。このシングルコンソールから、データを集約したいアカウントをDelegate Administratorとして指定し、情報を収集したいリージョンを指定するだけで、わずか数クリックで有効化できます。これにより、管理されているインスタンスと管理されていないEC2インスタンスの可視性が即座に得られ、インスタンスが管理されていない状態にある理由の診断と修正に役立ちます。
AWS Management Consoleを見ると、フロントダッシュボードの様々なウィジェットを通じて、ノードに関する情報をすぐに確認することができます。この例では、EC2インスタンスとハイブリッド管理リソースが混在する、Systems Managerで管理されているすべてのリソースが表示されています。これらのウィジェットはすべてインタラクティブなので、クリックして特定のセクションを展開したり、より詳しく調べたりすることができます。最後に、SSM Agentのバージョンに関する情報が表示されます。バグ修正や将来の改善を確実に適用するため、最新バージョンの使用をお勧めしています。
管理対象ノードのオペレーティングシステムを見ると、これらの管理対象リソースが実行しているすべてのOSを確認できます。ここで、管理環境で作業をしていて、サポート終了または終了間近のオペレーティングシステムからの移行を開始するよう指示された場合のシナリオを考えてみましょう。このシナリオでは、Windows Server 2016の管理対象インスタンスを、Windows Server 2019、あるいは理想的にはWindows Server 2022にアップグレードすることを目標としています。
ここから、そのリソースのリストを詳しく見ていきましょう。新しく追加された機能の1つである「ノードの探索」セクションに移動します。ここでは、アカウントとリージョン全体のすべてのリソースの内訳が表示され、その情報を確認することができます。環境全体でそれぞれのインスタンスがどこに存在するかを確認できます。コンピュータのホスト名などの情報も取得できます。システムがこの専用の管理者アカウントに集約する情報は非常に多岐にわたります。このリソースリストで作業する際には、組織全体で情報を共有し、Windows Server 2022への移行に向けてアプリケーションの所有者と協力する必要があるかもしれません。レポートを生成してローカルコンピュータにダウンロードすることができます。
問題が発生しているようです。すべてが安定していると言ったばかりですが、残念ながら、トラフィックライトシステムを見ると2つの問題があります。1つは移行に関する問題で黄色でマークし、もう1つは赤でマークされた問題で、調査が必要なダウンしているサーバーがあります。最初のステップとして、アラームが設定されているCloudWatchに直接アクセスします。この部分はus-east-1で実行していますが、us-east-1の一部として、2日前に新しくリリースされたものがあります。これは最新のもので、アプリケーションのデバッグを可能にするAI Operationsです。すべてが正常であるように見えますが、実際にはそうではありません。
調査を作成しましょう。ここでの調査では、異なるアラームやメトリクスをすべて確認し、1つの場所にまとめることができます。これは動的なダッシュボードのようなものですが、様々な製品で見られるようなノートブックに似ています。ここでのポイントは、組織全体で共有できるライブノートブックがあるということです。現在、ここにいる全員がこれにアクセスできます。必要なアラームを取り込むことができます。例えば、現在実行中のアラームをダブルチェックすることができます。ここでエラーを確認し、既存の調査に追加できます。この小さなサイドカーはどこでもポップアップします。このアイコンはコンソール全体で表示され続け、どこにいても調査に情報を追加することができます。
調査に追加して、より見やすくするためにフルスクリーンで開いてみましょう。今追加したメトリクスがこちらです。高いレベルで見ると、で黄色になる前から、私が注目していた様々な要素があります。いくつかのコンポーネントを追加しましたが、さらにCloudWatchは、ログを確認している最中に問題を見つけました。メトリクスを追加すると、リアルタイムで送られてきたログから問題を検出し、すぐに追加してくれます。それらを使用するかどうかを選択できます。これらが、Amazon Qが見つけた様々な提案です。Amazon Q investigationsが調査の過程で支援してくれています。ここで私自身の要素を追加することができます。赤信号が見えたので、さらに調査を進めると、残留効果を伴う潜在的な影響があるようです。ここでのポイントは、複数の人々がこのノートブック内で同時に協力できることです。このノートブックは即座に更新され、AWS Chatbotを使用してSlackやMicrosoft Teamsと同期できるため、Slackからもこの調査に関わることができます。
この調査はSlackからも開始できます。例えば、オペレーションチャンネルがある場合、それをここに接続します。オペレーションチャンネルをモニタリングしている人々は、完全に緑色のアラームを見ていても、何か少し変だと感じることがあります。インシデントになる前、すべてが赤くなる前でも、調査を開始できます。つまり、何か少しおかしいと感じて、バックアップが必要だと思った時点で調査を始められるということです。
関連するすべてのログとメトリクスをここにまとめ始めることができ、その間にバックグラウンドのAIモデルがこれらすべてを相関分析して、追加の問題を見つけ出します。これらはまだアラームを発生させていないかもしれませんが、全体として影響が出ているのが、ここで見ているような状況です。アラームは問題なさそうに見えますが、何かが起きたことは明らかで、回復したように見えても完全には回復していません。
分析の一環として、関連する可能性のある発見事項を示す観察結果が表示されます。それらを受け入れるか破棄するかを選択できます。例えば、CPU使用率が高くても、それがテストインフラ用だとわかっている場合、以前のデプロイメントによるものだったので、それは必要ないということで削除できます。本当に素晴らしいのは、十分なデータが集まり、Amazon Q Developerが状況を分析すると、実際に何が問題だったのかについての仮説を提示し始めることです。
仮説は自然言語で書かれており、これは大規模言語モデルを使用する利点の1つです。ECS、API Gateway、DynamoDBのメトリクスを調べることで、なぜこの問題を見つけたのかを説明します。この場合、DynamoDBによってスロットリングされているという問題を指摘しています。このトーク中に私たちのウェブサイトにこれほどのトラフィックを発生させてくれた皆さんに感謝します。とても素晴らしいことですが、実際のお客様が照明を元に戻す必要があるので、これを早急に修正しなければなりません。
仮説が提示されたら、それを受け入れることができ、そうすると私たちは一連のアクションを提案します。 これらのアクションは、問題を解決するために設計された様々なタイプのコンテンツになります。なぜなら、仮に深夜2時で、とにかく問題を解決したいという状況を想定しているからです。 例えば、最初に提案されるのは、AWSが提供する、AWSが構築した、コード化されたRunbookで、DynamoDBのプロビジョンドキャパシティを変更することでこの特定の問題を解決します。
私たちは、お客様が当社のサービスを利用されていても、私たちの自動化を完全には信頼されていないかもしれないことを理解しています。これは、自動化がインフラの下ではなく、お客様のインフラ内で実行されるため、もっともなことです。そこで、ランダムではないナレッジ記事も提供します - これがRunbookのコード化の元になったものです。私たちはサポートチームやお客様と協力して、これらのナレッジベースの記事の自動化された代替手段を手作業でコード化しました。 例えば、「Save the Benelux Day」というRunbookがあります。これは、潜在的な影響があるものの、サービスが完全に回復しないような問題が発生した際に、サービスを再起動するために使用します。
さらに面白いのは、お客様が所有する関連するRunbookも見つけることができる点です。深夜2時にチェックが必要で、グラフを確認したい場合は、ここにあります。 実行グラフが表示されるので、何をするのかを確認でき、 各種パラメータを入力してここから直接実行できます。これは実行に数分かかります。なぜなら、大規模な環境では、 数秒ではなく数分で修正が完了するからです。
CloudWatch Investigationsによる問題解決と自動化の実践
これが実行され、修正されている間に、あの黄色い表示が気になるので、先ほど作業されていた内容について確認させてください。Orenさん、あなたが作業している最中に、実は素晴らしいニュースがありました。ビジネスがさらに拡大し、環境にノードを追加したのです。残念ながら、それらは最適な状態ではなく、Systems Managerで管理できる状態ではなく、パッチの適用やオペレーティングシステムに関する情報の収集もできない状態のようです。 そのため、このNode Insightsページに戻ると、左上に153個のインスタンスが未管理状態であることが表示されています。これについて どうすればよいでしょうか。
ここで診断ボタンを押すだけでよいのです。これにより診断と修復のセクションに移動し、それらのEC2インスタンスがSystems Managerに登録されていない理由を特定し、 管理下に置くことができます。この機能で対応できる問題は2種類あります。まず、この新しいSystems Managerエクスペリエンスの一般的な デプロイメントに関するもの、そして次に、それらのEC2インスタンスが登録されていない理由に焦点を当てたものです。
新しい診断を開始できますが、ご覧の通り、今日少し前にも実行したところです。ここから、この診断レポートを確認したり、ダウンロードしたりすることができます。先ほど見ていたものと同様のCSVファイルが生成され、これらのEC2インスタンスがどのアカウントやリージョンに存在するのか、その基本的な情報を確認することができます。Orenが先ほど説明したような、チェックインしていないインスタンスのレポートを提供するだけでなく、この問題の修復も支援できます。このシナリオでは、これら153個のインスタンスすべてにVPCエンドポイントが不足しているようです。これは、パブリックインターネットへのルートがないか、単にVPCエンドポイントが欠けているかのどちらかです。
この場合、VPCエンドポイントをデプロイする必要があれば、同じRunbookがそれを実行してくれます。ここでは、Orenが先ほど言及したように、実行される手順を確認するだけです。ターゲットを変更したい場合は、管理されていないEC2インスタンスを持つすべてのアカウントにデプロイする必要はありません。単一のアカウントだけで始めたり、VPCエンドポイントをプロビジョニングしたい特定のリージョンだけにデプロイしたりすることもできます。準備ができたら、実行ボタンを押すだけです。
これにより、管理されていないインスタンスが存在する各アカウント、各リージョンに対して自動化ワークフローが開始されます。この場合、EC2インスタンスが配置されているVPCを評価し、Systems Manager用の新しいVPCエンドポイントをプロビジョニングして、このマネージドインスタンスとの接続を再確立することができます。さらに規模を確認するために、Automationに移動すると、ワークフローが開始されているのが分かります。管理されていない、あるいは管理されているEC2アクションのオーケストレーターがあり、最初のものをドリルダウンすると、すでに私のアカウントを横断して、リージョンごとにVPCエンドポイントの作成を開始し、これらのインスタンスのマネージドインスタンスステータスを解決しようとしているのが分かります。
最終的にはすべて緑色になりますが、もう一つ強調したい機能の設定を見てみましょう。この診断と修復機能は手動で開始することもできますが、定期的な診断をスケジュールした方がよいでしょう。管理されていないインスタンスを一度だけ確認するのではなく、定期的に監視したいものです。これを毎日または週1回実行するようにスケジュールでき、ここで開始時刻も指定できます。
準備ができたら保存ボタンを押すだけで、管理されていないEC2インスタンスを継続的にチェックし、それらが管理されていない状態にある理由を理解するのに役立ちます。また、以前の実行や診断を振り返り、同様の問題や異なる問題があったかどうかを確認し、インフラストラクチャーをより良い状態に保ち、インスタンスが管理されていない状態になることを防ぐことができます。まず、Ericに感謝したいと思います。すべてが緑色になったからです。ステージの反対側にあるライトのことを皆さんにお見せできないことに気づきました。申し訳ありません。でも、ありがとうございます。最後の黄色いものもフリップしたようです。ありがとうございます。素晴らしいですね。明らかに、私たちは適切なタイミングで対応できました。
赤信号が解消されたので、Global内の2つのポイントについてもう少しゆっくりとご説明させていただきます。
まず1つ目のポイントは、この調査結果が常に画面上で追従してくれるという機能です。すでに問題は解決されていますが、スロットリングが発生していたDynamoDBテーブルについてもう少し詳しく調べたい場合、調査を終了していない限り、この調査結果を常に参照することができます。最終的には、私が立てた仮説とその根拠が残りますが、どのダッシュボードを開いていても、この調査結果が追従してくれます。これにより、どこにいても必要な操作ができ、余計な心配をする必要がありません。普段から20個以上のタブを開いていて、毎日その10倍くらいのタブを開くことになりますが、サイドカーのように引き出せる機能のおかげで1つでもタブを節約できるのは素晴らしいことです。
このように調査結果が追従してくれるのがこの機能の特徴で、もちろん「フルページを開く」をクリックすれば、いつでも全画面表示に戻ることができます。もう1つ強調したいポイントがあります。全画面表示に戻りましょう。今回のシナリオでは午前2時2分という設定ですが、必ずしも深夜2時である必要はありません。午後2時でも、自動化を実行する前に、たとえそれが自分で作った自動化であっても、安全に実行できるかどうかを確認したいものです。先ほどお見せした複雑なグラフを毎回確認するのは、自動化を実行するたびにコードレビューをするようなもので、自動化の意味がありません。
そこで私たちが用意したのが、実行結果の自動プレビュー機能です。少し拡大してお見せしますが、この自動化を実行することのリスクレベルを表示してくれます。Core Automationチームが懸命に取り組んだ機能で、自動化を実行する際の概要を素早く把握することができます。例えば、1つのアカウントで実行するつもりが、実際には1万以上のアカウントを持つ組織全体で実行されてしまうような場合 - これはおそらく間違いです。あるいは、1つのリージョンで実行するつもりが、実際にはすべてのリージョンで実行されるような場合でも、ここで正確に実行範囲を確認できます。概要が表示され、さらに各ステップを分析して、変更を伴う（書き込み）APIと変更を伴わない（読み取り）APIを正確に識別します。
すべてが正常な状態になったので、CloudWatch Investigationsの優れた機能についてお話ししましょう。ここで一旦振り返ってみると、これは本当に確認する価値のある機能です。どんな問題でも、調査にかかる時間を大幅に短縮できるからです。アラームが鳴らなくても、何か気になることがあれば調査を始められるのが特徴です。通常、私たちのプロセスはアラームが鳴ってから始まりますが、「今見ているこの状況を詳しく調べたい」と思ったときに、メモ帳やVS Codeではなく、コンソール上で分析し、他の人と共有できるツールがあるのは素晴らしいことです。最終的に、もし最高の結果 - つまり、気になっていたことが実は何も問題なかったということが分かった場合でも、調査を終了するだけです。
本日はご参加いただき、誠にありがとうございます。まず、これまでの内容を手短に振り返らせていただきます。私たちは3つの重要なポイントについてお話ししました。というのも、結局のところ、どのサービスを使うかは重要ではありません。もちろん、これらのサービスは素晴らしいものですので、ぜひ皆さんに試していただきたいと思います。重要なのは、AWSの様々なサービスを使って、フリートやノード、リソースをどのように管理できるかということです。完全なServerlessアーキテクチャであれ、従来型のサーバーベースであれ、あるいはハイブリッドであれ、大規模な運用を実現する方法についてお話ししました。
まず最初に、スケールを認識し、それをシンプルにすることが重要です。AWS Systems Managerのようなツールを使用することで、アカウントやリージョンを横断したノードとフリートの管理を簡素化できます。次に、人工知能であれ、Generative AIであれ、カスタムインテリジェンスであれ、あるいはその3つすべてであれ、インテリジェンスを調査に取り入れることが重要です。これにより、調査時間を短縮し、できるだけ早く解決に導くことができます。そして、自動化を実現します。
ここで何度か繰り返し出てきた重要なテーマがあります。自動化が必要だということです。「当たり前じゃないか、これはCOP 325なんだから自動化が必要なのは分かっている」と思われるかもしれません。しかし、実際にどれだけの方が自動化を実現できているでしょうか？私のチームの1つは実際「Automation」という名前で、自動化プラットフォームを構築しており、多くのものを自動化しています。それでも完全な自動化には至っていません。これはビジネスの現実ですが、スケールのシンプル化、インテリジェンスの導入、そしてこれらを自動化と組み合わせることで、毎回手動での作業を気にする必要がなくなることを忘れてはいけません。
では、本日お話しした内容を実際に始めるにはどうすればよいでしょうか？画面にいくつかのQRコードを表示しています。1つ目は、新しいSystems Managerエクスペリエンスに関するアナウンスブログへのリンクです。2つ目は、実際にアカウントでプロビジョニングすることなくクリックスルーで見られるビジュアルデモへのリンクです。そして3つ目は実践的なワークショップです。実際に試してみたい場合は、アカウントチームと協力して、お客様の環境外のサンドボックスとしてAWSアカウントを用意し、本日お話しした内容をすべて体験していただくことができます。
Cloud Opsキオスクでお会いできればと思いますが、45分で終了してしまいます。テレポートできる方は、キオスクで担当者とお話しいただけます。改めて、本日のセッションにご参加いただいた皆様に心より感謝申し上げます。Orenと私は、セッション後も質問などございましたらお答えいたしますので、お気軽にお声がけください。ありがとうございました。re:Inventの残りの日程もお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion