EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

006 Greenplum DBの柔軟なシステム拡張の話

  2012/04/25 00:00

今回は第6回ということで最終回の予定でしたが、お伝えしたいことがまだまだあります!・・・ということで、残りを3回に分けて解説を続けたいと思います。もう少しだけ、お付き合いいただければと思います。今回は、Greenplum DB最大の特徴の一つでもあるシステム拡張の柔軟性についてご紹介します。

ますます困難になっていくキャパシティプランニング

 従来、データウェアハウスシステム(もしくはデータベースシステムでも同様ですが)を構築するプロジェクトにおいては、厳密にキャパシティプランニングを行うのが一般的でした。具体的には、データベースに格納するデータの量、処理内容や負荷、将来的なデータの伸び率などから、必要なハードウェアのスペックやデータの格納領域、ログの格納に必要な領域と容量、必要なソフトウェアライセンスを決定していく作業です。

 システムを設計する上では当然必要となるプロセスだろう、と誰もが考えることだと思いますが、最近はこのキャパシティプランニングは大変困難を伴う作業になってきています。この背景にあるのは、企業が扱うデータ量の急激な伸びと、ビジネス環境のダイナミックな変化です。

 市場の伸びやトレンドが比較的穏やかに変化するのであれば、企業が扱うデータ量の変化も予測可能な範囲で推移しますが、近年の急激な情報化の進展により、市場の変化はより急激になり、製品やサービスに対するユーザーの興味も一瞬のうちに移り変わるため、データ量および処理需要の予測は非常に困難になってきています。また、企業の買収・合併によるシステム基盤の統合、グループ企業や取引先とのデータ連携システム構築など、ビジネス環境が大きく変わる可能性がある状況では、果たして設計した内容がいつまで有効かどうかという疑問すら出てきます。

 もし必要な処理能力やストレージ容量を、必要なタイミングで拡張して行けるのであれば、システムに対する無駄な投資が無くなり、同時にリスクも減らすことが可能になるため企業にとっては大変大きなメリットになります。しかし、アーキテクチャ上の制限により従来のデータベースシステムではこのようなビジネス側の要求に応えることができませんでした。

Greenplum DBの柔軟な拡張の選択肢

 この状況を変えることができるシステム基盤として注目されているのが、シェアードナッシングMPP (Massive Parallel Processing)アークテクチャをベースとするデータベース製品です。シェアードナッシングアーキテクチャのシステムでは、処理ノードの追加により、データ格納容量と処理性能が台数に比例して伸びて行くため、急激なデータの増大にも応えることができます。また、このようなハードウェアリソースの拡張はデータベースの処理エンジンにより隠蔽され、アプリケーションのレベルではデータの格納場所や処理を行うノード数といったことは意識させないため、処理ロジックの変更も必要ありません。

 さらに、システムの性能向上のアプローチも変わってきます。必要な性能が出ない場合にはSQLの最適化やインデックスなどのデータベースのチューニングテクニックにより性能改善を試みるのが一般的ですが、この方法はデータベース技術者の技量にも依存しますし、最適化が深くなればなるほど適用範囲が狭まっていき、少しの設計変更で意味をなさなくなるというジレンマが発生します。シェアードナッシングアーキテクチャでは、このような人的コストがかかるやり方から、単純なハードウェアリソースの追加による性能改善のやり方への移行を促進します。

 Greenplum DBはシェアードナッシングMPPアーキテクチャの代表的なデータベース製品ですが、大きな特徴の一つは汎用ハードウェアで動作するソフトウェア製品というところです。Linux/Solarisが動作するx86ベースのサーバであればメーカーや製品を選ばず、ネットワークも標準的なEthernetで構成することが可能です。これにより、初期導入時にデータ量が非常に少ない場合でも、最小構成(例えばマスターサーバ1台+セグメントサーバ2台)を非常に低コストで構築することができます。そしてデータ量が増えてきた段階で、サーバ/ストレージ1台単位でシステムを拡張して行くことが可能です。

図1:Greenplum DBのシステム拡張における高い柔軟性
 Greenplum DBのシステム拡張における高い柔軟性

 処理ノードであるセグメントサーバを新たに追加する場合に必要な手順はシンプルです。まず新規にOSおよびGreenplum DBのソフトウェアをインストールした後に、サーバ追加後のシステム構成を記述した構成ファイルを用意し、拡張のためのコマンドgpexpandを実行してシステムを再構成します。これでシステムのセグメントサーバ数の拡張は完了していますが、まだ新規に追加したサーバには何もデータが格納されていません。続けて、データを再分散してシステム全体に配置するためのオプションをつけてgpexpandをもう一度実行します。そうするとバックグラウンドでデータ転送を行うプロセスが起動し、あらかじめ設定された分散ポリシーに従ってデータの再分散が行われます。

 上記の拡張はシステムを停止することなくオンラインで実行できるので、システムを利用している業務への影響は最小限で済みます。再分散の処理はシステムにI/O負荷をかけますが、再分散のバックグラウンド処理を稼働させる時間を指定できますので、影響の少ない時間帯を選んで処理させることも可能です。

導入時の選択肢の一つとしてのアプライアンス

 一方、MPPデータベース製品はハードウェアとソフトウェアが一体となったアプライアンスで提供される形態が一般的です。アプライアンス製品のメリットとしては次のようなことが挙げられます。

  •  初めからハードウェアとソフトウェアが構成されているため、導入すればすぐに使用可能になる
  •  製品ベンダーによるシステムテストやチューニングを実施済みの最適化された構成のため、導入時の作業なしで最大限の性能を享受できる
  •  製品の保守・サポート窓口が1つになるため、障害切り分け等の作業の負担を減らすことができる

 Greenplum DBに関しても、このようなメリットを享受することのできるGreenplum Data Computing Appliance (Greenplum DCA)というアプライアンス製品が提供されています。他社アプライアンス製品と異なるのは、Greenplum DCAのハードウェアはすべて汎用のサーバ、パーツ、スイッチ等のコンポーネントで構成されている点です。汎用ハードウェアを使用するということは規模のメリットを生かせるということであり、最新の技術が反映されたコンポーネントを活用することにより高い価格性能比を実現しています。

 Greenplum DCAは用途やシステム要件によりモジュールを組み替える形で柔軟に構成することが可能です。

 ユーザーは、データセンターにある既存のサーバや調達しやすいサーバを組み合わせて、その上にGreenplum DBをソフトウェアで導入することもできますし、迅速な導入や保守の一元化が重要であればアプライアンスでの導入が有利です。既存環境やシステム要件に合わせてどちらを選ぶかを決定していけばよいでしょう。

次回は、近年大きな話題になることの多い分散処理プラットフォームHadoopとの連携機能を、データベース/Hadoopのアーキテクチャや用途の違いの観点を含めて解説します。

著者プロフィール

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5