沈黙のGoogleと過熱するメディア:注釈と補遺

ダウンディテクター
ダウンディテクターはオランダのSerinus42が運営するネットサービスの障害検出サービス。日本では75のサービス障害についてフォローしている、筆者も時々チェックしているサイトだ。ダウンディテクターは、障害が起きていると感じたユーザーが当該サービスに障害ありとダウンディテクターに報告し、その報告時点におけるサービス毎の障害判定閾値を越えるとダウンディテクターによって障害と判定されるモデルで提供されている。ダウンディテクターの障害報告入力欄には報告対象サービス毎にカスタマイズされた障害種別の選択肢が用意されており、構造化され統計モデル化された口コミモデルとでも呼ぶべき仕組みとなっている。あくまで報告するユーザーの主観に基づくレポートである点に留意したい。ことにこの日のように昼過ぎからサービス障害が多発し各種報道でも繰り返しネット障害に言及されているような状況だと、不安や脅威となる要素に注意を向けやすくなる認知バイアスである注意バイアスが働いてささいな事でも障害と誤認するケースが増えても不思議はない。
注意バイアス
プロスペクト理論で有名なダニエル・カーネマンとエイモス・トベルスキーによる定義に基づくと、人が複雑な問題解決等のために何らかの意思決定を行う際、暗黙のうちに用いている簡便な解法や法則をヒューリスティックといい、ヒューリスティックは経験則と同義で扱われる。ヒューリスティックは判断に至る時間は早いが正しさは保証されない。起こり得るすべての結果という集合を仮定すると個々人の経験はその一部分でしかなく、または経験範囲は偏りを持つのが普通だ。偏った経験から導出された経験則に基づく判断結果には常に一定の偏りが含まれる。個々人の経験則=ヒューリスティックに含まれる認識上の偏りを認知バイアスと呼ぶ。注意バイアスとは認知バイアスの一種で不安を感じている者が脅威情報に選択的に注意を向ける現象をいう。
通信事業者による障害報告
KDDI1239分に自社設備に異常はなかったと当初説明したものの最終的には1224分発生、1647分復旧と報告しなおしている。NTT Communications1245分に障害復旧報告を公表、遅れて、さくらインターネットが1725分に復旧報告している。
復旧報告の中ではKDDINTT Communications、さくらインターネットともに「海外の経路不安定事象」、「自社設備に異常なかった」「複数の上位回線キャリアにて障害」と障害原因となった接続先事業者名について明言を避けていた。
一方、障害発生から一時間半ほど経過した1343分頃からIT専門媒体一般紙を含め報道機関が相次いで大規模な接続障害発生を報じ始めたが、この段階では個々のサービスの障害を結び付けた記事は見当たらなかった。この段階で、いまだ、あらゆる可能性を排除できない状況は変わらないものの障害長期化自体は避けられる可能性が見えた。
確認が取れないので報道が事実かどうかはさておきJR東日本のモバイルSuica障害が17時までに復旧と報じられた際に記事で「KDDIで発生した全国的なネット接続障害が原因」と名指しされた、と本文中では表現しているが日経BP ITProの記事はタイトルで、

 ”[続報]JR東日本「モバイルSuica」の障害は解消、KDDI回線が原因”


と断定し、本文では、

 “同社はKDDIの企業向けネット接続サービスを利用。KDDIで発生した全国的な
  ネット接続障害が原因だと見ている。”


と続けているが東日本旅客鉄道の誰がコメントしているのかは明らかにしていない。筆者個人の感想としては、どうもこういうあいまいな書き方は好きになれない。同じく本文中では、報道機関を通して社会に漏れ聞こえた、ときれいにまとめておいたが、と、いう構図を作った、という話かもしれない、と穿つのは筆者がひねくれているからか?
約款においては免責条件が定められている
たとえばOCNIP通信網サービス約款では第9章 通信(通信利用の制限等)と第12章 損害賠償(責任の制限)がそれにあたる。
インフラ障害による損害賠償請求に関する判例
よく引かれる事例だがこうした障害の際に比較される事案を再掲しておこう。NTT東日本のひかり電話障害の場合は、複数ゲートウェイスリップ機能において高負荷時に処理遅延が発生し輻輳崩壊が発生し2006919日から21日までの3日間に渡ってすべてのひかり電話において発着信を制限する事態となった。この時期は20063月末時点で47.1万チャネルだった契約数が翌20073月末時点で170.5万チャネルと一年のうちに3倍以上増加する急激な普及期だった。このときNTT東日本は約款上の義務を超え3日分の基本料金の請求減額(50円ほどだ)という対応がとられたがこれは現在に至るまで例外的に良心的な事例と記憶されている。

より一般的に引用されている事例としては、19841116日に起きた世田谷電話局前洞道内での電話通信ケーブル火災によって同局管内の89,000契約に及ぶ加入電話回線やDCを設置していた三菱銀行(当時)のオンラインシステム(全国243支店)が使用不能となり完全復旧まで9日間を要した例が挙げられる。この事例では被害を受けた利用者が、当時の公衆電気通信法109条に基づいて5日以上の通話不能となった日数に応じて日割基本料金の5倍相当を賠償した電電公社の対応では賠償額が低廉にすぎると営業損失の補填などを求めて裁判で争ったが、東京地裁(平成1413日)東京高裁(平成2712日)はいずれもインフラ障害による実質損害賠償請求を不可と判断した。
障害対応プロトコル
従来の通信事業者の広報プロトコルからすると障害発生報告(いわゆる第一報)、経過報告(第n報)、終息報告(最終報)を適切なタイミングで公表(この手順は電気通信事業法施行規則第58条に定められた電気通信事業者の報告義務の一部でもある)し、影響を受けた各方面に対して謝罪し、約款上の賠償義務が発生する場合は賠償の手順について説明し、障害原因のあらまし説明と再発防止を約束する手順を踏めば事態は沈静化するのが通例だ。
Google広報部の回答
Earlier today, some users were unable to access internet services as a result of a network configuration error. The configuration was fixed within eight minutes and service started returning to normal. Sorry for the inconvenience this caused.”

-- A Google Spokesperson

(対訳)
昨日、ネットワークの誤設定により、インターネットサービスにアクセスしづらくなる障害が発生しました。Google では、この誤設定を 8 分以内に正しい情報に修正しました。ご不便、ご心配をお掛けしたことをお詫び致します。

なお、Google広報からTechTarget編集部を通して質問した際に入手した原文では朝日新聞デジタルの記事で触れられていた「今後再発防止に取り組むという」にあたる記述が見当たらない。朝日新聞デジタルにはGoogleから別の文面が提供されていたのだろうか?
発生から30時間経過
筆者は、電気通信事業法施行規則58条をクソ意地悪く運用するとGoogle広報によるBGPリークを認めるまでの30時間をもって障害継続時間とカウントして、利用者から電気通信役務の提供の対価としての料金の支払を受けないインターネット関連サービスに適用される報告を要する重大事故の定義、二十四時間以上で十万以上の利用者、の定義を満たしているとこじつけられないこともないかもしれないとも思う。知己の総務省の中の人の顔を思い浮かべるに彼らはこういう下衆な手は使わないと思うが...。
カナダのBGPMON
BGPMONは世界に数百の観測点をもちBGPネットワーク監視サービスを提供している。BGPMON創設者であるAndree Toonk氏は2015年にCiscoに買収されたOpenDNSの中の人(Manager Network Engineering)でもある。ちなみにBGPMON20153月にOpenDNSに買収され、OpenDNS8月にCiscoに買収されている。なんともダイナミックな話である。
AS Pathフィルタ設定は万能ではない
完全なAS Pathフィルタを設定するためにはインターネット全体のある瞬間の全体像とトラヒックの分布をリアルタイムに把握している必要があるが、それぞれのASはインターネット全体の現状を把握してはおらず自身のPoPを介してインターネットの経路情報の一部を観測しているに過ぎない。また、仮にインターネット全体の状態をリアルタイムに観測できていたとしても最適経路を把握し続けるにはアルゴリズムの助けを借りてもなお、選択に費やせる時間と資源量の制約が立ちはだかる。組み合わせ爆発を抑え込むには組み合わせの数を抑え込むしかないのだが、インターネットは成長し続けており2バイトASNが枯渇し4バイトASNに移行しつつあるのが実態だ。限定合理性に制約されている以上、完全なAS Pathフィルタは存在しえないのでAS Pathフィルタ万能論に飛びつくのは危険だ。CAIDAの調査を見ればわかるように(すべてのBGPイベントの影響が収束した完備な)ASの接続構造グラフを把握する作業は容易なものではない。なにしろ調査中にどんどんASが増えていくしAS Pathグラフが変化していく、あらゆる要素がそこかしこで変化し続けるのだ。実務でBGPに触れている方にはインターネット全体でのリアルタイムなBGPコンバージェンスをイメージしていただきたい、収束時間を考慮するといかに無理な話かすぐご理解いただけると思う。

繰り返しになるが、AS管理・運用者の手元にあるいわゆる「フルルート」は真に厳密に今現在のフルルートを反映しているわけではない。インターネットに参加するには個々のネットワーク(AS)は複数の経路(Path)を持つことになっている。複数の経路がある場合は経路選択(経路制御)が必要だ。そして2以上の任意の数のリンクをもつノードが個々独立したポリシーに従って動的に組み合わさっていくとランダムグラフを描くことも思い出していただきたい。BGPネットワークも自律協調分散システムに普遍的にみられるふるまいをしている。

ちなみに今回の障害ではGoogleVerizonピアリングポリシーが定めるOperational Requirements要件(これはVerizon側が守るべき条件ではなくVerizonとピアリングするASが守るべき条件)に今回の障害は違反しているように見える。(そんなに杓子定規に適用はしないだろうが)

2.Operational Requirementsの以下のセクションを参照 
2.3 Each Internet Network must set next hop to be itself, the advertising router of the network. Each Internet Network will propagate such routes to its transit customers with its own router as next hop
2.4 Each Internet Network shall implement "shortest exit routing" and advertise routes consistent with that policy, unless both Internet Networks mutually agree otherwise based on special circumstances.
完全グラフとランダムグラフを含むグラフの分類

インターネットについてのおさらい
細かい話はしだすときりがないが、ここで大雑把に今回の障害の舞台を整理しておこう。世界に広く普及しているL2OSI Layer2)プロトコルであるEthernetL3L4プロトコルであるIPTCPUDP)も含めてそれぞれのフレームフォーマットを見ればわかるように経路制御を行っていない。L2Ethernetを利用している場合は(細かい話は端折ると)木構造n部グラフ(懐かしの10base2なら道グラフ)しか作れない。小さな会社や家庭のLANはおおむねこの範囲の技術で構成されているのが普通だ。複数の経路を条件に応じて選択可能にするならL4IGP(Interior Gateway Protocol)を利用する。複数拠点を持ち自前で冗長構成されたWANを構築しているような場合に利用されている。ここまでが単一主体によって構築運用されるネットワークの範囲だ。

単一主体によって構築運用されている閉じたネットワークイントラネットと言い換えてもよいをインターネットに参加させるにはすでにインターネットに参加してるネットワークの中に収容ISP回線接続契約してIPアドレス割当受ける形だするかIANAInternet Assigned Numbers Authority実務上はIANAら割当をけているRIRsRegional Internet Registries日本の場合はIANAAPNICJPNICからASNAutonomous System Numberの再割り当てを受け自身をAS: Autonomous System=自律システムとして登録しL4BGPBorder Gateway Protocolを利用して他のASとピリングまたはランジット契してトラヒック交換する自身をインターネットに加しているネットワークの一つにすることになる
RIRsは通常シングルホーム単一接続先しかもたない)のネットワークに対してASNを割当てないのでASはすべてマルチホームでBGP接続されているのが建前だ。したがって各ASは最低でも二つ以上の他のASに対する経路を持っていることになる。
ピアリングの力学
理屈上、最低二つ以上の接続先(Path)をもつASが組み合わさり、相互に自らのASNIPアドレスブロックとPathをピアリング相手のASに通知(経路広報)していくと最終的にはすべてのPathの組み合わせ(フルルート)がすべてのASに共有される。
しかし、通常はピアリング相手に自らの他のピアリング相手の経路まで通知して他のネットワークへのトランジット(乗り継ぎ、この場合は他のASの経路情報まで広報すること)を提供することはない。もし仮に自網についての経路広報しかしないピアリングのみで構築されていたとするとそのグラフは完全グラフ型となる。しかしトラヒックはアーラン分布することを考えると完全グラフ型のネットワークではオーバーヘッドがあまりに大きすぎて不経済だ。
ついでにインターネットに参加するすべてのASが自らのピアリングしている他のASの経路情報まで広報した場合、グラフはランダムネットワーク型になるがトラヒックがアーラン分布するためにAS毎のトラヒック負担の不均衡が大きな問題となる。

もう少し細かく見ていこう。とあるASが他のASからピアリングの申し入れを受けた際に受け入れるか否かはそのASが自らのポリシーに従って決定するわけだが、本文に記載した通り、個々のASは通常Selective/Restrictive/Openのいずれかのポリシーモデルをベースに任意に自身のポリシーを設定している。Selectiveポリシーとは個別相談に応じる用意がある、Restrictiveポリシーとは原則的に新規ピアリングは受け入れていない、Openポリシーとは原則的にピアリングは受け付ける用意がある、程度の意味だ。ただし、Openポリシーだからといってどんなピアリング要求も無条件に応じるわけではない。通常はトラヒック量やアドレス量、運用能力といった条件を満たしている必要があるし、さらに申し込み側に対して受け入れ側が独自の裁量で受け入れの可否判断や接続切断の権利を留保しているものだ。
さらに、ピアリング(通信事業者的には相互接続の一種)するには自ASと接続先ASの境界ルーターを接続するわけだが当然ながら境界ルーター設置国の通信法の制約を受ける。もちろん相互接続する境界ルーター間の物理的距離が離れているほど中継接続回線コストも伝送遅延も大きくなり、ピアリングが費用倒れになる可能性が高まる、といった物理的制約と付随する費用制約も受ける。

そこでBGPで相互に接続されたネットワーク間のトラヒック不均衡は回避できないのでトラヒック負荷を含む接続コスト負担を均衡させる仕組みが必要になる。

ピアリングは境界ルーター間をケーブル接続するだけでトラヒック交換(通信量が対称となるのが建前)でき、ISPから帯域を購入する場合と比較して伝送量課金が発生せず(それなりの運用規模があれば)低コストが期待できる。しかし極端な話、昨日今日ASNを取得したばかり(またはASN取得予定)のネットワークにはOpenポリシーを採用しているASが掲げる接続条件をクリアするのは荷が重いのが普通だ。そうしたピアリング先のないASはトランジットを提供している電気通信事業者とトランジット契約を交わしてトランジット、つまりトランジット提供ネットワークが持つ他のネットワークへの接続へのトラヒック中継(BGP的には相手の持つすべての経路情報=フルルート)を購入することになる。
ちなみにCAIDAAS-Level Internet Graphで頂点に位置するTier1事業者ピアリングだけでフルルートを取得しているRestrictiveポリシーを採用しているので理屈上新規にASN取得したネットワークが無償でフルルートを取得することはできない。通常フルルートを取得するにはTier1事業者またはTier1事業者からトランジットを購入しているTier2以下の情業者からトランジットを購入してフルルートを取得することになる

制約理論(TOC)的にみるとトランジット契約とはBGPトラヒックの最適化を目的とした制約条件として機能して
いるとも言える。

ともあれ、こうして形成された大規模なランダムグラフ構造を持つPathの組み合わせ、フルルートの中から最適な経路を選択するためにBGPはパスベクトル型経路制御アルゴリズムを採用している。突っ込まれる前に書いておくがMPLSなどの話には今回はあえて触れない。
カスタマーコーンとネットワーク外部性
Global BandwidthResearchは海底ケーブルの総帯域幅に対して利用主体の種別毎のシェアを割り出しているのであってインターネットにおけるトラヒックシェアを表しているわけではないインターネットのトラヒックシェア調査では検出できないトラヒックをも含めた調査である点に留意が必要だちなみにGoogleのインターネットトラヒックシェアは201010月時点で小さく見積もって平均6.4%最大で平均12%もしGoogleISPであったなら世界第二位のトラヒック規模に相当するARBOR Networksは報告していた
膨大なトラヒックを生成するGoogleの網構成
Open Network Summit 2017で公開されたGoogleの資料にはPoPPoint of Presenceは世界に100以上と記載されているがPeeringDBによると現時点でプライベートPoP109拠点を数えていたのでこちらの数字を採用している
Googleの網構造を踏まえた障害原因の推定
EspressoGoogleOpenNetwork Summit 2012での講演で公開していたCentralized Traffic Engineeringの考え方を推し進めた先に位置づけられる。Google2012年の段階でCentralized Traffic Engineeringを実システムで実践しており、「防弾」(堅牢、の意だろう)のI-Scaleと「実験可能な」G-Scaleの二つの論理ネットワークを構築して実ネットワーク規模で運用と実験を安全に両立する環境を持っていた。
今回障害における残件
総務省による大臣会見録画書き起こしを確認すると大臣発言は、

“今おっしゃったとおり、この通信障害というのは、25日の午後に全国でインターネットがアクセスしづらい状態が発生したということです。 これは、グーグルはインターネットで通信を成立させるため、技術的になりますけれども、事業者同士で行う通信経路の設定を誤ったことにより、国内事業者間の通信が、海外を経由する事態が発生してしまった。その一部の回線に多大な負荷がかかったということが原因でありました。
 各事業者の対応によって、その日の夕方までには概ね復旧したと聞いていますが、こういう事態により重大な事故の発生を防ぐ観点から、総務省においては、詳細な原因の調査と、今後の対応について検討を行う予定としています。”


となっている。
全体についての補遺:より広範な検証と検討が必要
発生件数の日次分布で見るとBGPリークは一日当たり平均9.5件発生しており中央値は5件、しかし825日は192件も発生しており観測された200日間に発生したBGPリークの10.2%825日に集中していたことがわかる。明らかに異常だ。記録を追っていくとGoogleBGPStreamPossible Hijackと判定された322分(UTCJTC1222分)の経路広報以前から23件ものイベントが記録されている。ものの3時間で平均の2倍を超えるイベントが起きている。これら先行するイベントに一見Googleは関係ないように見えるが小島氏のように丁寧に生ログを解析したわけではないのではっきりしたことはわからない。Google由来のイベントの後もBGPリークが突出して頻発しているのも気になる。日本における「全国的なネット接続障害」の直接の原因はGoogleが報道機関に認めたようにGoogleの経路広報設定の間違いにあったかもしれないが、筆者はより広範に8月末からの障害集中について詳しく検証していく必要があると考えている。


日当たりのBGPハイジャック、リーク、停止の発生件数分布

筆者は今回の障害については規模と影響の面からNATO CCD COECooperative Cyber Defence Centre of Excellenceの定義に基づくとダウンディテクターの検出した現象だけ見ればサイバー攻撃を疑うに足る事象だったと考える事象の発生原因が障害であったのか攻撃であったのかで政府の取るべき行動は大きく違ってくるそうした重要な問題の初期切り分けに時間がかかりすぎた今回の事例が提示した課題は多くかつ重いと言わざるを得ない
戻る
Load disqus comments

0 コメント