re:Invent 2024: AWS Systems Managerでマルチクラウド管理を一元化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Centralize multicloud management using AWS (COP321)
この動画では、マルチクラウド環境でのオペレーションの一元化について、架空の企業Octankの事例を通じて解説しています。AWS Systems Managerを使用した複数環境の統合管理や、CloudWatchとPrometheusを活用した可観測性の実現方法を、実際のデモを交えながら紹介しています。特に、AzureやGCPなど他のクラウド環境からAWSへのデータ統合方法や、IAM Roles Anywhereを使用した認証の仕組みなど、具体的な実装方法を詳しく説明しています。Phillips 66での導入事例では平均解決時間30%削減を達成し、Rackspaceでは10万台以上のサーバー管理を実現するなど、実践的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
マルチクラウド環境でのオペレーション一元化：AWSの定義と本日の目標
ようこそ。本日はマルチクラウド環境でのオペレーションの一元化についてお話しさせていただきます。まず、AWSでの「マルチクラウド」の定義からお話ししたいと思います。私たちは、複数のクラウド環境で重要なワークロードを実行している状態を「マルチクラウド環境での運用」と定義しています。SaaSアプリケーションもマルチクラウドに含める方もいらっしゃいますが、私たちはワークロードに焦点を当てています。
皆様のお顔が見えないので、まず、現在マルチクラウド環境で運用されている企業の方は声を上げていただけますでしょうか。そういった方々は、まさに適切な会場にいらっしゃいますね。複数の環境での運用に興味がない方は、声を上げるか、退室していただいても構いません。誰も退室されないようですね。まあ、実際には見えないので、退室されても分かりませんが（笑）。
それでは始めましょう。本日は、マルチクラウド環境での運用における追加コストと複雑さへの対処方法についてお話しします。かなり内容の濃いアジェンダをご用意しています。まず、本日のプレゼンテーションのために作成した架空の企業「Octank」についてご紹介します。彼らのユースケースについてお話ししますが、かなり一般的なものなので、皆様にも共感していただけると思います。私は日々マルチクラウドのお客様をサポートしており、これからご紹介するユースケースは、そうしたお客様の経験から得られたものです。
マルチクラウドの運用と可観測性について、私たちがどのようにお客様をサポートしているかをご紹介し、架空の企業の結果（実際には名前を出せない実在のお客様の結果を反映したもの）をお見せします。その後、情報公開の許可をいただいた実在のお客様の実際の結果もご紹介します。最後まで聞いていただければ、職場に戻ってすぐに実装できるリソースと情報もご提供します。
本日の目標を改めて申し上げますと、これは本当に皆様のためのセッションです。私たちは実験的なプロジェクトや非現実的なものをお見せするつもりはありません。本日ご紹介する内容は、すべて今日この会場を出てから、あるいは会場にいる間にでも、すぐに使い始めることができるものです。 これらはすべて、現在お客様が実際に使用している手法に基づいています。また、Richがライブデモもお見せします。ライブデモですので、うまくいくことを願っていますが...ご存知の通り、ライブデモですからね。
架空企業Octankのマルチクラウド課題とキャラクター紹介
Octankについてお話ししましょう。これは様々な事業に手を広げている大企業です。OctankがM&Aに関して解決している課題についていくつかお話しします。あるクラウドを主に使用している企業が、別のクラウドを使用している企業を買収した場合、これらのワークロードを移行するかどうかの判断を迫られるというケースを考えてみてください。規制要件も私たちがよく耳にする一般的なユースケースです。実際の規制要件である場合もあれば、そう認識されている場合もあり、また将来的に発生すると予想される規制に備えているという場合もあります。
Octankをモデルケースとして使用していきます。OctankはContoso、Northwind、Acmeのような、大企業が直面する典型的な課題を抱えた大規模企業だと考えてください。ホワイトラベルサイト、Eコマース事業、小売事業、そしてデリバリー事業も展開しています。そう、箱付きスクーターに乗って、一方通行の道を逆走している、あのデリバリー配達員たちのことです。それが私たちです。
ちなみに、このキャラクターの名前はTiです。名前を付けるときにあまり創造的な気分ではなかったので、実は自分では作らずにモデルを使用しました。これによってプレゼンテーションがずっと簡単になりました。でも心配しないでください。これは生成AIについての全体的なセッションではありません。本当に運用管理に焦点を当てたものです。 Richは、octやoctopusという言葉の代わりに、セッション全体でcephalopod（頭足類）という言葉を使うように言ってきましたが、私は「いやだ」と言いました。これはoctというタコです。そんな長い言葉は使いません。
Clodはいい言葉ですね。私はOctのCTOで、明らかにテクノロジーに非常に熱中している人間です。テクノロジーが大好きで、正直なところ、いつも自分自身とチームの仕事を自動化しようとしていますが、一度も成功したことがありません。なぜなら、単純な問題を解決した後は、常により興味深い問題に取り組むことになるからです。そして、ビジネスサイドを代表するEllieがいます。「私はお金と株主価値を気にしています。Royよ、あなたのサイエンスプロジェクトやつまらないギーク的なものに、そんなにお金を使わないでください」と。
私たちは確かに常に意見が一致するわけではありません。 そして、私たちが目にしているのは、AWSがテクノロジー企業であるため、AWSはテクノロジー面だけに注力していると思われがちですが、実際はそうではありません。AWSでは、多くのベストプラクティスや戦略的なガイダンスを得ることができます。AWSは、テクノロジー側とビジネス側の両方を代表する私とRegが、この2つの部分を組み合わせて魔法を起こすのを手助けしてくれます。一般的に、彼女は本当に理解していないと思います。システムを稼働させ続けるにはお金がかかるのです。大変なことですよ。時には少しお金を出さなければならないんです。
Systems Managerを活用したマルチクラウド環境の管理
では、ここからどう進めていきましょうか？さっそく話を進めていきましょう。皆さんは今からOctankの社員となります。おめでとうございます。皆さんをお迎えできて大変嬉しく思います。これは本当に素晴らしいことです。新入社員の皆さんを見てください。これから素晴らしいものをたくさん作っていただけることでしょう。ちょっと待ってください。Richのような方、つまりビルダーやテクニカルな方は声を上げてください。そういった分野に関心がある方ですね。では、ビジネスや戦略に関心がある購買側の方は、もっと大きな声で反応してください。そういう方はどのくらいいらっしゃいますか？もっと声を出してください。素晴らしいですね。あ、手を下ろした方々はカウントに入れませんよ。
OctankはNorthwindと合併しましたが、Northwindは別のクラウドで運用していて、私たちは慎重に検討した結果、そのワークロードをAWSに移行しないという決定を下しました。そこには多くの正当な理由がありました。Northwindには、現在のクラウドでの運用を継続することを求める顧客との契約があったのです。また、彼らは多くのネイティブサービスを使用しており、すべてを再設計して移行することは現実的ではありませんでした。さらに、人材のスキルや専門知識を失い、全員を再トレーニングする必要性も考慮しました。この状況に心当たりがある方はいらっしゃいますか？同じような状況に直面している会社の方はいらっしゃいますか？多くの方にとって、これは日常的な課題なのではないでしょうか。
このような状況が、マルチクラウド管理が必要とされる理由です。私たちは可能な限り早くクラウドへと移行し、データセンターを完全に閉鎖しました。もう戻りたくありません。不動産ビジネスに関わりたくないのです。それは私たちにとって良い選択ではありません。しかし、ツールの切り替えやこの多様な環境の運用は問題を引き起こしています。率直に言って、私たちが発見したのは、特にセキュリティ目標において、あるツールや運用チームから別のものへの切り替えに伴う時間のロスやコンテキストスイッチングによってリスクが生じる可能性があるということです。そのため、効率化と簡素化が必要です。そしてRichが素晴らしいものを作り続けることは、ビジネスサイドから見ても明らかに望ましいことですよね？
より多くの収益を生み出し、より多くの顧客を獲得できます。そのため、私たちは確実にサポートが必要です。まさにカップルカウンセリングが必要な状況ですね。それでは、AWSがこの点でどのようなサポートを提供しているかについて少しお話しし、その後でOctankの世界に戻りたいと思います。これは2016年以降にAWSがリリースしたマルチクラウドまたはハイブリッド対応機能の主要なものを簡単にまとめたものです。2016年初めのSystems Managerから始まりますが、これは実際には18の異なるサービスのようなものです。その中には多くの機能が含まれており、今日はその一部をご紹介します。ご覧の通り、時間とともに継続的なリリースが行われてきました。AWSはお客様のいる場所で対応することを望んでおり、時にはそれは他のクラウドを意味することもあります。
現在に近づくにつれて、他のプロバイダーのサービスが別の色で強調表示されているのがお分かりいただけると思います。2、3年前と比べて、他のクラウドプロバイダーのプラットフォームやサービスと直接やり取りする機能が増えています。今日ご紹介する内容の多くはエージェントベースですが、それだけにとどまらないことをご理解ください。2024年のことや、マルチクラウドサポート付きのClean Roomsについてはここに含まれていないことは承知しています。これらのスライドは2ヶ月前に作成する必要があり、そういうものなのです。2024年を無視したいと思っているのは、皆さんだけではないでしょう。
IAM Roles AnywhereとCloudWatchによる可観測性の実現
AWSサービスを技術的な観点からどのように活用していくのか、お話ししていきましょう。ここでは2つの視点から見ていきます。1つ目は、運用管理、パッチ適用、リモートアクセス、そして様々な場所に存在するマシン全体でのスクリプト実行についてです。その後、可観測性について詳しく見ていきます。 まず、基本的な部分から説明させていただきます。他の環境からAWSにアクセスする方法として、2つのアプローチをご紹介します。1つ目は、AWS Systems Managerを使用する方法です。このアプローチでは、他のクラウドやオンプレミス環境にSystems Managerエージェントをインストールします。このエージェントは資格情報ブローカーとして機能し、IAMロールに紐付けられた30分間有効なトークンをローカルファイルシステムにキャッシュします。
これらのトークンはローカルファイルシステムから取得できます（ただし、権限には十分注意してください）。そして、そのロールに付与されているサービス、例えばS3、SageMaker、Bedrock、OpenSearchなど、必要なサービスにアクセスすることができます。これは非常に一般的なアプローチで、最新の統計では約3,000万台の同時接続サーバーがSystems Managerで管理されています。 ただし、これが唯一の方法というわけではありません。今日はデモでは扱いませんが、現在パッチ適用やメンテナンス、リモートアクセスなどのソリューションをお持ちの場合、この機能を利用するためにSystems Managerを使用する必要はありません。証明書ベースの認証アプローチである、IAM Roles Anywhereを使用することもできます。
後ほどのスライドで詳しくご紹介しますが、今回のデモでは実際には使用しません。要するに、AWS APIへの安全なアクセスのための短期的な認証情報を取得する2つの主要なオプションがあり、ニーズに応じて最適な方法を選択していただけます。 また、他のクラウドを使用する際の重要なポイントとして、クラウドサービスプロバイダーの環境へのインターネットアクセスに関して、特定の要件をお持ちの方もいらっしゃるでしょう。インターネット経由でのアクセスが許可されていない場合でも問題ありません。これらのツールはすべて、VPNやDirect Connectを通じて使用することができます。選択は完全にお客様次第です。Systems ManagerやRoles Anywhere、その他本日お話しする内容について、パブリックエンドポイントへのインターネット経由での直接アクセスを強制されることは一切ありません。
デモでは、以下のような課題の解決方法をご紹介します。まず、コンテキストスイッチングの問題です。より少ないツールセット（この場合はAWSのツール）を使用することで、セキュリティデータへのアクセス遅延を低減し、インシデント管理を迅速化できます。Northwindを買収した際、私たちは彼らが持っているものの詳細な一覧を受け取れませんでした。数千台のサーバーが様々な状態で存在していることが分かり、それは誰にとっても予想外でした。インベントリの把握が非常に重要でしたが、それはパッチ管理（あるいはその欠如）において特に顕著でした。少し不安な状況でしたが、幸いにも解決策をご用意しています。
また、パブリックインターネット上で運用されているサーバーもありました。DMZではありませんが、それでも直接RDPやSSHでアクセスしている状況でした - これは良くありません。二度とこのようなことは行わないでください。私たちはClickOpsを嫌っています。自動化重視のアプローチを取っており、オンプレミス、Azure、GCPなど、場所を問わず、環境全体にわたってサービスに変更を適用する方法の1つをお見せします。ほぼすべてを自動化することが可能です。
それでは、デモに移らせていただきます。 はい、うまく動いていますね。 ここには多くの内容がありますが、まずはAWS Consoleから始めていきましょう。私の管理インスタンスのうち、どれがコンプライアンスに準拠しているかが一目で分かります。ご覧の通り、あまり良い状態とは言えませんね。非準拠のサーバーがたくさんあります。「私の真似はしないでください」という感じですが、実はこのようなデモのために、わざとデモ環境を壊れた状態にしているんです。
これは新しいNode Insightsビューです。確か日曜日にローンチしたばかりだと思います。ここでは、私の環境を構成する16のノードの概要が表示されています。 これにはAzureの複数のノード、GCPの1、2個のノード、そしてオンプレミス環境に6つのノードがあります。数字が完全には合っていませんが、ご容赦ください。この環境に何があるのかが非常に分かりやすく表示されています。
次に何をするのかについて詳しく見ていきましょう。ビデオを見つけます。今日は他のクラウドプロバイダーでの作業をお見せする際に、インターネットに頼らないことにしました。 実際に録画したものを使います。普段はそうしないのですが、今日は特別です。これは私がVMを作成している様子です。人生で見た中で最も刺激的な光景というわけではありませんが、 これが実際に私が先日行ったプロセスだということをご理解ください。これは月曜日に録画したもので、他のいくつかは2時間前に録画したものもあります。 はい、うまくいきましたね。そうそう、私はあんなに速くタイプできません - 再生速度を上げているんです。
さて、AzureでこのVMを作成した後、 Systems Managerに追加するプロセスを見ていきましょう。最初に行ったのは、IPアドレスをコピーして、直接SSHで接続することです。インターネット経由でのSSH接続は避けるべきと申し上げましたが、これはまだSSMに追加していないため、特別に許可している唯一のケースです。そのため、ここではまだ管理できません。私が行っているのは、Hybrid Activationと呼ばれるものの作成で、これはSystems Manager Consoleの左側のナビゲーションにあります。
名前を付けます - これはオプションなので、必須ではありません。これにより、そのリモートノードでアクティベーションを実行するために使用されるキーが作成されます。 必要に応じて、一度に何百台のサーバーでもこれを実行できます。実際、Systems Managerを導入するお客様の多くは、このように大量のサーバーを一括でオンボードしています。ここで一旦止めますね。 上部に表示されているのは - 少し小さいですが問題ありません。また、写真を撮っても構いません、これらはすでに期限切れですが - Activation CodeとActivation IDです。これらは、Systems Manager内でサーバーを実際に登録する際に使用されます。
CloudWatchとGrafanaを用いたマルチクラウドモニタリングのデモンストレーション
はい、それでは始めましょう。なお、これらの設定はAPIを通じても同様に簡単に行えます - 私は通常コンソールすら使用しません。これは、認証情報を貼り付けてAgentをインストールしてアクティベートするために使用していた、シンプルで簡単なスクリプトです。まさにこのような感じです。これ以上複雑なことは何もする必要がありませんでした。全く同じプロセスです。もちろん、PowerShellのみを実行している場合は、bashスクリプトではありませんが。これらすべてを準備した上で、私はこれをコピーして仮想マシンに送信します。とても簡単ですね。実行すると、処理が始まります。最後に、新しいインスタンスIDが出力されるのを確認します。 はい、できました。動画の最後に来ましたが、最後の出力行にMI-0BBで始まる文字列が表示されているのがわかりますね。これがManaged InstanceのID - MIはManaged Instanceの略です。とても簡単ですね。これで、そのサーバーにすぐにアクセスできます。
1BBでしたっけ？ 今見たばかりなのに覚えていませんね。適当に1つ選んでみましょう。 これが月曜日に追加してアクティベートしたマシンです。
ここから、このマシンの中身を簡単に確認できますし、 サーバー全体のインベントリを照会することもできます。後ほどお話しする予定のお客様は、Systems Managerで10万台のサーバーを管理されているんですよ。かなり印象的ですね。このマシンにbashがインストールされているか確認したい場合は、とても簡単な例ですが、 bashがあることがわかります。これは特に驚くことではありませんね。フリート全体で、どのマシンにどのバージョンのパッケージがインストールされているか確認したい場合も、ここから全て見つけることができます。ファイルシステムを参照することもできます。これはかなり便利だと思います。ここから直接ファイルのダウンロードやアップロードもできます。
これは最もスケーラブルなアプローチではありませんが、パフォーマンスカウンターをリアルタイムで表示することができます。問題があるとわかっているマシンがある場合、このようなツールを使ってリアルタイムで対話的に操作できます。実行中のプロセスリストを表示したり、プロセスを終了させたりすることもできます。繰り返しになりますが、オペレーターをコンソールから遠ざけ、サーバーに直接アクセスさせないようにするのがベストなアプローチです。 ここから、何かを終了させたい場合は、プロセス全体を強制終了できます。
しかし、もっと興味深いことができます。このノードにパッチを適用することもできます。 ここから、UAT、本番環境、開発テストなど、様々な環境に適用される完全なパッチベースラインを設定できます。このベースラインを作成し、各環境に順番にパッチを段階的にデプロイするのは非常に簡単です。これにより、不具合のあるパッチによる問題を防ぐことができます。まあ、そんなことは誰にも起こったことがないでしょうけどね。このように1台ずつパッチを適用する方法は最もスケーラブルなソリューションではありませんが、確実に実行できる方法の1つです。 例として、ここから直接パッチを適用できます。これは実行に少し時間がかかりますので、 その間にリモートアクセスについてお話ししましょう。
ここからは、インターネット経由のSSHについて、私は強く反対の立場です。最適なアプローチとは思えません。セキュリティが向上すると考えてSSHのポートを変更する人がいますが、それは本当に意味がありません。ポートスキャンは簡単にできてしまいます。ただ、この環境ではすでにこのインスタンスの中にいるので、topコマンドなどを実行できます。特に面白いことはありませんが、CPUの使用率が高くなっているのが見えますね。これは実はSystems Managerエージェントがこのマシンでパッチ適用作業を実行しているためです。今は基本的なコマンドだけを実行していますが、これらは後ほどログで確認することになります。
実際に何をしたのか見てみましょう。私が設定したのは、コンソールで入力したすべてのアクティビティ、つまりキーストロークのすべてを、CloudWatch のLogグループに送信するようにしたのです。この例では、KMSキーも設定しています。オペレーターのアクティビティやアクセスログを厳重に保護する必要がある場合もあるでしょう。私自身も確実に保護します。では、これらの1つを見てみましょう。これですね。これが先ほど私がそのサーバーでtopコマンドを実行した時の出力です。必要に応じてリアルタイムでストリーミングすることも、セッション終了時にまとめてCloudWatchにドロップすることもできます。
誰がどこで何をしたのかというログ全体を検索する必要がある場合や、誰かがsudoを入力した回数を確認したい場合（これはよく確認されるものですね）、このような方法で実現できます。後ほどログについてもう一度触れますが、今日のセッションではログにそれほど焦点を当てていません。なお、セッションの最後に、KMS暗号化とログを使用したSession Managerのセットアップ方法へのリンクを共有する予定です。
少々お待ちください。こちらの発表用メモを確認させていただきます。メモを拡大して確認しているところです。Patch Managerの状況を確認してみましょう。まだ実行中ですが、問題ありません。どこかに行ってしまうわけではありません。まあ、実際にはどこかに行くはずなのですが、それについては後ほど戻ってきましょう。
AWS Systems Managerの自動化機能についてお見せしたいと思います。これらのノードをすべて見てみましょう。デモ環境内で利用可能なノードの一覧に戻ります。ここにはOctank、Northwind、そして名前のないものがいくつかあります。これらのほとんどはEC2上では動作していません。実は多くが私のオフィスのデスクの下で動作しています。これらすべてに対して、同じ自動化を非常にシンプルに適用することができます。
これらのシステムにアクセスするために私が使用したドキュメントの1つをお見せしましょう。これは、フリート内のすべてのマシンに対して任意のスクリプトを実行するためのフローです。これはビジュアルエディタを使って実現できました。簡単に説明すると、まずSystems Managerアカウント内のすべてのインスタンスをリストアップし、それらすべてをループ処理して、それぞれのプラットフォームを確認します。Windowsかそれ以外かに基づいて、今回はWindowsのアクションを定義していないので何もしないか、あるいはシェルスクリプトを実行します。
この特定のケースでは、syslogというファイルがあるかどうかを確認しています。最近ではsyslogの仕組みが変更され続けているため、すべてのマシンにこのファイルがあるわけではありません。これは少しJournal Controlに関するコメントですね。最後に、その結果をレポートしたいと思います。これには複数のオプションがありましたが、今回の場合は、どのマシンにこのファイルが実際にあるかを示すために、DynamoDBテーブルに少しデータを入れることにしました。
まずDynamoDBテーブルをお見せしましょう。現時点ではアイテムは何もありませんが、このAutomationを実行します。環境全体で実行するためにSimple Executionを選択します。実行すると、私が持っているすべてのマシンで非同期的にこのフロー全体が実行されていきます。これを何回か実行してみましょう。すでに3つのインスタンスが見つかりました。カウンターは時間とともに増えていきます。これは冪等な実行方法です。基本的に、コンプライアンス要件がある場合や、私が今行っているような環境全体で1つのファイルを確認するような単純なタスクの場合でも、必要なすべてのマシンに対して有向非巡回グラフとして実行できます。
これはかなり単純な例ですが、この方法を使って環境を自動化できる可能性は事実上無限にあり、大きな価値があると考えています。このような自動化の出力をJira APIやService Now、あるいは他のシステムと連携させて、そこから得られる情報を理解する必要がある場合を考えてみてください。実際にはどんな方法でも制限されることはありません。
ここで、チェックリストを確認してみましょう。別のクラウドプロバイダーのコンソールにアクセスする必要がなかったため、コンテキストスイッチングが少なくなりました。また、優れた中央インベントリも持っています。インターネットを介したボックスへの直接的なリモートアクセスは不要になりました。Systems ManagerのSession Managerを使用する場合、実際の動作としては、エージェントがサービスへのWebSocketを開くという仕組みになっています。
マルチクラウド管理の利点とAWSサービスの規模
先ほど触れませんでしたが、エージェントはSystems Manager APIへのWebsocketを開き、これを通じて私たちのサービス側からそのマシンへのセッションを開始します。マシンとあなたのラップトップが直接接続することは一切なく、すべてがマネージドサービスを通じて管理されています。クリック操作を省いてコマンドラインだけでこの自動化を実行できるため、より再現性の高い自動化が実現できます。現在Ansibleを使用している方々にとって便利なのは、Systems ManagerでAnsibleスクリプトを実行することもでき、さらにスケールアウトする方法として活用できます。
次に、可観測性についてお話ししましょう。先ほどIAM Roles Anywhereについて触れましたが、同じルールが適用されます。Systems Managerエージェントを使用してサービス用の短期認証情報を取得するか、IAM Roles Anywhereを使用するか、選択は完全にお任せです。Octankを例に見ていきましょう。 OctankにはEC2ノードやサーバーを含む素晴らしいEC2環境があります。AWS内で観測可能なデータを収集し、CloudWatchやPrometheusに送信する方法は、一般的によく使われているものです。
まず、マシン内にエージェントが必要です。今回は特にOpenTelemetryに焦点を当てています。 これはインスタンスメタデータサービスを通じてSecure Token Serviceと通信します。すべてのEC2インスタンスはロールと認証情報を取得し、その認証情報を使用して可観測性プラットフォームの残りの部分へのすべてのAPI呼び出しを行います。これは皆さんが一般的に行っていることです。しかし、もし何か異なることをしたい場合、例えばAzureでAKSクラスターを実行し、同じようなデータをPrometheusやCloudWatchに送信したい場合はどうでしょうか？そして、このケースでAKSで管理されているノードにSystems Managerエージェントを簡単に導入できない場合はどうすればよいでしょうか？
朗報です - IAM Roles Anywhereを使用できます。ただし、認証チェーンは少し異なります。Prometheusの場合、次のように動作します。今日はPrometheusとPrometheusプロジェクトについて頻繁に言及していますが、これは非常に人気があるからです。PrometheusはIAM Roles Anywhereの一部である認証情報ヘルパープロセスと通信します。その認証情報ヘルパーは証明書をAWS内のIAM Roles Anywhereサービスに提示します。この例では、AWS Private CAサービスを使用して証明書に署名していますが、必ずしも私たちのCAを使用する必要はなく、お客様独自のCAを使用することもできます。
提示された証明書が正常に検証されると、AWS Secure Token Serviceがこの目的のために作成したロールにマッピングされた認証情報を発行します。認証情報は認証情報ヘルパーを経由して返され、このAKS環境から直接AWSの可観測性サービスにデータをプッシュできます。いくつかの追加手順が必要ですが、一度設定すれば完了です。 このケースでOctankが解決したかった問題には、事業部門をまたぐダッシュボードがありました。これはNorthwind側とOctank側で何を持っているか、そして2つの異なるクラウドプロバイダー間でのデータの統合を1つのツールセットで実現できるかという課題でした。また、ビジネスリーダーへの運用メトリクスの公開も課題でした。AWS認証情報を渡して「ログインして楽しんでください」とは言えません - それは良くないシナリオです。経営陣にそのようなことは言えません。この場合、CloudWatch、Prometheus、Azure Monitorからのメトリクスが混在しています。最後に、Kubernetesはオンプレミス、Azure、AWSなど、あらゆる場所に存在しており、これらすべての異なる場所からの中央集中型アラートが必要でした。では、デモに戻りましょう。
AKSとPrometheusを活用したマルチクラウドモニタリングの詳細
それでは、パッチ適用作業を見ていきましょう。素晴らしいですね。 次にCloudWatchに移動します。まず最初にDashboardsに移動して、 このダッシュボード画面と他のCloudWatchのコンポーネントを行き来しながら説明していきます。 まず簡単に概要を見てみましょう。ここには何が表示されているでしょうか？AKSで利用可能なコア数、Ready状態のAKS Pod数が表示されています。Prometheusのデータらしきものも見えますね。これらについて順番に見ていきます。
しかし最初に、 分散環境において重要となる2つのサービスについてお話ししたいと思います。Internet Monitorについては今日は詳しく説明しませんが、少しだけ触れておきましょう。AWSには、私たちが「インターネットの天気」と呼んでいるものを統合できるサービスがあります。AWSに直接アクセスするワークロードがある場合、世界中のプロバイダーで運用上の問題が発生した時に検知することができます。例えばここで見られるように、British Telecomで問題が発生したり、Hyderabadのプロバイダーで問題が発生したりした場合です。実際に、送信元IPアドレスとワークロードを実行しているVPCに基づいて観測されたトラフィックと、これらの問題を組み合わせて表示することができます。
CloudWatch内でこのような情報を提供し、実際の運用上の影響をより詳しく把握できることを覚えておいてください。ただし、今回の議論でより重要なのは、 Synthetic Monitoringです。ここでは、OctankのAWS環境からNorthwindのAzure環境へのVPN接続があります。このVPNを通じて、往復時間などを測定することができます。 下に表示されているこれらのプローブは、それぞれ特定のAvailability Zoneから開始されるため、ある環境から別の環境のターゲットへのアクセスに影響があるかどうかを確認することができます。これはAzureでも、オンプレミス環境でも同様に機能し、VPNを完全に通過することができます。
では、ダッシュボードに戻って、これらのメトリクスの1つを実際に見てみましょう。 これはReady状態のPod数を示しています。 このメトリクスを生成したクエリを見てみると、 CloudWatchでメトリクスを参照する際に通常見られるものとは異なることがわかります。Azureのサブスクリプションのように見えますね。実際その通りです。
まず、これをどのように設定するかをお見せし、その後でクエリがいかに簡単かをお示ししましょう。Settingsに移動して、 Metric Data Sourcesビューを見ると、Azureのデータソースとre:Inventという別のデータソースがあることがわかります。後者は実際にはPrometheusインスタンスです。 これについては後ほど説明します。CloudWatchメトリクスをAzure Monitorにリンクしたい場合は、 新しいデータソースを追加するだけです。利用可能なデータソースが多数あり、必要に応じて独自のものを作成することもできます。Azure Monitorを選択すると - はい、このように表示されます。テナントとシークレットを入力するだけで準備完了です。これらの認証情報はAWS Secrets Managerに保存されるので、必要に応じて随時更新することができます。
今からその全てを説明するのは少し時間がかかりすぎるので、別の方法をお見せしたいと思います。Metricsビューに戻って、別のクエリを実行してみましょう。グラフをクリアして、Azureと対話してみましょう。 現在、私のサブスクリプションは1つだけです。以前はもっとたくさんありましたが。では、デモ用のリソースグループを見てみましょう。 仮想マシンがありますね。最も基本的なメトリクスであるCPUを見てみましょう。
平均値を取ってみましょう。 この表示はゲージとして表示されるべきではないので、ビューを変更する必要がありますね。 はい、完璧です。ただし、完璧に退屈でもありますね。というのも、このサーバーでは特に面白いことが何も起きていないからです。デモとしてはあまり面白くないかもしれませんが、このように、Azure Monitorから直接メトリクスデータを取得することができます。これは裏側でLambda として動作しており、CloudFormationを使ってデプロイされていますが、全てCloudWatchコンソールを使って構築されているので、皆さんも非常に簡単に実装することができます。
それでは、Podについてもう少し詳しく見ていきましょう。もう一つ短いデモをお見せします。AKSからデータを取得してAmazon Web Servicesにプッシュする方法についてです。ここで行っているのは、通常の AKSコンソールを開いているところです。ご覧の通り、特に面白いことは何も起きていません。デモ用に2つのノードがあるだけです。 Cloud Shellを開いて、kubectlを使ってこのクラスター内で何が起きているのかを簡単に確認してみましょう。「キューブシーティーエル」と呼ぶ人もいますが、私は「キューブカドル」と呼ぶのが好きです。私の頭足類テーマに合っていると思います。
これは、Cloud Shell環境に認証情報を入力しているところです。ノードをリストアップして、実際に存在することを確認します。素晴らしい、問題ありません。画面上では少し歪んで見えるかもしれませんが、大丈夫です。説明していきますね。これは、このクラスター内で動作しているPrometheusの設定を確認しているところです。そして、ここで強調したいのが、このリモートライトURLです。このURLは実際にはAmazon Managed Prometheusのエンドポイントなんです。このクラスターにはCloudWatchエージェントもSystems Managerエージェントもインストールしていませんが、このアプローチを使ってPrometheusに直接データをプッシュすることができます。単にhelm installでPrometheusサーバーをインストールしただけの簡単な作業です。
そのダッシュボードに戻ってみましょう。このデータを見てみると、これがAKSで動作しているhelmでインストールしたPrometheus node serverから送られてくるロードデータです。CloudWatchに取り込まれると、AWS内で動作している他のものと同じように、CloudWatchアラームを使ってアラートを作成することができます。その時点では全く違いはありません。ただし、ここでは他にも興味深いことが起きているので、手短に強調しておきたいと思います。VPNデータのモニタリングもありますが、それは特に面白い部分ではないかもしれません。でも、もっと面白いことをしたい場合はどうでしょう？例えば、必要に応じてPrometheusからCloudWatchに移行するといったことです。状況によってはそれが理にかなっているかもしれません。
これは確実に評価が必要な事項ですね。それでは、お馴染みの Systems Manager に戻って、私が「monitor」と呼んでいるマシンを見てみましょう。はい、こちらです。 これは Debian マシンですね。 今回は root で作業を進めていきます。これは「私の真似はしないでください」という典型的な例です。この特定のサーバーでは CloudWatch エージェントが 実行されており、私はこれを Prometheus のコレクターとして使用して、この環境全体をスクレイピングしています。では、Prometheus の設定を少し見てみましょう。これは標準的な設定のように見えます。 Prometheus ですね。いくつかの Rebel が実行されていて、送信するデータを慎重に選別していますが、ここには remote write URL が存在しません。では、このデータで何をしているのでしょうか？
CloudWatch に移動してメトリクスに戻り、 グラフをクリアしてブラウズに戻ると、メトリクス内に たくさんのサーバー名を含むこのような名前空間があります。先ほど見ていたものと同じように見えますね - Ubuntu 2024、Firewall、Fedora などです。これを少しフィルタリングしてみましょう。ここに5台のサーバーがあります。Systems Manager に戻ると、同じ5台のサーバーが表示されています。
これが魔法のような仕組みです。Prometheus が実行されているか確認してみましょう。答えは実行されていません。 実際には、CloudWatch エージェントの中に Prometheus を組み込んでいるのです。 先ほどお見せした設定は、これらのエンドポイントからスクレイピングしたデータを直接 CloudWatch に送信し、CloudWatch 内のカスタムメトリクス用のカスタム名前空間に追加されています。そこに格納されると、他のメトリクスと同じように扱うことができます - アラームを作成したり、異常検知を使用したりできます。すべての機能が利用可能です。
このデータを送信する方法として、Embedded Metric Format というフォーマットを使用しており、実際にはログをトランスポートとして使用しています。これらのいくつかを展開してみましょう。 ここで Embedded Metric Format（EMF）をご存知の方はいらっしゃいますか？手が挙がらないようですね。これは実は CloudWatch の非常に素晴らしい機能です。適切に構造化されたデータを CloudWatch に送信すると、自動的にメトリクスを抽出して適切な場所に配置できます。この特定のケースでは、値がゼロというあまり面白くないメトリクスデータがありますが、このログベースのフォーマットを通じてメトリクスに追加されています。
アプリケーションが EMF を書き出すように設定されていれば、あなたのアプリケーションでも同じことができます。CloudWatch Logs に到達する限り、アプリケーションレベルのメトリクスを非常に簡単に作成できます。ビジネスワークロードデータを運用メトリクスデータと統合して、相関関係を分析できるようにすることを常に考えるべきです。ウェブサイトでの購入、金融取引、動画視聴など、すべてがメトリクスデータポイントとなります。
私はここでCloudWatchを使って多くのことを行ってきましたが、CloudWatchだけに限定されているわけではありません。もう一度dashboardsに戻って、このインフラストラクチャーダッシュボードを見てみましょう。 3時間にわたるload averageなどのデータがあります。Prometheusや Azureからのデータも入ってきており、とても良い感じです。でも、このデータを非技術者の方々に見てもらいたい場合はどうすればいいでしょうか？ 通常、お客様はGrafanaのようなツールを使用しますが、私も実際にそうしてみました。 同じデータソースを使って、全く同じダッシュボードをGrafanaで再現したんです。実際、両者を行き来して見比べてみると、全く同じデータであることがわかります。非技術者の方々にこのようなデータを見てもらいたい場合、Grafanaを使えばAWSコンソールにアクセスする必要がありません。これはAWS Managed Grafanaですが、オープンソースのGrafanaでも同様のことができます。先ほど申し上げたように、インフラメトリクスだけでなく、データベースビューの統合についても考える必要があります。
この統合されたデータベースビューは、全く同じアプローチで活用できます。 部門を横断したメトリクスを取得できます。現在101人のエージェントが対応しているCSR、メールのバウンス率、OctankとNorthwindを合わせた売上データなど、すべてを1つのビューにまとめることができます。これらは重ねて表示することができ、CloudWatchコンソールを使って同じアプローチで実現できます。このアプローチを使って運用メトリクスをビジネスサイドに公開することを強くお勧めします。非常に有用だからです。
部門横断的なダッシュボードについて、かなり良い進展が見られていると思います。3つの異なる環境からのデータが1か所に集約され、簡単に閲覧できるようになっています。 シングルペインオブグラス（single pane of glass）、あるいはシングルグラスオブペイント（single glass of paint）と呼びましょう。 シングルペインオブグラスと言えば、これを1つの成果と呼べると思います。Systems Manager用とObservability用の2つがあり、ビジネスサイドにとって非常に役立ちます。ツールが少なくなることで、頭痛の種も減ります。
ツールの統合は多くの場合、良いことです。私たちは摩擦を減らし、より速く動けるようにし、より多くの自動化を可能にする方法でそれを行っていると考えています。 それは確実にコストを削減し、クラウドのセキュリティ管理態勢を改善します。そして、もう誰もSSHでサーバーにアクセスする必要がありません。絶対にそうしないでください。クラウドネイティブなオープンソースのマネージドサービスを使えば、他のサーバーを管理するためのサーバーを用意する必要はありません。 そして最後に、より多くのイカがいます。TIは食べられません - いや、絶対に食べられます。とてもおいしいですよ。
では、実際のお客様の成果についてお話ししましょう。昨年、私はre:InventでPhillips 66と一緒にステージに立ちました。彼らがAmazon Managed GrafanaとAmazon Managed Service for Prometheusを使用して達成した運用改善の数字は、平均解決時間が30%削減というものでした。これは驚くべき数字です。彼らのペルソナベースのダッシュボードは素晴らしいものでした。このアプローチを使用して5,000台以上のサーバーを運用しており、その大部分はKubernetesベースですが、すべてではありません。実際にその様子を記録した動画がありますので、ご興味のある方はご覧ください。また、先ほど触れましたが、RackspaceはSystems Managerを使用して10万台以上のサーバーを管理しており、これは非常に素晴らしいことです。
実際の顧客事例と追加リソースの紹介
これらのサービスの利用状況から、驚くべき数字が出ています。CloudWatchは月間11兆個のメトリクス観測値を処理しています - この数字は想像もつきませんね。Systems Managerは毎週3,000万のインスタンスを同時に管理しています。リンクをご紹介する前に、4つのリンクがありまして、そのうち2つは本日ご紹介した内容のセットアップ方法について説明したブログ記事です。残りの2つはブログ記事ではありませんが、さらに詳しい情報が得られます。
これらの情報の多くが掲載されている、ハイブリッドおよびマルチクラウドのウェブページをご覧いただけます。また、ブログへのリンクも用意しています。マルチクラウド環境に関する問題解決のサポートや、戦略的なサポート、ベストプラクティス、技術情報など、私たちのチームがお手伝いできることがありましたら、アカウントマネージャーにご相談ください。担当者が私たちに連絡してくれます。 ここに2つのリンクがあります。1つ目は、Session ManagerでKMS暗号化とCloudWatchログを設定する方法についてで、これは強くお勧めしますし、間違いなくベストプラクティスだと考えています。2つ目は、AWSとAzureのワークロードを1か所で監視する方法を説明したもので、CloudWatchでAzure Monitorの設定を行う方法について詳しく解説しています。また、問題が発生した場合のデバッグのヒントも含まれています。簡単に言えば、通常はトークンが逆になっているのが原因ですが、修正は簡単です。
予定より4分早く終わりましたので、質問を受け付ける時間があります。ただし、会場内を回るマイクはないので、質問がある方は大きな声でお願いします。録音のために質問を繰り返させていただきます。照明が非常に明るいため、皆さまのお顔がよく見えないのですが。セッション終了後、私たちは会場の外におりますので、お話しされたい方はぜひお越しください。本日学んだことを試してみて、うまくいった場合もそうでない場合も、サポートが必要な場合は、LinkedInで私たちを見つけてください。私はEllieで、こちらはRichです。本日はご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion