古き良き人類にとって、もう一つの出来事が起きた。Google は、2018 年 1 月 18 日にクラウドの us-central1 ゾーンと europe-west3 ゾーンで Compute Engine が 93 分間停止した原因は自動化の障害であったと認めた。
Googleは今回の障害を「ネットワークプログラミングの障害」と分類し、その結果オートスケーラーが機能しなかったと説明しました。このソフトウェアの障害により、新規または新規に移行したVMは他のゾーンのVMと通信できなくなりました。
クラウド競合企業は、この障害について「新規作成および移行されたVMのGoogle Compute Engineネットワーク構成の伝播は、2つのコンポーネントによって処理されます。1つ目は、VM、ネットワーク、ファイアウォールルール、スケーリング決定の完全なリストを提供する役割を担っています」と説明しています。
「2 番目のコンポーネントは、特定のゾーン内のコンポーネントの更新ストリームを提供します。」
GoogleはDB構成の変更ミスで再び自社のクラウドを破壊した
続きを読む
障害発生中、最初のコンポーネントはデータを送信しませんでした。この情報不足により、他のゾーンのVMは他のVMとどのように連絡を取るべきか分からず、Autoscalerも最初のリソースからの情報フローを必要としていたため、停止してしまいました。
では、なぜ最初のコンポーネントが失敗したのでしょうか？Googleはこの問題を「プロセスがスタックし、更新を送信できなかった」と説明しています。言い換えれば、古き良きプロセスハングです。
「自動フェイルオーバーではプロセスを強制的に停止できず、通常の操作を復元するには手動フェイルオーバーが必要でした。」という点を除けば、通常は問題にはなりません。
はい、その通りです。自動化が失敗し、人間がそれを解決したのです。
Google の表現を借りれば、「ネットワーク構成情報の伝播が停止したため、エンジニアリングチームは警告を受けました。彼らは手動で代替タスクにフェイルオーバーし、データ永続化レイヤーの正常な動作を回復しました。」
Google は、将来的には「構成データが古い場合は VM の移行を停止する」ことと、「データ永続化レイヤーが長時間実行プロセス中にピアを再解決し、代替タスクへのフェイルオーバーを可能にする」ことを約束しました。
自動的に、音から判断して。だから、人間よ、あまりうぬぼれないで。®
