要約

  • AFRINIC は2026年2月19日、数か月にわたる継続的なトラフィックがモーリシャスのデータセンターの接続容量を上回り、一部のオンラインサービスと内部サポート業務が遅くなっていると公表した。
  • 帯域増強は承認済みで実施中だったが、告知には対象サービスの全体、基準性能、目標容量、稼働開始時刻、観測期間、受入れ結果が記載されていない。
  • AFRINIC のサービスレベル・コミットメントは、サーバーの可用性、問い合わせへの初回応答、問題の完全解決を別々の尺度としている。
  • 機密性を保つ容量―サービス受入れ記録があれば、構成図や会員案件を公開せずに、増強とサービス回復の関係を検証できる。

遅延は、停止より見えにくい。サーバーは電源が入り、監視上はインターネットに接続されている。利用者も最終的には画面を開ける。しかし、一つの処理を終えるまでの時間が延び、内部の担当者も同じ道具を待つ。その状態を可用か不可用かの二択に押し込むと、起きている変化の中心が失われる。

AFRINIC の2026年2月19日付「一時的なサービス遅延に関する告知」は、その中間状態を明示した。告知によれば、過去数か月の継続的なネットワーク・トラフィックが、モーリシャスのデータセンターにある当時の接続容量を上回った。いくつかのオンラインサービスは通常より遅く応答する可能性があり、内部サポートの効率にも影響したため、会員からの問い合わせやサービス依頼への応答が通常の基準より長くなる場合があった。

対策も書かれている。帯域増強はすでに承認され、サービス事業者と実施を進めていた。AFRINIC は、これにより容量が大幅に増え、通常のサービス性能が回復すると説明した。

ここまでは、原因として示された制約、利用者側の症状、組織の判断、期待する結果が一つの文書に並んでいる。だが、その後を閉じる公開記録は、今回確認した資料からは再構成できない。どのサービスが受入れ対象だったのか。変更前の容量や遅延はどの程度だったのか。何を目標として承認したのか。新しい経路はいつ稼働し、どの負荷でどれだけ観測したのか。誰が回復を受け入れたのか。告知はそこまで扱っていない。

この不足から、増強が失敗した、遅れた、あるいは現在も性能が低いとは言えない。内部には測定値や変更記録が存在するかもしれない。公開資料が証明するのは、実施中までであり、公開資料だけでは受入れまでの接続が見えないという点である。

可用性の内側にある性能低下

AFRINIC のサービスレベル・コミットメントは、2015年11月の第1版で、各サービスとネットワークに99.8％の可用性を掲げる。可用性は、サーバーが物理的に電源オンの状態にあり、稼働中のサービスへインターネット接続を持つ時間の割合と定義されている。計画保守、第三者サービスの停止、エンドユーザー側の接続問題、不可抗力は計算から除かれる。

これは重要な継続性の基準である。電源と接続がなければ、オンラインのレジストリ機能は動かない。ただし、この定義は応答速度を測っていない。ページの表示に時間がかかっても、サーバーが接続を保っていれば、字義どおりの可用性条件は満たし得る。2月の告知が「停止」ではなく「通常より遅い応答」と書いたことが、その差を具体化している。

同じ文書は、問い合わせの時間も二つに分ける。すべての問い合わせに2営業日以内の実効的な応答を行うとし、応答時間を問題にどれだけ早く反応するか、解決時間を問題の記録から完全解決までの期間と定義する。

最初の返答が届いても、案件は未解決であり得る。案件が解決しても、その間に使われた全サービスが同時に正常化したとは限らない。サーバーが接続されていても、取引処理が速いとは限らない。

尺度 実際に確認する状態 単独では確認できない状態
サービス／ネットワーク可用性 除外条件を踏まえ、サーバーが電源と接続を維持したか 容量逼迫やサービス遅延が解消したか
初回応答 問い合わせや問題に最初に反応するまでの時間 問題が完全に解決したか
解決時間 記録から完全解決までの時間 初回応答が適時だったか、システム性能が回復したか

帯域を増やした後も、三つの尺度は別々に動く。オンライン処理はすぐ速くなっても、蓄積したサポート案件の解消には時間がかかる。初回応答だけは期限内でも、複雑な案件は長く開いたままになる。反対に、回線は契約どおり増強されても、別のアプリケーション依存が一つのサービスを遅くする場合がある。

受入れとは、これらを無理に一つの点数へまとめることではない。どの結論がどの観測から生まれたかを残すことである。

増強には二つの「後」がある

承認の後に実装があり、実装の後に受入れがある。さらに実装の中にも、事業者による引き渡し、設定、稼働経路への投入がある。受入れの中には、観測窓の設定、代表的な負荷、サービス別の判定、例外、修正がある。

2月時点の表現は「承認済み、実施中」である。これは調達や変更の権限が動き、作業が始まっていることを示す。新容量がすでに本番経路で使われた日や、性能確認が終わった日を示すものではない。一方で、日付が公表されていないから未実施だと推測することもできない。

元の制約が数か月の継続的なトラフィックだった以上、静かな一瞬だけで増強を受け入れるのは不十分である。ピークを含む比較可能な期間、または元の負荷を代表できる試験が要る。ネットワーク全体の平均だけでなく、影響を受けたサービスの種類ごとに結果を見る必要もある。

公開版の受入れ記録は、内部の技術報告よりずっと小さくてよい。正確な回線容量、構成、価格、会員の利用記録は保護できる。公開するのは、サービス区分、性能帯、観測期間、結果の状態に限定できる。

受入れ記録の要素 残すべき意味
告知と変更の識別子 2月の制約に対する正しい増強を特定する
対象サービス区分と劣化期間 「通常性能」の対象と起点を決める
保護された基準値と承認目標 変更前の状態と権限の内容を分ける
事業者の引き渡しと稼働時刻 承認と実際の経路変更を分ける
代表負荷と観測窓 原因となった条件に近い形で確認する
区分別の遅延、エラー、可用性 接続の維持と性能回復を混同しない
初回応答と解決 サポートの二つの時間を独立に保つ
例外、判定者、修正履歴 一部受入れ、監視継続、ロールバックを消さずに記録する

結果は、成功か失敗かだけでなく、「稼働、測定中」「一部受入れ」「受入れ完了」「修正後に再測定」でもよい。一つのアプリケーションが別のボトルネックを持つなら、その例外を記録すれば、回線増強の成果も会員が経験する遅延も正しく扱える。

ステータス表示は出口であって根拠ではない

AFRINIC の公開ステータスには、状態を時間とともに進める仕組みがある。2月とは別で、因果関係も確認されていない4月の権威 DNS サービス低下の通知は、調査中の状態から更新を重ね、明示的な解決状態に至った。この例が示すのは、公開面が経過と終了を表示できるということだけである。2月の容量問題の完了証明にはならない。

今回取得したステータス履歴では、2026年の1月、4月、6月のアーカイブが見えた一方、確認した応答には2月の項目がなかった。しかし、その表示から内部記録がない、過去に別の公開項目がなかった、増強が完了しなかった、とは結論できない。取得した公開画面の範囲にすぎない。

また、Resolvedというラベルだけでも足りない。DNS の問題と容量の問題では確認方法が違う。容量であれば、稼働時刻、代表負荷、サービス結果との接続が必要である。ステータス画面は結論を届ける場所であり、受入れ記録は結論を支える材料である。

資料が答えていないこと

旧容量、新容量、事業者、稼働開始、測定期間、現在の性能は、公表資料からは分からない。すべてのサービスが同時に回復したか、段階的な受入れがあったか、後から調整したかも分からない。

サービスレベル違反も証明されていない。通常基準より応答が長くなる可能性という告知は、特定の会員案件が2営業日を超えた証拠ではない。遅さは、定義上の可用性を失った証拠でもない。公開の受入れ結果が見えないことは、増強の失敗を意味しない。

確認できるのは、もっと限定された構造である。AFRINIC は性能低下を公表し、容量増強を決め、通常性能の回復を目標にした。既存の約束は可用性、応答、解決を分けている。終了の記録も、この違いを維持しなければならない。

回線が太くなったことと、サービスが戻ったことは、異なる文である。受入れは、その二つの文を同じ証拠の中でつなぐ。

情報源