不揮発性メモリに最適化したMySQLの高可用性構成

みなさん、こんにちは！　ヤフーでデータベースエンジニアをしている松浦です。
以前、不揮発性メモリに最適化したMySQLのストレージエンジン開発についてのブログ記事を執筆いたしました。
今回のブログ記事は、その続報です。不揮発性メモリ上のデータベースにおける、高可用性構成やその監視・運用に関わる研究開発成果をご紹介します。

前回記事の振り返り

さて、本題に入る前に、まずは、前回のブログ記事の簡単な振り返りをさせてください。
前回のブログ記事では、DRAMのようにバイト単位でアクセスが可能だが、DRAMとは異なり、サーバの電源遮断後もデータが残り続け、また、NVMe SSDよりも高速な記憶デバイスである「不揮発性メモリ」の紹介をしました。ヤフーでは、データベース技術を進化させるべく、不揮発性メモリに最適化したMySQLのストレージエンジン（Leoと呼んでいます）の研究開発に取り組んでいることもご紹介いたしました。

不揮発性メモリ上におけるデータベースの課題

Leoは、不揮発性メモリ上にデータファイルやトランザクションログファイルを配置し、それらを、Memory-mapped Fileとしてアクセスし、トランザクション処理を実行する形態をとっていました。
ここで、少し考えてみましょう。
たとえば、下図のように、Leoが稼働しているマシンが故障したり、データファイルやトランザクションログファイルを配置している不揮発性メモリが故障したりすると、どうなるでしょうか。

Leoが稼働しているマシンが故障した場合、Leoを利用するアプリケーションの処理は止まってしまいますし、不揮発性メモリが故障した場合、最悪ケースでは、不揮発性メモリ上のデータファイルやトランザクションログファイルが読みだせず、データがロストしてしまうという、非常に深刻な課題が発生します。また、バックアップを取得している場合でも、不揮発性メモリが故障した時には、不揮発性メモリ上の最新のトランザクションログファイルが読みだせず、バックアップ時点にまでしか復旧できないという課題も発生します。
データベースは、多くのインターネットサービスの稼働を支えており、たとえ、マシン障害が発生しても、インターネットサービスを継続できること、また、データのロストは絶対に発生しないといった、高い可用性が求められます。
この要求を満たすために、今回、研究開発を実施したのが、Leoの高可用性構成です。

Leoの高可用性構成と従来のMySQLの高可用性構成

今回のブログの本題である、Leoの高可用性構成について、従来のMySQLの高可用性構成とも対比しながら、ご紹介をいたします。
Leoは、不揮発性メモリにその処理を最適化することを重要なコンセプトとしているため、高可用性構成の検討にあたっても、その方針を踏襲しました。

Leoの高可用性構成は、データベースの高可用性構成でよく見られる、Source-Replica構成をとっています。すなわち、通常時は、Sourceノードで更新・参照処理を実行し、Replicaノードは、待機状態、もしくは、参照処理を実行します。Sourceノード障害時は、更新・参照処理をReplicaノードにフェイルオーバし、データベースの処理を継続することで、アプリケーションの継続稼働を実現します。SourceノードとReplicaノードの不揮発性メモリ上のデータファイル、および、トランザクションログファイルは、同期しており、Sourceノードの不揮発性メモリ障害時も、Replicaノードの不揮発性メモリに障害直前のデータが残っているため、データロストが回避可能となっています。Leoの高可用性構成の特徴は、SourceノードとReplicaノードの不揮発性メモリ上のデータファイルとトランザクションログファイルの同期処理の部分です。

Binaryログによる同期

従来のMySQLでは、MySQLのBinaryログ(以下の図ではBinlogと表記)という仕組みをつかって、Source-Replica間で、データの同期を図ります。Binaryログによるデータ同期を、簡略化して説明すると、Sourceノードに投入された更新SQLを、Replicaノード側がポーリングにより受信し、その更新SQLをReplicaノード側で再実行することで、データ同期を実現します。すなわち、従来のMySQLのデータ同期の方法は、ロジカルレプリケーションに基づくものとなります。

このロジカルレプリケーションでのデータ同期方法では、Replicaノード側でSQLの再実行が必要で、SQLのパース・意味解析・最適化・実行計画生成といった、前処理の性能オーバーヘッドが発生します。

RDMAによる同期

Leoでは、この前処理の性能オーバーヘッドを回避し、また、システムコール発行やContext Switchを可能な限り抑え、不揮発性メモリの性能を活かせるよう、Source-Replica間の不揮発性メモリ上のデータファイルやトランザクションログファイルを、RDMA(Remote Direct Memory Access)を用いて、同期するアプローチを取りました。
RDMAによる同期では、

1. SourceノードからReplicaノードへ変更を書き込むrdma_write()を用いる方法
2. Sourceノードの変更をReplicaノードにrdma_read()で取り込む方法
3. SourceノードとReplicaノードの協調動作により同期を図る方法

など複数の方法を検討しました。そして、各方法のメリット・デメリットや、Leoの想定ユースケースに鑑みて、（1）のrdma_write()を用いた同期方式で、Leoの高可用性構成を実装しました。

ただし、全てのデータ同期が、RDMAを用いて実装されているかというと、そうではなく、CREATE TABLEやDROP TABLE, CREATE USERやGRANTといった、DDLやユーザ作成・権限に関わるものは、ロジカルレプリケーションを用いて、Source-Replica間で同期を実現しています。

RDMAによるデータ同期の効果は、約2倍〜5倍程度の性能向上

性能評価のワークロードとしては、sysbenchのoltp_write_onlyを用いました。oltp_write_onlyは、更新SQLのみを発行します。そのため、Source-Replica間でのデータ同期処理が常に実行され、今回のRDMAによるデータ同期の効果を確認するには適切です。
どちらの評価でも、ストレージエンジンはLeoで、データファイルとトランザクションログファイルは不揮発性メモリ上に配置しています。
RDMAによるデータ同期との対比として、Leoで従来のMySQLのBinaryログベースのデータ同期を実施した際の評価結果も合わせて掲載します。評価結果は、従来のMySQLのBinaryログベースのデータ同期方法をLeoに適用した際のトランザクションスループットを1とし、今回開発したRDMAによるデータ同期方法によるトランザクションスループットを、その相対値として示しています。
評価結果より、RDMAによるデータ同期方法を適用することで、従来のBinaryログベースのデータ同期方法と比べて、約2倍〜5倍程度の性能向上が実現できています。

Leo高可用性構成の監視・運用

データベースの運用では、高可用性構成の死活監視や、Sourceノード障害時にエンドポイントをReplicaノードに切り替えるといったことも必要です。Leoも例外ではありません。
Leoの高可用性構成の監視・運用では、MySQLの高可用性構成を監視するOSSツールである、「Orchestrator」が適用可能です。下図が、社内の開発環境で、Leoの高可用性構成をOrchestratorで監視している様子です。Orchestratorを用いて、高可用性構成のトポロジーや稼働状況の確認が行え、また、Sourceノード障害時には、Orchestratorからエンドポイントの切り替え処理の発火や、通知などを行えます。

まとめ

今回のブログでは、データベースの高可用性構成やその監視・運用についてご紹介しました。
ご一読いただきありがとうございました！

記事で紹介した内容のスライドはこちらからご覧ください。

データベースはインターネットサービスを支える重要なコンポーネントですので、その進化に貢献できるよう、引き続き、開発に取り組んで参ります。
また、私たちが開発しているLeoの取り組みは、本ブログを通して、定期的に情報発信をして行きたいと思っております。次回記事もお楽しみください！