サーバー製品に関する日本のお客様向け最新ブログ記事

新たに利用するデータベースとして Postgres を選択した Wei は、Citus を使って Postgres を Microsoft Azure 上で水平方向にスケールアウトさせています。またその際には、Ubuntu/Linux 仮想マシンを活用しています (Wei のシステムは「VeniceDB」というコードネームで呼ばれています)。VeniceDB システムには 2 つの Citus データベース クラスターが含まれており、どちらのクラスターも RQV 分析ダッシュボードおよび関連 API にサービスを提供しています。

それぞれの Citus クラスターには現在、22 のノード (合計 44 ノード) が含まれており、2 つのクラスターを合わせるとコア数は 2,816、メモリは 18.7 TBに達しています。Wei は Azure Premium SSD Managed Disks をなんと 1.5 PB (ペタバイト) 分もデータベースのために利用しています。またそれとは別に、さらに 1.5 PB 分の Azure Blob Storage をステージング キューや未加工の Windows イベント データのために使っています。

上で紹介したのは、あくまで現在のノード数です。Wei は今年中に Citus データベース クラスターをアップグレードし、さらにノードやリソースを追加する予定です。

Wei と彼のチームが Postgres と Citus の実稼働を Azure 上で開始したのは、Citus が Azure Database for PostgreSQL の組み込み機能として統合される以前のことでした。そのため、彼らは Postgres データベースと Citus 拡張を一からすべて自分で管理する必要がありました。

幸いなことに現在では、Postgres のために利用するクラウド データベースを検討中の新規ユーザーに向けて、マイクロソフトはフルマネージドのデータベースを Postgres 向けのサービスとして提供しています。さらに Azure Database for PostgreSQL には、展開オプションとして、Citusが組み込まれました。このオプションは Hyperscale (Citus) と呼ばれています。

Postgres のオープンソース拡張である Citus のほかにも、Wei はいくつかの Postgres 拡張を利用しています。例えば、彼は ‘postgresql-topn’ を使ってデータ内で頻繁に現れるアイテムの上位を抽出したり、‘pg_cron’ を使ってデータベース タスクのスケジューリングを行ったりしています。さらに ‘intarray’ で NULL の含まれていない整数配列を操作し、‘postgresql-hll’ で HyperLogLog データ構造をネイティブのデータ型として扱えるようにしています。

また、Wei のチームは Postgres をそれなりの頻度でアップグレードしてきました。「VeniceDB」システムは Postgres 10 を使って立ち上げられましたが、現在実稼働中の Citus データベース クラスターでは、Postgres 11.5 が動作しています。さらに Wei は Postgres 12 と Citus 9.x を使ったテストにも着手しています。Wei はこう言っています。「Postgres と Citus はこの 2 年間で改良されてきました。私にはそれが分かります」

Postgres の Citus 拡張を使い Postgres をスケールアウトすることで、Wei のチームは Windows 診断テストやユーザー フィードバックから生まれる大規模なデータ セットの取り込みに必要な I/O 性能を実現できるようになりました。「この RQV 分析のユースケースでは、書き込み処理を非常に多用します」と Wei は言います。「私たちは毎日 8 ～ 10 TB のデータを Postgres データベースに取り込んでいます。また規制要件の関係で、毎日同じくらいのデータを削除しています」

また、このシステムは読み込み処理も非常に多用します。めったに読み込まれない「死んだ」データを 5 TB 程度保存しているだけのデータベースとは違い、Wei のシステムの場合、RQV 分析ダッシュボードのデータを使用するユーザーは、最大 200 TB の診断データのクエリを絶え間なく実行しています。

「数百人の同時ユーザー、毎日 600 万件以上のクエリに対応可能です」と Wei は言います。「ダッシュボードは、場合によっては 20 ～ 25 分ごとに更新されます。そのため、このデータベースは 150 ～ 200 TB のデータを毎日数百回ずつ読み込まなければならないのです。Citus のおかげで、75% のクエリに対する応答時間は 200 ミリ秒以下に収まっています。一部の種類のクエリの場合、75% の応答時間は 90 ミリ秒以下です。片方の Citus クラスターでは、95% のクエリに対する応答時間が 1 秒以下となっています。もう一方の Citus クラスターでも、3 秒以下に収まっています」

Citus を使用し Postgres を多数のノードにスケールアウトさせることで、Wei のチームはより多くのメモリと計算資源を利用可能となり、さらに Citus が提供する大規模な並列処理の恩恵も受けられるようになりました。その結果、Wei は動的な OLAP キューブ作成とロールアップ作成に求められる性能および応答時間を達成できています。しかも Citus を利用することで、Wei のチームはキューブ/ロールアップの計算を新しいデータがやってくるたびインクリメンタルに実行できるようになっています。

「分散型の PostgreSQL は革新的な手法です」と Wei は語ります。「Azure 上の Citus のおかげで、OLAP キューブをオンデマンドで作成できています」

新しいデータを「調理」しダッシュボードに追加するまでに、もう 2 ～ 3 日もかかることはありません。「Windows の品質に関する最新のデータを RQV 分析ダッシュボードのユーザーの手元まで、確実に届けられるようになりました」と Wei は言います。「そのため、ダッシュボードのユーザーはタイトなリリース スケジュールを守りながら、製品の品質を高めることができています」

エンジニアその他のチームメンバーは、RQV 分析ダッシュボードを使って Windows のリリース作業に関する重要な意思決定を行っています。そのため、データベース内のデータは正確でなくてはなりません。しかし、ダッシュボードの基盤となるデータベースに、誤って不適切なデータが入り込んだらどうなるでしょうか。Wei は PostgresOpen 2018 に登壇した際、このようなケースについて語り、自身がリアルタイム分析データベースを構築したときの教訓を共有しました。

「時には間違ったデータを取り込んでしまうこともあります。そのエラーを修正するために、多大なコストを強いられる場合もあります」と Wei は言っています。「ある時などは、約 2 週間分もの不適切なデータを取り込んでしまいました。とにかくおかしい列が、1 列あったのです。私はどうしようもない状況に陥ったと思いました。テーブルを削除するなら 7 日はかかると知っていたからです。しかし私はそのとき、これは Postgres なのだから更新を行えるのだということに気がつきました。Citus は分散型システムという性質を持っているため、更新は速やかに実行可能でした。そこで私はある週末に作業を行うことにしました。週末はクエリの件数が少ないからです。Postgres と Citus のおかげで、260 億行の更新をたった 10 時間で実行できました。これには本当に驚かされました。データの更新によるデータ精度の向上という点において、ほかの分散データベースにはこのレベルの能力などとても望めません」
ペタバイトスケールのデータベースを Azure 上の Citus でサポート

Wei は Citus による Postgres のスケールアウトを心から勧めています。「一部の組織では、大規模なデータ ウェアハウスが必要なときに、データ レイクを構築しています。しかしその代わりに私が勧めるのは、Citus の利用を本気で検討することです」と Wei は言います。「Citus はペタバイトスケールの Postgres データベースであり、大規模なエグゼクティブ向け分析ダッシュボードの駆動が可能で、数百件の同時実行クエリに対応しています。Citus と Postgres を Azure 上で合わせて使うという手法は、マイクロソフトの社内チームにとって適切なアプローチでした—これは他の多くの組織にとっても適切なアプローチであると確信しています」

Citus は Azure Database for PostgreSQL で展開オプションとして組み込まれ、利用可能となりました (このオプションは Hyperscale (Citus) と呼ばれています)。そのためユーザーは、Wei と Windows データ & インテリジェンス チームが実行したのとまったく同じように、Postgres を Microsoft Azure 上で水平方向にスケールアウトさせられるようになっています。しかもデータベースを管理するために、貴重なエンジニアリング サイクルを費やす必要はありません。

**********
このストーリーの執筆にレビュー、編集、その他の協力していただいた、Min Wei、Teresa Giacomini、Greg Thomas、Marco Slot、Jose Miguel Parrella、Craig Kerstiens、Samay Sharma、Umur Cubukcu に深甚なる感謝の意を表します 。