New Relic Synthetics の API 外形監視の監視元ロケーションを東京と海外からのマルチロケーションにしてみた
前回、New Relic Synthetics で外形監視を試してみました。
その中で New Relic のTokyo, JPロケーションはAWS の ap-northeast-1（東京リージョン）であることを知りました。
New Relic から外形監視したい対象のサービス、システムで同じくAWS の ap-northeast-1を利用している場合、AWSの東京リージョン障害で監視が機能しないことも考えられます。
リージョン障害を見据えて New Relic Synthetics から他ロケーションからの監視設定を追加してみます。設定方法と、どのように表示されるのか紹介します。
ロケーション追加
New Relic Synthetics の基本的な設定方法は前回の記事を参考にしてください。New Relic Synsteices の Endpoint availability を利用しPOSTメソッドのリクエストを送り、レスポンス内容をチェックしてOK/NGの判定をしている構成をベースに進めます。
対象のモニターを選択します。
Generalを選択。
ロケーションの選択から、Tokyo, JP（東京）に加え、Singapre, SG（シンガポール）を追加。複数ロケーションから外形監視したいときでもチェックを入れるだけです。
Pingの様な死活監視ならまだわかりますが、モニタリングスクリプトを実行するのも設定はこれだけとは...非常に簡単です。
保存します。
マルチロケーションの追加はこれだけ設定完了です。
ロケーションの追加は地域の名前にチェックを入れ、削除するときはチェックを外すだけのお手軽設定でした。
観測
Summaryから確認するとロケーションが増えています。東京、シンガポール共にチェック成功しています。
応答速度を見比べてみます。並はありますがワーストケースで東京が260msに対して、シンガポールが808msとかなり開きがあります。日本国内のユーザー視点で応答時間を確認したいという場合は海外ロケーションだと厳しそうです。
日本国内での応答時間を把握しつつ、東京リージョン（AWSのap-northeast-1）障害に備えるには、東京（Tokyo, JP）と他のロケーションを1つ追加くらいが落とし所ではないでしょうか。
実行履歴を確認します。東京と、シンガポールが同時刻に実行されている履歴を確認できました。
実行履歴の詳細を比較
東京とシンガポールの詳細からLoad timeを見比べてみました。地理的な問題は避けられないですね。
- DNS名前解決時間（
DNS）に大きな差がある - TCPコネクション確立時間（
CONNECT）に大きな差がある
東京
シンガポール
クエリ
分析したいときは New Relicのクエリ言語であるNRQL（New Relic Query Language）か、PromQL（Prometheusのクエリ言語）で検索できます。
Events explorer から選択式でクエリを作ることができます。過去6時間分の東京と、シンガポールのDNS名前解決時間（DNS）のグラフと平均値です。ロケーション名はAWSのリージョン名で表示されています。
クエリビルダーを使えば自由に検索できます。ピンク枠のところにマウスを持っていくとEdit in query builderと表示されクリックして編集画面に入ります。
クエリの編集だけではなくChart typeから表にしたり、棒グラフにしたりビジュアルも変更できました。
ちなみに東京と、シンガポールの応答時間の平均値を表示していました。この形式ですとダッシュボードなどに利用できそうですね。
おわりに
現状日本国内からの応答時間を正確に確認したいなら New Relic Syntheticsは東京 + 1ロケーション構成がよいのではないでしょうか。死活監視目的ならとくにロケーションにこだわらなくてもよいかもしれませんけど、AWSの単一のリージョン障害で監視が止まることを考えたら2ロケーション選択しておいてもデメリットはあまりないかと思いました。
