2022年11月30日03:24（東京）に、AdGuard DNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuard DNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日

米Facebookは10月5日（現地時間）、前日の日中に発生したInstagramやOculusも含むすべてのサービスに影響した障害について、その原因と復旧方法について説明した。 今回の停止は、前日簡単に説明したように、グローバルバックボーンネットワーク容量を管理するシステムによって引き起こされたものだが、約6時間にもわたり、非常に重要なことであるため、もう少し詳しく説明する価値があると考えたとしている。 グローバルバックボーンは、Facebook全社のコンピューティング施設を接続するネットワークで、世界中を数万マイルの光ファイバーケーブルで接続している。このインフラの保守のため、エンジニアは通常、バックボーンにオフラインで接続し、ファイバーの修理、容量追加、ルータのソフトウェア更新などを行う。 昨日の停止は、こうした定期的なメンテナンスの一環として、容量を評価するコマンドを発行したところ

A new iOS 14 privacy feature could potentially cause problems for enterprise or educational network and device management setups, Cisco warned on Thursday. The privacy feature in question is an option to use a "private," or randomized, media access control (MAC) address when connecting a Wi-Fi network. Generally, devices identify themselves using the same MAC address when connecting to networks, w

Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか Microsoft Azureは、2019年5月2日午後7時43分から午後10時35分まで（日本時間 2019年5月3日午前4時43分から午前7時35分まで）の約3時間、DNSの名前解決に問題が発生。 ほぼ全世界的に、Microsoft AzureをはじめOffice 365/Microsoft 365やMicrosoft Dynamicsなど同社サービスに対する接続ができなくなるという大規模な障害を起こしました。 この大規模障害の原因は、同社サービス用のDNSのメンテナンス作業のミスが原因だったと発表されました（中間報告の段階では既存のDNSからAzure DNSへのマイグレーション作業に失敗したと報告されていました。現在の報告では計画メンテナンス作業での失敗だとされ

「ネットワークの誤設定により、インターネットサービスにアクセスしづらくなる障害が発生した。ご不便、ご心配をおかけしたことをお詫びする」――。2017年8月25日昼ごろ日本国内で発生した大規模な通信障害。これについて米グーグルが、原因となる誤設定があったと、謝罪の意を8月26日に表明した。 当初より識者の間では、「グーグルから送られてきた大量の経路情報が引き金になったのではないか」との見方が強かった。実際にその通りだったわけだ。 とりわけ大きな影響を受けたのが、NTTコミュニケーションズとKDDI、そしてこの両社の通信サービスを利用していた法人・個人だ。インターネットの接続から各種ネットサービス、金融取引、モバイルSuicaのような決済サービスにまで影響が及んだ。 ただグーグルは、同社がいう「ネットワーク誤設定」が、人為的ミスなのか、ソフトや機器の不具合によるものなのかまでは明らかにしていな

2017年8月25日、NTTコミュニケーションズ（NTTコム）のインターネット接続サービス「OCN」で発生した通信障害に関して、インターネット通信関連の識者は誤った経路情報が大量に流れたことが原因ではないかとの見方を示した。ここでいう経路情報はルーターがBGP（Border Gateway Protocol）というプロトコルを使って交換するものだ。 日本ネットワークインフォメーションセンター（JPNIC）の岡田雅之氏は、NTTコムは複数の組織と対等な関係でネットワークの経路情報をやり取りしているが（これを「ピアリング」という）、そのうちのある組織が誤った経路情報を大量に流したのではないかと話す。その結果、「NTTコムを介してインターネットに接続していた企業のルーターが、大量の経路情報を受け取り高い負荷がかかり、一部はフリーズしたような状態に陥るなどして通信障害につながったのではないか」（岡

大型のシステム障害の詳細が見えてきた。全日本空輸（ANA）が2016年3月22日に起こした国内線旅客システム「able-D（エーブルディ、以下では便宜上開発コード名のANACore：アナコアと称す）」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース（DB）サーバーが停止したというもの（関連記事：ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン）。今回、弊誌

弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。 世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。 うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。 つづく。 続き。 弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブ

「無線LANにあまり大きな期待をしないでほしい」――。無線LAN関連の取材をすると、ネットワーク担当者や構築を支援したエンジニアの、こんな声をよく耳にする。 無線LANは家庭ではもちろん、駅やコンビニエンスストアでも無料で利用できるようになっている。比較的新しい無線LANアクセスポイント製品には、1Gビット/秒を超える通信速度をうたうものも登場している。今や「どこでも高速に通信が可能な技術」、というイメージが定着しつつある（写真）。 しかし、そのネットワークを構築・運用する“裏方”であるエンジニアは、思った以上に苦労しているようだ。とりわけ企業の中で使う無線LANは、スペース当たりのアクセスポイントの数が多く、快適な通信環境作りが難しい。冒頭の発言は、有線と同様の高速通信を期待する利用者への、いわば嘆きだ。 こうしたふと漏れた一言には、無線LANを活用するうえでのヒントが隠されている。技術

RSSフィードサービスを提供する米Feedlyは6月11日(現地時間)、DDoS攻撃を受けてサービスを提供できない状態に陥ったことをブログで明らかにした。攻撃中止の条件として攻撃者が金銭を要求してきたが、同社は要求を拒否。サービス再開に向けた作業を続けている。 DDoS攻撃は、サーバーなどに大量のパケットを送り付けてサービス提供を妨害する攻撃だ。Feedlyは11日午前2時(太平洋標準時)に、DDoS攻撃を受けていると公表。ネットワークプロバイダーと共に攻撃を無効にする作業を進め、また捜査当局や他の被害者と協力して攻撃に対処すると表明した。4時間後の午前6時(同)にブログを更新して、インフラの変更に数時間を要すると告知。ユーザーがサービスにアクセスできない状態が10時間を超えた。攻撃によるデータの損失や情報漏洩はないという。 Feedlyと連携するEvernoteにもDDoS攻撃の影響は及

そういえば、宅内LANでこんなことがあったので書き残しておきます。 我が家は、1Fから2Fの間で有線LANをひいております。家を建てたときに、将来の事を考えて、CAT6e(6a)を配線してもらってます。 さて、1Fに設置したスイッチングハブ(NETGEAR製)から、2Fに設置したスイッチングハブ(NETGEAR製)に同じようにCAT6eのLANケーブルを使ってつないでみたのですが、はて100Mbpsで認識する。 何度かつなぎ直したり、スイッチングハブの電源を再起動してみると、時折1Gbpsで認識する。なんぞこれ。 最初は、スイッチングハブにつながっているWOL対応のサーバが落ちている場合、サーバ側が100Mbpsでの接続になるようだったので、それに引きずられているのかと思い、1Fから来ているLANコンセントへのケーブルを、スイッチングハブのポートに繋ぐのをやめて、起動しているサーバの1Gb

はじめに 初めまして、（⁠株）ミクシィの中野和貴です。私はシステム本部運用部インフラグループネットワークチームという部署で働いており、ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50～55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや、その後のインフラ事情を紹介していきます。 日々大量のトラフィックが流れるmixiのネットワークですが、大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。 ミクシィのネットワーク構成と問題の発覚 mixiでは主要なネットワーク機材にはお金をかけていますが、サービス規模からどうしてもラック数が多くなってしまうため、エッジスイッ