不揮発性メモリでのデータベース処理最適化 〜 ヤフーにおけるデータベース技術の研究開発

こんにちは！　ヤフーでデータベースエンジニアをしている松浦です。
インターネットサービスを作る上で、そのデータの保持・管理を担うデータベースは重要なソフトウエアコンポーネントですが、今回のTech Blogでは、ヤフーにおけるデータベース技術の研究開発についてのお話をします。
ヤフー社内では、さまざまなデータベースを運用していますが、そのデータベースを最新のハードウエアに対応させる研究開発を行っています。
具体的には、不揮発性メモリを有効に活用するMySQLのストレージエンジン「Leo」の開発に取り組んでいます。
本日は、Leoについて簡単にご紹介をします。

不揮発性メモリとは？

まず、前段として、Leoのお話をする前に、不揮発性メモリについてです。
不揮発性メモリは、DRAMとは違い、サーバーの電源が遮断後もデータが残り続ける不揮発性を有しているメモリのことです。広く言えば、NAND Flashメモリ等を用いたSATA SSDやNVMe SSDも不揮発性メモリの一種ですが、近年、DRAMとおなじようにバイト単位でアクセス可能な不揮発性メモリが商用化されており、今回のTech Blogでいう不揮発性メモリとは、このバイト単位でアクセス可能な不揮発性メモリのことを指します。
Leoはこのバイト単位でアクセス可能な不揮発性メモリに最適化したデータベースを開発しようという取り組みです。
不揮発性メモリの特徴としては、前述のバイト単位でのアクセスに加えて、以下の図のように、容量は、DRAMより大きくSSDより小さく、アクセス性能はDRAMより低くSSDより高いという、DRAMとSSDの中間の性質を有します。（下図のPersistent Memoryが不揮発性メモリを指す）

HDD前提のデータベース技術は適しているのか？

次に、Leoの開発趣旨についてお話をします。
既存のデータベース技術は、揮発性のメモリであるDRAMと、DRAMに比べてアクセス速度が極めて低速なSSDやHDDをデータベースの永続化先とする前提で開発されています。すなわち、データアクセス時に低速なSSDやHDDへのアクセスをできるだけ抑えるため、DRAMをデータベースバッファとして利用します。また、データベースへの書き込みも、低速なSSDやHDDにすぐに直接行うのではなく、最初は、DRAM上に書き込みを行いますが、データの消失を防ぐため、トランザクションコミット時に、データの書き込み内容をシーケンシャルI/Oとなるようログにまとめ、ログをSSDやHDDに先に書き出し、SSDやHDD上のデータベースファイルへの書き込みは、チェックポイント等により非同期で行う（WAL: Write-ahead Logging）、という工夫をしています。
DRAMとアクセス速度が近く、データの永続化が可能な不揮発性メモリをデータベースの永続化領域として利用する場合も、データベースバッファやWALという機構をもった既存のデータベース技術が不揮発性メモリに対して最適か否かを探ろうと考えました。そして、最適ではない場合、見直すべき点を見直し、チューニングや運用が簡単かつ、5GやIoTといった大量のデータ処理が必要とされる時代において、不揮発性メモリの高速性を生かした高速かつ高信頼なデータベースを開発しよう、というのがLeoの開発趣旨です。

Leoの概要

Leoは現在進行形で開発中ですので、その作りは常に進化していますが、今回はその概要をお伝えします。
まず、Leoは、トランザクションをサポートするMySQLのストレージエンジンであるInnoDBと同じように、行レベルでの排他や、データ操作のAtomic性や一貫性の保証、Dirty Readの防止、障害回復といったトランザクションをサポートします。
内部の作りとしては、テーブルのデータやそのインデクスデータを保存するデータファイルと、障害回復時に利用するトランザクションログファイルを不揮発性メモリ上に配置します。
そして、Leoは、それらをMemory-mapped Fileとしてアクセスし、テーブル操作やトランザクションログの書き出しを行います。このMemory-mapped Fileの操作には、不揮発性メモリ上でのソフトウエア開発を容易化するためにOSSとして開発をされているPMDK（Persistent Memory Development Kit）というソフトウエアライブラリ群に含まれる、libpmem［参考1］という低レベルのライブラリを利用しています。

Leoの特徴

Leoの開発において、不揮発性メモリ上に配置するデータファイルやトランザクションログファイルをlibpmemによってMemory-mapped Fileとしてアクセスすることとも関連していますが、Leoの最大の特徴は、不揮発性メモリの性能を最大限に引き出せるよう、その設計・実装がなされているという点です。
不揮発性メモリの種類にもよりますが、そのLatencyは、通常は、1usec未満です［参考2］。
一方で、通常のソフトウエアにおいて、データを保存する永続化領域へのアクセスはどのように行うのが一般的でしょうか？
ソフトウエアは多種多様ですし、永続化領域がローカル領域ではなく、リモートのストレージ装置の場合もあると思いますが、最も一般的な形態は、open、write、read、closeといったOSシステムコールを介してのアクセスではないでしょうか？　OSのシステムコールを介して永続化領域へのアクセスを行う場合は、ユーザー空間とカーネル空間の間での処理の遷移、I/Oに伴うContext Switch等が発生することから、そのLatencyは最低でも数usecとなり、不揮発性メモリのLatencyを超過してしまいます［参考3］［参考4］。これでは、不揮発性メモリの性能を最大限に引き出せません。
そこで、Leoは、不揮発性メモリ上のデータにアクセスするたびに、OSのシステムコールを発行するのではなく、データファイルやトランザクションログファイルを自身のアドレス空間の一部にMapし、Memory-mapped Fileとしてアクセスすることで、可能な限り、ユーザー空間からカーネル空間への処理遷移や、Context Switchを発生させず、データ処理を実行するよう設計・実装をしています。これにより、1usec未満という不揮発性メモリの低レイテンシー性を最大限活用しています。
加えて、内部のデータ構造もできるだけ排他が競合しないよう工夫をし、どうしても排他制御が必要なところも、できるだけ軽い排他となるよう工夫をしています。

このような工夫を施している、Leoでトランザクション制御等が実際にどのように動いているかを、簡単に、スライドにまとめましたので、もしよろしければ、こちらもご覧頂ければと思います。

まとめ

今回のブログでは、不揮発性メモリを有効に活用するMySQLのストレージエンジン「Leo」の開発とその概要について簡単にご紹介しました。Leoは、5GやIoTといった新しい時代におけるサービスを支えるデータベースをビジョンに掲げて開発を進めています。
Leoに関する取り組みは、本ブログを通して、定期的に情報発信をして行きたいと思っております。次回記事もお楽しみください！
新型コロナウイルスにより、皆様、不安な日々を送られていると思いますが、どうぞ健康第一で日々をお過ごしください。インターネットの力によって、皆様の日常が少しでも快適となるよう、新規サービスや新規技術の開発に取り組んで参ります。
本日はご一読ありがとうございました。

参考資料

［参考1］ Persistent Memory Development Kit
https://pmem.io/pmdk/
［参考2］ Persistent Memory Documentation
https://docs.pmem.io/persistent-memory/getting-started-guide/introduction
［参考3］ C. Li, C. Ding, and K.Shen. "Quantifying The Cost of Context Switch". Proc. of the 2007 Workshop on Experimental Computer Science.
https://www.usenix.org/legacy/events/expcs07/papers/2-li.pdf
［参考4］ G. Lee, S. Shin, W.Song, et al. "Asynchronous I/O Stack: A Low-latency Kernel I/O Stack for Ultra-Low Latency SSDs". Proc. of the 2019 USENIX Annual Technical Conference.
https://www.usenix.org/system/files/atc19-lee-gyusun.pdf