SNS投稿を使ってクラウド障害を検知してみた

2023年3月16日に開催された「SoftBank Tech Night Fes 2023」の講演資料です。

近年、大規模な通信障害やクラウド障害が複数回発生しています。クラウドインテグレータはこのような障害情報を素早く検知・対応して、顧客満足度を下げないことが重要です。
本セッションでは、クラウドに関する障害を素早く検知する方法を検討し、実装した成果を発表します。
まず、障害発生時のSNS投稿を分析して、どのような傾向があるかを説明します。その後、開発したクラウド障害検知システムを説明します。最後に、AIを使いSNS投稿の障害らしさを判別する方法を説明します。

■関連リンク
・SNS投稿を使ってクラウド障害を検知してみた (ルールベース編)
https://www.softbank.jp/biz/blog/cloud-technology/articles/202212/detect-cloud-outage-using-sns/

・Azure, Google Cloud, AWSのリソースタグの制約を比較して、共通タグルールを作成した
https://www.softbank.jp/biz/blog/cloud-technology/articles/202207/resource-tag/

■作成者
宮田 銀河（みやた ぎんが）
ソフトバンク株式会社
法人事業統括 クラウドエンジニアリング本部
DevOpsエンジニア

■SoftBank Tech Nightについて
ソフトバンク株式会社のエンジニア有志が開催するテックイベントです。
各分野のエキスパートが、日頃培った技術や事例、知見について発信しています。
イベントは開催スケジュールはconnpassをご確認ください。
https://sbtechnight.connpass.com/

SoftBank Tech Night Fes 2023公式サイト
https://www.softbank.jp/biz/events/tech-night-fes-2023/

Transcript

1. SNS投稿を使って クラウド障害を検知してみた クラウド・DevOpsエンジニア 宮田 銀河 SoftBank Tech Night Fes 2023 2023年 3月 16日 資料の置き場
2. 一瞬の自己紹介 • 名前: 宮田 銀河 (みやた ぎんが) • 経歴: 機械系大学院 → 新卒２年目 • 特技: 資格勉強 2/66
3. 合格した資格は、20個 基本 情報 応用 情報 情報処理安全確保 支援士 (登録予定) データベース ス ペシャリスト IPA（情報処理推進機構） パブリッククラウド AWS全冠 3/66
4. 今日の話 情報処理安全確保 支援士 (登録予定) データベース ス ペシャリスト 基本 情報 応用 情報 クラウドの障害を検知する話 AWS全冠 自己研鑽の時間をフル活用して、やってみた。 IPA（情報処理推進機構） パブリッククラウド 4/66
5. 20分後に知ってほしい3つのこと 1. クラウド障害を早く知るには、SNSの確認が有効 2. SNS投稿を使い、障害検知するAIを作成可能 3. しかし高精度AIの作成は大変。再学習を自動化しよう 5/66
6. SNS投稿を使ったクラウド障害検知とは？ クラウド障害を素早く検知する クラウドの障害に関する SNS投稿 Azure障害でビルドすら開始できない・・・ XXXX/4/16 9:30 AM Azure障害起きているのか。範囲広そうだな XXXX/4/16 9:31 AM Azure障害...勘弁してくれ XXXX/4/16 9:32 AM SNS投稿の具体例 6/66
7. そもそも障害って何？ 障害発生日 キャリア 障害の規模 2022/07/02 KDDI 約3091万人に影響、 復旧まで61時間 2021/10/14 NTTドコモ 約1290万に影響、 復旧まで29時間 “提供サービスが使えなくなる or 使いづらくなる”と定義 身近な例: この1,2年で発生したキャリア障害 https://news.yahoo.co.jp/articles/8d04bdbf9e585e04b63a34df1bcf509bf6983aba 7/66
8. 近年のクラウド障害 →年に数回ほど 大規模な障害が発生している 障害発生日 クラウド 障害の概要 2023/01/25 ポータル画面が表示されない 2022/05/27 Route53のDNS解決が失敗する 2021/12/16 API接続できない この1,2年で発生したクラウド障害の例 8/66
9. なんで クラウドの障害を検知したいの？
10. 障害を検知できると、何が嬉しい？ push 開発者 別の作業 deploy 障害発生中か 💡 仕方ない、 別作業しよう push 開発者 deploy あれpushできないぞ？ NWに問題？ 検知できていないと... 検知できていると デプロイできない... 自分のコードが 間違っている？ 時間を節約できる →今の作業をすぐ諦めて、別の作業ができる 自分に問題はないのに、トラシューすることに ... 10/66
11. どうやって障害を検知するのか？ 大きく、２つの方法がある 公式情報を使う 非公式情報を使う 11/66
12. 公式情報を使う ←この記事で解説 公式情報を使う 非公式情報を使う 12/66
13. 公式情報の通知が ない or 遅い場合もある。 →検知が遅れる 公式情報を使うデメリット 障害発生 数分〜OO時間 公式の障害情報通知 (例: Azure 2021年9月に発生したVMの障害は、数時間後に通知があった) 13/66
14. 非公式情報を使う ↑今回の話はこれ 公式情報を使う 非公式情報を使う (SNSの情報) 14/66
15. SNS投稿の分析 1.投稿数 2.投稿ワード 3.投稿時間 障害検知を したい理由 検知方法の 確立・評価 発生した課題 解決方法 OOを使う SNS投稿の分析
16. まず、SNSの状況を調べてみる 「公式情報より早く、障害検知って可能なのか？」 私 「とりあえず、障害発生時のSNS投稿を分析しよう！」 →某SNSを見に行く 16/66
17. 障害発生時の SNSの様子を見てみる SNSアイコン 17/66
18. 障害発生時のSNSの様子 障害に関するSNS投稿が確認できる。 →障害前後で投稿数にも変化あるかも？ →調べてみる。 Azure障害でビルドすら開始できない・・・ XXXX/3/16 9:30 AM Azure障害起きているのか。範囲広そうだな XXXX/3/16 9:31 AM Azure障害...勘弁してくれ XXXX/3/16 9:32 AM Azure障害起きてんな。 XXXX/3/16 9:33 AM Azureポータルにつながらない XXXX/3/16 9:33 AM 障害発生時のSNS投稿の例 18/66
19. 1. 障害発生時に SNS投稿数は増える？ 19/66
20. 1.障害発生時の投稿数の推移 Azureを含むSNS投稿数 日時 投 稿 数 ー ”Azure”を含む投稿数 障害発生時に Azureを含む投稿数が急増している (約5倍に増えている) 20/66
21. 2.どんな障害投稿が 増える? 21/66
22. • 障害
 • 落ち
 • 使えない
 • …
 2.障害前後で増えた投稿のワード 以下ワードを含む投稿が増加 障害発生 SNS投稿数 投 稿 数 日時 -方法- • 障害前後の投稿をわかち書き (≒形態素解析)し • 障害前にも投稿されているワードを除く (に,を 等) 22/66
23. 2.障害前後で増えたワードの可視化 *Wordcloudによる障害前後に増えた投稿の可視化 *Wordcloud: 単語の出現率に応じて、その単語を大きく表示 する方法。 “障害”、”コンソール”、”W”、”落ち”、”でき” などのワードが目立つ。 クラウド固有の情報も見つかる (“azure”、”リージョン”) 23/66
24. 3. SNS投稿 と 公式の障害通知 どっちが早い? 24/66
25. 3.SNS投稿 と 公式の障害通知 どっちが早いか SNS投稿が公式の障害通知よりも 1時間20分早い (他の障害もその傾向あり) 累 計 投 稿 数 SNS投稿日時 [2021年9月2日のAWS障害] SNS投稿日時 vs 公式の障害発生通知 1時間20分の差 朝からAWS障害 8:17 AM AWSの調子が悪い 9:25 AM 25/66
26. SNS投稿を使えば いち早く障害検知できそう! -SNS投稿の分析結果- 1.投稿数 → 増える (5倍になる場合も) 2.投稿ワード → 障害ワードが増える 3.投稿時間 → 公式よりもSNS投稿の方が早い 26/66
27. 障害検知を したい理由 SNS投稿の分析 1.投稿数 2.投稿ワード 3.投稿時間 検知方法の 確立・評価 発生した課題 解決方法 OOを使う 障害検知方法の確立・評価
28. Azure? 大丈夫？ XX:XX AM Azure… XX:XX AM Azure障害...勘弁してくれ XX:XX AM Azure障害起きている。 XX:XX AM 過去の障害発生前後の投稿数を可視化 SNSの投稿数 投 稿 数 日時 障害発生時には、↓以下条件を満たす可能性が高い ー”Azure”を含む投稿数 が基準値Bを超える ー障害ワードを含む投稿数 が基準値Cを超える 28/66
29. ↓以下の条件を満たした場合、障害発生と判定 A. 20分連続で障害投稿数が増加の傾向 B. Azureを含む投稿数 ≧ 基準値B C. 障害ワードを含む投稿数 ≧ 基準値C 過去の障害を検知できるか調査した (以降は、開発した検知ツールを”本ツール”と表現) どんな条件で障害を判別するか？ SNS投稿数 投 稿 数 日時 29/66
30. 障害発生日 クラウド 障害の概要 公式情報との検知時間の差 2023/01/25 ポータル画面が表示されない 20分早い 2022/05/27 Route53のDNS解決が失敗する 60分早い 2021/12/16 API接続できない 30分早い 本ツール vs 公式障害情報の検知時間 +α 検知精度は90%超 しかし、、、課題もある 30/66
31. 障害検知を したい理由 SNS投稿の分析 1.投稿数 2.投稿ワード 3.投稿時間 検知方法の 確立・評価 発生した課題 解決方法 OOを使う 障害検知方法の確立・評価
32. 現時点の検知時間 本ツールの2つの課題 1. *偽陽性の割合が高い 2. 障害発生→検知まで長い場合がある (公式情報より早いが・・・) 公式情報 投 稿 数 障害発生からの経過時間 (分) Azure障害？ XXXX/X/X 9:05 AM Azure落ちてる！ XXXX/X/XX 9:30 AM 12回“障害”と予想→4回は間違い (=33%) *障害発生してないが ”障害”と判定 32/66
33. より早く検知しつつ 検知精度を95%以上にしたい 33/66
34. どうやって早く検知するか？ 早く検知するために、基準値を下げる？ 投 稿 数 障害投稿数の検知基準 時間 ー ”Azure”を含む投稿数 基準を下げる 今の障害検知の時間 34/66
35. 基準値を下げると 35/66
36. 基準値を下げると検知は早くなるが、、、 少し早く検知できるが、誤 検知が増える 投 稿 数 新規の検知基準 時間 障害投稿数の検知基準 ー ”Azure”を含む投稿数 36/66
37. *現状の仕組みでは、 精度と検知時間が比例する 精 度 検知時間 精度を上げる→検知遅い 早く検知する→精度が落ちる *現状 の仕組み: 障害ワードを含む投稿数が基準値を超える 37/66
38. どうしよう・・・ 38/66
39. 何もわからないけど、 AI使おう AI 39/66
40. 障害検知を したい理由 SNS投稿の 分析 検知方法の 確立・評価 発生した課題 解決方法 AIを使う AIを使う
41. 障害検知を したい理由 SNS投稿の 分析 検知方法の 確立・評価 発生した課題 解決方法 AIを使う AIを使う AIの使い道 AI検知方法の 確立・評価 発生した課題 解決方法 OOの導入 AIの使い道 AIの学習/評価
42. SNS投稿の障害らしさをAIで識別する AIをどう使うの？ 現時点の検知時間 公式情報 Azure障害？ XXXX/X/X 9:05 AM Azure落ちてる！ XXXX/X/XX 9:30 AM 理想の検知 42/66 累 計 投 稿 数 障害発生からの経過時間 (分)
43. • (精度向上) 障害らしい投稿だけを取得する • (速度向上) 障害らしい投稿が複数ある場合→障害検知 改善方針: 障害らしさを判別するためにAIを使う 障害らしさ 0% 障害らしさ 100% ↓AIの出力イメージ (SNS投稿の障害らしさを判別) クラウドの障害に関する SNS投稿 Azure資格に落ちた...普段使わないから... XXXX/X/XX O:OO AM やべえAzure更新試験に落ちた。 XXXX/X/XX O:OO AM Azure資格、あと10点足りずに落ちた XXXX/X/XX O:OO AM クラウドの障害に関する SNS投稿 Azureどこかのサービス落ちてるっぽい？ XXXX/X/XX O:OO AM Azure落ちてる XXXX/X/XX O:OO AM つまり、Azureのリージョンが落ちてる？ XXXX/X/XX O:OO AM 43/66
44. 障害検知を したい理由 SNS投稿の分析 1.投稿数 2.投稿ワード 3.投稿時間 検知方法の 確立・評価 発生した課題 解決方法 AIを使う AIの学習/評価 AIの使い道 AI検知方法の 確立・評価 発生した課題 解決方法 OOの導入 AIの使い道 AIの学習/評価
45. AIモデルの学習方法 AWS/Azure障害時の投稿
 (ex. aws落ちてない？)
 ×400投稿
 AWS/Azure正常時の投稿
 (ex. aws資格落ちた) 
 ×400投稿
 前処理 ライブラリ: fastText (facebookが2016公開) 前処理: 正規化→Mecab→”AWS・Azure”を”クラウド”に replaceする –-例--- ・「awsに障害発生しているかも」 →「”クラウド” “に” “障害” “発生” “して” “いる” “かも”」 ・「azureに障害発生しているかも」 →「”クラウド” “に” “障害” “発生” “して” “いる” “かも”」 45/66
46. AIモデルの学習結果 AWS/Azure障害時の投稿
 (ex. aws落ちてない？)
 ×400投稿
 AWS/Azure正常時の投稿
 (ex. aws資格落ちた) 
 ×400投稿
 前処理 ライブラリ: fastText (facebookが2016公開) 約88%の正答率
 (評価データは学習に使ってない投稿 x 200投稿) 46/66
47. AIを使用した障害検知の方法 A. 20分連続で障害投稿数増加傾向 B. 平均障害投稿数が基準値(3投稿/10分)以上 C. 平均投稿数が基準値(50投稿/10分)以上 D. 30分以内で障害と判定した投稿数が2以上 Dの時に障害発生と判定する →この条件でシミュレーションを実施 47/66
48. AIを使用して検知が早くなった🤗 障害検知時間の比較 (公式 vs AI使用する/しない) 日時 障害の概要 公式情報 vs AIを使用する 公式情報 vs AIを使用しない 10/13 VM起動できない 135分以上早い 75分以上早い 12/08 EC2接続エラー 38分早い 28分早い 12/23 SSO接続エラー 96分早い 86分早い 48/66
49. 障害検知回数と精度評価 AIを使用して検知精度は90→98%になった🤗 めでたし、めでたし... 49/66
50. が、、、
 実際のAI障害検知は甘くない
 50/66
51. 障害推定の可能性 当たってなくない？ [障害投稿の可能性: 100%] AWSが落ちているのか... XXXX/X/XX O:OO AM [障害投稿の可能性: 85%] AWS障害で業務が怠っている XXXX/X/XX O:OO AM [障害投稿の可能性: 100%] AWS障害かな... (^^;) XXXX/X/XX O:OO AM [障害投稿の可能性: 0%] 色んなサービスが落ちているぽいし、 AWSの不具合か XXXX/X/XX O:OO AM [障害投稿の可能性: 45%] AWSが落ちた時には、それを補うサービスが必要 XXXX/X/XX O:OO AM [障害投稿の可能性: 26%] 【速報】AWSなど複数のウェブサービスで障害発生中 XXXX/X/XX O:OO AM ↓ここ最近の、AIを使った場合の推定結果 51/66
52. 過学習？データが足りない？ いずれにせよ、 モデルの修正が必要！ 52/66
53. AIモデルを修正するために 手元で”再学習させる辛さ”... 再学習に必要なこと
 1. エディタを起動して
 2. データをダウンロードして
 3. そのデータにラベルを正しく付与して
 4. 前処理 (正規化→分かち書き→replace)して
 5. 学習と評価データに分割して
 6. 再学習 (←ここで、やっと再学習できる)
 7. モデル性能を比較して、モデルの更新
 53/66
54. DevOpsエンジニアとして AIモデルの更新まで 自動化したい (MLOps) 54/66
55. MLOpsとは DevOpsの概念に以下が加わる ・機械学習モデルの自動的な開発 ・機械学習モデルの自動的な性能テスト・更新 DevOps ML MLOps 55/66
56. 障害検知を したい理由 SNS投稿の 分析 検知方法の 確立・評価 発生した課題 解決方法 AIを使う MLOpsの導入 AIの使い道 AI検知方法の 確立・評価 発生した課題 解決方法 MLOpsの導入 AIの使い道 AIの学習/評価
57. 現システムの構成 1. Azure Functionを定期実行 システム AIモデル 投稿情報保存 3. 障害ロジックを使い検知 2. SNS投稿の取得 Azure資格に落ちた...普段使わないから... XXXX/X/XX O:OO AM やべえAzure更新試験に落ちた。 XXXX/X/XX O:OO AM Azure資格、あと10点足りずに落ちた XXXX/X/XX O:OO AM クラウドの障害に関する SNS投稿 SNS 57/66
58. 僕のかんがえたさいきょうの MLOps構成 58/66
59. (理想) システムの構成 MLOps システム AIモデル 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 もし差分があれば、 再学習のジョブをキックする 投稿情報保存 (学習用データ) 差分確認 AIの学習サービス (AWS, GCP, Azure) AIモデル更新 59/66
60. システム AIモデル 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 もし差分があれば、 再学習のジョブをキックする 差分確認 AIの学習サービス (AWS, GCP, Azure) AIモデル更新 投稿情報保存 (学習用データ) 投稿情報をgoogleにエクスポート 60/66
61. システム AIモデル もし差分があれば、 再学習のジョブをキックする 投稿情報保存 (学習用データ) 差分確認 AIの学習サービス (AWS, GCP, Azure) AIモデル更新 投稿情報を見て ラベルを付与する人 障害投稿なら ラベルを付与 投稿に正解ラベルを付与 61/66
62. システム AIモデル 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 AIモデル更新 もし差分があれば、 再学習のジョブをキックする 差分確認 投稿情報保存 (学習用データ) 学習データに差分があれば、再学習を実行 AIの学習サービス (AWS, GCP, Azure) 62/66
63. もし差分があれば、 再学習のジョブをキックする 差分確認 システム 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 投稿情報保存 (学習用データ) AIの学習サービス (AWS, GCP, Azure) AIモデル更新 AIモデル 再学習した結果がよければ、AIモデル更新 63/66
64. システム AIモデル もし差分があれば、 再学習のジョブをキックする 投稿情報保存 (学習用データ) 差分確認 AIの学習サービス (AWS, GCP, Azure) AIモデル更新 投稿情報を見て ラベルを付与する人 障害投稿なら ラベルを付与 手作業はここだけ。圧倒的に楽 64/66
65. もし差分があれば、 再学習のジョブをキックする 差分確認 システム 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 投稿情報保存 (学習用データ) AIの学習サービス (AWS, GCP, Azure) AIモデル更新 AIモデル 高精度AIを作るのは大変 再学習を自動化をしよう 65/66
66. もし差分があれば、 再学習のジョブをキックする 差分確認 システム 障害投稿なら ラベルを付与 投稿情報を見て ラベルを付与する人 投稿情報保存 (学習用データ) AIの学習サービス (AWS, GCP, Azure) AIモデル更新 AIモデル SNS投稿から障害を検知して、時 間を節約しよう！ (終) 66/66