Elasticオブザーバビリティを使用して、AWSサービスのメトリックの監視を一瞬で始める方法

著者

Bahubali Shetti

blog-charts-packages.png

現在、分散型アプリケーションへの移行が本格化しています。この主要因は、消費者やペースの速いビジネスに関わる企業が"ダウンタイムゼロ"を求めていることにあります。このようなニーズによってデプロイの要件は複雑化しており、グローバルな分散や迅速なイノベーションを実現する機能も求められています。

今日アプリケーションをデプロイするにあたって、クラウドが事実上唯一の選択肢になりつつあります。クラウドへのデプロイでは、多くの場合、アプリケーションのホスト先としてAWSが選ばれています。AWSなら世界のさまざまなリージョンに対応し、開発やイノベーションを迅速化する無数のサービスを利用可能であり、さらには運用コストや資本コストも抑えられるからです。開発チームにとって、AWSには、Amazon EKS上のKubernetesに移行できる、最新のサーバーレスオプションをテストできる、優れたサービスで従来の階層型アプリケーションを強化できるといった価値もあります。

Elasticオブザーバビリティには、設定不要のAWSサービス向け統合機能が30種類用意されており、今後さらに追加される予定です。

こうした統合や機能については、以前投稿した以下のブログで簡単にご紹介しています。

その他にも以下の投稿で、Elasticの主要なAWSサービス向けの統合機能について説明しています。

AWS統合機能の一覧については、Elasticのオンラインドキュメントをご覧ください。

ElasticオブザーバビリティはネイティブなAWS統合機能に加えて、AWSの各種サービスおよびAWSの演算処理サービス（EC2、Lambda、EKS/ECS/Fargate）上で実行されているアプリケーションのログとメトリックも集約できます。このようなデータすべてをElasticの高度な機械学習機能で視覚的かつ直感的に分析できるため、エンドユーザーに影響が出る前にパフォーマンスの問題を検出し、根本原因を明らかにすることができます。

サービスマップ、トレーシング、依存関係、機械学習ベースのメトリックの相関付けなど、Elasticオブザーバビリティが提供するアプリケーションパフォーマンス監視（APM）機能の詳細については以下をご覧ください。

このように、Elasticには、AWSの各種サービスやAWSの演算処理サービス（EC2、Lambda、EKS/ECS/Fargate）上で実行されているアプリケーションのメトリックを取り込み、集約し、分析する機能が用意されています。Elasticはログ関連の機能を備えているだけでなく、AWS環境に対応した一元的なオブザーバビリティソリューションでもあるのです。

このブログでは、AWSサービス上で実行される以下のようなシンプルなAWSアプリケーションのメトリックをElasticオブザーバビリティで監視する方法について説明します。

  • AWS EC2
  • AWS ELB
  • AWS RDS（AuroraDB）
  • AWS NATゲートウェイ

これからご紹介するように、統合機能をインストールするとメトリックがすぐに取り込まれ、レビューを直ちに開始できます。

前提条件と構成

このブログの内容を実際に試してみたい方のために、本デモに使用したコンポーネントと詳細設定を以下に挙げます。

  • Elastic Cloudにアカウントがあり、デプロイしたスタックがあること（手順はこちら）。
  • AWSから必要なデータを取り込む権限があるAWSアカウントがあること。詳細はElasticのドキュメントをご覧ください。
  • AWSの3層アプリを使用し、Gitの手順に従ってインストールしました。
  • このブログでは、Elasticの汎用AWS統合機能のインストールについて説明ます。この機能は、メトリックの収集となる4つのサービスに対応しています
    （ElasticのAWS統合機能でサポートされるサービスの一覧）。
  • 他のブログでAWSでのアプリケーション監視（メトリック、ログ、トレース）について説明しているため、ここではアプリケーション監視については説明しません。代わりに、AWSサービスを簡単に監視する方法を扱います。
  • メトリックを確認するには、アプリケーションに負荷をかける必要があります。そこで、アプリケーションへのトラフィックを増やすPlaywrightスクリプトも作成しました。

3層アプリケーションの概要

Elasticの設定に進む前に、監視対象を確認しましょう。aws-three-tier-web-architecture-workshopの手順に従うと、以下のものがデプロイされます。

デプロイの内容：

  • 6サブネットのVPC x 1
  • AZ x 2
  • 各AZのWebサーバーx 2
  • 各AZのアプリケーションサーバーx 2
  • 外部向けアプリケーションロードバランサーx 1
  • 内部向けアプリケーションロードバランサーx 1
  • アプリケーションレイヤーへのトラフィックを管理するNATゲートウェイx 2
  • インターネットゲートウェイx 1
  • リードレプリカを含むRDS Aurora DB x 1

ブログの後半で、このアプリに負荷をかけるためのPlaywrightスクリプトもご紹介します。このスクリプトは、メトリックを増やしてダッシュボードを"起動する"ためのものです。

設定手順

それでは、アプリケーションを用意する方法、ElasticのAWS統合機能、今回取り込む対象について詳しく説明します。

手順0：AWSの3層アプリケーションをインストールして認証情報を取得する

AWSの3層アプリに関する手順と、Git上のワークショップのリンクの手順に従ってください。ワークショップについては、こちらをご覧ください。

アプリをインストールしたら、AWSから認証情報を取得します。これは、ElasticのAWS統合機能に必要になります。

認証情報を取得する方法はいくつかあります。

  • アクセスキーを直接使用する
  • 一時的なセキュリティ認証情報を使用する
  • 共有の認証情報ファイルを使用する
  • IAMロールのAmazonリソースネーム（ARN）を使用する

必要な認証情報と権限の詳細をご確認ください。

手順1：Elastic Cloudのアカウントを取得する

指示に従ってElastic Cloudの使用を始めます。

手順2：ElasticのAWS統合機能をインストールする

ElasticのAWS統合機能に移動します。

［Add AWS］（AWSの追加）を選択します。

ここで認証情報を入力すると、Elasticにポリシーとして保存されます。このポリシーは、次の手順でエージェントをインストールする際に使用します。

上図からわかるように、このElasticの汎用AWS統合機能は30種類のAWSサービスから多くのデータを収集します。このElasticの汎用AWS統合機能をインストールせずに、個々の統合機能を選択してインストールしてもかまいません。

手順3：AWS統合機能でElastic Agentをインストールする

統合ポリシーを作成したので、Elasticの［Management］（管理）の下にある［Fleet］（フリート）セクションに移動します。

先ほどの手順で作成したポリシーの名前を選択します。

［Add agent］（エージェントの追加）ウィンドウの説明のステップ3に従います。以下を実行する必要があります。

1：EC2インスタンスを起動する

  • t2.medium以上
  • Linux - 任意
  • EC2インスタンスの起動時にインスタンスのキャパシティ予約を［Open］（開く）に設定する

2：インスタンスにログインして、［Linux Tar］タブでコマンドを実行する（以下の例を参照）

curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.5.0-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.5.0-linux-x86_64.tar.gz
cd elastic-agent-8.5.0-linux-x86_64
sudo ./elastic-agent install --url=https://37845638732625692c8ee914d88951dd96.fleet.us-central1.gcp.cloud.es.io:443 --enrollment-token=jkhfglkuwyvrquevuytqoeiyri

手順4：アプリケーションにトラフィックを送る

アプリケーションの実行は非常に簡単ですが、▲

AWS 3層アプリケーションのWebサイトへのトラフィックを増やす、Playwright用の簡単なスクリプトを以下に示します。

import { test, expect } from '@playwright/test';

test('homepage for AWS Threetierapp', async ({ page }) => {
  await page.goto('http://web-tier-external-lb-1897463036.us-west-1.elb.amazonaws.com/#/db');

   await page.fill('#transactions > tbody > tr > td:nth-child(2) > input', (Math.random()*100).toString())
  await page.fill('#transactions > tbody > tr > td:nth-child(3) > input', (Math.random()*100).toString())
  await page.waitForTimeout(1000)
  await page.click('#transactions > tbody > tr:nth-child(2) > td:nth-child(1) > input[type=button]')
  await page.waitForTimeout(4000)

});

このスクリプトではブラウザーを3つ起動しますが、playwright.config.tsファイルで1つのブラウザーのみに制限してもかまいません。

この演習では、Webサイトをテストする間、約5時間にわたり5分間隔でこのトラフィックを実行しました。

手順5：AWSダッシュボードに移動する

Elastic Agentを起動できたので、次は関連するAWSダッシュボードに移動し、取り込まれている情報を確認しましょう。

AWS統合機能のダッシュボードは、Elasticの検索バーで検索すればすぐに見つけられます。このブログに関連するダッシュボードは以下のとおりです。

  • [Metrics AWS] EC2 Overview（EC2概要）
  • [Metrics AWS] ELB Overview（ELB概要）
  • [Metrics AWS] RDS Overview（RDS概要）
  • [Metrics AWS] NAT Gateway（NATゲートウェイ）

表示される情報を見てみましょう。

これらのダッシュボードはすべて、設定なしですぐに使えます。以下の図では、今回のアプリの関連項目のみにビューを絞り込んでいます。

すべてのダッシュボードで、時間枠をトラフィック生成スクリプトを実行した時間に限定しています。

ElasticオブザーバビリティのEC2概要ダッシュボード
ElasticオブザーバビリティのEC2概要ダッシュボード

4つのEC2インスタンス（Webサーバー2つ、アプリケーションサーバー2つ）にフィルタリングすると、以下のことを確認できます。

1：4つのインスタンスがすべて稼働していて、ステータスチェックでエラーは検出されていない。

2：時間枠内の平均CPU使用率が表示され、異常は見当たらない。

3：ネットワークの受信/送信バイト数が、データベースでの行の読み込み期間にわたって集約され表示されている。

今回は表示可能なメトリックのごく一部しか紹介していませんが、AWS EC2ではさらに多くのメトリックを利用できます。特定インスタンスの検索を絞り込むときに役立つディメンションなど、AWSドキュメントに記載されているメトリックはすべて利用できます。

ElasticオブザーバビリティのELB概要ダッシュボード
ElasticオブザーバビリティのELB概要ダッシュボード

ELBダッシュボードについては、2つのロードバランサー（外部Webロードバランサーと内部アプリケーションロードバランサー）をフィルタリングしています。

この設定不要のダッシュボードでは、アプリケーションのELB固有のメトリックを確認できます。AWSドキュメントに記載されているほとんどのアプリケーションのELB固有メトリックについて、グラフを追加できます。

今回の2つのロードバランサーでは、以下のことがわかります。

1：両方のホスト（ELBに接続されたEC2インスタンス）が正常に機能している。

2：トラフィックの生成期間には、ロードバランサーのキャパシティユニット（使用量）とリクエスト数の両方が予想どおりに上昇している。

3：400番台と200番台のカウントを表示するよう設定されている。400番台は、アプリケーションの問題やアプリケーションサーバーとの接続の問題を特定するのに役立ちます。

ElasticオブザーバビリティのRDS概要ダッシュボード
ElasticオブザーバビリティのRDS概要ダッシュボード

RDSにデプロイしたAuroraDBについては、ダッシュボードでAuroraのプライマリインスタンスとセカンダリインスタンスのみをフィルタリングしています。

EC2やELBと同様に、CloudWatchのほとんどのRDSメトリックについて、グラフやチャートを新規に作成できます。このダッシュボードでは、以下の項目に絞り込んで表示しています。

1：挿入スループットと選択スループット

2：書き込みレイテンシ

3：CPU使用状況

4：時間枠内の総接続数

ElasticオブザーバビリティのAWS NATダッシュボード
ElasticオブザーバビリティのAWS NATダッシュボード

上図では、アプリケーションサーバーの前に配置される2つのNATインスタンスだけが表示されるようにフィルタリングしました。他のダッシュボードと同様に、必要に応じて他のメトリックのグラフやチャートも作成できます。

このNATダッシュボードでは、以下のことを確認できます。

1：パケットドロップがないため、NATゲートウェイは正常に機能している。

2：Webサーバーからのアクティブな接続数が想定どおりである。

3：受信/送信バイトのメトリックがほぼ正常である。

おつかれさまでした。これで、お使いのアプリケーションについて、AWSサービスの主要なメトリックの監視を始められるようになりました。

AWSで監視できる他の要素

AWSサービスのログを追加する

メトリックを監視できるようになったので、次はログも追加してみましょう。ログを取り込む方法はいくつかあります。

1．Elastic AgentのAWS統合機能にログの設定があります。受信したい項目を有効にしてください。RDSからAuroraのログを取り込んでみましょう。Elastic Agentポリシーで、［Collect logs from CloudWatch］（CloudWatchからログを収集する）を有効にします（下図を参照）。次に、フリート管理用のUIでエージェントを更新します。

2．Lambdaのログフォワーダーをインストールします。この方法では、複数の場所からログを取り込みます。以下のアーキテクチャー図をご覧ください。

この方法の詳細については、こちらのブログでも説明しています。

Elasticの機械学習でデータを分析する

メトリックとログ（またはそのいずれか）をElasticに取り込んだら、Elasticの機械学習機能を使ってデータ分析を始めましょう。この機能については、以下で詳しく説明されています。

Elasticのブログには、他にも多くの動画や記事があります。

まとめ：Elasticオブザーバビリティを使うと簡単にAWSサービスのメトリックを監視できる

ElasticオブザーバビリティがAWSサービスのメトリック監視にどのように役立つのかご理解いただけたかと思います。以下に、このブログで説明してきた内容を簡単に振り返ります。

  • ElasticオブザーバビリティはAWSサービスのメトリックのインジェストと分析をサポートしている
  • Elastic Agentを使用するとAWSサービスからのインジェストを簡単に準備できる
  • Elasticオブザーバビリティには、情報の事前確認に使える設定不要の（OOTB）AWSサービス向けダッシュボードが複数用意されており、ニーズに合わせて変更することもできる
  • ElasticオブザーバビリティのAWS統合の一環として30種類以上のAWSサービスに対応しており、対象サービスは今後も定期的に拡大予定である
  • 関連ブログで説明されているように、Elasticの機械学習機能を使用してAWSサービスのメトリックを分析できる

AWS Marketplaceから登録すると、7日間の無料トライアルをご利用いただけます。世界中のあらゆるAWSのElastic Cloudリージョンで、すぐにデプロイをお試しください。AWS Marketplaceで購入したElastic製品は月次の一括請求書に記載され、AWSの確約利用割引が適用されます。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

Elastic Cloudの無料トライアルに登録

お好みのクラウドを選び、多彩な機能を組み込んでデプロイできます。Elasticsearchを開発するElasticが、クラウド向けに高機能なElasticクラスターとサービスを提供します。

無料トライアルを始める