クラウド時代のデータベースを理解するために①

最近、分散データベースとかNewSQLとかサーバレスなデータベースとか色々聞きますよね。
でも、専門ではない人たちにとって、「何が違うの？」「自分たちに必要なDBはどれなの？」という点が分かりづらいと思います。

私も良く聞かれます。

• AuroraはNewSQLですか？
• NewSQLってサーバレスなんですか？
• スケールできないDBとか聞きますけど、リードレプリカ増やせますよね？

などなど。この辺に基本的なところから答えられるように、順を追って解説していきましょう。

「コンピュートとストレージは別であれ」

と神が言うと、コンピュートとストレージは分離された。

と言うのは冗談ですが、まずはここからスタートしましょう。
クラウド以前のデータベースを使っていた人にはお馴染みのように、それまでデータベースは大きな1つの箱でした。

過去に私は下図でデータベース（厳密にはRDBMS）のコンポーネントを解説していますが、クラウド以前のデータベースでは、SQLを処理する部分（パーサーやオプティマイザ、エグゼキューター）と、データを効率的かつ安全に管理するストレージエンジンは、同じサーバ内に配置されていました。

(https://speakerdeck.com/tzkoba/cloud-nativeshi-dai-falsedetabesu?slide=7)

「別にそれでもいいじゃない」と思う人もいるかも知れません。では、この「DBが1つの大きな箱」では何が問題になるのでしょうか。

コンピュートとストレージを、別々に拡張できない

これです。サーバの監視をしていると、CPUやメモリ、ディスク容量など様々なリソース不足がでてきますが、「DBが1つの大きな箱」状態ではCPU（＝コンピュート）が足りなくてもディスク（＝ストレージ）が足りなくても、できることはDBサーバのスケールアップだけです。

「CPU利用率が80%を超えたので、CPUだけ増やしたいんです！」と言うのが難しく、結果として無駄なコストが掛かっていたと言うことですね。

クラウドが当たり前になってからの方々には、実はここのコンピュートとストレージの分離と言うのが伝わりづらいのかも知れません。

もちろん、↑は極端な言い方です。
オンプレミスの頃は、サーバのソケットが空いていればそこに新しいCPUを挿せましたし、そもそもサーバと別筐体の（お高い）ストレージを使って、容量が不足したらストレージの中で拡張できたよという話はあります。
ただ、上のコンポーネント図をもう一度見てみてください。
サーバとストレージが物理的に分かれていたとしても、データベースのコンポーネントは基本的に1つのサーバに配置されていました。
当然例外はあり、Oracle RACやASMなどを持ち出す方もいるかも知れません。が、その話は長くなるので、別の機会に、、、

そしてAuroraへ

もちろん、クラウド以降のデータベースが全てコンピュートとストレージが分離されているのかと言うと、そんなことはありません。

多くの人が思い浮かべるのが、下図右側のAmazon Auroraでしょう。

（https://www.slideshare.net/slideshow/cloud-native-database-cndt2023-nttdata/264525812 より抜粋）

図にあるように、Auroraでは "賢い" ストレージにコンピュートを生やすことで、読み取り性能の向上が見込めます（最近ではLimitless DBにより書き込み性能の向上も可能になりました）。

容量が不足すればストレージも自動的に拡張しますし、コンピュートとストレージの分離の良い所をきれいに実装した構成です。

サーバレス・データベース

このコンピュートとストレージの分離から派生する、データベース提供形態の新しい形が「サーバーレス」です。

サーバレスなデータベースが構成可能なものとして、

• Amazon Aurora Serverless v2
• TiDB Serverless
• Neon

などがありますが、いずれもコンピュートとストレージの分離を前提として、「コンピュート部分がオンデマンドで自動的に拡張され、管理が容易」になるサービスです。勘違いしてはいけない点として、ストレージに保持しているデータ分のコストは継続的に発生します。

サーバレスではありますが、ストレージレスではありません。

この辺りはアプリケーション実行環境としてのサーバレスと考え方が違ってきますので注意しましょう。

また、別の話としてサーバーレスのメリットは良く低コストと考えられがちですが、これもデータベースでは必ずしも真実ではありません。

サーバーレス・データベースには、「急激な負荷の上昇にどれだけ迅速に対応できるのか？」という課題があります。先ほど言ったように、コンピュート部分は自動的に拡張されるのですが、それが負荷増に間に合わないとリソース不足や、最悪ではDBハングアップのような結果を招きます。

また、コンピュート部分の拡張に必要なリソースとして、最低限xxぐらいのCPU/メモリを準備しておく必要があったり、負荷が少ない（または全く無い）時間帯でもコスト削減ができなかったというケースも良くあります。

では、サーバーレスのメリットは何かというと「予測不可能性への対応」です。サービスをリリースするけど、需要予測からどれぐらい上振れするか分からないなどのケースで使うべきだと言えます。

開発環境での利用という例も一部見ますが、データベースにおいてはそれもサーバレスでコスト削減ができるとは個人的には考えていません。

---

ここまでで「コンピュートとストレージの分離が大事なんだな」「分離してるとサーバレスってやつもできるんだな」と理解したことだと思います。

ただ、世の中のコンピュートとストレージを分離したデータベースの全てがサーバレスになれるか、と言うとそうではないのです。

次の記事では、その辺りを別の概念も示しながら見ていくことにします。