アーキテクチャ・ジャーナル 積極的で現実的なクラウドの利用法 Eugenio Pace、Gianpaolo Carraro 2009/08/03
Page1 Page2 Page3 Page4

■LOtSS の LitwareHR への適用

　前のシナリオで説明したように、最適化は抽象化のさまざまなレベルで実現できます。結局のところ、最適化とは大規模システムからある構成要素を選び出し、その要素を安価な代替製品に置き換えることに他なりません。もちろん、その際に代替製品への積み替えコストが高くなり、代替製品を使うメリットが失われることがないようにする必要があります。

　実際、ISV は長い間この手法を取り入れてきました。現在、自社でリレーショナル データベースを開発する ISV はほとんどありません。これは、市販されているパッケージ化された RDBMS が安価であるため、同様の機能を構築することのメリットがないからです。

　市販されている RDBMS を採用することで ISV は投資を最適化でき、データを保存、取得、クエリするために必要な“配管設備”を開発および維持する必要がなくなります。ISV はその分のリソースを、さらに価値の高いアプリケーション コンポーネントに振り分けることができます。しかし、これには負担がまったくかからないわけではありません。レガシー コードが存在する一方、新しいスキルを身に付けたり、新しいプログラミング パラダイムを学習したりする必要があります。これらはすべて“積み替え”コストであり、特化したコンポーネントを採用することの結果として生じるものです。

　ANSI SQL などの標準や共通のリレーショナル モデルの登場と普及は“コンテナ化”に相当し、こうしたコストの削減に貢献してきました。

　ビジュアル コンポーネント（ActiveX コントロールなど）の市場は、LOtSS の一例です。この市場では、外部サプライヤーが特化したコンポーネントを作成することで、大規模ソリューションでの最適化を実現できています。“積み替えコスト”は、だれもがツールに準拠することで生じた事実上の標準によって削減できています（図 6 を参照）。

図 6: 3 つのベンダーによって提供される 3 つの専用ビジュアル パートを基に構築されたウィンドウ

　クラウド サービスにより、ISV はアプリケーションの別の側面を最適化することもできます。

■UI におけるクラウド サービス

　“マッシュアップ”は、クラウド サービス活用の先駆けとなった例の 1 つです。Microsoft Virtual Earth や Google Maps などの地図サービスでは、低コストで複雑な地理情報/地図機能を簡単にアプリケーションに追加できます。多くの小規模 ISV にとって、このような機能を社内システムで開発することはほとんど不可能です。それらの ISV は、イメージ取得/レンダリングのコストをまかなうことができないからです。HTML、HTTP、JavaScript、および XML などの確立された標準と、新たに登場した GeoRSS などの標準は、それらのテクノロジへのハードルを下げることに貢献しています（図 7 を参照）。

図 7: Microsoft Virtual Earth、ASP.NET、および GeoRSS フィードを使用した Web マッシュアップ

■データ層におけるクラウド サービス

　重要なアプリケーションには、ストレージが欠かせません。現在、情報の格納には主に 2 つの手法があります。すなわち、ファイル システムを使用する手法と、リレーショナル データベースを使用する手法です。前者は、大規模データセット、非構造化情報、ドキュメント、または独自仕様のファイル形式に適しています。後者は、通常、高度に定義されたデータ モデルを使用する構造化情報の管理に利用されます。これらのモデルのハイブリッドも既に存在します。多くのアプリケーションは、データのエンコード形式に XML を使用し、それらのデータセットをファイル システムに格納しています。この手法では、個別のサーバーと追加のメンテナンスを要する本格的な RDBMS のコストをかけずに、取得や検索などのデータベースのような機能を実現できます。

　自社ストレージ システムの運用コストには、ディスク領域の管理と、復元性およびフォールト トレランスの実装が含まれます。

　現在、クラウド ストレージ システムにはさまざまなタイプがあります。それらのタイプは、一般的に 2 つに分類されます。1 つ目はファイル システムに近い BLOB 永続性サービスで、2 つ目は RDBMS に似た簡単な半構造化エンティティ永続性サービスです。しかし、これらに類似する機能を過度にクラウドへ移行することには危険が伴います。クラウド ストレージ システムは、基本的にローカルのストレージ システムとは異なるからです。まず、クラウド ストレージでは、システム設計で共通する原則の 1 つ、“データをコンピューティングの近くに配置する”が当てはまりません。ユーザーはストレージと対話するたびにネットワークを経由して要求を生成する必要があるため、ストレージとの対話が多いアプリケーションでは、待ち時間の大きな影響を受ける可能性があります。

　幸いにも、データはさまざまなタイプで送られてきます。ほとんど、または決して変更されない情報（参照データ、履歴データなど）がある一方で、頻繁に変更される情報（現在の株価など）もあります。これを区別することによって、最適化の可能性が広がります。

　クラウド ストレージの活用による最適化シナリオの 1 つは、アーカイブです。このシナリオでは、頻繁にアクセスまたは変更されるデータをローカルに格納します。そして、ほとんど使用されないにもかかわらず削除できない情報は、すべてクラウド ストレージ サービスに移行できます（図 8 を参照）。

図 8: クラウド ストレージ サービスに参照/履歴データを格納するアプリケーション

　この最適化により、使用するローカル ストレージのサイズを、頻繁に使用するデータ分だけに減らすことができ、ディスク容量、サーバー容量、およびメンテナンス コストを抑えることができます。

　ただし、この手法では別のコストが発生します。大部分のクラウド ストレージ システムのプログラミング モデルは、従来のものとは大きく異なります。これは、アプリケーション アーキテクトが、ソリューションとの関係で考慮する必要のある積み替えコストの一例です。ほとんどのクラウド ストレージ サービスでは、基本的な操作には SOAP や REST などのインターフェイスが公開されています。しかし、複雑な演算子やクエリ言語などは今のところ公開されていません。

INDEX
	［アーキテクチャ・ジャーナル］
	積極的で現実的なクラウドの利用法
	1．序論
	2．エンタープライズにおけるLOtSS - Big Pharma
	3．LOtSSのLitwareHR への適用／UIおよびデータ層におけるクラウド・サービス
	4．クラウドにおける認証と承認／細分化、最適化、そして再構成

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）