Amazon Web Services ブログ

Dynatrace、AWS Lambda、および AWS Service Catalog を使用して、自己修復 Infrastructure-as-Code を構築する

AWS のパートナーソリューションアーキテクト、Kishore Vinjam
Dynatrace の戦略的パートナーイネーブルメント＆エバンジェリズム担当ディレクター、Andreas Grabner 氏

Dynatrace Logo-2
Dynatrace APN Badge-3

クラウド運用またはシステム管理で作業するエンジニアは、多くの場合、パフォーマンスモニタリングツールで検出された問題を修正するために手動でスクリプトを更新する必要があります。 これには、プロセスの再起動、リソースのクリーンアップ、メモリの停止、および CPU 使用率に関する問題などがあります。このような問題は頻繁に発生し、貴重な時間が取られてしまいます。

この記事では、お客様がどう Dynatrace、AWS Lambda、および AWS Service Catalog を使用して、ワークフローを構築し、Dynatrace AI で検出された問題に対して必要なインシデント対応アクションを開始するかを説明します。

Dynatrace AI は、エンドユーザーが、基礎となるシステムリソースが原因で実際のユーザーエクスペリエンス、サービスレベルアグリーメント (SLA)、またはサービスの可用性から影響を受けたときに、問題を検出して通知をトリガーします。基礎となるリソースに起因する問題には、ディスクがいっぱいである、設定の変更が不適切、負荷が増加している、または依存するサービスの問題などがあります。

AWS Service Catalog を使用すると、AWS での使用が承認されているサービスのカタログを作成および管理でき、Lambda を使用すると、サーバーをプロビジョニングまたは管理せずにコードを実行できます。

Dynatrace は、AWS パートナーネットワーク (APN) のアドバンストテクノロジーパートナーで、Migration、DevOps、Containers の AWS コンピテンシーを持っています。今日の複雑な IT 環境で成功し、明日や将来も成功し続けるには、Dynatrace などの AWS コンピテンシーパートナーと連携することがスマートな一手 (The Next Smart) です。

AWS コンピテンシープログラムでは、お客様の成功事例を紹介したり、特定のソリューション領域やセグメントで高い専門性を示したりしたトップの APN パートナーを確認、検査、精査しています。

AWS Service Catalog のアーティファクトの自動調整

AWS Service Catalog の管理者は、AWS CloudFormation テンプレートを用意し、制約を設定して、AWS Identity and Access Management (IAM) ロールを管理します。IAM ロールは、製品に割り当てられて、高度なリソース管理を実現します。お客様は、AWS Service Catalog を使用して、アクセスが許可された製品を起動します。

さらに、AWS Service Catalog によって管理される Infrastructure-as-Code (IaC) を実装したお客様は、インフラストラクチャプロビジョニングパイプラインを拡張し、Auto-Remediation-as-Code を実行できます。これにより、プロビジョニングしたスクリプトへの変更をロールアウトするために必要な手動の手順が省けます。

前述のように、Dynatrace が識別して問題の通知をトリガーできるさまざまなインシデントがあります。ビジネスロジックと呼ばれるこれらのイベントに基づいて実行される修復アクションは、トリガーの種類と実際の影響により異なります。

この種のビジネスロジックの開発に際限はなく、すべての可能性をここで説明することは不可能です。この記事では、SLA に影響を与える CPU_SATURATION イベントを処理する 1 つのビジネスロジックについて説明します。 イベント名が示すように、イベントは CPU リソース不足が発生するとトリガーされます。他のすべての可能性は、Dynatrace のウェブサイトの「Problem Detection and Analysis」で調べることができます。

当社がサポートする組織では、クラウド管理チームが許可された製品のカタログを作成しているのをよく見ます。そのカタログには、データサイエンスワークステーション用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとその他のユースケースが含まれます。組織内のさまざまなエンジニアに起動する能力が与えられ、セルフプロビジョニングを行います。そしてそれが終わると終了します。

CPU パワーを増加させる必要があることは、CPU_SATURATION イベントが Dynatrace によって連続して複数回トリガーされることで示されます。通常、これがクラウド管理者にエスカレートされて修正措置が取られるまでの間、サービスのダウンタイムではないとしても、ユーザーエクスペリエンスが低下します。

以下のサンプルソリューションでは、Dynatrace、AWS Lambda、および AWS Service Catalog を利用してこの修復プロセスを自動化する方法を示します。

ソリューションの概要

このソリューションでは、Dynatrace によってトリガーされるイベントに基づいて AWS Service Catalog 製品を自動調整する方法を確認します。提供される AWS CloudFormation テンプレートを使用して、Dynatrace OneAgent とともに Amazon EC2 インスタンスをデプロイすることから始めます。次に、AWS 環境をモニタリングするように Dynatrace SaaS インスタンスを設定します。

OneAgent は、Amazon EC2 からパフォーマンスメトリクスを収集し、Dynatrace SaaS インスタンスに送信します。Dynatrace がエンドユーザーエクスペリエンス、SLA、または基礎となるリソースのサービスの可用性に影響を与える問題を特定すると、問題通知イベントがトリガーされます。Dynatrace SaaS インスタンスは、Amazon API Gateway を介して Lambda 関数をトリガーするように設定されています。Lambda 関数はさらに問題を検証し、AWS Service Catalog アーティファクトを自動調整します。

次の図は、ソリューションのアーキテクチャを示しています。

Dynatrace-Service Catalog-1.1

図 1 – Dynatrace 自動調整サービスカタログアーティファクト。

設定

  • AWS Service Catalog は、Amazon EC2 インスタンス製品をプロビジョニングするために使用され、さらに Amazon EC2 の初期化中にユーザーの日付を通じて Dynatrace OneAgent もインストールします。OneAgent は、Amazon EC2 ホストからパフォーマンスメトリクスを収集します。
  • Dynatrace SaaS インスタンスは、AWS 環境をモニタリングするように設定されています。
  • この設定では、Amazon API Gateway、AWS Lambda、Amazon EC2、SSM Parameter Store、および AWS CloudFormation テンプレートが使用されます。

仕組み

AWS 環境を Dynatrace SaaS インスタンスにアタッチすると、OneAgent が設定された Amazon EC2 インスタンスが Dynatrace によって継続的にモニタリングされます。Dynatrace がエンドユーザーエクスペリエンス、SLA、またはサービスの可用性に影響を与える問題を特定すると、問題の通知がトリガーされます。これは、Amazon API Gateway である API をトリガーするように設定されています。これにより、イベントが検証され、必要に応じて修復呼び出しがトリガーされます。

実際の問題を特定すると、AWS Service Catalog が自動調整され、Dynatrace が通知を受けます。

では、Dyntrace SaaS インスタンス統合が AWS と連携してどのように機能するかを確認し、必要に応じて AWS Service Catalog を自動調整しましょう。

  • まず、Dynatrace での AWS モニタリングを有効にして、AWS 環境を Dynatrace SaaS インスタンスにアタッチします。
  • AWS Service Catalog を使用して、インスタンスの作成中に OneAgent をインストールする Amazon EC2 インスタンスをプロビジョニングします。Amazon EC2 インスタンスが起動すると、自動的に Dynatrace SaaS に登録されます。
  • Dynatrace がホスト、サービス、またはアプリケーションの正常性に影響を与えている CPU_SATURATION を特定すると、問題の通知がトリガーされ、関連する PID 情報とともに AWS API Gateway の API を呼び出します。

次に、この API は、次の手順を実行する Lambda 関数をトリガーします。

  • Dynatrace API の「problem/details/」を呼び出して、問題に関する詳細情報を取得します。
  • トリガーされたイベントが修復呼び出しをトリガーする資格があるかどうかを検証します。
  • 対象イベントで、Dynatrace API「entity/infrastructure/hosts/」を呼び出して、影響を受けるホストの追加情報を取得します。
  • API「describe-instances」を使用して Amazon EC2 インスタンスをクエリし、現在の servicecatalog-product-id 情報を取得します。
  • SSM パラメータストアからの Amazon EC2 インスタンスの事前承認済みリストを確認し、次に大きい承認済み Amazon EC2 インスタンスで CloudFormation テンプレートを更新します。この記事では、提供されている CloudFormation テンプレートの 1 つが、Amazon EC2 インスタンスの事前承認済みリストを作成します。AWS マネジメントコンソールから事前承認された値を更新するには、[AWS Systems Manager]、[パラメータストア]、[/dynatrace/approvedinstancetypes/]、[編集] の順にクリックします。
  • Lambda 関数は、更新された CloudFormation テンプレートを使用して、AWS Service Catalog に新しいバージョンを自動的に作成します。これから発売されるすべての新製品には、今後更新済みの Amazon EC2 タイプが付属します。
  • AWS Service Catalog が正常に更新されると、Dynatrace の問題の修正アクションに関するコメントが追加されます。

前提条件

  • AWS アカウントが必要です。
  • Dynatrace SaaS Free Trail にサインアップし、AWS アカウントをアタッチして自動検出を開始し、環境のモニタリングを開始します。
  • AWS Service Catalog の基本的な理解。詳細については、AWS Service Catalog 管理者ガイドの「開始方法」セクションを参照してください。
  • AWS CloudFormation スタックを起動する方法の理解。詳細については、スタックの作成ユーザーガイドを参照してください。

はじめに

このセクションでは、Dynatrace AI を設定し、AWS Service Catalog と統合して、報告された問題に基づいて AWS Service Catalog アーティファクトを自動調整する方法を説明します。

CloudFormation テンプレートは、このブログの必要に応じて AWS Service Catalog 製品を作成し、AWS 環境を設定するために提供されています。AWS 環境の設定には、必要な SSM パラメータの作成、Lambda 関数のインストール、Amazon API Gateway のセットアップが含まれます。

Dynatrace 問題通知を設定する手順は次のとおりです。

  • AWS Service Catalog に付属する CloudFormation テンプレートを使用して、OneAgent が自動的にインストールされた Amazon EC2 インスタンスをプロビジョニングします。
    • CloudFormation テンプレート (DynatraceMonitoringAsAServiceCFStack.json) をダウンロードします。
    • AWS Service Catalog のポートフォリオが存在しない場合は、作成します。
    • 以前にダウンロードした CloudFormation テンプレートを使用して、製品を作成します。
    • 製品をポートフォリオに追加します。
    • (オプション) 必要に応じて、テンプレート制約や起動制約を追加します。
    • ポートフォリオにアクセスするためのエンドユーザーのアクセス許可を付与します。
    • 許可されたユーザーとしてログインし、製品を起動します。 製品の起動中は、各パラメータの説明の下にあるパラメータページの指示に従ってください。
    • 製品が正常に起動すると、OneAgent を含む Amazon EC2 インスタンスがインストールされます。

図 2 は、「EC2InstanceWithOneAgent」という名前の AWS Service Catalog 製品の外観を示しています。

Dynatrace-Service Catalog-2.1

図 2 – AWS Service Catalog の製品の詳細ページ。

  • 次に、CloudFormation テンプレート (DynatraceEnvironLaunch.yaml) と Lambda zip ファイル (receiveDynaNotification.zip) をダウンロードします。
  • 「ReceiveDynaNotification.zip」ファイルを Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。次のステップで「BucketName」の値として使用するので、バケット名を書き留めます。
  • AWS マネジメントコンソールから CloudFormation スタックを起動します。[すべてのサービス] > [マネジメントとガバナンス] > [CloudFormation] > [スタックの作成] の順にクリックします。[テンプレートの選択] で、[参照] をクリックし、先にダウンロードした「DynatraceEnvironLaunch.yaml」をポイントして、[続行] をクリックします。
  • 製品の起動中は、各パラメータの説明の下にあるパラメータページの指示に従ってください。CloudFormation テンプレートは、次の手順を自動的に実行します。
    • AWS Lambda で使用される次の SSM パラメータを設定します。
      • Dynatrace Saas インスタンス名
      • 認証情報
      • ワークスペースとして使用される Amazon S3 バケット
      • 承認されたインスタンスタイプのリスト。
    • これらの SSM パラメータは、必要に応じて [Systems Manager]、[共有リソース]、[パラメータストア]、[/DynatraceApprovedInstanceTypes]、[編集] の順にクリックして手動で更新できます。
    • 実行に適したロール「CommonLambdaRole」を使用して Lambda 関数「ReceiveDynatraceLambda」を作成します。
    • 有効にした API キーを使って、Amazon API Gateway で API「ReceiveDynatraceAPI-<stagename>-」を作成します。この API は、Lambda 関数「ReceiveDynatraceLambda」をトリガーします。
  • CloudFormation スタックが正常に起動した後、AWS マネジメントコンソールに接続して、[ネットワークとコンテンツ配信]、[Amazon API Gateway] の順にクリックし、次に [API]、[ステージ]、そして最後に [投稿] を選択します。「呼び出し URL」を書き留めます。

Dynatrace-Service Catalog-3

図 3 – API 呼び出し URL の画面。

  • Amazon API Gateway で、[API キー]、[ApiKeyToUseAtDynatrace] を選択して、[表示] をクリックし、API キーを書き留めます。

Dynatrace-Service Catalog-11

図 4 – Dynatrace インスタンス認証用の API キー。

  • 次に、Dynatrace でアラートプロファイルを作成して割り当て、必要に応じて組織のためにエラーを報告します。アラートポートフォリオのサンプルを図 5 に示します。

Dynatrace-Service Catalog-12

図 5 – Dynatrace アラートプロファイルの設定。

  • Dynatrace でカスタム問題通知を作成して、アラートプロファイルを割り当てます。Amazon API Gateway の「呼び出し URL」と「API キー」の内容を Dynatrace の「Webhook URL」と「X-API-KEY」列に貼り付けます (下記)。下部で適切なアラートを選択し、「Send Test Notification」をクリックして認証を検証し、[Save] をクリックします。
  • 以下のテキストをコピーして、[Custom Payload] の下に貼り付けることができます。
    .
    {
    “State”:”{State}”,
    “PID”:”{PID}”,
    “ProblemTitle”:”{ProblemTitle}”
    }
    .

Dynatrace-Service Catalog-13.2

図 6 – Dynatrace の問題通知の AWS API との統合。

  • 新しくデプロイされた Amazon EC2 インスタンスが Dynatrace コンソールに表示されていることを確認します。

Dynatrace-Service Catalog-7.1

図 7 – Dynatrace SaaS インスタンスでモニタリングされる AWS リソース。

  • Linux サーバーで「stress」ツールを使用して、CPU_SATURATION イベントをトリガーします。これは、次のコマンドを使用してインストールおよび実行できます。
# sudo yum update -y

# sudo yum install stress -y

# stress --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.95;}' < /proc/meminfo)k --vm-keep -m 1
  • Dynatrace AI によって問題が特定されたら、イベントがトリガーされます。

Dynatrace-Service Catalog-14

図 8 – Dynatrace AI は影響を受ける AWS インスタンスを報告します。

  • これにより対象となる CPU_SATURATION イベントがトリガーされると、AWS Service Catalog 製品が更新されます。

Dynatrace-Service Catalog-15

図 9 – AWS Service Catalog 製品用のアーティファクトの自動更新。

  • 更新前と更新後の CloudFormation テンプレートは次のようになります。

Dynatrace-Service Catalog-9.1.2

Dynatrace-Service Catalog-9.2.2

図 10 – 対象イベントでの CloudFormation テンプレートの更新。

  • AWS Service Catalog 製品が更新されると、コメントが Dynatrace 問題に追加されます。

Dynatrace-Service Catalog-10.2

図 11 – AWS Service Catalog アーティファクトが自動更新された後の Dynatrace への応答。

まとめ

この記事では、Dynatrace が AWS でのリソース不足による問題を報告したときに自動修復アクションがどうトリガーされるかを見てきました。

このようにして、リソース不足が頻繁に発生したときにインフラストラクチャカタログを自動更新し、起動したすべての新しいリソースを自動調整することができます。エスカレーションが発生するのを待つ必要も、クラウド管理チームが修正措置を講じるのを待つ必要もないため、カタログの自動更新によりエンドユーザーエクスペリエンスが向上します。

クラウド管理チームは、小さいリソースから始めて、実際のリソース使用量に基づいて自動的にスケーリングできます。プロビジョニングされた長期実行インスタンスがある場合は、適切なときにサービスカタログから更新できます。

動画を見る (51:16)

自動修復および自己修復インフラストラクチャのその他のユースケースについては、Dynatrace によるAWS reInvent: 2018 での Self-Healing with AWS Lambda に関するセッションをチェックしてください。