UberがMySQLフリートのメジャーアップグレードを完了、パフォーマンスとセキュリティを強化

原文リンク(2024-10-14)

Uberは、バージョン5.7から8.0にアップグレードすることで、MySQLフリートデータベースを大幅に改善した。チームは、MySQLの新しいバージョンで改善されたパフォーマンスと同時実行性を利用したかった。また、MySQL 5.7が2023年10月に使用期限を迎えるためだった。この作業には1年以上かかり、3リージョンの19のプロダクションゾーンで2,100以上のクラスタと16,000以上のノードをアップグレードした。

Uberのブログ記事でSiddharth Singh氏らは、MySQLのインフラにはペタバイト級のデータが複数あり、毎秒300万以上のクエリを処理していると説明している。そのため、アップグレード中の中断を最小限に抑えることが不可欠だった。これを支援するため、Uberのエンジニアリング・チームは、各クラスタを複数段階のアップグレード・プロセスに誘導するシステムを自動化し、手動による操作を不要にした。Singh氏は続けて、インプレース・アップグレードではなく、サイドバイサイドのアップグレード戦略を選択した経緯を説明する。この決定には、ダウンタイムを最小限に抑え、リスクを低減し、より良いテストを可能にするというニーズがあった。

サイドバイサイドのアップグレードプロセスにはいくつかの段階があった。まず、クラスタ内の各 MySQL 5.7ノードに対して、同じリージョンまたはゾーンに対応する MySQL 8.0のレプリカノードを追加した。その後、システムのパフォーマンスを観察し、問題を検出するために1週間の監視期間が設けられた。この「ソーク期間」が終了すると、エンジニアは5.7レプリカノードからトラフィックを迂回させ、MySQL 8.0ノードを各クラスタのプライマリステータスに昇格させた。最後に、すべてのMySQL 5.7ノードがクラスタから削除され、バージョン8.0への移行が完了した。

システムの安定性とデータの整合性は、アップグレードの最重要課題であった。チームの計画では、MySQL 8.0ノードをプライマリ・ステータスに昇格させるのに十分な自信が持てるまで、サービスの低下が検出された場合は直ちにMySQL 5.7にロールバックすることにした。その後、5.7へのロールバックはサポートされないため、回避する必要があった。

アップグレードには課題があった。MySQL 8.0へのアップグレード後、一部のクラスタのクエリ実行プランが変更され、レイテンシとリソース消費量が増加した。データベースソフトウェア会社のPerconaと協力し、Uberのチームは影響を受けるクラスタを特定し、修正を実施した。その他にも以下のような問題があった。

• いくつかの互換性のないクエリと設定。

• デフォルトの文字セットと照合順序設定の変更。

• MySQL 8.0との互換性のためにクライアント・ライブラリをアップグレードする 必要性。

この重要なアップグレードを大規模に実施するための最適な方法についての話を共有しているのは、Uberだけではない。今年初めにInfoQが取り上げたように、GitHubは5.7から8.0への同様のアップグレードを行い、その結果の一部も共有した。アップグレードから得られた多くの知見の中で、GitHubは8.0から5.7への後方レプリケーションが、異なるフレームワークや言語を使用するクライアントで使用された場合にロールバックの潜在的な期間が短くなるなどの問題にも直面した。また、レプリケーションのバグが発生したり、大きなWHERE IN値を含むクエリを実行した際にクラッシュが発生したりした。

PerconaのPrzemysław Malkowski氏も、MySQLを8.0にアップグレードする際に障害を回避する方法について詳細に投稿しており、アップグレード前に書き込み関連のワークロードをテストするのは困難であることを強調し、データ損失、遅いクエリ、ダウンタイムの可能性、クライアントアプリケーションの非互換性などの可能性を強調している。Malkowski氏はまた、万が一ダウングレードが必要になった場合の方法についても説明している。

MySQL 8.0へのアップグレードによって恩恵を受けた組織もある。ArzoooのJyoti Ranjan Parida氏はMediumの記事で、アップグレードの利点について説明している。

• ウィンドウ関数、共通テーブル式、JSONの強化などの新機能が追加。

• インデックスとクエリの実行の改善によるパフォーマンス向上。

• パスワードの有効期限ポリシーの改善。

• リソース管理の改善と、より効率的なクエリのサポート。

• グループ・マルチソース・レプリケーション。

Parida氏はまた、アップグレードの際に注意すべき点についても説明し、以下のような前提条件を包括的に挙げている。

• データ型や関数が古くなっていないか確認する。

• 孤立したファイルや無効なトリガーを削除する。

• サポートされていないパーティションテーブルを避ける。

• キーワード違反を解決する。

• 新しいデータ・ディクショナリとの名前の衝突をなくす。

• 旧式のSQLモードを更新する。

• ENUM/SET列の長さをチェックする。

• 共有テーブルスペースからテーブル・パーティションを再配置する。

• ASCまたはDESCを使用する古いGROUP BY句を修正する。

• 長い外部キー名を短くする。

• utf8mb3からutf8mb4への変換を検討し、Unicodeサポートを改善する。

このような障害にもかかわらず、Uberのアップグレードは大幅なパフォーマンス改善をもたらした。サーバー側のベンチマークでは、高い同時実行レベルで、インサートで29%、リードで33%、アップデートで47%のレイテンシの改善が見られた。クライアント側では、一部のクエリが78%高速化し、データベース全体のロック時間が94%短縮した。

メリットと課題を慎重に検討することで、移行を成功させ、リスクを軽減し、サービスの中断を最小限に抑えた。

• Siddharth Singh、Sriram Rao Udupi、Raja Sriram Ganesan、Debadarsini Nayak (Uber)