原文(投稿日：2022/01/12)へのリンク
携帯電話とインターネットが日常の必需品と呼ばれるようになって、Webサイトやビジネスサービスが１週間に数十億、あるいはそれ以上のアクセスを受けることも珍しくはなくなりました。
北米のブラックフライデーやアジアのダブルイレブン(別名"独身の日")などのセールスデーは、従来の小売業界がディジタル世界に適応した好例と言えるでしょう。これらの企業は、自らのビジネス目標を達成するために、新たなニーズと課題に取り組むことが必要になりました。
すべての企業に同じ質問が問われているのです — 今回のブラックフライデーでディジタルセールスを促進する必要がある。しかし、それが成功して、信じられないほどのトラフックがデータベースクラスタにやってきたとき、我々のデータベースはそれを処理できるのだろうか？
データベースソリューションに関しては、さまざまなビジネスケースに対していくつもの選択肢があります。その選択肢は、NoSQLプロダクト(MongoDB、Cassandra、Amazon DynamoDBなど)からNewSQLプロダクト(最近注目されているAmazon Aurora、CockroachDBなど)まで多岐にわたっています。
このような優れたソリューションに加えて、一部の業界においては、既存のデータベースクラスタ上のトランスペアレントシャーディング(transparent sharding)もまた、検討の対象となるでしょう。
データベーストレンドランキングのDB-Enginesによると、新たなデータベース製品がマーケットに出回っている一方で、従来のリレーショナルデータベースはいまだ大きなシェアを占め続けています。
データベースが新たに直面する課題を考えたとき、これら旧来のデータベースを活用して、新しい実用的なアイデアを通じて強化する、効率的かつ費用効果の高い方法はあるのでしょうか？データベースのトランスペアレントシャーディングは、この問いに対する最適解のひとつなのです。
DB-Engineのデータベース人気ランキング
この問題に対する最良のテクニックのひとつは、データを別々の行と列に分割することです。このように、大きなデータベーステーブルを複数の小さなテーブルに分割する方法を"シャード(shard)"と呼びます。元々のテーブルは、垂直(vertical)シャードあるいは水平(horizontal)シャードに分割されます。これらのテーブルを表すために、垂直シャードには'VS1'、水平シャードには'HS1'といった表現がよく用いられます。数字は最初のテーブルあるいはスキーマを表すもので、2、3と続きます。これらデータのサブセットが、テーブルの元々のスキーマとして参照されるのです。
それでは、シャーディングとパーティショニング(partitioning)の違いは何なのでしょう？どちらも大規模なデータセットを小さく分解するものですが、大きく違うのは、シャーディングが水平あるいは垂直いずれにおいても、分解されたデータが複数のコンピュータに分散していることを暗黙的に含んでいる点です。一方でパーティショニングでは、データがさまざまな形でサブセットに分解されたとしても、単一のデータベースの中には保持されています。これはデータベースインスタンスと呼ばれることもあります。
シャーディングは、データを多数の部分に分割した上で、いくつものマシンに格納することにより、次のようなメリットを提供します。
とはいえ、シャーディングアーキテクチャも完璧ではありません。いくつかのデメリットがあります。
シャーディング: ひとつから複数のシャードへ
人生もテクノロジも、そのほとんどにおいて、万能の解決策というものは存在しません。自身のニーズやシナリオを完全に把握するための徹底的な分析を行う必要があります。それをした上で初めて、最善の解決策を選択することが可能になるのです。
一般論としては、シャーディングアーキテクチャのメリットの方が勝っているため、データベース産業において重要な役割を果たしている優れたプロダクトの多くがこのアーキテクチャに基づいています。CitusあるいはVitessは、それぞれの定義はありますが、基本的にはデータベースシャーディングアーキテクチャをベースとしています。
CitusはPostgreSQLクラスタを分散するためにコーディネータ(プロキシ)クラスタを管理します。Vitesも同じようにMySQLをシャードします。これらはいずれも、これまでの主流であるリレーショナルデータベースを使った、低コストで効率的な分散ソリューションの提供に特化しているのです。実際には、シャーディングアーキテクチャはほとんどのNoSQLおよびNewSQLプロダクトの基礎でもあるのですが、それはNoSQLとNewSQLにおけるシャーディングに注目した別の話題、ということになるでしょう。今回の記事では、リレーショナルデータベースにおけるシャーディングに注目したいと思います。この分野では、旧来のシャーディング技術にいくつものイノベーションがもたらされているからです。
シャーディングは、データベースの分散に対するニーズから生まれました。昨今はプライバシ保護やSQL監査、テナント、分散認証など、データベースに関連のある新たな問題が増えています。
これらは現実世界における、データベースへの新たな要求を表すものです。これらの問題をどう扱うかは、データベースのタイプに関わらず、すべてのデータベースプロダクトに突きつけられた、逃れることのできない疑問なのです。データベースシャーディングソリューションによって、これらの問題に対処することはできるのでしょうか？そのためには、シャーディングの進化が必要なように思われます。データベースシャーディングアーキテクチャの次なる進化は何か — 今回の記事ではそれを取り上げます。
私の回答は、DBMSの上に位置して、シャーディングを越える分散データベースシステムを作るための指針となる概念である、Database Plusです。
Database Plusは、既存の多様なデータベース上に標準レイヤとエコシステムを構築して、標準化された統一的なデータベース利用仕様を提供することを目的として考え出されました。上位レベルのアプリケーションには機能を提供すると同時に、下位データベースのフラグメンテーションを最小化することによって、ビジネスが直面するさまざまな課題に対処します。その結果として、アプリケーションがデータベース毎に異なるサービスではなく、標準化されたサービスのみに対応すればよい、という環境が実現するのです。
このアイデアは、Apache ShardingSphere PMC(Project Management Committee)の発案によるもので、このコンセプトをアーキテクチャに実装した5.0.0 GAのリリースには約1年を要しています。
3.xと4.xのリリースステージにおけるApache ShardingSphereは、シャーディングの問題を解決するための単なる分散データベースミドルウェア(シャーディングアーキテクチャ)として定義されていたのですが、データベースの新たな課題とコミュニティが、これをデータ暗号化やシャドーデータベース、分散認証、分散ガバナンスといった機能を備えた革新的なプロジェクトへと推し進めたのです。これらの変革はいずれも、従来のシャーディングの枠組みを超越しています。シャーディングはDatabase Plusの一部に過ぎません。
ShardingSphere Database Plusアーキテクチャの進化
Apache ShardingSphereの例は、単純な古いシャーディングアーキテクチャでもシャーディング以上のことができる、という私の主張を裏付けるものです。カーネルメカニズムはプロキシまたはドライバを通過するすべてのトラフィックを指揮します。そこでSQLを解析することができて、すべてのデータベースのロケーションを知っていれば、以下の処理を実行するのは難しくないでしょう。
ではこれらの処理は、エンドユーザにとってどのような意味を持つのでしょう？このようなカーネルジョブをベースとすることで、Apache ShardingSphereのプロダクトは、データベースにおけるユーザの痛点を和らげることが可能なのです。
シャーディングやデータ暗号化、シャドーデータベース、分散認証、分散ガバナンスなどは元々、上記のような必要なステップを踏まえてのものでした。Apache ShardingSphereのDatabase Plusコンセプトが提案するアーキテクチャは、これらの拡張機能を、フレキシビリティを持って提供します。
すべての機能がプラグインになっていて、この分散システムにいつでも追加ないし削除することができるのです。データベースをシャードしたい人もいれば、データ暗号化の方を選びたい人もいるでしょう。ユーザのニーズが進化と多様化の一途をたどっていることを踏まえて、Database Plusでは、完全なカスタマイズを可能にすると同時に、新たなプラグイン(機能)を継続的に受け入れることによって、ユーザの要求にひとつひとつ、明確かつ柔軟に応えることを可能にしているのです。
ShardingSphereのアーキテクチャには、下図１で示すように、次の4つのレイヤが含まれています。
ShardingSphereの4層アーキテクチャ
Foundation Layer: ドライバやプロキシといったさまざまなアクセスターミナルを提供することで、ユーザの多様なニーズに柔軟に対応します。
Storage Layer: これらデータベースの全機能をサポートすると同時に、さらに多くの機能を含めることが可能です。
Function Layer: ユーザのニーズに合ったさまざまな機能プラグインを提供することで、プラグインの選択と組み合わせによる高度な柔軟性を実現します。
Solution Layer: 業界指向(金融、Eコマース、エンターテイメント業界など)および具体的な特定のシナリオ指向の標準的なプロダクトソリューション(分散データベースソリューション、暗号化データベースソリューション、データベースゲートウェイなど)をエンドユーザに提供します。
ShardingSphere JDBCとShardingSphere Proxyは、5年間におよぶ開発およびテスト期間を経て、実運用可能なプロダクトとしてリリースされました。数多くのコミュニティユーザが自身の運用ケースを提供して、運用上のフィジビリティ検証を行ってきました。
さまざまなShardingSphereクライアントがコア機能を共有する構造により、下図2に示すような、クエリパフォーマンスと管理上の便宜のバランスを実現するハイブリッドデプロイメントも選択可能になっています。
ShardingSphere JDBCとProxyのハイブリッドデプロイメント
Apache ShardingSphereのコミュニティは、ShardingSphereの全機能を操作および管理可能なSQLダイアレクト(方言)のひとつとして、DistSQL(distributed SQL)を提案しています。
SQLは従来より、データベースと対話する標準的な方法ですが、この分散データベースシステムには新しい機能がたくさんあるため、それらを設定し、利用するためのSQLダイアレクトを検討する必要がありました。
DistSQLはSQLライクなコマンドで、分散データベースやテーブルの生成、修正、削除、データベースの暗号化と復号化を行うことができます。これまで述べたような機能は、この分散SQLですべて実行可能です。DistSQLのスニペットをいくつか紹介しましょう。
DistSQLの使用例
分散データベースシステムのガバナンス機能は、分散クラスタ管理の難しさを軽減する上で必要なものです。コンピューティングとストレージが分離されているShardingSphereのエコシステムでは、この機能が新バージョンで大幅に強化されています。
さらに新機能として、分散ロック(distributed lock)が近くリリースされる予定です。
ShardSphereの分散ガバナンス
これまでメリットをたくさん挙げてきましたが、制約や制限についても述べておくべきでしょう。ShardingSphereを導入する前に、以下の項目について十分に考慮しておく必要があります。
この章では、ShardingSphereエコシステムの全要素を結合するSQLダイアレクトであるDistSQLを使って、"分散データベースの構築方法"と"暗号化テーブルの構築方法"という、２つの実例を紹介したいと思います。
このパートは、DistSQLを使って分散データベースを構築する方法を実例で紹介します。ユーザとアプリケーションは、さまざまなサーバ間にシャードされた論理テーブル(分散テーブル)にアクセスするために、プロキシに接続します。これらのシャードに注意する必要はありません。アプリケーションでは論理テーブルの操作と管理を行えばよいのです。
前提:
プロセス:
SQLコマンドを実行してProxy CLIにログインする
mysql -h127.0.0.1 -uroot -P3307 -proot
DistSQLを使用して2つのMySQLデータベースを登録する
ADD RESOURCE ds_0( HOST=127.0.0.1, PORT=3306, DB=demo_ds_0, USER=root, PASSWORD=root );
ADD RESOURCE ds_1 ( HOST=127.0.0.1, PORT=3306, DB=demo_ds_1, USER=root, PASSWORD=root );
DistSQLによってシャーディングルールを生成する
CREATE SHARDING TABLE RULE t_order( RESOURCES(ds_0,ds_1), SHARDING_COLUMN=order_id, TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=4)), GENERATED_KEY(COLUMN=order_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123))) );
先程のシャーディングルールによってシャーディングテーブルを生成する
CREATE TABLE `t_order` ( `order_id` int NOT NULL, `user_id` int NOT NULL, `status` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
リソース、シャーディングデータベース、シャーディングテーブルを表示する
sql SHOW SCHEMA RESOURCES;
SHOW DATABASES;
SHOW TABLES;
シャーディングテーブルを表示する
SHOW TABLES;
以下はMySQL内のテーブルです。
以下はShardingSphere Proxy内のテーブルです。
シャーディングテーブルをドロップする
DROP TABLE t_order;
この例では、DistSQLを使って暗号化テーブルを生成する方法を示します。データ暗号化はShardingSphere Proxyの機能で、データの暗号化および復号化を行います。アプリケーションのコーディングを変更する必要はなく、単にプレーンテキストをProxyに送れば、そのプレーンテキストが暗号化され、暗号文がデータベースに送信されます。どのテーブルのどの列が、どのようなアルゴリズムで暗号化されるのかは、ユーザが設定することができます。
前提:
プロセス:
以下のコマンドを実行してProxy CLIにログインする
mysql -h127.0.0.1 -uroot -P3307 -prootDistSQLでリソースを追加する
ADD RESOURCE ds_0 ( HOST=127.0.0.1, PORT=3306, DB=ds_0, USER=root, PASSWORD=root );
暗号化ルールを生成する
CREATE ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=AES,PROPERTIES('aes-key-value'='123456abc')))));
SHOW ENCRYPT TABLE RULE t_encrypt;
暗号化テーブルを生成する
CREATE TABLE `t_encrypt` ( `order_id` int NOT NULL, `user_plain` varchar(45) DEFAULT NULL, `user_cipher` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
MySQLの実行結果は以下のとおり
このテーブルにデータを挿入する
INSERT INTO `t_encrypt` VALUES(1,"abc");
MySQLの内容は以下のとおり
暗号化ルールを変更する。
ALTER ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=MD5)) ));
SHOW ENCRYPT RULES;
暗号化ルールを削除する
DROP ENCRYPT RULE t_encrypt;
シャーディング、暗号化、その他の付加機能を備えて、DBMSの上位に位置するデータベース分散システムは、常に変化するユーザのニーズを低コストで実現する、実践的かつ効果的な方法です。このようなソリューションは不安定性や、まったく新しい分散型データベースの導入によって生じる過重なワークロードに関する懸念を取り除いてくれます。
私にはShardingSphere PMC(Project Management Committee)のメンバとしての身内贔屓があるかも知れませんが、私がこのオープンプロジェクトに対するコントリビューションを選択した理由は、それが現実世界におけるデータベース関連の問題や運用シナリオを解決する可能性を持つ、素晴らしいイノベーションであったから、ということも事実です。
プロとしてのキャリアの中で、私は、世界で最もインターネットが普及している社会のひとつにおいて、膨大な量のデータを管理し活用する企業の一員となってきました。データスパイクが引き起こす問題や、運用上のニーズと実現可能なデータベースソリューションとのギャップについても十分理解しています。
Database Plusがクラウド時代における新たな課題を解決する唯一の方法である、と言うつもりはありませんが、現実的かつ革新的なソリューションとして推奨したいとは思います。
最後に、シャーディングについて一言。シャーディングは、インターネット革命が引き起こした新たな課題に対する、数多いソリューションのひとつです。シャーディングデータベースアーキテクチャは時代遅れだという専門家もいますが、事実はまったく違います。
派手さはないかも知れませんし、他のソリューションのように喧伝されることもありませんが、効果的で実用的なソリューションであることは間違いありません。
最近のシャーディングは、重要かつ革新的なコントリビューションを新たに受けることによって、少し前には想像さえできないほどの進化を遂げています。スケーラビリティを求めるブロックチェーン企業の中で人気が高まっているのも、おそらくはそれが理由でしょう。