au通信障害、復旧を遅らせた「輻輳」って何？ 過去にはドコモも
7月2日に発生し、現在も完全復旧には至っていないKDDIの大規模通信障害だが、多方面に影響を与えたことでも大きな注目を集めている。その原因は音声通話処理に関する部分で「輻輳」（ふくそう）が発生したためだというが、そもそも輻輳とはどのようなもので、なぜそれが通信障害を起こすほど甚大な影響を与えてしまうのだろうか。 甚大な影響を与えたKDDIの通信障害、その原因は 大規模通信障害は「au」「UQ mobile」「povo」など、KDDIが提供するモバイル通信の利用者のほぼ全てに影響しただけでなく、KDDIのモバイル回線を利用している楽天モバイルやMVNO、さらにはKDDI回線を利用する多くの企業のサービスにも影響を与えることとなった。 実際この通信障害により、KDDI回線を利用していた銀行の店舗外ATMが使えなくなったり、宅配便サービスの配送情報が更新されなくなったり、気象観測点の一部データが
KDDI“過去最大”の通信障害、発生の経緯は？ 緊急会見で判明したこと
何が起きたのか 7月2日の午前1時35分頃から、全国の携帯電話ユーザーがau網での音声通話やSMS、モバイル通信サービスを利用しづらい状況が発生した。また、一部のIoT機器で通信しづらくなる状況となった。 通信状況はデータ通信を中心に復旧が進んでおり、ユーザーごとに徐々に利用できる状況に回復している。西日本エリアでは富山県、長野県、静岡県以西の西日本エリアでは、音声通話の復旧作業についても3日11時ごろに完了している。ただし、ネットワーク試験などを実施するため、発着信やデータ通信の総量を制御する“流量制御”を行っており、しばらく利用しづらい状況が続いている見通し。 東日本エリアでは17時30分に復旧作業が終了した。 通信障害の影響は、端末やOS（プラットフォーム）によっても異なる。音声通話は利用できないか、利用しづらい状況が3日17時の時点でも続いている。スマートフォンなど音声回線を利用す
KDDIの通信障害についてまとめてみた - piyolog
2022年7月2日、設備障害によりKDDIの携帯電話サービスで障害が発生しました。ここでは通信障害に関連する情報をまとめます。 通信障害発生から復旧発表まで3日以上 au携帯電話サービスがご利用しづらい状況について 障害発生同日8時以降から1時間おきに障害報告が公表されていた。 障害発生・復旧の状況は以下の通り。 対象地域 障害発生日時 復旧作業終了時間 復旧完了日時 西日本 2022年7月2日 1時35分頃 2022年7月3日 11時頃 2022年7月5日15時36分 東日本 2022年7月2日 1時35分頃 2022年7月3日 17時30分頃 2022年7月5日15時36分 影響を受けたのは全国の個人・法人向けのau携帯電話、UQ mobile携帯電話、povo、au回線利用事業者の音声通信、ホームプラス電話、ホーム電話、auフェムトセル、SMS送受信。7月3日11時時点の概算では約3
2022年6月21日に発生したCloudflareの大規模障害の原因 - Qiita
概要 今回は、2022年6月21日に発生したCloudflareの大規模障害についての原因がまとめられた記事が公開されたため、その内容について翻訳およびサマライズしていきます。 何が起こったのか 2022年6月21日にCloudflareの19のデータセンターのトラフィックに影響を与える障害が発生したようです。 また、この19のデータセンターはどうやら世界中のトラフィックのかなりの割合を扱う拠点だったようです。 ではなぜ、大規模な障害が発生したのかというと、原因はどうやらこれらの重要な拠点の耐障害性を向上させるための変更(ネットワーク設定の変更)を行なったことが起因しているようです。 なので、今回の障害では悪意のある攻撃等ではなかったことになります。 障害が発生した時刻と復旧した時刻 障害が発生した時刻は、2022年06月22日 15:58ごろに発生し、2022年06月22日 16:42ご
2022年4月に発生したアトラシアンのサービス停止に関するインシデント事後レビュー | Atlassian Japan 公式ブログ | アトラシアン株式会社
本ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。また、PDF版をダウンロードいただけます。 はじめに – 共同創業者兼共同最高経営責任者より 2022年4月上旬に発生した障害により、お客様へのサービス提供が中断されたことをお詫び申し上げます。私たちは、当社の製品がお客様のビジネスにとってミッションクリティカルであることを理解しており、その責任を重く受け止めています。今回の全責任は私たちにあり、影響を受けたお客様の信頼を回復するために尽力しています。 アトラシアンのコア バリューの 1 つに「オープンな企業文化、デタラメは無し (Open company, no bullshit)」というものがあります。この価値を実現する取り組みの一環として、インシデントについてオープンに議論し、学びにつなげています。そして、このインデント事後レビュ
MySQLで3億レコード物理削除した話 - Qiita
はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」（同）。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日本で8700台を販売しているが、今回の不具合は初めての事象と聞いている」（ANA広報）。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー
うるう秒の挿入で複数のサイトに障害が発生
インターネットに大混乱を引き起こすには、ほんの1秒あれば十分だ。 グリニッジ標準時（GMT）7月1日午前0時、協定世界時にうるう秒が追加されたことで、複数の人気ウェブサイトやソフトウェアプラットフォームでサイトの混乱が発生したようだ。 国際地球回転及び基準座標系事業（International Earth Rotation and Reference Systems Service）が行うこの時間調整は、原子時計をムラのある地球の自転速度と一致させるために必要だ。1972年に時間調整が導入されて以来、何度となくうるう秒が追加されてきた。 うるう秒が引き起こした障害の影響を受けたサイトには、人気のリンク共有サイトRedditが含まれる。Redditは、Javaで構築されたオープンソースデータベース「Apache Cassandra」に問題が発生したのはうるう秒が原因、とTwitterで述べた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
