要約

  • Akamaiは11時21分UTC、外部サービス事業者がインドでEdge Deliveryの問題を引き起こしていると発表した。19分05.300秒後、追加調査から外部事業者が原因ではないようだと訂正した。
  • 15時47分に修正を実施してコンポーネントを稼働状態へ戻したが、インシデント全体は監視中で、原因と解決時刻は公表されていなかった。

コンポーネントが「稼働中」に戻ることと、インシデントが「解決済み」になることは同じではない。Akamaiが8月22日に公開した記録は、その違いを明瞭に示している。最終更新ではEdge Deliveryコンポーネントが正常化した一方、インシデントの上位状態は監視中のままで、解決時刻も空欄だった。

さらに、その前には原因に関する重要な修正があった。11時21分42秒UTCの初報で、Akamaiは外部サービス事業者に伴う問題がインドのEdge Deliveryに影響しているとし、同社と連携中だと説明した。11時40分47秒には、追加調査の結果、外部サービス事業者が原因ではないようだと発表した。

2件の更新の間は19分05.300秒である。これは当初の帰属が調査中の仮説だったことを示すが、Akamai内部に原因があったことまでは示さない。最初の説明が意図的に誤っていたとも言えない。代わる原因は、その後の公開更新にも現れなかった。

12時25分、13時16分、14時00分、15時00分の更新はいずれも調査の継続を伝えた。15時47分01秒、Akamaiは修正を実施し、現在の観測ではサービスが通常運用へ戻りつつあると説明した。影響が完全に軽減されたことを確かめるため、監視を続けるとも述べた。

ここには四つの異なる判断がある。コンポーネントの状態は稼働中、事業者の観測は復旧傾向、インシデントの状態は監視中、顧客アプリケーションの回復は公開資料では未計測である。キュー、再試行、セッション、オリジン負荷がいつ平常化したかは、顧客側で別に確認する必要がある。

記録上の開始時刻11時21分42.110秒から監視移行15時47分01.891秒までは4時間25分19.781秒だった。これは開始から監視までの経過時間であり、全顧客が同じ障害を連続して受けた時間ではない。顧客数、リクエスト数、エラー率、遅延分布、トラフィック比率は公開されていない。

地理的な範囲も拡大してはならない。インシデント名は「Edge Delivery Issues in India」だが、都市、州、都市圏、PoP、エッジクラスター、ASN、プレフィックスは示されていない。インドの全ネットワークや全利用者への障害という根拠はない。

Akamaiの一般文書は、観測できる層を整理するために使える。通常、顧客はプロパティのホスト名をCNAMEでAkamaiのエッジホスト名に対応付ける。マッピングシステムがエッジサーバーのアドレスを返し、エッジはキャッシュから応答するか、必要に応じて顧客のクラウドまたは物理オリジンへ接続する。

したがって、顧客DNS、Akamaiのマッピング、クライアントからエッジまでの処理、プロパティ設定、キャッシュ、エッジからオリジンまでの取得が別々の観測面になる。ただし、文書は今回どの層が故障したかを示していない。製品の一般構造で非公開の原因を補うことはできない。

運用上重要なのは、状態の変化だけでなく帰属の変化も時刻付きで保存することだ。利用者側のエラー、DNS応答、エッジ情報、設定変更、キャッシュ状態、オリジン接続とアプリケーション指標を残せば、最初の仮説と訂正のどちらが自社の症状に合うかを検証できる。

逆に、初報だけで別の供給者へ原因を固定すると、不要な経路変更や設定変更を招く。訂正後も古いエスカレーションを続ければ、公開情報と現場判断が分離する。新しい説明がない時こそ、原因の空白を認めて観測対象を広く保つ必要がある。

公開記録から確定できる範囲は限定的だ。Akamaiはインドで軽微なEdge Delivery性能低下を記録し、外部事業者への初期帰属を撤回し、内容非公開の修正を行って監視へ移った。原因と正式な解決は公表されていない。コンポーネントの緑色表示は、その不足を埋める証拠ではない。

情報源