GitLab.com、18時間に及ぶサービス停止の根本原因を事後検証

被害が終わって空気がきれいになり始めた後、GitLabは、18時間に及んだサイト停止の原因と今後の対応計画、問題発生の全容を統括する資料を公開した。

データベースの高負荷状態は、当初、スパムの 流入によるものと判断された。しかしながら、さらに調査した結果、GitLab社員の乱用(abuse)を報告するトロール(troll)が事態を悪化させたことが明らかになった。それによってフラグの付けられたアカウントが、乱用の報告がチームのエンジニアを対象としたものと気付いていなかった別の社員によって、誤って削除されてしまったのだ。

後になって私たちは、問題となった負荷の一部が、そのGitLab社員と、関連するデータを削除しようとしたバックグラウンドジョブによって引き起こされたものであることを知りました。これは、そのアカウントに乱用というフラグが付けられた結果、削除対象として誤ってスケジュールされてしまったためです。

影響を受けたエンジニアのバグレポートには、自身のアカウントが削除された理由として、“スパム報告が作成される10分前にユーザからのスパム報告を受け取ったため、人為的エラーによって私の全プロジェクトが削除されたのです。”と述べられている。

データベース負荷の上昇により、先行書き込みログ(Write Ahead Log/WAL)セグメントが二次側の処理する前に一次側で削除されたため、一次側から二次側へのレプリケーションが停止した。運の悪いことに、WALアーカイブ – 削除が許可される前にセグメントがアーカイブされることを要求する – はオンになっていなかった。

レプリケーションが停止したため、二次側では再構築が必要になった。レプリケーションを開始するには空のデータディレクトリが必要なため、あるエンジニアが手作業でそれを行なった。その時、二次側のデータディレクトリだけでなく、誤って一次側のデータディレクトリも削除してしまったのだ。

一次データベースを不幸にして失ったのであれば、サイトのダウンはごく短期間で済むはずなのだが、GitLabチームにとって、事態はさらに悪い方向に進んだ。データを復元しようとした時、バックアップが動作していなかったことが分かったのだ。バックアップの中心的手段であったpg_dumpは、実は何もバックアップしていなかった。バージョンの不一致によってフェールしていたのだ。通知のEメールは、DMARCをサポートしていない受信サーバによってブロックされていたため、誰もそのことを知らなかった。

その他のバックアップ方法も、さまざまな理由によって利用できなかった。例えば同チームでは、Azureディスクスナップショットをデータベースには使用していなかった。もし使用していたとしても、データをオンラインに復帰させるための時間は、逆に長くなっていたかも知れない。

各ストレージのアカウントには約30TBという制限があります。同じストレージアカウントのホストを使用してスナップショットを復元する場合、処理は通常、非常に短時間で完了します。その一方で、異なるストレージアカウントのホストを使用する場合には、完了まで数日とはいかなくても、数時間を要することがあります。

残された手段は、障害が発生する6時間前に取得したLVMのスナップショットからの復元だった。

チームはリカバリ手順の修正と改善を行なうために14の問題点を打ち出し、現在はその対処を進めている。障害から２週間、彼らはすでにWAL-Eの導入を完了して、WALセグメントのAWS S3へのリアルタイムアーカイブを実現している。この形式でのバックアップからの復元テストでは、ポイント・イン・タイムのリストア実行を２時間以内で完了した。さらに、PostgreSQLバックアップのリカバリを自動テストするシステムにも取り組んでいる。