クラウド時代の防疫体制

私の此方の書き込みでも紹介させていただきましたが、

「家電にも影響が…」SHARPのマスク販売でサイトがサーバーダウン→SHARPのIoT家電まで不具合が発生

というわけで、

　・マスク購入受付サーバーがアクセス過剰でサーバが落ちた
　・シャープ製IoT製品が使用できなくなった
　・IoT製品が参照するサーバーとマスク購入受付サーバーが同一？
　　それが道連れで落ちてIoT製品も使えなくなったらしい

その様な次第で、この際は同一サーバーで受付をしたことから一方の障害が別のサービスを道連れにして落としたという事らしい。

マスク販売サイトへの集中でシャープのIoT家電がダウン--原因を広報に聞いた

なお、うっかりサーバーが落ちた、と書きましたが、正しくはサーバーそのものの問題ではなく、ファイアウォールにてアクセス数を制限していて、あっさりそれを超えるアクセスがあったのが直接の原因とのことです。このため応答が遅延したり無かったり503が返ったりで、IoT機器をコントロールするスマホのアプリの動作が重かったり固まったりエラー表示したり、ということらしい。

序でに言うと、マスク購買受付サイトに入るにはSHARPのユーザーサービスに登録したメンバーズID(COCORO ID)が必要で、これはスマホのアプリでも共通に使用するものだったので、同じIDでスマホからIoT機器を使用すると同時に購買受付サイトに入ろうとすると、そこでサーバーの応答が滞るというものらしい。要するに紐づいていると駄目、ということですね。

こうしてみますと、タイトルには「防疫」と書きましたが要するに、うっかり追加のサービスを既存のサービスに追加したところ、追加サービスで過剰なアクセスがあったため道連れで本来のサービスに支障を来たした、という典型的なお話ですね。


で、このサービスはAWS Lambda上に構築されているものの様で、対応としては、入り口を分ける、具体的には別のインスタンスなりを立てて、そこに今回の新規サービスを立てる、というところでしょう....と書くと知人にこっぴどく叱られます。現用サービスの追加の形でとにかくこなせ、新しいサーバーを構築する工費なんてかけられるか、馬鹿め、と。

むぅ、そうしますと、ファイヤウォールの制限をもっと広げて、これに対応するためにインスタンスごとマルっと高性能サーバーに持っていって回線容量も増やして、という事になるのかな。まぁ、その辺りはAWSのコンソールWebページからチョイチョイ....(391STEP位?)....チョイですから、本当にCPUを挿し換えたり回線を繋ぎ替えたりはしませんけどね。とはいえ、それは勿論現用サーバー運用担当者の業務範疇に押し込められるもので、そうしますと担当はサビ残三昧。序でに、なんでも購買受付処理が正しくできたかどうか不明だ、なんだそうで、これからログとレコードを突き合わせてレコード内容を正しく修正して行かねばならない。これを3000件、人力で？明日朝までに？

....どうしろと。

まぁ、こうゆう時うちで有りがちなのは本来の担当が雲隠れして私の様な部外者が駆り出されてサーバー室、じゃない今回は事務所に缶詰になるところでしょう。んで、翌朝定時をとっくに過ぎたころにやってきた本来担当が朗らかな笑顔で「できた？」と問うてくるのを虚ろな目で眺めるの。

こんなことが今頃現地で起こってやしないでしょうね。