3層構造アーキテクチャがもたらすメリットとは?

前回はSQL Data Warehouseの概要を説明しましたが、その際、SQL Data Warehouseにおいて最も特徴的なアーキテクチャは「3層構造のアーキテクチャ」と述べました。今回はこの「3層構造のアーキテクチャ」がもたらす、さまざまなメリットを説明していきます。

3層構造のアーキテクチャ

SQL Data Warehouseでは、「1台のコントロールノード」「スケールアウト可能な複数台で構成するコンピュートノード」「60のストレージ」と3層構造のアーキテクチャで構成されています。このような3層構造のアーキテクチャにより、SQL Data Warehouseでは他のPaaS型データウェアハウス(DWH)サービスにはない特徴的な機能を実装しています。

以下、SQL Data Warehouseの特徴的な機能を紹介しましょう。

データベースの停止

SQL Data Warehouseではデータベースの停止ができます。一見当たり前のように思うかもしれませんが、実のところ、この機能はクラウド型のRDBMSサービスとしては珍しい機能です。世の中に存在するクラウド型DWH・サービスにはコンピュートノードとストレージが一体型（このようなサービスを2層構造のアーキテクチャという）のものがありますが、そういったサービスでは、データベースを停止したり、即座に起動したりすることはできません。

この停止機能のメリットはどこにあるのでしょうか。例えば、筆者が担当していたDWHでは、多くの場合、土日の利用者はいません。要するに企業の休日である土日は、バッチなどの処理を除いては、DWHシステムはほぼ利用されることはありません。一方で、クラウドは利用した分だけ料金が課金される仕組みで、これはSQL Data Warehouseでも同様です。

この段階で何を言いたいか察しがついた方も多いと思いますが、要するに、データベースの停止機能を利用することにより、例えば、会社が休みで利用者がほとんどいない日はSQL Data Warehouseを停止させておくことが可能となります。

2層構造のアーキテクチャのDWH・サービスの場合、コンピュートノードとストレージが一体化されているため、コンピュートノードを停止させることはストレージのデータも消してしまうことになりますが、3層構造のSQL Data Warehouseはコンピュートノードを停止させても、ストレージのデータが消えることはありません。

停止状態のSQL Data Warehouseにおいてはコンピュートノードの料金は発生せず、ストレージのみ従量課金が発生します。この機能を使うことにより、コストコントロールを行い、高額になりがちなDWHの料金の最適化を行うことが可能です。

瞬時にスケールアウト/スケールインが可能

SQL Data Warehouseでは、コンピュートノードを増やして処理能力を増やす（スケールアウト）ことや、逆にコンピュートノードを減らして処理能力を減らす（スケールイン）ことを、瞬時に行えます。これも、データを事前に60のストレージに分割して格納しており、なおかつ、コンピュートノードがストレージと分離しているため可能となっている機能です。

例えば、SQL Data Warehouseで3台のコンピュートノードで稼働している場合、各コンピュートノードには20のストレージが割り当てられています。このSQL Data Warehouseを6台のコンピュートノードで稼働するようにコントロールノードを増やす（スケールアウト）場合、内部的には、各コンピュートノードにこれまで20のストレージが割り当てわれていたものを10のストレージへ割り当てられるように、コンピュートノードとストレージの割り当ての変更作業が行われます。

一方、コンピュートノードとストレージが一体型のサービスで同様のスケールアウトを行う場合は、現在起動中のサービスとは別にスケールアウト済みのサービスを起動させ、そのサービスに対して内部的にデータの移行を行うという動作となります。

このスケールアウトの問題点は、スケールアウトに伴う「データ移行動作中」にサービスが読み取り専用になるなど、ある程度の利用制限を受けてしまう点です。さらにデータ量が多くなるにつれて、データの移動量が多くなって移動時間がかかってしまうため、利用制限の時間も長くなります。大規模なDWHでスケールアウトを行う場合は、かなり綿密に業務制限などを行う必要があるでしょう。

SQL Data Warehouseに話を戻すと、スケールアウトの動作は先ほど説明した通り、新しいコンピュートノードを起動させ、ストレージの割り当てを変更するのみです。したがって、スケールアウト自体は非常に高速に行うことができ、その逆のコンピュートノードを減らすスケールインに関しても同様に高速に行うことができます。

例えば、バッチ処理などで大量の処理能力を必要とするタイミングでは多くのコンピュートノードを起動させ、逆に平常時には少ないコンピュートノードで稼働させるなど、時間帯に応じてコンピュートノードをスケールアウト/インさせれば、処理能力の変更を容易に行えます。

この機能もまた、高額となりがちなDWH・サービスのコストコントロールに役立つとともに、「必要な分だけ、必要なリソースを調達する」というクラウドらしい機能です。

ストレージの拡張を意識する必要がない

SQL Data Warehouseの高い拡張性を象徴する機能として、ストレージの自動拡張があります。

コンピュートノードとストレージ一体型のサービスの場合、ストレージが足りなくなったら、コンピュートノードとストレージを合わせて追加しなければならず、スケールアウトの動作を必要とするなどの制約を受けます。これに対し、SQL Data Warehouseはストレージの拡張はコンピュートノードとは無関係に自動で実施されます。

このようにSQL Data Warehouseでは、大量データを処理するアーキテクチャだけでなく、高額になりがちなDWH・サービスのコストの問題に対して、柔軟にコントロールできるような伸縮性、拡張性をもったサービスとなっています。

これだけ挙げればSQL Data Warehouseはいいことずくめに見えますが、一方で不得意な処理もあります。それは小さなクエリが大量に実行されるようなOLTP系のシステムには不向きであるということです。

同時接続は1024まで可能ですが、クエリの同時実行は2017年5月時点で最大でも32となります。OLTP系のような細かなクエリが大量に実行されるシステムには、SQL Data Warehouseではなく、SQL Serverや同じAzureのSQL Databaseのほうが適しています。大量のデータを比較的少人数で高速に分析するようなシステムにこそ、SQL Data Warehouseは向いていると言えます。

山口 正寛

1984年生まれ。大阪府出身、東京都在住。データベースエンジニア。SQL Server、Oracle、MySQL、PostgreSQLなどのデータベースで、小規模から大規模な案件まで数多く経験。現在ではクラウドの流れに逆らうことなく、「データベース×クラウド」をキーワードに案件対応、セミナー活動、執筆活動など幅広く活動中。株式会社システムサポート所属。