Amazon Web Services ブログ

Amazon OpenSearch Serviceを利用したVMware Cloud on AWSワークロードのモニタリング

2021年9月8日：Amazon Elasticsearch ServiceはAmazon OpenSearch Serviceに名称変更されました。詳細を確認する。

AWSでSpecialist Solutions Architectを務めるDrew Rutledgeによる記事です。

VMware Cloud on AWSは、VMwareとAWSが共同で開発したソリューションで、vSphere、NSX、vSANなどのVMwareのSoftware-Defined Data Center (SDDC) テクノロジーをAWSグローバルインフラストラクチャ上で提供します。

Amazon OpenSearch Service (Amazon Elasticsearch Serviceの後継サービス) を利用すると、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できます。Amazon OpenSearch Serviceは、Elasticsearchから派生した、分散型のオープンソース検索および分析スイートです。


本番ワークロードをデプロイする場合、発生する可能性のある問題にプロアクティブに対処するために、ワークロードの状態を可視化することが重要です。例えばアクセス不能、オペレーティングシステム (OS) の不安定性、アプリケーションの構成ミス、などその他さまざまな問題が考えられます。

組織が本番ワークロードを監視およびトラブルシューティングする際の一般的な方法には、Webサーバーのログ、Linux syslog、Windowsイベントログなど、アプリケーションおよびサーバーログのモニタリングがあります。

OpenSearch (データを検索および分析するためのオープンソースツール) とOpenSearchダッシュボード (Kibana 7.10から派生したデータを視覚化するためのオープンソースのユーザーインターフェイス) を組み合わせることで、アプリケーションとサーバーの健全性を集計、モニタリング、可視化するための強力な仕組みを提供します。

Amazon OpenSearch ServiceをAmazon Kinesis Data FirehoseおよびAWS Lambdaと組み合わせることで、マネージド型でエンドツーエンドのログ集約とモニタリングのソリューションを作成でき、VMware Cloud on AWS上のワークロードにも適用できます。

本稿では、このモニタリングソリューションの利点と活用方法のアイデアについて説明します。以下はアーキテクチャの概要図です。

図1 — モニタリングソリューションのアーキテクチャ

このアーキテクチャ図は、VMware Cloud on AWS SDDC内でホストされているWebサーバー仮想マシン (VM) 群を示しています。ウェブサーバーのアクセスログ (この場合はApache httpd) をキャプチャすることによって、HTTPレスポンスコード、経時的なページビュー、特定のソースIP によるヒットなどのメトリクスをモニタリングできます。

これらの仮想マシンは、Kinesisエージェントを経由して Amazon Kinesis Data Firehoseにトラフィックを転送します。Kinesisエージェントは、仮想マシンにインストールされたスタンドアロン型Javaアプリケーションで、Kinesisにデータを簡単に送信できます。そのデータがFirehose配信ストリームに格納されると、Lambda関数がトリガーされ、出力された生のログをOpenSearchが解析可能なJSON 形式に変換します。

正常に変換されたログは、Amazon OpenSearchサービスに転送されます。何らかの理由で出力されたログが変換されない場合、またはOpenSearchに到達できない場合、ログエントリが失われないようにAmazon Simple Storage Service (Amazon S3) バケットに転送されます。

トポロジーの詳解

まずはVMware Cloud on AWSから始めて、本稿でご紹介するアーキテクチャについてもう少し詳しく説明しましょう。

Software-Defined Data Center (SDDC) は、VMwareが管理するAmazon Virtual Private Cloud (VPC) にあり、VMwareが所有するAWSアカウントでホストされたお客様専有の環境です。セットアップおよび設定時に、このアカウントはElastic Network Interfaces (ENI) を使用して、お客様が所有するAWSアカウントのVPCに接続されます。

図2 — Webサーバー仮想マシンが表示されているVMware vSphereクライアント

VMware Cloud on AWS環境では、vCenterコンソールに2つのWebサーバー仮想マシン、centos-web01とcentos-web02が表示され、図2に示すように、「Production Web Servers」フォルダに格納されています。

これらのWebサーバー仮想マシンの健全性モニタリングを実施し、どのように利用されているかを追跡します。問題が発生した際には原因の特定に役立つログを簡単に確認できるようにします。

図3 — VMware Cloud on AWSでホストされる仮想マシンはENIを介してネイティブAWSサービスに直接アクセスします

VMware Cloud on AWSは、図3に示すように、複数のENIを活用してVMwareが管理するSDDCとお客様が所有するAWSアカウントVPC間で通信することにより、ネイティブAWSサービスとの直接通信を可能にします。この通信によるトラフィックはSDDCとお客様が所有するAWSアカウントのVPC間を直接通過し、2つの環境間を繋ぐENI接続の外部は経由しません。

このENI接続によって、VMware Cloud on AWSでホストされる仮想マシンとネイティブAWSリソースの間に、広帯域幅、低レイテンシー、かつセキュアな接続が提供されます。本稿でご紹介するモニタリングソリューションもこのENI接続によって、VMware Cloud on AWS内の仮想マシン (VM) に対して活用することができます。

従来、ログをElasticsearchに送信するためにはLogstashのようなものを使っていたかもしれません。このElasticsearch、Logstash、および Kibanaの組み合わせは、一般に「ELKスタック」と呼ばれます。Apache 2.0のライセンスバージョンの ElasticsearchとKibana (バージョン 7.10.2まで) を使用してELKスタックを自分でデプロイおよび管理するか、OpenSearch、OpenSearchダッシュボード、およびLogstashを使用してELKスタックの代替となるオープンソースを自分で管理するかを選択していました。

しかしこのアーキテクチャを使用した場合、お客様は複数のサーバとプロセスを管理する必要がありました。代わりに、AWSが提供するシンプルな代替手段であるAmazon Kinesisが利用できます。Kinesis Data Firehoseを活用してログデータをキャプチャし、Lambda関数を使用して変換して、OpenSearchに確実かつ簡単に配信できます。またこのサービスはフルマネージド型であるためインフラストラクチャを維持する必要がなく、ニーズの拡大に合わせて拡張できます。

この組み合わせでは、VMware Cloud on AWS内の仮想マシンはログデータをKinesisエージェント経由でKinesis Data Firehoseに送信し、Kinesis Data FirehoseはLambda関数によってJSON変換されたログデータをOpenSearchに送信します。OpenSearchはログを解析し、タイムスタンプ、HTTP応答コード、イベントの重大度などのさまざまなフィールドで並べ替え、フィルタリングおよびレポートします。

httpdなどの一般的なアプリケーションのログを解析できる構築済みのLambda関数が数多くありますが、お客様は独自のLambda関数を作成して独自のアプリケーションのログを解析することもできます。

インストールしたKinesisエージェントの設定によって、仮想マシンはログを配信ストリームに送信しています。この設定はとても簡単です。Linux仮想マシンの場合、次のようにyumでエージェントをダウンロードし、サービスを実行するだけです。

インストール

sudo yum install - y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm

実行

sudo service aws-kinesis-agent start

Windows仮想マシンで上記を実行する場合でもプロセスは同様です。MSIファイルを使用してKinesisエージェントをインストールし、Linuxバージョンとよく似た方法で設定ファイルを編集します。WindowsにKinesisエージェントをインストールするプロセスの詳細については、公式ガイドをご参照ください。

セットアップは簡単です。設定ファイルを編集してエージェントに配信ストリームを指定し、キャプチャするログへのパスを定義します。エージェントの設定ファイルは、/etc/aws-kinesis-agent/agent.jsonに存在します。

設定の詳細については、公式ガイドをご参照ください。なお設定が必要な主な項目は次のとおりです。

  • firehose.endpoint — エージェントにKinesis Firehoseエンドポイントを指定します。
  • assumeRoleARN — エージェントに対して定義したAWS Identity and Access Management (IAM) ロールのAmazonリソースネーム (ARN)
  • awsAccessKeyId — エージェントをAWSリソースにアクセスできるように設定したAWSアクセスキーID
  • awsSecretAccessKey — AWSアクセスキーIDに対応するシークレットアクセスキー
  • filePattern — エージェント経由で送信するログを含むディレクトリ
  • deliveryStream — 設定したKinesis配信ストリーム名

ネットワークタイムアウト、またはLambda呼び出し制限によってLambda関数の呼び出しが失敗した場合、Kinesis Data Firehoseはデフォルトで呼び出しを3回再試行します。

再呼び出しも失敗した場合、Kinesis Data Firehoseはそのレコードのバッチをスキップします。スキップされたレコードは、正常に処理されなかったレコードとして扱われ、バックアップ手段として安全なS3バケットに送信されます。またすべてのレコードをS3に送信するように設定することもできます。

このようなソリューションを設定するときは、AWSセキュリティのベストプラクティスに従って、S3バケットが適切に保護されていることを確認すること、不正アクセスを防ぐためにIAMロールとセキュリティグループが適切に設定されていることなどを確認することが重要です。AWSサービスへのアクセスを委任するIAMロールを作成する方法については、公式ガイドをご参照ください。

すべてのデータがOpenSearchに正常にストリーミングできたら、今度はそれを最大限に活用するために視覚化する必要があります。OpenSearchダッシュボードのユーザーインターフェイス (UI) に初めてログインすると、 [Discover] タブに、生のログデータがロードされ始めていることがわかります。これは、図4に示されているもの同様です。

図4 —「Discover」ページでは、Kinesisからロードした生のログデータが表示されます

ホスト、レスポンス、タイムスタンプなど、追跡したいさまざまなフィールドが強調表示されていることがわかります。生のログ出力を見ることは有益でありトラブルシューティングに役立ちますが、OpenSearchとOpenSearchダッシュボードの真の利点は視覚化です。

視覚化するには、OpenSearchダッシュボードの [Visualizations] メニューに移動します。このメニューには、ホームページの [Visualize] ボタンをクリックしてアクセスできます。[Create Visualization] をクリックすると、さまざまな視覚化タイプから選択できます。

図5 — 利用可能な様々な視覚化タイプを表示する [New Visualization] メニュー

上に示したように、視覚化しようとしているデータに応じて、いくつかのオプションがあります。たとえば、折れ線グラフを作成して (ログのタイムスタンプを活用して）時間の経過とともに発生するデータを視覚化したり、円グラフを使用して割合を示したりすることができます。要件に応じて最も適した視覚化のタイプを選択します。

まず円グラフを作成して、ウェブサイトがサービスを提供するさまざまなHTTPレスポンスコードの割合を示します。これにより、ページが見つからない、または複数のログインが拒否されていた場合などに潜在的な問題をさらに調査する必要があるか迅速に判断できます。

円グラフの編集中にグラフのソースとなるデータのパラメータを設定したり、グラフの表示方法を決定したりすることができます。Refreshボタンを押すことでグラフがどのように表示されるかを逐次確認でき、グラフの作成後は保存できます。

図6 — Webサーバー用のHTTPレスポンスコードのグラフ作成

他のチャートをいくつか作成すると (例えば一方は経時的なページビュー確認用、もう片方は特定のソースIPによるヒット確認用) 、それらをすべて1つのダッシュボードに集約できます (図7を参照) 。これにより、追跡したいさまざまな指標のすべてを1か所でモニタリングできます。

このタイプのダッシュボードは、ネットワークオペレーションセンターの大画面で永続的に起動して実行するのに最適です。いつでもWebサーバー環境のステータスをすばやく確認できます。

図7 — 作成した様々なグラフのすべてを表示するOpenSearchダッシュボード

これは一例ですが、このソリューションによって多種多様なユースケースにおいてログデータを集約することが可能になります。ワークロードが何をしているのか視覚化することは、サービスの継続性を維持するために重要です。したがって、このようなソリューションは、お客様の環境にアクセスするユーザーに際可能な限り最高のエクスペリエンスを提供するために非常に役立ちます。

また、このソリューションは、オンプレミスのワークロード、またはAmazon Elastic Compute Cloud (Amazon EC2) でホストされるワークロードとほぼ同じ方法で実装できるため、ワークロードがどこにあっても同様なインサイトを得ることができます。

まとめ

VMware Cloud on AWSは、様々なAWSネイティブサービスと簡単に統合できます。仮想マシンのログデータを集約して視覚化する場合、Amazon Kinesis Data FirehoseとAmazon OpenSearchサービスを組み合わせることで、コスト効率に優れ、マネージド型でセキュアかつスケーラブルなソリューションが提供可能になります。

VMware Cloud on AWSの仕組みの詳細については、リファレンスアーキテクチャ、紹介動画、ソリューション概要など、これらのリソースをご覧ください。

本稿の詳細ならびにこのようなソリューションをお客様の環境に実装する方法については、AWSまでお問い合わせください。

翻訳はSpecialist SA 武田が担当しました。原文はこちらです。