CDNを使用している高可用性アプリの測定に関する推奨事項を探しています

私は、高可用性アプリケーション（つまり、5秒のページ間ナビゲーションで99.5％増加しているアプリ）のパフォーマンスと可用性を正確に測定することに苦労しているFortune 500企業で働いています。この可用性の数値を決定するために、予定されたダウンタイムと予定外のダウンタイムの両方を考慮します。ただし、最近CDNをミックスに追加したため、メトリックが少し複雑になります。現在、CDNはトラフィックの約75％を処理し、残りを独自のサーバーに送信しています。

「真のユーザーエクスペリエンス」と呼ばれるものの測定を試みます（つまり、テストスクリプトは、一般的なユーザーがアプリケーションをクリックすることをエミュレートします）。これらの監視スクリプトは、ネットワークの外側にあります。時間。

経営陣は、可用性を測定するために最悪のシナリオを採用することを決定しました。したがって、オリジンサーバーに問題があり、CDNがコンテンツを正常に提供している場合でも、可用性が低下します。同じことが逆の場合にも当てはまります。私は、「ユーザーエクスペリエンス」が成功している限り、不必要に自分を罰するべきではないと考えています。結局のところ、パフォーマンスと可用性を改善するためにCDNがあります！

他のフォーチュン500企業が可用性の数値をどのように計算するかについての知識を持っている人がいるかどうか疑問に思っています。たとえば、ダウンしていないように見えるCDNを使用する店頭のapple.comを見てください（主要な製品発表がある場合を除きます）。これらの指標で不必要に自分自身を傷つける必要があるとは思わない。私たちはされているこれらの数字に基づいてビジネス上の意思決定を行います。

しかし、これらの指標が経営陣に見えることを考えると、問題は非常に迅速に解決され、解決されます（読む：すぐに赤テープを切り抜けます）。何らかの外部要因（CDN）が数値に影響しているため、アプリケーションがアップまたはダウンしていること。

考え？

（誤ってこの質問をStackOverflowに投稿しましたが、クロスポストは事前に申し訳ありません）

要約では、「利用可能」と「利用不可」を構成するものを明確に定義し、それに対して自分自身を測定する必要があります。たとえば、サイトのクライアント側のパフォーマンスSLAを「フォールド」の1秒、完全にレンダリングされたページの3秒にすることができます。パフォーマンスSLAを満たしていない場合は、その期間の可用性障害としてカウントする必要があります。CDNにアクセスしているかどうかは関係ありません。ユーザーエクスペリエンスが重要です。

ただし、5分ごとにしか測定を行っていないため、CDNとマスターサイトのヒットを別々に測定し、可用性の75％がCDNから、25％がマスターからのものであると計算するのが妥当と思われます。ここでの難点は、75％が単なる平均であることです。特定の期間の責任を正確に配分するには、計画変更中や問題が検出された場合の手動による対策など、1つまたは他のサイトが実際に顧客に対応していない時期を知る必要があります。また、マスターサイトまたはCDNのいずれかがダウンしたときに何が起こるかを考慮する必要があります。顧客はHTTP 500を取得していますか、それとも作業サイトに透過的にフェールオーバーしていますか？多くは、負荷分散ソリューションに依存します。あなたが説明した「最悪の」測定基準は単純すぎます。自問してみてください、 "

CDNがダウンしたときに「非難」するべきかどうかに関しては、絶対に。ヒットの75％がCDNに到達する場合、カスタマーエクスペリエンスの75％はそれらに依存します。顧客に優れたエクスペリエンスを提供するのはあなたの責任であるため、CDNに問題がある場合は、エンジニアリングリソースを使用してそれを証明し、プロバイダーにフォローアップする必要があります。

考慮すべきもう1つのことは、マスターサイトが長期間利用できない場合に何が起こるかです。説明したように、CDNはマスターサイトのコンテンツの静的コピーであるように聞こえます。マスターサイトが長時間ダウンしていると、CDNが古くなり始める可能性があります。したがって、SLAの一部は新鮮である必要があります。「フォールド」まで1秒、コンテンツが15分以内の完全にレンダリングされたページで3秒です。

user44700に同意します。サーバーの可用性テストとCDNを分離し、独立した2つの独立した追跡を行う方が良いでしょう。真の可用性はServer Avail * CDN Availになります。どちらかがダウンした場合-ページ/サイトがダウンしていると考えているためです。これにより、モニタリングベンダーのコストも削減されます。

ブラウザーテストを1つ作成して、失敗した項目を調べることはしませんが、Catchpointのような一部の企業には「コンテンツの可用性」という概念があります。たとえば、Webページに404を配信するファイルのCDNへの呼び出しがあるとします。ほとんどの監視ソリューションはこれが失敗であると通知しますが、実際に失敗したのはCDNでしたか？そのファイルはさらに重要でしたか？誰かが、ユーザーが気付かないレリック参照を削除するのを忘れただけかもしれません。

いくつかのアイデアについては、このブログ投稿を読むことができます：http : //blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

SLAレポートは、現実を正確に反映する必要があります。ユーザーの観点から可用性を測定しており、測定を行っているサーバーのみで問題が発生している場合、SLA内でその問題を報告してもユーザーエクスペリエンスは反映されません。

ソース情報を高水準に保ちたいと思うことは理解できます。おそらく、不正確であっても常に報告しますが、理由を特定するメモを付けます。

同意できない場合は、おそらく、測定サーバーの誤りを少なくするための技術的な解決策があります。

情報が停止として報告され、そうでない場合、報告はどのような価値を提供しますか？

私の環境では、複数のソースからレポートしています。外部の視点から可用性を報告する外部監視方法論と、人間が入力し、状況を最も正確に反映する複数の要因を考慮する内部停止記録システムを報告します。

GomezとKeynoteは、あなたが言及した種類のメトリックを収集するためのエンタープライズに受け入れられたソリューションです。Gomezには、google-analytics-esque javascriptファイルをソースとしてエンドユーザーUXを監視するサービスもあります。

Pingdomは良い：http ://www.pingdom.com/

私たちはCDN対応サイトを持つFortune 500であり、いくつかのことを使用しています。さまざまなものを検出する場合は、さまざまなものを測定する必要があると正しく判断しました。私があなたが具体的に何を望んでいるのか明確ではありません-アプリが実際にダウンしたかどうかを判断するのに役立つ可用性の数字、またはあなたの背中を管理する数字。とにかく...

1. 外部合成モニタリング-Keynote / Gomez / Webmetrics。以前はKeynoteを使用していましたが、現在はGomezを使用しています。もちろん、これにはCDNやその他の外部コンポーネントも含まれます。これは、SLA全体を測定するのには適していますが、アプリケーションのSLAを決定するのにはあまり適していません。

「CDNから」を取得するには、別のKeynote / Gomezモニターを使用し、代替DNS名などを使用して、CDNを介さずにアプリに向けることができます。ただし、まだ静的なアセットがあるため、可用性よりもパフォーマンスに役立ちます。また、インターネットの停止、エージェントの停止などをループで維持します。

2. 実際のユーザー監視。ネットワークベース（Coradiant、Tealeaf）とタグベース（Jiffy、Gomez）があります。Coradiantをネットワークスニファーとして使用し、データセンターでホストされているアセットの実際のユーザーに見えるパフォーマンス、つまり、CDNのすべての静的ジャンクではなく、実際のアプリケーションを決定します。その後、アプリのエラー率とパフォーマンスを判断するレポートを作成し、Apdex（apdex.org）を派生メトリックとして使用しました。場合によっては、ネットワークベースを使用できない（トラフィックが多すぎる、またはネットワークで取得できる場所でアセットがホストされていない）場合、タグベースはそれほど信頼できません。エンドユーザーの応答時間とエラーを実際に確認できるという大きなメリットがあります。実際のユーザーが行うすべてのケースでエラーが発生しない合成モニターを簡単にセットアップできます。

3. ローカル合成監視。Nagios / zabbix / sitescope /その他100人。アプリのモニターをローカルに向けます（CDNを通過しないでください）。実行可能な（たとえば、誰かを起こさせるためにページを送信する）可用性監視の場合、これがゴールドスタンダードです。ネットワーク関連のものは考慮しません。

4. ログ監視。ある意味では、これはゲットーの実際のユーザー監視です。しかし、いつエラーが発生したかを見たいだけの場合は、非常に便利です。実際のユーザー監視の「実際にはそうではない」という利点があります。多くの場合、Web層での時間を記録している場合を除き、可用性のみです。この場合、サーバーエンドにかかった時間を示します。SLAに直面しているユーザーには役立ちませんが、 」splunkを使用します。

「エンドユーザーストーリー」と「どのプログラマが頼る必要があるか」が必要なため、これらのいずれかではありません。

BrowserMobは素晴らしい