クラウド時代のデータベースを理解するために①
最近、分散データベースとか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により書き込み性能の向上も可能になりました）。
容量が不足すればストレージも自動的に拡張しますし、コンピュートとストレージの分離の良い所をきれいに実装した構成です。
サーバレス・データベース
このコンピュートとストレージの分離から派生する、データベース提供形態の新しい形が「サーバーレス」です。
サーバレスなデータベースが構成可能なものとして、
などがありますが、いずれもコンピュートとストレージの分離を前提として、「コンピュート部分がオンデマンドで自動的に拡張され、管理が容易」になるサービスです。勘違いしてはいけない点として、ストレージに保持しているデータ分のコストは継続的に発生します。
この辺りはアプリケーション実行環境としてのサーバレスと考え方が違ってきますので注意しましょう。
また、別の話としてサーバーレスのメリットは良く低コストと考えられがちですが、これもデータベースでは必ずしも真実ではありません。
サーバーレス・データベースには、「急激な負荷の上昇にどれだけ迅速に対応できるのか？」という課題があります。先ほど言ったように、コンピュート部分は自動的に拡張されるのですが、それが負荷増に間に合わないとリソース不足や、最悪ではDBハングアップのような結果を招きます。
また、コンピュート部分の拡張に必要なリソースとして、最低限xxぐらいのCPU/メモリを準備しておく必要があったり、負荷が少ない（または全く無い）時間帯でもコスト削減ができなかったというケースも良くあります。
では、サーバーレスのメリットは何かというと「予測不可能性への対応」です。サービスをリリースするけど、需要予測からどれぐらい上振れするか分からないなどのケースで使うべきだと言えます。
開発環境での利用という例も一部見ますが、データベースにおいてはそれもサーバレスでコスト削減ができるとは個人的には考えていません。
ここまでで「コンピュートとストレージの分離が大事なんだな」「分離してるとサーバレスってやつもできるんだな」と理解したことだと思います。
ただ、世の中のコンピュートとストレージを分離したデータベースの全てがサーバレスになれるか、と言うとそうではないのです。
次の記事では、その辺りを別の概念も示しながら見ていくことにします。
Discussion