- Tarsnap の中央サーバーが Amazon EC2 us-east-1 で
failed system status check により停止し、サービスは 2023-07-02 13:07:58 UTC ごろから約 26時間16分 中断した
- 障害は 13:10 UTC に検知されたが、予期しない再起動の後は人が直接点検するまでサーバーコードの自動起動を無効にしておく運用方針が適用されていた
- 復旧は Amazon S3 上のログ構造ファイルシステムから メタデータヘッダー を読み取り、ローカルで処理を順番に再生する方法で進められ、最初の段階は 2023-07-03 01:49:49 UTC に完了した
- 状態再構築の過程で、2014年に書かれた machine re-owned 処理の未検証ケースと、再開ロジックの初期化漏れが明らかになり、ディスクスループット制限も復旧を遅らせた
- Tarsnap には明確な SLA はないが、公正と判断される障害にはクレジットを付与する方針に基づき、2023-07-13 にすべてのアカウントへ1か月分のストレージ料金の 50% クレジット が付与された
障害発生と初期対応
- 2023-07-02 13:07:58 UTC ごろ、Tarsnap の中央サーバーが Amazon EC2 us-east-1 リージョンでオフラインになった
- EC2 の状態は
failed system status check だった
- 仮想マシンでこの状態は、停電、物理サーバーのハードウェア障害、EC2 ネットワーク障害など複数の原因を示しうる
- 同時刻に広範な EC2 障害報告は見当たらず、孤立したハードウェア障害の可能性が最も高いと見られた
- 監視は 2023-07-02 13:10 UTC に障害を検知した
- 別の EC2 リージョンから5分ごとにアーカイブの書き込み、読み出し、削除を実行する方式で監視していた
- 13:10 UTC のSMS通知では起きられなかったが、13:15 UTC の電話通知で対応が始まった
- 初期調査では明確な一時的エラーが見当たらず、システムが停止したと判断して代替 EC2 インスタンスの準備に入った
自動再起動を避けた運用方針
- 2023-07-02 13:52 UTC ごろ、Amazon が障害サーバーを新しい EC2 インスタンス上で再起動した
- 障害開始から約45分後だった
- オペレーティングシステムである FreeBSD は起動したが、Tarsnap サーバーコードは自動では起動しなかった
- 自動起動を無効にしていた理由は、予期しない再起動の後、トラフィックを受ける前に状態を人手で確認するためだった
- 運用方針として「何かが壊れたときにデータ損失を防ぐこと」が「サービス可用性を最大化すること」より重要とされている
- 再起動後のサーバーログには ファイルシステム破損 が記録されていた
- 障害原因はハードウェアを停止させたか、ファイルシステムを載せた Elastic Block Store とサーバーの接続を切断したものと考えられた
- 既存サーバーの復旧ではなく、新しいサーバーの設定を続行することにした
S3 ログ構造と復旧手順
- Tarsnap サービスはデータを Amazon S3 に ログ構造ファイルシステム として保存している
- 各 S3 オブジェクトは、すべてのログ項目のメタデータを含むヘッダーと、必要に応じてログ項目データを含む
start write transaction ログ項目は、マシンとトランザクション nonce を識別するヘッダーだけを持ち、ログデータはないstore data block ログ項目は、マシンとブロック名を識別するヘッダーとブロックデータをあわせて持つ
- 正常時にはログ項目メタデータは EC2 にキャッシュされ、Amazon S3 から再読込はしない
- Amazon S3 の読み取りは、tarsnap クライアントの要求に応答してブロックデータを読むときにのみ発生する
- EC2 インスタンスの状態復旧は2段階に分かれる
- まず S3 からすべての メタデータヘッダー を読む
- その後、すべての処理をローカルで 再生(replay) する
- ログ構造ストレージでは、データ削除時に保存領域を確保するためログ項目が再書き込みされるので、2段階を同時に実行することはできない
- ログ項目には順序番号があり、正しい順序で再生できるが、取得後にまずソートする必要がある
復旧中に明らかになった欠陥とボトルネック
- 最初の段階は問題なく進み、2023-07-03 01:49:49 UTC に完了した
- 復旧プロセスは Amazon S3 に同時リクエスト 250 件を送る設定になっていた
- この値は10年前の Amazon S3 が処理できた水準に合わせた設定で、現在なら大幅に増やせた可能性がある
- 2番目の段階はほぼ直ちに失敗した
- 再生されたログ項目が存在しないマシンに属するデータを記録しているというエラーが発生した
- 原因は 2014 年に書かれたマシンのアカウント移動処理コードだった
- Tarsnap ユーザーがマシンをアカウント間で移動する必要がある場合、新しい
machine registration ログ項目を保存し、以前の項目を削除する方式が使われていた
- テストはあったが、データが保存された状態でマシンが re-owned された後にサーバー状態を再構築するケースは漏れていた
- 新しいマシン登録ログ項目の順序番号がより大きいため、再生過程では、まだ存在しないマシンにデータが保存されたように見えてしまった
- 原因を特定した後、その「seatbelt」を無効化して状態再構築を再開した
- その直後、Amazon S3 でデータを見つけられないというエラーが発生した
- 再開時の試行で S3 データダウンロード段階をスキップした際、
maximum log entry sequence number の値が初期化されず 0 のまま残っていたためだった
- この問題を修正した後、状態再構築は正常に続行された
- 状態再構築は必要以上に遅く進んだ
- ディスクスループットがボトルネックだとわかっていれば、関連する EBS ボリュームのスループットをより高く設定できたはずだった
- 睡眠不足のためプロセスを綿密に監視できず、そうでなければ gstat(8) と Amazon CloudWatch でボトルネックを確認し、EBS ボリュームを再設定できたはずだった
サービス再開とクレジット付与
- 2023-07-03 15:10 UTC ごろ、状態再構築プロセスが完了した
- 正確な完了時刻は記録されていない
- サーバーを読み取り専用モードにして簡単なテストを実施した
- 既存サーバー状態と比較し、障害時点で既存サーバーのファイルシステムが失った最後の数秒分のデータを除いて一致することを確認した
- 障害後最初の実サービストラフィックは 2023-07-03 15:25:58 UTC に発生した
- 障害開始から約 26時間16分 が経過した時点だった
- Tarsnap には明確な SLA はないが、公正と思われる障害にはクレジットを提供する方針を適用している
- 2023-07-13 にすべての Tarsnap アカウントへ1か月分のストレージ料金の 50% をクレジットとして付与した
- 障害対応と休息の後にクレジット処理が行われた
1件のコメント
Hacker News の意見
この記事が HN のトップに上がるとは本当に思っていなかった。質問に答えたいが、今は夜10時で、子どもが午後5時に寝てしまったので、運がよければ子どもが起きるまでに4時間ほど眠れそう
朝にまた確認して質問に答える
SLA がないと明確に述べているのはよいが、自分のバックアップと自分との間に大きなリスクが挟まっているように感じる
https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch...を読んで、ある程度効果が出ている。図書館、つまり本のための Blockbuster みたいな場所ならどこでも手に入る
ここ数週間で、私もいくつかの EC2 インスタンスが EBS から切断されたような症状で落ちており、私の場合は eu-west だった
「Tarsnap には SLA はないが、公正に見える場合は障害に対してクレジットを付与する」という曖昧なポリシーに基づき、2023-07-13 に全員の Tarsnap アカウントへ1か月分のストレージ費用の50%を付与した、という部分は Percival がどんな人物かをよく示している
このクレジットは顧客を十分に補償する方向にかなり寛大に見えるし、大手クラウドプロバイダーと違って各顧客に個別に来て懇願させることもなかった。加えて、明確で技術的かつ詳細な事後分析まであった。どこでもこうあるべきだと思う
Tarsnap が存在し、picodollars 単位で価格設定されている世界に住んでいるのは、かなりうれしい
災害復旧手順をきちんと設定し、テストしていれば、ダウンタイムははるかに短縮できたはず
完全に別のステージングシステムを作り、停止してから再作成できるようにし、さまざまな障害モードを定期的にテストし、システム復旧の詳細な手順をすべて文書化する必要がある
長期的には、売上を伸ばして、似たようなことが起きたときに大いに役立つパートタイム人材を雇えるかどうかも検討する価値がある
私たちも小規模なクラウドソリューションプロバイダーで、ML API に注力しているが、クラウドハードウェアを使う場合、専用であれ仮想であれ障害は定期的に起きるということが、年を追うごとに明らかになっている。RAM、HDD、その他のハードウェア部品はいつでも故障し得るので、長期的に高可用性のオンラインサービスを運用するなら100%考慮すべきだ
正直な事後分析と、難しい状況をうまく処理したことに敬意を表する。ただし睡眠不足については、問題を直せる人が一人しかいないなら、多少の追加障害時間を受け入れてでも頭をすっきりさせることを恥じる必要はない
アラートが鳴っている中で少し寝に行くのは奇妙に感じるが、アドレナリンと睡眠不足が重なると、問題をさらに悪化させるのはあまりに簡単だ
説明だけを見ると、この復旧プロセスは定期的にテストするのが比較的簡単そうで、残っているバグを見つけたり復旧時間を評価したりできそうだ
よく言われるように、テストされたバックアップだけが本物のバックアップだ
今後は毎年リハーサルすることを、確実に高い優先順位に置くつもりだ
このようなプロフェッショナルで礼儀正しく、正直な事後分析を見るのはいつでもよいものだ
古いTarsnap社の情報に基づいて言っているのかもしれないが、私がTarsnapを本気で使うのをためらわせた唯一の要素は、予期せぬColin Percival障害、つまりキーパーソンリスクだった
そう感じているのは自分だけではないと思う
個人的には、より単純な解を選ぶ。私の経験では、単純なシステムが持つ信頼性レベルに到達するには途方もない追加の複雑さが必要で、その複雑さの大半は状況を悪化させる
サーバークラスタリングではこの点が明らかだ。安定した電源とネットワークを備えた単一サーバーは、コストと複雑さがおおむね5倍ほど増える水準に達するまでは、そのサービスを冗長化しようとするどんな試みよりも信頼できる。そこまで行ってようやく単一サーバーと同程度の平均故障間隔になり、その後になって初めて実際の改善が可能になる
真の信頼性への最善の道は、可能な限りの単純さと良いバックアップだと強く信じている。24時間365日の可用性が必要な場合、選べる技術はかなり限られる
これはColinの仕事であり、Colinの名前が懸かっており、Colinにとって非常に重要なものだ
BigBackupCorpでは同じ種類のサービスを受けるのは難しい。従業員も取り替え可能で、経営陣も取り替え可能で、率直に言えば顧客である私も、会社が方針を変えてBigFlowerArrangementShippingCorpになると決めれば取り替え可能な存在だ
小さな事業の良いところは、完全に自分自身の利益で動いていることだ。株価いじりやVC式の小細工のようなものがない。収益性のある事業なら、誰かがやって来て買収し、自分の名前を懸けて自分の仕事にできる。オープンなインターネットはこうしたものから大きな恩恵を受けていると思う
このリスクは慎重に計画すれば、望むだけ小さくできる
Tarsnapのようなサービスは複数レイヤーの1つとして置き、多層バックアップを作って定期的に検証するほうがよい
再生されたログ項目が存在しないマシンのデータを記録している、というようなエラーは、TLA+モデルを書けば捕まえられそうだ
restic+backblazeのような組み合わせを使えばコストが数桁下がるのに、Tarsnapを使う利点が何なのか気になる。どんな具体的な必要があればTB年あたり3000ドルを払う動機になるのか分からない
バスファクターが低いのではと尋ねる人には、バックアップを1つのサービスや1つの場所だけに置くつもりではないでしょう？ TarsnapとRestic+Backblaze、Rsync.net、S3などを併用するのでしょう？ と言いたい。「バックアップは復旧という贅沢を享受するために払う税金」だ
たとえば動画や写真ライブラリには別のサービスを使っているが、会計データベースや重要文書などはTarsnapにバックアップしている
Tarsnapを10年使っているが、可用性の問題もほとんどなく、覚えている限りどんな種類の問題もほとんどなかった
26時間のダウンタイムの大半はバックアップ復元に費やされたように聞こえる。奇しくも、これが私が本番環境でTarsnapを使えないまさにその理由だ
ユーザーの立場では、バックアップ復元が苦痛なほど遅い。自分のシステムがオフラインのときに、バックアップサービスのせいで何時間も待つ忍耐はない。今は改善されているかもしれないが、最後に使った数年前には、数GBのバックアップを復元するのにおおよそ1時間単位でかかっていた