SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Security Online Day 2025 春の陣(開催予定)

2025年3月18日(火)オンライン開催

Enterprise IT Women's Forum

2025年1月31日(金)17:00~20:30 ホテル雅叙園東京にて開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

EnterpriseZine(エンタープライズジン)

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

翔泳社の本

【前編】:クラウド環境の全体像とネットワークリソース

抄録:『絵で見てわかるクラウドインフラとAPIの仕組み』


 前回は、書籍『絵で見てわかるクラウドインフラとAPIの仕組み』(翔泳社 平山 毅、中島 倫明、中井 悦司、矢口 悟志、森山 京平、元木 顕弘 著)から、第1章を抜粋して紹介しました。今回からは、第2章(中井 悦司 著)となります。本章では、IaaS タイプのクラウドサービスが提供するコンポーネント群について、代表的なコンポーネントの機能を紹介しながら、その全体像を把握します。また、シンプルな Web アプリケーションシステムをクラウド上に構築する想定で、代表的なコンポーネントの組み合わせ方法を学びます。今回は、その中からクラウド環境の全体像とネットワークリソースにあたる部分を抜粋して掲載しています。

2.1 クラウド環境の全体像

 クラウドサービスを構成する大きな枠組みとして、「テナント」「リージョン」「アベイラビリティゾーン」があります。まずは、これらの概念を理解しておきましょう。クラウドサービスにもいくつかの種類があるので、本書では、Amazon Web Services(AWS)、および、OpenStack で構築したクラウド環境を前提とします。

2.1.1 テナント

 第 1 章の図 1.6(P.7)に示したように、クラウドサービスの利用者には、それぞれに個別のテナント環境が用意されます。たとえば、AWS の場合は、AWS Account がテナントに該当します。1 つのテナント環境を複数のユーザーで共同利用することもできるので、どのような単位でテナントを用意するかは、事前に検討が必要となります。この際、図 2.1 に示した点がポイントとなります。

図2.1 テナント設計の考慮ポイント
図2.1 テナント設計の考慮ポイント

 たとえば、できるだけ細かくテナントを分けるのであれば、1 つのアプリケーションシステムに対して、1 つのテナントを用意します。1 つのプロジェクトチームが複数のアプリケーションシステムを構築/管理する場合、チームメンバーはアプリケーションごとに別れた複数のテナントに属することになります。ただし、これは少し極端な例で、典型的には、プロジェクトチームごとにテナントを用意して、そのチームが構築/管理するアプリケーションシステムを同じテナントにまとめます。この場合でも、仮想ネットワークを利用して、アプリケーションシステムごとにネットワークセグメントを分割することは可能です(図 2.2)。

図2.2 テナント分割の例
図2.2 テナント分割の例

2.1.2 リージョン

 AWS では、地理的に大きく離れた複数の箇所にクラウドインフラを用意しており、それぞれのクラウドインフラは「リージョン」と呼ばれます。「東京リージョン」「シドニーリージョン」など、クラウドインフラが存在する国や地域が特定できるようになっています。

 日本国内のユーザーが利用するアプリケーションは、東京リージョンに構築したシステムから提供するなどの使い方ができます。それぞれのリージョンの環境は独立しているので、複数リージョンにまたがる仮想ネットワークを構成するようなことはできません。リージョンごとに別々の仮想ネットワークを用意する必要があります。

 一方、ユーザーアカウントやテナントの情報はリージョンごとに別れているわけではありません。それぞれのテナントから複数のリージョンを利用することが可能です(図 2.3)。たとえば、「東京リージョン」と「シドニーリージョン」に同一のアプリケーション環境を構築しておき、DR(Disaster Recovery)環境として利用することができます。

 普段は、東京リージョンのアプリケーション環境を利用しておき、大規模災害などで東京リージョンが使用できなくなった際は、シドニーリージョンのアプリケーション環境に利用先を切り替えるといった使い方になります。ただし、リージョンによって、使用できるグローバル IP アドレスの範囲が異なるので、接続先のリージョンを切り替えるには、アプリケーションのユーザーが明示的に接続先を変更するか、DNS の登録を変更する必要があります。

図2.3 テナントとリージョンの関係
図2.3 テナントとリージョンの関係

 また、このような場合、東京リージョンのアプリケーションが使用するデータをシドニーリージョンに複製しておく必要があります。これについては、オブジェクトストレージを利用する方法があります。「それぞれのリージョンのクラウドインフラは独立している」と説明しましたが、この後で説明するように、オブジェクトストレージの機能はすべてのリージョンから共通に利用できるようになっています。

 OpenStack においても、AWS と同様にリージョンの機能が利用できます。OpenStackでプライベートクラウドを構築する場合は、どのような単位でリージョンを用意するかは、クラウド環境の設計次第です。AWS のように複数の国にクラウドインフラを用意して、それぞれを個別のリージョンとすることもできますし、国内の複数のデータセンターのクラウドインフラを別々のリージョンとして管理することも可能です。

 2.1.3 アベイラビリティゾーン

 AWS では、前述のように、リージョンごとに独立したクラウドインフラが用意されており、使用するリージョンによって仮想マシンインスタンスを起動する地域が決まります[※1]。さらに、1 つのリージョンを構成するクラウドインフラは、該当地域における複数のデータセンターに分散配置されています。「東京リージョン」のクラウドインフラであれば、東京近辺の複数のデータセンターから構成されており、それぞれのデータセンターは「アベイラビリティゾーン」として識別されます(図 2.4)。

※1 IaaS タイプのクラウドで提供される仮想マシンは、一般に、「仮想マシンインスタンス」と呼ばれます。

図2.4 リージョンとアベイラビリティゾーンの関係
図2.4 リージョンとアベイラビリティゾーンの関係

 AWS の仮想ネットワークにおいて、仮想スイッチに相当するコンポーネントであるサブネットは、アベイラビリティゾーンごとに用意されます。また、仮想マシンインスタンスを起動する場合、あるいは、仮想ストレージのボリュームを作成する際は、使用するアベイラビリティゾーンを指定する必要があります。

 そして、異なるアベイラビリティゾーンに存在する仮想マシンインスタンスと仮想ストレージを接続することはできないので、この点にも注意が必要です。既存のボリュームを異なるアベイラビリティゾーンに持っていく際は、仮想ストレージのクローニング(複製)機能を用いて、他のアベイラビリティゾーンに複製して利用します(図2.5)。

図2.5 アベイラビリティゾーンとストレージ接続の関係
図2.5 アベイラビリティゾーンとストレージ接続の関係

 OpenStack においても、アベイラビリティゾーンを利用することができます。OpenStack の場合、仮想ネットワークについては、複数のアベイラビリティゾーンにまたがる形で利用できます。

 つまり、ネットワーク接続についてアベイラビリティゾーンの違いを意識する必要はありません。同一の仮想スイッチに接続した仮想マシンインスタンスは、異なるアベイラビリティゾーンで起動していたとしても、論理的には、同一のネットワークスイッチで直結されたかのように動作します。

 OpenStack でプライベートクラウドを構築する場合、どのような単位でアベイラビリティゾーンを構成するかは、いくつかの選択肢があります。AWS と同様に近郊のデータセンターの単位でアベイラビリティゾーンを分けることも可能ですが、この場合は、データセンター間のネットワーク帯域に注意が必要です。

 前述のように、仮想ネットワークは複数のアベイラビリティゾーンにまたがって構成されるため、データセンター間のネットワーク帯域が不足すると、「論理的には同一のスイッチに接続しているにもかかわらず、仮想マシンインスタンス間の通信速度が遅い」などの不都合が生じる可能性があります。

 あるいは、同一のデータセンター内で、異なるフロアーや異なるラックのように、もう少し小さな単位でアベイラビリティゾーンを分けることも可能です。たとえば、異なるフロアーでアベイラビリティゾーンを分けたとします。複数の Web サーバーを起動する際に、複数のアベイラビリティゾーンで Web サーバー用の仮想マシンインスタンスを起動すれば、電源障害などで特定フロアーのサーバーが全滅しても、Web サーバーが全面停止することはありません(図 2.6)。

図2.6 アベイラビリティゾーンを利用した冗長化
図2.6 アベイラビリティゾーンを利用した冗長化

 仮想ストレージについても同様の考え方が適用されます。仮想ストレージの実体となるデータ領域は、データセンター内に設置された物理的なストレージ装置に確保されるので、ストレージ装置の設置場所に対応してアベイラビリティゾーンが決まります。異なるアベイラビリティゾーンにある仮想マシンインスタンスと仮想ストレージの接続を許可するかどうかは、クラウドインフラの管理者が事前に決めて設定しておきます。

 データセンター単位でアベイラビリティゾーンを分ける場合、異なるアベイラビリティゾーンの仮想マシンインスタンスと仮想ストレージを接続するということは、データセンターをまたいでサーバーとストレージを接続することになります。アクセス速度の面で問題が発生する可能性が高くなるので、このような場合は、異なるアベイラビリティゾーンでの接続は許可しないほうが良いでしょう。

 複数のリージョンから成るクラウド環境では、リージョンごとに独立した仮想ネットワークが構成されます。ここでは、それぞれのリージョンの仮想ネットワークを構成するコンポーネントを説明します。仮想ネットワークについては、AWS と OpenStackで用語の違いなどがあるため、少し注意が必要です。

次のページ
2.2.1 ルーター

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
関連リンク
翔泳社の本連載記事一覧

もっと読む

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/13479 2020/11/27 19:26

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング