2.1 クラウド環境の全体像
クラウドサービスを構成する大きな枠組みとして、「テナント」「リージョン」「アベイラビリティゾーン」があります。まずは、これらの概念を理解しておきましょう。クラウドサービスにもいくつかの種類があるので、本書では、Amazon Web Services（AWS）、および、OpenStack で構築したクラウド環境を前提とします。
2.1.1 テナント
第 1 章の図 1.6（P.7）に示したように、クラウドサービスの利用者には、それぞれに個別のテナント環境が用意されます。たとえば、AWS の場合は、AWS Account がテナントに該当します。1 つのテナント環境を複数のユーザーで共同利用することもできるので、どのような単位でテナントを用意するかは、事前に検討が必要となります。この際、図 2.1 に示した点がポイントとなります。
たとえば、できるだけ細かくテナントを分けるのであれば、1 つのアプリケーションシステムに対して、1 つのテナントを用意します。1 つのプロジェクトチームが複数のアプリケーションシステムを構築／管理する場合、チームメンバーはアプリケーションごとに別れた複数のテナントに属することになります。ただし、これは少し極端な例で、典型的には、プロジェクトチームごとにテナントを用意して、そのチームが構築／管理するアプリケーションシステムを同じテナントにまとめます。この場合でも、仮想ネットワークを利用して、アプリケーションシステムごとにネットワークセグメントを分割することは可能です（図 2.2）。
2.1.2 リージョン
AWS では、地理的に大きく離れた複数の箇所にクラウドインフラを用意しており、それぞれのクラウドインフラは「リージョン」と呼ばれます。「東京リージョン」「シドニーリージョン」など、クラウドインフラが存在する国や地域が特定できるようになっています。
日本国内のユーザーが利用するアプリケーションは、東京リージョンに構築したシステムから提供するなどの使い方ができます。それぞれのリージョンの環境は独立しているので、複数リージョンにまたがる仮想ネットワークを構成するようなことはできません。リージョンごとに別々の仮想ネットワークを用意する必要があります。
一方、ユーザーアカウントやテナントの情報はリージョンごとに別れているわけではありません。それぞれのテナントから複数のリージョンを利用することが可能です（図 2.3）。たとえば、「東京リージョン」と「シドニーリージョン」に同一のアプリケーション環境を構築しておき、DR（Disaster Recovery）環境として利用することができます。
普段は、東京リージョンのアプリケーション環境を利用しておき、大規模災害などで東京リージョンが使用できなくなった際は、シドニーリージョンのアプリケーション環境に利用先を切り替えるといった使い方になります。ただし、リージョンによって、使用できるグローバル IP アドレスの範囲が異なるので、接続先のリージョンを切り替えるには、アプリケーションのユーザーが明示的に接続先を変更するか、DNS の登録を変更する必要があります。
また、このような場合、東京リージョンのアプリケーションが使用するデータをシドニーリージョンに複製しておく必要があります。これについては、オブジェクトストレージを利用する方法があります。「それぞれのリージョンのクラウドインフラは独立している」と説明しましたが、この後で説明するように、オブジェクトストレージの機能はすべてのリージョンから共通に利用できるようになっています。
OpenStack においても、AWS と同様にリージョンの機能が利用できます。OpenStackでプライベートクラウドを構築する場合は、どのような単位でリージョンを用意するかは、クラウド環境の設計次第です。AWS のように複数の国にクラウドインフラを用意して、それぞれを個別のリージョンとすることもできますし、国内の複数のデータセンターのクラウドインフラを別々のリージョンとして管理することも可能です。
2.1.3 アベイラビリティゾーン
AWS では、前述のように、リージョンごとに独立したクラウドインフラが用意されており、使用するリージョンによって仮想マシンインスタンスを起動する地域が決まります［※1］。さらに、1 つのリージョンを構成するクラウドインフラは、該当地域における複数のデータセンターに分散配置されています。「東京リージョン」のクラウドインフラであれば、東京近辺の複数のデータセンターから構成されており、それぞれのデータセンターは「アベイラビリティゾーン」として識別されます（図 2.4）。
※1 IaaS タイプのクラウドで提供される仮想マシンは、一般に、「仮想マシンインスタンス」と呼ばれます。
AWS の仮想ネットワークにおいて、仮想スイッチに相当するコンポーネントであるサブネットは、アベイラビリティゾーンごとに用意されます。また、仮想マシンインスタンスを起動する場合、あるいは、仮想ストレージのボリュームを作成する際は、使用するアベイラビリティゾーンを指定する必要があります。
そして、異なるアベイラビリティゾーンに存在する仮想マシンインスタンスと仮想ストレージを接続することはできないので、この点にも注意が必要です。既存のボリュームを異なるアベイラビリティゾーンに持っていく際は、仮想ストレージのクローニング（複製）機能を用いて、他のアベイラビリティゾーンに複製して利用します（図2.5）。
OpenStack においても、アベイラビリティゾーンを利用することができます。OpenStack の場合、仮想ネットワークについては、複数のアベイラビリティゾーンにまたがる形で利用できます。
つまり、ネットワーク接続についてアベイラビリティゾーンの違いを意識する必要はありません。同一の仮想スイッチに接続した仮想マシンインスタンスは、異なるアベイラビリティゾーンで起動していたとしても、論理的には、同一のネットワークスイッチで直結されたかのように動作します。
OpenStack でプライベートクラウドを構築する場合、どのような単位でアベイラビリティゾーンを構成するかは、いくつかの選択肢があります。AWS と同様に近郊のデータセンターの単位でアベイラビリティゾーンを分けることも可能ですが、この場合は、データセンター間のネットワーク帯域に注意が必要です。
前述のように、仮想ネットワークは複数のアベイラビリティゾーンにまたがって構成されるため、データセンター間のネットワーク帯域が不足すると、「論理的には同一のスイッチに接続しているにもかかわらず、仮想マシンインスタンス間の通信速度が遅い」などの不都合が生じる可能性があります。
あるいは、同一のデータセンター内で、異なるフロアーや異なるラックのように、もう少し小さな単位でアベイラビリティゾーンを分けることも可能です。たとえば、異なるフロアーでアベイラビリティゾーンを分けたとします。複数の Web サーバーを起動する際に、複数のアベイラビリティゾーンで Web サーバー用の仮想マシンインスタンスを起動すれば、電源障害などで特定フロアーのサーバーが全滅しても、Web サーバーが全面停止することはありません（図 2.6）。
仮想ストレージについても同様の考え方が適用されます。仮想ストレージの実体となるデータ領域は、データセンター内に設置された物理的なストレージ装置に確保されるので、ストレージ装置の設置場所に対応してアベイラビリティゾーンが決まります。異なるアベイラビリティゾーンにある仮想マシンインスタンスと仮想ストレージの接続を許可するかどうかは、クラウドインフラの管理者が事前に決めて設定しておきます。
データセンター単位でアベイラビリティゾーンを分ける場合、異なるアベイラビリティゾーンの仮想マシンインスタンスと仮想ストレージを接続するということは、データセンターをまたいでサーバーとストレージを接続することになります。アクセス速度の面で問題が発生する可能性が高くなるので、このような場合は、異なるアベイラビリティゾーンでの接続は許可しないほうが良いでしょう。
複数のリージョンから成るクラウド環境では、リージョンごとに独立した仮想ネットワークが構成されます。ここでは、それぞれのリージョンの仮想ネットワークを構成するコンポーネントを説明します。仮想ネットワークについては、AWS と OpenStackで用語の違いなどがあるため、少し注意が必要です。
