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

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

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

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

決めるべき項目

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

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

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

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

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

1 監視対象は何か

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

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

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

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

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

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

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

本稿で監視対象となる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など (弱い通知)

なお、New Relic で電話通知する際には、 PagerDuty との統合や Twilio を使った Webhook の設定などが必要です。

New Relicのアラートをトリガーに電話やSMSで通知を受ける - New Relic公式ブログ

New Relic でできることは非常に多いですが、ウェビナー New Relic はじめの一歩 の「APM 利用の成熟度に関するベストプラクティス」でも記載されているように、まずはエラー分析やレイテンシ、ベースラインアラートを中心に導入していきます

以上で、監視のゴールを「定期的・継続的に観測し、異常を検知し復旧させること」 とした際の設計の考え方、 WP と New Relic を使った設計になります。

冒頭にも記載しましたが、具体的な New Relic の設定については、無料枠の New Relic を使って WordPress を監視してみる(設定編) をご確認頂ければと思います。

最後に

監視は一度設計して実装すれば終わり、というものではありません。

随時見直しや改善を行っていかなければならないので、その運用スキームの検討やサービス向上していくために測定すべき対象や SLIや SLO などの追加、更新していくための段階的ステージも考えていく必要があります。

いち早く警報システム的な役割を設計・設定して脱し、「監視システム実装ガイド」で記載されている広義の監視の役割となる、定期的・継続的に観測しシステムの価値を維持・向上させる営みになっていければより楽しそうだなあ、と思いました。

以上です。

どなたかのお役に立てば幸いです。

参考

脚注

  1. 自分の中で整理しやすいように双方を織り交ぜて組み立てています。両書籍における一貫した論理体系を確認したい方は書籍にあたっていただければと思います。
  2. 馬場 俊彰『Webエンジニアのための監視システム実装ガイド』Compass Booksシリーズ,2020-03, p.4
  3. (監視システム実装ガイド, p.94)
  4. (監視システム実装ガイド, p.122)
  5. (監視システム実装ガイド, p.124)
  6. 当然ですが、広義の監視を検討する上では、アラーティング目的からの観測項目だけでは不足してくるかと思います。
  7. (監視システム実装ガイド, p.86)
  8. (監視システム実装ガイド, p.78)
  9. (監視システム実装ガイド, p.111,115)