Apache Derby データベースを使う、第 1 回: 集中型のプロバイダー環境での管理対象オブジェクト

管理対象要素として Derby を使用して、システムを拡張および自動化する

この 2 回の連載では、例えば IBM® オートノミック・コンピューティングのタッチポイント技術や WSDM (Web Services Distributed Management) などの技術を使用して、Apache Derby データベースの管理を自動化することの重要性を取り上げます。第 1 回のこの記事では、需要が高まっている自動 IT 管理について説明します。自動 IT 管理は、アプリケーション、データ・センター、そして経営業務から事務処理までの一元化と統合によって促進されます。データベースの統一化された利用と管理要件への取り組み、そして FCAPS の使用が IT 管理ソリューションの設計にどのように役立つかを含め、Derby を管理対象要素として使用する方法を学んでください。

Stephen B. Morris, CTO, Omey Communications

Stephen は、アイルランドの Omey Communications で CTO を務めています。過去 20 年間にわたり、世界屈指の複数のネットワーキング会社で、J2EE/J2SEベースのネットワーク管理システム、課金アプリケーション、SNMP エンティティーの移植と開発、ネットワーク・デバイス技術、そして GSM モバイル・ネットワーキング・アプリケーションなど、広範なソフトウェア・プロジェクトに取り組んできました。著書には「Network Management, MIBs and MPLS: Principles, Design and Implementation」(Prentice Hall PTR、2003 年) がある他、ネットワーク管理をはじめとした記事が InformIT および OnJava.com に記載されています。彼の連絡先は、stephenbjm@yahoo.com です。



2006年 10月 31日

エンド・ツー・エンドの IT 管理の必要性

組織とサービス・プロバイダーとの間の境界線は、これまで通信サービスと IT サービスを分け隔てる線に沿って引かれていました。その一方で、請求書と固定費の件数を減らすという要件を満たすための企業のニーズとして、通信サービスと IT サービスをまとめて提供してくれる単一のプロバイダーを求める組織が増えてきています。この密接な統合を実現するには、単にソフトウェア技術をデプロイして使用するだけでは足りません。これから説明するように、必要となるのはソフトウェア・エンティティーの適切なインスツルメンテーションによって管理の容易性を実現することです。IBM は、このように極めて特殊化された、将来的に高い収益が見込まれる特定分野での技術を開発している数少ない組織の 1 つです。

図 1 に示すのは極めて典型的な企業の略図で、ここでは広範なソフトウェアとハードウェアが日常的に使用されています。アプリケーションをホストするためにグリッド・プロバイダーなどの専門プロバイダーを採用する企業が次第に増えてきていることから、図 1 の左側のネットワーク・クラウドにある要素は、右側のネットワーク・クラウドへと移行しています。

図 1. IT および通信体系
The IT and telecom ecosystem

IT 管理ツールは、企業ネットワークとサービス・プロバイダー・ネットワークの両方で重要な要素となっています。この記事で話題とする課題は、Derby のようなアプリケーションを対象としたエンド・ツー・エンドの IT 管理ツールが欠如しているということです。IBM は他に先駆けて、この問題をオートノミック・コンピューティングおよび WSDM (Web Services Distributed Management) の採用により解決しています。慎重な管理を行うには、すべての IT インフラストラクチャーが計測機能を備える必要があります (インスツルメンテーション)。そのため、Derby にはアプリケーション・デプロイメントと管理という 2 つの異なる捉え方があります。この記事では、このようなすべての IT リソースに対する 2 通りの捉え方の必要性を明示し、対処するための原則を導き出します。


IT: 成功の代償

私は 2003 年の著書「Network Management, MIBs and MPLS: Principles, Design and Implementation」(「参考文献」にリンクを記載) で、現代のネットワークは、離島のようにそれぞれ独立したオートメーションで構成されていると述べました。この考えは今でも同じで、ますます多くのネットワークとサービスが統合されずに動作しています。世界経済はどうやら技術びいきのようで、私たちが今日、当然のもののように思っているネットワークとサービスには、例えば、(自宅と職場での) インターネット、携帯電話、IPTV (インターネット・プロトコル TV)、衛星放送、オンライン・ゲーム、オンライン・コンテンツを使用したゲームなどがあります。これらの技術が、ほとんど日常茶飯事のように使われているのです。このようなネットワークの重複した特性を表す一例として、UK を拠点とするテレビ会社では現在、携帯電話でテレビ番組の録画を操作できるようになっています。このような録画方法には、携帯電話ネットワーク、インターネット、そしてテレビ会社へのアクセスが必要です。料金は固定制ではなく、このサプライ・チェーンのそれぞれのプロバイダーがアクセスに対する料金を請求しています。

その一方で、IT 産業では以下のような劇的な統合と注目すべき新しい (それほど新しくないものもありますが) ソフトウェア標準が生まれています。

  • Web サービス
  • BPEL (Business Process Execution Language)
  • Java™ 技術 (今では事実上の標準です)
  • オープン・ソース製品の多彩な組み合わせ

オープン・ソース・モデルの成功は確固たるものなので、ハイテク製品には以下の主要な要件があると自信を持って言えます。

  • 低価格の製品であること。
  • 柔軟性が高く、ユーザーが構成可能な製品であること。
  • 機能する製品であること。
  • 常識的な価格が設定された製品であること。

最近では、ソフトウェア・ベンダーが収支を合わせるのは困難なことでしょう。一部のベンダー (ウィルス対策ソフトウェアのベンダーなど) は、サブスクリプション・モデルを用いて少なくともある程度の収益を確保するようになっています。オープン・ソース・ツールの実力を知るには、Linux® と Apache Axis を見れば十分です。

ソフトウェアの場合のオープン・ソース・モデルには、1 つの大きな欠点があります。それは、Linux や Axis など、スタンドアロンの垂直アプリケーションに偏りがちになるということです。このような閉鎖的アプリケーションには、いくつかの興味深い特色があります。例えば、多くの場合はインストールして自動化するのが難しいという点です。これらのアプリケーションは、自動管理を目的としてビルドされているわけではありません。閉鎖的ソフトウェアでは一般的に、管理の容易性よりも機能性のほうが重要視されます。

現在のソフトウェア (オープン・ソースと閉鎖的ソースの両方) の閉鎖的性質は、その所有コストについてもかなりの犠牲を払っています。ソフトウェアの問題が解決されたように見える場合でも、以下の 2 つの顕著な問題が浮かび上がってきます。

  1. 組織には自動化されたエンド・ツー・エンドの管理が必要なこと (この連載の主題です)。
  2. 組織ではますます IT 準拠が必要になってきていること。これは、IT とその使用方法が組織の方針と法規制の両方に準拠していることを確実にするためです (IT 準拠についての詳細は、「参考文献」を参照してください)。

サービス提供: 区分された家

IT サービスおよび通信サービスのデプロイメントと管理で主な問題となるのは、この 2 つはこれまでまったく異なる分野として扱われてきたという点です。具体的には、以下のように定義されてきました。

  • IT サービスとは、ビジネス・ソフトウェアのユーザーに対して提供される機能のことで、例えば、ネットワーキング、データベース・エンジン、アプリケーション、パッチ、ウィルス対策ソフトウェアの更新、オペレーティング・システムなどが挙げられます。IT サービスは、組織的ビジネス・プロセスが使用するコンピューティング・インフラストラクチャーを表します。
  • 通信サービスとは、企業によって直接使用されるネットワーク技術 (テレフォニーなど)、あるいは他のサービス間のパイプ役となるネットワーク技術 (VPN (Virtual Private Network)、MPLS (Multiprotocol Label Switching) など) のことです。通信サービスは従来、専門プロバイダーによって提供されています。
  • デプロイメントとは、データベース・エンジン、ネットワーク、およびミドルウェアなどの IT 要素の使用を開始し適用することです。デプロイメントの主要な要件は、デプロイされた要素の使用方法です (管理ではありません)。
  • 管理とは、基礎となる IT インフラストラクチャーの運用サービスを維持するための一連のプロセスのことです。

デプロイメント本位のアプローチは、管理本位のアプローチとは完全に異なるものになりがちです。この概念を具体的に理解するには、デプロイメントと管理の違いを示す 2 つの例、オーバープロビジョンと正しいサイズのプロビジョン、そして QoS (Quality of Service) との関係を考えると役立ちます。デプロイメント本位のアプローチでは、帯域幅、サーバーの数、そしてプロセッサー処理速度などのパラメーターを過剰に設定する傾向があります (オーバープロビジョン)。一方、管理本位のアプローチでは、実際の負荷および予測負荷の大きさと一致するようにインフラストラクチャーを整備しようと試みます。

つまり、デプロイメント本位のアプローチはオーバープロビジョンによって QoS を最大限にするよう期待をかけ、管理本位のアプローチは動的に QoS を確実にしようと試みるということです。IBM のオートノミック・コンピューティング・イニシアチブでは、効果的なデプロイメントの基礎にもなる管理を中心としたフレームワークを提供しています。それではここで、エンタープライズ・アプリケーションでの Derby の使用方法を簡単に紹介しましょう。


アプリケーション・レベルでの Derby の使用方法

アプリケーション (およびデータベース管理者 (DBA) などのユーザー) は、リレーショナル・データの保管、取得、そして操作のために Derby を使用します。遅延の可能性があることを別として、データがホスト・コンピューター上にあるものなのか、あるいは複数のネットワークを介して送られてきたものなのかは、アプリケーションにとってほとんど問題になりません。データがクライアント・プログラムに向けてプッシュされると、プロセスが透過的に発生します。

このコンテキストでは、アプリケーションは図 2 に示すように Derby を捉えます。つまり配管系統で言えば、Derby はパイプに接続されたプロバイダーで、データはパイプを介して双方向にプッシュされます。

図 2. 1 つ以上のネットワークで Derby を使用するビジネス・プロセスのアプリケーション
図 2. 1 つ以上のネットワークで Derby を使用するビジネス・プロセスのアプリケーション

リスト 1 は、Derby のデータベース・インスタンスにアクセスするクライアントの例です。

リスト 1. Derby のデータベース・インスタンスにアクセスするクライアント
C:\java\derby\db-derby-10.1.2.1-bin\demo\nserverdemo>java SimpleNetworkClientSample
Starting Sample client program
Got a client connection via the DriverManager.
connection from datasource; getDriverName = Apache Derby Network Client JDBC Driver
Got a client connection via a DataSource.
Testing the connection obtained via DriverManager by executing a sample query
number of rows in sys.systables = 16
Testing the connection obtained via a DataSource by executing a sample query
number of rows in sys.systables = 16
Goodbye!

リスト 1 は、Derby 配布にバンドルされているサンプル Java プログラムからの出力です。ここで重要なのは、クライアントは単純に Derby インスタンスと基礎となる IT インフラストラクチャーを使用して、必要なリソースを消費するという点です。一方、この単純なクライアント・プログラムの実行によって発生するリソース消費量についてはどうでしょう。


リソースを使用する側としての Derby

リスト 1 に示したプログラムの実行中に、戦略的ポイントで中断してみましょう。このプローブ・ポイントで、どのようなタイプのリソースが消費されているかを確認するだけの単純なチェックを行います。図 3 は、Microsoft® Windows® XP タスク・マネージャーからの引用です。強調表示した合計 (Totals) が、Derby クライアントのリソース消費量を調べるための大体の基準となります。

図 3. リソース消費量の基準
図 3. リソース消費量の基準

次に、Derby クライアントに戻って、リスト 2 の変更されたプログラム出力を見てください。

リスト 2. Derby のデータベース・インスタンスにアクセスするクライアント
C:\java\derby\db-derby-10.1.2.1-bin\demo\nserverdemo>java SimpleNetworkClientSample
Starting Sample client program
Got a client connection via the DriverManager.
connection from datasource; getDriverName = Apache Derby Network Client JDBC Driver
Got a client connection via a DataSource.
Testing the connection obtained via DriverManager by executing a sample query
Please press enter to test the Derby connection.

図 4 に、Derby クライアントが SQL ステートメントを実行する直前のリソース消費量のスナップショットを示します。すなわち、リスト 2 で説明している時点です。

図 4. SQL コマンドを実行する直前のリソース消費量
図 4. SQL コマンドを実行する直前のリソース消費量

図 3図 4 を見ると、Derby をこのように使用した場合のリソース消費量が大体分かります。この 2 つの図で強調表示したカウンターに、ホストのリソース消費量が反映されます。Handles は、ファイルやレジストリー・エントリーなどのエンティティーを示します。Threads は、プログラム・タスクを同時に実行できるオブジェクトです。Processes は、プログラム全体 (Derby クライアントなど) に関連します。クライアントがネットワークで動作している場合は、ネットワーク関連のリソース消費量 (帯域幅、ルーター/スイッチの処理、およびサーバー・アクセス) を考慮に入れることができます。

消費されたリソース要素は、前述のオーバープロビジョンと QoS についての内容を反映します。つまり、クライアント、データベース、ネットワークなどを伴うシステムをデプロイする場合、そのリソース消費量によって必要となるインフラストラクチャーが左右されるということです。システムに必要な規模を推定するのは、簡単な作業ではありません。ただし、次のセクションを読むとわかるように、管理問題を機能分野別に分けると IT 管理ソリューションの設計に役立ちます。


管理特性: FCAPS

FCAPS (Fault, Configuration, Accounting, Performance, and Security) は、ネットワーク管理の分野では長年使われている頭字語です。IT 管理分野ではまだ普及していないものの、この頭字語は管理ソリューションを分類および設計するための優れたテンプレートとなります。FCAPS は、管理システムが一般的に (あるいは理想として) 対処する主要な機能領域を説明しています。Derby 関連の IT インフラストラクチャーに当てはめると、FCAPS の各領域は以下のように説明できます。

  • Fault (障害): 障害に対処 (サーバーに障害が発生した場合、バックアップに切り替えてサービスを引き継ぐなど)
  • Configuration (構成): システムの操作に対処 (ユーザーおよびデータベースの作成など)
  • Accounting (アカウンティング): Derby データベースを使用する際の課金に関するあらゆる側面に対処
  • Performance (パフォーマンス): Derby データベースの操作パターンの分析に対処 (ボトルネックが発生したかどうかの判断など)
  • Security (セキュリティー): セキュリティーのインプリメンテーションに対処 (パスワードの保守やセキュリティー問題のチェックなど)

次のセクションでは、FCAPS をベースとした架空の IT 管理ソリューションが、Derby をどのように捉えているかを説明します。


IT 管理と Derby に対する IT 管理の 捉え方

以下の単純な Derby アプリケーションのシナリオで、FCAPS に関してそれぞれのシナリオをどのように分類できるかを簡単に説明しましょう。まず、存在しないデータベース・テーブルをクライアントが開こうとすると、障害が発生します。IT 管理システムは、クライアントにメッセージで応答できます。クライアントがデータベースを開いて、テーブルのいくつかの列を更新するクエリーを実行すると、構成機能が実行されます。アカウンティングは、データベース内のテーブル拡大に応じたディスク・スペースの使用に対する課金を処理します。課金は必ずしも金銭的なものであるとは限りません。単に、ある種の使用タリフ (部門間の合意など) を反映する場合もあります。パフォーマンスは、大量の SQL コマンドが実行されたときにボトルネックが発生したかどうかの判断に基づかせることができます。セキュリティーは、ユーザーが該当するデータベースにのみアクセスすることを確実にします。

Derby には、アプリケーション・プログラミング・インターフェース (API) が組み込まれているため、プログラマーはこの API を使用して、データベースを中心とした完全なアプリケーションをビルドできます。概念としては、この API は図 5 のような構成で、開発者はこの API でアプリケーションを作成してコンパイルし、そのアプリケーションを Derby データベースに対して実行します (データベースを作成した後)。

図 5. ファット・クライアント・プログラムと Derby の相互作用
図 5. ファット・クライアント・プログラムと Derby の相互作用

データベースのライフ・サイクルに含まれるすべての要素 (データベースの作成、テーブルの更新、テーブルの削除、テーブルの挿入、データベースの削除など) を制御するために、開発者は図 5 のアプリケーションのセマンティクスを作成することができます。

Derby データベースのもう 1 つの使用方法は、管理対象オブジェクトとして使用することです。図 6 に示すように、この手法では管理アプリケーションが代わって複雑な Derby 操作を処理します。

図 6. シン・クライアント・プログラムと Derby 管理システムとの相互作用
A thin-client programinteracts with a Derby management system

この管理アプリケーションは、FCAPS 機能もインプリメントします。このように、Derby を管理対象オブジェクトとして扱うことにより、より単純なクライアント・プログラム (つまり、ソフトウェアの数が減るということ)、そして IT 管理システムの土台という、2 つの付加価値要素を手に入れることができます。


インスツルメンテーションの概要

幸いにも、図 6 に示した管理ソフトウェアを作成するための技術が存在します。IBM と Sun Microsystems は双方ともにその技術でスタブを持っていました。IBM ではオートノミック・コンピューティング・タッチポイント、そして Sun Microsystems では JMX (Java Management Extension) です。いずれの技術も総称してインスツルメンテーションと呼ぶことができますが、それぞれに固有の利点があります。例えば、タッチポイントは Web サービス・ベースで WSDM に準拠しており、Axis などの便利なオープン・ソース・ソフトウェアを採用しています。一方、JMX は Java ベースの技術で、Java プラットフォーム (リモート・メソッド呼び出し (RMI) およびセキュリティーなど) を活用しています。

この連載の第 2 回では、タッチポイント技術を使って、Derby を管理対象オブジェクトとして使用し、図 6 の要件を満たす方法について説明する予定です。Derby を管理対象オブジェクトとして組み込むには、以下の原則があります。

  • Derby インスタンスをリモート側で開始および停止できること
  • アプリケーション・サーバーのインフラストラクチャーを使用して Derby を実行可能であること
  • Derby クライアント・プログラムのソース・コードを簡単に拡張できること
  • Derby インフラストラクチャー・データにアクセスしやすいこと
  • Derby のエラーと例外を有効に処理すること

オートノミック・コンピューティング・タッチポイントが上記を含めたさまざまなニーズに対応する理由は、第 2 回を読むとわかります。


まとめ

IT の要件は急速に増加し続けています。この増加を加速させている原因の一端となっているのは、携帯電話やインターネットによって家庭で技術を利用できるようになるなど、商用ネットワーク・サービスの範囲が広がっていることです。利用者はますます技術に精通するようになり、エンタープライズ IT と同様のサービスを求めるようになってきています。

単純に IT をデプロイして性能をオーバープロビジョンするといった古いモデルが活躍していた時代は終わりに近づいています。システムは与えられる負荷に合わせて動的に拡張するように装備する必要があります。そして、これを唯一可能にするのがオートメーションです。この問題の一部の要素は専門プロバイダー (グリッド・サービス・ベンダーなど) に任せることもできますが、企業内にはまだたくさんの問題が残ります。このような背景においては、IT がそれ自体の成功の犠牲になっていることと同じです。不幸中の幸いは、すぐそばに救いの手があるということです。

管理対象オブジェクトとしての Derby などのアプリケーションを使用して、まずは必要なオートメーション要素をネットワークの適所に配置してください。次に、これらのオートメーション要素を使って複雑な管理対象オブジェクトを管理すれば、基本アプリケーション・ソフトウェアに切望される簡易化を実現できます。さらに、単純化したクライアントを FCAPS 準拠の IT 管理システムと連動させてください。この連載の最後には、この一連の要件を達成する方法がわかるはずです。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Information Management
ArticleID=232663
ArticleTitle=Apache Derby データベースを使う、第 1 回: 集中型のプロバイダー環境での管理対象オブジェクト
publish-date=10312006