クラウドと業界: 第 3 回 電気通信ソリューション

Service Storm による開発および統合の強化

クラウド・ベースの業界ソリューションについて説明する連載の第 3 回では、プロセス中心の斬新な PaaS を紹介します。クラウド対応のセルフサービス電気通信プロトタイピング・プラットフォームである Service Storm は、PaaS モデルの 1 つです。この迅速な統合を可能にするモデルが、専門家ではないユーザーでも、登録されたサービス、マッシュアップ、ビルトイン・ルール、イベント、データベース・サービスを組み合わせることでアプリケーションを作成できるようにしている仕組みを探ります。さらに、クラウド技術と Service Storm によって電気通信ソリューションやエンタープライズ環境における PaaS の機能を強化する方法についても説明します。

Xin Peng Liu, Advisory Software Engineer and Quality Management Architect, IBM

Xin Peng Liu photoXin Peng Liu は、IBM Software Group、Rational Quality Management 開発チームの顧問ソフトウェア・エンジニア兼アーキテクトです。以前は、クラウド・サービスおよび IBM SOA Advanced Technologies の開発リーダーとして、クラウド・コンピューティングと業界ソリューションの設計開発、およびその他の SOA 技術の試験に取り組んでいました。



Yu Chen Zhou, Senior Technical Staff Member and Lead Architect, IBM

Yu Chen Zhou 的照片Yu Chen Zhou 博士は中国の IBM Research に勤務するシニア・テクニカル・スタッフです。IBM SWG SOA Advanced Technologies、China SOA Design Center のクラウド・コンピューティングおよびソリューション・エンジニアの主任アーキテクトとして、クラウド対応業界ソリューション、フェデレーテッド・メタデータ管理、SOA ポリシーなどの高度な技術プロジェクトを発足し、主導してきました。現在、IEEE および ACM のシニア・メンバー、IBM Master Inventor、IBM Academy of Techinology のメンバーであり、かつては W3C および TOG ワークグループのメンバーでもありました。『Service Oriented Computing』の主要な著者である彼は、IEEE カンファレンスの議事録、IBM Research Report、そして IBM developerWorks で 17 の記事を発表しました。



Xi Ning Wang, Advisory Software Engineer and Cloud Architect, IBM

Xi Ning Wang photoXi Ning Wang は、IBM China Software Development Labs 内の GCG Cloud Labs に勤務する顧問ソフトウェア・エンジニアです。彼は、クラウド・コンピューティングの技術およびソリューションの設計、開発経験を積んできました。現在は、クラウド・コンピューティングと業界ソリューションの分野を専門に取り組んでいます。


developerWorks 貢献著者レベル

Liang Xue , Advisory Software Engineer BPM Architect, IBM

Liang Xue photoコンピューター・サイエンスで博士号を持つ Liang Xue は、2006年に IBM に入社しました。彼女は、SOA ポリシー、メタデータ管理、クラウド、および SOA ドメインでの WSRR 開発で、プロジェクト・リーダーを務めています。2011 年に First Plateau を受賞しました。現在は BPM 開発および BPM クラウド配信のシニア技術リーダーとして働いています。



Xiao Xing Liang, Staff Software Engineer, IBM

Xiao Xing Liang photoXiaoxing Liang は、IBM Software Group 内部の Business Performance and Service Optimization チームに所属するスタッフ・ソフトウェア・エンジニアです。SOA、BPM、および Web 2.0 技術およびソリューションの開発に経験を積んでいます。



Chang Hua Sun, Staff Researcher, IBM

Chang Hua Sun photoChang Hua Sunは、IBM China Research Lab のスタッフ研究員です。それ以前は、IBM SOA Advanced Technologies のスタッフ・ソフトウェア・エンジニアとして、複数のプロジェクトで SOA およびクラウド関連の技術およびソリューションを開発してきました。



Shuang Liang, Software Engineer, IBM

Shuang Liang photoShuang Liang は、IBM Software Group 内部の Business Performance and Service Optimization チームに所属するソフトウェア・エンジニアです。SOA および BPM 技術およびソリューションの開発に経験を積んでいます。



2012年 4月 12日

はじめに

この記事は、業界ソリューションでクラウド・コンピューティングを使用できるようにする方法について説明する連載の第 3 回目です。第 1 回では、PaaS のベスト・プラクティスおよびパターンの概要を説明し、第 2 回ではクラウドをベースとした IIF ソリューションのライフサイクル管理の機能および実装メカニズムについて説明しました。今回の記事では、電気通信業界ではクラウド技術によって PaaS をどのように機能強化しているかを説明します。また、Service Storm という SDP が、4 つの異なるユーザーの役割を対象に、サービスの迅速な統合を行うモデルとシステムの正常性を確認するための統合ビューをどのように提供しているのかを探ります。

電気通信技術と IT 技術が急速に収束しつつあるなか、電気通信サービス・プロバイダーは巨額のインフラ・コストを前にして、以下の必要に迫られています。

  • 投資を回収するために、価値の高い新しいサービスを今まで以上に短期間で開発すること
  • 従来のサービス (例えば、音声サービスなど) の収益低下に対処すること
  • 仮想サービスをはじめとするインターネット・ベースのサービスを提供しているサービス・プロバイダーなど、競争力のあるサービスをかなりの低価格で大胆に提供している新しい競合企業に負けないこと

頻繁に使用される略語

  • PaaS: Platform-as-a-Service
  • SDP: Service Delivery Platform

サービス・プロバイダーは、サービスの構築、導入、管理に対する投資を正当化しなければなりません。それと同時に、提携するサード・パーティーのサービス・プロバイダーによる新しい魅力的なサービスの開発を促進することも必要です。このような複合サービスの需要、そして無線ネットワークと有線ネットワークの収束 (ブロードバンドなど) は、縦割り型のアーキテクチャーから脱却する必要性を浮き彫りにしています。今日のサービス・プロバイダーは、サービスやインフラの収束を可能にする水平統合型の標準準拠のプラットフォームをベースにしなければなりません。それが、標準をベースとしたサービス配信プラットフォーム (Service Delivery Platform: SDP) です (SDP とは一般に、特定のタイプのサービスを対象としたサービス配信アーキテクチャーを提供するコンポーネント (サービス作成、セッション管理、プロトコルなど) のセットのことを指します)。

電気通信 SDP は、サービス・プロバイダーが新しい革新的なサービスを作成して配信することを可能にする、水平統合型の標準ベースのオープン・プラットフォームです。広範にわたる顧客ベースを引き付けてサービスを提供するために、現在、電気通信サービス・プロバイダーは音声を中心としたレガシー・ネットワーク・サービスから、業界およびコミュニティー全般の「ロングテール」をターゲットとしたサービスに移行しつつあります。サービスのターゲットはより明確にされ、焦点が絞り込まれ、パーソナライズされていくことになりますが、このような付加価値サービスを開発し、使用するのは、ビジネス・モデルと技術にとって簡単なことではありません。電気通信網とインターネットは、ソフトウェア・アプリケーションおよびアプリケーション開発技術という点で、別々に進化してきたためです。

SDP の場合、ソリューションをホストするのに最適な手段は、付加価値サービスと PaaS (Platform-as-a-Service) を低コストで実現するクラウドです。クラウドは、電気通信サービス用のオープンな開発コミュニティーとビジネス・モデルを提供します。新しいサービスとアプリケーションを顧客に配信するにはいくつかのビジネス・モデルがありますが、そのうち最も有名なのは PaaS モデルです。

ソフトウェア開発サイクルおよび新しいアプリケーションの収益化に主眼を置かなければならないソフトウェア・サプライヤーにとって、PaaS モデルは斬新な手法です。PaaS モデルによって、ソフトウェア・サプライヤーはアプリケーションを設計、開発、テスト、デプロイ、ホストするためのインフラストラクチャーやサービスに対して、投資する必要も保守をする必要もなくなります。PaaS は、アプリケーションを開発およびデプロイするための仮想プラットフォームを作成します。PaaS では、アプリケーション・インフラストラクチャーの運用方法を決定するための選択のほとんどをシステムのプロバイダーが行います。ユーザーはプロバイダーのオンデマンド・ツールとコラボレーティブな開発環境を使用して、それぞれが必要とするアプリケーションを構築します。

PaaS が実現する集中型クラウド・コンピューティング・モデルでは、エコシステム内のさまざまな役割が、付加価値サービスを中心に 1 つのホスト環境に集められます。これらの役割には、以下のものがあります。

  • 電気通信事業者
  • 付加価値サービスの開発パートナー
  • 電気通信関連のアプリケーションを利用する企業
  • 個々の顧客

PaaS は、需要と供給という 2 つの側面を持つ市場モデルに適合します。このモデルでは需要側と供給側の間でのビジネスの仲介がプラットフォームにおいて行われます。PaaS は両方の側面から収益を引き出すことによって、サービスの上流に位置する開発者と、下流に位置する顧客のための価値を創造します。電気通信サービス・プロバイダーは、低コスト、オープンな性質、製品化までの時間短縮、リッチなアプリケーション、そして収益を伸ばすためのさまざまな手法を実現することによって、この新しいビジネス・モデルのメリットを享受します。電気通信事業者によってソフトウェア・サイクル全体に対応した環境が提供されることから、開発者にとっては、独自の IT インフラのプロビジョニングおよび管理にかかるコストを削減できることになります。PaaS を開発で利用することによる主なコストは、アプリケーションが使用した実際のコンピューティング・リソース、あるいはコンピューティング・リソースを使用するユーザー数に基づくランタイム料金です。


Service Storm

私たちは、大量の顧客を持つ電気通信事業者 (移動体通信事業者を含む) を調査し、ビジネス・モデルと技術モデルの両方における要件と課題を分析しました。その結論として私たちが実装したのが、PaaS モデルのクラウド対応セルフサービス電気通信 SDP である Service Storm です。Service Storm は Web 2.0 とその他の仮想化技術を利用して、エコシステムにおけるさまざまな役割の要件に対処します。Service Storm は従来のエンタープライズ開発モデルやパートナー・ベースの開発モデルとは異なります。Service Storm が実現するのは「オープン開発コミュニティー」モデルです。このモデルでは、ドメインの要件や、コミュニティーの要件、あるいはユーザー固有の要件にすら応じた電気通信ベースのアプリケーションを、誰もが素早く開発することができます。

Service Storm は、パーソナライズされた付加価値サービスを迅速に統合するモデルを提供します。この Service Storm モデルでは、専門家ではないユーザーでも、登録されたサービス、マッシュアップ、ビルトイン・ルール、イベント、データベース・サービスなどを組み合わせてアプリケーションを作成することができます。そして、異なるユーザー・グループ間での独立性とセキュリティーを確保するために、3 層の分離メカニズムでリソースをセキュアに維持します。リソースの割り当てについては、管理およびキャパシティー・プランニングのメカニズムを利用して適切に行うことで、容易に行えるようにします。また、ビジネス・ユーザーの要求の増加に応じてデプロイメントとスケーラビリティーを迅速かつ柔軟に調整できるように、自動デプロイメント・メカニズムも提供されています。さらに Service Storm は、ビジネス・ソリューションとそのホスティング・プラットフォームに関して、ビジネスと IT 両方の観点でのシステム正常性を統合したビューを提供します。

電気通信事業者が市場を制するためには、絶えず革新を行い、カスタマー・エクスペリエンスを差別化し、アジャイルでなければなりません。電気通信事業者のビジネス・モデルでは、電気通信事業者が成功するための要素には、プラットフォームのトレードオフ (オープン・プラットフォームかクローズド・プラットフォームか、独自仕様か標準か、無料か有料か) のバランスを適切に取り、分断化を避けることが関係してきます。このビジネス・モデルでは、私たちは付加価値のある電気通信サービスに関する要件に応じて、役割を以下の 4 つのカテゴリーに分類しています。

個人ユーザー
これまで、パーソナライズされたサービス用の限られたオプションを持つエンド・ユーザーとしてのみ振舞っていた個人ユーザーは、独自のアプリケーションを開発できるだけの IT の知識を持ちあわせていません。しかし、個人または小さなコミュニティーに固有の要件については深く理解しているので、個人のニーズやビジネスの機会にあわせて革新するために簡単に使える機能によってブラック・ボックス化された環境を必要とします。

アプリケーションを一から作成することを望んでいる個々のユーザーの要件は、電気通信事業者に新しいビジネス・モデルをもたらします。増収の機会は、従来の音声ベースや SMS ベースのビジネスだけにあるわけではありません。そのようなモデルでは、リッチ・コンテンツ、マルチメディア、そして極めてパーソナライズされたサービスから、エンド・ユーザーが大いにメリットを得られるはずです。

電気通信事業者
この電気通信事業者は、一般ユーザー・コミュニティー向け付加価値サービスを開発し、ホストしています。このモデルは、従来の付加価値サービスのビジネス・モデルに分類されます。さらに小規模なユーザー・コミュニティーに対し、より粒度の細かい付加価値サービスを提供するために電気通信事業者に必要なのは、製品化までの時間を短縮する、一層強力で柔軟な開発モデルとインフラストラクチャーです。
ビジネス・パートナー
ビジネス・パートナーは、一般のユーザー・コミュニティー向け付加価値サービスを開発し、その利益を電気通信事業者と分かち合います。ビジネス・パートナーの要件は電気通信事業者の要件と同様ですが、それに加え、開発のホスティング・コストを削減すること、そして電気通信業界の標準に準拠した製品環境をテストし、プロビジョニングするという要件もあります。
企業ユーザー
従来から企業ユーザーは、移動性労働力の管理システムやフロント・エンドの顧客関係管理 (CRM) システムなどといった業界固有のアプリケーションをエンタープライズ・システムの一部として所有するために、電気通信サービスを利用しています。特に、IT 能力のない中小規模の企業では、電気通信サービスが大いに利用されています。

このような企業ユーザーの要件は、新しいアプリケーションの開発およびデプロイメントを、その一部をアウトソースすることで迅速化することにより、IT インフラの保守コストを削減することです。

Service Storm は、上記の 4 つのカテゴリーのユーザーの要件をすべて満たすように設計されています。図 1 に、Service Storm のアーキテクチャーを示します。

図 1. Service Storm のアーキテクチャー
Service Storm のアーキテクチャー

このアーキテクチャーは以下のコンポーネントで構成されています。

  • サービス・アセンブラー: アプリケーション・ロジックをドラッグ・アンド・ドロップ操作で定義できるビジュアル・ツールです。付加価値サービスの実装を目的として、電気通信サービス (SMS、MMS、LBS (Location Based Service)) とその他の要素 (Web 2.0 UI および外部サード・パーティーのサービスを含む) を統合することができます。また、コーディングせずにデプロイ可能な成果物を自動的に生成することができます。
  • 管理コンポーネント: BOSS とのコラボレーションにより、SDP に管理機能を提供します。管理コンポーネントには以下のものがあります。
    • サービス管理: SDP に公開された電気通信サービス、SDP に登録された外部サード・パーティーのサービス、および新しく生成されたアプリケーションを管理するためのコンポーネントです。
    • ソリューション管理: サービスを実装してクラウド環境にデプロイされたソリューションを管理するためのコンポーネントです。
    • クラウド管理: クラウド・インフラストラクチャーとしてのコンピューティング・リソースを管理するためのコンポーネントです。
  • ランタイム・ソフトウェア・プラットフォーム: このプラットフォームはクラウド環境に組み込まれ、付加価値サービスのためのアプリケーションをホストするランタイム環境を提供します。通常、ランタイム・ソフトウェア・プラットフォームを構成するのは、アプリケーション・サーバーとプロセス・サーバー、そしてビジネス・ルール、イベントおよび運用状況を重点的に扱うその他のランタイム環境です。
  • クラウド・インフラストラクチャー: コスト節減を目的としたリソース共有に必要な機能のための、仮想化されたコンピューティング・リソースを一元管理するクラウド環境です。

インフラストラクチャーの要素

複数の個別のアプリケーションを共有リソース・プールでホストするクラウド・プラットフォームは、コンピューティング能力をオンデマンドでアプリケーションに割り当てることができます。クラウド・プロバイダーにとって課題となるのは、以下の点を考慮してリソースを管理することです。

  • ホストするアプリケーションのサービス品質に対する高いレベルの要求
  • リソースの管理コスト

ホストしているランタイム環境は、アプリケーションがデプロイされる前に、必要なリソースが割り当てられた上で、SDP 内に自動的に作成されなければなりません。Service Storm ではセキュリティーのために、3 層のリソース分離メカニズムを使用して、割り当てられたリソースがユーザー・グループごとに確実に分離されるようにします。その一方で、サービス・プロバイダーに割り当てられたリソースは、ユーザー・グループのサイズやビジネス拡大の要件に応じてスケールアップとスケールダウンをすることができます。さらに、リソースをより効率的に管理できるように、キャパシティー・プランニング・メカニズムが各役割の要件に対処します。

リソースの分離

クラウド・コンピューティングでは、サービスを専用コンピューター・プラットフォームで実行することにより、サービス・プロバイダーを、プラットフォーム所有者とクラウド・インフラストラクチャー・プロバイダーから切り離すことができます。このモデルは、インフラストラクチャー・プロバイダーが個々のサービスを適切に分離できることを意味します。Service Storm を構成する物理リソースには、ホスト、CPU、メモリー、ディスク・スペース、およびネットワークがあります。Service Storm のソフトウェア・リソースには、OS、ミドルウェア、アプリケーションなどがあります。

各サービス・プロバイダー、そして各サービス・プロバイダーのエンド・ユーザーは、干渉や競合を避けるために、互いに分離されていなければなりません。Service Storm が提供する 3 層の分離メカニズムは、以下のようにして、リソースを分離できるようにします。

アプリケーション層
アプリケーション・レベルで分離することにより、アプリケーション・データとビジネス・ロジックは十分に分離された状態になります。エンド・ユーザーは、許可なく他のエンド・ユーザーのデータやビジネス・ロジックにアクセスすることはできません。エンド・ユーザーのアカウント情報は、特定のアプリケーションに関連付けられるからです。許可されたエンド・ユーザーだけが、該当するサービス・プロバイダーによって公開される、その特定のアプリケーションにアクセスすることができます。この分離は、特定の電気通信事業者のグループまたはビジネス・パートナーのグループが作成したアプリケーションに対し、エンド・ユーザーが確実にアクセスできるようにします。アプリケーションは、エンド・ユーザー、電気通信事業者、およびビジネス・パートナーごとに分離されます。
ネットワーク層
ネットワークの分離は、特定の物理ネットワークへのネットワーク・トラフィックを分離してセキュリティーおよび効率性を強化するために、よく使用されています。分離技術には、一般に以下の 2 つのタイプがあります。
  • 物理的な分離。物理ノード間の物理的な接続を切断します。
  • 論理的な分離。多くの場合、ソフトウェアを使用して分離します。
仮想 LAN 技術や仮想スイッチ技術と結び付けられた仮想マシンの場合、ネットワークの分離は、物理サーバー・ホストと、これらのホスト上で実行される仮想マシンに効果的に適用することができます。
仮想マシン層
同じ物理マシン上で実行される仮想マシンは互いに分離されます。仮想マシン・モニターは、準仮想化と完全仮想化の両方の場合に、仮想ゲスト環境およびホスト・システムでの分離に対処します。仮想マシンで実行されているソフトウェアは、仮想マシン・モニターや別の仮想マシンで実行されているソフトウェアに対して、アクセスすることも変更を行うこともできません。図 2 に仮想リソースの分離の一例を示します。
図 2. 仮想リソースの分離
仮想リソースの分離

リソースの管理およびスケーリング

リソースの使用量には、ストレージ、I/O 帯域幅、CPU 使用量、メモリー使用量が含まれるのが一般です。アジャイルなリソース管理機能が実現する柔軟なメカニズムは、ビジネス・アジリティーという成果をもたらします。サービス・プロバイダーには、電気通信分野でのさまざまな機能、品質、およびリソースのスケーリングが必要です。例えば、基幹ビジネス・プロセスのサービス・プロバイダーが応答時間の短縮と可用性の向上を実現するには、より多くの仮想リソースが必要となります。その一方、支援サービスを提供するサービス・プロバイダーには、経費を削減するために少ないリソースあるいは共有リソースが割り当てられます。クラウド・インフラストラクチャーで仮想リソースを調整することにより、容易に柔軟性をもたらすことができます。

さまざまなパフォーマンス調整の問題を解決するために、水平スケーリング・メカニズムと垂直スケーリング・メカニズムが用意されています。水平スケーリングには、スケールアップ機能とスケールダウン機能が含まれます。垂直スケーリングは、スケールアウト機能と縮小機能を意味します。

例えば、サービス品質を向上させるために、リソースに関してビジネス・サービスの要件が増えたとします。ハイエンドの用途が増えてくると、サービスにはさらに高度な機能が必要になってきます。この問題を解決するのは、ミドルウェアのクラスタリングです。Service Storm では、組み込み仮想テンプレートが、例えばスタンドアロンのアプリケーション・サーバーとクラスターなどといったトポロジーを提供し、通常のシステム・スループットとそれよりも高いシステム・スループットの両方に対応します。スケーラビリティーを向上させるためにビジネス・ユーザーに必要な作業は、Service Storm のサービス品質オプション (エンド・ユーザーの数、高可用性を有効にするかどうかなど) を指定することだけです。すると、指定したオプションに対応する仮想システム・リソースが自動的に関連付けられて、サービス品質の要件が満たされることになります。

電気通信事業者およびビジネス・パートナーの役割では、基本的なリソースのスケーリングの他、さまざまな役割を対象としたサービス・ライフサイクル全体にわたる詳細なサブリソース・テンプレートを定義することもできます。仮想マシンのトポロジー、あるいは各仮想マシンのハードウェアおよびソフトウェア・リソースは、ビジネス・モデラー、開発者、テスター、本番環境管理者などの役割に応じてカスタマイズされます。

Service Storm の初期リソース割り当て機能とスケーリング機能は、それぞれのグループ (サービス・プロバイダー・グループまたはサービス・エンド・ユーザー・グループ) でのユーザーの役割に応じてカスタマイズされており、サービス・ライフサイクル全体に対応可能です。

キャパシティー・プランニング

キャパシティー・プランニングには、以下の作業が含まれます。

  • 将来、負荷レベルがシステムを飽和状態にした場合に必要なキャパシティーの量を予測すること。
  • システムが飽和状態になるのを遅らせるための最もコスト効率の高い方法を判断すること。

Service Storm で提供しているキャパシティー・プランニングは、さまざまな役割に対処します。電気通信事業者とビジネス・パートナーは、初期リソース割り当て時のリソースに対する制約を定義し、将来リソースを増やす場合の上限を指定することができます。さらに、サービス・レベル・アグリーメントに、リソースの拡張および回収についての条件を定義することも可能です。

ユーザーが使用する仮想リソースの使用量が事前に定義されたしきい値に達すると、クラウド・インフラストラクチャーは仮想マシン・リソースを拡大するための手段として、追加のメモリーとディスク・スペースを割り当てるか、クラスターにノードを追加して作業負荷のバランスを取ります。逆に、仮想システムの使用量が事前に定義されたしきい値を一定の期間下回った場合には、アイドル状態のノードが取り除かれたり、メモリーが回収されたりします。

自動スクリプト (「より賢いデプロイメントと監視」で説明) に基づき、仮想リソースには水平スケーリングまたは垂直スケーリングが適用されます。仮想リソースの管理は、サービスを中断することなく、サービス・プロバイダーのキャパシティー・プランニングに従って自動的に行われるため、SDP の運用コストが大幅に削減されることになります。

システムのスケーリング

コンシューマーの数が増えるにつれ、さらに大きなコンピューティング能力が必要になってきます。Service Storm では、ランタイム環境を水平スケーリングすることも、垂直スケーリングすることもできます。水平スケーリングと垂直スケーリングのメカニズムは、パフォーマンス調整の問題を解決する二次元的な手法です。これらの自動デプロイメント機能によって提供される柔軟なメカニズムが、ビジネス・アジリティーを実現します。

スケールアップおよびスケールダウンは、実行中のサービス・ノードがパフォーマンス監視結果に基づいて調整されることを意味します。スケールアップとは、デプロイされたサービス・ノードへの CPU やメモリーの割り当てを増やすことで、スケールダウンとは、逆に CPU やメモリーの割り当てを減らすことです。

スケールアウトと縮小でも、デプロイされたソリューションの実行能力を調整することができます。スケールアウトは、本番環境の作業負荷が増大し、デプロイされたソフトウェア・クラスターへの負担が大きくなった場合に適用されます。その場合、新しいノードがプロビジョニングされてクラスターに追加され、それによってコンピューティング能力が強化され、パフォーマンスが維持されることになります。縮小も似ていますが、逆の効果があります。つまり、稼働中の環境がアイドル状態になると、クラスターからメンバー・ノードの一部を解放して、リソースを別の用途に使用できるようにします。


より賢いデプロイメントと監視

柔軟で効率的な SDP では、ランタイム環境 (OS、ネットワーク、ミドルウェア、およびアプリケーションを含む) を自動的にインスタンス化して構成することが必須です。Service Storm のデプロイメント・モデルは、仮想マシン・テンプレート、ネットワーク・リソース、そして自動スクリプトを弾性的に組み合わせ、デプロイメント全体を構成可能にしています。つまり、従来のように画一的にソリューションをデプロイするのではなく、各コンポーネントを柔軟に構成できるということです。また、Service Storm はビジネスとインフラストラクチャーの監視を集約したビューも提供します。このビューは、デプロイ後のランタイム管理に大いに役立ちます。

構成可能なデプロイメント・モデル

自動デプロイメントを実装するために、Service Storm では以下の要素からなる完全なデプロイメント・モデルを提供しています。

仮想マシン・テンプレート
OS とミドルウェアは、1 つの仮想マシン・テンプレートで統合されます (図 3 を参照)。OS とミドルウェアの構成ポイントは、特定の仮想マシン・テンプレートに対して定義されるため、サービス・プロバイダーがカスタマイズすることができます。構成ポイントには、3 つのタイプがあります。それは、特定のソフトウェア構成ポイント、OS レベルの構成ポイント、そしてハードウェア・リソースのプロパティーです。
ネットワーク・リソース
Service Storm はネットワークを一元管理します。管理対象には以下のものがあります。
  • 仮想マシンの内部ネットワーク・アドレスの割り当て
  • 外部サービスのアドレスおよびポートの構成
  • 内部仮想システムへのルーティング
エンド・ユーザーはこれらの値を指定することで、デプロイされた環境を制御することはできません。
自動スクリプト
自動スクリプトは、特定の構成ポイントに対してリソースを構成または再構成します。Service Storm は統合されたモデルをベースに、デプロイメント時に特殊な構成自動スクリプトを関連付けます。すべての構成ステップが編成されて、それぞれのステップに対応する自動スクリプトが呼び出されると、サービス・プロバイダーから、インフラストラクチャーを実装する負担が取り除かれます。
図 3. アプリケーション実行時の自動デプロイメント
アプリケーション実行時の自動デプロイメント

自動デプロイメントが完了した時点で、Service Storm はテンプレート・リポジトリーから仮想マシン・テンプレートを選択し、選択したテンプレートに必要な自動構成スクリプトを関連付けます (図 3 を参照)。

ソリューションのデプロイメント

Service Storm はソリューション全体のデプロイメントに対処するだけでなく、個々のコンポーネントのデプロイメントと構成にも対処します。電気通信分野で柔軟なビジネスを実現するには、SDP が、ソリューション全体についても、単一のリソース・コンポーネントについても、自動的にデプロイするための素早く簡単な方法を提供しなければなりません。

Service Storm には、例えばアプリケーション・サーバー・クラスターと高可用性のソリューション・パターンなどといった、標準的なミドルウェア・ソリューション・パターンがいくつも用意されています。これらのソリューション・パターンには、ソリューションを再び生成できるように、事前にビルドされたミドルウェアのメタデータと自動スクリプトが組み込まれています。ユーザーは、構成ポイントの値を設定することで、ソリューション・パターンをカスタマイズすることができます。例えば、サービス・プロバイダーはクラスターに含めるノード数と、高可用性機能を使用可能にするかどうかを選択することができます。

集約された監視ビュー

監視も SDP の重要な機能です。監視によって、物理リソースとソフトウェア・リソースの実行状況を把握することができます。PaaS モデルをベースとする Service Storm では、例えばビジネス・プロセス・インスタンスの応答時間、仮想システムのリソース使用状況 (CPU、メモリー、およびディスク・スペース) などの監視専用のリソースを選択することができます。

ビジネス・リソースとインフラストラクチャー・リソースの両方の監視結果が、統合されたビューにマッシュアップされてユーザーに表示されます。この広範な結果が統合されたビューから、SDP 全体の状況を把握できるため、SDP 運用のリスクが軽減されるとともに、緊急時の迅速な対応が実に容易になります。ビジネス・プロセスの重要業績評価指標 (KPI) は、Service Storm の監視ポータルに取り込まれます (図 4 を参照)。

図 4. ビジネス・プロセスの KPI の監視
ビジネス・プロセスの KPI の監視

参考文献

学ぶために

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

  • IBM Industry Application Platform: このプラットフォームを使用できるクラウドはいくつかあります。いずれかのクラウドを選んで、WebSphere Application Server および DB2 Express-C を使って特定の業界のあらゆるアプリケーションを開発、デプロイしてください。
  • その他のソフトウェア評価版を調べてください。

議論するために

コメント

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=Cloud computing, Industries
ArticleID=808844
ArticleTitle=クラウドと業界: 第 3 回 電気通信ソリューション
publish-date=04122012