米マイクロソフトは2022年2月8日午前、オンライン会議アプリ「Teams(チームズ)」で障害が発生していると発表した。
マイクロソフトによると、8日午前8時半ごろから、日本を含むアジア太平洋地域で、利用者がオンライン会議に参加できない不具合が起きている。
マイクロソフトは「利用者が会議に参加できない問題が起きていることが分かった。影響を軽減するために取り組んでいる」とコメントしている。
雑記系ブログ。セキュリティとか、マイルとか、投資とか、、、 / Miscellaneous Blogs. Security, miles, investments, etc
米マイクロソフトは2022年2月8日午前、オンライン会議アプリ「Teams(チームズ)」で障害が発生していると発表した。
マイクロソフトによると、8日午前8時半ごろから、日本を含むアジア太平洋地域で、利用者がオンライン会議に参加できない不具合が起きている。
マイクロソフトは「利用者が会議に参加できない問題が起きていることが分かった。影響を軽減するために取り組んでいる」とコメントしている。
弊社では、影響を受けたシステムのごく一部の再起動に成功し、サービスが復旧するかを確認しています。監視を続けながら、根本的な原因の把握に努め、他の潜在的な緩和経路を開発する予定です。
マイクロソフトのコラボレーション環境「Teams」に障害が発生し、不特定多数の人がビデオ/オーディオ会議の機会や、ドキュメントにアクセスする機会を失いました。
Microsoftは、2022年7月21日01:47(UTC)にこの問題を認め、対応に着手しました。
当初は小規模なMicrosoft Teamsの障害でしたが、Exchange Online、Windows 365、Office Onlineなど、Teamsを統合した複数のMicrosoft 365サービスにも障害が発生しています。
接続障害を引き起こした問題は、内部ストレージサービスへの接続が壊れていることを特徴とする最近のデプロイメントであると発表しました。
しかし、Teamsだけでなく、Microsoft 365のさまざまなサービスに接続できないとの報告がユーザーから寄せられ、障害の影響を受けています。
マイクロソフトは、この問題を確認し、その後のMicrosoft 365の停止は、Teamsの統合されたサービスのみに影響したと述べています。
「Microsoft Word、Office Online、SharePoint Onlineなど、Teamsを統合した複数のMicrosoft 365サービスへの影響を確認しています。」とマイクロソフトは説明しています。
同社がMicrosoft 365 Serviceのヘルスステータスページでさらに詳しく説明しているように、影響を受けたユーザーは、以下のサービスのいずれか、または複数に問題が発生したとのことです。
トラフィックを正常なサービスにリダイレクトして影響を軽減した後、遠隔測定によりMicrosoft Teamsの機能が回復し始めたと述べています。
出典:Microsoft Teams outage also takes down Microsoft 365 services
出典:Microsoft Teams outage widens to take out M365 services, admin center
Have I Been Pwned(HIBP)はクラウドファーストのサービスとして構築され、Azure Table Storageのような最新のクラウドパラダイムを活用して、以前は達成できなかったようなレベルのパフォーマンスでコストを大幅に削減することができました。これは小さなお金で大きな成功の実現ですが、今日はその正反対、クラウド・コストに負けた話について書きます。
それは、2021年12月のAzureの請求書が、通常よりはるかに高額だったことから始まりました。問題を発見するのに少し時間がかかりました。
その請求書は2022年1月10日に届きましたが、武漢ウイルスの影響で、請求書を見るまでにさらに10日ほどかかってしまいました。
私が最初に見るのはAzureのコスト分析で、上記のような項目を使用しているすべての個別サービスに分解しています。HIBPは、ウェブサイト、関係データベース、サーバーレス「Functions」、ストレージなど、多くの異なるコンポーネントで構成されています。すぐに、あるサービスがトップに浮き上がりました。
最初の項目が、すべてのサービスにおける帯域幅コストの98%を占めています。すべての HIBP サービスだけでなく、Hack Yourself First から Why No HTTPS まで、Azure で実行しているすべてのサービスです。ここで話しているのは、Microsoft の Azure インフラストラクチャから送信されるデータの帯域幅(GB あたり 0.1205 豪ドル)であり、通常は Web サイトへのトラフィックなどです。しかし、これはストレージアカウントです。まず、使用量が急増し始めた時期から見てみましょう。
2021年12月20日。NCAから提供された何億もの新しいパスワードとともに、FBIのためのPwned Passwordsインジェスト・パイプラインが開始されたのです。オープンソースのコードベースが初めて製品としてリリースされたのでしょうか。それとも他に何か?私は、帯域幅の使用状況をより細かく調べることから始め、さらに深く掘り下げていく必要がありました。
一貫して、それぞれのスパイクは17.3GBでした。完全に直線的な分布ではありませんが、かなり規則的なスパイクです。Pwned Passwordsのダウンロード可能なハッシュです。しかし、これらは常にCloudflareのエッジノードにキャッシュされます。そのため、私は無料でサービスを提供することができ、オリジンサービスからの帯域幅を無視できるように、そこの人々と多くの仕事をしました。実際、それが問題だったのでしょうか?ストレージアカウントで診断を有効にして、個々のリクエストのレベルまで、もう一度深く掘り下げてみましょう。
さて、そこで問題です。これらのリクエストは定期的にログに現れ、17.3GB分のコストが発生していたのです。このIPアドレスはCloudflareのもので、トラフィックは間違いなく彼らのインフラを経由しており、したがってキャッシュされるはずでした。Cloudflareのダッシュボードが何を言っているのか見てみましょう。
Cloudflareがキャッシュすべきものをキャッシュしていないという症状は明らかでしたが、根本的な原因は明らかではありませんでした。私はすべての設定、例えば「downloads」サブドメインのキャッシュポリシーを定義するページルールを調べ直しました。
そして、その結果、両方のSHA-1アーカイブが15GBを超えていました。根本的な原因がはっきりしたので、Cloudflareのルールを微調整してみました。
HIBPのウェブサイトから直接ダウンロードできるリンクを削除し、シードがたくさんあるtorrentだけを残したので、データを入手するのはまだ簡単でした。その後、Cloudflareが15GBの上限を上げたので、torrentをダウンロードできる環境にない人たちのためにリンクを復活させました。危機は去りました。
それで、被害総額はどうなったのでしょうか?
その期間の通常の使用量に加え、11,000AUD以上の費用がかかっています。痛っ! 他の地域の人たちからすると、約8,000USD、約6,000GBP、約7,000EUR、約840,000JPYに相当します。これは、1日あたり約350豪ドルが、1カ月間かかったことになる。本当に痛かったし、起こってはならないことだった。もっと早く気づいて、このようなことが起こらないような安全策をとっておくべきだったのです。
まず、Azureの帯域幅が高価であることは常に認識し、特に最も多くのデータを扱うストレージアカウントについて、もっとよく監視するべきです。この記事の最初のグラフを見ると、トラフィックが異常になる前では、帯域幅は1日に50GBを超えることはありませんでした。この閾値を超えたときに、ストレージアカウントにアラートを設定しましょう。
出典:How I Got Pwned by My Cloud Costs
【クラウド設定で恐ろしい課金額が発生した他の記事】