最新情報をフォロー
OTN Architect Community
OTN ArchBeatブログ Facebook Twitter YouTube Podcastアイコン

SOAとクラウド・コンピューティング

著者：Jürgen Kress、Berthold Maier、Hajo NormannOracle ACE Director、Danilo SchmeidelOracle ACE Director、Guido SchmutzOracle ACE Director、Bernd Trops、Clemens Utschig-Utschig、Torsten WinterbergOracle ACE Director

Industrial SOAシリーズ記事

2014年4月

クラウド・コンピューティングの喧伝

誰もがクラウド・コンピューティングについて語っているのはなぜでしょうか。ITプロジェクトは当たり前のように、長期化してコストも膨らみ、ビジネスの利害関係者にとってはメリットがほとんどない計画と実装が行われています。これに対して、クラウド・コンピューティングは、IT部門に相談しなくても、ビジネス・ユーザーの要件に合わせたサービスをすぐに実装でき、使用量に応じた請求を受けることができます。

しかし、セキュリティ、アーキテクチャ、可用性、標準などの側面が評価されないことも多く、やがてクラウド・ユーザーはクラウド・プロバイダに振り回されることになります。たとえば、クラウド・プロバイダの倒産後、クラウド・プロバイダを変更して、それに伴ってデータやアプリケーションを移行する必要があるというシナリオは、これまで十分にテストされていません。ビジネスの継続性は、クラウドの評価プロセスの開始段階から重要な役割を果たすものとして考えるべきです。

ここでの最大の課題は、既存のデータとシステムをクラウド・ソリューションとどのように統合するかです。クラウドとオンプレミスのシステムにまたがる統合を実施しなければ、プロセスを独立的に実行することしかできず、クラウド版の孤立したソリューションのサイロができてしまいます。ユーザーにとって重要な情報が複数のプロセスやシステムにまたがって利用できない状況になります。現在は、社内のITで発生していたような問題がクラウド・プロバイダへと移ろうとしています。"レガシー・クラウド"とも言える保守の困難なソリューションの構築を防ぐためには、アーキテクチャ全体を事前予防的に管理すること、特にクラウドへの統合を管理することが重要です。何があっても信頼することをクラウド・プロバイダに求められたとしても、ITのすべての側面をクラウド・ソリューションにアウトソースすることは到底できません。

ind-soa-cloud-fig01
図1：クラウド・コンピューティング導入の動機（出典：IDC）

クラウド・コンピューティングの定義と基準

クラウド・コンピューティングとは、すばやく提供および利用できる、構成可能なコンピューティング・リソース（ネットワーク、サーバー、ストレージ・システム、アプリケーション、サービスなど）の共有プールに対する、使用量に基づいたネットワーク・アクセスのためのモデルです。IPベースのサービスをセルフサービスで要求し、個別にオンラインで利用します。待機時間の短いブロードバンド・インターネット接続を利用できることが前提条件となります。ITリソースはプール内にまとめられ、必要に応じて提供されます。請求は、サービスの使用量に基づいて行われます。

クラウド・コンピューティングの概要

クラウド・コンピューティングのモデルは、水平スケーリングの方法に基づいて以下のように区別されます。

  • Infrastructure-as-a-Service（IaaS） - ハードウェア・プラットフォームをサービスとして提供します。例：Amazon EC2、Oracle Compute Service（現在はプレビュー版を提供）
  • Platform-as-a-Service（PaaS） - ソフトウェア・プラットフォームをサービスとして提供します。例：Google Apps Engine、Oracle Java Cloud
  • Software-as-a-Service（SaaS） - クラウド・プロバイダのハードウェアおよびソフトウェアを仮想化し、機能をサービスとして提供することで、アプリケーションや機能をアウトソースできるようにします。例：Salesforce CRM [文献-1]、Oracle Sales Cloud

一方、デプロイメント・モデルは、可用性とインストール先に従って分類されます。パブリック・クラウドは、インターネット上で一般利用者向けに提供されるサービスです。プライベート・クラウドは社内のサービスです。ハイブリッド・クラウドおよびコミュニティ・クラウドは、これら2つのモデルを混ぜ合わせたものです。たとえば、社内クラウド・アプリケーションの障害発生時、または高負荷のときにAmazonの処理能力を利用します。

大企業ではITが中心的な役割を果たし、競争力につながるため、しばしば独自のデータセンターで社内クラウド・ソリューションが構築されます。中小中堅企業では、パブリック・クラウドのサービスが頻繁に利用されます。さらに、アプリケーションの視点から機能を分類することもできます。B2B分野では、おもにプライベート・クラウドが利用されますが、B2C分野の大半でパブリック・クラウドが利用されます（図2）。

ind-soa-cloud-fig02
図2：クラウド・プロバイダが採用される分野

クラウド・コンピューティングの課題 - SOAベースか

クラウド・コンピューティング・ソリューションのおもな課題は、セキュリティと品質特性（パフォーマンス、待機時間、可用性など）です。統合や適応、俊敏性、ソリューションの再配置可能性は、実装フェーズやその後で大きな役割を果たします（図3）。

ind-soa-cloud-fig03
図3：クラウド・コンピューティングの課題（出典：IDC）

これらの課題は、SOAベースのアーキテクチャにより解決できます（事実、SOAはクラウドの前提条件であると主張する専門家やアナリストもいます）。

米国国立標準技術研究所（NIST）[文献-2]は、クラウドの標準技術を定義する主要機関です。複数のクラウド間の統合に関する課題や、SOAによる課題の解決方法をおもに扱っています。NISTはクラウド環境とクラウド・ブローカ・サービスとしてのオンプレミス環境間の統合方法を定義しています。クラウド・ブローカは以下の3種類に分類されます。

  • サービスの仲介（Service Intermediation） - この種のクラウド・ブローカは、ある固有の機能を強化してクラウド・コンシューマに高付加価値のサービスを提供することで、特定のサービスを強化します。クラウド・サービスへのアクセスの管理、ID管理、パフォーマンスのレポート、高度なセキュリティなどが強化機能として挙げられます。Facebook Connectは、多数のユーザーが日常的に利用している仲介クラウド・サービス・ブローカの一例です。
  • サービスの調停（Service Arbitrage） - この種のクラウド・ブローカは、多様な類似サービスを選択できるようにすることで、柔軟性と"都合に応じた選択"を可能にします。サービスの調停の例としてComputeNextが挙げられます。ComputeNextのクラウド・コンシューマはIaaSサービスを自由に選択できます。
  • サービスの統合（Service Aggregation） - この種のクラウド・ブローカは複数のサービス間の統合を行います。クラウド統合ブローカ（例：Dell Boomi）は、システム間の相互運用性とデータのセキュリティを保証します。この記事では、サービス統合における統合の側面について焦点を当てます。[文献-3]

クラウドでの受注～決済プロセスの例 — SOAを利用する理由

この記事での受注～決済プロセスの例を見れば、クラウド環境でSOAの利用が必要となる理由が分かるでしょう。この例では、ドッグ・フードの広告をSalesforceで行い、Amazonで購入処理、ローカルの財務システムで請求処理を行います。販売、物流、会計の全体的な連携と、それに伴うプロセス・データの統合が重要な役割を果たします（図4）。

ind-soa-cloud-fig04
図4：クラウドでの"ペット・ストア"サンプルのプロセス

ビジネス部門側では、「顧客にとって関心の高い商品はどれか」、「顧客が購入したことのある商品はどれで、現在検討中の商品はどれか」、「顧客の与信枠に応じて、事前の支払後に納品するか納品後に請求するか」、「商品の在庫や配送のステータスはどうなっているか」といった疑問がプロセスの過程で発生します。

これらの疑問に答えるには、さまざまなクラウド・システムをローカルITシステムとリンクすることが不可欠です。このリンクは、プロセスに直接影響します。データを比較するためには、共通のメトリックと定義が必要になります。ベスト・プラクティスとして、顧客、契約、商品などの企業の中核となるエンティティに共通的にアクセスするための基盤となるマスター・データ管理（MDM）プログラムを作成します。このMDMの原則は、クラウドベースのプロセスにも当てはまります。この記事の例では、MDMによりすべてのシステム内の顧客を定義して、その顧客を識別できるようにします。このような統合は以下の複数のレベルで発生します。

クラウドを使用した共有データのデータ統合

データ・レベルでは、定期的なデータ統合とリアルタイムでのデータ統合の考え方を区別します。ポイント・ツー・ポイント統合と定期的なデータ・クレンジングとしては、たとえば、AmazonのショップからSalesforce CRMシステムへの販売データの日次データ送信が挙げられます。一方、請求用に販売データを会計システムに送信するためのデータ統合はリアルタイムで実行されます。

クラウド全体でのプロセス統合

変化する要件に対応するために、各ビジネス部門がその場その場で（権限とロールに応じて）有効なビジネス・プロセスの変更を直接行います。この記事の例に当てはめると、マーケティング部門が送料無料に惹かれてAmazonとeBayの両方で商品を販売することを決定します。これはプロセス統合において、共通データ・オブジェクトに基づいて追加のSaaSソリューションをプロセスに統合することを意味します。そうすれば、エンタープライズ・ビジネス・オブジェクト（顧客の定義などのデータを含むオブジェクト）やエンタープライズ・ビジネス・サービス（顧客ファイルの更新操作など）といったSOAの概念を利用できます。多くの場合、クラウド・ソリューションごとにビジネス・オブジェクトやサービスの定義が異なります。その理由で、プロセスを統合する共通のメタモデルが必要になります。オブジェクト・モデルに求められる特性は以下のとおりです。

  • アプリケーション非依存、作成や変更が容易
  • さまざまなクラウド・ソリューションでスケーラブルかつ再利用可能
  • UN/CEFACT、コア構成要素技術仕様（CCTS）、Open Applications Group OAGIS、ISO 11179、SIDなどの標準技術のサポート

すべてのオブジェクトを共通のリポジトリおよびデータ・ディクショナリに保持する必要があります。オブジェクトの修正にはモデル・デザイナを利用できます。将来的に、複雑なオブジェクトについては、表記規則、カタログ、動的トポロジ、検索エージェントに基づいたモデル・マッチャーが利用される可能性があります（セマンティックSOA）。

クラウドでのルール・エンジンとタスク管理

ルール・エンジン内に抽出可能な意思決定ルールは、ビジネス・ユーザーによっていつでも変更できます。これは、プロセスの俊敏性を確保する上で不可欠な側面です。この記事の例に当てはめると、前回の注文について未決済の150€の支払いを受け取るまでは、顧客の注文は送信されません。このしきい値は、たとえば、未決済の請求総額が非常に低い場合や高い場合に、ビジネス・ユーザーによっていつでも変更できます。ルール・エンジンおよびタスク管理ソリューションは特に、個別にプログラミングされないSaaSクラウド・アプリケーションで利用されます。ただし、使用されるルール・エンジンはクラウド・アプリケーションごとに異なります。この問題は将来的に、共通の標準と、オブジェクトおよびルールを定義するための全体的なメタモデルによって解決できる可能性があります。

同じことがタスク管理にも当てはまります。商品が納品されていない場合、カスタマ・サービス部門が手動で介入して、その顧客に対して速達により無料で配送します。結果のタスクは、Amazonなどのクラウド・ソリューションとローカルの会計システムの両方で実行する必要があります。この解決策の1つとして考えられるのが、統一的なサービス指向型タスク管理、またはプロセスの識別と処理を行う汎用プロセス・ポータルでのケース処理を導入することです。ここで重要になるのは、プロセスのトレーサビリティです。この記事のプロセス例に当てはめると、トレーサビリティとは、注文のステータスや、注文がどこで消失したかが分かることであり、配送の追加コストについて誰が責任を持つかを決定できることです。プロセス所有者はすべてのクラウドにわたって定義されます。あいまいな部分があれば、最終的に中央のエラー・ホスピタルやプロセス用のクレンジング・ハウスに移されます。将来的には、タスク管理、ロギング、エラー・ホスピタル用に一元化されたクラウド・サービスが解決策となるでしょう。

クラウド内のデータやプロセスはセキュアか

セキュリティ標準は、以下のようなシステム境界を越えたセキュリティ対策に準拠するための決定的な役割を果たします。

  • フェデレーテッド・セキュリティと不正検出
  • 認証（OAuth、WSS、SAML、JAAS）
  • 認可（XACML）
  • フェデレーション（SAML、WS-Trust）
  • プロビジョニング（SPML、RBAC）

すべての企業において、データの制御能力を完全に失ってもよいと考えるか、あるいは制御能力を維持する方がよいのかを自問する必要があります。この記事のプロセス例に当てはめると、CRMおよびショップ顧客のデータについてはクラウド・ソリューションに移行するという決定が下されましたが、会計データについては引き続き企業独自のデータセンター内で管理します。重要な企業データの定義やクラウド・ソリューションの評価については、以下の手順が有効であると分かっています。

  • データのライフ・サイクルの定義と導入
  • 顧客データなどの重要なデータのセキュアな分離（仮想データ・プールやタギングの利用）
  • 機密データやデータ・サービスの暗号化
  • セキュリティとリカバリの概念設定（当局による要求に従うためなど）
  • データのセキュアな削除
  • データの地理的位置の定義
  • クラウドの所有者の決定（プライベート・クラウドまたはパブリック・クラウド）

SOAアーキテクチャでは、サービスはIP経由で利用でき、再利用可能です。重要なデータやプロセスの保護はDMZ内で始まり、エンタープライズ・ゲートウェイに従って実施されます（図5）。リクエストはゲートウェイでインターセプトされた後に処理され、適用すべきルール（ポリシー）がチェックされ、Webサービス仮想化レベルに送信されます。

ind-soa-cloud-fig05
図5：エンタープライズ・ゲートウェイ

Webサービス仮想化レベルは一般的に、コールを適切なWebサービスへルーティングするフェデレーテッド・エンタープライズ・サービス・バスです。ゲートウェイはDMZ内のXMLファイアウォールとして導入できます。また、ゲートウェイでは、特定のWebサービス攻撃（XMLコンテンツ攻撃、XMLスキーマ攻撃、DTD攻撃、暗号化攻撃、SOAP攻撃など）を特定して保護することもできます。

受信したメッセージはゲートウェイによってインターセプトされ、ポリシーを使用してチェックされた後、必要に応じて処理されます。ポリシーは、特定のアクションをトリガーする一連のフィルタ条件で構成されます。これらのフィルタはあらかじめ定義され、受信したメッセージのサイズのチェックや認証など、さまざまな機能を提供します。この記事の例に当てはめると、Amazon Shopシステムから受信したメッセージのサイズがチェックされます。このサイズが上限を超える場合は、通知が発行され、それ以降の処理が停止します。

ind-soa-cloud-fig06
図6：Amazon EC2のクラウド管理

後者の機能を使用するために、ゲートウェイをセキュア・トークン・サービス（STS）と統合できます。また、Secure Sockets Layer（SSL）によって、メッセージをトランスポート・レベルで保護できます。

クラウドのガバナンス — SOAプロセスの所有者は誰か

全社的な標準の導入は、SOAとクラウド・コンピューティングの両方にとって中心的な役割を果たします。SOAのガバナンスは、クラウドのガバナンスの先導役となります。SOAアーキテクチャでサービスおよび契約を形式化することが、クラウド・サービスの形式化のテンプレートとして機能します。SOA導入の一環として確立された、ビジネス・ユーザーとIT部門の間の構造およびワークフローがその後の基礎となります。プロセスの管理では、システム全体にわたるソリューションに注目する必要があります。

管理の考え方に基づいて、各種クラウドやシステムにわたるプロセスに対して、リソースの拒否や割当てを行います。監視用ダッシュボードには、クラウド・システムとオンプレミス・システムの両方に関する分析が統合されます。これらの分析は、既存の管理ツールや通知システムとともに統合されるため、プロセスやシステムへの依存性を表すことができます。

将来的には、ビジネス・ユーザーが一貫したプロセス情報とプロセス監視情報をリアルタイムで受け取ることができるようになります（複数のクラウド・プロセスにまたがるビジネス・アクティビティの監視）。利用可能なすべてのプロセスがプロセス・ポータル内で実行され、プロセスの再利用可能性が保証されます。ビジネス部門は個別にシステム・リソースを要求して利用します。IT部門は引き続きITの所有権を保持し、IT管理の責任を負います。プロセスに基づいて、ビジネス部門に対して使用コストが透過的に示されます。

ind-soa-cloud-fig07
図7：クラウド・プラットフォームの要件

SOAとクラウドの同調

クラウドベースのサービス導入を予定している企業は、SOAアーキテクチャを通じてその基礎を確立できます。サービス契約を形式化する際に、SOAおよびクラウドのガバナンスのための基礎を構成します。このSOA統合プラットフォームが、既存アプリケーションのクラウド・サービスへの統合やクラウド間での統合において重要な役割を果たします。将来的には、標準的なデータ・モデルとオントロジおよびセマンティックとを組み合わせることで、複数のシステムやクラウドにわたってデータやプロセスをリンクするための基礎が確立されます。

この統合プラットフォームおよびクラウド・ソリューションのアセットは動的に管理されます。ただし、データを保護するためにはマルチテナント機能が必要になります。データ・アクセスとデータ管理は明確に区別します。すべてのシステムおよびクラウドにわたってプロセスのセキュリティを保証して、ライフ・サイクル全体にセキュリティを適用する必要があります。ビジネス・クリティカルなシステムでは、可用性とスケーラビリティに優れた待機時間の短いフェイルセーフなプラットフォームが求められます。さらに、目の前に迫る問題を検出して、事前に修正することも重要です。障害の発生時には、システムで自律的に修復を実施できます。

SOAおよびクラウドベースのシステムを導入する動機についてまとめたPaul Fremantle氏のことばの引用です。「効果的なクラウドベースのシステムを構築するには、SOAおよび最新のエンタープライズ・アーキテクチャの原則に従う必要があります」

結論

SOAの統合とクラウド・サービス・ブローカの概念がクラウド・コンピューティングにとっての鍵となるのはなぜでしょうか。その疑問に答えるために、ITの歴史をざっと確認しましょう。ITは、カスタム構築によるソリューションから始まりました。Zuse Z10などの独自規格のハードウェア・システムが登場した頃は、オペレータがオペレーティング・システムを含む独自規格のソフトウェアをパンチ・カードに読み込む必要がありました。自動車業界では、大量生産によって幅広い層が自動車を所有できるようになりましたが、同じことがIT業界でも起こりました。大量生産と標準化によって、まずハードウェアとソフトウェアが分離され、オペレーティング・システム、データベース、ミドルウェアなどの標準レイヤーの構築が進みました。

さらに、サービス指向アーキテクチャによって、コンポーネントがサービスへと分解され、再利用可能になり、複数のプラットフォームにわたって統合されるようになりました。この方式は、自動車業界における、複数のモデルが同じ部品（エンジンなど）を共有するプラットフォーム方式と似ています。クラウド・コンピューティングはITパラダイムを変えようとしています。ITシステムは複数のユーザーや企業によって利用されます。自動車業界の例で言えば、ユーザーは自分用の自動車を購入せず、カーシェアリング・サービスを利用するようなものです。カーシェアリング企業は、異なるドライバ間の自動車のブローカ役となります。同様にITでは、クラウド・サービス・ブローカは異なるクラウド間の仲介や統合を行い、ブローカ役を果たします。新しいクラウドベースのソリューションとともに統合する必要のある既存のレガシーなITシステムや、仲介の必要がある異なるクラウド・ソリューションといった問題については、クラウド・サービス・ブローカを使用することで解決できます。

自動車業界では石油が置き換えられる傾向にありますが、それと同様にクラウド・コンピューティングによりIT業界やITの利用方法が刷新される可能性があります。しばらくの間はガソリン自動車を利用するとしても、電気自動車は進化を遂げ、採用も進んでいます。ITに関して言えば、今後も長期的にレガシーなメインフレーム・ソリューションがオンプレミスで運用されるでしょうが、最新のソリューションではクラウド・テクノロジーの利用が進み、SOAテクノロジーがクラウドへの橋渡しとなります。

オラクルのクラウド・ソリューションに関する追加情報

リンクと参考文献

この記事で表される著者の見解は、オラクルの見解とは異なる場合があります。

false ,,,,,,,,,,,,,,,,