Facebookの「MySQL 8.0」への移行作業、エンジニアが詳細をブログに

　Facebookは「MySQL 8.0」への移行作業で同社が経験した数多くの頭痛の種と、タイムラインを同社ブログで概説した。それを読むと、エンジニアリング関連の輝かしい経歴と規模を有する同社にとってもこの種のアップグレードが困難なものになり得ることがよく分かる。

　Facebookのエンジニアリングチームは投稿の中で、MySQLのバージョン5.6から8.0へのアップグレードの概要を説明した。「MySQL」は同社のストレージエンジンやレプリケーション、ワークロードの基幹インフラを担っている。同社はこのオープンソースのデータベースをカスタマイズして機能を追加し、レプリケーション時の互換性を保証し、パフォーマンスを向上させつつ変更を最小限に抑える必要があった。

　この投稿は、企業がオープンソースのソフトウェアをカスタマイズしたとしても、最終的にプロプライエタリーなシステムと同様の複雑さを抱えることになる可能性を浮き彫りにしているという点で一読の価値がある。以下は、MySQL 8.0へのアップグレードに関する詳細を記した同社の投稿で注目すべき点だ。

• このプロジェクトは完遂までに2年を要した。
• 今回の作業に先立つ直近の大規模アップグレードは「MySQL 5.6」へのアップグレードであり、ロールアウトまでに1年以上を要した。また「MySQL 5.7」がリリースされた際には、同社独自の「MyRocks」ストレージエンジンの開発が進められていたために、アップグレードを見送っていた。
• MySQL 8.0が発表された時点ではMyRocksの開発が完了していたため、Facebookはアップグレードを実施し、同社のストレージエンジンの機能向上を図ることにした。
• MySQL 5.6のカスタマイズブランチにはMySQL 8.0にポートすべきコードパッチが1700件存在していた。そしてこの取り組みは、FacebookがMySQLに新たに追加する機能と、5.6のコードベースに対して発生し続けるフィックスによって複雑なものとなった。
• このアップグレードでは、5.7を完全にスキップしたかたちで5.6から8.0への移行が進められた上、一部のAPIを非推奨、あるいは完全に削除した。このため旧式のAPIを使用していたアプリケーションはアップデートが必要になった。
• カスタマイズコードの中にはドキュメントが残されていないものもあった。Facebookによると、コードのほとんどには優れたコメントがあり、ドキュメントも用意されていたという。その一方、ドキュメントがないコードもあったため、同社は古いドキュメントや投稿、コードのコメントを探し出して、その更新履歴を洗い出す必要があった。
• 最も複雑な機能では、MySQL 8.0への著しい変更が必要になり、解決しなければならない互換性の問題が存在していた。
• 同社は最終的に、2300件を超えるパッチを評価し、そのうちの1500件をMySQL 8.0へとポートした。

　このアップグレードは価値あるものだったのだろうか。Facebookは、MySQL 8.0へのアップグレードによって取り得る選択肢が広がったと主張している。とはいえ、同社は今後のアップグレードについて早々に検討し始めているのかもしれない。