GitHub、1200台以上のMySQL 5.7を8.0へアップグレード サービス無停止のまま成功させる

[新野淳一，ITmedia]

この記事は新野淳一氏のブログ「Publickey」に掲載された「GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる」（2023年12月12日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。

　米GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。

　そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。

参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている

　そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことを明らかにしました。

　同社がどのような作業を行ったのか、ブログのポイントを紹介していきましょう。

GitHub.comのサービスを止めずにMySQLをアップグレードする

　GitHubがデータベースをアップグレードするのはMySQL 5.7のサポートが終了することが主な理由で、MySQL 8.0へアップグレードすることにより、セキュリティフィクスや最新機能を得ることができるためだとされています。

　対象となるMySQLサーバはMicrosoft Azure上の仮想マシンやベアメタルサーバによる1200台以上のホストで稼働し、1つのプライマリと複数のレプリカからなる50以上のクラスタ構成によって高可用性と高性能を実現しています。

　このクラスタ群には300TB以上のデータが保存され、1秒当たり550万回のクエリが発行されています。

　GitHubのサービスレベルを維持しつつ、このMySQL群をMySQL 8.0にアップグレードする必要があるわけです。

　前提条件としてテストは十分に行いつつも、すべての障害をあらかじめ完全に防ぐことはできないため、アップグレードの途中で何かあったときにはサービスを止めることなくMySQL 5.7にロールバックできるようにする必要がありました。

　また、障害が発生した場合の影響範囲を狭めるため、アップグレードはクラスタごとに行う必要がありました。これは全体のアップグレードが終了するまでにある程度の時間がかかること、そしてアップグレード期間中はMySQL 5.7とMySQL 8.0が混在することを意味します。そのため、この複数バージョンの環境下でも安定して運用を続けられることを担保する必要がありました。

　同社が準備を始めたのが2022年7月。ここから1年以上かけてMySQL 8.0へのアップグレードを行うことになります。

レプリカサーバ群を順次MySQL 8.0へインプレースアップグレード

　同社は最初に次のようなことを行ったと説明しています。

• MySQL 8.0のベンチマークを行い、適切な設定を決定する
• 5.7と8.0のあいだで異なる構文や新しい構文を認識する
• 継続的インテグレーションにMySQL 8.0を追加し、バグや非互換を検出して対応
• アップグレードスケジュールを策定し、社内に伝達
• 問題を追跡するためのプロジェクトを作成

　アップグレード作業では、次のような段階的なアップグレードを採用しています。

1. MySQL 5.7のレプリカサーバを1台、MySQL 8.0へインプレースアップグレード
2. アプリケーションからは接続せず、オフライン状態で安定動作を確認する
3. 安定動作を確認後にオンラインとし、クエリのレイテンシなどメトリクスを監視
4. それ以外のレプリカサーバもMySQL 8.0へ順次アップグレード
5. プライマリはまだMySQL 5.7のまま。ロールバック用のMySQL 5.7のレプリカもオンライン状態で十分残しておく
6. MySQL 5.7のレプリカサーバをオフラインへ

プライマリサーバをMySQL 8.0へ置き換えアップグレード

　次はプライマリサーバをMySQL 8.0へアップグレードする準備です。

• プライマリ候補となるMySQL 8.0サーバをクラスタに追加し、現プライマリのMySQL 5.7のレプリカとする
• ロールバック用のMySQL 5.7のレプリカサーバ群と、稼働中のMySQL 8.0のレプリカサーバ群の2系統がプライマリ候補となるMySQL 8.0サーバの下流に配置される

　図にすると次のようなトポロジになると説明されています。

　この状態から、オーケストレーターによる正常なフェイルオーバーによってプライマリ候補となるMySQL 8.0サーバをプライマリサーバへ昇格させることで、プライマリのMySQL 8.0へのアップグレードを実行します。

　少なくとも24時間監視し、プライマリが正常にMySQL 8.0にアップグレードされ、ロールバックする必要がなくなったと判断できた段階でMySQL 5.7サーバ群を削除します。

運用の自動化や自己修復機能に投資していく

　こうした作業により、MySQL 8.0へのアップグレードが成功したと説明されました。GitHubはこのアップグレード作業から、可観測性やテストが重要であるとあらためて学んだと、次のように書いています。

This upgrade highlighted the importance of our observability platform, testing plan, and rollback capabilities. The testing and gradual rollout strategy allowed us to identify problems early and reduce the likelihood for encountering new failure modes for the primary upgrade.

このアップグレードでは、観測可能なプラットフォーム、テスト計画、ロールバック機能の重要性が浮き彫りになりました。テストと段階的なロールアウト戦略は早期に問題を特定し、プライマリのアップグレードにおいて新たな障害に遭遇する可能性を減らすことができました。

　その上で、アップグレードにはマニュアル作業が非常に多いため、将来的にはこうしたマニュアル作業を減らしていきたいとし、そのために運用タスクの自動化や自己修復機能などに投資していくとしています。