要約

  • 2019年12月23日、ハードウェア故障とストレージ設定の不備が重なり、ARINの仮想マシン切り替えが失敗した。公開サイトとARIN Onlineは別々の時刻に復旧した。
  • その後、理事会はインフラ報告、是正計画、停止リスクの評価を求めた。記録には管理上の追跡が残る一方、すべてのリスクが解消されたことや、各復旧目標が検証済みであることまでは示されていない。

冗長構成でも切り替えられなかった理由

12月23日午後12時35分、ARINの監視システムが、顧客向けサービスを支える複数の仮想マシンについて警報を発した。運用担当者は待機中の別ハードウェアへ手動で切り替えようとしたが、うまくいかなかった。12時55分には、ARINのウェブサイトと顧客向けアプリケーションARIN Onlineが利用できなくなった。公開された事故説明が確認しているのはこの二つであり、他のレジストリサービスすべての状態ではない。[4]

調査では、仮想マシンクラスタが使っていた共有ストレージへのアクセスが原因候補になった。事後検証でARINは、ストレージ装置のハードウェア故障と設定不備が組み合わさり、仮想化エンジンが停止したと説明した。故障部品は交換され、修正した設定はベンダーサポートの確認を受け、クラスタは通常運用に戻った。[4]

ここで重要なのは、主系と待機系の両方が同じストレージに依存していた点だ。ホストが二台あっても、共通の依存先が失敗すれば、切り替え操作だけでは利用可能なアプリケーションを生み出せない。冗長化は、設計上分離された故障に対する備えである。共通依存を自動的に独立させる仕組みではない。

公開記録はウェブサイトとARIN Onlineの停止を示すが、Whois、RDAP、DNS、IRR、RPKI、登録情報が停止したとも、影響を受けなかったとも述べていない。あるサービスについて説明がないことは、その停止や正常稼働の証拠にはならない。この境界を守らないと、ひとつのアプリケーション障害を組織全体の停止に読み替えることになる。[4]

年初のDNSSEC障害とは分けて読む

2019年1月の理事会議事録には、DNSSEC検証を行う利用者に影響するARIN.NETドメインの障害が記録されている。John Curranは事後検証を理事会に説明し、最高技術責任者Mark Kostersとミッションクリティカルなシステムを整理すると述べた。議長は、その作業後に報告するよう求めた。議事録には障害の長さ、原因、後続報告の結果は記されていない。[3]

この出来事と12月のストレージ障害を同じ原因の連続事故として描く根拠はない。前者はDNSSEC検証に関わるドメインの利用障害、後者はウェブサイトと顧客アプリをホストする仮想化環境の喪失として記録されている。Curranがいずれも理事会へ説明したという共通点だけで、技術的な因果関係を作るべきではない。

サイトと顧客アプリは別々に戻った

停止が長引き、修復の見通しが立たないため、午後3時30分に運用チームはウェブサイトを災害復旧サイトへ切り替えた。ウェブサイトは午後4時に復旧し、ARIN Onlineは午後5時10分に復旧した。ホームページが見られることと、顧客が使うアプリケーションが戻ることは同じではない。[4]

故障部品は1月2日に交換され、影響したクラスタは再び稼働した。ウェブサイトを本番データセンターに戻すには追加の停止が必要なため、その切り戻しは1月25日の計画済み保守時間に合わせられた。サービスの復旧、部品の交換、本番環境への復帰、すべての是正策の完了は、異なる節目である。[4]

ARINの説明では、災害復旧サイトは維持・試験されていた。ただし、復旧時間の数値目標や、いつ切り替えを決断するかの基準は公開されていない。何が起き、何時に戻ったかは分かるが、事前の目標に照らした成否までは示されていない。

Curranの職責と運用チームの仕事

ARINの組織説明では、理事会が組織の範囲や使命を担い、CEOとともに戦略・財務の監督を行う。CEOと職員はその方針を日々の運用に反映する。理事会がCEOを選び、CEOは運用スタッフを任命・監督し、理事会の議席を持ち、諮問評議会との連絡役も担う。[1][2]

Curranの公式略歴には、複数のインターネット企業でCTOを務めた経験と、1997年からのARIN創設理事としての経歴がある。2009年まで理事長を務め、その年にCEOとなった。[1] これは技術経験の背景にはなるが、ストレージ障害を彼自身が診断したという証拠ではない。12月の運用報告はCOO Richard Jimmersonによるもので、監視、ベンダーとの調整、復旧、事後検証は運用チームの仕事として記述されている。[4]

理事会記録から見えるCurranの役割は、技術作業そのものではなく、運用情報を監督の場へつなぐことだ。2020年1月には説明に追加情報を出し、理事会はインフラ報告、長期是正の前倒し、災害復旧機能の強化、停止リスク評価を求めた。[5] こう整理すれば、彼の管理責任を扱いつつ、個人が障害を「救った」という英雄譚にしなくて済む。

事故説明を継続的な監督へ

2020年3月、COOは完全な更新資料を4月に示す予定で、是正期限は年末、作業は計画どおりだと理事会に説明した。[6] 5月の議事録では、障害是正報告と技術インフラの補足資料が完成したと記録されている。理事会は、システムと業務機能の結び付き、作業の開始・終了日、四半期ごとの報告を求めた。[7]

これは事後説明を管理工程に変える動きだ。理事会が資金や優先順位を判断するには、どの機能がどのシステムに依存し、誰がいつまでに何を直し、どう確かめるのかを知る必要がある。Curranは、技術解決策を外部委託する際の原則と時期をまとめる考えを示した。[7] これはストレージ交換を本人が主導した証拠ではなく、理事会が技術と業務上の影響を読めるよう報告を整える役割の記録である。

2021年2月には、理事会がシステム性能や顧客サービスの指標、主要サービスのサービス水準、可用性・信頼性の枠組み、システム依存関係図を求めた。議事録には、多くのシステムを最新の状態にしたとの説明もあるが、2019年のすべての是正項目が完了したとは記されていない。[8]

状態の見える化は復旧そのものではない

2021年4月、ARINはサービス状態ページを公開した。ARIN Online、プロビジョニング、Whois、RDAP、RPKI、IRR、報告サービス、ウェブサイトなどを分けて扱い、メール、SMS、Slackなどで通知を受け取れる。発表は、この対応がコミュニティ提案ACSP 2020.5に応えるものだと説明し、CTO Mark Kostersが署名している。[9]

状態ページが答えるのは「どのサービスに影響が出ていると運営者が報告しているか」であり、災害復旧経路が機能したかではない。正常稼働率の測定でもSLAでもない。公開時期だけから、2019年の障害を受けて作られたとも断定できない。確かな価値は、ユーザーがサービスを区別し、更新を追えるようになったことだ。[9]

2022年、COOはNetAppに関係する以前の高リスクが、組織体制の変更とインフラ更新で緩和されたと理事会に報告した。ARINは他のベンダーのソリューションにも移行していた。[10] これは議事録に記録された経営側の説明であり、2019年の全対策に対する独立監査ではない。2025年の年次報告も、一貫したサービス提供を組織目標に掲げるが、当該障害の復旧時間を測定してはいない。[1][11]

記録から分かること、分からないこと

公開資料は、仮想マシンの切り替え失敗、サイトとアプリの停止、異なる時刻での復旧、故障部品の交換と設定修正、理事会の是正・リスク報告要求、その後の技術負債報告や状態ページという流れを示す。[4][5][6][7][8][9]

一方で、ARINの全サービスが停止したとも、他のサービスが影響を受けなかったとも証明していない。すべての是正項目が期限内に完了したことや、リスク低減が第三者に検証されたことも示さない。この不明点は非難でも免責でもなく、参照した公開資料の限界である。

ネットワーク事業者にとって、この区別は実務的だ。ウェブサイト、アカウントアプリ、プロビジョニング、RPKI公開、登録データベースは、それぞれ依存先や代替手段が違う。どの業務がリアルタイム接続を要し、どの情報をキャッシュから利用でき、どの変更を待つべきかを事前に決められる。それはARINの責任を顧客に移すことではなく、一つの画面の状態を別のサービスの状態と混同しないための備えだ。

ARINにとって次の検証点は、サービスごとの復旧時間、復旧試験の範囲、共有依存のリスク、障害後の対策を試験で閉じた割合である。理事会が指標と依存図を求めたことは議事録に残るが、2019年の個別サービス測定は公開されていない。設備更新、ダッシュボード、「復旧済み」という表示だけでは、当時の故障経路を想定した試験成功の証拠にならない。

Curranのリーダーシップは、観察できる管理の仕組みで見るべきだ。依存関係が理事会に届くか、技術負債に期限があるか、復旧目標が試験されるか、顧客がサービスごとの状態を見分けられるか。資料は2019年以後に報告と可視性が強化されたことを示すが、全目標を閉じた公開スコアカードはない。技術復旧は運用チームが担う。CEOの役割は、リスク、責任、証拠が組織の意思決定に届くようにすることだ。[5][6][7][8][9]

結論：レジリエンスはサービスごとに確かめる

2019年12月の障害では、高可用性とされた構成でも、共有ストレージへの依存が主系と切り替え先を同時に止めうることが明らかになった。ウェブサイトとARIN Onlineは別々に復旧し、理事会はその後、インフラ、是正、停止リスクの報告を求めた。[4][5]

記録から見えるCurranの役割は、執行と制度の両面にある。理事会へ情報を補い、監督の過程に資料を載せ、システム性能や依存関係の説明を改善する。技術的な診断と復旧は運用チームの仕事だ。後続資料はインフラ変更、定期報告、状態ページを記録しているが、将来の停止がないことを保証するものではない。[1][2][5][7][8][9][10]

より広い教訓は、レジストリの権威と運用の信頼性は別問題だということだ。どのサービスが影響を受け、どの依存が失敗し、どの経路で復旧し、いつ戻り、修正がどう確かめられたかを分けて示す必要がある。ARINの記録はその一部を見えるようにし、同時に答えていない問いも残す。評判や「高可用」というラベルではなく、サービス単位の証拠がレジリエンスを示す。

出典

  1. ARIN Board of Trustees and John Curran biography
  2. ARIN Organization Structure & Staff
  3. Board of Trustees Meeting Minutes — 16 January 2019
  4. Richard Jimmerson, “Operations at ARIN: New Blog Series and Recent Outage Information,” 19 March 2020
  5. Board of Trustees Meeting Minutes — 22–23 January 2020
  6. Board of Trustees Meeting Minutes — 25 March 2020
  7. Board of Trustees Meeting Minutes — 21 May 2020
  8. Meeting of the ARIN Board of Trustees — 3 February 2021
  9. ARIN, “New ARIN Service Status Page Available,” 5 April 2021
  10. Meeting of the ARIN Board of Trustees — 4 August 2022
  11. ARIN 2025 Annual Report
  12. 本人確認のための視覚資料のみ：ARIN公式のJohn Curran写真。AI生成エディトリアル・ポートレートの本人確認にのみ使用し、運用上の事実を裏付ける証拠ではない。