この記事は、ニフクラブログで2023-06-30に公開された記事を移転したものです。 こんにちは、CRE部 技術支援チームです。
現在のビジネスや生活に、アプリケーションは欠かせない存在になっています。提供される機能やサービスは様々ですが、その性能はユーザーエクスペリエンスやビジネス成果に直結します。ユーザーは、いつでも遅延なく使えるものとしてサービスを利用していますので、提供側としてその品質を維持することは大変重要な任務の一つとなっています。
しかし、システム運用にトラブルはつきものです。様々な要因で障害が発生し、結果としてサービス品質にも影響します。複雑化と高速化が進むシステム環境下で、アプリケーションの問題を素早く特定し、効率的に解決することは容易ではありません。そこで今回は、これらの問題解決に有効なツールの1つである、APMについて確認したいと思います。
はじめに
APMとは
APMは「Application Performance Monitoring」の略であり、アプリケーションパフォーマンスを監視し、分析するための方法です。これは、ユーザーが経験するアプリケーションのスピードやレスポンスタイム、エラーレートなどをリアルタイムに把握し、アプリケーションの挙動を理解し、必要な場合には対処するためのソリューションとなります。
APMを導入することにより、監視したいアプリケーションがどの程度効率的に動作しているか、エンドユーザーがどのような経験をしているかを測定します。また、問題が発生した際には、その原因を特定、通知し、解決するための重要な情報を提供可能です。
検証概要
今回はAPMツールとしてDatadogを使用し、ニフクラ上に作成したWeb/APサーバーとDBサーバーを監視します。 監視用設定の投入後、負荷試験や障害試験を実施して、状態を確認してみたいと思います。
構成イメージ
- はじめに
- 検証概要
- 構成イメージ
- 前提条件
- 利用リソース
- 検証準備
- テストしてみる
- まとめ
- 注意事項
前提条件
本記事は、以下の前提知識がある方を想定しています。
- ニフクラの基本的なコントロールパネルの操作、サービスを利用する知識
- Linuxサーバーの基本的な操作、知識
利用リソース
本検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。
| リソース | リソース名 | 数量 | 用途 | OSバージョン等 |
|---|---|---|---|---|
| サーバー | apmwebap01 | 1 | Web/APサーバー | Rocky Linux 9.1 |
| サーバー | apmdb01 | 1 | DBサーバー | Rocky Linux 9.1 |
| ルーター | apmRT01 | 1 | 外部アクセスSNAT用ルーター | - |
| プライベートLAN | PLAN222apm | 1 | Web/AP - DB間接続用セグメント | - |
検証準備
仮想サーバー、ルーターの作成
上記「利用リソース」に記載のサーバー2台、ルーター1台を作成し、それぞれプライベートLANへ接続します。
作成方法の詳細は以下をご参照ください。
クラウドヘルプ（SSHキー）
クラウドヘルプ（サーバーの作成）
クラウドヘルプ（ファイアウォールグループの新規作成）
クラウドヘルプ（ルーターの作成）
クラウドヘルプ（プライベートLANの作成）
各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定します。
Web/APサーバー、外部アクセス用ルーターはプライベートLANに加え、共通グローバルIPを使用します。
DBサーバーはプライベートLANのみ利用ですが、Datadogエージェントとの通信用に外部アクセスSNAT用ルーター経由でアクセスできるよう設定します。
DBサーバーのインストール （作業対象：apmdb01）
DBサーバーとしてMySQLをインストールします。詳細は割愛しますが、Web/APサーバー向けに利用できるよう、適切にDB及びユーザーを作成します。
- インストールバージョン
- MySQL Ver 8.0.32
Web/APサーバーのインストール （作業対象：apmwebap01）
Apache HTTP Server, PHP, Wordpress をそれぞれインストールします。詳細は割愛しますが、DBサーバーを参照して Wordpress が動作するようセットアップします。
- インストールバージョン
- Apache 2.4.53
- PHP 7.4.33
- Wordpress 6.2.2
ここまでセットアップが完了したら、外部テスト端末より、Web/APサーバーへのアクセスが可能であることを確認しておきます。
Datadog のトライアルライセンス発行
Datadogの無料トライアル | Datadog （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
Datadogの14日間有効なトライアルライセンスを発行します。アカウント登録を進めると、Datadog用エージェントの登録に必要なAPIキーが発行されますので、情報を控えておきます。
Datadog Agentのインストール（作業対象：apmdb01, apmwebap01 共通）
トライアルライセンス登録時に発行されたAPIキーを含むコマンドを各サーバーに投入し、Datadogエージェントをインストールします。
# DD_API_KEY=XXXXXXXXXX DD_SITE="ap1.datadoghq.com" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"
インストール後、Datadogの管理画面より登録したホストが認識されていることを確認します。
機能の概要、インストールの詳細については 公式ドキュメント もご参照ください。 （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
監視用設定の投入
エージェントのインストール完了後、今度はサーバー毎にアプリケーション連携用の設定を投入していきます。
DBサーバー（作業対象：apmdb01）
MySQLの設定
MySQLがDatadogからの接続を受け入れる設定及び、MySQLのパフォーマンスデータ収集に必要なパフォーマンススキーマを有効にします。
MySQL
mysql> CREATE USER 'datadog'@'localhost' IDENTIFIED BY '<YOUR_PASSWORD>'; mysql> GRANT PROCESS ON *.* TO 'datadog'@'localhost'; mysql> GRANT SELECT ON performance_schema.* TO 'datadog'@'localhost';
Datadog Agent の設定
次に、Datadog AgentがMySQLサーバーに接続できるように設定します。
Datadog用の定義ファイル、mysql.d/conf.yaml を編集します。通常は /etc/datadog-agent/conf.d/mysql.d/ の下にあります。
conf.yaml
init_config:
instances:
- server: 127.0.0.1
user: datadog
pass: <YOUR_PASSWORD>
設定内容の反映には Datadog Agent の再起動が必要となりますが、あとでまとめて実施します。
機能の概要、インストールの詳細については 公式ドキュメント もご参照ください。 （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
Web/APサーバー（作業対象：apmwebap01）
Apacheのパフォーマンスデータを提供するため、Apacheのmod_statusを有効にします。
httpd.conf
LoadModule status_module modules/mod_status.so
ExtendedStatus on
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
Apacheを再起動しておきます。
# systemctl restart httpd
次にDatadogのApacheインテグレーション設定ファイルを編集します。このファイルは通常、 /etc/datadog-agent/conf.d/apache.d/conf.yamlにあります。
conf.yaml
instances: - apache_status_url: http://localhost/server-status?auto
設定内容の反映には Datadog Agent の再起動が必要となりますが、あとでまとめて実施します。
機能の概要、インストールの詳細については 公式ドキュメント もご参照ください。 （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
APMの設定（作業対象：apmdb01, apmwebap01 共通）
各サーバーにAPM連携用の設定を投入します。
Datadog用の設定ファイルである、datadog.yamlを開き、apm_configセクションの設定を有効にします。 このファイルは /etc/datadog-agent/datadog.yaml にあります。
datadog.yaml
apm_config: enabled: true
Datadog Agentを再起動します。
# systemctl restart datadog-agent
機能の概要、インストールの詳細については 公式ドキュメント もご参照ください。 （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
Datadog Webコンソールから登録状況の確認
Infrastructure -> Host Map より、各サーバーの登録状況を確認します。
APM -> Service Map
各サーバー設定したアプリケーション、APMの連携状況が表示されています。
Dashboard -> Apache - Overview
Dashboard -> MySQL - Overview
アプリケーション毎の詳細ステータスについても確認可能になっています。
外形監視についても設定してみる
Datadogでは外形監視が可能です。 外形監視とは、ユーザーの視点でシステムの動作を確認するタイプの監視のことを指します。具体的には、外形監視はシステムが提供するサービスや機能が期待通りに動作しているかを確認します。システムの内部構造やコンポーネントの状態に注目する内部監視（インフラストラクチャ監視やアプリケーション監視など）とは対照的な監視ソリューションです。
外形監視設定 ( Synthetics )
Datadogでの外形監視は、Synthetics から設定します。
メニューより、UX monitoring -> Synthetics Tests -> New Test を選択
(1) Define request
監視したいサーバーの情報を設定します。
- URL：テストしたいWebサーバーのURLとメソッドを指定します
- Name：任意のテスト名を指定します
- Additional Tags：環境識別用のタグを設定します（任意）
設定後、Test URL押下にて、接続成功することを確認しておきます。
(2) Define assertions
監視条件を設定します。この条件は要件に応じて複数設定可能です。 今回設定した内容は以下の通りです。
- When：リクエスト送信時のステータスコード期待値を"200"として定義します。
- And：リクエスト送信時の応答時間期待値を "300ms" 以下として定義します。
(3) Select locations
リクエストの送信元地域を設定します。この条件は要件に応じて複数設定可能です。 今回設定した内容は以下の通りです。
- Managed Locations：リクエスト送信元地域を"Asia/Pacific - Tokyo(AWS)"として定義します。
(4) Define retry conditions
- Retry test：失敗時のリトライ回数と許容検知時間を定義します。
(5) Define scheduling and alert conditions
リクエストの送信間隔を設定します。今回 "5分毎" に設定しました。
(6) Configure the monitor for this test
異常を検知した際の通知先を設定します。今回は自身のメールアドレス宛に通知が届くように設定しました。
(7) Set permissions
このテストシナリオへのアクセス権限を設定します。今回は特に制限なしとして設定しました。
機能の概要、インストールの詳細については 公式ドキュメント もご参照ください。 （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
外形監視状況確認 ( Synthetics )
設定後の外形監視が稼働しているかを確認します。
5分おきにチェックが入り、指定したロケーションからのテストが成功していることを確認できました。 ちなみに、リクエスト送信元のIPは選択するロケーションによって固定のものが公開されています。ファイアウォール等アクセスコントロールの際は、以下の情報をご参照ください。
https://ip-ranges.ap1.datadoghq.com/synthetics.json （2023年6月時点の情報です。リンク切れの際はご容赦ください。）
テストしてみる
ここまでで、環境のセットアップと監視連携の設定が完了しました。 続いて、負荷をかけた時と、障害の際の動作について確認してみます。
負荷をかける
外部テスト用端末から、Web/APサーバー宛てに多重アクセスし、負荷をかけます。 テストツールには、JMeterを使用しました。
しばらくすると、メール通知が飛んできました。
先ほど外形監視で設定したAssertionのうち、「リクエスト送信時の応答時間 "300ms" 以下」を満たさなかったことによる通知となります。
Datadogコンソール画面から状態を確認してみます。
Web/APサーバーのステータスが橙になっており、概要としてCPU使用率が高騰していることがわかります。
該当ホストの状態をみてみます。
やはりCPU使用率が高くなっていることが確認できます。
DBサーバーの応答速度には遅延が見られないことから、Web/APサーバーの過負荷が原因であることがわかります。
DBサーバーのプロセスを落とす
次に、DBサーバー障害を想定し、MySQLプロセスを落としてみます。
# systemctl stop mysqld
しばらくすると、メール通知が飛んできました。
先ほど外形監視で設定したAssertionのうち、「リクエスト送信時のステータスコード"200"」を満たさなかったことによる通知となります。
続いて、Datadogコンソール画面から状態を確認してみます。
APMのTrace情報からは、ステータスコード500エラーとその過程が記されています。
エラー内容の詳細と各プロセスの処理時間が確認できます。以下は関連する確認画面の一例となります。
この通り、各パフォーマンス情報とエラーの状況を容易に確認できることがわかりました。
まとめ
システムに障害や問題が発生した際、APMによって、様々な視点からアプリケーションの状態監視が可能であることが確認できました。 APMはシステムの安定運用を支える強力なツールですが、監視すべき項目や設定については、基本的にシステム管理者側で検討する必要があります。（全自動でやってくれるわけではない。） また、なんでも監視対象に入れてしまうと、適用する監視機能によっては思いもよらないコスト増となるケースがありますので、やはり慎重に監視設計を進めることをお勧めします。
ニフクラでは、コントロールパネルから 基本監視 や、パフォーマンスチャート を無料でお使いいただけます。ご要件に応じて監視ソリューションを組み合わせることによりシステムの安定運用に役立てていただければ幸いです。
注意事項
- 本記事については検証結果の１つとなります。実際に利用される場合は、事前にそれぞれの要件を確認の上、実装してください。
- 本記事ではOS上の操作についても記載していますが、ニフクラではOS以上はご利用者様の責任範囲となりますのでご留意ください。
- 本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
- 本記事で記載した各サービス/ニフクラの機能等は、2023年6月時点の情報です。利用時には各サービス/ニフクラの機能の最新情報をご確認いただきご利用ください。
