この記事は「RookだらけのAdvent Calender」13日目の記事です。
昨日はRookで展開したYugaByteDBを使いながら、2つのAPIやデータ分散のアーキテクチャなどを学びました。
今日はRookによるYugaByteDB編の最終回として、この構成がどのようなユースケースにフィットするのかを検討したいと思います。
YugaByteDBに適したユースケース
まず、Productionな環境で必要なデータベース構成を、フロントのサービス規模に応じて3つに分類してみましょう。
- 可用性は必要だが、スケールは不要なケース
- 可用性は当然必要で、Readクエリに対してスケールが必要なケース
- 可用性は当然必要で、Read/Writeともにスケールしたいケース
1.はAmazon RDSでいうところのMulti-AZ構成のようなものを想定して下さい。
基本的にはシングルインスタンスですが、DBMSまたはストレージの部分でデータが冗長化され、障害時には別ノードにフェイルオーバすることでサービスを継続します。
2.は上記のMulti-AZにReadレプリカも付いた構成となります。
可用性は担保しつつ、データのレプリカでReadクエリのみ実行を許可することでスケールアウトが可能です。Writeクエリを処理できるのは1インスタンスのみですので、Writeはスケール不可です。
そして、レプリカも親－子－孫のような構成が作れますが、多くても10数インスタンスというのがこの構成の特徴です。
3.はいわゆるマルチマスターなデータベースとなります。
複数のデータベース・インスタンスが、ReadもWriteも処理しながらお互いにデータを同期し続けます。全インスタンスの役割は基本的に同一で、台数を増やせば増やすほどスケールするため、100台以上の規模でデータベース・クラスタを構築することが可能です。
この3.のアーキテクチャでは色々な実装方法がありますが、クラウドベンダがManaged Serviceとして提供しているものでは、以下の2つの仕組みに分かれているように見えます。
（マルチマスター・データベースの2つの類型）
このうち、YugaByteDBは左側の「RDB on 分散KVS」の一つで、YQLとDocDBに分かれた階層構造（昨日説明したもの）からもそのことは明らかです。
ここまでの話から、分かることは以下です。
- Readレプリカで対応できるケースで、可用性担保のためにYugaByteDBを採用するのは不適です。
- Spannerを使うようなWrite負荷も非常に高いケースで、正しいキー設計の下でYugaByteDBを運用することで、他にない性能を達成できる可能性があります。
Rookから見た分散データベース
上記のように、YugaByteDBを「RDB on 分散KVS」として捉え、Write負荷の高いユースケースで運用が可能なことは理解して頂けたのではないでしょうか。
それをRook、つまりKubernetes Operatorで運用する意味はどこにあるのでしょうか。
これは分散データベースの構築要件に由来すると考えています。
先ほどあげた2.のケース、10数台のレプリケーション構成を正しく構築し、障害時のリカバリも含めた運用を行うことは簡単ではありません。しかし、これは実現している企業もあるかと思います。
一方で100台単位にスケールするデータベース・クラスタを構築し、データのバックアップや障害復旧などをきちんとやり切るにはどの程度の管理負荷がかかるでしょうか。
これは間違いなく、膨大なものになるでしょう。
そのようなステートフルなワークロードの運用を助けるために開発が進められているのが、Kubernetes Operatorです。
現在のRook-YugaButeDBは構築を担うだけの非常にシンプルな機能しかありません。しかし、そこにバックアップ/リカバリなどの運用機能が搭載されれば、現在はニッチにしか受けていないYugaByteDBのブレークスルーとなりえます。
まとめ
本日はYugaByteDB編の最後ということで、どのようなユースケースに適しているか、そしてRookを用いてそれを構築する意味などを少し考えてみました。
Rookだらけのアドベントカレンダーの本筋からは外れるため、YugaByteDB自身の機能や性能などについては今回検証を行っていませんが、そちらも時間を見て行いたいと思っています。
よろしくお願いします。