時間との競争: Weimob のデータ復旧にはなぜ時間がかかるのでしょうか?

WeMallの「データベースを削除して逃走」事件から数日が経過した。 WeMallのサービスは完全に復旧したと報告されています。新規ユーザーの場合、関連するすべてのビジネス活動を通常どおり開始できます。ただし、古いユーザーの場合、データは完全に復元されていません。公式サイトの情報によると、加盟店アカウントと株式データは復旧したとのこと。 2月28日夕方時点で、約70％のデータが復旧される予定。

B サイドのユーザーや一般の人々は、クラウド コンピューティング、コンテナ化されたデプロイメント、エラスティック スケーリング、データ バックアップなどの現在のテクノロジがすでに非常に進歩しているのに、なぜリカバリ サイクル全体にまだこれほど長い時間がかかるのか疑問に思うでしょう。そこで今日は技術的な観点からの私の理解についてお話ししたいと思います。

正式にテクノロジーについて話す前に、今年の羅鵬氏の大晦日のスピーチ「時間の友」についてお話ししたいと思います。羅鵬さんは「関わる」ということについて語ってくれましたが、長年IT技術に携わってきた「同世代」の私にとっては、とても感動的でした。ゲームの外側に立っていると、多くのことは複雑ではないと感じることがよくありますが、実際に関わってみると、私たちが見ているのは氷山の一角に過ぎず、多くのことは思っていたよりもはるかに複雑で難しいことがわかります。

[[316971]]

非常に鮮明な例を挙げると、人々は通常、簡単に達成できる成果を選んだがります。なぜなら、脳のフィードバックの観点から言えば、簡単に達成できる成果は簡単に得られるからです。しかし、低く見える果物は実際には低くない可能性があります。おそらく、あなたはそこから遠すぎるのでしょう。近づいてみると、最初に見たよりも高いことがわかります。近づいてみると、手の届かないところにあることがわかります。

まるで山のようです。遠く離れると、山は高くないと思うでしょう。自分で山のふもとまで歩いてみなければ、登るのは不可能だとは分からない。ここに写真を添付し​​ました。エベレスト北斜面の登山ベースキャンプで撮影した写真です。当時の標高は約5,300メートルでした。私の後ろには、標高8,848メートルの世界最高峰、伝説のエベレスト山が見えます。高くないように見えるかもしれませんが、それはまだ十分離れていたからです。言い換えれば、何かが簡単だと思ったとき、それは実際には簡単ではないことが多く、おそらくあなたがそれを理解していないからでしょう。

[[316972]]

WeMall 事件に戻ると、同じ論理が当てはまります。現代の大規模インターネット製品は、toC であれ toB であれ、ユーザーの観点から見ると非常に使いやすいものですが、その背後にあるアーキテクチャの複雑さは氷山の下の部分であり、その複雑さは想像をはるかに超えています。私はよく「認知は想像力を制限する」と言います。したがって、現時点では、WeMall は氷山の下でデータの早期復旧を促進するために全力を尽くしているはずだと私は考えています。

さて、技術的な話題についてお話ししましょう。明らかに、WeMall の現在の主な問題はデータベースの復旧です。公式から具体的な技術的詳細は発表されていないため、インターネット上ではごくトップレベルのアーキテクチャ図しか見つからず、システムインフラストラクチャ、特にデータベースアーキテクチャに関する詳細な情報を入手できていません。したがって、技術的な複雑さを理解していただくために、個人的な経験に基づいていくつかの推測をすることしかできません。

まず、データベースの動作環境を理解しましょう。簡単に言えば、主に次の 3 つのタイプがあります。

「クラウド上ではない」 ：独自のデータセンターを構築し、ハードウェア、ソフトウェア、データをすべて自分で管理します。これは、クラウド プラットフォームが普及する前の主流の慣行でした。このモデルでは、関連するすべてのデータベースの高可用性、容量拡張、およびデータ バックアップを非常に専門的なチーム (DBA チームと運用保守チーム) によって管理および保守する必要があり、企業に比較的高い技術要件が課せられます。

「すべてクラウド上」 ：完全にクラウド環境上に構築されています。ここでのクラウドはパブリック クラウドでもプライベート クラウドでもかまいません。クラウドベンダーは、高可用性、容量拡張、データバックアップなどの機能をサポートする完全なソリューションセットを提供します。クラウド コンピューティングの普及とデータベース アズ ア サービス (DBaaS) の急速な発展により、このソリューションを選択する新興企業がますます増えると考えられます。

「偽のクラウドコンピューティング」 ：このソリューションは、ルイ・ヴィトンのバッグを使って野菜を梱包するのと少し似ていて、非常に奇妙ですが、業界では珍しいことではありません。これは過渡期の産物であると言うべきでしょう。このアプローチは、クラウド ソリューションを仮想マシンとして使用することです。この方法は、前述の「クラウドに移行しない」方法と非常によく似ています。クラウドをまったく活用していません。データセンター内のマシンをクラウドに移動するだけです。クラウド ソリューションが提供できる災害復旧機能と容量拡張機能は削除されました。

上記の 3 つの方法では、「クラウドを利用しない」および「偽のクラウド」は、「完全なクラウド」よりもデータに大きなリスクをもたらします。 「クラウド化しない」や「擬似クラウド」の場合、運用・保守担当者が「rm -rf /*」や「fdisk」などの極端な操作を実行する機会がある可能性が高くなりますが、「フルクラウド」の場合、オペレーティングシステムレベルからそのようなコマンドを実行する機会は少なく、rm -rf / によってデータベースデータが削除されることはありません。

削除操作がオペレーティング システムのデータ ファイル レベルで行われない場合 (バックアップは通常、ファイルの形式で存在します)、データベース自体の特性を利用することで、誤って削除されたデータの回復効率が大幅に向上します。

同様に、データ誤操作の問題（たとえば、テーブル内のフィールドを誤って一括更新するなど）に直面した場合、「すべてクラウド上」は、「クラウド上にない」や「クラウド上に偽物」よりも明らかに有利です。私にはこれに関する個人的な経験があります。以前、自作のデータベースを使ったプロジェクトがありました。 DBA の誤操作により、実稼働環境のデータベースで where 条件のない更新ステートメントが実行され、オークション アイテムのすべての入札記録フィールドが直接失われました。その後、完全なロールバックとバイナリログの再生が困難になり、最終的に復旧に 4 時間以上かかりました。その後、クラウド データベースで同じエラーが発生しましたが、ロールバック回復には数分しかかかりませんでした。

Tencent Cloudのこれまでの回答から、WeMallの削除されたデータはTencent Cloud上にないことが大まかに分かります。現在のデータ復旧速度と合わせると、WeMall が「オールクラウド」アーキテクチャを採用していないか、データの一部のみがクラウド上にある可能性が高いとほぼ判断でき、より極端な「rm -rf /*」や「fdisk」の状況が発生した可能性が非常に高いです。この場合、すべてのマスタースレーブライブラリファイル、完全バックアップファイル、増分バックアップファイル、および binlog が同時に失われます。ここでの技術的な課題は主に、従来の IT ベンダーがディスクリカバリをどのように実行するかという点にあり、これはもはやどのクラウドベンダーにとっても重要なスキルではありません。

このような状況では、すべてのデータを回復することは技術的に非常に困難であると考えられます。私の大まかな理解によれば、少なくとも以下の技術的な閾値を超える必要があります。

オフサイトでのコールド バックアップまたは災害復旧がある場合は、完全バックアップを取得するのが理想的ですが、完全バックアップは通常非常に大きいため、ファイル転送と検証が完了するまでに長い時間がかかります。オフサイトの完全バックアップが利用できない場合は、より時間のかかるディスク回復方法を使用する必要がありますが、100% の成功は保証されません。ディスクのリカバリに時間がかかる理由については、後ほど説明します。ここでのもう 1 つの問題は、完全バックアップが「古すぎる」可能性があることです。これにより、その後のリカバリにさらに時間コストがかかります。

増分バックアップを取得します。多くの場合、増分バックアップのオフサイト災害復旧バックアップを実行する時間が十分にないため、ディスクから復元する必要がある可能性が高くなります。これは時間の無駄であり、100% 完全な復旧を保証することもできません。

binlog を取得します。 Binlog は、すべてのデータベース テーブル構造の変更 (CREATE、ALTER TABLE など) とテーブル データの変更 (INSERT、UPDATE、DELETT など) を記録するバイナリ ログ ファイルです。通常、インデックス ファイル (末尾に .index が付く) とログ ファイル (末尾に .00000* が付く) の形式でディスクに保存されます。 binlog データの変更の正確性を確保するために、binlog は通常、行形式になります。そのため、ファイルサイズは小さくなく、ファイル数も多くなります。

上記を基本入力として、データベース レベルでデータのインポートと回復を開始できます。このプロセスにも多くの時間がかかり、上記のファイルが 100% 取得できることが前提となります。上記のバックアップ ファイルにデータの問題がある場合、追加の時間コストはさらに大きくなります。

最後に、ディスク ファイルの回復について説明します。ディスクなどのストレージ メディア上のファイルを削除したり、フォーマットしたりしても (低レベル フォーマットを除く)、ディスク上のデータは実際にはディスクから消えるわけではなく、ファイル アロケーション テーブルにマークされるだけです。データ領域内のデータ自体はすぐには消去されません。ファイルのデータ領域が後から書き込まれた情報によって上書きされない限り、削除されたファイルは復元可能です。これは、ディスク ファイルが削除された後に回復されるための理論的根拠です。

ただし、データベースのデータ ファイルとバックアップ ファイルは非常に大きくなることがよくあります。個々のデータ領域が上書きされている限り、復元されたファイルは不完全になります。この時点で、これを修正するには人間の介入が必要です。作業量と技術的な難易度は非常に大きく、特殊な器具や設備が必要になる場合もあります。より複雑なケースでは、データ カービングも使用されます。データ カービングは、デジタル フォレンジック研究で頻繁に使用されるファイル回復手法です。ディスクのファイル システム タイプを利用せずに、一見区別のないバイナリ データ セット (つまり、生のディスク イメージ) からファイルを抽出します。

さらに、WeMall のような大規模なシステムでは、各垂直ビジネス ユニットが独自のビジネス データベースを持ち、異なるソリューションを使用する場合もあります。このアーキテクチャの異質性は、復旧プロセスにも大きな課題をもたらすでしょう。また、部分的なデータ復旧が完了した後でも、すぐにオンラインにすることはできません。代わりに、他の関連データが回復されるのを待って、データを相互チェックし、データが完全であることを確認する必要があり、これには多くの時間がかかります。

これらは私が思いつく状況のほんの一部です。私は非常に遠くから観察者の視点で問題を見ているので、実際の状況は私が説明したものよりも複雑になると思います。最終的な回復結果を推測することはまだできず、私たちにできることは待つことだけです。