5,500超のMySQLインスタンスを少人数で運用するには - LINEのDB運用効率化・自動化の取り組み

──LINEで扱っているMySQLインスタンスの規模についてお聞かせください。

原地　インスタンス数の変遷は下のグラフをご覧ください。これは、どの日付にMySQLのインスタンスが何台あったのかを可視化したものです。増加ペースは年々加速しており、現在（2021年11月時点）は合計で5,500インスタンスを超えています。

MySQLインスタンスの種類は大きく分けて、LegacyとVerda1.0、DBS for MySQLの3つが存在しています。これはLINE社内での呼び方ですが、最も古くから存在しているのがLegacyで、物理マシンにMySQLをインストールしたもの。Verda1.0はLINEのプライベートクラウドであるVerdaの仮想マシンにMySQLをインストールしたものです。また、同じくVerdaの仮想マシンを使用しており、Verda1.0の後継にあたるのがDBS for MySQLになります。

現在、アプリケーション開発者は専用の管理画面からDBS for MySQLのインスタンスを自分で作成可能であり、DBAへ申請してインスタンスを構築する手順を踏む必要はありません。作成がより容易になったことと事業拡大が相まって、MySQLインスタンスの増加スピードが加速したのだと思います。

扱っているMySQLのバージョンは5.6や5.7、8.0などが混在しています。バージョン5.6はすでにEOL（保守終了）しているため、5.7あるいは8.0にアップグレードするプロジェクトを推進している最中です。

北川　今期はMySQLのアップグレードやオペレーションのオートメーション、self management¹の充実を目標に運用改善を進めています。

かつて抱えていた「運用の属人性が高い」という課題

──LINEではどのようにしてMySQLの運用を改善してきたのでしょうか？

北川　私が入社したのは2016年で、当時はDBAチームの人数が10人程度で、MySQLのインスタンス数は今よりはるかに少ない500ほどでした。

当時は、LINE MUSICやLINE GAMEといった特定サービスのデータベースを1人のDBAが担当していました。かつ、1人が2種類以上のデータベースを見る体制であり、私の場合はOracleとRedis、MySQLの3種類を管理していました。

その頃は、現在と比べると各種ツールや仕組みなどの整備が進んでおらず、運用の属人性が高い状態でした。さらに、作業があまり効率化されていない状態でインスタンス数が増加したことに伴い、徐々に課題が顕在化していきました。たとえば、各DBAの日々の業務が運用だけで手一杯になってしまう、といった課題です。

また、特定サービスのデータベース障害が発生した場合、担当エンジニアしか対応できない状況だったので、みんな休みにくい。さらに、各DBAが複数種類のデータベースを管理しているため、特定のデータベースを集中的に学んで専門性を磨くことが難しい状態でした。

その後、2018年頃に体制変更があり、DBAのチームが3つに分割されました。1つ目のチームはMySQLとRedisとOracle、2つ目のチームはMySQLとSQLサーバーというように、チームごとに担当するデータベースが異なり、MySQLはすべてのチームが見ているという状態が1年半ほど続きました。その後、今のチーム編成になったのですが、運用改善のための取り組みが急速に進んだのは現体制になってからです。

──改善が進んだのは、意外にも近年になってからの話なのですね。

原地　そうです。2021年に入ってから組織変更があり、MySQLの運用を専任するMySQL1チームとMySQL2チームが編成されました。MySQLチームは社内のすべてのMySQLインスタンス運用を担当します。他チームが管理していたMySQLのインスタンスを、少しずつMySQL1チーム、2チームのDBAに引継ぎしています。

北川　もちろん、2021年以前から運用業務の自動化・効率化に取り組んでいましたが、現在のチームになってから改善が加速しました。その甲斐あって、運用の負担が着実に軽減しているのを実感しています。

MySQL運用を支える技術(1) モニタリング

──ここからはMySQLインスタンスを運用するための仕組みを教えてください。

原地　まず、各インスタンスの状態を可視化するために内製ツールの「MONDB+」を使用しています。このツールでは以下のような情報を可視化でき、日々の運用に役立てています。

• MONDB+ 機能一覧　
  • Service/Instanceの検索・詳細画面
  • Backupの確認、リストア画面
  • ACLの登録
  • Disk使用量の一覧
  • 各種DBMSのInstall
  • MySQL Replica追加
  • アラート一覧
  • nstance数の統計情報
  • スロークエリの確認
  • データ抽出画面
  • HA管理画面

原地　他には​​データ可視化ツール「Grafana」で監視しており、何か障害が起きた場合、このツールが提供する情報を見て状況を判断することが多いです。

──データベースの異常を検知するために用いているツールはありますか？

田中　システム監視ツールの「Prometheus」を用いて各種データベースの情報を取得しており、そのデータをもとに「DBONE2.0」というアラート通知用の内製ツールがSlackの特定チャンネルに通知を発行しています。

原地　アラートが通知された後、DBAがインスタンスの状態を確認し、問題ないことがわかれば該当のアラートを確認済みのステータスにします。もともとは、Webアプリケーションの画面からその作業をしていたのですが、LINEの社内ツールは画面を閲覧するためにVPN接続する必要があるので非常に面倒でした。夜間にアラートが通知された場合などに、わざわざパソコンを開く必要がありましたから。

そこで、私たちは運用負荷軽減のために「iruka-san」というSlack Botを作成しました。アラートが鳴った際には、「iruka-san」に対して特定の絵文字でリアクションします。例えばそれが、「問題ないアラートのため無視してよい」ことを示す絵文字であれば、「DBONE2.0」のAPIが呼び出されてアラートのステータスが確認済みに変更されます。つまり夜間や外出時にアラートが鳴っても、スマホを操作するだけで対応が完結できるようになり、DBAの負荷が軽減されています。

また、「iruka-san」は他にも各種のLINE内製のAPIと連携しているため、Slackの絵文字でリアクションしたり、Botに話しかけたりといった簡単な操作で、MySQLインスタンスの各種情報を参照できるのも利点です。

「iruka-san」の機能一覧。

MySQL運用を支える技術(2) バックアップ

──バックアップ取得はどのような方法で行っていますか？

北川　 オンラインでMySQLのバックアップを取得できる「Percona XtraBackup」というツールを使用しています。バックアップした情報は国内の他のリージョンに送って冗長化しており、リストアする作業は「MONDB+」上から実施できます。バックアップ・リストア作業のいずれもAnsibleによって自動化しており、「MONDB+」の画面上からバックアップ・リストアの操作をした場合に、裏側ではそのスクリプトが走る仕組みです。

MySQL運用を支える技術(3) アップグレード

──先ほど、MySQLのバージョン5.6はすでにEOLしているため、5.7あるいは8.0にアップグレードするプロジェクトを推進しているとのお話がありました。アップグレードや、アプリケーションが参照するデータベースを新しいMySQLサーバーに変更するためのスイッチオーバーの知見を教えてください。

原地　私たちは「MySQL Upgrade Helper」という、アップグレード支援ツールを自前で開発しています。

田中　アップグレードを行う場合、通常ならばバージョンの古いMySQLインスタンスと同等の構成で新しいバージョンのインスタンスをDBAが立ち上げ、mydumperやmyloaderなどのツールを使用してレプリケーションを行います。この作業で実施するオペレーションは、どのようなMySQLインスタンスでもほぼ同一です。

そこで私たちはアップグレードに必要となる定型的な一連の作業を自動化・効率化する意図から「MySQL Upgrade Helper」を開発しました。旧ホスト名と新ホスト名をWeb画面上から指定することで、これら一連の手順を完結できるようになっています。

原地　MySQLのバージョンによる設定ファイル情報の差分も画面上で比較できるようにしました。旧ホストと新ホストの情報を画面から登録する際に、設定値の差異が表示されるため、修正の必要がある場合はDBAがそれを見て直します。

また、レプリケーションを実施する際に問題が生じそうな箇所は、事前に検出できるようにしました。一例を挙げると、データのレプリケーションを行う場合、プライマリーキーの存在しないテーブルではパフォーマンスが低下します。そのため「MySQL Upgrade Helper」では、古いホストのテーブル一覧をチェックし、プライマリーキーが存在しないテーブルがあれば警告を出すようにしています。他にも各種のチェックを自動で行っています。

スキーマ・データの両方のマイグレーションだけではなく、スキーマのみ・データのみのマイグレーションも指定可能にしています。これにより、事前に新しいホストにスキーマやテーブルのみを作成しておき、後からデータを登録するなど柔軟性の高い移行を可能にしています。また、もちろんアクセス制御リスト（ACL）のマイグレーションも行えます。

他に有益なツールとしては「MySQL Query Replayer」ですね。これは、TCPパケットのキャプチャを取得することでSQLのクエリの観測とリプレイができるツールで、私たちのチームに所属する大塚さんが開発したOSSツールです。このツールを用いて旧環境で発行されていたクエリを取得し、新環境で実行することでパフォーマンスの課題などが発生していないかを確認できます。

「MySQL Query Replayer」はObserverとQueuing MW(Redis)、Applierから構成されています。Observerで取得したMySQLのクエリをQueuing MWへ転送し、Applierがそれを周期的に取得して再現対象のMySQLに実行します。この際、MySQLのip:portの組を1コネクションとし、このコネクション数も再現します。また、コネクション単位でクエリの実行順序、QPSも可能な限り再現することを目標としています。（mysql-query-replayer READMEより引用）

MySQL運用を支える技術(4) スイッチオーバー

──スイッチオーバーを実現するために工夫されていることはありますか？

北川　スイッチオーバーの知見については私からお話しします。アプリケーションから参照するMySQLインスタンスを旧環境から新環境へとスイッチオーバーする場合、最も注意するべきはロールバックです。不具合など問題が見つかった場合に、データロストなしに再び接続先のインスタンスを新環境から旧環境へと戻さなければなりません。

この際に、アプリケーションを一時停止してメンテナンス状態にできれば楽ですが、LINEではサービス停止が許されないケースが多いです。加えて、MySQLではバージョンの高いインスタンスからバージョンの低いインスタンスへのレプリケーションが公式にはサポートされていません。これらの課題を解決するために、私たちは「simple switchover」というツールを作成しました。このツールを用いたスイッチオーバーの流れについて、図を用いてご説明します。この図はスイッチオーバー前の状態で、アプリケーションは旧環境のデータベースを参照しています。移設先の新環境は、先ほどご説明した「MySQL Upgrade Helper」で事前に作成しておきます。

次に、データベースの新しいエンドポイントを発行し、これをまずは旧環境に紐付けます。そして、アプリケーションが参照するエンドポイントを変更します。

その後、スイッチオーバーを実施して新しいエンドポイントに新環境のデータベースを紐付けます。そして、プライマリーサーバーを新環境にしてレプリカサーバーを旧環境に変えます。問題なければこれでスイッチオーバーは終了です。

次にロールバックの流れをご説明します。先ほど、「MySQLではバージョンの高いインスタンスからバージョンの低いインスタンスへのレプリケーションが公式にはサポートされていない」とお伝えしましたが、実は裏技的な方法を用いることでこれが実現可能になります。

まず5.7↔︎5.6の場合は、5.6のバージョンを5.6.24以上にすれば5.7から5.6へのレプリケーションが可能になります。そのため、このアップグレードのパターンでは、まず5.6を最新バージョンへ上げた後に、5.6から5.7へのアップグレードを行うことになります。また、8.0↔︎5.7の場合はinit-connectという設定に、SET NAMESでCollationを追加することで8.0から5.7へのレプリケーションが可能になります。

こうした手段を用いることで、「simple switchover」では多種多様なパターンのMySQLのスイッチオーバーとロールバックを実現しています。ご覧のとおり、複雑なことは特にやっていません。どちらかといえば、裏技的な方法を発見するまでの調査が一番大変でしたね。

MySQL運用を支える技術(5) 全ツールをAPIで操作可能にする

──各種のツールが運用を支えているのですね。

田中　今回ご紹介した各種ツールが優れているのは、多機能であるだけではなく、それぞれがAPIを持っていることなんです。複数のシステムで連携し合うことが前提となっています。まるでピタゴラスイッチアーキテクチャですね（笑）。例えば、先ほどご説明した「MySQL Upgrade Helper」もAPIを提供しているので、何十台もレプリケーション対象のホストを登録したい場合などは、コマンドラインでワンライナーを書いて、curlをループさせてAPIを呼び出すことで作業を効率化できます。

コマンドラインでワンライナーを書いて、curlをループさせてAPIを呼び出している様子。

原地　APIベースでの機能開発の場合、エンジニアの分業がしやすいのも利点です。例えば「MySQL Upgrade Helper」では、フロントエンド側は私が、APIは北川さんが作るという体制で開発を行いました。

北川　「全ツールにAPIがある」という利点を生かして、ありとあらゆるオペレーションを統合的に管理できる「IRUKA SHOW」というWebアプリケーションを開発予定です。その画面から各ツールのAPIを呼び出すことで、ありとあらゆる作業がWeb上で完結します。これから作成する各種ツールは必ずAPIを持たせ、全機能に「IRUKA SHOW」からアクセス可能にして一元管理できるようにするのが目標です。

大量のインスタンスを運用するからこそ得られる知見がある

──膨大な量のインスタンスを扱うために、数多くの自動化・効率化が行われていることがわかりました。

田中　LINEでDBAをやっていると、とにかく扱うデータベースインスタンスの数が多いのですが、だからこそ貴重な経験ができますよ。5,500インスタンスもあると、1インスタンスにつき1年に1回くらいの確率でしか起きないような珍しいトラブルを、数時間おきに目にすることになります。その圧倒的な数に溺れられますよ（笑）。

私は前職で数百台くらいのMySQLインスタンスを管理していましたが、「もっと膨大な規模のデータベースを扱いたいし、ハードワークしたい」と思って2021年6月にLINEに入社しました。その甲斐あって、これまでのキャリアで見たこともないようなMySQLのアクシデントを、LINEに入ってから既に複数回は見ました。

──MySQL1チームには優秀なメンバーが揃っているでしょうから、このチームの中で切磋琢磨することで得られる経験は貴重なものになりそうです。

北川　MySQL1チームには、強みを持ったメンバーが集まっていますね。例えば原地さんならばDevOps系ツールの開発が得意でMySQL運用ができますし、田中さんは言わずもがなMySQL運用のスペシャリストです。「MySQL Query Replayer」を開発した大塚さんはMySQLの内部実装の深い部分に精通しています。そして、私は複数の領域を幅広く担当しています。

各領域のスペシャリストがいるからこそ、バランスのとれたチームワークが可能になっているのだと思います。MySQL1チームは合計で4人なのですが、この少人数でこれだけ大量のツールを作り、運用を自動化・効率化してきました。無理のない形で運用できているのは、メンバー全員が各々の強みを発揮できているからなのかなと思います。

取材・執筆：中薗昴
写真：⼭辺恵美⼦