ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

クラウド・アプリケーション開発について
知っておくべきこと

アプリケーション (APP) /APP-14-106
Research Note
M. Driver
掲載日:2015年1月20日/発行日:2014年10月15日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2015年3月9日(月)・10日(火)に開催する 「エンタプライズ・アプリケーション & アーキテクチャ サミット 2015」 のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)


クラウド・アプリケーションの開発と導入をサポートするアーキテクチャの選択は、品質と適時性に影響し、成否の分かれ目にもなり得る。ITリーダーは、手痛い失敗を回避し、クラウド・アプリケーション開発の作業を最適化するために、本リサーチノートに示すベスト・プラクティスに従うべきである。


要約


主要な課題

  • 新規のクラウド導入を最適化しようとする際、アプリケーション開発 (AD) 部門のリーダーは、クラウド・ホスティング、クラウド最適化、クラウド・ネイティブというアプリケーションの側面や、サービスとしてのインフラストラクチャ (IaaS)+ミドルウェア、クラウド・ベースのサービスとしてのプラットフォーム (PaaS)、クラウド・ネイティブなPaaSといった実行環境に遭遇する。これらは内容が紛らわしく、選択を難しくしかねない。
  • 先行コストとマイグレーションのリスクが、初期のクラウドADの意思決定を左右する。しかし、長い目で見れば、長期的な投資やクラウドの利点を最大化する必要性が、戦術的な選択よりも優先されるべきである。
  • クラウド・テクノロジは急速に発展しているため、クラウド・ソリューションの設計、導入、 管理の絶え間ない変化が、今後数年間の課題になる。

推奨事項

  • クラウド・プラットフォームを利用するカスタム・ソリューションが、どの施策にも必要なわけではない。したがって、電子メール、CRM、ERP、ガバナンス、ビジネス生産性向上のアプリケーションといった単純なソリューション・シナリオには、サービスとしてのソフトウェア(SaaS)ベンダーが提供している、従来の社内エンタプライズ・ソフトウェアに代わるサービスを検討する。
  • クラウドの戦術的な導入については、コストやリスクを最小限に抑えるために、クラウド・ホスティングによるアプリケーション戦略を選択する。
  • 影響が大きい長期的なクラウドの導入には、クラウド最適化アプリケーション戦略を策定する。ただしその際には、当該ソリューションの提供に必要な新しいアプリケーション・アーキテクチャ、原理、スキル、ベスト・プラクティスに伴うコストとリスクに注意する。
  • クラウドの特性を全面的に生かしたソリューションを導入するには、クラウド・ネイティブ・アプリケーション戦略を選択する。ただし、AD部門がこの新しいモデルを発展させるにつれて生じる相応のコストについて予算を組み、計画を立てる。


目次



図目次



はじめに

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

ガートナーではクラウド・コンピューティングを、従来のサーバ中心型アプローチと区別する5つの基本特性によって特徴付けている。

  • サービス・ベース:利用者側の事情は、適切に定義されたサービス・インタフェースを介して、プロバイダー側の事情から切り離されている。
  • 拡張性と弾力性:サービスの処理能力は、利用者の需要に応じて、すべて自動化された速度で(サービスによって数秒であったり、数時間であったりする) 加減される。
  • 共有:サービスは、リソースの蓄積を共有することで規模の経済性を確立している。
  • 従量課金制:サービスは、各種の料金モデルに対応できるように、使用基準に従って追跡記録される。
  • インターネット・テクノロジの活用:サービスは、URL、HTTP、IPのほか、RESTful、Web指向アーキテクチャなど、インターネットの識別子、フォーマット、プロトコルを使用してデリバリされる。

こうした特性は、クラウド・プロバイダーや利用者に影響を及ぼす (備考1および「Defining Cloud Computing」参照)。それぞれのクラウド特性は、主要なアーキテクチャ原理によって実現され、サポートされており、通常は一連の一般的なクラウド設計パターンに沿って実装されている (こうしたクラウド特性、アーキテクチャ原理、設計パターン [さらにアンチパターン] については「Cloud Characteristics, Principles and Design Patterns」の中で詳しく述べている)。

クラウド・コンピューティングは、4タイプのサービスを通じて、アプリケーション導入の選択肢を企業に提供する。すなわち、IaaS+ミドルウェア(以下IaaS+)、クラウド・ベースのPaaS、クラウド・ネイティブなPaaS、SaaSである(それぞれの詳細は「ITリーダーが知っておくべきこと:アプリケーションPaaSモデルと利用パターン」APP-13-126、2013年8月23日付を参照されたい)。

一般にSaaSは、特殊なビジネス・ニーズに対する「既製」の解決策になるが、IaaS+やPaaSは、新しいソフトウェア・アーキテクチャのための土台である。IaaS+とPaaSは同様の目的に使用されるものの、共有インフラストラクチャに対する両者の取り組み方はまったく異なる。IaaS+と2種類のPaaS (クラウド・ベース、クラウド・ネイティブ) は、ほとんどいずれのタイプのソリューションも提供可能であるが、そこには、企業が選択する組み合わせによって固有の性質、制約、能力が含まれる。例えば、IaaSは最も柔軟であるが、アプリケーション開発者に委ねられるアーキテクチャと保守にかかわる責任はより大きい。PaaSは制約がより多いものの、抽象化された高次のAPIやソフトウェア開発キット (SDK)を通じて、いっそうの運用効率と開発生産性をもたらす。

クラウド・プラットフォームは、クラウド・サービスとして独自に提供される新しいソリューションのための基盤を提供する。クラウド・ホスティング、クラウド最適化、クラウド・ネイティブは、企業が新しいクラウド・ソリューションを構築する際に理解すべき、最も重要なコンセプトである (図1参照)。




図1. クラウドの概念



出典:ガートナー (2013年11月)



  • クラウド・ホスティング・ソリューション:エンタプライズ・アプリケーションをIaaSに移植することで、単純なハードウェア共有型のマルチテナント性のメリットを実現している(「マルチテナント性に関するガートナーの参照アーキテクチャ」APP-10-138、2010年12月24日付参照)。例えば、ほとんど使用されていないアプリケーションを稼働しているデータセンターのサーバを停止して撤去し、そのアプリケーションをIaaS上に再展開し、必要な場合のみ起動するといったことが可能になる。これにより、企業はワークロードをクラウド・デリバリ・モデルへと移行できるが、クラウド・ホスティングでは、クラウド・コンピューティングの主要な長所を完全には生かせない。
  • クラウド最適化ソリューション:クラウド・プラットフォームの広域に及ぶ特性を生かせるようにリファクタリングや再設計を施されているが、それは直接的な下位レベルのプログラム制御を通じて実現されていることが多い。優れたクラウド最適化ソリューションの基本原理には、水平的な拡張性、耐障害性、高性能、効率性、容易な相互運用性が挙げられる。この場合、企業は、静的なフットプリントのアプリケーション(例えば、Web、アプリケーション、データベース・サーバから成る単純なn層アプリケーション) を、IaaSまたはクラウド・ベース のPaaSに移行することで、自動的にスケールの拡大/縮小に適応するように適宜改良できる。
  • クラウド・ネイティブなソリューション:クラウド・コンピューティング・プラットフォームの決定的な特性を全面的に生かせるように設計されている。これらのアプリケーションは、クラウド・コンピューティングの中核的な特性を具体化しており、こうした特性を可能な限り堅牢な形で提供し、サポートする中核的な原理、パターン、ベスト・プラクティスを活用して構築されている。これらのアプリケーションはIaaSを基盤として構築することも、より生産性を高めるためにクラウド・ベースのPaaS上に構築することも、あるいはより適した形としてクラウド・ネイティブなPaaS上に構築することもできる。クラウド・ネイティブなアプリケーションは、クラウド・コンピューティングの特性のメリットをほとんど生かせるだけでなく、次世代アプリケーションの特性 (例:DevOps) を生かす上でも都合が良い。
  • IT部門におけるクラウド・ネイティブなアプリケーション設計のプラクティスやパターンの採用は、依然として主に最先端のテクノロジ採用企業でしか見られないが、ガートナーの顧客が伝えるところによれば、自社独自のクラウド・ソリューションを構築することへの関心が、運用の複雑さの軽減や迅速な市場化というクラウド・サービスのメリットを獲得する目的から高まっている。プライベート・クラウド・コンピューティングの採用増は、主としてコンピューティングおよびストレージの粒度の粗い仮想化 (例:IaaS)において現れることが多いものの、クラウド・ネイティブなアプリケーション設計でなければ最大化できないセルフサービスのリソースをAD部門に提供する。プライベートPaaSという発展中の構想は、こうした動向の一環である。人気の高いプログラミング・フレームワーク(Spring、Rails、Node.jsなど)が発展してクラウド・ネイティブなアプリケーション設計の原理を網羅するとともに、こうした原理の採用を簡易化しようとしている。

クラウド・ホスティング、クラウド最適化、クラウド・ネイティブをめぐる適切な選択は、この意思決定を左右する所定のビジネス・シナリオを前に、企業が最も重視するクラウド特性はどれであるかに、完全に依存している。理論上 (しばしば実質的にも) AD部門は、インフラストラクチャ(例:IaaS)にプログラミング・モデルを提供する環境でクラウド・ホスティングから始め、後に当該アプリケーションのクラウド最適化に取り組む決断を下してもよい(ただし、過去に選択したプログラミング手法の影響で多大な労力が必要になることから、それが出発点にならない場合も多い)。

企業は、価値とコストの目標達成に向けてクラウド・コンピューティングを採用している。それぞれのIT部門は、アプリケーションをデータセンターからIaaSプロバイダーに移行することでコストを削減しようとクラウド・コンピューティングに期待することもあれば、PaaSによって開発者の生産性を向上させ、市場投入までの期間を短縮することで価値を得たいと考えることもある。IT部門によって動機がさまざまであるように、利用可能なクラウド・プラットフォーム・プロバイダーのテクノロジやビジネス戦略もさまざまである。したがって、企業はビジネス・プロセスとの連携、現行アーキテクチャの制約、潜在的なアプリケーション移行の目的に基づいて、アーキテクチャの選択肢の中から慎重に選択を下す必要がある。



クラウドのサポートはアーキテクチャの3つのレイヤからもたらされる

クラウド・アプリケーションの主要な特性をサポートするアーキテクチャ原理は、展開されるソリューションの3つの明確なレイヤとして示される(図2参照)。クラウドのサポートは、基盤となるクラウド・プロバイダー(通常はIaaS+またはPaaS)において開始される。そのランタイム・コンテナは、根底にあるシステム・コードにおいて、クラウド・アーキテクチャの原理をサポートしている。具体的にどの原理がサポートされるか、どのようにサポートされるか、またサポートの堅牢さについては、クラウド・プロバイダーのタイプ(例:IaaS+であるか、PaaSであるか)や、特定のタイプ内のベンダーによって異なる。




図2. アプリケーション・アーキテクチャにおいてサポートされるクラウド特性



出典:ガートナー (2013年11月)



自社のインフラストラクチャ・サービスにクラウド・アーキテクチャ原理への堅牢なサポートを含めているクラウド・プロバイダーは、こうした機能をアプリケーション・コード自体に実装するために必要なコードを少なくしている。また、プラットフォーム自体の根底にある設計モデルに開発者を従わせることで、上位レベルのアプリケーション・コードの柔軟性を制限している。

クラウド・アーキテクチャの原理は、アプリケーション・コードで直接サポートすることも可能である。こうしたサポートの第1層は、アプリケーションのシステム・コードのレイヤ、すなわち一般的にはクラス・ライブラリ、言語コンパイラ、サービス・モジュール、SDKなどの中に含まれる。これらはクラウド・アプリケーション開発者によって活用される再利用可能な資産であるが、その下部にあるクラウド・プロバイダーからは独立している。このレイヤを超えるクラウド特性のサポートがアプリケーションで必要になった場合、開発者はアプリケーションのプログラミング・コードにそれを直接実装しなければならない。

IaaS+のプロバイダーは、クラウド・アーキテクチャの原理について簡易なサポートしか提供しない。クラウド・ベースのPaaSプロバイダーは、より幅広いクラウド特性を適度にサポートする。クラウド・ネイティブなPaaSプロバイダーは、あらゆるクラウド・アーキテクチャ原理のための堅牢なサポートを備えている。図3に、各クラウド・プラットフォームに期待される特性や、それらの特性がアーキテクチャの複雑性や構築に必要とされる開発者のスキルに及ぼす影響を示す。




図3. クラウド・インフラストラクチャ特性の影響



出典:ガートナー (2013年11月)

* 表をクリックすると拡大表示します。




分析

強力な後方互換性が必要であるが、クラウド特性はわずかでよい場合は、 IaaS+を基盤とするクラウド・ホスティング・アーキテクチャを検討する


長所:少額のIT投資と強力な後方互換性
短所:短所:クラウドのメリットはハードウェア共有型のマルチテナント性に限定

クラウド・ソリューションを構築し、提供する際に最も混乱の少ない方式は、アプリケーションとその基盤となるミドルウェアを、IaaS+の環境上に移行してインフラストラクチャ近代化の基盤を提供することである(「ミドルウェアの役割とIaaS、PaaSを理解して最大限に活用する」APP-12-96、2012年9月10日付参照)。こうすることで開発ツール、開発工程の大部分、既存のコード資産をそのまま維持できる。ソリューションは、従来のホスティングに類似した形態でIaaS+のリソース上に再展開されるが、一方で従量課金制と手動による弾力性の調整(例えば、利用度の高い期間はアプリケーションを小規模 なインスタンスから大規模なインスタンスに移行する)というメリットが加わる。その結果得られるクラウド・ホスティング・ソリューションは(IaaSプロバイダーのサービス品質[QoS]次第ではあるが)エンタプライズ規模の特性を維持したものとなり、ITスタッフの再教育は最小限で済む。

原則として、IaaS+への展開は、データセンター空間を他のテナントと共有する(電源と不動産を共有し、場合によっては、他のテナントと同一物理サーバ上で共存し、ハイパーバイザによって隔離される)場合を除き、ローカル・サーバへの展開と同じである。多くの人は、当該IaaSオファリングの調整/管理用のAPIやセルフサービス・インタフェースによってそれが指定される場合を除いて、自分が使用しているインスタンスがどこで実行され、データがどこに保存されるかを意識しない。しかし実際には、クラウド・コンピューティングに期待する特性を得るために、アプリケーションや付随する管理、セ キュリティ、ストレージ・モデルをある程度改良することが妥当である。例えば、リニア・スケーリングを可能にするために、アプリケーションにステートフル・コンポーネントを削減する調整を加えなければならない場合がある。こうした調整作業はクラウド最適化に相当し、すなわち、クラウド・コンピューティングのメリットを生かすために、アプリケーション・アーキテクチャを段階的に発展させることとなる。

クラウド・ホスティングの主な価値は、ハードウェア共有型のマルチテナント性によるコストと若干の弾力性という利点を生かせることである。企業は、ハードウェア・リソースの管理と調達の負担を、サービス・プロバイダーに委託することもできる。ただし、システム・インフラストラクチャ上で稼働しているスタックの継続的な保守と管理の責任は、通常は企業側に残る。さらに、すべてのエンタプライズ・アプリケーションが、IaaS上で運用した方が低コストというわけではない。アプリケーションは、リソース要件が予測不能である、流動的である、または短期的である場合に最もメリットを得られる。要件が安定し、予測可能で、長期的である場合には、変動的なクラウドIaaS環境で運用するとコストが高くつくケースがあり、特に企業が社内システムで仮想化を多用している場合はなおさらである。

推奨事項:AD部門のリーダーは、アプリケーションに強力な後方互換性と最小限のクラウド特性が必要な場合、クラウド・ホスティングのアプリケーション・アーキテクチャと、(ミドルウェアのホスティングを伴う)クラウドIaaS+のプロバイダーを組み合わせることを検討する。技術的にはクラウド展開であるため、これらのアプリケーションは管理された仮想化ランタイムの中で規模の経済性を享受できるが、真のクラウド・アーキテクチャの原理によるメリットはわずかである。


強力な後方互換性と最小限のクラウド特性が必要な場合は、クラウド・ホスティング・アプリケーションとクラウド・ベースaPaaSを検討する


長所:(スキルとコードの両面における)適度な後方互換性
短所:
クラウドのメリットは、具体的なアプリケーション設計に多分に依存し、わずかまたは中程度

IaaS+を基盤とするクラウド・ホスティングよりも高度なアプローチは、既存のソリューションを導入するか、または新たなエンタプライズ規模のアプリケーションを構築する基盤として、クラウド・ベースのPaaSを利用する方法である。クラウド・ベースのPaaSプロバイダー内にソリューションを再展開するには、おそらく多少のリファクタリング作業が必要となるが、一般的には中程度か、またはわずかである。

クラウド・ベースのPaaSプロバイダーがIaaS+ソリューションと最も明らかに異なる点は、Tibco Silver FabricやCloudSoft AMPなどのクラウド管理プラットフォーム (CMP) を、自社のインフラストラクチャ・サービス内に直接含めていることである。この追加により、ワークロード需要の変化に応じたアプリケーションの弾力性(自動スケーリング)が提供される。ただし、クラウド・ベースのPaaSプロバイダーは、他のクラウド・アーキテクチャ原理に関して簡易なサポートしか備えていないことがあり、その場合は開発者がアプリケーション・システムやビジネス・ロジック内で直接それらに対処するしかない。

推奨事項:開発者は、アプリケーションにおいて適度な後方互換性とある程度のクラウド特性が必要な場合、クラウド・ホスティングのアプリケーション・アーキテクチャとクラウド・ベースのPaaSプロバイダーを組み合わせることを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキルやベスト・プラクティスへの依存が少ない。開発者は、クラウドの目標、特性、アーキテクチャ原理、パターン、責務のわずかな面についてのみ責任を負う。


適度なクラウド特性と導入時に最大限の柔軟性が必要な場合は、クラウドIaaS+を基盤とするクラウド最適化アプリケーションを検討する


長所:クラウド・プラットフォームの強力な独立性と最小限のロックイン
短所:PaaSテクノロジの機能を複製する多大なコーディング作業

開発者は、中核的なクラウド特性に対してより堅牢なサポートが必要になった場合、クラウド・ホスティングからクラウド最適化アプリケーション・アーキテクチャへの移行を検討すべきである。開発者に与えられる最初の選択肢は、おそらくIaaS+へのクラウド最適化アプリケーションの導入である。こうしたアプリケーションは、クラウド・コンピューティングの利点を生かせるように進化しているが、そもそもは単純なクラウド・ホスティングのプロジェクトとして開始されていることが多い。クラウド・ホスティング・アプリケーションは、前身であるクラウド以前のアプリケーションと同様のアーキテクチャ原理を擁するが、クラウド最適化アプリケーションはアーキテクチャ上の束縛をなくし、そこから解放されている。開発者は、継続的なリファクタリングと修正の工程を通じて、弾力性に優れるものの障害が発生しやすいIaaSリソースに対応したアーキテクチャ・パターンを徐々に組み込むことで、こうした変革を達成する。

クラウド・ホスティング・ソリューションの導入を計画しているアーキテクトは、基盤となるIaaS+プラットフォームをそれほど理解しないままで切り抜けられるが、クラウド最適化アプローチの場合、アーキテクトはIaaSオファリングに加え、そのオーケストレーションと管理機能について詳しく習得しなければならない。アーキテクトや開発者は、プログラムを通じて弾力性を組み込むために、例えば以下を理解する必要がある。

  • ソリューションごとに固有の適切なスケーリングのしきい値
  • 既定のしきい値に対してアプリケーションの利用状況を評価し、仮想リソースの故障を監視するために適用可能なAPI
  • 所定の層(例:Web、アプリケーション・サーバ、キャッシング、データベース)への仮想リソースの追加または削除を通じて、ソリューションのスケールの拡大/縮小を行うために必要となる適用可能なAPI
  • 測定とオーケストレーションのフロー制御を、クラウド最適化アプリケーションのアーキテクチャやコード・ベースの範囲内でどこに、どのように実装するか。

ITリーダーへの影響は明白である。クラウド最適化ソリューションが高度化するにつれて、IaaSオファリングに関する開発者のスキルも、ソリューションの他の要素(例:プログラミング言語、アプリケーション・サーバのランタイム、データベース) も拡充しなければならない。開発チームは、近代化に向けて古いコード資産を持ち込みながら、一方で多くのテクノロジ・スキルを習得しなければならない。こうしたことは多くのIT部門に深刻な課題をもたらす。

推奨事項:開発者は、アプリケーションにおいて適度な後方互換性と中核的なクラウド特性へのある程度のサポートが必要な場合、クラウド最適化アプリケーション・アーキテクチャとIaaS+プロバイダーの組み合わせを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキルやベスト・プラクティスにやや依存する。開発者は、クラウドの目標、特性、アーキテクチャ原理、パターン、責務の多くについて責任を負う。ほとんどの主流のIT部門にとっては、クラウドのアーキテクチャ原理と設計パターンをアプリケーション・コードで直接サポートするために必要な、高度な技術スキルと十分な帯域幅が、この戦略の基本的な制約となる。


適度な後方互換性とある程度のクラウド特性が必要な場合は、クラウド最適化アプリケーションとクラウド・ベースaPaaSプロバイダーを検討する


長所:クラウド・プラットフォームの適度な独立性と相応のロックイン
短所:いくつかの高度なPaaS機能を複製するための相応のコーディング作業

一部のクラウド・ソリューションは、クラウド・ホスティング・アーキテクチャで実現できる以上に堅牢で、中核的なクラウド特性のサポートを必要とする。その場合、開発者は、こうしたアプリケーションがクラウド最適化モデルを通じて中核的なクラウド・アーキテクチャ原理の利点を生かせるように、アプリケーションのリファクタリングまたは再設計を検討する必要がある。開発者は、IaaS+よりもクラウド・ベースのPaaSプロバイダーの方が、インフラストラクチャ・サービスの一環としてこうした作業への堅牢なサポートを直接備えていることを認識するようになる。必要なリファクタリングの程度は、対象ソリューションのアーキテクチャに応じて中程度であるか、または多大である可能性がある。

IaaS+を基盤とするクラウド最適化ソリューションは、極めて単純である。最初の手順としてクラウド・ホスティングを採用した上で、IaaS APIと従来のソリューション・コンポーネントを併用しながら、段階的に改良していく。クラウド最適化ソリューションを導入するためにアプリケーションPaaS(aPaaS)を採用する場合、最初の手順を省き、当初のアプリケーションを再展開できるようにする前に、 詳細な修正を施さなければならない。こうした修正のために、ITリーダーは契約中のaPaaSプロバイダーが採用しているフレームワークやアーキテクチャを理解し、aPaaSプロバイダーと協力する必要がある。

例えば、Google App EngineのObjectデータ・ストアを代わりに使用する場合、アプリケーション内の、リレーショナル・データ・ストレージとアクセスを管理する部分を書き換える。初回の再展開の後は、開発者側に追加の作業はなく、当該アプリケーションはクラウド・ベースaPaaS環境の一定のメリットを獲得する。例えば、典型的なクラウド・ベースaPaaSの環境において、開発者はOS、アプリケーション・サーバ、他のミドルウェア・コンポーネントを保守する責任を負わない。こうしたサービスは、一定の耐障害性に加えて、サービス・プロバイダーによる価値提案の一部である。

ある程度の労力で従来のミドルウェアからクラウド・ベースaPaaSへと移行できるアプリケーションもあるが、多くのアプリケーションは、膨大なリファクタリングを伴わずには不可能である。そうした多くのアプリケーションでは、完全な再開発によって(IaaSまたはaPaaSを基盤とする)本格的なクラウド・ネイティブ・ソリューションを構築することを企業が望まないならば、IaaSベースのアプローチの方が適している。以下のいずれかの項目に該当するならば、そのアプリケーションは、クラウド最適化ソリューションとしてaPaaSに再展開する理想的な候補ではないと考えられる。

  • アプリケーションが、OSまたはハイパーバイザのリソースを直接使用する。
  • アプリケーションが、互換性のあるクラウド・サービス実装が存在しないコンポーネント (ミドルウェア、サービス、プログラミング・ライブラリなど) に依存している。
  • Webユーザー・インタフェースがない、主としてバッチ・オペレーション向けのアプリケーション、またはネイティブなクライアント・アプリケーションである。
  • アプリケーションにカスタムの通信プロトコルが多用されている。

推奨事項:開発者は、アプリケーションに適度な後方互換性とある程度のクラウド特性が必要な場合、クラウド最適化アプリケーション・アーキテクチャとクラウド・ベースPaaSプロバイダーの組み合わせを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキルやベスト・プラクティスにやや依存する。このアプローチの場合、開発者はクラウドの目標、特性、アーキテクチャ原理、パターン、責務の多くの面について責任を負う。


強力なクラウド特性とできる限り柔軟な導入を必要とする場合、IaaS+を基盤とするクラウド・ネイティブなアプリケーションを検討する


長所:クラウド・プラットフォームの強力な独立性と最小限のロックイン
短所:PaaSテクノロジの機能を複製するために、ほとんどの主流のIT部門にとって、対応範囲をはるかに超える膨大なコーディング作業 (または追加のシステム・サービス) が必要

開発者は、アプリケーションの導入において、微調整された、柔軟で堅牢なクラウド特性へのサポートを必要とする場合、クラウド・ネイティブなアプリケーション・アーキテクチャを重視すべきである。こうしたアプリケーションを導入する際の最初の選択肢はIaaS+である。ただし、IaaS+を基盤として使用する場合、ソリューション開発者は、仮想化されていない「ベアメタル」なコンピューティング、ストレージ、ネットワーク・リソース以外のすべてについて責任を持つことになる。IaaS+内でクラウド・ネイティブなソリューションを構築する開発者は、コンポーネントの選択を完全にコントロールすることができ、Javaまたは.NETベースのアプリケーションやWebサーバ、商用またはオープンソースのデータベース、プログラミング言語といった、仮想化ソフトウェアと互換性のある多様なアプリケーション・インフラストラクチャの中から自由に選択することができる。

IaaS上でクラウド・ネイティブなソリューションを構築する開発者は、自社のソリューションのあらゆる属性を直接操作できるため、ユーザー・エクスペリエンス、信頼性、相互運用性、移植性、パフォーマンスを詳細なレベルでコントロールできる。開発者やアーキテクトは、ソリューションの提供に使用されるクラウド・サービスの潜在能力を最大化するために、多くのWebアプリケーションに使用され古くなったモデル/ビュー/コントローラ・パターン向けアクタ・モデルのようなフレームワークの代わりに、イベント駆動型や並列型のプログラミングを広く活用する必要がある。また開発者はほかのさまざまな属性、例えばマルチテナント性/従量課金制、モニタリング/スケーリング、ステートレス/非共有型アーキテクチャ、合意プロトコルなどについても考慮すべきである。高度な能力を備えたクラウド対応アプリケーション・プラットフォーム(CEAP)は、こうした問題の多くに対処できるが、自身の専門知識がクラウド以前のアプリケーション・サーバに依存している開発者にとって、これらの問題はチャレンジングなものとなる。

IaaSの柔軟性と信頼性には良い面も悪い面もあり、それは、多くのAmazon EC2顧客が2011年4月と8月に、Amazon Web Services(AWS)データセンターの大規模なサービス中断によって不適切なクラウド・ソリューション設計が露呈した際に目の当たりにしたとおりである。このとき、高いスキルを持つプログラマーによって作られ、クラウド向けに最適化されていると考えられていた何十もの有名なWebサイトやアプリケーションが障害を起こした。TwilioやNetflixといった一握りの高名なクラウド・サービスのみが、クラウド最適化ソリューション設計の主要な原理に対する優れた考慮がなされていたことから、比較的無傷で混乱を切り抜けた。障害は不可避という認識がクラウド最適化ソリューションの開発における主要な留意点であり、すなわち「障害に備えた設計」がベスト・プラクティスになる。アーキテクチャ・パターンやプラクティスの継続的な進歩にもかかわらず、自社のクラウド・ネイティブ・ソリューションに最大限の制御と移植性を求める企業にとって、まずIaaS+に代わる選択肢はない。

推奨事項:開発者は、広範なクラウド特性とある程度の後方互換性がアプリケーションに必要な場合、クラウド・ネイティブなアプリケーション・アーキテクチャとIaaS+プロバイダーの組み合わせを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキル、ベスト・プラクティスに大いに依存しなければならない。開発者は、クラウドの目標、特性、アーキテクチャ原理、パターン、責務のほぼすべてについて責任を負う。ほとんどの主流のIT部門にとっては、クラウドのアーキテクチャ原理と設計パターンをアプリケーション・コードで直接サポートする負担を負うために求められる高度な技術スキルと十分な帯域幅が、この戦略の基本的な制約となる。ほとんどの場合、これらの要件 は、通常の主流のクラウド開発者が対応できる範囲をはるかに超えているとガートナーは考える。


後方互換性は不要であるが、強力なクラウド特性が必要な場合は、クラウド・ベースaPaaSを基盤とするクラウド・ネイティブなアプリケーションを検討する


長所:クラウド・プラットフォームの強力な独立性と相応のロックイン
短所:PaaSテクノロジの機能を複製する相応のコーディング作業(または追加のシステム・サービス)。多くのタイプAの(先進的な)テクノロジ採用ユーザーにとっては妥当であるが、主流のユーザーにとってはそうではない。

クラウド・ベースPaaSの導入のスイート・スポットは、クラウド最適化アプリケーション・アーキテクチャと組み合わせた場合に見いだせる。一方で、開発者はクラウド・ネイティブなアーキテクチャをサポートするために、クラウド・ベースPaaSの導入を拡張することも可能である。クラウド・ベースのPaaSプロバイダーは通常、クラウド特性を全面的にサポートするために必要な、全部ではないが一部のアーキテクチャ原理に対応している。開発者は、クラウド・ベースPaaS内のシステム・インフラストラクチャ・サービスを、アプリケーション・コード内で直接補完することができ、これらのクラウド最適化コード基盤を拡張し、開発することが可能である。

推奨事項:アプリケーションの後方互換性は不要であるが、強力なクラウド特性が必要な場合、開発者は、クラウド・ネイティブなアプリケーション・アーキテクチャとクラウド・ベースのPaaSプロバイダーの組み合わせを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキルやベスト・プラクティスに大いに依存する。開発者は、クラウドの目標、特性、アーキテクチャ原理、パターン、責務の多く (ただし全部ではない) について責任を負う。


後方互換性は不要であるが、最大限のクラウド特性が必要な場合は、クラウド・ネイティブなアーキテクチャとaPaaSプロバイダーを検討する


長所:基礎となるaPaaS基盤からもたらされる、強力な「クラウド性」を備えた既製のアプリケーション・サポート
短所:重度のロックインと低い後方互換性 (スキルとコード)

クラウド・ネイティブなPaaSは、ゼロから構築されるクラウド・ネイティブなソリューションにとっては注目せずにいられない選択肢であり、特に最大限のコントロールが不要な場合にはなおさらである。クラウド・ネイティブなPaaS市場は広範で細分化されているが、以下の2つの基本的な様式がある。

  • 時には正式なIT経験のない「市民開発者」によって実装されている、主流でしばしば機会追求指向の迅速なADを対象とする高生産性オファリング
  • 高度で、体系的な要件をサポートするように設計された高制御性プラットフォーム

まず、aPaaSプロバイダーから入手できる既存の機能セットを使用してソリューションの構築を開始する。その後、自社のニーズに合わせて当該ソリューションに微調整を加えられるため、ソリューションのすべてをゼロから構築しなくてもよい。必要であれば、ソリューション全体をゼロから構築することもできる。

この手法の主な実装時の特徴は、ドラッグ・アンド・ドロップ方式のWYSIWYG (What You See Is What You Get) 開発ツールであり、Microsoft ExcelやAccessの利用に慣れ親しんだすべての事業部門ユーザーが同ツールを利用することができる。これらのツールでは、プロバイダーのデータ・ストア内の顧客メタデータという形ですべてのビジネス・ロジックを保存する。プロバイダーのaPaaSと連携するように設計されたサードパーティ製コンポーネントの購入や共有が行えるマーケットプレースやコラボレーション領域を提供しているプラットフォームもある。機会追求的なアプリケーションにとって、本アプローチの生産性に関するメリットは明白であるが、エンドユーザーが、正式な市民開発者戦略のないまま無制御かつ無統制の開発に携わるというリスクをもたらす。

より体系的なADプロジェクト向けとして、より下位レベルの開発言語やツールセットを提供する高度なプログラマー向けのaPaaSオファリングがある。ただし、Javaのような一般的なプログラミング言語をサポートするaPaaSベンダーでさえ、独自の基盤コンポーネントに適応させるために、独自のライブラリや恣意的なシンタックス制限を設けていることが多いため、新しいスキルセットは必要になる。しかし、オブジェクト指向プログラミングやデータベース設計に精通するプログラマーであれば、これらのツールは比較的習得しやすい。

新しいプラットフォームに必要なスキルの再教育を行いたくない、または開発環境や実行環境をベンダー1社のみに委ねたくないという理由から、aPaaSは不適切であるという使用シナリオを選択する場合もある。4GLと並んで、aPaaSオファリングは一般的にベンダー独自のモデルであり、他のaPaaSの選択肢にアプリケーションを移植することは、可能であったとしても困難である。また、aPaaSのマルチテナントな本質にかかわるセキュリティや信頼性への懸念も、一部の用途に対する訴求力を削ぐ可能性がある。

推奨事項:アプリケーションに後方互換性は不要であるが、幅広いクラウド特性が必要な場合、開発者は、クラウド・ネイティブなアプリケーション・アーキテクチャとクラウド・ネイティブなPaaSプロバイダーの組み合わせを検討する。この組み合わせは、新しいツールをはじめ、開発者のスキルやベスト・プラクティスに大いに依存する。開発者は、クラウドの目標、特性、アーキテクチャ原理、パターン、責務についてほとんど責任を負わない。



推奨リサーチ

  • 「Defining Cloud Computing」
  • 「Cloud Characteristics, Principles and Design Patterns」
  • 「Platform as a Service: Definition, Taxonomy and Vendor Landscape, 2012」
  • 「PaaSのロードマップ:新大陸の出現」(APP-11-41、2011年4月25日付)
  • 「Gartner Reference Model for PaaS

備考1

クラウド利用者とプロバイダー

「プロバイダー」という用語は、IaaS+ミドルウェア、PaaS、SaaSのいずれかのプロバイダーを意味する。「利用者」は、IaaS上またはいずれかのタイプのPaaS上で稼働するアプリケーション(またはサービス)自体、あるいは当該アプリケーション(またはサービス)を実装する開発者(人)を指し、当該アプリケーションやSaaSソリューションを使用するエンドユーザーのことではない。



(監訳:片山 治利)


APP: APP-14-106 (G00247030)
※本レポートの無断転載を禁じます。


←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright