フォーム読み込み中
この記事は、ソフトバンク Advent Calendar2022の22日目の記事です。
クラウドエンジニアリング本部の宮田銀河です。この記事では、”SNS投稿を使ってクラウド障害を検知する (ルールベース編) ”方法について紹介します。後日、このルールベース編の課題を解決する"AI編"も記事にする予定です。
まず先に、開発したシステムの概要図とSlack/メール通知例 (右) を下図に示します。
開発したシステムは、下記の通り動作をします。
Azure Functionsを定期的 (5分毎など) に実行
Azure FunctionsでSNSのAPIを呼び出し、SNSに投稿された情報を取得
取得した情報をAzure Blob Storageに保存
取得した情報が障害検知条件 (後述)を満たした場合、障害通知
本記事は、以下の順で説明します。
開発に至った経緯
障害検知するために非公式情報を使う理由
障害発生時のSNS投稿数・内容の調査
システムの開発
開発したシステムの課題
皆さんは、1年前の今日 (2021年12月22日) 何をしていましたか?私は”クリスマス直前のウキウキしてる人”になりたかった人です。実は1年前の今日、AWS (Amazon Web Services) のバージニア北部のEC2 (Amazon Elastic Compute Cloud) に障害が発生しました。この障害に関する複数のSNS投稿があり、影響の大きな障害であったことがわかります。2021年は、このクラウド障害以外にも複数回の障害が発生しました。
「SNSの投稿からこれらの障害を検知できるのではないか?」と単純に気になりました。これがきっかけで、SNSに投稿された障害情報を用いてクラウド障害を検知するシステムを開発しました。このシステムを改良したものを特許出願中です (別の記事で紹介する予定)。
クラウドの障害を知る方法は2つあります。公式情報を使う方法と非公式情報を使う方法です。それらの特徴を下記の表にまとめました。
特徴 | 公式情報を使う | 非公式情報を使う |
---|---|---|
情報源 | 各社の公式発表 | 不特定多数の投稿 |
信憑性 | 高 | 低 |
障害の詳細情報 (例) | 分かる (xxxのリージョンのyyyに障害が発生した等) | 分からない場合が多い (yyyが使えない等) |
情報の早さ | 早い | さらに早い場合あり (後述) |
公式情報を使うメリットは、信憑性の高いかつ詳細情報を得られることです。公式情報を使って障害を通知する例は、”AWS Health Dashboard の障害情報を Slack へ送信”を参照していただければと思います。
非公式情報を使うメリットは、情報が早いことです。例として、2021年9月2日にAWSのDirect Connectに障害が発生した時のTwitterの投稿状況を調査しました。累計の障害投稿数と投稿日時の関係を下記に示します。ここで、“障害投稿”=”障害用語を含む投稿”と定義します。障害用語は、”死、障害、落、使えない”などです。
AWSから9:39に公式の障害発生通知がありましたが、それよりも1時間以上早く投稿された障害投稿がありました。公式の障害通知があった時点で、約20個の障害投稿がありました。このことから、TwitterなどのSNS投稿を使えば、障害をいち早く検知することが可能だと考えられます。これが非公式情報を使って障害を検知しようと思った理由です
前節では公式情報よりも早く障害を検知できる可能性を示しました。この節では、障害発生前後において、SNS投稿数が変わるのか、どんな用語を含む投稿が増えているのかを説明します。例として、次は2021年12月9日にAWSで障害発生した時のTwitterの投稿状況を調査しました (Amazon Web ServicesをAWS、Google CloudはGC、MicrosoftのAzureをAzureと表示しています)。
GC、 Azureを含む投稿数に比べて、AWSを含む投稿数が急増していました。さらに、障害発生前後の投稿を比較すると、図の右に示す用語が増えていることがわかりました。
ここでWordCloudという技術を使い、出現頻度が高い用語を可視化しました (下図)。可視化している用語は、障害後の投稿に含まれる用語から、障害前の投稿にも含まれる用語を除いたものです。
障害、落ち、影響などネガティブな用語が大きく表示されていることがわかります。usやeastなどのリージョンに関係する用語も含まれていますね。
障害発生時の投稿の特徴がわかったので、その特徴からどのように障害を検知するかを説明します。今回は、クラウドの障害発生時の投稿データを分析して、以下の4つの条件のうち2つ以上の条件を満たす場合に障害と推定することにしました。1つだけだと誤検知が増え、3つ以上だと検知漏れが増えたためです。また、その条件を採用した理由を表にまとめました。
No | 条件 | 採用した理由 |
---|---|---|
1 | 15分連続で*障害投稿が増加傾向 | 障害時に投稿数が指数関数的に増えるため |
2 | 障害投稿数が基準値以上 | 障害時に障害投稿が増えるため (例: 「AWS落ちてる?」など) |
3 | クラウド用語を含む投稿数が基準値以上 | 障害時にクラウド用語を含む投稿が増えるため (例: 「AWS?」、「Azure?」など) |
4 | 障害/正常投稿が基準値以上 | 障害時に障害投稿の割合が増えるため |
前述の通り“障害投稿”=”障害用語を含む投稿”です。障害用語は、”死、障害、落、使えない”などです。
システムのフローチャートは、画像の通りです。”SNS投稿をGET”する処理は定期的に実行します。メール通知を気軽に実装するためにAmazonのSNSを使用しました。Slackへの通知は、「Azure利用料金をSlackに通知する」を参照いただければと思います。
障害時の投稿データをシミュレートして開発したシステムの評価をしました。その評価と気付いた課題について説明します。
下記の表は、2021年12月に発生した障害に関して、開発したシステムが”公式の障害情報と比較して、何分早く検知できたか”を示しています。公式の障害情報は、AWSならAWS Health Dashboard、AzureならStatusのRSSを参考にしています。
障害の概要 | 公式障害情報の通知時間(日本時間) | 本システムの検知時間(日本時間) | 公式障害情報と比較して、何分早く検知できたか |
---|---|---|---|
[AWS] EC2の接続エラー (12月8日) | 0:56 | 0:30 | 26分 |
[Azure] AD / O365接続エラー (12月16日) | 11:28 | 11:00 | 28分 |
[AWS] SSOの接続エラー (12月23日) | 10:56 | 9:30 | 86分 |
表に示した障害に関して、公式情報よりも早く検知することができました。
開発したシステムを使うことで、公式情報よりも早く障害を検知できました。しかし障害が発生していないのにも関わらず、障害発生していると誤検知することが複数回ありました。この原因を説明します。AzureやAWSの障害の復旧後に障害投稿が増える傾向があります。この投稿には、ニュースアカウントによる障害を解説した投稿やそれを見た人の投稿が含まれます。これらの投稿の影響を受けたことが原因の1つに挙げられます。これは、システムの適合率が悪くなることを意味します。その他にも以下のような課題がありました。
現時点で上記課題はAIの導入により解決済みです。後に"AI編"として記事にする予定です。
SNS情報を使ってクラウドの障害を検知する方法を紹介しました。まず障害発生時のSNS投稿を分析し、その分析結果を踏まえて実際に障害検知システムを開発しました。実際に開発したシステムの評価結果は、公式情報よりも早く障害の検知が可能であることを示唆しています。SNS情報を使って、クラウドの障害を検知したい方の参考になれば幸いです。
では、ソフトバンク Advent Calendar 2022 の 23日目の辻さんにバトンを渡します。辻さんの紹介をすると、辻さんは私が新卒入社して1年間、私の指導係でした。今の私があるのは、間違いなく辻さんのおかげです。きっと素晴らしい記事を書いているはずです (露骨なゴマすり)
この記事を読んで興味を持っていただいた学生・エンジニアの方は、ぜひ当社の採用に応募して頂けると嬉しいです。
常に進化し続けるソフトバンクを楽しみながら
そんな一人一人の挑戦が会社の未来を創ります
条件に該当するページがございません