CTOがキャリアを懸け、ビットレベルまで降りてDBをハックした話
(tech.devsisters.com)- Devsisters史上もっとも長かった『CookieRun: Kingdom』の36時間障害
- メインの分散DBとしてCockroachDBを使用: 4ノード、12TBのストレージ、7つのレプリカ
- データベース拡張作業中にノードの半数がダウン
- これによりサービス全体で障害が発生し、CockroachDB側のサポートエンジニアは復旧不可能と判断
- そこで、ストレージに保存されたデータを直接探し出すための取り組みをまとめた記事
24件のコメント
なかなか議論を呼んでいる文章ですね……？ サービス面ではどうか分かりませんが、作業した開発者たちはものすごく誇らしかっただろうなと思います
ユーザーの反応がどうだったかは分かりませんが、ロールバックを防ぐために努力したという点では、ユーザーとしては称賛の一票を入れたいです。とはいえ、36時間のあいだに起きたであろうユーザー離れや顧客体験を考えると、損失のほうが大きかったかもしれませんが、開発者の立場から見ると面白い挑戦だったと思います。会社がゲーム会社ではなく銀行だったらどうだったでしょうか？
Pokémon GOはGCPのSpannerを使っているそうですが（https://cloud.google.com/blog/topics/…
該当文書をもとに開発チームの意図を把握すると、そのプロジェクトではCockroachDBを使うべきではなかったようですね。
どのDBを使うべきだったのでしょうか？
サービスによってはぞっとする内容ですね。
面白く読みました。
見ると、そのブログにはこの障害に関する内容が連載として掲載されていました。通して読んでみると、あれの復旧にあたっていた人たちが感じたであろうメンタル崩壊ぶりが実に印象的でした。
一部のユーザー体験を損ねて大多数を守るロールバックよりも、36時間かけてすべてのユーザー情報を復旧するほうがビジネス的に正しい判断なのかは、正直よくわかりませんね。開発者の観点では興味深い内容ですが。
本文の内容にこんな一節がありました。
お客様に最高の体験を届けることが私たちのミッションであり、それを本気で実践するために努力してきました。誰一人として落胆して諦めることはありませんでした。
金のためなら一部のユーザーは切り捨てても構わないという話を、ここでも聞くことになるとは。韓国のゲーム業界におけるユーザーの扱いを、またしても思い知らされました。
それは少しひねくれて見すぎだと思いますし、結果論として見れば、問題を解決できなかったなら時間は時間として無駄になり、バックサーバー復旧はバックサーバー復旧で不満を買ったでしょう。
そして、サービスを提供できないなら、その間ユーザーを見捨てているという観点も同じです。
非常に、非常に激しく共感します...
開発者の観点ではとても興味深く読みましたし（刺激的なタイトルも含めて）、私も似たような見方をしていました。少し前の記事で言及されていた内容なので実際とは差があるかもしれませんが、Cookie Run: Kingdom の売上は3,000億ウォンを超えているようですし、36時間のダウンタイムを期待売上に換算した場合と、ロールバック後の補償支給額を比較して判断した案件だったのでしょう。
問題解決を重視する開発者文化が強い組織だという点も、ある程度影響していたのではないかと思います。
自分ならどんな決断をしたか、今でもよく分かりませんね。
最近のゲームでは（特にランダムガチャ系のあるゲームでは）、ロールバックは……本当に最悪の場合にしか使えない手段なんですよね……。L社のゲームのようにイメージを気にしないのでない限り不可能ですし、特にこの件はむしろロールバックせず、その後に補償を大きくしたことで、ユーザーたちも「資源が足りなくなったら、また一度サーバー落ちないかな？」みたいな冗談を言い合っていたくらいですからね……。私は正しい判断だったと思います。
ゲームなので、36時間前にロールバックすると、キャッシュ関連で金銭的な損失もかなり大きかった可能性がありそうですね。
ビジネス的に正しい判断ではないと思う、に一票。
意図しない設定ミス（これが最もクリティカルで、あきれるほどのヒューマンエラー。レプリカを動作不能にしてしまうような重大な操作をこんな形でやらかしてしまった。DBの設計開発者を全員連れてきても、これは復旧できない）
だからといってデータを丸ごと失うわけにはいかないので……最新データの整合性は諦めるとしても、最終的に保存されたバイナリ形式のDBデータ（7 TB）を直接見つけ出して、これをcsvに変換するためにgoプログラムを作成……？
この変換用goプログラムを作るのって、どれだけうまく作っても何の意味があるんだろうか……
はぁ……考えるだけでも息が詰まりますね。どうしてこんなことにならなければならなかったのか……
こうしたヒューマンエラーが起きないようにプロセスを強化するのが何より重要ですね。障害対応しながらバイナリ変換で苦労した話はしないでほしいです.
こういう話をしてはいけない理由が、また別にあるのでしょうか？ ポストモーテムを公開すること自体に意味があるのに、と思います。
私が見るに、本当に役立つ文章を書くなら、タイトルはこうあるべきではないでしょうか？
「ノード設定ミスによりクラスター不可エラーが発生した原因分析と教訓」
そういう話は別で書けばいいことで、「障害原因の分析」と「障害解決の過程」は別のトピックで、どちらも重要な話なのに、「障害原因の分析」がなかったからといって記事の価値を貶めるような行動は理解しがたいですね...
原因分析の記事も続編として書いてくれるとさらに良さそうだ、と言えばいいのであって、その前に価値がないと言うのは良い態度ではないですね。
厳密に言えば『障害対応の過程』ではなく、"不完全なデータ復旧の力業"の過程です。単に損失範囲を少し減らした？ その程度です。
上の文章のどこに、データ復旧が「不完全」だと書かれているのでしょうか。少なくとも上の文章の内容では、完全な復旧に成功したとありますよね。さらに、消してしまったDBを復旧したことが障害対応でないなら、何だというのでしょうか。あの件のあと、そのサービスはそのまま運営終了したのでしょうか。
それは、この話をしてはいけない理由にはならないのでは？
ずいぶん大変な生き方をされていますね