CMS 障害の回避: Web サイトのダウンタイムを防ぐ方法

サイトがダウンしていると見なされるとは、実際にはどういう意味ですか?

多くの場合、それはあなたが誰に尋ねるかによって異なります。

Web サイトがダウンしていると見なされるには、さまざまな意味があります。

• ウェブサイトは完全に利用できません。
• Web サイトはオンラインですが、使用できないほど遅いです。
• Web サイトで、特定のユーザーまたは場所に対してエラー メッセージが表示されます。
• Web サイトはほとんどの訪問者に対して機能していますが、コンテンツの作成、編集、公開などのために CMS にログインできない人もいます。

原因や程度に関係なく、Web サイトのダウンタイムの影響は、e コマースの注文の損失やユーザーの不満から顧客の信頼の低下に至るまで、深刻なものになる可能性があります。

CMS 障害の回避シリーズの第 3 回では、Web サイトのダウンタイムの古典的な根本原因と、それを回避するために継続的な監視やその他の要因が果たす役割について説明します。

まず、継続的な監視が果たす役割

私たちはウェブサイトのさまざまな側面を監視しているため、完全に管理された WordPress VIP プラットフォームを構成するさまざまなレイヤーのいずれかで何かが正しく機能していないことを知ることができます。 これらの層は次のとおりです。

• ネットワーク接続
• ロードバランサー
• ウェブサーバー
• オブジェクトキャッシング (Memcached)
• データベース
• エラスティックサーチ
• ファイル サービス (CDN)

ウェブサイトの安定性に影響を与える可能性のある将来の問題を予測できるように、問題を早期に発見するよう努めています。 さまざまなシステム コンポーネントのログを相互参照することで、Web サイトが不安定であると報告された期間を確認できます。 ダウンタイムの原因は単一の問題ではなく複数の要因の組み合わせである可能性があるため、多くのツールを使用して、システムとアプリケーションの両方でデータを比較しています。

ほとんどの場合、ウェブサイトが不安定になる原因はアプリケーション コード、つまりカスタムまたはサードパーティの WordPress テーマとプラグイン コードです。 不安定なサイトを調査する際に確認するいくつかの事項と、それぞれを軽減する方法を次に示します。

キャッシングが不十分

サイトのパフォーマンスと安定性を確保するためにできる最も重要なことは、キャッシュできるページ全体がキャッシュされるようにすることです。 キャッシュされていないページは、要求されるたびにサーバー上で構築する必要があります。これは、プロセスが遅くなり、エラーが発生しやすくなります。

WordPress VIP の回答:

WordPress VIP プラットフォームは、エッジ キャッシュ サーバーのグローバル ネットワークを介して強力なページ キャッシングを提供します。各エッジ キャッシュ サーバーは、エンド ユーザーに最も近いコンテンツを保存および提供するために使用されます。 エッジ キャッシュ サーバーからの応答時間は、ほとんどの場合、ページ キャッシュをバイパスしてオリジン サーバーにヒットするものよりもはるかに高速です。

キャッシングの課題

パーソナライズされた完全にインタラクティブなエクスペリエンスが必要なため、一部のサイト、特に e コマース サイトでは、ページ キャッシュ レベルでキャッシュすることはできません。

多くの場合、静的ページがエッジ キャッシュによって提供され、動的機能 (ログイン ステータス、ショッピング カートなど) が JavaScript によって追加されるという妥協が見られます。 JavaScript からの非同期リクエストを使用して、ページ全体の読み込みよりもはるかに低いオーバーヘッドで設計された WordPress REST API エンドポイントと通信できます。

あるいは、ここでオブジェクト キャッシングの出番です。 ページは動的なままにすることができますが、ページの一部とページで使用されるデータをオブジェクト キャッシュに格納して取得することで、データベースへのクエリを実行する必要がなくなります。

WordPress VIP の回答:

各 WordPress VIP アプリケーション環境には専用の Memcached クラスターがあり、オブジェクト キャッシュ データをメモリに保存して、非常に迅速かつ効率的に取得できます。

テストされていないコードの展開

これは、Web サイトのダウンタイムのもう 1 つの一般的な原因であり、純粋な原因と結果に基づいて診断するのは非常に簡単です。

あなたの Web サイトがテストされていないコードを展開したばかりで、サイトの問題がすぐに発生する場合は、おそらく原因があります。 可能であれば、疑わしいコードをできるだけ早く以前のバージョンに戻してください。

このような状況を回避するために行う最善のことは何ですか? 本番環境にリリースする前に、個別の開発環境またはステージング環境ですべてのコードを徹底的にテストします。

WordPress VIP の回答:

すべてのサイトの展開は GitHub を介して行われるため、WordPress VIP のお客様は、新しいコードの変更を失うことなく、簡単にコードを元に戻すことができ、GitHub の改訂履歴に安全に保存されます。 オプションで、緊急時に、GitHub とは別に、お客様に代わってお客様の Web サイトを以前のデプロイにロールバックすることができます。

環境に関しては、当社のフル マネージド サービスでホストされているすべてのアプリケーションは、個別の開発環境またはステージング環境を持つことができます。 本番環境からのデータの同期は簡単で、本番 Web サイトと同じ量と同じ種類のデータに対してコードをテストできます。

PHP エラー

WordPress はサーバー上で PHP コードを使用します。 PHP エラーは「致命的」である可能性があります。つまり、エラーが発生すると、Web ページ、スクリプト、またはコマンドの実行が停止します。 これらはほとんどの場合、目に見えるエラーとしてどこかに現れ、PHP ログに記録されます。

注: PHP 7 の一部の PHP 警告は、PHP 8 では致命的なエラーになるため、これらのエラーを真剣に受け止めることが重要です。

WordPress VIP の回答 (および役立つアドバイス):

当社のプラットフォームはすべての PHP エラーを自動的にログに記録し、WordPress VIP のお客様がダッシュボードで利用できるようにし、当社のエンジニアが利用できるようにします。

プロのヒント: サイトが正常に動作しているように見えても、すべての PHP エラーに対処して修正します。 定期的に、安定しているように見えるサイトで、致命的なエラーを含む PHP エラーでいっぱいのログを目にします。 ただし、必ずしもサイトが正しく機能しているとは限りません。 マイナーなエラーや警告に対処して PHP ログを明確に保つことで、デバッグ中により深刻なエラーを見つけやすくなります。

遅い MySQL データベース クエリ

すべての WordPress Web サイトは、データベースを使用して Web サイトのコンテンツと構成データを保存します。 データベース クエリは Web ページのコンテンツ データをフェッチしますが、これらのクエリは非効率的に記述される場合があります。 数百ページしかないサイトでは問題なく動作するかもしれませんが、大量のデータを処理すると失速します (当社のプラットフォームの一部の Web サイトには数百万の保存されたレコードがあります)。

遅いクエリはデータベース リソースを拘束し、SQL を実行するページ、スクリプト、またはコマンドだけでなく、アプリケーション全体でサイトの安定性に影響を与える可能性があります。 実行に 0.75 秒以上かかるクエリなど、単一または複数のデータベース クエリが遅いため、サイトはしばしば苦労します。

WordPress VIP の回答:

WordPress VIP は、すべてのデータベース書き込みクエリが発生するプライマリ データベースと 1 つ以上の読み取り専用レプリカ データベースを備えた専用データベース クラスターを各アプリケーションに提供することで、データベースのボトルネックを軽減するのに役立ちます。 これにより、同時に実行できるデータベース クエリの数が増加し、サイトに負荷がかかっているときにリソースの負荷が分散されます。 とはいえ、低速のデータベース クエリは、データベース リソースを追加するだけで常に解決できるとは限りません。 そのため、Query Monitor と New Relic (当社のプラットフォームで提供) を使用して、遅いデータベース クエリを監視することをお客様にお勧めします。 これらはクエリがデータベースのどこで発生したかを強調するため、開発チームはクエリをリファクタリングしてパフォーマンスを最適化できます。

最後に、当社のアプリケーション サポートとプレミア エンジニアは、お客様のチームがこれらのクエリを見つけて分析し、速度と効率を改善する方法を提案するのにも役立ちます。

過剰なデータベース書き込み

カスタム ロギングやトラッキング コードなどの機能によって、リクエストごとにデータベースが更新されることがあります。 これは、次の 2 つの理由で不安定になる可能性があります。

• 前述のデータベース レプリカ: すべての書き込みクエリはプライマリ データベースに送信されます。 同じページ要求内の同じテーブル (または複数のテーブル) に対する後続のデータベース クエリもそこに送信されます。 データベースのレプリカを利用しないと、サイトのスケーラビリティが制限されます。
• ページ キャッシングのバイパス: ページ リクエストごとにデータベースへの書き込みを行うには、ページ キャッシングをバイパスする必要があります。 しかし、そうするということは、防御の最初の (そして最善の) ラインが侵害されたことを意味します。

WordPress VIP の回答:

このような状況では、機能をリファクタリングすることをお勧めします。 たとえば、コンテンツ分析は通常、サーバー側のコードではなく、ページ内の JavaScript のスニペットを使用する外部サービスに委任するのが最適です。サーバー側のコードでは、キャッシュがうまく機能せず、データベースへの過剰な書き込みが発生する可能性があります。

ダウンタイムのその他の既知の原因とその回避方法

プラグイン

WordPress エコシステムには、優れた機能を提供する人気のある便利なサードパーティ製プラグインが何千もあります。 ただし、スケーリングに課題があり、大量のコンテンツとトラフィックを含む Web サイトに追加すると、ダウンタイムの問題が発生する可能性があります。

WordPress VIP の回答:

優れたエコシステム管理者として、トラフィックの多い環境でプラグインのパフォーマンスを向上させるための提案を定期的にベンダーに提供しています。 また、当社のプラットフォームで大規模に試行およびテストされた代替プラグインを提案することもできます。

カスタム ロギング

カスタム ロギングは強力なデバッグ ツールであり、多くの場合、本番サイトでのみ発生すると思われるバグや問題を追跡するための唯一の実行可能な方法です。 しかし、多くの場合、トラフィックの多いサイトで PHP に組み込まれたカスタム ロギングが処理速度を低下させたり、データベースへの過剰な書き込みによってサイトがダウンタイムの危険にさらされたりするのを見てきました。

WordPress VIP の回答:

お客様には、WordPress VIP アプリケーション ダッシュボードのヘルス パネルで標準の PHP ログへのアクセスを提供しています。 そこに、データベースに悪影響を及ぼさないカスタム エラーをログに記録できます (また、New Relic にもログを記録できます)。

リモート API 呼び出し

一部の Web サイトでは、他のアプリケーションやサービスへのサーバー側 REST API 呼び出しを利用しています。 これらは通常の状況では非常に高速ですが、基盤となるアプリケーション コードによって応答が遅くなったり、タイムアウトになったり、エラーがスローされたりすることがあります。

WordPress VIP の回答:

これらの問題を最小限に抑えるために、「防御的コーディング」をお勧めします。 リモート呼び出しの目的にもよりますが、多くの場合、リモート リクエストが失敗した場合、以前のリクエストからのキャッシュされた応答にフォールバックすることができます。または、少なくとも「エラーを適切に処理」して、ページの残りの部分をまだロードします。 これらのシナリオを処理するために、いくつかのヘルパー関数が用意されています。 タイムアウトを低く保つことは、リモート API が応答しない場合に PHP リソースがより迅速に解放されることも意味します。

詳しくは、CMS 災害の回避シリーズをご覧ください。

ビジネスが危機に瀕している場合、コンテンツ管理システム (CMS) で貧弱なデジタル エクスペリエンスを提供することによって、新しいビジネスを別の場所に送り出し、ブランドを傷つける余裕はありません。 ウェブサイトのパフォーマンスを改善する方法では、5 つの一般的な速度低下の原因を診断し、アジャイル CMS を使用して物事を加速する方法を説明します。

交通量の多い日はお祝いの場であるべきです。サイトやアプリケーションを維持しようとし、負荷を処理するために鼻歌を振るエンジニアにとっては悪夢ではありません。 高トラフィック向けの WordPress のスケーリングでは、WordPress Web サイトがこれらのトラフィックの波を処理できるようにするための 4 つのアプローチについて説明します。