要約

  • 障害記録は8月8日18時57分49秒UTCに始まり、9日01時01分02秒に解決した。最初の通知から全面復旧まで6時間3分13秒だった。
  • アカウント登録、Droplet作成、Reserved IP、バックアップとスナップショット、オートスケール、DOKS、GenAI、Droplet Console、データベースクラスター作成が複数地域で影響を受けた。
  • DigitalOceanは20時02分35秒に根本原因を特定したとしたが、その内容は公開しなかった。22時02分55秒には修正の実装・展開中と説明した。
  • 00時31分29秒に監視へ移り、29分33秒後に全面復旧を宣言した。
  • 根拠が示すのは作成・割り当て・拡張など制御面の障害であり、全Droplet、既存通信、保存データ、既存DB問い合わせの一律停止ではない。
  • 対象地域名、顧客数・比率、エラー率、滞留処理、SLA、補償、恒久対策は公表されていない。

弾力性は保有量ではなく、変更できる余地で決まる

クラウドの余力は、空いているCPUだけでは測れない。需要が増えたときに新しいDropletを作れるか、故障したノードを入れ替えられるか、変更前にスナップショットを取得できるか。今回の障害は、そうした次の一手に集中した。

既存のサービスが表面上動いていても、拡張操作が失敗すれば余裕は時間とともに失われる。データベースクラスターが「Creating」のままなら復旧計画が進まない。Reserved IPを割り当てられなければ切り替え手順が止まる。影響は障害発生と同時に全面化するとは限らず、顧客が変更を必要とした瞬間に顕在化する。

ステータス記録は、全顧客の全操作が失敗したとは述べていない。したがって全面停止とは呼べない。しかし「既存資源が残ったから軽微」とも言えない。変更権限の可用性は、現在の稼働状態とは別に評価すべきである。

公開時系列は復旧の段階を分けている

18時57分49秒の最初の通知では、登録、Reserved IP、スナップショット、DropletとDroplet系サービスが挙げられた。19時38分23秒にはGenAI、コンソール、作成中で止まるデータベースクラスターが追加された。

開始から1時間4分46秒後の20時02分35秒、DigitalOceanは根本原因を特定したと発表した。ただし原因そのものは書いていない。22時02分55秒には修正を実装し段階的に展開中とし、従来の障害がまだ続く可能性を認めた。

00時31分29秒、顧客は列挙されたエラーを経験しないはずだとして監視段階に入った。そこから29分33秒後に解決した。原因特定、修正展開、監視、解決は別の状態であり、最後の緑表示だけでは途中の不確実性を表せない。

広い症状は共通依存を示唆するが、内部設計までは示さない

公式コンポーネント履歴ではDroplets Global、Kubernetes Global、Managed Databases Global、Reserved IPが劣化状態になった。文章では登録、バックアップ、スナップショット、オートスケール、GenAI、コンソールも対象となった。

これだけ異なる操作が同時に影響を受ければ、共通のプロビジョニングまたは制御機能があったと考えるのは自然だ。ただし、これは症状からの分析である。DigitalOceanは、認証、キュー、内部DB、証明書、ネットワーク、特定地域、ソフトウェア変更のどれが原因かを公表していない。

製品資料は利用者側の接続関係を説明する。DOKSはマネージド制御プレーンを持ち、Droplet、ボリューム、APIなどと連携する。Droplet APIには作成、イメージ、バックアップ、スナップショット、オートスケールプールが含まれる。だが、資料上の連携を事故原因に置き換えることはできない。

制御面の障害とデータ面の障害は混同できない

公式説明の中心は、作成、割り当て、バックアップ処理、拡張、クラスター操作、コンソール接続である。稼働中のDropletが一斉停止した、既存のパケット転送が止まった、データが消失した、既存DBの読み取りが全面的に失敗したとは記載されていない。

この区別は被害を小さく見せるためではない。オートスケールの失敗は、数十分後の負荷超過につながり得る。作成できないDBは復旧を遅らせる。コンソールに入れなければ、別の経路を持たない小規模運用者は対応を失う。

それでも、これらは具体的な操作失敗であり、クラウド全体の停止とは違う。顧客は障害時間内に実行した変更を抽出し、それぞれが完了、失敗、取消し、不明のどれかを確認する必要がある。

バックアップは保険であると同時にクラウド操作でもある

Automated BackupsとSnapshotsは、最初から最後まで影響範囲に入っていた。復旧用データは本番処理と別物に見えるが、その作成命令と進捗管理は同じプロバイダーに依存する。

既存バックアップの破損や消失は報告されていない。報告されたのは操作の失敗可能性である。確認すべきは、要求が受理されたか、処理が完了したか、成果物から復元できるかの三段階だ。現在のステータスが正常でも、過去のジョブが成功した証明にはならない。

DigitalOceanは失敗件数も、滞留した作業を自動再実行したかも説明していない。再送前にはAPI履歴と実際の資源を照合し、重複や未完了状態を避ける必要がある。

小規模利用者ほど「作って直す」に依存する

大企業は予備容量や複数クラウド、専任の障害対応者を持てる。小規模事業者は必要なときに資源を追加することで固定費を抑える。つまり、余力を事前保有せず、プロビジョニングの約束として保有している。

その約束が止まると、待機、再試行、手作業の確認に人員が奪われる。さらに、DigitalOcean側とは別に始まった顧客障害の復旧を妨げる可能性がある。元の原因がアプリにあっても、代替Dropletを作れなければ停止時間は伸びる。

顧客数、企業規模、損失額は不明であり、総経済損失は計算できない。「minor」は提供者の分類であって影響の分母ではない。クレジットやSLA判定も開示されていない。

解決後に残るのは状態の照合作業だ

最終更新は全対象サービスの全面復旧を確認し、問題が続く場合はサポートチケットを開くよう案内した。公開障害は閉じたが、6時間の間に送られた各要求の結末までは示していない。

明確に失敗した処理、実行中のまま残った処理、自動再試行された処理、顧客対応が必要な処理を分ける情報がない。地域名もないため、複数地域構成のどこが同時に影響したかを判断できない。根本原因と恒久対策がなければ、修正の耐久性も評価できない。

必要な事後説明は、原因、範囲、修正、照合、再発防止を別々に示すものだ。顧客が要求した状態と実際の状態を一致させられることが、単なる復旧宣言を保証へ変える。

今できる監査は時刻から始まる

対象時間は18時57分49秒から翌01時01分02秒UTCまで。登録、Droplet作成、Reserved IP、オートスケールイベント、DOKS操作、バックアップ、スナップショット、コンソールアクセス、DBクラスター作成の履歴を調べる。各要求に最終状態を付けることが先決だ。

DigitalOceanから次に必要なのは、地域別・操作別の分母、滞留処理の扱い、根本原因、恒久修正である。同じ製品群で再発すれば共通依存への懸念は強まるが、今回だけで8月6日の書き込み経路障害との同一原因を証明することはできない。

今回の教訓は、クラウドの可用性を「今動いているか」だけで測れないことだ。次を作れるか、壊れたものを交換できるか、回復点を新たに保存できるか。その制御もまた、冗長化と検証の対象である。

情報源