![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
私たちユーザーが利用するアプリケーション、例えば、Amazonのようなショッピングサイト、TwitterやFacebookなどのSNSなどでは普段はあまり意識しませんがその裏側にはサービスを支える基盤（インフラストラクチャ）やソフトウェア群があります。
まず次の図を見てください。
オンプレミス/IaaS/PaaS/SaaSごとにどこまでがクラウド事業者から提供され、どの部分を利用者が管理すべきかを表しています。
| 管理範囲 | オンプレミス | IaaS | PaaS | SaaS |
| データ | o | o | o | o |
| アプリケーション | o | o | o | x |
| ランタイム | o | o | x | x |
| ミドルウェア | o | o | x | x |
| OS | o | o | x | x |
| 仮想マシン | o | x | x | x |
| 物理サーバ | o | x | x | x |
| ネットワーク | o | x | x | x |
| ストレージ | o | x | x | x |
WindowsServerやLinuxなどOSを動かすための仮想マシン、ネットワーク、ストレージなど
基本的な基盤部分に加えて、ミドルウェア、ランタイム、アプリケーション、データなど
レイヤー構造（層）で表現される点をイメージしておくと読み進めやすいと思います。
IaaSは、イアース/アイアースと読みます。
サーバやストレージ、ネットワークなどの物理的なハードウェア資源や仮想化を提供するサービスです。
例えば、仮想サーバやコンテナなどのコンピューティング機能、ディスクや共有サーバなどのストレージ機能、ルータやファイアウォールなどのネットワーク機能が提供されます。
また、仮想サーバではWindowsまたはLinuxのどちらかのOSを選択することができます。利用者がOSをインストールするのは煩わしいため、OSイメージもクラウド事業者から提供されます。
Azureには次のようなIaaSのサービスがあります。
PaaSは、パースと読みます。
IaaSで提供されるインフラ部分に加えて、アプリケーションを動かすためのプラットフォーム一式を提供するサービスです。
例えば、ブラウザからのHTTPリクエストに応答するIISなどのWebサーバ機能、構造化されたデータを保存するSQLServerなどの
データベース機能、Javaなどのプログラムを動かすソフトウェア機能が提供されます。
これらアプリケーションを動かすために必要でOSの機能にないものを「OSとアプリケーションの中間」という意味でミドルウェアと呼びます。
（補助的なソフトウェアをランタイムと呼ぶこともあります）
プラットフォームと聞くと初めはなんだかよくわからないかもしれませんが、OS、ミドルウェア、ランタイムなど
アプリケーションの土台となっている部分をひっくるめてプラットフォームと呼んでいる、という理解で問題ないと思います。
PaaSのメリットについて考えてみましょう。
例えば、PHPとSQLServer、IISを使ったWebアプリの構築を考えた場合、オンプレミスやIaaSの場合は、OSの各種設定をした後にPHP、
SQLServer、IISをそれぞれ改めてインストールする必要があります。これら開発に必要な環境が予め用意されているので、
開発者は煩わしいインストールや設定作業から解放され、開発に専念できるというメリットあります。
Azureには次のようなPaaSのサービスがあります。
SaaSは、サース/サーズと読みます。
アプリケーションそのものを提供するサービスです。
新たにアプリケーションを開発することなく、契約すれば使いたい機能をすぐに使い始めることができる点がメリットです。
身近なものだと、SaaSには次のようなサービスがあります。
AzureブランドとしてのSaaSの提供はありませんが、特徴についてはAZ-900試験で問われます。
冒頭に示した図解を再掲します。
| 管理範囲 | オンプレミス | IaaS | PaaS | SaaS |
| データ | o | o | o | o |
| アプリケーション | o | o | o | x |
| ランタイム | o | o | x | x |
| ミドルウェア | o | o | x | x |
| OS | o | o | x | x |
| 仮想マシン | o | x | x | x |
| 物理サーバ | o | x | x | x |
| ネットワーク | o | x | x | x |
| ストレージ | o | x | x | x |
従来のオンプレミスの形態では下のレイヤーから上まですべてを利用者が調達・設定・管理する必要がありました。そのうち、いくつかの部分をクラウド事業者が提供・管理してくれるので、この図でいうと右に行くに連れて利用者側の負担が減りメリットが大きくなります。
一方で、IaaSを選択した場合はOSより上のレイヤーを利用者が設定・管理する必要がありますが、OSの設定やインストールするソフトウェアなど利用者が自由にカスタマイズできるというメリットもあります。（左に行くに連れてカスタマイズ性が高い）
つまり、管理負荷軽減とカスタマイズ性はトレードオフの関係にあり、どちらか一方を優先すればもう片方のメリットは享受しにくくなります。
一般的には、オンプレミスにある既存システムをクラウドに移行する場合、既存の構成や設定をそのまま移行しやすいIaaSが選択される傾向にあります。ただ、アプリケーションを動かすサーバをIaaSに移行する場合であっても、バックアップや監視など運用に関するサービスはPaaSに移行しやすいので積極的に検討すべきです。
新規で何かしらの機能を使いたい、システムを構築する場合はSaaS/PaaSを検討します。世の中にすでにあるサービスで要件が満たせるのであればSaaSを利用するのが手っ取り早いですし、アプリケーションを新規開発する場合でもPaaSを組み合わせて利用すれば運用負担は大きく軽減できるでしょう。
AZ-900試験では利用者とクラウド事業者間での責任境界についても問われます。クラウド事業者はAzureの場合はMicrosoftですね。
利用者とクラウド事業者とで誰がどの部分の責任を持つのか定めたものを「共同責任モデル」と呼びます。「責任共有モデル」と呼ぶこともあります。
| 責任範囲 | オンプレミス | IaaS | PaaS | SaaS | オンプレミスをのぞくサービスモデルごとの責任の所在 |
| データ | o | o | o | o | クラウド利用者(顧客)が責任を負う |
| デバイス(PCやスマホ) | o | o | o | o | |
| アカウントとID | o | o | o | o | |
| ID・ディレクトリの基盤 | o | o | z | z | 責任の所在はサービスモデルにより異なる |
| アプリケーション | o | o | z | x | |
| ネットワーク制御 | o | x | z | x | |
| OS | o | x | x | x | |
| 物理サーバ | o | x | x | x | Microsoftが責任を負う |
| 物理ネットワーク | o | x | x | x | |
| データセンター | o | x | x | x |
| o…クラウド利用者 |
| x…Microsoft |
| z…共同責任 |
下3つの物理的なレイヤーはわかりやすいですね。
例えば、故障した物理サーバの交換、データセンターのセキュリティ対策などはMicrosoftの責任のもと行われます。利用者が責任を負うことはありませんが、物理サーバの故障により影響を受けることはあるので冗長化など可用性を担保するための設計観点は重要です。
上3つのレイヤーもイメージしやすいかと思います。
ID/PWやアクセス権、PCやスマホなどのデバイス、データの管理など「それぞれのユーザーがアプリケーションを利用するために必要なもの」はすべて利用者側の責任となります。
ややこしいのは中間層の「共同責任」の部分です。
例えば「アプリケーション」では、プラットフォームの仕組みはMicrosoftが責任を持ちますが、暗号化など設定の部分は利用者側の責任です。
AZ-900の試験では中間層の「共同責任」の部分は問いにくいと思いますので、利用者側の責任となる箇所、クラウド事業者側の責任となる箇所の2点をしっかり理解していれば問題ないと思われます。
今回はサービスモデルの違いと共同責任モデルについて解説しました。サービスモデルの比較をまとめると次の表のような形になります。
| サービスモデル | カスタマイズ性 | 構築・運用の容易性 |
| IaaS | ◎ | △ |
| PaaS | 〇 | 〇 |
| SaaS | △ | ◎ |
試験ではどのサービスがIaaS/PaaSのどれに該当するか問われる場合があります。それぞれのサービスモデルの特徴と合わせてIaaS/PaaSの代表的なサービス名を覚えておきましょう。
