Badooで最も負荷の高いデータベースの例による、ダウンタイムのないリレーショナルデータベースの最適化

高負荷の状態では、リレーショナルデータベースの最適化の複雑さは桁違いに高くなります。これは、さらに強力なハードウェアを購入すると高価になり、長時間データベース変更プロセスやデータ移行のために夜間にアプリケーションをオフにする方法がないためです。



最近、アプリケーション用にPHPコードを最適化する方法について話しました。 記事の順番は、単一の要求を失うことなく、Badooで最もロードされ重要なデータベースの内部構造を完全に変更する方法についてです。

患者さん

ユーザーデータベース（UDB）は、Badooへのほとんどすべてのリクエストを開始するサービスです。 いくつかの問題を解決します。まず、認可が行われる基本的なユーザーデータの中央リポジトリです（たとえば、email、user_id、facebook_id）。 このデータの保存に加えて、サービスは一意性制御を提供します（そのため、同じ電子メール、facebook_idなどを持つ2人のユーザーはシステムに登録できません）。 そして、同じサービスは、何千ものシャードのうち、他のすべてのユーザーデータを含むものに関する情報を提供します。



2018年末には、UDBは8億人以上のユーザーからのデータを保存し、約1 TBのディスクスペースを占有します。 これらはすべて、各データセンターのマスタースレーブMySQLサーバーのペアによって処理されます。 合計で、1秒あたり140,000を超えるリクエストを処理します。



コードはユーザーデータが存在するシャードを見つけることができないため、UDBの低下はすべてのBadooのアクセス不能を意味します。 したがって、信頼性と可用性のために大きな要求があります。



この特異性のため、ストレージ構造を変更するのは非常に費用がかかるため、2013年のUDBの設計は非常に真剣に考えました。 ただし、時間の経過とともに、要件と負荷プロファイルが変化します。 システムを新しい要件と負荷レベルに適合させるために、多くの小規模で単純な変更が行われましたが、残念ながら、そのような変更は最も効果的ではありません。 そして、次のハックや高価なハードウェアの購入の代わりに、よりグローバルに最適化を行う方が賢明だった日が来ました。 さらに、このパスの主要な段階を検討します。

非侵襲的な最適化

大規模でロードされたデータベースの構造に変更を加えると、データ移行プロセスが複雑になるため、非常に費用がかかります。 したがって、まず、データ構造に影響を与えず、コードとSQ​​Lクエリに限定されるすべての最適化オプションを使い果たす必要があります。 おそらく、これは数年間、過剰な作業負荷の問題を延期するのに十分であり、それにより現時点でビジネスにとってより重要なことを行うことができます。



システムをよく理解すればするほど、そのような最適化のアプローチを見つけやすくなります。 役立つすべてのメトリックを収集してください。 これは、CPU使用率やRAM使用率などのシステムメトリックスや特定のデータベースのメトリックスだけでなく、最適化されたデータベースに関連付けられているアプリケーションのアプリケーションレベルのメトリックスに関するものでもあります。 異なるタイプの操作には、1秒あたりいくつのリクエストがありますか？ 応答時間はどのくらいですか？ 入出力のサイズは？ これらのメトリックによって、最適化の成功を判断できます。 データベースサーバーのCPU使用率をわずかに削減する最適化が必要になることはほとんどありませんが、同時にアプリケーションの応答時間を10倍に増やします。







UDBの追加のアプリケーションレベルメトリックの収集を開始すると、実行された操作のどれが負荷の80％を生成し、研究の最初の候補であり、どの操作がほとんど使用されないかを理解できました。



最も頻繁な操作（特定の条件を満たすユーザーの取得）の詳細な分析により、利用可能なすべてのユーザーデータがデータベースから要求されているにもかかわらず、実際には95％のケースでuser_idのみが使用されていることがわかりました。 このケースをテーブルから1列のみを抽出する別のAPIメソッドに分離するだけで、カバリングインデックスの使用から恩恵を受け、これを使用してデータベースサーバーからCPU負荷の約5％を除去できました。



別の頻繁な操作の分析では、HTTP要求ごとに実行されるという事実にもかかわらず、実際には、それが取得するデータは非常にまれであることが示されました。 このリクエストをレイジーモデルに変換しました。



最適化プロジェクトの場合のメトリックの主な目標は、データベースをよりよく理解し、最も太い部分を見つけることです。 負荷プロファイルの1％未満を占めるクエリの最適化に多くの時間と労力を費やすことは意味がありません。 負荷のプロファイルを理解できるメトリックがない場合は、それらを収集します。 このようなコード側の最適化により、消費されたデータベースの80％からCPU使用率の約15％を削除することができました。

テストのアイデア

ロードされたデータベースの構造を変更して最適化する場合は、理論上非常に有望に見える最適化でも実際にはプラスの効果が得られない可能性があるため（場合によってはマイナスの効果もあるため）、テストベンチでアイデアを確認することから始めます。 そして、本番環境での長いデータ移行後にのみ、このことを知りたくないでしょう。



スタンド構成が実稼働構成に近いほど、信頼性の高い結果が得られます。 重要なポイントは、スタンドの正しい負荷を確保することです。 ランダムまたは同じクエリを実行すると、誤った結果が生じる可能性があります。 最適なオプションは、実稼働からの実際の要求を使用することです。 UDBの場合、ファイル内のJSONログのみの形式で、API読み取りリクエスト（パラメーターを含む）の10回ごとに本番環境からログを記録しました。 1日で、7億件のリクエストからサイズが65 GBのログを収集しました。



読み取り要求の数と比較して、レコードをテストしませんでした。これは非常に小さく、負荷に影響しません。 ただし、これはあなたの場合には当てはまらないかもしれません。 書き込み要求をテストベンチにロードする場合、書き込み要求をスキップするとテストベンチで一貫性エラーが発生する可能性があるため、各要求を収集する必要があります。



次のステップは、スタンドでログを正しく失うことです。 スクリプトクラウドから実行されている400人のPHPワーカーを使用して、高速キューから収集されたログを読み取り、リクエストを順次実行しました。 この場合、キューは厳密に定義された速度の別のスクリプトで満たされます。 アイデアをテストするために、x10の速度を使用し、10回のリクエストごとに本番から収集したという事実を掛け合わせて、本番と同じ量のRPSを提供しました。







これらの係数を使用すると、テストベンチでのすべての負荷降下を伴う生産日がわずか2時間半で飛ぶことがわかります。



したがって、たとえば、クエリログで半日x5の速度（運用からの負荷の50％）で実行した最初のテストは次のようになりました。







同じツールを使用して障害テストを実行できます。つまり、スタンドのベースが劣化し始めるまで速度（およびRPS）を上げます。 これにより、データベースがどれだけの負荷に耐えられるかを明確に理解できます。



新しいデータスキーマをテストした後、元のデータベース構造で制御テストを実施することも重要です。 その結果と実稼働環境での現在のパフォーマンスが大きく異なる場合は、まずその理由を理解する必要があります。 テストサーバーが正しく構成されておらず、負荷テストデータが信頼できない可能性があります。



また、新しいコードが正しく機能していることを確認する価値があります。 ジョブを実行しないクエリのパフォーマンスをテストすることはほとんど意味がありません。 古いAPIと新しいAPIが同じAPI呼び出しで同じ値を返すかどうかを確認する統合テストが役立ちます。



すべてのアイデアに関する結果を受け取った後は、価格と品質のバランスが最適なオプションを選択し、生産のための新しいスキームを導入するだけです。

スキーマの変更

まず、サービスの動作を停止せずにデータスキームを変更することは、常に非常に難しく、費用がかかり、リスクが高いことに注意してください。 したがって、構造の変更中にアプリケーションを停止する機会がある場合は、それを行ってください。 残念ながら、UDBの場合、これを買う余裕はありませんでした。



回線変更の複雑さに影響を与える2番目の要因は、変更の計画規模です。 テーブルに提案されたすべての変更が単なる変更を超えない場合（たとえば、新しいインデックスまたは列のペアを追加する場合）、MySQLまたは代替スレーブのpt-online-schema-changeやgh-ostなどの典型的なプロセスでそれらを変更してから場所を変更できます。



私たちのケースでは、1つの巨大なテーブルの縦方向のシャーディングで、他の列やインデックス、および異なる形式のデータを含む約12の小さなもので優れた結果が示されました。 通常のツールを使用したこのような変換は、もはや不可能です。 それではどうしますか？



次のアルゴリズムを適用しました。

1. 現在のデータを含む古いスキームと新しいスキームの両方が同時に存在する状態を達成しています。 記録は両方に行われ、同時に両方のバージョンでデータの一貫性が保証されます。 この項目については、以下で詳しく検討します。
   
   
2. 読み込み全体を新しい回路に徐々に切り替えて、負荷を制御します。
   
   
3. 古いスキームの記録をオフにして削除します。
   
   

このアプローチの主な利点：

• 安全性：最終段階まで瞬時にロールバックする可能性があります（何か問題が発生した場合は、読み取り値を古いスキームに戻すだけです）。
  
  
• データ移行中の完全な負荷制御。
  
  
• 古い回路の大きなテーブルを大きく変更する必要はありません。
  
  

ただし、欠点もあります。

• 移行プロセス中に両方のバージョンのスキーマをディスク上に保持する必要があります（スペースが少なく、移行するテーブルが非常に大きい場合、これは問題になる可能性があります）。
  
  
• 移行プロセスをサポートするための一時的なコードがたくさんあります。移行プロセスは完了すると切断されます。
  
  
• 2つのスキームから並行して読み取ることにより、キャッシュをウォッシュすることができます。 古いバージョンと新しいバージョンがRAMをめぐって競合する恐れがあり、サービスの低下につながる可能性があります（実際、これにより実際に追加の負荷が発生しましたが、移行はオフピークで実行されたため、問題は発生しませんでした）。
  
  

このアルゴリズムの主な難点は最初の点です。 詳細に検討します。

同期を変更

静的データの移行は特に難しくありません。 ただし、データベースの移行中に記録全体を停止できない場合はどうなりますか？



新しいスキームの同期を実現するためのいくつかのオプションがあります。ログのローリングによる移行と、べき等の記録の移行です。

データスナップショットを移行した後、次の変更のログを再生します

各データ更新トランザクションは、アプリケーションレベルでトリガーを介して特別なテーブルに記録されるか、レプリケーションbinlogがログとして使用されます。 そのようなログを取得したら、ログ内の位置を記憶して、トランザクションを開いてデータスナップショットを移行できます。 その後、収集されたログを新しいスキームに適用し始めます。 同様に、たとえば、人気のあるMySQL Percona XtraBackupバックアップツールは動作します。



新しいスキームが現在のレコードへのログに追いついた後、最も重要な段階が始まります：古いスキームでの記録を短時間一時停止する必要があり、利用可能なログ全体が新しいスキームに適用されることを確認します。これは、スキーム間のデータが一貫していることを意味します、アプリケーションレベルで、両方のソースで一度に記録を有効にします。



このアプローチの主な欠点は、操作ログを何らかの方法で保存する必要があることです。それにより、複雑なスイッチングプロセスで負荷が発生する可能性があります。また、何らかの理由で回路が不整合になった場合に記録を破る可能性があります。

べき等レコード

このアプローチの主なアイデアは、変更が完全に同期される前に古いスキームへの書き込みと並行して新しいスキームへの書き込みを開始し、残りのデータの移行を完了することです。 同様に、通常、新しい列は大きなテーブルに入力されます。



同期記録は、データベーストリガーとソースコードの両方に実装できます。 いずれにせよ、最終的に新しいスキームにデータを書き込むコードを記述する必要があり、コード側での移行の実装により多くの制御が提供されるため、コードでこれを正確に行うことをお勧めします。



考慮すべき重要な点は、移行が完了するまで、新しいスキームは一貫性のない状態になることです。 このため、新しいテーブルを更新するとデータベース定数（外部キーまたは一意のインデックス）に違反するシナリオが可能になりますが、現在のスキームの観点からは、トランザクションは完全に正しいため、実行する必要があります。



この状況では、移行プロセスにより、正常なトランザクションがロールバックされる可能性があります。 この問題を回避する最も簡単な方法は、すべてのリクエストにIGNORE修飾子を追加して、新しいスキームにデータを書き込むか、そのようなトランザクションのロールバックをインターセプトし、新しいスキームに書き込まずにバージョンを実行することです。



この場合のi等記録による同期アルゴリズムは次のとおりです。

1. 互換モード（IGNORE）の古いスキームでの記録と並行して、新しいスキームでの記録を有効にします。
   
   
2. 新しいスキームを徐々にバイパスし、一貫性のないデータをキャプチャするスクリプトを実行します。 その後、両方のテーブルのデータを同期する必要がありますが、条項1で競合する可能性があるため、これは不正確です。
   
   
3. データ整合性チェッカーを起動します-トランザクションを開き、新旧のスキームの対応を比較する行を順次読み取ります。
   
   
4. 競合がある場合は、再接続して段落3に戻ります。
   
   
5. 両方のスキームのデータが同期されていることをチェッカーが示した後、もちろん、微妙なニュアンスを逃さない限り、スキーム間にさらなる不一致はないはずです。 したがって、しばらく（たとえば、1週間）待機してから、制御チェックを実行します。 彼がすべてが正常であることを示した場合、タスクは正常に完了し、読み値を翻訳できます。
   
   

結果

データ形式を変更した結果、メインテーブルのサイズを544 GBから226 GBに減らすことができました。これにより、ディスクの負荷が減り、RAMに収まる有用なデータの量が増えました。



全体として、プロジェクトの最初から、記載されているすべてのアプローチを使用して、ピークトラフィック時のデータベースサーバーのCPU使用率を80％から35％に削減することができました。 その後のストレステストの結果は、現在の負荷の増加率で、少なくとも3年間は既存のハードウェアにとどまることができることを示しました。



1つの巨大なテーブルをいくつかに分割すると、データベースの将来の変更を行うプロセスが簡素化され、BIのデータを収集するスクリプトも大幅に高速化されました。