要約

  • DigitalOceanは、Cloud Control PanelとAPIからManaged Databasesクラスターを作成する際にエラーが発生する可能性を報告した。既存データベース全体の停止とは説明していない。
  • 記録上、開始から監視入りまで6時間18分57.959秒、解決まで9時間21分54.719秒を要した。11時30分の「作成可能」は、新規クラスターが直ちにonlineになったことを意味しない。

復旧通知は、どの操作がどこまで戻ったのかを分解して読む必要がある。DigitalOceanの「Managed Databases Creation」事象では、11時30分34秒UTCの更新で、利用者は新しいクラスターを作成できるようになったとされた。しかし、作成要求が通ることと、完成したデータベースがすぐにトラフィックを受けられることは別である。

事象は8月23日05時11分37秒に始まった。DigitalOceanはManaged Database製品の問題を調査中で、Cloud Control PanelとAPI要求の双方でクラスター作成時にエラーが起こり得ると説明した。Managed Databases - Globalコンポーネントはoperationalからdegraded_performanceに変更された。

07時06分56秒の更新では、影響が複数リージョンに及ぶとされた。エンジニアは通常のプロビジョニングを戻すための緩和策を実施中だった。ただし、失敗した要求の割合、対象顧客数、二つの入口が同じ形で失敗したかどうかは公開されていない。

11時30分34秒、DigitalOceanはNYC3とNYC1でManaged Databaseクラスター作成に影響した修正を実施したと発表した。利用者は新規クラスターを作成できるはずだとして、安定性の監視に移行した。14時33分31秒には、両リージョンで作成を妨げていた問題が解消したとして事象をresolvedにした。

公開記録の開始から監視入りまでは6時間18分57.959秒である。監視は3時間02分56.760秒続き、開始から解決までは9時間21分54.719秒となる。この精密な時刻は、全顧客が同じ長さだけ連続して影響を受けたことを証明しない。要求数や顧客数の分母は示されていない。

地域の表現も途中で変化した。最初はGlobalコンポーネント、次に複数リージョン、最後の二つの更新ではNYC1とNYC3が名指しされた。調査で範囲が絞られたのか、他リージョンが先に回復したのか、初期コンポーネントが単に広い分類だったのかは不明である。

DigitalOceanの一般的な製品資料は、作成操作の段階を理解する助けになる。クラスターはコントロールパネル、doctl、APIから作成できる。APIではPOST /v2/databasesを使い、エンジン、リージョン、サイズなどを指定する。

要求が受理されても、処理はそこで終わらない。DigitalOceanのPythonクライアント資料では、新しいデータベースリソースは最初にcreatingとなり、トラフィックを受けられるようになってからonlineへ変わる。PostgreSQLの作成案内では、通常のプロビジョニングに5分以上かかるとされる。

したがって、監視入りの更新には限界がある。11時30分以降に作成要求が通っても、各クラスターは通常の非同期処理を経る。要求受理、リソース出現、creatingの終了、online到達、実際の接続成功を一つの瞬間に圧縮してはならない。

既存クラスターの状態は、さらに別の観測対象である。公開更新は新規作成を一貫して問題として挙げ、クエリー、データ耐久性、バックアップ、複製、フェイルオーバーの停止を報告しなかった。だからといって、全ての既存クラスターが無影響だったと個別に保証されたわけでもない。

この差は、拡張や復旧を計画する現場で重要になる。現在のアプリケーションが正常でも、増設用、分離用、別リージョン用、復旧用の次のクラスターを作れなければ、運用上の選択肢は減る。データ面が動いていることは、変更を実行できる制御面の健全性を保証しない。

コンポーネント表示にも同じ注意が必要だ。最後の更新に記録されたNYC1とNYC3の行は、operationalからoperationalのままだった。一方、本文は作成機能への修正と解決を報告している。緑色の集約表示だけでは、特定の制御面取引の失敗を捉えられない。

根本原因は公開されていない。要求検証、スケジューラー、容量、ネットワーク、ストレージ、データベースエンジン、APIゲートウェイ、オーケストレーションのどこが失敗したかは分からない。通常の作成手順を説明する資料から、今回の内部障害点を推定することはできない。

運用記録では、復旧時刻を一つだけ置くのではなく、操作ごとに残すべきである。最初に成功した作成要求、そのリソースが現れた時刻、onlineへの遷移、初回接続、既存クラスターの平常化はそれぞれ異なる証拠になる。公開状態と顧客側の状態を並べれば、回復の遅れも過剰な推測も避けられる。

今回の事象は公開上解決した。結論は「DigitalOceanの全データベースが9時間停止した」ではない。新規作成という制御面の機能が損なわれ、復旧後も通常のプロビジョニング時間を経て初めて利用可能になった、という限定された事実である。

情報源