CDN障害をいち早く検知するためのNew Relic Synthetics活用法

CDNが落ちることに備えて 

CDNは、インターネットで何かしらのサービスを実現しようとする場合に、利用を避けては通ることができない存在となっているのはみなさまもご存知かと思います。その様な中で、CDNが一時的とはいえダウンしてしまうということは、みなさまが日々提供しているサービス自身もエンドユーザ様から利用することができなくなってしまうということを意味しています。

CDNに不測の障害が発生し自社サービスに影響がでるという経験を通して多くの学びがあるかと思いますが、元々CDNプロバイダーに所属していた経験から挙げるとすると、『CDNは決して落ちないということはなく、落ちた場合を想定して、どの様な準備をしておくか』が重要です。

CDNが落ちてしまった場合にとりうる手段としては以下のようなケースが挙げられます。  

• 障害を回避するために障害のあるCDNを外し、他のCDNに一時的に切り替える
• CDNを外し、直接自社オリジン(CDN用語で、お客様のデータセンターやシステムを意味します。)で配信を行う

  こうした決断を迅速に行い、そのための運用を行う必要があります。この判断材料となるためにCDNのデータを常時収集し、適切な判断材料を提供することがNew Relic Oneがもつ1つの大事な役割と考えています。

サービスの停止をNew Relic Oneで把握するには

データの収集や適切な形の情報を把握するために、もしものCDN障害を検知するかは、是非、New Relic Oneの１つの機能であるSyntheticsの活用を強くお薦めします。New Relic Oneのライセンスを契約されていて、Full Userのユーザアカウントをお持ちであれば、今すぐにご利用可能です。

Synthetics自体は、さまざまな用途に合わせて複雑な設定を行うことは可能ですが、CDNの異常を検知するという観点では、以下のシンプルな設定を行うのがおすすめです。

Syntheticsの設定方法

New Relic Oneにログインして、右上のAdd more dataをクリックします。

さまざまな設定メニューが表示されますので、画面の中程にある[Simulate traffic]セクションの[New Relic Synthetics]タイルをクリックしてください。

複数のSyntheticsのための設定メニューが表示されます。

メニューの中にある、Availabilityを選択します。

選択すると、SyntheticsのHeadリクエストPollingを行うための設定画面になります。

• Accountには、複数のアカウントをお持ちの場合プルダウンメニューからデータを管理したいアカウントを選択します
• Nameには管理をしやすい任意の名前を指定します。
• URLは、Headリクエストを送りたいURLを指定します。例えば、トップページやポーリングのためのダミーのページやオブジェクトでもかまいません。(ここで指定するURLは、リクエストがCDN経由になるようにご用意されているCNAMEレコードを指すFQDNとなるようにしてください。)
• Periodは、プルダウンから適切なポーリング周期を設定します。最短1分から、最大1日の範囲で周期を設定することができます。

TagsやAdvanced optionsについては必須ではないので、割愛します。

上記の設定を行うと、画面下部で[Select locations]をクリックすることができるようになります。[Select locations]をクリックし、次の行程に進んでください。

次に、どのNew Relic Oneの拠点からSyntheticsを稼働させるかを選択する画面が出てきます。日本で展開されているサービスであれば、[Tokyo, JP]にチェックを入れていただくのが良いでしょう。想定されるエンドユーザー様に近い位置にあるlocationにチェックを入れてください。

チェックを入れていただくことで、画面下部の[Save monitor]をクリックすることができるようになります。クリックを行い設定が完了となります。

上記の設定で、定期的にSyntheticsがリクエストを送信するようになります。結果をNew Relic Oneポータルにて参照可能となります。

上記の設定では、まだNew Relic One内でのアラートの設定や外部通知については行っていません。こちらについては別の記事でお伝えしたいと思います。  

CDN障害をNew Relic Oneで可視化してみると

CDNの障害では、Syntheticsのデータではポーリングが失敗したり、500番台のエラーが急に増加した(CDNが返している)といった事象として表面化します。どのようなことが見えるか少し紹介します。

Success rateが100%ではなくなっていることが記録されます。CDNの役割としてSuccess rateが劣化すること自体が、期待される事象ではありません。何かしらの障害が発生したのではないかという事が考えられます。CDNを利用している構成でSuccess rateが劣化した場合、システムの状況を把握しながら、サービス影響が発生していないかを確認して頂くのが良いと思います。

500番台エラーの急激な増加も確認することができます。これだけではCDNがエラーを返したのか、自分たちのシステムが返したのかの判断をするのは難しいと思います。一方で、New Relic Oneは一元的にシステム側の状態も把握することができるため、InfrastructureやAPMなどのシステムの状態ととSyntheticsの状態をNew Relic One上で突き合わせることによって、今回はCDNがエラー返していることが容易に判断することができます。

＜ Failuresレポートによる大量の500番台のエラー一覧 ＞

こちらについては、日頃からレポート上にエラーが上がってこないように意識されている箇所と言えますので、急にエラーが増えたということ自体が何かおかしなことが発生していると判断できる情報となりました。(常日頃から、Failureレポートにエラーが上がってこない様にする取り組みも大事になってきます。)

< SLAレポートに現れるuptime%の劣化 >

こちらは、例えば、前日までのUptimeが100%だった状況から、Syntheticsのリクエストに対する正しいレスポンスを返すことができない状況が発生し、Uptimeが急に100%を維持できない状況になっているということが容易に把握できます。

CDN をご利用のお客様は、New Relic OneのSyntheticsを利用して、CDN の状況を常に把握しておける状態にしておくことをおすすめします。またNew Relic Oneには CDN のログデータを取り込むことも可能ですので、興味がある方はぜひやってみてください。取り込んだログデータから以下の様なグラフを作成することができ、問題発生時にはグラフに谷間ができていることをご理解いただけると思います。

今後 CDN のデータをNew Relic Oneに取り込むことで何がわかるかについても時期を見て書いていこうと思います。