シャーディング可能なデータベースからデータを削除する

シャードシステムからファイルを削除するプロセスを最適化する問題を解決する方法に関する記事。 ファイルを共有して操作するプロジェクトについてです。 このシステムは約8年前にスタートアップでしたが、その後正常に起動し、数回販売されました。 プロジェクトには最初からプロジェクトに携わっている4人の開発者がいます。これは非常に貴重です。 ドキュメンテーションは、伝統的に、書く時間がないか、あまり意味がありません。



なぜこれを読んで、なぜ私はこれをすべて書いたのですか？ 星が目からこぼれるように、システムの内側に注意深く置かれたビートについて説明します。



Hanna_Hlushakovaに協力していただき 、プロジェクトを終わらせ、記事の準備にご協力いただきありがとうございます。 基本的に、問題の説明とそれを解決するためのアルゴリズムの説明がありますが、これはコード、データ構造、またはその他の必要なものの例はありません。 私の経験が自宅で熊手を避けるのに役立つかどうかはわかりませんが、何か役に立つものを手に入れたいと思います。 おそらく、この記事は貴重な時間の完全に取り消せない損失になるでしょう。

プロジェクトについて

このプロジェクトは、ガートナースクエアのリーダーの1つであり、アメリカとヨーロッパに30万人以上の従業員を抱えるクライアント企業と、メンテナンス用の数十億のファイルを所有しています。



このプロジェクトでは、Microsoft、C＃.netサーバー、MS SQLデータベース、14台のアクティブサーバー+ 14台のデータミラーリングモードのテクノロジーが使用されています。



データベースの量は最大4 Tbで、営業時間内の一定の負荷は1分あたり約40万リクエストです。



データベースには多くのビジネスロジックがあります。

450テーブル

1000のストアドプロシージャ

80,000行のSQLコード

従来は、ドキュメントを作成する時間がなかったか、関連性がありませんでした。

タスクについて

タスクは、クライアントによってすでに削除されたストレージからファイルの削除をやり直すことであり、削除されたファイルが復元される場合に備えて、削除されたファイルの保存期間が切れました。 現在のバージョンでは、会社自体の計算によると、1年前に削除されたファイルはサーバーに保存されていましたが、ビジネス条件によると、1か月しか保存されていませんでした。 一部のファイルはS3に保存されているため、会社は余分なデータの代金を支払い、オンプレミスストレージを使用した顧客は、ファイルが必要以上のスペースを占有する理由を知りませんでした。



クライアントの会社のデータベースshardovany。

以前の削除はどのように機能しましたか？

システム内のすべてのファイルに関する情報を持つグローバルサーバーでは、15,000個のファイル識別子の範囲が形成されました。



次に、スケジュールに従って、ファイル識別子の範囲でサーバー調査が開始されました。

範囲の境界は各シャードに転送されました。



応答でシャードは、範囲から見つかったファイルを送信しました。



メインサーバーは、データベースで削除するために、不足しているファイルをキューテーブルに追加しました。

次に、キューテーブルから、ストレージからの物理ファイル削除サービスは削除用の一連の識別子を受信し、その後、ファイルを削除することを確認する確認を送信し、これらのファイルがそこで使用されているかどうかを確認するためにすべてのシャードのチェックを開始しました。

ファイルの数が増加すると、数十億のファイルがあり、範囲の数が大幅に増加したため、このアプローチは非常に遅くなり始めました。 削除されたファイルはそれぞれ合計数と比較して5％未満のままでした。数十億のファイルを整理して数百万の削除されたファイルを見つけることは非常に非効率的です。



たとえば、通常、ユーザーがファイルを削除した後、復元する必要がある場合に備えて、ファイルを1か月間保存する必要があります。 この期間が過ぎると、ファイルはプログラムによってリポジトリから削除されます。 現在のファイル数、範囲数、および範囲バイパスの速度では、サーバーがすべての範囲を完全にバイパスするのに1年かかります。

その場所が解放されなかったことは明らかであり、それはユーザーの不満を引き起こしました。なぜなら、彼らのサーバーは、レポートによると予想されるよりも何倍も多くのファイルを保存したからです。 S3の追加の場所については、サービス会社自身が支払いましたが、これは彼女にとって直接的な損失でした。



作業開始時までにS3でのみ、2ペタバイトの削除されたファイルが保存されました。これはクラウド上のみです。 さらに、ファイルが専用サーバーに保存されているクライアントもありました。同じ問題がありました。サーバーのスペースは、ユーザーによって削除されたがサーバーから削除されていないファイルで占められていました。

何をすることにしましたか？

削除イベントを追跡することにしました：

• クライアントはファイルを削除してから期限切れになりました。
• ユーザーは、回復の可能性なしにすぐにファイルを削除しました。

断片化されたデータベースからファイルを削除するとき、楽観的なアプローチを使用し、使用するチェックの1つを削除することにしました。 ファイルの99％が1つのシャード内でのみ使用されることがわかっています。 すぐにファイルを削除キューに追加し、ストアからの削除によってサービスが確認されたときに再度チェックが行われるため、このファイルの使用について残りのシャードをチェックしないことにしました。



さらに、新しいバージョンのリリース前に削除されたファイルを追加するために、削除されたファイルを範囲ごとにチェックする現在のジョブを残しました。



シャードで削除されたものはすべてテーブルに収集され、すべてのファイルに関する情報とともに1つのサーバーに転送されます。



このサーバーでは、削除キューテーブルに送信されます。



削除前の削除用テーブルでは、ファイルがすべてのシャードで使用されていないことが確認されます。 チェックのこの部分は、コード変更の前にここにあり、彼らはそれに触れないことに決めました。

コードで何を変更する必要がありましたか？

各シャードには、削除されたファイルの識別子を書き込むテーブルが追加されました。



データベースからファイルを削除するためのすべての手順が見つかりました。たった2つしかありませんでした。ユーザーがファイルを削除した後、ファイルはしばらくの間データベース内にあります。



データベースからファイルを削除する手順では、削除されたファイルを使用してこのローカルテーブルにエントリを追加しました。



ファイルを持つグローバルサーバーで、彼らはシャードデータベースからファイルのリストをダウンロードするJOBを作成しました。 シャーディング可能なデータベースからプロシージャを呼び出すだけで、内部でDELETEが行われ、OUTPUTにファイルのリストが表示されます。 MS SQL Serverのプル-リモートサーバーからのプルは、リモートサーバーへの挿入よりもはるかに高速です。 これはすべてブロック単位で行われます。

これらのファイルは、グローバルサーバーの削除キューテーブルに追加されます。

キューテーブルに、シャード識別子を持つフィールドが追加され、削除イベントの発生元がわかります。

誰もがどのようにテストしましたか？

3つの環境があります。



Devは開発環境です。 コードは、githの開発ブランチから取得されます。 IISに異なるバージョンのコードを展開し、複数のバージョンのオーケストレーションを作成することができます。 vpn内のクライアントからdev環境に接続します。 データベースへのすべての変更は、システムの他の部分の作業を中断する可能性があるため、最近まで、データベースのみで不便でした。 その後、基地はローカルになりました。 既に実行されているコードは、すべての作業を台無しにしないように、データベースを備えた開発サーバーに注ぐことができます。 開発環境では、12個ではなく3個のシャードがあり、それらはprod上にありますが、通常はこれで相互作用をテストするのに十分です。



ステージング-環境は、コードのバージョンに応じてprodと同じです（まれにあるため、ほぼ同じですが、管理者によってprodに変更が加えられています）。 masterブランチからのコードのコピー。 prodのコードとのいくつかの違いがデータベースで検出されることもありますが、一般的には同じです。 ステージングと乙女にも3つの破片があります。 ステージングおよび開発に負荷はありません。 ここでは、コードがprodと一致するため、すでに完全に統合テストを実行できます。 すべてのテストに合格する必要があります。これは、展開に進む前の前提条件です。



負荷のかかった状態でテストが行​​われるパフォーマンスラボ。 負荷は、prodの10分の1のjmeterを使用して作成されます。シャードが1つしかないため、不便な場合があります。 販売データが取得され、匿名化されてperfラボで使用されます。 prodと同じ構成のすべてのサーバー。



これは1シャードのprodにかかるおおよその負荷であると想定されているため、負荷は10倍少なくなります。 欠点は、販売とは異なり、グローバルベースが非常に活用されていないことです。 また、変更が主にファイルを含むグローバルデータベースに関係している場合、テスト結果にほぼ依存することができます-製品では、これはそのように動作しない可能性があります。 perf labは負荷と製品を理想的に一致させることはできませんが、負荷の下でテストする機能は、製品に展開する前に多くのエラーをキャッチするのに役立ちます。



いくつかのケースをキャッチするために、販売からのデータを見ることができるバックアップサーバーもあります。 一般に、会社は開発者が販売データにアクセスすること、および管理およびサポートチーム（オペレーション）が開発にアクセスすることを禁止するライセンスの下で運営されているため、データベース管理者の支援を求める必要があります。 販売データを使用すると、テストが非常に簡単になります。これは、prodデータのみで発生する場合があり、ユーザーにとってシステムがどのように機能するかを理解するために、実際のシステムでデータを調べることが非常に役立つためです。



perf labでのテスト中に、ストレージからファイルを削除する負荷が単語からまったく認識されないことが判明しました。 負荷テストを実装する際、クライアントソフトウェアからのより一般的なリクエストを選択しましたが、その一部はストレージのクリーニングに含まれていませんでした。 これはデータベースであるため、異なるデータに対して変更されたプロシージャを手動で呼び出すことにより、変更されたすべてのオブジェクトに対して簡単なテストを実行することが判明しました。 （私が知っていたオプションについて）。

さらに、統合テストとパフォーマンステストでは、最も一般的なタイプのファイルストレージに重点が置かれました。



perfラボの追加機能は、すぐには見つかりませんでしたが、prodとperfのいくつかのテーブルのデータ量の不一致です。 すべての販売JOBがデータを生成するパフォーマンスで動作するという意味では、テーブルで生成されたデータを処理するものが常に存在するとは限りません。 また、たとえば、perfでの削除のための前述のテーブルキューは、prodでのレコードよりもはるかに大きく、perfで2000万レコード、prodで20万レコードです。

展開プロセス

展開プロセスは非常に標準的です。 このタスクのアプリケーションコードに変更はありませんでした。すべての変更はデータベース内でのみ行われます。 DBAは常にデータベースにロールされます;このプロセスは自動化されていません。 変更の適用と変更のロールバックのために、2つのバージョンのスクリプトが用意されており、DBAに対する指示が記述されています。 スクリプトの2つのバージョンは常に作成され、変更のロールバックとロールバックについて必ずテストされます。 そして、これらの同じスクリプトを使用して、統合と負荷テストを開始する前に、ステージングとパフォーマンスラボに変更を適用します。

展開後はどうなりましたか？

展開後の最初の5時間で、ファイルをダウンロードしようとしてクライアントソフトウェアがエラーを受信したという100万のイベントが発生しました。 「ファイル破損」イベント。 これは、クライアントがファイルをダウンロードしようとしているが、ファイルがリポジトリで見つからなかったことを意味します。 通常、これらのイベントはまったく発生しないか、1日あたり1〜2000で測定されます。



3人、時には5人（私を含む）のチームで失敗の原因を見つけるのに少なくとも1週間かかったことをすぐに言わなければなりません。



「ファイル破損」イベントが発生したファイルのリスト全体を収集しました。



100万を超えるイベントがあり、それらはすべて異なるユーザー、異なる会社からのものであるという事実にもかかわらず、このリストには250の一意のファイルしかありませんでした。



イベントが到着したときにデータベースのバックアップを調査するために、バックアップサーバーのDBAが提起されました。 プロジェクトベースには、分析に役立つすべての種類のログを含むかなり多くのテーブルがあります。 データベースから情報を削除する場合でも、削除されたものとイベントによってログが追加されます。 製品では、そのようなレコードは1週間保存され、アーカイブサーバーにマージされます。



そして、何が起こったのかを分析するのに非常に役立ったログのあるテーブルもそうです：

クライアントでのイベントを含む完全なログが各シャードで維持されます



グローバルサーバー上：

• ユーザーがすべてのファイルをダウンロードするリクエストのログ
• ユーザーからシステムへのファイルのアップロードのログ
• FileCorruptイベントログ
• ストレージからの削除をキャンセルするログファイル
• データベースから削除されたファイルのログ

さらに、アプリケーションログを備えたELKが利用可能でした。



開発環境でエラーを繰り返すことができたため、仮定が正しいことが確認されました。 非常に多くの要因が同時に発生し、非常に多くのユーザーがこの特定の時間に来たと信じることは非常に困難であったため、最初は、誰もこの仮説を真剣に受け止めませんでした。

何が悪かったのですか？

システムには、約250個（システム内の数十億個のファイル）の超大人気メガファイルがあることがわかりました。 250はい！



これらのファイルはまだ非常に古いものでした。 これらのファイルがシステムにアップロードされた時点で、ストレージへのファイルキーを生成する別のシステムが使用されていました。



このタイプのキーでは、物理ストレージからの物理的な削除方法が他のファイルとは異なる動作をすることが判明しました。



削除されたクラスには、古いキーを持つファイル専用の条件を持つコードブロックがあります。 システムは、削除時に、ファイルがシャード上にないことを確認する前に、この古いファイルを別の場所に移動します。 まあ、それはうまくいきませんでした。



そして、ファイルが移動された瞬間に（そして私はそれが非常に人気があることを思い出すでしょう）、ユーザーの1人が彼に新しいユーザー権限を与えようとすると、クライアントソフトウェアはこのファイルのストレージに行きますが、適切な場所にファイルがありませんでした。 それが移動されるので、それはうまくいきません。 クライアントソフトウェアは、ファイルが破損しているというメッセージを送信します。 データベースでは、破損としてマークされます。 そして、すべての情報がデータベースから削除されます（ほとんどすべて）。



それまでの間、シャードチェックルーチンはファイルが使用されていることを検出します。 そして、それを返すために必要な応答を送信します。 しかし、すべての情報はすでにデータベースから削除されており、返すことは不可能です。



おかしい？



つまり、ファイルが削除されたとき、ユーザーはその期間にファイルが移動され、シャードがチェックされ、この時点でユーザーがダウンロードのリクエストを送信しました。



ここにあります-あなたがマッチする最も信じられないほどのマッチの場合、アクションの高負荷。







驚きから回復し、すべてをロールバックした後、他のクライアントのディスクから復元されたため、ユーザーからのファイルが生きていることを確認しました。



当然のことながら、テスト中に過去5年間に使用された新しいキータイプで新しいファイルが削除されたため、テストではすべてが正常でした。



私たちの楽観主義は減少し、私たちは最も楽観的な道を歩まないことに決めました。

回顧

さまざまな種類のストレージのテストを追加する必要があると判断しました

ストレージから削除されたときに呼び出しを使用するパフォーマンスラボに負荷を追加する

有名なレースコンディションを閉じる

監視を追加します（ただし、計画には含まれますが、元のスコープには適合しませんでした）

監視について

彼らはすぐに監視を行うことにしましたが、より速く展開する必要があるため、何かが背景に消えていきました。



監視のために、プロジェクトはZabbix、ELK、Grafana、NewRelic、SQL SentryおよびAppDynamicsのテストバージョンを使用しました。



このうち、pef labにはNewRelicとSQL Sentryがありました。



すべてのシステムメトリックをすでに測定しているため、ビジネスメトリックを測定する必要がありました。 Zabbixを使用してこのような監視を整理した経験がありました。同じことをすることにしました。



このスキームは、JOBで必要なメトリックを収集するテーブルと、収集したメトリックをZabbixにアップロードする手順を作成するデータベース内で非常に単純です。



指標：

• グローバルベースで削除するキュー内のファイルの数
• サーバーによってキューに入れられたファイルの数
• リポジトリからアンインストールプログラムに送信されたファイルの数
• 削除されたファイルの数
• FileCorruptイベントの数
• 各シャードで削除するファイルの数

監視は、削除の新しい実装の展開を開始する前に、販売に個別に実装および展開されました。

新しいソリューション

一般に、寝ないよりも食べ過ぎの方が良いと判断し、新しい計画を立てました。

1. 誰もファイルを使用していない同じシャードを確認し、未使用のファイルのみをサーバーに転送します。
2. サーバーに転送するとき、テーブル内のすべてのファイルを収集し、削除のためにテーブルキューに配置する前にファイルがシャードで使用されていないことを確認します。
3. ファイルを使用してシステムで検索する場合、テーブル内のデキューキューを検証が必要なファイルとしてマークします。
4. 検索されなかったファイルのみを返します。
5. 検索されたファイル、シャードの再確認。
6. 一般に、ファイルを削除する手順のチェックを削除します。ファイルはすぐに解決されるはずです。また、使用済みのファイルは原則としてファイルに到達しないはずです。
7. 削除中のファイルをすべて削除する手順を考慮し、その情報を削除しないでください。

展開中のポイント6には、いくつかの段階でのチェックの削除が含まれていました。 最初に、彼らはチェックを去り、それから1週間後に会社の従業員のファイルのチェックはオフになり、2週間後、チェックは完全にオフになりました。

コードで何を変更する必要がありましたか？

繰り返しますが、すべての変更はデータベースにのみ適用されます。



変更の規模は、グローバルサーバーで最大でした。

シャードからダウンロードされたすべてのファイルを追加する中間テーブルを追加します。

シャードで使用されていない中間テーブル上のファイルをチェックするJOBを作成します。



削除されたファイルのキューに、ファイルが最後にアクセスされた日付のフィールドを追加し、インデックスを追加します。



ファイルにアクセスできるすべての手順を見つけてください-5つの手順が判明しました。 キューテーブルで最後に使用した日付を変更するブロックを追加します。 日付は、入力されたかどうかに関係なく、毎回変更されます。



削除プログラムをファイル発行手順に追加して、使用日が空のファイルのみを表示するようにします。



使用日とチェックのすべてのファイルを収集するJOBを追加します（クライアントソフトウェアがファイルをシャードに追加できるようにするために必要な10分の遅延で、通常は最大2分かかりますが、安全に再生することにしました）。すべてのシャードでファイルを使用します。 検証が完了すると、ファイルが見つからない場合は使用日がリセットされ、それ以外の場合はファイルがキューから削除されます。 検証プロセス中に使用日が変更された場合、検証の進行中にファイルがシャードにアップロードされた可能性があると想定されるため、データは変更されません。シャードには検証が既に完了しており、ファイルの新しい検証サイクルが必要でした



シャード上：



削除されたファイルを含むテーブルからファイルを削除する手順では、ファイルが使用されていないことを確認する必要がありました。 プロシージャのシンプルさと美しさはそれほど失われていません-NOT EXISTSが出力付きのDELETEに追加されただけです。



彼らはJOBを追加しました。これはバックグラウンドで、サーバーで使用されるテーブルファイルから強打されました。

テスト

すべてのストレージオプションの使用に関するシナリオが統合テストに追加されました。

また、新しいファイル削除機能をテストする新しいケースを作成しました。



Perf Labは、グローバルサーバーに負荷を追加しました。 さらに、ストレージからファイルを削除することに対応する負荷を追加しました。

展開する

データベースの変更のアプリケーションおよびロールバック用のスクリプトが準備されました。 DBAはスクリプトをロールし、負荷テスト中にファイルを削除するためのキューテーブルのロックに注意を払わなかったことが判明しました。 その結果、最適なインデックスではないインデックスを修正しました。



このため、新しいコードを展開する前にシステムで削除されたファイルに応じて、範囲によるJOBチェックを無効にし、削除されたファイルの識別子を手動で分析および追加する必要がありました。

結果

その結果、展開の結果として、新しい削除されたファイルは24時間以内にストレージから削除されます。

新しいシステムの起動前に削除されたファイルは、バックアップで作成され、prodのキューに追加されました。



その結果、2ペタバイトのS3の余分なデータが削除されました。 専用のクライアントサーバー上のファイルでも同じことが起こり、サーバー上のそれらの場所がクライアントに表示される場所と一致するようになりました。



キューテーブルの湾曲したインデックスは、バックログのインデックスを変更するタスクであるprodに残りますが、優先度の高いタスクのためにわずかに延期されます。