全6442文字
PR

 DX(デジタルトランスフォーメーション)において、データ量の増減に柔軟に対応することは避けて通れない問題です。そのため今日のデータベース(DB)には従来のACID(Atomicity、Consistency、Isolation、Durability)特性だけでなく、スケーラビリティーが求められます。

 しかし、従来のリレーショナルデータベース(RDB)だけではデータ量の増減に対応するためのスケールアウト/スケールインの実現は難しく、そうしたニーズに対しては一般的には非リレーショナルデータベースであるNoSQL(Not Only SQL)が選択されます。

 一方でNoSQLには次のような問題があります。完全なACID特性を提供しない、エンジニアの追加学習コストがかかる、既存のRDBとのデータ連係が難しい――といった点です。一口にNoSQLといってもMongoDBのようなドキュメント型DBやRedisのようなKey-Value型DBなど様々な製品が存在します。その性質や得意分野は大きく異なります。

 そのためサービスに最適な製品を選ぶには、その製品とアプリケーションの性質を十分に熟知する必要があります。さらにサービスの特性によっては複数種のNoSQL製品を利用する必要があり、各製品間でのデータ同期の難しさといった問題も発生します。

 米Microsoft(マイクロソフト)の「Azure Database for PostgreSQL(以下、Azure PostgreSQL)」で提供されるデプロイオプションの1つである「Hyperscale(Citus)(以下、Hyperscale)」を利用すれば、従来のRDBのメリットを維持したまま高いスケーラビリティーを享受できます。

 HyperscaleはPostgreSQLのフォーク(派生)ではなく拡張機能であるため、従来のPostgreSQLで利用できるコマンドはそのまま利用できます。既にPostgreSQLのスキルを持つエンジニアであればHyperscaleを利用するためにかかる学習コストは比較的小さいということです。ここでは最初にHyperscaleのアーキテクチャーや特徴および従来のPostgreSQLとの違い、注意点について説明します。そして、それらを踏まえてどのようなサービスにフィットするかを解説します。

Hyperscaleのアーキテクチャーとその特徴

 まずHyperscaleのアーキテクチャーについて解説します。Hyperscaleは1台のコーディネーターノードと2台以上のワーカーノードで構成します。コーディネーターノードの役割はどのデータがどのワーカーノードに存在するのかというメタデータを適切に管理し、アプリケーション(クライアント)からリクエストを受け取り、その内容に従ってクエリーを適切なワーカーノードにプッシュダウンすることです。

 プッシュダウンとは一般的に検索条件による絞り込みをそのサーバー本体ではなく別のサーバーにさせることです。一方ワーカーノードの役割はコーディネーターノードからプッシュされたクエリーを実行し、その結果をコーディネーターノードに返すことです。最終的な結果セットはコーディネーターノードを通してクライアントに返されます。

1台のコーディネーターノードと2台以上のワーカーノードで構成
1台のコーディネーターノードと2台以上のワーカーノードで構成
Hyperscaleのアーキテクチャー
[画像のクリックで拡大表示]

 例えば上の図中に記載されているクエリーのように、対象となるデータがワーカーノード#1に存在する場合、コーディネーターノードはワーカーノード#1にのみクエリーをプッシュしその結果をアプリケーションに返します。必要となるデータが存在するワーカーノードにのみアクセスすればいいため、1台のDBと比べて並列性が向上します。

 一方で分析クエリーのようにすべてのデータを集計するクエリーに対しては、コーディネーターノードはすべてのワーカーノードにクエリーをプッシュし、個々のワーカーノードがそれぞれ集計します。これにより1台のサーバーで集計処理をするより高速なレスポンスが期待できます。

 アプリケーションから見るとコーディネーターノード1台だけでクエリーが完結しているため、まるで1台のPostgreSQLサーバーに接続しているかのように見えます。なお、アプリケーションはコーディネーターノードにのみ接続できます。ワーカーノードには一切アクセスできないため注意してください。