1.2 クラウドが実現するインフラの標準化
先ほど、IaaS タイプのクラウドは、仮想化によって物理環境から切り離されているという説明をしました。この点をもう少し詳しく解説していきます。ここから、仮想化がもたらすクラウドの真のメリットが見えてきます。
1.2.1 クラウドによる構築手順の標準化
これまで、新たなシステムを構築するにあたり、サーバーやストレージなど物理的な機器の準備から始めるのは当たり前のことでした。しかしながら、物理機器の準備には、いくつかの点で大きな手間がかかります。
「そうそう。サーバーの設置や配線作業は面倒で時間がかかるよね」――いいえ、そんな単純な話ではありません。設置／配線などの物理作業はもちろん手間がかかりますが、その他にも面倒な点が隠されています。
たとえば、構築するシステムの規模に応じて、適切な機能／性能の機器を選択する必要がありますが、各ハードウェアメーカーは、競合他社との厳しい競争の中、常に新しい機種を市場に投入していきます。それぞれの機器が提供する機能も変わっていき、時代遅れの古い機種は、やがては販売停止となります。
そのため、各ハードウェアメーカーの製品販売状況や最新機種の機能／性能を調査して、その時点で入手可能な製品の中から、適切なものを選ぶことが求められます（図 1.8）。
また、これまでになかった新しい機能を利用する場合、システム構築作業はその分だけ複雑になります。似たような機能であっても、製品によって設定方法がそれぞれ異なるため、まずは製品マニュアルを読んで、設定手順を確認する必要があります。その製品の専門家を呼んで、打ち合わせを行なうこともあります。これでは、システム構築の事前準備だけで何か月もかかるというのもうなずけます。
IaaS タイプのクラウドでは、このような個別の物理機器の設定方法や機能の違いを意識せずに利用できるという点に大きなメリットがあります。
たとえば、先ほどの図 1.6（前編参照）に示した「仮想ルーター」や「仮想スイッチ」といった、仮想ネットワーク機器について考えてみましょう。これらの背後には、物理的なネットワーク機器があり、ネットワークの仮想化を実現するためのソフトウェアが動作しています。
しかしながら、クラウドの利用者から見えるのはあくまで、クラウドサービスとして標準化されたルーターやスイッチの機能です。一度、そのクラウド上での仮想ネットワーク機器の使い方を覚えてしまえば、同じ方法で何度でもシステム構築が可能になります（図 1.9）。
このように、システム構築のたびにその時点で入手可能な機器やその設定方法を調べ直す必要がなくなります。一度作ったシステムと同じものを何度でも繰り返し構築することができるので、過去の経験を活かしてシステム構築作業を効率化していくことが可能になります。
もちろん、クラウドそのものを作り上げるための物理機器は、時代とともに進化していきます。社内で利用するプライベートクラウドであれば、数年ごとに、その時点での最新機種を用いた新たなクラウドインフラを構築するという手もあります。新しいハードウェアのほうが性能が高く、消費電力も少ないため、同じ台数のサーバーでより多くの仮想マシンを提供できるようになるでしょう。
このような場合でも、クラウドの利用方法が変わることはありません。既存のクラウドインフラで稼働するシステムを新しいクラウドインフラに再構築することも容易ですので、より高性能なクラウドにシステムを載せ替えていくことも可能になります。
「クラウドを活用することで、効率の悪い古い機器をいつまでも使い続けるシステムをなくしていく」――そのような目的でクラウドインフラを積極活用する企業もあります（図 1.10）。
1.2.2 クラウドによるコンポーネントの抽象化
クラウドによってシステムの構築手順が標準化される背景には、システムを構成するコンポーネントが「抽象化」されているという側面があります。
物理機器が提供する機能は、その機器の物理的な構成に縛られますが、クラウド上で提供されるコンポーネントにはそのような制約がありません。あくまでも、利用者にとって必要な機能が、必要な形で提供されるという特徴があります。
たとえば、仮想マシンに出入りするネットワークパケットをフィルタリングするファイアウォール機能について考えます。物理環境では、ファイアウォール装置がその役割を担うので、ファイアウォールに物理的に出入りするパケットに対して、「どのサーバー宛てのどのようなパケットを通過させるのか」という条件を指定する必要があります。
しかしながら、サーバー管理者の視点で考えると、フィルタリングしたいのは、自身が管理するサーバーに出入りするパケットであって、ファイアウォール装置に出入りするパケットではありません。
このためクラウド上で提供されるファイアウォール機能は、ファイアウォール装置がどこにあるのかを気にせずに利用できるようになっています。フィルタリングルールをまとめた「セキュリティグループ」を事前に定義しておき、フィルタリングを適用したい仮想マシンにこれを適用します（図 1.11）。これにより、仮想マシンの前に新たなファイアウォール装置が追加されたかのように、パケットフィルタリングが行なわれるようになります。
物理機器によるシステム設計になじんだエンジニアは、このようなコンポーネントの抽象化に、最初は少しとまどうかもしれません。しかしながら、一度、抽象化された機能を理解してしまえば、すぐにその便利さを実感することでしょう。物理環境に依存した本質的でない設計要素を忘れて、「システムとして実現したいこと」に意識を集中することができます。
これは、ネットワーク以外の機能についても同様です。たとえば、仮想マシンを用意する場合、仮想マシンに割り当てる仮想 CPU の個数やメモリー量などを決める必要があります。
このとき、物理環境のサーバー設計になれているエンジニアは、ついつい物理サーバーと同じ感覚で、CPU コア数やメモリー容量を細かく決めようと考えます。サーバーを発注する際は、メモリー容量などは具体的な数値で指定する必要があるからです。
しかしながら、クラウド上で仮想マシンを用意する場合は、このような細かな指定は行ないません。「t2.small」「m3.large」など、事前に定義された「インスタンスタイプ」を指定すると、それぞれに対応した構成で仮想マシンが用意されます。
これらのインスタンスタイプは、システム管理者によって事前に用意されており、「CPU 性能を重視する」「メモリー容量を重視する」など、仮想マシンの利用目的に応じて使い分けるようになっています（図 1.12）。クラウドの利用者には、細かな数値にこだわるのではなく、あくまでも利用目的を重視するという意識が求められます。
