Windows Azureエンタープライズアプリケーション開発技法 PaaSサービス・モデル ―― 第3章　クラウドとオンプレミスの考え方の違い　3.8 ―― 日本マイクロソフト株式会社コンサルティングサービス統括本部 赤間 信幸 2012/01/23

本コーナーは、日経BP社発行の書籍『Windows Azureエンタープライズアプリケーション開発技法』の中から、特にInsider.NET読者に有用だと考えられる章や個所をInsider.NET編集部が選び、同社の許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『Windows Azureエンタープライズアプリケーション開発技法』の詳細は「目次情報ページ」や日経BP社のサイトをご覧ください。

ご注意：本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

■3.8　PaaS サービスモデル

　IaaSとPaaSの違いについて、要点を簡単に述べると、IaaSは、ブロックを組み立てるように、様々な部品を組み合わせてシステムを構成することができるが、PaaSはシステムモデル（主にインフラモデル）自体が標準化されており、そのモデルに従ってシステムを構成することになる、というのが大きな違いである（図 3-42）。

図 3-42　PaaSとIaaSの違い

　PaaS型サービスが定義しているシステムモデルのことを、ここでは「サービスモデル」と呼ぶことにする。このようなサービスモデルは、特にオンプレミス環境でのシステム開発に慣れた開発者からすると、非常にやりづらさを感じるものになると思う。これについて解説する。

●3.8.1　サービスモデルのメリットとデメリット

　具体的に話を進めるため、Windows Azureコンピュートサービスのサービスモデルを例にとって説明する。図 3-43は、現在のWindows Azureコンピュートサービスのサービスモデルを分かりやすく示したものである。

図 3-43　Windows Azureのサービスモデルが課す制約

　Windows Azureコンピュートサービスでは、サーバーを自由に組み合わせてシステムを組み立て上げることは許されていない。例えば、以下のような制約が課される*1。

• 利用可能なサーバーは、Webロール、Workerロール、VMロールの3種類のみ。これらを組み合わせて、1つのシステムを組み上げる。
• 外部との通信は、ロードバランサーにより負荷分散される。このロードバランサーでは、セッションアフィニティ機能*2は使えない。
• 外部との通信は、TCP/IP通信とHTTP（またはHTTPS）通信に限定される。UDP通信は使えない。
• 1つのシステムは、1つのパブリックIPアドレスでしか公開できない。また、パブリックIPアドレスは固定されておらず、システムを再配置した場合には変更される。
• 各ロール間の通信は、サービス定義ファイルに定義されたものしか認められない。

*1　なおこの制約については、SDKのバージョンによって異なるため、正確なところは最新のSDKについて調査することを推奨する。

*2　同一のクライアントからのリクエストを、同一のサーバーにルーティングし続ける機能のこと。

　さて、これらの制約をどのように思われたであろうか？　例えば、「UDP通信が認められていない」という制約について考えてみると、この制約は、オンラインゲームのように、高速通信の目的でUDP通信を使っているシステムにとっては致命的なものと言える。あるいは、「固定IPアドレスが使えない」という制約について考えてみると、この制約もまた、システムによっては致命的な場合がある。これらの問題は、IaaS型のサービスではそもそも発生しないことが多いだろう。

　しかし、「すべてのシステムでUDP通信が必要か？」「すべてのシステムで固定IPアドレスが必要か？」という観点で考えてみる。確かにUDP通信や固定IPアドレスが必要なシステムもあるが、一般的な業務アプリケーションを想定した場合、むしろこれらは使うべきではない機能である。リモート通信はHTTP通信やTCP/IP通信を使うべきだし、当該システムを呼び出す際にはIPアドレス直接指定ではなく、nakama.cloudapp.netといったホスト名を使うべきである。すなわち、サービスモデルに従ってアプリケーションを作っていれば、そもそもそうした設計・実装ミスを犯すことがなくなる、ということになる。

　この例からわかるように、「制約が多い」ことは確かに「できることが少ない」ということを意味するが、「設計・実装上のリスクが少なくて済む」「早く・安く・上手く作れる」ということでもある。自由度の高さは、裏を返せば、設計・実装品質リスクの高さでもある。スキルの高い熟練開発者にとってはこうした制約は時として邪魔に感じられるかもしれないが、スキルの高くない開発者にとってはむしろこうした制約は有難いものなのである。

　また、スキルの高い熟練開発者にとっても、このような制約はマイナスばかりではない。このサービスモデルに併せて設計・実装されたアプリケーションは、「すぐさま」インターネット環境に公開することができる。例えば、「1週間の超短期開発プロジェクト」を担当しなければならなくなった場合を考えてみていただきたい。PaaS型サービスを使えば、そもそもインフラに関する設計や実装、テストの作業はすべてショートカットでき、限られた貴重な時間を有効にアプリケーション開発に充てることができる。これは、開発期間が短くなればなるほど、極めて大きなメリットとなる。

　このような「制約」と「設計・実装リスクや開発速度」などの関係は、サービスモデルに限った話ではなく、開発の様々な場所に見られる話である。例えば、アプリケーションフレームワークなどはその最たるものである（図 3-44）。確かに、アプリケーションフレームワークを使うことによって、「好き勝手にアプリケーションを作ること」はできなくなったが、そのかわりに、「早く・安く・上手く」かつ「より低いリスクで」アプリケーションを作ることができるようになった。今日のアプリケーション開発において、アプリケーションフレームワークを使わない開発は、極めて少なくなっていると言ってよいだろう。

図 3-44　アプリケーションフレームワークを使った開発

　もちろん、こうした「制約」が厳しすぎると、適用できるシステム領域が狭くなってしまう（すなわち、そのPaaS型サービス上に載せることができるアプリケーションの種類が極端に限定されてしまう）。このため、「制約」と「適用領域」のバランスをうまく取ることが重要である。実は、リリース当初のWindows Azureコンピュートサービスは、現在に比べて極端に制約が厳しく*3、適用可能なシステム領域がかなり狭かった。しかしその後、顧客のフィードバックを元にこの制約を徐々に緩めていくことによって、現在の形に落ち着いている。今後も顧客からのフィードバックによって制約がさらに緩められたり機能追加されたりすることもあるだろうが、重要なのは「だからといって制約の全くない世界がよいというわけではない」という点である。適度なシステムモデル制約があることによって、インフラ設計リスクの低減、素早いアプリケーションの公開、容易なアプリケーション管理などが可能になってくるのである。

*3　例えば、Workerロールサーバーはリモートからの直接通信を受け付けることができず、バッチサーバーとしてしか使うことができなかった。また、WebロールサーバーとWorkerロールサーバーは、Windows Azureキューストレージを介した非同期通信しか認められていなかった。

●3.8.2　既存アプリケーションの移行要件がある場合

　このようなPaaSのサービスモデルが問題になりやすいのは、既存アプリケーションをクラウド上に移行する場合である。アプリケーションを新規開発する場合には、サービスモデルに併せた形で設計・実装を行えばよいが、既存アプリケーションの移行の場合はそうはいかない。サービスモデルに適合させるために、コードの修正、場合によっては一部、設計変更をしなければならないような場合もあるだろう。

　問題なのは、このようなケースでは、PaaS上にシステムを移植するよりも、IaaS上にシステムを移植する方が簡単なことがある、という点である。IaaS型サービスにはPaaS型サービスのようなサービスモデル制約がない（あるいは少ない）ことが多く、単一システムの移行に限って言えば、コスト的に移行費用を抑えられる場合もある。しかし、だからといってIaaS上への移行を選択してよいのかとなると、一考が必要である。

　一般に、「標準化」のメリットは、その「標準」に従って作られたものが多ければ多いほど大きくなる。例えば、「アプリケーション開発標準」を作った場合、その標準に従って作られたアプリケーションが1つだけであればメリットはさほどないが、10個、100個と増えてくると、そのメリットは絶大になる。なぜなら、同じ標準に従って作られていれば、アプリケーションの管理や保守を共通化することができるからである。

　これと同じ議論が、IaaS／PaaSの選択においても当てはまる。単一のシステム移行であれば、IaaS上にシステムを移植した方が、直近のコストメリットが大きくなるかもしれない。しかし中長期的に見た場合には、たくさんのアプリケーションが同じプラットフォーム上に載ってくるかもしれない。そのような場合には、AzureのようなPaaS型サービスを使ってインフラを縛っておくことのメリットは非常に大きくなってくる。

●3.8.3　クラウド化ロードマップの必要性

　こうしたメリットは、直近の一件のシステム移行だけを見ていては判断できない。このため、特に多数のシステムを保有している企業であれば、今後を見据えた中長期的なクラウド化ロードマップを検討するべきである。典型的には、現在保有する業務システムや、今後開発する予定の業務システムを洗い出し、これを各種のポートフォリオ分析手法で分類し、今後、クラウド化を通してどのようにシステムを標準化していくのかを考えるのである。

　特に、AzureなどをはじめとしたPaaS型サービスは、大企業における「各部門が勝手に開発してしまった野良アプリのインフラ標準化」などには極めて有効である。システムを多数持つ企業であれば、ぜひこうした点も踏まえて、クラウド化の検討をしていただければと思う。

■

　以上がPaaSサービスモデルに関する解説だ。『Windows Azureエンタープライズアプリケーション開発技法』の転載は、今回で終了である。

「Windows Azureエンタープライズアプリケーション開発技法」

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