インフラ・DevOps
Telstra障害:ネットワークが2006年と判断した夜
Telstra outage: The night a network decided the year was 2006 (netnod.se)
要約
2026年7月8日、オーストラリアの通信事業者Telstraのモバイルネットワークで大規模な障害が発生し、音声通話やSMSが利用できなくなり、緊急通報にも影響が出ました。原因は、単一のGPS受信機がメンテナンスから復帰した際に、誤って年を2006年と認識し、ネットワーク全体がそれに同期してしまったことでした。この障害は、現代社会における正確な時刻同期の重要性と、その脆弱性を浮き彫りにしました。
全文翻訳
Sven-Christian “Svenne” Ebenhag, 2026.09.17 Telstra障害:ネットワークが2006年と判断した夜 Netnod Time
Netnodでは時々、なぜ時間が重要なのかという質問を受けます。Netnodはスウェーデンの国家標準時を配信しており、これは非常に専門的なエンジニアだけに関係することのように聞こえるかもしれません。実際には逆です。もし「今」という共通の理解がなければ、私たちが当然だと思っている多くのことが機能しなくなります。この夏、オーストラリアはこのことを痛感しました。今回は、時間が現代社会にとってなぜ重要なのか、この特定のケースで何が起こったのか、そして私たちが得られる主な教訓について説明する機会を得たいと思います。
2026年7月8日、オーストラリア最大の携帯電話事業者であるTelstraが運営するモバイルネットワークの大部分が機能停止し、音声通話が通らず、テキストメッセージも届かなくなりました。オーストラリアの緊急番号への通話さえも届きませんでした。しかし、この障害はさらに広範囲のシステムに影響を及ぼし、列車、決済端末、チケットシステム、EV充電器などが混乱しました。ネットワークが攻撃されたわけでも、光ファイバーが誤って切断されたわけでもありません。すべてのシステムには電力がありました。
原因は何か、とあなたは尋ねるかもしれません。それは、メルボルンにある単一のGPS受信機が、定期メンテナンスから復帰した際に、年を2006年だと信じ込み、ネットワークの残りの部分もそれを信じるように説得してしまったことでした。Telstraは、Technology Audit Partners (TAP) という会社に独立したレビューを依頼しました。このレポートは非常に興味深い読み物です。なぜなら、同じ種類の障害が、人々を生かし続けるために依存しているシステムを含む、多くの重要なサービスに現れる可能性があるからです。これらのシステムの多くが機能するためには、時間が正確であること、あるいは少なくともすべてのシステムで同じであることが極めて重要です。そして、この分野の誰もが知っているように、「正確」とは相対的な言葉です。絶対的な時間というものはなく、参照値に対してある範囲内の時間しかありません。その範囲がどれだけ広いかは、何をしているか、あるいはどのようなビジネスを行っているかによって完全に異なります。Telstraのようなモバイルネットワークを運営することは、ビジネスがどれほど時間に依存しているか、そのものです。
現代の携帯電話通信が時間がいかに重要かを説明する
最新の携帯電話プロトコルは、精密な時間なしでは機能しません。モバイルネットワークは、FDD (Frequency Division Duplex) または TDD (Time Division Duplex) のいずれかを使用して、アップリンクデータとダウンリンクデータを分離します。FDDは各方向に独自のスペクトル帯域幅を与え、両方が衝突することなく連続して実行できます。一方、TDDは単一のスペクトルブロック全体を両方向に使用し、非常に短い間隔で送信と受信を交互に行います。通常、ダウンリンクの方がアップリンクよりも多くのデータが流れるため、FDDの固定比率はアップリンクスペクトルを多く無駄にしますが、TDDは実際のトラフィックに合わせて比率を調整できます。そのため、スウェーデンの主要な5G帯域である3.5GHzを含む、ほとんどの最新の5GスペクトルはTDDです。
これもTDDが正確な時間に依存する理由です。同じ周波数を使用する各セルは、他のすべてのセルと同期して方向を切り替える必要があります。クロックがドリフトするセルは、隣接するセルの受信ウィンドウにデータを送信し、その結果、ネットワークは自己妨害を開始します。業界は、2つの方向を分離するためにスペクトルを割り当てるのではなく、時間の精度に依存することを選択し、すべてのセルが「今」がいつであるかについて合意することへの強い依存を受け入れました。したがって、時間に依存することは設計上の選択です。
しかし、私たち全員がシステムが「今」について合意できる能力にどれほど依存しているかを考えると、時間がそれに値するほど考慮されていないのは、いくぶん不可解です。そして、それは公開されたレポートから非常に明確な教訓です。
では、実際に何が起こったのでしょうか?
時間の配信アーキテクチャ。
まず、時間の配信アーキテクチャを理解することが不可欠です。時間の配信プロトコルはすべて階層を構築します。Telstraがレポートによると展開しているNetwork Time Protocol (NTP) は、その階層をストラタム (strata) で表現します。ストラタム0は、GPS受信機やNetnodの原子時計などの参照自体です。ストラタム1は、Netnodが提供するNTPサーバーなど、ストラタム0の参照に直接同期されたマシンです。ストラタム2はストラタム1サーバーから同期し、ストラタム3はストラタム2から同期し、以下同様です。
Telstraの場合、その階層は、少なくとも当初は特定の形状をしていました。2010年のこの設計では、オーストラリアの国家計量研究所 (NMI) にストラタム1ソースがあり、スウェーデンの研究機関がスウェーデンで行っているように、国の時間スケールを維持していました。Telstraは、それらの外部参照から、シドニーとメルボルンにある独自の2つのストラタム2サーバーに時間を取り込み、それが次にシドニー、メルボルン、パースにある3つのストラタム3サーバーに供給されていました。それらの下にクライアントがありました。この文脈では、クライアントとはラップトップや電話を意味するのではなく、携帯電話ネットワークインフラストラクチャ全体、例えばセルサイト間のハンドオーバーを処理するノードを指します。広大な地理的範囲に数千のノードがあり、それらのすべてが「今」が何であるかについて、数百万分の1秒以内の同じ考えを持つ必要がありました。
TAPレポートは、このセットアップを「目的に合致している」と記述しており、Telstraに「NMIから非常に信頼性が高く権威のある参照時間ソース」を提供したとしています。ストラタム自体は、時間が正確かどうかを示すものではなく、サーバーから参照までのステップ数を示すだけです。悪い時間参照を持つストラタム1サーバーは、依然としてストラタム1サーバーです。
悪い時間ソースからの保護
したがって、NTPは悪い時間ソースからの防御を必要とします。実際、それは2つの異なる防御策を持っており、それぞれが互いに独立していると仮定しています。比較可能な候補の中で、より低いストラタムがより大きな重みを持つことになります。これが、クライアントがどのソースを選択するかを決定するメカニズムです。NTPは複数のソースを比較し、他のソースと一致しないものを破棄します。ありえない時間を主張する単一のソースは、それがどれほど権威を主張していても、多数決で除外され、ドロップされます。これらの防御策のいずれも、特定の障害に特化したものではなく、連携して、破損した受信機、設定ミスのあるサーバー、または外部攻撃から保護します。しかし、これらの保護措置は、クライアントが監視している時間ソースが互いに真に独立している場合にのみ機能します。
NTPの2つの展開方法
NTPは2つの方法で展開できます。クライアント/サーバーモードでは、関係は宣言され方向性があります。ノードはサーバーから時間を受け取りますが、それ以外は何も受け取りません。2010年のTelstraのセットアップは、実際にはこのようなクライアント/サーバーモデルでした。ピアリングは許可されていましたが、同じストラタムレベルでのみ許可されていました。TAPレポートは、冒頭で述べたように、このセットアップを「目的に合致している」と記述しました。
もう一つの方法はシンメトリック (ピアリング) モードで、ノードは相互に時間を交換し、アルゴリズムが現在好むソースに落ち着きます。ピアリングは柔軟性があり、ソースの損失をうまく乗り越えます。しかし、それはまた、本番環境でのトポロジーが設計されたものではなく、創発的なものであることを意味します。あなたが文書化したのは、誰も承認したことのない形状に静かに再編成される可能性のあるセットアップです。
Telstraの2020年のアップグレード
2020年にモバイルコアのタイミングシステムがアップグレードされ、新しいNTPタイミングシャーシを含む新しいハードウェアがインストールされました。そのインストールにより、いくつかの変更が加えられました。最初の変更は強制的なものでした。新しいシャーシは、同じボックス内でストラタム2サーバーがストラタム3サーバーに供給することを許可できなかったため、2つを相互に配線する必要がありました。シドニーのストラタム3はメルボルンのストラタム2から、メルボルンのストラタム3はシドニーから時間を受け取りました。実際には、2つのストラタム2ソースを持つ代わりに、各サイトは1つしか残されませんでした。TAPレポートは、冗長性のこの低下が認識され、受け入れられたと述べています。
2番目の変更は、クライアント/サーバーモデルからピアリングモデルへの移行でした。レポートは動機について明確ではありませんが、この冗長性の損失を補償したかったと示唆するのは合理的です。各サイトが2つではなく1つのソースしか持たない場合、サーバーが独自の代替を見つけることを許可することで、より良い回復力という印象を与えることができたかもしれません。TAPレポート