1営業日で何百万の国々を移行したか

Badooは、1億9千万人のユーザーを抱える、新しい人と出会う世界最大のソーシャルネットワークです。

すべてのデータは、ヨーロッパとアメリカの2つのデータセンターに保存されます。 少し前に、アジアのユーザーからのインターネット接続の品質を調査し、700万人のユーザーの場合、ヨーロッパのデータセンターからアメリカのデータセンターに移動すると、サイトの読み込みが2倍速くなることがわかりました。 初めて、データセンター間でのユーザーデータの大規模な移行という課題に直面しましたが、これをうまく管理しました。1営業日で150万人のユーザーを移動する方法を学びました。 国全体を動かすことができました！ 最初の部分では、私たちの前に設定されたタスクと、達成した結果について詳しく説明します。

アーキテクチャBadoo

Badooのアーキテクチャは、さまざまな会議やHabré自体でよく話題になっていますが、それでもタスクを理解するために重要な主要なポイントを繰り返します。 Badooは、Linux、nginx、PHP-FPM（Badooが開発）、memcached、MySQLなどの標準技術スタックを使用してWebページをレンダリングします。

ほとんどすべてのユーザーデータは、数百のMySQLサーバーに配置され、オーソライザーと呼ばれる「自己作成」サービスを使用してそれらに分散（「共有」）されます。 ユーザーIDとユーザーが配置されているサーバーのIDの大きな対応表を格納します。 ユーザーをサーバー間で分散するために「分割の残り」などの方法を使用しないため、データベースサーバー間でユーザーを簡単に移動できます。これは元々Badooアーキテクチャに組み込まれていました。







MySQLに加えて、セッション、サイトへの最後の訪問日、投票するユーザーの写真、検索するすべてのユーザーの基本データなど、さまざまなデータを保存する多くのC / C ++サービスがあります。



「デート」セクションに対応するサービスもあります。 他の国とは異なり、国ごとに1つのコピーが存在します。 RAMを大量に消費するため、384 GBを配置しても、すべてのデータを1つのサーバーに物理的に収めることができません。 さらに、彼は「自分の」データセンターにのみ「住んで」います。



さらに、すべてのユーザーに関する一般情報を保存する「中央」のMySQLデータベースと、すべてのBadooユーザーの情報を一度に保存する個別の課金データベースがあります。 さらに、アップロードされた写真とビデオ用に個別のリポジトリがあり、これらは個別の記事になります。 このデータも移動する必要があります。

問題の声明

タスクは非常に簡単に定式化されます。1営業日で全国からユーザーデータを転送し、移行中にこれらのユーザーがサイトを使用できるようにします。 「移行」した国の中で最大の国はタイで、約150万人の登録ユーザーがいます。 この数を8労働時間（および昼食）に分割すると、必要な移行率が得られます。これは1時間あたり約17万ユーザーです。

1営業日で国を移動するための要件は、この時点で何が起こるかという事実によって決まります。 たとえば、一部のサーバーまたはサービスを「横になったり」遅くしたりする可能性があります。その後、作成された負荷を減らすためにコードを「ライブ」編集する必要があります。 また、移行コードにエラーがあり、ユーザーの問題につながる可能性があります。これをすぐに確認し、プロセスを一時停止（またはロールバック）する機会があるはずです。 要するに、ユーザーを転送するためのこのような大規模な操作の実装には、何が起こっているかを監視し、操作中に必要な調整を行う「オペレーター」の存在が必然的に必要です。



技術的には、ユーザーごとに、このユーザーに関するデータを配置できるすべてのMySQLインスタンスのすべてのテーブルから選択を行い、C / C ++サービスに保存されているデータを転送する必要があります。 さらに、サービスの1つについては、デーモン自体を転送する必要があり、両方のデータセンターで実行中のデーモンインスタンス間でデータを転送する必要はありません。

データセンター間のデータ転送の遅延は約100ミリ秒なので、多数の小さなリクエストではなくストリームによってデータがダウンロードされるように操作を最適化する必要があります。 移行中、各ユーザーのサイトへのアクセス不能時間は最小限である必要があるため、プロセスは大きなバンドルではなく、各ユーザーに対して個別に実行する必要があります。 私たちが注目した時間は、特定のユーザーがサイトにアクセスできない状態が5分以内（1〜2分が望ましい）でした。

作業計画

1時間あたり170,000人のユーザーを移行する必要があり、各ユーザーの移行時間は約2〜3分であるという事実に基づいて、これらの条件を満たすために必要な並列実行スレッド数を計算しました。 各スレッドは1時間あたり平均25ユーザーを転送できるため、スレッドの合計数は6,800（つまり170,000 / 25）になりました。 実際、2,000スレッドのみに限定することができました。 ほとんどの場合、ユーザーはさまざまなイベント（たとえば、データセンター間のMySQLレプリケーション）の発生を単に「期待」します。 したがって、各スレッドは3人のユーザーを同時に処理し、そのうちの1人が何かの待機状態になったときに切り替えました。



各ユーザーの移行は、多くの連続したステップで構成されていました。 各ステップの実行は、前のステップの終了後に厳密に開始され、最後のステップが正常に完了したことを条件としました。

また、各ステップは反復可能であるか、「ロシア語で話す」べき等である必要があります。 つまり 各ステップの実行はさまざまな理由でいつでも中断される可能性があり、彼はどの操作を完了する必要があるかを判断し、これらの操作を正しく実行できる必要があります。

これは、移行のクラッシュや、内部サービスまたはデータベースサーバーの一時的な障害の際にユーザー情報を失わないために必要です。

アクションの構造とシーケンス

準備手順

現時点では、ユーザーを「移行中」としてマークし、バックグラウンドスクリプト（存在する場合）による処理の終了を待ちます。 この手順には約1分かかり、その間、別のユーザーが同じストリームで移行できます。



請求データの移行

国の移行中は、課金を完全にオフにしました。そのため、特別なアクションやロックは必要ありませんでした。データは中央のMySQLデータベースから別のデータベースに単純に転送されました。 各スレッドからこのデータベースへのMySQL接続が確立されたため、請求データベースへの接続の総数は2,000を超えました。



写真の移行

ここでは、写真を事前に別々に比較的簡単に転送する方法を見つけたため、少し「カウント」しました。 そのため、ほとんどのユーザーにとって、この手順では、転送の瞬間から新しい写真がないことを確認しただけです。



ユーザーマスタデータを入力する

このステップでは、各ユーザーのデータのSQLダンプを生成し、それをリモート側に適用しました。 同時に、このステップでは古いデータは削除されませんでした。



認証サービスのデータを更新する

オーソライザーサービスは、ユーザーIDとサーバーIDの間の通信を保存します。このサービスのデータを更新するまで、スクリプトはユーザーデータを古い場所に移動します。



古い場所からユーザーデータを削除する

DELETE FROMクエリを使用して、ソースMySQLサーバーのユーザーデータを消去します。



中央データベースからデータを転送する手順

雄弁な名前Misc（英語とは異なる-異なる）の下にある中央データベースの1つには多くの異なるテーブルが含まれており、各テーブルに対してユーザーごとに1つのSELECTとDELETEを実行しました。 貧弱なデータベースから毎秒40,000のSQLクエリを圧縮し、2,000以上の接続を開いたままにしました。



サービスからデータを転送する手順

原則として、すべてのデータはデータベースに含まれており、サービスはそれらに迅速にアクセスすることのみを許可します。 そのため、ほとんどのサービスでは、ある場所からデータを削除し、既に新しい場所にあるデータベースからの情報でデータを再入力しました。 ただし、ユーザーごとではなく、1つのサービス全体を単純に転送しました。サービス内のデータは単一のコピーに格納されていたためです。



保留中のレプリケーション

データベースはデータセンター間で複製され、複製が「到達」するまで、ユーザーデータは異なるデータセンターで一貫性のない状態になります。 したがって、すべてが正しく機能し、データが互いに整合するように、各ユーザーのレプリケーションの終了を待つ必要がありました。 また、このステップで時間を失わないようにするため（20秒から1分）、この時点で他のユーザーを移行するために使用されました。



最終ステップ

ユーザーに移行が完了したことを示すマークを付け、既に新しいデータセンターにあるサイトにログインできるようにします。

MySQLデータ転送

前述のように、ユーザーデータをMySQLサーバーに保存します。これは、各データセンターで約150個です。 各サーバーには複数のデータベースがあり、各データベースには数千のテーブルがあります（平均して、1000ユーザーごとに1つのテーブルを作成しようとします）。 データは、自動インクリメントフィールドをまったく使用しないか、少なくとも他のテーブルでそれらを参照しないように設計されています。 代わりに、user_idとsequence_idの組み合わせが主キーとして使用されます。user_idはユーザー識別子であり、sequence_idは同じサーバー内で自動的にインクリメントされる一意のカウンターです。 したがって、参照整合性を失わずに、各ユーザーに関するレコードを別のサーバーに自由に移動でき、古い自動インクリメントフィールドと新しい自動インクリメントフィールドの値の対応を構築する必要がありません。



データの移動は、ほとんどのMySQLサーバーで同じスキームに従って行われました（エラーが発生した場合、短い時間間隔後にステップ全体がクラッシュして再起動することに注意してください）。

• 「受信側」に進み、そこにすでにユーザーデータがあるかどうかを確認します。 ある場合、データのアップロードは成功しましたが、ステップは正しく完了していません。
• リモート側にデータがない場合は、ユーザーによるフィルタリングを使用して必要なすべてのテーブルからSELECTを作成し、先頭にBEGIN、末尾にCOMMITを含むSQLダンプを作成します。
• SSH経由でダンプをリモート側の「プロキシ」に入力し、mysqlコンソールユーティリティを使用して使用します。 COMMITリクエストがパスすることもありますが、ネットワークの問題などにより、回答を得ることができません。 これを行うには、最初に前回の試行でダンプがあふれているかどうかを確認します。 さらに、一部のデータベースでは、ユーザーのデータの不足は通常の状況であり、データ転送が実行されたかどうかを確認できるようにするために、そのような場合に必要に応じて確認した特別なテーブルにINSERTを追加しました。
• SELECTクエリにあった同じWHEREでDELETE FROMを使用して元のデータを削除します。 原則として、WHERE条件にはuser_idが含まれ、いくつかのテーブルでは、このフィールドはさまざまな理由で主キーの一部ではありませんでした。 可能であれば、インデックスが追加されました。 これが困難または非実用的であることが判明した場合、データを削除するときにuser_idが最初に選択され、次に主キーが削除されたため、ロックの読み取りが回避され、プロセスが大幅に加速しました。

対応する手順を実行したことがないことが確実にわかっている場合は、リモート側のデータの可用性のチェックをスキップします。 これにより、データを転送するサーバーごとに約1秒間勝つことができます（これは、送信されるパケットごとに100ミリ秒の遅延があるためです）。



移行中に、お話ししたい多くの問題に遭遇しました。

自動インクリメントフィールド（auto_increment）

自動インクリメントフィールドは請求データベースでアクティブに使用されるため、古いIDを新しいIDに「マッピング」する複雑なロジックを記述する必要がありました。

困難なのは、sequence_idはサーバー内でのみ一意であるため、上記のsequence_idのみが主キーに含まれるテーブルのデータを単純に転送できないことでした。 sequence_idをNULLに置き換えて新しい自動インクリメント値を生成することもできません。これは、まず、1つのテーブルにデータを挿入してsequence_idの生成を実行し、結果の値を別のテーブルで使用するためです。 次に、他のテーブルは、sequence_idを使用してテーブルを参照します。 つまり、データが転送されるサーバー上で適切な量の自動インクリメントフィールド値を取得し、ユーザーデータ内の古いsequence_idを新しいものに置き換え、完成したINSERTをmysqlコンソールユーティリティが後で使用するファイルに書き込む必要があります。

これを行うために、受信サーバーでトランザクションを開き、mysql_insert_id（）と呼ばれる必要な数の挿入を行いました。1つのトランザクションに複数の行が挿入された場合、最初の行の自動インクリメント値を返し、トランザクションをロールバックします。 この場合、トランザクションがロールバックされた後、データベースサーバーが再起動しない限り、自動増分は挿入された行数だけ増加したままになります。 必要な自動インクリメント値を受け取った後、適切な挿入リクエストを作成しました。これには、自動インクリメントの生成を担当するテーブルも含まれます。 ただし、これらのリクエストでは、トランザクションがロールバックされた後に形成された穴を埋めるために、自動インクリメントの値がすでに明示的に示されていました。



Max_connectionsとMySQLの負荷



各スレッドは、処理する必要があるサーバーへのMySQL接続を1つ作成しました。 したがって、すべての中央MySQLサーバーで2,000の接続を維持しました。 接続が増えると、MySQLは秋まで不適切に動作し始めました（バージョン5.1および5.5を使用します）。



一度、移行中に、中央のMySQLサーバーの1つ（非常に重い負荷がかかったサーバーの1つ）がクラッシュしました。 移行はすぐに中止され、転倒の原因を突き止めました。 RAIDコントローラーが単に「飛び出した」ことが判明しました。 管理者は、これはこのサーバーに与えた負荷によるものではなく、「堆積物が残った」と言っていましたが。



InnoDB、MVCC、およびDELETE FROM：落とし穴



すべてのデータをInnoDBに保存し、転送されたすべてのデータがすぐに削除されたため、一部のサーバーのテーブルにあるキューをレーキするすべてのスクリプトの速度が低下し始めました。 空のテーブルからのSELECTが数分かかったのを見て驚いた。 MySQLパージスレッドには、削除されたレコードをクリアする時間がありませんでした。キューを持つテーブルが空であるという事実にもかかわらず、まだ物理的に削除されず、フェッチ時にMySQLによって単にスキップされた多くの削除されたレコードがありました。 レコードをクリーニングするためのキューの長さの定量的な説明は、SHOW ENGINE INNODB STATUSと入力して、行履歴リストの長さを調べることで取得できます。 私たちが観察した最大の値は、数百万件のレコードです。 DELETE FROMを使用してInnoDBテーブルから多くのレコードを慎重に削除することをお勧めします。 これを回避し、可能であれば、たとえばTRUNCATE TABLEを使用することをお勧めします。 TRUNCATE TABLE形式のクエリはテーブルを完全にクリアし、これらの操作はDDLであるため、削除されたレコードは元に戻す/やり直しログに追加されません（InnoDBはDDL操作のトランザクションをサポートしません）。

DELETE FROMを使用してすべてのデータを削除した後、テーブルから選択を行う必要がある場合は、主キーにBETWEEN条件を課そうとします。 たとえば、auto_incrementを使用する場合、テーブルからMIN（id）およびMAX（id）を選択してから、それらの間のすべてのレコードを選択します。これは、何らかの制限またはid> Nの形式の条件のいずれかのみを持つレコードを選択するよりもはるかに高速ですまたはid <N 。 InnoDBは削除されたレコードをスキップするため、MIN（id）およびMAX（id）を受け取るリクエストには非常に長い時間がかかります。 ただし、一方で、キー範囲のクエリは通常と同じ速度で実行されます。削除されたレコードは、そのようなクエリ中に選択に含まれません。



また、すべてのクエリが同じクエリを持ち、このテーブルにuser_idインデックスが存在しない、DELETE FROM WHERE user_id =という形式の「ハング」クエリが多数あることに驚きました。 判明したように、レコードの削除時にFULL SCANテーブルが作成され、分離レベルがREPEATABLE READ（デフォルト）である場合、MySQLバージョン5.1（およびそれよりも程度は低いが5.5）はそのようなクエリのスケーラビリティが非常に低くなります。 同じレコードに対してロックの競合が非常に激しいため、クエリの処理時間が雪崩のように増加します。

問題の可能な解決策の1つは、トランザクションの分離レベルREAD COMMITEDを設定することです。これにより、データが削除され、InnoDBはWHERE句に収まらない行にロックをかけません。 これがどのように深刻な問題であったかを説明するために、移行中に撮影したスクリーンショットを次に示します。 スクリーンショットのtmp.tiw_fixテーブルには、約60のエントリのみが含まれています（！）。user_idのインデックスは含まれていません。

ユーザーストリームの割り当て

最初は、特定のユーザーがどのサーバーにいるかに関係なく、ユーザーをフローごとに均等に分散しました。 また、各スレッドでは、対応するスレッドに割り当てられたユーザーを移行するために満たす必要があったすべてのMySQLサーバーへの接続を開いたままにします。 その結果、さらに2つの問題が発生しました。

• MySQLサーバーの速度が低下し始めると、このサーバーに住んでいるユーザーの移行が遅くなりました。 他のすべてのスレッドが実行を続けると、問題のサーバーにいるユーザーにも徐々に到達します。 徐々に、このサーバーに蓄積されるスレッドの数が増加し、さらに遅くなり始めました。 サーバーのクラッシュを防ぐため、操作中にコードに一時的なパッチを導入し、さまざまな「クランチ」を使用してこのサーバーの負荷を制限しました。
• 必要なすべてのMySQLサーバーへの各フローでMySQL接続を開いたままにしていたため、各スレッドはすべてのMySQLサーバーへの多数の開いた接続を持ち、max_connectionsに依存し始めるという結論に徐々に達しました。

最終的に、スレッドごとにユーザーを配布するためのアルゴリズムを変更し、各ユーザーに1つのMySQLサーバーのみに住んでいるユーザーを割り当てました。 したがって、このサーバーの「ブレーキ」の場合の雪崩のような負荷増加の問題、および一部の弱いホストでの同時接続が多すぎる問題をすぐに解決しました。

続行するには...

次のパートでは、ユーザーの写真を事前に移行した方法と、写真を使用してサーバーの負荷を制限するために使用したデータ構造について説明します。 その後、2つのデータセンターの16台のサーバーで2,000の同時実行移行フローを調整する方法と、それをすべて機能させるために使用された技術ソリューションについて、さらに詳しく説明します。



Yuri youROCK Nasretdinov、PHP開発者

Anton antonstepanenko Stepanenko、チームリーダー、PHP開発者