検索
連載

仮想化の仕組みがイマイチ分からない――クラウドをより深く理解したい人のための「仮想化」超入門AWSで学ぶクラウド時代のサーバ&ストレージ基礎知識(3)

これまであまり物理的なサーバとストレージに触れてこなかった方を対象に、AWSを用いてサーバとストレージの基礎知識を解説する連載。第3回は、Amazon EC2にとって欠かせない技術である「仮想化」を詳しく解説します。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
AWSで学ぶクラウド時代のサーバ&ストレージ基礎知識

AWSで学ぶクラウド時代のサーバ&ストレージ基礎知識

 本連載「AWSで学ぶクラウド時代のサーバ&ストレージ基礎知識」は、これまで仮想マシン(Virtual Machine:VM)は使っていたけど物理的なサーバに触れてこなかったエンジニアやサーバ管理者、情報システム部門担当者(情シス)などを対象に、サーバとストレージの基礎知識を「Amazon Web Services」(AWS)の操作を例に解説しています。

 本連載は全7回の予定で、各回は下記のテーマで基礎知識を解説して、テーマに関連するAWSのサービスを紹介していきます。

  • 第1回:サーバ
  • 第2回:ブロックストレージ
  • 第3回:仮想化
  • 第4回:サーバ運用に必要な技術
  • 第5回:ファイルストレージ
  • 第6回:オブジェクトストレージ
  • 第7回:ストレージのデータ保護

 連載3回目となる今回は、第1回で解説した「Amazon Elastic Compute Cloud」(以下、Amazon EC2)にとって欠かせない技術である「仮想化」についてあらためて解説します。AWSを触るときには意識しない部分ですが、仮想化を知ることで、AWSのようなクラウドサービスを利用するメリットをより深く理解できるようになるでしょう。

そもそも「仮想化」って何ですか?

 「仮想化」は、ハードウェアリソースを抽象化し、物理的なリソースを複数の仮想的なリソースとして利用可能にする技術です。第1回ではハイパーバイザーの役割として「サーバ仮想化」について解説しましたが、ストレージやネットワークなども仮想化の対象となっています。

サーバ仮想(第1回で解説)

  • ハイパーバイザーが物理リソースの管理と仮想マシンのデプロイなどを行う
  • 物理サーバのCPU、メモリ、ストレージなどを複数の仮想マシンに分割する

ストレージ仮想化

  • 複数の物理ストレージを仮想的に統合して1つの大きなストレージプールを構成し、必要な容量を論理的に分割して、仮想ストレージとして利用できるようにする技術
  • 第2回で解説した「RAID」(Redundant Arrays of Inexpensive Disks)もストレージ仮想化の一つ

ネットワーク仮想化

  • スイッチやルーターなどの物理的なハードウェアリソースを仮想化ソフトウェアで抽象化し、ソフトウェア制御により、ネットワークを構築する技術
  • 仮想的にネットワークを分割する「VLAN」(Virtual Local Area Network)や、ネットワーク構成機器をソフトウェア経由で一括制御する「SDN」(Software-Defined Networking)といった技術によって実現される

 これらの仮想化技術を利用することで、AWSや他のクラウドサービスは展開されています。以降は仮想化技術のメリットを説明していきます。

リソースの最適化

 仮想化は、リソースの効率的な活用(リソースの最適化)を可能にします。例えば、サーバ仮想化環境では、CPU、メモリ、ストレージなどのリソースを動的に仮想マシンに割り当てるのが特徴で、各仮想マシンが必要とするリソースを必要なときに、必要な分だけ消費します。

 オンプレミス環境でリソースを利用する際には、運用者がリソースを管理して最適化する必要があります。しかし、AWSのようなクラウドサービスでは、この部分はクラウドサービスプロパイダー側で最適化されるので、ユーザーはリソースを気にすることなく使いたい分だけ使用できます。

コストの効率化

 リソースの最適化はコストの効率化にもつながります。仮想化により、1台の物理サーバ上で複数の仮想マシンを運用できるため、機能ごとに物理サーバを用意する必要がなくなります。

 これによりハードウェアの購入費用や設置スペースの確保といった初期コストだけでなく、サーバ自体の電力消費、サーバの冷却に必要な空調電力といったランニングコストも削減できます。

 AWSをはじめとしたクラウドサービスでは、データセンターでこうしたコスト効率化が行われることで、ユーザーはクラウドのリソースを安価な金額で利用できます。

運用の柔軟性

 仮想化技術は、運用の柔軟性も大幅に向上させることができます。仮想リソースは物理リソースに依存せず、移動やコピーが簡単にできます。この機能により、システムの展開やメンテナンスが容易になり、ダウンタイムを最小限に抑えられます。

 また、仮想化環境では、スナップショットやレプリケーションといった機能を活用することで、迅速な障害対応や復旧が可能です。例えば、物理サーバの故障時には、仮想マシンを別の物理サーバに移動させることで、サービスの中断を最小限に抑え、ビジネスの継続性を確保できます。

 ここまで、仮想化技術のメリットを解説してきました。以降は、オンプレミス環境とクラウド(AWS)環境における仮想化についてそれぞれ見ていきます。前述した仮想化技術のメリットがそれぞれの環境でどのように生かせるのかと、それを実現するハイパーバイザーについて解説します。

オンプレミス環境における仮想化

オンプレミス環境のハイパーバイザー

 ハイパーバイザーはサーバ仮想化において最も重要になるコンポーネントであり、ハードウェアリソースを抽象化し、それを複数の独立した仮想リソース(仮想マシン)として提供します。ハイパーバイザーとして使用される物理ハードウェアを「ホスト」、その上で動く仮想マシンを「ゲスト」と呼びます。

 ハイパーバイザーを使うことで、ホストのリソース(CPU、メモリ、ストレージなど)を管理し、ゲストに割り当てることが可能になります。これが仮想化です。前述したメリットを享受できるようになるため、多くの企業で仮想化が採用されています。

 また、ハイパーバイザーには「タイプ1」と「タイプ2」の2種類の方式があります。タイプ1のハイパーバイザーは「ベアメタル型ハイパーバイザー」と呼ばれ、直接物理サーバ上にインストールされる方式です。多くの企業で採用されているハイパーバイザーは、このタイプ1になります。タイプ1のハイパーバイザーの例としては、「VMware ESXi」「Microsoft Hyper-V」「KVM(Kernel-based Virtual Machine)」などがあります。

 対して、タイプ2のハイパーバイザーは「ホスト型ハイパーバイザー」と呼ばれ、物理サーバ上のOSにハイパーバイザーをインストールし、アプリケーションとして動く方式になります。タイプ1に比べると、リソースにアクセスする際にホストOSを経由するため、余計なオーバーヘッドが発生しますが、アプリケーションとしてインストールできるため、汎用(はんよう)PCの上で動かす開発環境などとして利用するケースがあります。タイプ2のハイパーバイザーの例としては、「VMware Desktop Hypervisors(VMware Fusion、VMware Workstation)「Oracle VM VirtualBox」などがあります。

オンプレミス環境での仮想マシン運用

 ハイパーバイザー導入後のステップは、仮想マシンの作成と運用です。仮想マシンを作成し、サーバとして展開するまでの流れについては本連載第1回で解説しました。ここでは、仮想マシンのリソース変更や仮想マシン自体の複製といった、運用について重要になる点を紹介します。

リソース変更
 仮想マシンのリソース(CPU、メモリ、ストレージ)は、ハイパーバイザーの管理コンソールから数値を変更するだけで増減が可能です。

 ただし、変更するリソースや増減する内容によっては、仮想マシンを停止する必要がある場合もあります。

 また、リソースの変更に当たって最も考慮すべきなのは、“リソースを増やすとき”です。ハイパーバイザーが利用できるリソースは、物理リソースに依存しています。物理リソースの容量を超えるリソースは使用できないため、必要なリソースが物理リソースを上回る場合は、追加の物理サーバを用意する必要があります。

クローン
 クローン機能を使うと、既存の仮想マシンを基に、同じ設定やデータを持つ新しい仮想マシンを迅速に作成できます。この機能は、テスト環境の作成や同一設定の仮想マシンを必要とする場合によく使われます。

テンプレート
 指定した仮想マシンの設定や構成を「テンプレート」として保存する機能で、保存したテンプレートから仮想マシンを新たにデプロイ(展開)できます。

 この機能によって、既存の設定を仮想マシンに適用した上でのデプロイや、複数の仮想マシンを短時間で効率的にデプロイすることも可能で、運用者の作業ミスや負荷を減らすことにもつながります。また、必要に応じてテンプレート上の構成や設定をカスタマイズして、仮想マシンをデプロイすることも可能です。

スナップショット
 仮想マシンの現在の状態(ストレージ、メモリ、設定など)を保存する方法で、本連載第2回で解説したスナップショットと基本的な用途は同じです。仮想マシンのスナップショットでは、メモリや仮想マシンの構成情報なども1つのスナップショットデータとして包括的に保存します。作成したスナップショットデータを使うことで、仮想マシンを任意の時点の状態に戻すことが可能です。

 システムを変更したり、アップデートしたりする前にスナップショットを作成しておくことで、問題などが発生した際には仮想マシンを元の状態に戻すことができます。

AWS環境における仮想化

AWSのハイパーバイザー

 ハイパーバイザーはAWSでも使用されており、ユーザーが手軽にAmazon EC2インスタンス(以下、EC2インスタンス)を利用できるのは、ハイパーバイザーの管理や運用をAWSが担当してくれるためです(本連載第1回の「責任共有モデル」を参照)。

 AWSで使用されているハイパーバイザーは「Xen」や「Nitro Hypervisor」で、“タイプ1のベアメタル型”になります。Xenは初期のEC2インスタンスで使用されていたハイパーバイザーですが、現在はほとんど使用されていません。

 Nitro HypervisorはAWSが開発したハイパーバイザーで、「Nitro Card」といった専用ハードウェアと組み合わせることで「AWS Nitro System」を構成します。

 従来のXenハイパーバイザーは、管理用の仮想マシンが各仮想マシンのネットワーク、ストレージ、セキュリティを制御していたのに対し、AWS Nitro Systemは、各仮想マシンのネットワーク、ストレージ、セキュリティの制御を専用のハードウェアにオフロードします。これにより、ハイパーバイザーのオーバーヘッドが減少し、サーバのほぼ全てのリソースをEC2インスタンスなどに割り当てることができます。また、Nitro Systemによって、ホストに直接アクセス可能なベアメタルインスタンスというのも提供されています。

 ユーザーがEC2インスタンスを利用するに当たっては、ハイパーバイザーがどのように動いているかを気にする必要はありません。ただし、使用できる機能やインスタンスの種類などに影響することもあるため、最新の情報をキャッチアップしておくことをお勧めします。

Amazon EC2インスタンスの運用

 オンプレミス環境における仮想マシン運用については前述しましたが、AWS環境のEC2インスタンスでも同様の運用が可能です。例えば、リソースの変更やEC2インスタンスの複製などが可能であり、以降では、オンプレミス環境での運用を踏まえて詳細を解説します。

インスタンスタイプ
 EC2インスタンスのリソース(CPU、メモリ、ストレージなど)を変更したい場合は、「インスタンスタイプ」を変更することで対応できます。

 Amazon EC2にはさまざまなインスタンスタイプが提供されており、用途に応じて最適なリソース構成のインスタンスタイプを選択できます。例えば、現在使用中のEC2インスタンスでメモリだけが不足している場合は、使用中のEC2インスタンスよりもメモリだけが大きいインスタンスタイプを選びます。これにより、余分なリソースの消費、つまりコストも最小限に抑えることができます。

 また、オンプレミス環境では、物理リソースの範囲内でしかリソースを利用できないという制限がありますが、AWSではリソース不足による制限がありません。もちろん、AWSもその裏では物理リソースが稼働していますが、世界中のユーザーが共有して利用できるほどの膨大なリソースが用意されています。そのため、リソースが不足してインスタンスタイプを変更できない、という状況になることはほぼありません。

インスタンスタイプの変更手順
 EC2インスタンスが停止していることを確認し、[アクション]→[インスタンスの設定]→[インスタンスタイプの変更]の順でクリックします。

 新しく適用したいインスタンスタイプを選択します。

 変更前と変更後のインスタンスタイプを比較できます。問題がなければ[適用]をクリックしてインスタンスタイプを変更します。

【参考】インスタンスタイプの命名規則

 Amazon EC2のインスタンスタイプには多くの種類がありますが、どのようなリソースのインスタンスタイプかは表記によって分かるようになっています。

 インスタンスタイプ名は、「インスタンスファミリー」「インスタンスタイプの世代」「プロセッサファミリー」「追加機能」「インスタンスサイズ」の順で表記されています。それぞれの詳細に以下のWebサイトを参照してください。


AMI(Amazon Machine Image)
 オンプレミス環境の仮想マシン運用ついてクローンとテンプレートの機能を解説しましたが、AWS環境では「AMI」(Amazon Machine Image)がそれに該当します。AMIを使用するとこでオンプレミス環境と同じように、効率的に仮想マシンをデプロイできます。AMIには、OS、アプリケーション、ボリュームなどの情報が含まれており、同じ設定とソフトウェアがインストールされた仮想マシンをデプロイすることが可能になります。

 AMIには大きく分けて、「クイックスタートAMI」「カスタムAMI」「AWS Marketplace AMI」「コミュニティAMI」の4種類があります。オンプレミス環境でのテンプレート相当として利用できるのがカスタムAMIです。カスタムAMIはユーザー自身が作成できるAMIであり、既存のEC2インスタンスから作成します。そのため、クイックスタートAMIに含まれていないアプリケーションやユーザー設定なども含めることができ、カスタムAMIから新たにEC2インスタンスをデプロイすることで簡単に環境を複製できるというわけです。

 また、Amazon EC2にもテンプレートは存在しますが、これはEC2インスタンスの起動フロー時に入力するパラメーターなどが保存されたもので「起動テンプレート」と呼ばれます。そのため、オンプレミス環境におけるテンプレートとは、利用方法が異なります。

 その他のAMIの活用方法としては、既存の仮想サーバ構成をAMIとしてバックアップすることで、障害発生時に仮想サーバをAMIから復元することです。また、他のAWSリージョンにAMIをコピーしておくことで、ディザスタリカバリー(DR)として活用することも可能です。

AMIの作成およびAMIからEC2インスタンスをデプロイする手順
 EC2インスタンスを選択し、[アクション]→[イメージとテンプレート]→[イメージを作成]の順でクリックします。

 作成するAMIの名前を入力し、[イメージを作成]をクリックします。

 AMIの作成が開始するので「AMI ID」をクリックします。

 AMIの作成が完了すると以下のように表示されます。

 このAMIからEC2インスタンスを作成する場合は、右上の[AMIからインスタンスを起動]を選択します。

 先ほど作成したAMIが構成されていることを確認し、適宜インスタンスタイプなどを設定します。インスタンスの構成が完了したら、[インスタンスを起動]をクリックして、EC2インスタンスを作成します。

その他の仮想化技術(サーバレス&コンテナ)

 ここまで仮想化について、ハイパーバイザーと仮想マシンを中心に解説してきました。最後に、サーバ仮想化に対してよく取り上げられる技術として「サーバレス」と「コンテナ」について簡単に触れておきたいと思います。

サーバレス

 サーバレスは、開発者がサーバの管理やプロビジョニングを意識することなく、コードの実行に集中できるクラウドコンピューティングのモデルです。サーバの設定やメンテナンス、スケーリング、インフラの管理はクラウドプロバイダーが全て担当します。

 例えば、AWSには「AWS Lambda」というサービスが用意されています。AWS Lambdaはイベント駆動型であり、イベント(例:HTTPリクエスト、データベースの変更、ファイルのアップロードなど)によってトリガーされると、コードが実行されます。このイベント駆動モデルにより、リソースは必要なときにだけ消費され、無駄なリソース使用を防ぐことができます。

コンテナ

 コンテナは、アプリケーションとランタイム環境全体をパッケージ化して、“仮想的に動作させる技術”です。コンテナによる仮想化では、ホストOSのカーネルを共有しながら、各コンテナが独自のOSイメージを持つ仕組みとなります。

 ハイパーバイザーのゲストOSのように多数のプロセスが実行されることはないため、従来の仮想マシンと比較してリソースのオーバーヘッドが少なく、起動時間が短いといった特徴があります。

 代表的なコンテナプラットフォームには、「Docker」や「Kubernetes」があります。また、AWS上でもコンテナを扱うことができ、代表的なサービスに「Amazon Elastic Container Service」(Amazon ECS)や「Amazon Elastic Kubernetes Service」(Amazon EKS)があります。

まとめ

 今回は、仮想化についてオンプレミス、Amazon EC2の観点から解説しました。オンプレミス環境の仮想化について知ることで、普段なに気なく使っているAmazon EC2について、より知識を深められたのではないかと思います。

 次回は、「サーバ周辺テクノロジー」として、

  • 安全な接続を実現する認証(キーペア)
  • 大規模環境におけるスケーリングおよび負荷分散
  • エッジ環境における仮想化

の3点を解説します。

筆者紹介

占部 蒼馬

ネットワンシステムズ ビジネス開発本部 応用技術部 クラウドインフラチーム

2021年にネットワンシステムズに新卒として入社。サーバやクラウド製品の評価、検証、そして案件サポートを主な業務として担当。現在は、マルチハイブリッドクラウド環境での管理や最適化を中心に検証業務に従事している。


筆者紹介

小林 浩和

ネットワンシステムズ ビジネス開発本部 応用技術部 クラウドインフラチーム

2011年にネットワンシステムズに新卒として入社。仮想化製品を中心としたクラウドインフラ全般の評価、検証、そして案件サポートを主な業務として担当。近年ではエッジコンピューティングやAI(人工知能)など先進技術に関する調査及び検証業務にも従事している。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る