主なポイント
Binance Ledger への移行は、以前のリレーショナル データベース サーバーに固有のホット アカウント問題を解決することを目的としていました。
暗号通貨取引所は、毎日休憩時間がある通常の取引所とは異なり、メンテナンス時間がなく、年中無休で24時間365日稼働しています。
新しい Binance Ledger への移行はオンラインで実行され、ユーザーの資産が SAFU のまま維持され、ビジネスにまったく影響が及ばないようにする必要がありました。そのため、エンドユーザーのエクスペリエンスはシームレスなままでした。
私たちは、gh-ost ツールで採用されている一括移行戦略ではなく、段階的なアカウントごとの移行戦略を選択しました。
Binance Ledger への移行と、プロセス全体で使用されるツールとテクニックについて詳しくご覧ください。
Binance Ledger は当社の技術業務の基盤となっており、膨大なユーザーベースで毎日何百万ものトランザクションを処理しています。システム、その目標、課題の詳細については、当社のブログ「Binance Ledger が Binance エクスペリエンスを強化する方法」をご覧ください。旧バージョンから新バージョンへの移行プロセスでは、典型的な課題に直面しました。飛行機がまだ飛行中に、エンジンをオンザフライでアップグレードするにはどうすればよいかということです。ユーザーの資産を移行する必要があり、資金を SAFU に保つことが最優先事項でした。
Binanceの移行における主な課題
設定した目標を達成するには、次の課題に対処する必要がありました。
新しい元帳の完全な正確性を確保する
資金の問題を検出し、タイムリーかつ正確に解決できる
アップストリームのダウンタイムが発生しない
移行ミッションとオンライン データベース DDL の比較
ソリューションの詳細に入る前に、大規模なテーブルに対してオンライン DDL (データ定義言語) を実行する際の一般的な問題を見てみましょう。DDL とは一体何でしょうか。何億行もの行があるテーブルに別の列を追加する必要があると想像してください。業務を中断することなく、これをオンラインで実行する必要があります。
gh-ost ツールはこの問題を解決するために広く使用されており、次の図でその動作を確認できます。
このプロセスは基本的に 2 つのフェーズで構成されます。
同期フェーズは、新しいテーブルが元のテーブルと完全に同一になるまで継続されます。同期されるデータには 2 種類あります。
既存データ
増分データ（進行中の移行プロセス中に元のテーブルから生成された新しいデータ）
進行中のトランザクションを中断せずに、元のテーブルを新しいテーブルと交換するカットオーバー フェーズ。
Binance Ledgerの問題が他と異なる点
いくつかの類似点があるにもかかわらず、Binance Ledger のオンライン移行ミッションには、本質的に独自の課題がいくつかありました。
まず、Binance のバックエンド システムは分散環境で動作しますが、オンライン データベース DDL はモノリシック環境です。次に、データはユーザーの資産であるため、一括移行アプローチを採用することはできません。最後に、大量移行を開始する前に、関連するすべてのサービスが全体として機能することを確認する必要があります。
前のオンライン DDL の例と同様に、移行にも 2 つのフェーズがありました。
同期フェーズでは、古い元帳から新しい元帳に残高を同期するために専用のレプリケータサービスが特別に構築されました。
アカウントごとの切り替えフェーズ
段階的アプローチ
タスクは大規模で、諺にあるように、ローマは一日にして成らずです。大規模で複雑な問題領域に対しては、分割統治アプローチがしばしば効果的に機能します。
フェーズ 1: レプリケーション
理由
ここでの私たちの思考プロセスを 2 つの主なポイントにまとめることができます。
私たちは、現在の台帳システムを動かす既存の MySQL クラスターに参加する新しいスレーブとして Binance Ledger をモデル化しました。レプリケーション技術を活用することで、ユーザーの残高を非同期で完全に同期させることができます。
その後、本番トラフィックをそのまま Binance Ledger にルーティングして、その正確性と堅牢性を検証できます。このフェーズで問題が発生しても、当社とユーザーに影響はありません。
何
以下に、レプリケーション パイプライン全体を示します。注意すべき重要なパスは次のとおりです。
転送 → 元帳 → Binance 元帳レプリケーター → Binance 元帳
方法
レプリケーション プロセスを 2 つの個別のステップに分割しました。
元帳DBのスナップショットをダンプし、それをBinance元帳にインポートしました。
スナップショットがダンプされた後の元帳 DB の bin ログを複製しました。
最終的には、残高と残高ログのデータは、古い元帳と Binance 元帳の間で完全に同期され、完全な調整モジュールによってさらに検証できるようになります。
いつ
Binance Ledger は 2022 年 8 月初旬に稼働を開始しました。その後、レプリケーション プロセスを開始し、2022 年 11 月中旬まで続きました。このプロセスは、新しい台帳システムの正確性を 100% 検証する必要があったため、私たちにとって重要な期間でした。次の移行フェーズに進む前に、このステップをスキップすることはできませんでした。
最終的に、問題は見つからず、状況に慣れるためにリリース ルーチンをいくつか実行しました。3 か月のプロセスは特に速いものではありませんでしたが、SAFU の目標達成には必要でした。
フェーズ2: オンライン移行
理由
数億のアカウントを移行するために、カスタマイズされた移行ジョブを構築しました。
何
以下に、1 つのアカウントのコア移行フローを示します。
以下に留意すべき重要な注意事項をいくつか示します。
アカウント システムは、各アカウントの所有権マッピングを維持します。
口座A → 元帳
アカウントB → Binance Ledger
アカウントC → 禁止
アカウントを移行する前に、保留中の同時トランザクションが存在する場合は、ビジネスへの影響を軽減するためにスキップされます。
所有権のマッピングを元帳から禁止に変更し、残高の更新を禁止して不変にしました。
古い元帳と Binance 元帳の残高を調整しました。
所有権のマッピングを禁止から Binance Ledger に変更し、将来の残高更新が Binance Ledger に直接ルーティングされるようになりました。
パフォーマンス メトリックによると、ステップ 3 からステップ 5 までの平均所要時間は 150 ミリ秒でした。理論上、この 150 ミリ秒の移行期間中、ユーザーはトランザクションを実行できません。影響を受けたトランザクションはゼロであることが判明しました。
処刑
Binance では、「綿密な計画よりも実行力」という原則を掲げています。確実な実行は成功に不可欠であり、資金の安全性は常に最優先事項です。問題をできるだけ早く把握するために、3 週間かけて段階的に移行戦略を採用し、悪影響の規模を軽減しました。
和解プロセス
調整は、偏りのない観点から潜在的な残高の異常をタイムリーに検出する上で非常に重要です。状況を悪化させる前に迅速に対応できるよう、ほぼリアルタイムでプロセスを実行できます。オンライン移行プロセス専用に、リアルタイムと完全の 2 種類の調整モジュールが開発されています。
リアルタイム
トランザクション レベル ベースの調整プロセスは、資金の問題をリアルタイムで検出するように構築されています。
満杯
データ ウェアハウスに同期されたスナップショットに基づいて、定期的に完全な調整を実行できます。このプロセスにより、古い元帳と Binance 元帳のすべての残高が同じであることが保証されます。
たとえば、古い元帳にまだ 1,000 万人のユーザーがいるとします。この完全な調整を使用して、古い元帳と Binance 元帳の残高と残高ログが同じであることを確認できます。
移行プロセスのまとめ
簡単に言えば、このミッションは、1) レプリケーション技術を使用して新しい Binance Ledger の正確性を検証し、2) アカウントごとの移行戦略を実装して、エンジンをゆっくり、安全かつ確実にアップグレードすることで達成されました。
前述のオンライン移行パラダイムは、同様のタスクで再利用できると考えます。ここで説明したプロセスやトピックに興味をお持ちいただけましたら、ぜひチームへの参加をご検討ください。Binance では、日々の課題に対して新鮮な視点を持つ熱心な人材を常に求めています。
参考文献
Binance Ledger が Binance 体験をどのように強化するか
GitHub の MySQL 用オンライン スキーマ移行ツール
参考文献
MLOps を使用してリアルタイムのエンドツーエンドの機械学習パイプラインを構築する | Binance ブログ
Binance はあなたにぴったりの場所ですか? Binance に参加しない理由 | Binance ブログ