Amazon Web Services ブログ
Amazon CloudWatchでAzureとAWSのワークロードを同時に監視する
概要
クラウドアプリケーションとサービスを効果的に運用するには、監視とオブザーバビリティに重点を置く必要があります。チームにとって、メトリクスの定義、キャプチャ、分析、オペレーションの可視性の確保、ログから実用的な洞察を抽出することが重要です。
多くの企業では、技術チームがインテグレーションシステムを共有して、管理するサービスやインフラストラクチャを監視しています。共有されたオブザーバビリティシステムは、組織のパフォーマンスと可用性のデータを統合します。これにより、チームはサービスとコンポーネント間の関係を視覚化できます。チームはリアルタイムのデータを利用して共同作業を行い、パフォーマンス、可用性、またはセキュリティ問題の原因を迅速に特定します。
ワークロードがさまざまなクラウドで実行されるマルチクラウド環境では、一元化されたオブザーバビリティソリューションを作成すると、アプローチがサイロ化され、複雑さが増し、直接的および間接的なコストが増加する可能性があります。マルチクラウド環境でワークロードを実行するお客様にとって、全体像を把握し、統一された方法で監視を行うことは非常に重要です。
AWS は、ハイブリッド環境やマルチクラウド環境におけるモニタリングとオブザーバビリティの改善に役立ついくつかのサービスを提供しています。これらのサービスの1つが Amazon CloudWatch で、AWS、オンプレミス、その他のクラウド上のリソースとアプリケーションの状態を監視するのに役立ちます。
この記事ではAmazon CloudWatch の機能を使い、 Azure Monitor からのメトリクスデータクエリを使用して、マルチクラウド環境のワークロードを監視する方法を紹介します。
この機能により、ハイブリッド環境やマルチクラウド環境で実行されるワークロードや、独自のカスタムデータソースを可視化できます。Amazon EC2 インスタンスと Azure 仮想マシンの両方からの CPU 使用率などのデータを同じダッシュボードでクエリして視覚化し、このデータからアラームを作成できます。
図 1. 機能の概要
CloudWatch データソースは、メトリクスクエリを実行する AWS Lambda を利用しています。クライアントシークレットや Azure サブスクリプション ID などのリモート認証情報のストレージは、AWS Secrets Manager によって管理されます。AWS CloudFormation はこれをユーザーに代わってスタックとして作成します。このアプローチは拡張可能なソリューションを生み出します。メトリクスデータソースの同じフレームワークに基づいて構築されています。このフレームワークにより、Amazon S3 の CSV ファイルのデータや、Amazon Managed Service for Prometheus のメトリクスを CloudWatch に組み込むことができます。他のデータソースの詳細については、ドキュメントを参照してください。
前提条件
- AWS アカウントを保有していること
- Owner 権限を持つ Azure アカウントのサブスクリプションを保有していること
ステップ 1. Microsoft Entra ID ポータルで「アプリの登録」を作成する
Azure メトリクスデータを Amazon CloudWatch にインテグレーションするには、Azure テナントから「アプリの登録」を作成する必要があります。このプロセスについては簡単に説明しますが、この記事では Azure ロールベースのアクセス制御 (Azure RBAC) や特定のセキュリティとガバナンスのニーズに関する詳細は説明しません。
ここで説明するプロセスを実装する前に、必ずレビューして、セキュリティ要件を満たしていることを確認してください。この設定では、Amazon CloudWatch のサブスクリプション内のすべてのリソースへの Reader アクセスをモニタリングできることに注意してください。
- クラウドアプリケーションの管理者として Microsoft Entra 管理センター にサインインします。
- 「ID」 メニューを選択し、次に「アプリケーション」を選択し、「アプリの登録」を選択します。
- 「新規登録」を選択します。
- 名前 (例: Amazon CloudWatch) を入力し、ユースケースに合ったテナントオプションを選択します。これはデフォルトの 「この組織ディレクトリのみに含まれるアカウント (既定のディレクトリ のみ – シングル テナント)」設定のままにします。
- 「登録」 を選択します。
- 「証明書とシークレット」メニューを選択し、「新しいクライアントシークレット」を選択します。
- 「説明」 と 「有効期限」 を入力します。
- このシークレットは、有効期限が切れる前に AWS 側で更新する必要があることに注意してください。
- 「追加」を選択します。
- 「値」をコピーして安全に保管してください。これは、パスワードやその他のアクセストークンに似た機密性の高い文字列です。
- 「概要」メニューから次のフィールドをコピーします。
- アプリケーション (クライアント) ID
- ディレクトリ (テナント) ID
「アプリの登録」を作成したら、次のステップ 2 で Azure サブスクリプションからデータを読み取る権限を付与する必要があります。
代替方法: Azure CLI を使用してアプリ登録を作成する
このコマンドは、単一テナントの「アプリの登録」を作成します。
az ad app create --display-name 'Amazon CloudWatch' \
--sign-in-audience 'AzureADMyOrg'前のコマンドから返された ID を以下の引数に置き換えます。
az ad sp create --id 'ID'引数の ID を、以下の引数の最初のコマンドの ID に置き換えます。
az ad app credential reset --id 'ID'出力に表示されるパスワードは、Amazon CloudWatch の設定に使用されるため、書き留めておきます。
代替方法: Azure PowerShell を使用してアプリの登録を作成する
このコマンドは、単一のテナントの「アプリの登録」を作成します。
New-AzADApplication -DisplayName "Amazon CloudWatch" -SignInAudience "AzureADMyOrg"前のコマンドから返された App_ID を以下の引数で置き換えます。
New-AzADServicePrincipal -ApplicationId "App_ID" 最初のコマンドから返された ID を以下の引数に置き換えます。
New-AzADAppCredential -ObjectId "ID" | Format-Listシークレット値は Amazon CloudWatch の設定に使用されるため、書き留めておきます。
ステップ 2. ポータルで Azure サブスクリプションにアクセス許可を付与する
- Microsoft Azure Portal にサインインし、グローバル検索ボックスで 「サブスクリプション」を検索します。
- Amazon CloudWatch とインテグレーションしたいサブスクリプションを選択します。
- メニューから「アクセス制御 (IAM)」を選択し、次に「追加」を選択し、「ロールの割り当ての追加」を選択します。
- リストから「Monitoring Data Reader」を選択し、「次へ」を選択します。
- 「メンバーを選択する」を選択し、「アプリの登録」の名前を入力します。
- 名前を入力するまでリストに表示されない場合があることに注意してください。「アプリの登録」の名前を選択し、「選択」をクリックします。
- 最後に、「次へ」を選択し、「レビューと割り当て」を選択します。
これらの権限が適用されていることを確認するには、サブスクリプション内の他のリソース (仮想マシンなど) の IAM ページを確認してください。
代替方法: Azure CLI を使用して Azure サブスクリプションにアクセス許可を付与する
以下のコマンドの Subscription_ID をサブスクリプションに置き換え、app_ID を上記で使用した az コマンドの出力に置き換えます。
az role assignment create --role 'Monitoring Data Reader' \
--scope '/subscriptions/Subscription_ID' --assignee 'app_ID'代替方法: Azure PowerShell を使用して Azure サブスクリプションにアクセス許可を付与する
New-AzADServicePrincipal コマンドから返された ID を下の引数に置き換え、Subscription_ID をサブスクリプションに置き換えてください。
New-AzRoleAssignment -ObjectId "Id" -Scope "/subscriptions/Subscription_ID" -RoleDefinitionName "Monitoring Data Reader"ステップ 3: Azure からメトリクスデータを読み取るように CloudWatch を設定する
まず、CloudWatch コンソールの左側のナビゲーションで「設定」を選択し、次に「メトリクスのデータソース」を選択します。
図 2. CloudWatch サービスの設定ページ
次に、「データソースを作成」、「Azure Monitor」、「次へ」 の順に選択します。
図 3. メトリクスデータソースのリストから Azure Monitor 選択
データソースに名前を付けます。この名前は、作成された CloudFormation スタックの名前として表示されることに注意してください。Directory (tenant) ID、Application (client) ID、およびシークレットデータを入力し、「データソースを作成」を選択します。
図 4. Azure アプリの認証情報を使用して新しいデータソースを構成する
CloudFormation へのリンクを辿ることで、スタックの進行状況を確認できます。通常、このプロセスは 2 分以内に完了します。Prometheus や Amazon RDS などの他のメトリクスデータソースでは、オプションで VPC 内に Lambda 関数を作成できます。これにより、プロビジョニング時間が 1 ～ 2 分長くなる場合があります。この画面が表示されたら、インテグレーションは完了です。
図 5. CloudWatch の完成したインテグレーションページ
ステップ 4. Azure 環境のデータを視覚化する
CloudWatch を使用して Azure Monitor にメトリクスデータのクエリを実行できるようになりました。「CloudWatch メトリクスを開く」ボタンをクリックするか、左側のナビゲーションメニューで「すべてのメトリクス」を選択し、次に「マルチソースクエリ」を選択して、ドロップダウンでデータソース名を選択します。
図 6. マルチソースクエリのコンソールの図
サブスクリプション、リソースグループ、その他のフィールドを選択します。CloudWatch は、AWS アカウントと同様に Azure サブスクリプションを監視するようになりました。
図 7. CloudWatchを使用して Azure VM の CPU を視覚化
このインテグレーションがどのように機能するかについて一言 – Azure Monitor (CloudWatch の他のメトリクスデータソースタイプと同様) は CloudWatch に永続化されません。そのため、CloudWatch は Azure のデータにアクセスする際にオンデマンドで Azure にクエリを実行します。これは CloudWatch アラームにも当てはまります。CloudWatch アラームも同様に、アラーム評価ごとに十分なデータポイントをクエリして、アラート条件が満たされているかどうかを確認します。メトリクス Lambda に対応するロググループで、すべてのクエリの詳細を確認できます。
よくある問題のトラブルシューティング
Lambda はメトリクスデータソースインテグレーションのクエリを実行するために使用され、ログは CloudWatch Logs に保存されます。ロググループは、設定のエラーを見つけるために利用できます。
最もよく見られるエラーと、解決方法に関する注意事項は次のとおりです。
エラーメッセージ：
INFO Sending response: { Data: [], SubscriptionIds: [] }
これは、Azure IAM が権限を適用しておらず、Lambda が Azure からのサブスクリプションを列挙できないことを示しています。正しいサブスクリプションでステップ 2 が完了していることを確認してください。
エラーメッセージ：
INFO An error occurred: RestError: Commonly allowed time grains:...
すべてのメトリクスデータソースのタイプがこの機能をサポートしているわけではありません。ストレージアカウントの使用状況メトリクスなど、Azure Monitor に集約される頻度が低いデータを表示しようとすると発生する場合があります。これは、あまり頻繁に入力されないメトリクスでは予想される動作です。詳細については、Azure Monitor API のドキュメントをご覧ください。
エラーメッセージ：
INFO An error occurred: AuthenticationRequiredError: invalid_client ensure your credentials are correct
これは通常、AWS Secrets Manager に間違った認証情報が保存されていることが原因です。テナント ID、アプリケーション ID、シークレット値が正しいことを再確認してください。CloudFormation スタックを再作成しなくても、これらの値を AWS Secrets Manager で直接変更できます。
インテグレーションを次のレベルへ
ハイブリッドおよびマルチクラウドの監視およびオブザーバビリティソリューションは、クラウド運用を監視するための強力なメカニズムです。CloudWatch をソリューションの中心的なコンポーネントとして使用することで、これらの機能を自動化し、拡張機能を使用して付加価値を高めることができます。最も強力な方法の 1 つは、Azure 環境内のメトリクスデータに基づいてアラームを作成することです。CloudWatch アラームは、管理者へのページ送信、JIRA チケットの作成、サーバーの再起動、フェイルオーバーの開始など、あらゆる自動ワークフローをトリガーできます。
CloudWatch は 1 つ以上のクラウド環境で問題が発生したときにアラートを出す、複合アラームを作成できます。Azure と AWS の両方で動作するワークロードがあり、両方のプロバイダーにデプロイすると機能停止が発生することを考えてみましょう。クラウド環境全体の HTTP エラーの総数に基づく複合アラームを使用し、アクションをトリガーします。これらはすべて、Azure と AWS の両方で作成されたクラウドネイティブなメトリクスに基づいています。ユースケースによっては、環境ごとにアラームを分けるよりもこの方が適している場合があります。
コストと削除
CloudWatch で外部メトリクスデータソースを使用しても追加料金は発生しませんが、Lambda、Secrets Manager、CloudWatch Logs、および CloudWatch アラームの使用には標準料金がかかります。 Azure Monitor API からデータを取得する場合の料金の詳細については、Azure のドキュメントを参照してください。
ステップ 3 で作成した CloudFormation スタックを削除するだけで、インテグレーションを解除できます。これにより、Lambda 関数とシークレット情報が Secrets Manager から削除されます。
まとめ
CloudWatch を使用してマルチクラウドのオブザーバビリティソリューションを作成すると、さまざまな環境のメトリクスを視覚化してアクションを実行できます。アラーム、ダッシュボード、Metric Math などの CloudWatch の機能を使用すると、高度なクエリを作成して、サイロ化されたオペレーションデータを解放し、複数のクラウドプロバイダーを使用する際の複雑さに対処する時間を短縮できます。この機能を使用することで、AWS から外部のメトリクスデータにアクセスしてアクションを実行できるため、CloudWatch はメトリクスデータを運用するための中心的な役割を果たします。
著者について
翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。