• Azure Databricks は9月5日、米国中部で別個の2件の障害を報告し、いずれもコンピュートの起動とジョブに影響した
  • 両障害は解消されたが、入手可能なステータス報告からは、原因が同じだったとは確認できない

事実

Azure Databricks は9月5日、米国中部リージョンで別個の2件のサービス障害を報告した。最初の障害 ES-2194668 は、Classic Compute、Declarative Pipelines、Jobs に影響した。報告された問題には、クラスターの起動失敗、Pending または Starting 状態のままになったクラスター、ノートブックの接続失敗、失敗した、または遅延が続いたジョブやパイプラインが含まれていた。ステータス追跡では、この障害が2時間を超えて記録された。

その後、2件目の障害 ES-2195009 が米国中部の Compute と Unity Catalog に影響した。顧客は再び、クラスターの起動失敗、ノートブックの接続エラー、コンピュートの起動中に失敗した、または処理が進まなくなったジョブに直面した。この障害は1時間以内に解消された。報告には、2件の障害の根本原因が同じだったとは記されていない。両障害は別々に解消されており、単一の継続的な停止ではなく、別個の2件のサービス事象として扱うべきである。

評価

両障害では、Databricks が計算リソースを提供する段階で作業が止まった。顧客のデータ、コード、ノートブックがそのまま残っている可能性はあっても、クラスターが Pending または Starting のままであれば、スケジュール済みジョブは実行できない。このため、クラスター起動は、単にプラットフォーム上にデータが保存されていることとは別の依存要素となる。

短時間の中断なら、ジョブの再試行で足りる場合もある。期限のあるワークロードがリージョン内の計算リソースの復旧を待てない場合は、別の計画が必要になる。別の環境で実行する手段を事前に検証しておくことや、起動が遅れた後でも再開できるようジョブを設計することが考えられる。2件の障害に共通の原因があるとは示されていないため、1つの技術的な修正で両方に対応できるとはまだ想定できない。BTW の読者にとって重要なのは、管理型の計算リソースを利用するチームが、どのジョブなら待てて、どのジョブは待てないかを把握することだ。その判断によって、単純な再試行で足りるのか、別のリージョンを事前に準備する必要があるのかが決まる。

今後の注目点

ES-2194668 と ES-2195009 それぞれの根本原因に関する情報、米国中部での追加のコンピュート障害、再試行やリージョン復旧に関する Databricks の指針を注視すべきだ。顧客にとって有用な証拠となるのは、重要なジョブが中断後に問題なく再開できるか、またはコンピュートを起動できない状態が続く場合に別のリージョンへ移せるかどうかである。