金曜日の午後、WordPressサイトで突然トラブルが発生したとします。その瞬間から、組織は2つの問題に直面します。1つはサイトを復旧すること、そしてもう1つは、「原因は誰にあるのか」を突き止めることです。
そして実際には、後者の方が時間がかかることも少なくありません。開発者は「公開したばかりの変更が原因ではないか」と考え、マーケティング担当者はサーバー側の問題を疑います。制作会社や運用担当者は双方から連絡を受けますが、判断材料となる情報を十分に持っていません。ようやく調査の方向性が定まった頃には、サイト停止による損失だけでなく、原因究明に費やした時間も大きなコストになっています。
問題の本質は、関係者の意見が食い違っていることではなく、それぞれが異なる情報を見ながら判断していることにあります。開発者はコードを、マーケティング担当者はアクセス状況を、制作会社はサポート対応の状況を確認しており、全員が同じデータを同じタイミングで見ているわけではないため、原因を効率よく絞り込むことができません。
Kinstaでは、こうした状況を防ぐため、すべての関係者が同じ情報をもとに調査できる環境を提供しています。Kinstaのサポートエンジニアが障害調査に使用するレスポンスコード、PHPパフォーマンス、キャッシュヒット率、リクエストログといったデータは、MyKinstaで分析権限を持つユーザーであれば誰でも確認できます。同じデータを共有することで、原因を押し付け合うのではなく、全員で協力して問題を解決できるようになります。
また、サポートとのやり取りもよりスムーズになります。この記事では、MyKinstaで利用できる各種分析ツールの概要や活用方法に加え、それらを個人のデバッグ作業だけでなく、チーム全体で効率よく問題を切り分けるためのワークフローとして活用する方法をご紹介します。
パフォーマンスの問題が「責任の押し付け合い」になる理由
企業のWordPressサイトは通常、ひとりで管理するというケースはほとんどないでしょう。開発者がコードを管理し、マーケティング担当者がキャンペーンを運用し、制作会社やフリーランスがホスティングやサイト運用を担当するのが一般的です。それぞれが自分の役割をこなす一方で、見えている情報は必ずしも同じではありません。
そのため、サイトに問題が発生すると、本来は技術的な問題であるはずなのに、いつの間にか「誰に原因があるのか」という話になってしまいます。
- 開発者：コードは確認できるが、サーバーの状態までは把握できないため、原因がサーバー側にあっても気づきにくい。
- マーケティング担当者：アクセス状況は把握できるが、データベースの状態は確認できないため、アクセス急増など、自分が見えている変化を原因だと考えがち。
- 制作会社やフリーランス：問い合わせの窓口になるが、障害の原因を判断するための情報を持っていないこともよくある。その結果、各担当者の間を取り次ぐ役割に終始してしまう。
共通して確認できる情報がない場合、それぞれが「原因は他の担当者にあるのでは」と根拠もなく考えてしまいがちです。さらに、多くのサーバーでは、診断に必要なデータをサポート担当しか確認することができません。その場合、ユーザーはサポートへ問い合わせ、自分で見ることができないログをサポート担当が確認し、その回答を待つことしかありません。
Kinstaでは、このような課題を考慮し、これとは異なるアプローチを採用しています。以下、問題が発生した際に確認したいKinsta専用コントロールパネル「MyKinsta」のツール、それらを関係者全員で状況を共有しながら調査を進めるためのワークフローに取り入れる方法をご紹介します。
サイトに問題が発生したとき、MyKinstaの分析画面で確認できること
サイトで問題が発生したら、まずは「どのような問題が起きているのか」を正しく把握することが重要です。表示速度が低下しているのか、エラーが発生しているのか、それともアクセスの急増によって負荷がかかっているのかによって、取るべき対処が異なります。
例えば、キャッシュの問題をサーバーの問題と勘違いしたり、一時的なエラーの増加をトラフィックの急増が原因だと思い込んだりすると、原因の切り分けに余計な時間を費やすことになります。
こうした状況でまず確認して欲しいのが、MyKinstaの「分析」画面です。
MyKinstaのダッシュボードからアクセスできる「分析」画面には、企業全体のデータが表示されます。サイトごとの分析データは、「サイト」＞（サイト名）＞「分析」に移動してください。いずれの画面でも、アクセス権を持つすべてのユーザーが同じ分析データを閲覧できます。
サイトが実際にエラーを返しているかを確認する
何よりもまず、サイトが実際にダウンしているのか、それとも単に動作が遅いだけなのかを確認します。原因も対処法も異なるため、この見極めを誤ると調査が長引き、関係者の間で原因を探り合う状況にもなりかねません。
「レスポンス」タブの「レスポンスコードの内訳」には、選択した期間中にサイトが返したHTTPステータスコードの分布が表示されます。
500番台のコードが集中している場合はサーバーまたはアプリケーションに問題があることを示し、400番台のコードが集中している場合はリソースへのアクセスに問題があることを示します。さらに2つのチャートを使用して、さらに掘り下げることも可能です。
- 500番台エラーの内訳：一般的な500エラーと、それぞれ異なる原因を示す502 Bad Gatewayや503 Service Unavailableを区別
- 400番台エラーの内訳：クライアント側のコードを分類し、404エラーの集中発生と、認証、権限、またはレート制限の問題を示すその他のレスポンスを区別
分析データへのアクセス権を持つすべてのユーザーが同じ内訳を確認できるため、原因を推測するのではなく、具体的な問題の解決にすぐに取り掛かることができます。
動作が遅いサイトと障害が発生しているサイトを区別する
サイトの表示に6秒かかる場合も、500エラーが表示される場合も、訪問者にとっては快適な体験とは言えません。しかし、その原因はまったく異なります。「パフォーマンス」タブでは、それぞれを区別して確認できます。
サイトの動作が遅い原因を調査する際には、以下のチャートが役立ちます。
- PHP+MySQL平均応答時間：キャッシュされていない各リクエストに対して、アプリケーションが処理やクエリを実行するのにかかる時間を示す。急激な上昇は、通常、インフラの問題ではなく、パフォーマンス低下の最初の兆候。
- PHPスループット：その期間に実行されたリクエストの数を示す。コードの変更ではなく、スループットの急増とパフォーマンスの低下が一致する場合、その原因はバグではなく負荷である可能性が高い。
- AJAX使用状況：admin-ajax.phpのアクティビティにおける急増の有無がわかる。これは、プラグインやバックグラウンドタスクを実行しているログイン済みユーザーによって引き起こされる、バックエンドリソースの消費要因として一般的でありながら見過ごされがちなもの。
- アップストリーム時間最大値上位：最も遅い個々のパスが一覧表示されるため、推測に頼ることなく、サイトの平均時間を引き上げているページやエンドポイントを直接特定できる。
これらを総合的に判断することで、次の対応としてアプリケーションの最適化を行うべきか、それとも障害としてエスカレーションすべきかがわかります。
サイトのどの程度がキャッシュされているかを確認する
サイトの表示速度が遅い原因は、コードやインフラではなく、キャッシュから配信される割合が低いことにあるかもしれません。キャッシュ比率が低下すると、サーバーは本来処理する必要のないリクエストを処理することになり、その結果、応答時間が長くなります。「サーバー環境に原因があるのではないか」と疑われることの多いケースですが、実際にはサーバーが原因であることはほとんどありません。
「キャッシュ」タブでは、Kinstaのキャッシュレイヤー全体でリクエストがどのように処理されているかが表示されます。
各リクエストは、以下のいずれかに分類されます。
HIT：キャッシュからリクエストを配信することを意味する（ほとんどのトラフィックはこれが望ましい）BYPASS：ルールや競合によりリクエストがキャッシュから除外されていることを意味するMISS：コンテンツがまだキャッシュされていないが、最初のリクエスト後にキャッシュされることを意味する
正常なサイトのキャッシュチャートは、HITが大部分を占めます。BYPASS率が上昇した場合、「トップサーバーキャッシュバイパス」レポートで、キャッシュをスキップした具体的なパスを確認できます。
一部のバイパスは問題ではありません（WordPressのログインページがキャッシュされない場合など）。しかし、キャッシュ可能なページがここに表示されている場合は、プラグインの競合やキャッシュルールの問題を示唆しています。ページの表示が遅くなった場合は、これらのデータを確認することで、サーバーに問題があると決めつけるのではなく、そのページがキャッシュされているかどうかを判断できます。
リソースを消費している要因を特定する
サイトにエラーは発生していないものの、想定以上に帯域幅や容量を消費している場合は、「上位リクエスト」チャートで原因を特定できます。リソースに関する問題は特定が最も困難です。帯域幅の超過や負荷による速度低下には、通常エラーコードは表示されません。
以下の3つのチャートを確認することで、原因となっているURLやリソースを特定できます。
- サーバー帯域幅：オリジンサーバーから直接最も多くのデータを取得しているURLを確認できる
- 総帯域幅：CDNおよびエッジキャッシュによって配信されたデータを合算するため、各リクエストの全体的な負荷を確認できる
- アクセス数：サイズに関係なく最もリクエストの多いリソースを表示し、単一の大きなファイルではなく、常に負荷がかかっているエンドポイントを確認できる
これらを組み合わせることで、リソースの急増が巨大なメディアファイル、制御不能なエンドポイント、あるいは同じパスに何千回もアクセスするクローラーのいずれに起因するかを明らかにすることができます。そこから、通常はアセットの最適化、CDN経由での配信、またはエンドポイントへの対応といった対策が講じられます。
トラフィックの急増の原因がクローラーやボットである場合、ボット対策機能を使用すれば、プラグインを操作したりサポートに問い合わせたりすることなく、MyKinstaから直接、非人間によるトラフィックを特定、分類、ブロックすることができます。
APMでパフォーマンス問題の原因を特定する
上でご紹介した分析データでは、サイトで「何が起きているか」がわかります。次にKinstaのAPMツールを利用することで、その原因を突き止めることができます。例えば、分析データでPHPの応答時間が午後2時に急増したことがわかったら、APMを有効化して、どのプラグイン関数、データベースクエリ、または外部API呼び出しが原因だったかを特定可能です。
APMはすべてのプランに標準搭載されており、MyKinstaに組み込まれています。
APMは必要時にのみ有効化
「分析」画面が常にデータを収集しているのに対し、APMはデータ収集中にサーバーのCPUやメモリを使用します。そのため、APMは問題の調査中に必要な時間だけ有効にすることをおすすめします。
APMを有効にするには、MyKinstaで「サイト」＞（サイト名）＞「APM」に移動し、「APMを有効化」をクリックします。監視時間（2時間、4時間、12時間、24時間）を選択し、「監視を有効にする」をクリックすると、APMが起動します。選択した時間が経過すると、APMは自動的に無効になります。
つまり、APMは次のような流れで活用できます。
- 問題が発生した、または再現できるタイミングでAPMを有効にし、通常時は無効にしておく。これにより、サーバーへの負荷を最小限に抑えられる。
- 問題が発生しそうな時間に合わせて監視時間を設定し、問題を再現するか、再び発生するのを待つ。これにより、問題発生時のデータを取得できる。
- 十分なデータが収集できたら結果を確認し、調査が終わったらAPMを無効にする。
APMの分析結果の見方
APMでは、収集したデータが「トランザクション」「WordPress」「データベース」「外部」の4つのタブに分類して表示されます。
まずは「トランザクション」タブで、処理時間の長いリクエストを確認します。各トランザクションを開くと、そのリクエストで実行された処理のタイムラインが表示され、特に時間がかかっている処理を確認できます。これにより、データベースクエリ、特定のプラグインの処理、サードパーティAPIなど、どこに最適化の優先順位を置くべきかを判断できます。
また、「外部」タブは、原因がサーバー環境にあるのかどうかを切り分ける際に役立ちます。例えば、リクエストの遅延が外部APIへの通信によるものであれば、APMでわかります。そのため、「サイトの動作が遅い」と漠然とサポートへ問い合わせるのではなく、「原因はサーバーではなく、メール配信サービスのAPIにある」といった具体的な情報をもとに調査を進められるようになります。
ログビューアとアクティビティログで時系列を把握する
問題の原因を特定するには、「何が」「いつ」「どのような順序で」起きたのかを把握することが重要です。MyKinstaでは、「ログビューア」と「アクティビティログ」の2つを組み合わせることで、その経緯を時系列で確認できます。
ログビューアにはサイト上で発生した処理やイベントが記録され、アクティビティログにはユーザーが実行した操作が記録されます。
ログビューアでは、サイトのパフォーマンスではなく、サイト上で実際に発生した処理やイベントを確認できます。MyKinstaの「ログ」画面では、以下の3種類のログを利用できます。
error.log：PHPエラーや警告を記録。ページが正しく表示されない場合はまずこのログを確認。kinsta-cache-perf.log：キャッシュの動作状況を記録。ページがキャッシュから配信されたのか、それともキャッシュを経由せずに配信されたのかを確認できる。access.log：サイトに届いたすべてのHTTPリクエストを記録。アクセス状況の分析や、繰り返し発生する404エラーの調査に役立つ。
ログビューアでは最大20,000行まで表示でき、任意の文字列で絞り込み検索を行うこともできます。また、より詳細な分析が必要な場合は、MyKinstaのファイルマネージャーからログファイルをダウンロードし、外部ツールで確認することも可能です。
アクティビティログ：誰が何を行ったかを確認
アクティビティログには、MyKinstaでサイトに対して実行されたすべての操作が、時系列で記録されます。
アクティビティログは、「サイト」＞（サイト名）＞「ユーザーの活動」から確認できます。各エントリには、簡潔な操作内容の説明、ユーザー名、タイムスタンプ、およびステータスアイコンが表示されます。ステータスは、緑色のチェックマークが成功、赤色の感嘆符が失敗を意味します。
他のログと組み合わせて確認することで、問題の原因をより正確に切り分けることができます。例えば、error.logにエラーが記録されている場合は、アクティビティログで同じ時間帯の操作履歴を確認することで、どの操作がエラーの発生につながったのかを特定できます。
稼働監視で問題をいち早く把握する
これまで紹介したツールは、問題が発生した後に原因を調査するためのもの。稼働監視は問題の検知を自動化します。訪問者から「サイトが表示されない」という連絡を受けて初めて気づくのではなく、Kinstaとサイト管理者がほぼ同時に問題を把握できるようになります。
Kinstaでは、すべてのサイトを1日約480回監視しています。また、「ユーザー設定」＞「通知」で稼働監視の通知を有効にすると、重要な問題が検出された際にメールで通知を受け取ることができます。
- サイトエラー：サイト自体で検出された問題を通知
- SSLエラー：は、訪問者がサイトから離脱する前に、証明書や設定の問題を通知
- ドメインの有効期限切れ：ドメインが失効する前にその旨を通知
なお、一時的な通信エラーによる誤検知を防ぐため、通知は最初の失敗時ではなく、3回連続で監視に失敗した場合に送信されます。
KinstaのパートナーであるSIX15 Solutionsでは、30以上のクライアントサイトでこの機能を活用しています。その価値は監視そのものではなく、クライアントが問題に気づく前に、多くのトラブルへ対応できる点にあるようです。
現在、Agencyプランで30件以上のクライアントサイトを管理しています。小規模なマーケティングサイトから数千人規模の会員制サイトまで幅広く運用していますが、これまで問題やサイトダウンは一度も発生していません
ただし、すべての通知が問題の発生を意味するわけではありません。プランの利用上限に近づいた際に送信される「プランのご利用限度に関するお知らせ」は、問題を未然に防ぐための早期警告として役立ちます。
また、「分析」画面を確認することで、利用上限に近づいた原因も把握できます。例えば、キャンペーンによって想定以上のアクセスが発生した場合や、クローラーやボットによるアクセスが増加した場合など、原因を特定したうえで適切な対策を講じることができます。
共通のデータで原因究明をもっとスムーズに
サイトで問題が発生すると、実際の復旧作業よりも、「何が原因だったのか」「誰が対応すべきなのか」を突き止めることに時間がかかるケースは少なくありません。
MyKinstaの「分析」画面では、サイトが遅いのか、エラーが発生しているのか、それとも負荷が集中しているのかを把握できます。さらに、APM、ログビューア、アクティビティログ、稼働監視などを組み合わせることで、問題の発生をいち早く検知し、関係者全員が同じ情報をもとに調査を進められます。
重要なのは、これらの機能を個別に使うのではなく、社内全体で情報を共有するためのワークフローに取り入れることです。関係者全員が同じ分析データを確認できれば、サポートへ問い合わせる前の段階で原因を効率よく切り分けることができます。その結果、「誰が悪いのか」を議論するのではなく、「何が起きているのか」を中心に調査を進められるようになります。
複数の担当者でサイトを運用している場合、KinstaのWordPress専用マネージドクラウドサーバーなら、関係者全員が同じ情報をもとに問題へ対応できます。また、多数のクライアントサイトを管理している制作会社には、共同管理や権限共有機能を利用できるエージェンシーパートナープログラムもご用意しています。
