カスタマーサクセス部 佐竹です。
本ブログでは、AWS re:Invent 2022 で発表されたアップデートである「Torn Write Prevention」と RDS における「Optimized Write」について記載します。
はじめに
AWS re:Invent 2022 で「Torn Write Prevention」略して TWP というアップデートが発表されました。日本語に直訳すると「引き裂かれた書き込みの防止」となります。
リリースにおける AWS 公式のニュースページは以下の通りです。
AWS Announces Torn Write Prevention for EC2 I4i instances, EBS, and Amazon RDS
また、Torn Write Prevention は以下のアップデート（Optimized Writes）にも寄与しています。
Amazon RDS Optimized Writes enables up to 2x higher write throughput at no additional cost
これに加えて以下のブログも参考にしながら、少し裏側と背景を掘り下げてみましょう。
New – Amazon RDS Optimized Reads and Optimized Writes
Doublewrite Buffer
ここからデータベースの話になります。
MySQL データベース、及び MariaDB には「Doublewrite Buffer」、日本語では「二重書き込みバッファ」と呼ばれる機能が実装されています。
以下はそれぞれのデータベースごとのリファレンスです。
- MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.6.4 二重書き込みバッファー
- InnoDB Doublewrite Buffer - MariaDB Knowledge Base
この機能について理解するために、MySQL のドキュメントから詳細を引用してみます。
二重書込みバッファは、InnoDB データファイル内の適切な位置にページを書き込む前に、バッファプールからフラッシュされたページを InnoDB が書き込む記憶域です。 ページ書込み中にオペレーティングシステム、ストレージサブシステムまたは予期しない mysqld プロセスが終了した場合、InnoDB はクラッシュリカバリ中に二重書込みバッファからページの適切なコピーを見つけることができます。
噛み砕いてみます。
前提として、データベースが予期せず急に停止や破損をしてしまった場合、書き込もうとしたデータが失われる懸念があります。データベースはこれを回避するために、ダブルライトバッファと呼ばれるバッファ領域に一度書き込みを行い、その後、実際のデータファイルへの書き込みを行うという二段階の書き込みが実装されています。
1段階目の書き込み部分がダブルライトバッファで、2段階目のデータファイルへの書き込みが、実データの書き込みになると言えるでしょう。もし1段階目が終わった後、その次に2段階目に移行するという段階で、何らかの理由によりデータベースが急停止してしまった場合、1段階目のみに記載されたデータが生まれてしまいます。
そして急停止後に再度データベースが起動した後、クラッシュリカバリが行われます。このリカバリ中、1段階目だけに書き込まれたデータは追ってデータファイルに書き込まれ、データが正常になります。
実際に、MySQL のクラッシュリカバリ中には以下のログが出力されます。
[Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
このメッセージにある「half-written data page」つまり「半分だけ書き込まれたデータ」というのは、先ほど記載した1段階目だけが終わったデータのことを指しています。
また、本機能名に着目してみますと、最初の単語「Torn」は「引き裂かれた」という意味です。「half-written data page」という単語を見ると「なるほど」と思うのですが、片方だけに書き込まれた状態をデータが「引き裂かれた(Torn)」と表していると思われました。
というように、ダブルライトバッファはデータベースのデータを正常に保つために実装されている「良い機能」なのですが、問題もあります。
Doublewrite Buffer の問題
ダブルライトバッファの問題を一言で表現すると「余計なリソースを割かれる」ということです。このダブルライトバッファがあるために、通常時の書き込みにもオーバーヘッド（余計な待ち時間）が生まれてしまいますし、破損時の復旧にもオーバーヘッドが生まれてしまいます。
しかし、このダブルライトバッファはデータベースにおける Atomicity （原子性/不可分性）を担保するには、必要な機能ではあります。
この機能を使わずとも、Atomicity の「全か無か (all or nothing) 」状態が担保されるなら、この機能を使う必要はない、ということになります。
ここでやっと、Torn Write Prevention に登場して頂くことになります。
Torn Write Prevention
「New – Amazon RDS Optimized Reads and Optimized Writes」にある以下の英文を見てみましょう。
This extra step maintains data integrity, but also consumes additional I/O bandwidth. When running those write-heavy workloads that I described earlier, this might require provisioning of additional IOPS to meet your performance and throughput requirements.
※以下は著者による日本語訳
この余計な手順により、データの整合性が維持されますが、追加の I/O 帯域幅も消費されてしまいます。 （前述の）書き込み負荷の高いワークロードを実行する場合、パフォーマンスとスループットの要件を満たすために、追加の IOPS のプロビジョニングが必要になる場合があります。
ここでも、先に書いたリソースを割かれてしまう問題に言及されています。
本機能の結論を急ぐと、Torn Write Prevention によって Atomicity が担保されることになり、これはつまりダブルライトバッファが不要になります。このため、余計なリソースを割かれることがなくなり、速度が向上します。
ブログにおいては、2ステップの書き込み処理が1ステップになるため、速度が最大2倍になると書かれています。そしてこの Torn Write Prevention は AWS Nitro システムで提供されるとのことです。
ちなみに少し調べてみたところ、この Torn Write Prevention は既に「Atomic Write」として世に出ている機能と同等と思われました。ただこれは私の想像によるところで、現状 Nitro システムにおいてこの Atomicity をどう担保しているのかの情報はありませんでした。
ですが、先のブログにある以下の文章がほぼほぼその解答に近そうです。
Optimized Writes uses uniform 16 KiB database pages, file system blocks, and operating system pages, and writes them to storage atomically (all or nothing), resulting in the performance improvement of up to 2x that I mentioned earlier.
※以下は著者による日本語訳
Optimized Write は、均一な 16 KiB データベースページ、ファイルシステムブロック、そしてオペレーティングシステムページを使用することで、それらをストレージにアトミックに (全か無かで) 書き込むことで前述の最大2倍のパフォーマンス向上をもたらします。
EC2 インスタンスにおける TWP 対応
RDS の裏側は EC2 インスタンスです。このため、EC2 でも TWP が利用できるというわけです。
現時点で、RDS for MySQL のバージョン 8.0.3 以上かつ db.r5b もしくは db.r6i インスタンスファミリーでのみ提供されていますが、EC2 インスタンスを利用すれば MariaDB にも実装ができそうです。
そして、EC2 インスタンスでの利用においては、公式のドキュメントが既に用意されています。
確認してみると、本ドキュメントには利用における前提条件が以下の通りに記載されています。
- An instance type and storage type that supports the required block size.
- Amazon Linux 2 with kernel version 5.10 or later.
- ext4 with bigalloc enabled and a cluster size of 16 KiB, and the most recent ext4 utilities (e2fsprogs 1.46.5 or later).
- O_DIRECT file access mode to bypass Linux kernel buffer cache.
これらを満たす場合に TWP が利用可能ではありますが、正直なところ MySQL では RDS を利用したほうが非常に楽なように思われます。そして、このドキュメントに記載されている設定が、RDS にそのまま施されているように思われます。
まとめ
拙い文章ではありましたが、できるだけ容易に Torn Write Prevention ≒ Atomic Write について記載させて頂きました。
このような仕組みを AWS が積極的に開発実装し、加えて利用者側がほとんどインフラ側を意識せずに利用が可能となっている RDS で提供され、それでもって追加費用なしで利用できるというのは AWS の凄さをまたも思い知らされた気持ちになります。
そして、本機能は東京リージョンでも既に利用が可能となっています。
RDS for MySQL において、対応しているエンジンバージョン (8.0.30 以上) であれば、TWP に対応しているインスタンスクラス (db.r5b もしくは db.r6i) にスケールする（切り替える）だけで Optimized Write が有効化されるとのことです。有効化がされると同時に、ダブルライトバッファが無効化されます。
反対に、TWP に対応していないインスタンスクラスへとスケールする場合には、ダブルライトバッファが有効化されてしまう（Optimized Write が使えなくなる）点にご注意ください。
本ブログが少しでも AWS のバックグラウンドに関する理解の参考になれば幸いです。
その他のブログ記事のご紹介
EC2 に関するアップデートまとめブログも合わせてよろしくお願いいたします！
▼ 11月28日〜12月2日 AWS re:Invent 2022開催中！▼
米・ラスベガスで開催されるAWS最大のカンファレンスイベント！
ご登録はこちらから：
それでは、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
