無料枠の New Relic を使って WordPress を監視してみる(設計編)

セキュリティ製品特集

#AWS Elastic Beanstalk

#WordPress

#New Relic

#監視サービス

#AWS

もきゅりん

2020.11.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、もきゅりんです。

皆さん、今日も何か監視してますか？フーコー？

自分は先月末に、毎朝晩に監視していたカブトムシ(♂)が亡くなって悲しい気持ちになりました。

でも今は代わりに彼らの子孫を監視して、すくすくと育つのを見てワクワクしています。

このブログの目的は、カブトムシではなく、WordPress(以下WP)の監視を順序立てて設計して New Relic で実装してみる(設計編)、になります。

(ただし、アラートの運用設計などは省いており、監視設計と実装の一部を扱います。)

監視の基本的な考え方は「入門監視」、「Webエンジニアのための監視システム実装ガイド (以下監視システム実装ガイド) 」に準じています。 ^*1

未読の方へ補足をしておくと、「入門監視」は監視を行うための本質的な考え方について、「監視システム実装ガイド」はその考え方を基礎にしつつ、より現場に近く、運用的な視点も含めた書籍となっています。(個人的な見解です。)

「入門監視」については、下記弊社ブログの書評もあります。

書評「入門　監視」雰囲気で監視をやっているすべての人にオススメ

今回の監視に用いる New Relic がどのようなものか知らない方は、[初心者向け] SaaS型の可観測性プラットフォーム New Relic とはどんなものかをご確認下さい。

先に結論となる New Relic の設定項目から紹介します。

なお、本稿では New Relic の具体的な設定方法については紹介しません。具体的な設定方法については、無料枠の New Relic を使って WordPress を監視してみる(設定編) をご確認下さい。

New Relic の設定

構成図

WP の環境は簡易的に ElasticBeanstalk (以下EB) で構築しています。外部 Amazon RDS データベースを備えた高可用性の WordPress ウェブサイトを Elastic Beanstalk にデプロイする - AWS Elastic Beanstalk を元に構築しています。

eb_architecture_image

アラート項目

事象	New Relic Alerts & AI	アラートレベル
トップページが表示できていない	Ping, Simple Browser (New Relicの死活監視)	電話 (強い通知)
ページロード時間の増加	Apdexスコア(APM/Browser) < 0.8 (5分間)	電話 (強い通知)
ディスク使用率	EC2 (85%以上の使用率), RDS (使用可能なストレージ容量1G以下)	メール/Slackなど (弱い通知)

New Relic の設定

New Relic 機能	主なデータ取得内容
Browser	ブラウザのページロード時間
APM	サーバーサイドの処理時間
Synthetics	Ping , Simple Browser(死活監視)
Infrastructure	標準的なOSメトリクス (CPU, Memory, Network, Storageなど)
AWS Integrations	RDSのメトリクス
Logs	Nginxのアクセス/エラーログ, RDS(MySQL)のログ(error, general, slowquery, audit)

これ以降の節では、設定の考え方を説明していきたいと思います。

そもそも監視とは何か、すなわち監視の目的 (ゴール) = 定義とは何でしょうか。

監視の定義を決める

「監視システム実装ガイド」に記載されているように、本稿の監視を以下のように考えることにします。 ^*2

広義の監視: 定期的・継続的に観測しシステムの価値を維持・向上させる営みの全て
狭義の監視: 定期的・継続的に観測し、異常を検知し復旧させること

そして、本稿においての監視の定義は、上記書籍における狭義の監視としての、定期的・継続的に観測し、異常を検知し復旧させること とします。

決めるべき項目

上記の監視の定義に、そのまま質問項目を設けられます。

監視対象は何か
異常時とはいつで、どこに何を使って発報するか
どんな頻度で、どんな手法で観測するか
誰がどのように復旧作業を行うか

また定常的にどのように対象を可視化するか(ダッシュボードの作り方、見せ方)、などもあります。

「監視システム実装ガイド」では、これら内容をしっかり整理してドキュメントにまとめ、随時更新するように推奨しています。 ^*3

それでは、1から3までを検討していきたいと思います。本稿では4の「誰がどのように復旧作業を行うか」については触れません。

1 監視対象は何か

監視対象は何になるでしょうか。

監視対象については、狭義の監視を目的として、「監視システム実装ガイド」に沿って、アラーティング目的から重要な観測項目を決めていく方針とします。 ^*4

アラーティング目的の観測項目決めは、対処が必要な項目 / 事象を漏れなく検知し通知するための取り組みです。アラーティングの先の、通知や対応を具体化できることを前提に項目を決めます。 ^*5

以下のような観点で観測項目を洗い出します。 ^*6

SLI 低下を確認するための観測項目
インシデント発生時に原因箇所を迅速に特定するための観測項目
ユーザ体験やサービスの機能要件に直接関わる観測項目
リソース利用状況
イベント・ログ
セキュリティ・コンプライアンス
運用作業のトリガー

最重要なのは、SLIに関わってくるものです。また、仮に現実的な SLI/SLO がない場合の優先順位を下記のように言及しています。 ^*7

ユーザー影響のある異常を迅速に検知し復旧する
トップページが規定時間内に応答できたことを基準とし、時間ベースで可用性を計測する

本稿で監視対象となるWPのサービスにおいても、SLI/SLOの現実的な値を設定できないとして、まずは、ユーザー影響のある異常に関わるもの、トップページが規定時間内に応答できているかを検知することを最優先とします。(その他、一般的な観測項目を追加します。)

システムの機能要件、構成図、各種リソースの詳細パラメータなどを改めて整理することが、監視の対象を明確にするのに近道になるかと思います。

SLI/SLO/SLA とは何か、という方は、下記記事の「SLI, SLOをどのように定義するか」のみ確認頂ければと思います。

モダンなシステムにSLI/SLOを設定するときのベストプラクティス - New Relic公式ブログ

2 異常時とはいつで、どこに何を使って発報するか

本当に必要なアラートのみ実装することを原則 とします。

その理由については、「入門監視」、「監視システム実装ガイド」でも強く言及されていますが、直感的に無用なアラートが飛び交うことは、アラートに対する緊張が失せていくことが容易に想像ができます。

アラートは、緊急性とそれに応じた連絡手段のセットを選択します。 ^*8

サービスを利用するユーザーの満足度に関係する度合いの高い指標になるほど、緊急性は強まっていきます。(例えば、見たいページが見れない、決済ができない、処理が遅い、など。)

緊急性が高ければ高いものほど、優先的に異常時の定義とすべきと考えます。

今回の WP の例では以下のような事象とアラートレベルのセットとしてみました。

事象	アラートレベル
トップページが表示できていない	電話(強い通知)
ページロード時間の増加	電話(強い通知)
ディスク使用率 85%以上	メール/Slackなど (弱い通知)

いつ、誰に、どんなサービスをどのように提供するのか、システムのサービスを明確にすることで、アラートに本当に必要な事象を洗い出せると思います。

また、「監視システム実装ガイド」には、具体的な通知ツールの選択肢や担当の決め方なども記載されています。 ^*9

3 どんな頻度で、どんな手法で観測するか

適切と考える必要なメトリクスによって、利用する監視ツールの選定をすべきだと考えます。場合によっては、各種監視ツールを適材適所で組み合わせて利用することも必要になってくるかと思います。

今回は (機能的に申し分ないことと自分が使ってみたい背景があるため) New Relic を使用します。

下記、再掲とはなりますが、 New Relic の機能でアラートを設定します。

なお、Apdex がどのようなものかの詳細は、Apdex：ユーザー満足度の測定 | New Relicのドキュメントをご確認下さい。

簡単に述べれば、ウェブアプリケーションやサービスのレスポンスタイムについて、ユーザー満足度を計測するための業界標準です。

設定値については Apdex T: How to Set the Right Value を参照します。

事象	New Relic Alerts & AI	アラートレベル
トップページが表示できていない	Ping, Simple Browser (New Relicの死活監視)	電話 (強い通知)
ページロード時間の増加	Apdexスコア(APM/Browser) < 0.8 (5分間)	電話 (強い通知)
ディスク使用率	EC2 (85%以上の使用率), RDS (使用可能なストレージ容量1G以下)	メール/Slackなど (弱い通知)