LoginSignup
0
0

More than 1 year has passed since last update.

AWS障害時のNature Remo リモート APIの状況

Last updated at Posted at 2020-12-01

Nature Remoサーバ障害

先日、AWSのus-east-1リージョンの障害に伴い、Nature Remoを利用できない事象が発生しました。

参考リンク
【11/26 11:12更新】システム障害のお詫びと復旧のお知らせ
【11/26 10:15更新】11月25日からシステムの障害が発生しております

Remoが赤点滅になり、リモコン操作ができない状況になりましたが、Wifiルータ障害等とは状況が異なる動作をしておりました。サーバ障害時にAPIを動作させた場合どのような状況になっていたのか、またサーバ障害を早期に確認する方法があったのか、定期的に実行しているAPIの状況から振り返ってみます。

通常時のNature RemoのAPI利用状況

Nature Remo (初代) と Nature Remo mini を利用しています。
リモコンとして利用するだけでなく、センサーデータを1時間に1回の頻度で取得し、スプレッドシートに保管をしています。

センサーデータを 1時間に1回の頻度で取得する方法は、こちらの記事を参考にしています。
リビングの環境監視ダッシュボードを60分で作る方法(Nature Remo Cloud APIとGoogleサービス連携)

AWSの障害の前後での、このスプレッドシートへの記載状況から当時の状況を振り返ります。

AWSの障害発生中はセンサーデータを取得できていない

AWSの障害発生の前後の時間帯は、スプレッドシートへの書き込み失敗しています。
Remo自体の障害や、Wifiルータの障害であれば、APIは利用できるが、センサーの情報が古い情報のまま更新されていないという状況になります。
今回のようにサーバー側が原因でNature Remoが使えないという場合、書き込みができないということで状況の切り分けが可能と思われます。
サーバの障害が発生している可能性があることをメール等で通知すれば、原因の切り分け、把握がしやすくなりますし、慌てずに済みそうです。

障害前後の時間帯のセンサーデータの取得状況

スプレッドシートへの書き込みができていても、センサーのデータを更新できているもの、データを更新できていないものなどがあり、正しい情報を取得できない状態になっているものもありました。
温度や湿度等の具体的な数値は割愛しますが、時刻だけまとめると以下のようになっていました。

参考) スプレッドシートへの書き込み時刻と、センサーから取得した情報の更新時刻 (JSTに修正してあります)

スプレッドシート 書き込み時刻 Remo温度 取得時刻 Remo湿度 取得時刻 Remo照度 取得時刻 Remo人感 取得時刻 mini温度 取得時刻
11/25 20:53 11/25 19:13 11/25 20:04 11/25 9:10 11/25 20:53 11/25 15:28
11/25 21:53 11/25 19:13 11/25 20:04 11/25 9:10 11/25 21:47 11/25 15:28
11/26 4:53 11/25 19:13 11/25 20:04 11/25 9:10 11/25 22:56 11/25 21:57
11/26 6:53 11/25 19:13 11/25 20:04 11/26 5:40 11/25 22:56 11/25 21:57
11/26 7:53 11/26 7:33 11/26 7:20 11/26 5:40 11/26 7:45 11/25 21:57
11/26 8:53 11/26 8:19 11/26 8:35 11/26 5:40 11/26 8:51 11/25 21:57
11/26 9:53 11/26 8:19 11/26 9:34 11/26 5:40 11/26 9:53 11/25 21:57
11/26 10:53 11/26 10:51 11/26 10:33 11/26 5:40 11/26 10:53 11/25 21:57
11/26 11:53 11/26 10:51 11/26 10:33 11/26 5:40 11/26 11:42 11/25 21:57
11/26 12:53 11/26 12:27 11/26 12:50 11/26 5:40 11/26 12:54 11/25 21:57

状況を確認すると

  • 障害発生時間帯は、スプレッドシートへの書き込みが失敗している。4:53は書き込み成功 5:53は書き込み失敗となっているのは中途半端に回復したためか?
  • 障害の発生前から、温度、湿度、照度の情報が更新できていなかった。しかし、人感センサーの時刻は更新されている。
  • 照度の値は、障害回復後も正しく取得できていない。(上表には値は記載していませんが、朝5:40から夜まで、ずっと 124 という値で一定でした。通常時は、明るい場合は240以上、暗い場合は10未満の値であることが多く、124という数字が続くことは無いため、ここからも障害の可能性を検知できるかもしれません)
  • Nature Remo miniのデータ更新が復旧していない。(miniは、AWSのトラブルのあと赤点滅から自動復旧しなかったためと考えられます。)

余談ですが、Nature Remo miniの復旧にあたっては、電源ON/OFFでは回復せず、以下の手順を実施することで、復活させることができました。
ソフトバンク光BBユニットをお使いの方へ

考えられるサーバ障害検知方法

今回のようなサーバー側の障害を検知する方法として、結果から考えてみると以下のような方法が考えられます

  • APIの実行に失敗し、スプレッドシートへの書き込みができなかったことをメール等通知する
  • 照度センサーが 124 等の値で連続している

前者の方法であれば、比較的短期間に確認ができます。ただし通知方法にAWSのサービスを前提とした方式(AWS SNS等)としてしまうと、AWS障害時に通知ができない場合があるので、他の方法で通知するのが適切だと思います。
後者の方法は、障害が判明するまでに時間が掛かってしまうため、早期に障害を検知するという目的には適していません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0