LINE株式会社およびヤフー株式会社は、2022年11月17日・18日の2日間にわたり、技術カンファレンス「Tech-Verse 2022」をオンライン（ライブストリーミング形式）にて開催しました。特別連載企画「Tech-Verse 2022 アフターインタビュー」では、発表内容をさらに深掘りし、発表で触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「半年で1,800台のMySQLインスタンス移行を行うための自動化ツール」です。
LINEでは6,000台以上のMySQLインスタンスを管理しており、MySQLのバージョンアップやシャーディングといったMySQLの移行（マイグレーション）業務に多くの時間を費やしています。また、MySQL 5.6のEOLやCentOS 6のEOS、IDCRoomの引っ越し、古いプラットフォームのEOSなどの理由で、2023年3月までに1,800台のMySQLインスタンスを移行しなければなりません。
LINEのMySQL1チームはDBAの作業工数を削減するために、各サービスの開発者自身が画面操作のみで簡単にMySQLを移行できるWebシステム「MUH-Prod（MySQL Upgrade Helper- Production ）」を開発しました。今回はセッションで語られた内容についての秘話を、MySQL1チームに所属するMySQL DBAの原地芳暢が解説します。
MySQL移行のノウハウがチーム内に蓄積されている
――まずチームの役割と、原地さんの業務内容を簡単に教えてください。
MySQL1チームはその名の通り、LINEの主に日本における各種サービスのMySQLの運用や、運用を自動化・効率化するツールの開発をしています。1チームという名前が示す通りMySQL 2チームもあり、LINEの韓国拠点であるLINE Plusのメンバーが所属しています。MySQL2チームは主に韓国で提供している各種サービスのMySQLの運用や、プライベートクラウド「Verda」のMySQLに関する業務などを担当しています。
MySQL1チームとMySQL2チームは相互に連携を取っており、片方のチームが何かのツールを作った際には、もう片方のチームもそのツールを業務で活用するケースがあります。私自身の業務内容としては、MySQLの運用と各種ツールの開発を担っています。
――今回のインタビューでは「Tech-Verse 2022」のセッションをふまえ、より深掘りした内容を伺います。セッション内では「MUH-Prod」のアーキテクチャとして、フロントエンドの「MUH-Web」が存在しており、ここから後段にある複数のAPIを呼び出している旨を説明されていました。このように、役割ごとに別々のAPIを作成する設計にしたことによって生まれた利点はありますか？
実はもともと、各APIはそれぞれを単独で利用できるサービスとして作っていました。後から各サービスにAPIのエンドポイントを生やして、Webサービスから呼び出せるような作りにし、「MUH-Prod」に転用したという流れです。結果的に、マイクロサービス的な構造になっています。それぞれを独立したサービスとして構築したことで、一つひとつの設計がシンプルになりました。
他にAPIを機能ごとに分けた利点としては、特定機能だけを他の用途に転用しやすいことが挙げられます。この図のなかでいえば、MyInfo APIがその典型ですね。これはスロークエリの情報やInnoDBのステータスログなど、MySQLのさまざまな情報を取得できるAPIです。
私たちは運用負荷軽減のために、MySQLに関する情報の参照や簡易的な操作ができるiruka_sanというSlack Botを活用しています。そして、iruka_sanはその処理のなかでMyInfo APIを呼び出しています。
――「MUH-Prod」では、MySQL移行を複数のStepに分割していること、そしてInspectionやSet Variablesの工程ではバージョン間の仕様の差異を吸収するための処理を行っていることなどが、セッション内で述べられていました。これらの工程においては、MySQL1チームが持つ知見がフル活用されていると感じます。MySQL1チームはどのようにして、MySQL各バージョンの差異についての知識を習得してきたのでしょうか？
LINE社内ではこれまで、各メンバーが膨大な数のMySQLの移行を実施してきました。その過程で多くの知識を得ています。またLINEには、各プロジェクトのワークプランや発生した問題などをWikiに記録する文化があります。そうした各メンバーの持つノウハウやWikiの記載内容をベースにしつつ、LINE PlusのMySQL2チームとも情報連携をしながら「MUH」の開発プロジェクトを推進してきました。
また、LINEではMySQLのConfigファイルの設定を社内で標準化しています。そのため、MySQLの新しいバージョンがリリースされた際には、社内で利用する前に必ず公式のリファレンスなどを読んで、MySQLの各パラメータの役割や設定すべき値を確認します。その工程を通して、MySQLのパラメータの知識も培われてきました。
――読者のなかには、原地さんのチームのメンバーのようにMySQLに詳しくなりたい方もいるはずです。そうした方が、MySQLのバージョン間における仕様の差異についての知識を効率的に身につける方法はあるでしょうか？
これまで数多くのDBAの方々が技術カンファレンスに登壇して、MySQLのバージョン間における仕様の差異について発表しています。その資料を読んで学習することがおすすめです。私自身も、同僚であるyoku0825さんの作った資料を、これまで何回読んだかわかりません。そのうえで、より深い知識を身につけたいならばMySQLの公式のリファレンスを読むことが、スキル向上の近道だと思います。
何か課題が発生したら、チーム内で議論してすぐに対応できる
――「MUH-Prod」のリリース後に判明した課題はありますか？
私たちが予想していなかったツールの使い方をした方がいました。「MUH-Prod」ではTarget（移行先）のMySQLが書き込み可能になった後に、もし問題が発生してもロールバックできるように、TargetからSource（移行元）のMySQLに対してレプリケーションを行う仕組みがあります。このレプリケーションはあくまで各サービスで用いられるデータを複製しておくことが目的であり、移行途中でテーブル定義変更やユーザー追加などが行われることを想定していませんでした。
しかし、移行途中にユーザー追加をした方がおり、その際にTargetのMySQLからSourceのMySQLに向けてユーザーのACLに関するデータのレプリケーションが行われました。そして、TargetのMySQLのバージョンが8.0でSourceのMySQLのバージョンが5.7の場合、ACLを管理するためのテーブルにおいて特定カラムの型が異なるため、レプリケーションのSQLがエラーになってしまうという課題が発生しました。
この際には、メインとレプリカ間でカラムのデータ型が異なる場合の挙動を定義するslave_type_conversionsオプションを設定することで対応しました。こうした課題が判明した際に、チーム内で話し合ってシステムの要件を決めて、すぐにリリースできるのは私達のチームの良いところですね。
――今後、さらに「MUH-Prod」の機能を改善していく予定はありますか？
大幅な変更は今のところ考えておらず、まだ実現できていない細かな機能を少しずつ実装したいと考えています。たとえば私たちはチーム内で、TCPパケットのキャプチャを取得してSQLのクエリの観測とリプレイができる「MySQL Query Replayer」というツールを活用しているのですが、これはまだ各サービスの開発者たちに提供できていません。これを、いつか提供できたらいいなと思っています。
それから「MUH-Prod」の移行完了までに必要なStepの数を減らしたいという案は挙がっています。InspectionやSet Variables、Data ImportなどのStepを一度にまとめて実施するような感じですね。また、現在の仕様では各サービスが接続するデータベースを切り替えるタイミングでコネクションをKILLするため、どうしてもエラーが発生してしまいます。ProxySQLなどのミドルウェアを導入することで、エラーを起こさずに切り替えができないだろうか、というアイデアも出ています。
国内トップレベルの優秀なDBAたちと一緒に働ける環境
――MySQL1チームにいたからこそ経験できたことはありますか？
これまで述べてきたように、扱うMySQLの数がとにかく多く、取り組む技術課題の難易度も高いことから、MySQLについての知識は相当に身についたと思います。それから、チーム内には北川健太郎さんやyoku0825さん、大塚知亮さんといった高度なスキルと情熱を持ったDBAたちがいるので、彼らと一緒に働けることが貴重です。
また、運用改善をすればするほど自分たちの自由な時間が生まれますから、さらなる運用改善やサービスを良くするための活動ができることが楽しいです。大規模かつ絶対に止められないデータベースをうまく運用するためのツール開発や体制構築といった、工夫しがいのある仕事がたくさんある環境です。
それから、韓国側のMySQL2チームのメンバーとやりとりをすることが多いのですが、翻訳botや通訳を介したコミュニケーションをとる際に、なるべく伝わりやすい言葉選びや説明をする習慣が身につきました。
――原地さん個人のエンジニアとしての今後の目標を教えてください。
チーム内のオペレーション改善だけではなく、今後はさらに幅を広げてRedisやMongoDB、Oracle Databaseといった他のデータベースの運用改善業務にも貢献したいと思っています。データベースの運用工数を削減し、DBAたちに時間の余裕が生まれるようにして、より良い運用体制やサービス開発者たちとの協業につなげていきたいです。
――原地さんのDBAとしてのさらなる活躍が楽しみです。今回はありがとうございました。