こんにちは。ラクスインフラ部門にて従事しているas119119です。
ユーザ名に119という数値を2回使用しておりますが、特段意味はございません。
アルファベット順でaが1番目、sが19番目だったので、便宜的に使用しているだけとなります。
裏を返せば、asasasというユーザ名となるわけです。早速主題から脱線してしまいました。
今回、こちらのブログでは、
「仮想化について主観的に考えてみた」と題して、今後より一層の一般化・汎用化が想定される技術である仮想化について割と自由かつ奔放に考察を交えて取り上げてみます。
今回のブログ構成は以下の通りとなります。
1. 仮想化について
ここでは仮想化という概念について主観的な形で内容をまとめてみます。
新しい技術が次々と登場するICT業界において、比較的新規性があるような印象があるが息の長い技術ともなりつつあるのが仮想化ではないかと考えております。
仮想化とは、一般的にはハードウェアリソースを抽象化する技術であるとされています。具体的には、1台の物理的なサーバ内部のハードウェアリソースを論理的に分割し、複数の仮想サーバを同時に動作させることを可能とするものです。このことから、より規模の大きなサービスやシステムで積極的に活用されている技術の一つとなっています。
論理的という表現がやや抽象度が高い印象があるのですが、仮想化については端的には物理的な資源を別の資源であるように扱えるということで、実体を偽ることのできる技術だと考えることができます。
仮想化技術も複雑化してきており、その種類も
・サーバ仮想化
・ネットワーク仮想化
・デスクトップ仮想化
・ストレージ仮想化
・アプリケーション仮想化
などの複数の分類が可能となっています。
本稿では、最も一般的なサーバ仮想化を主として扱っていきます。
では、仮想化の利点をいくつか挙げてみます。
仮想化の利点①／コストカット
仮想化技術を採用する利点はいくつかありますが、まずはコストのカットを挙げることができます。
物理サーバで構築していた場合でも、仮想化技術によって論理的な分割をすることで仮想マシンを構築することができれば、活用されていないCPUやメモリなどのリソースを最適利用することができ、結果物理サーバ台数の減少につながり、最終的にはコストの削減につながると言えます。
仮想化の利点②／拡張性
次に拡張性があるという点です。
仮想化技術によって分割されたサーバに対し、必要に応じてCPUやメモリ、サーバ自体についても容易に追加や削除が可能となっており、柔軟かつ拡張性の高いシステムの構築を実現することが可能となります。
仮想化の利点③／保守性
待機させていたサーバへ稼働していたOSをオンライン状態で切り替えることによって、システムを継続させたままメンテナンスをすることが可能となります。
仮想マシンの実体はファイル*1となるので、バックアップを作成し、当バックアップファイルから同じ仮想環境の復元が可能となります。
これによって同一機能を必要とする仮想OSを短い時間で大量にデプロイすることが可能となります。これを利用した技術としては、オートスケール機能を挙げることができます。
仮想化の利点④／柔軟性
サーバ構築作業が柔軟に可能となるという点も利点の一つとなります。
構築する際の仮想マシン（ゲスト）のOSについては、必ずしもホストOSと同じにする必要はないということからも柔軟性の高い技術です。
仮想化の利点⑤／運用管理の負荷軽減
運用管理の観点からは、物理サーバを運用する場合と比較し、管理における負担が軽減されます。 例えば、従来の物理サーバで機材メンテナンスを行う場合には、システム停止の為に関係各所に調整、メンテナンス時間も深夜帯になることもあり得ます。 一方、仮想化環境で構築されたシステムのメンテナンスはそこで稼働している仮想OSをオンラインで別の物理機に移行できますので、特に事前の調整も必要なく、いつでもメンテナンスすることが可能となります。
仮想化技術に関して上記5つの利点を抽出してみましたが、システム構築を実現する上で検討する必要があるのは、コストであるのは間違いないと言えます。
仮想化実現のために必要なハードウェアやソフトウェアは有償である場合が多いと言えますが、小規模なシステム構築や安価な物理サーバでシステムを構築する場合には、仮想化を採用したことによって逆にコストが割高になってしまうこともあり得ます。
初期投資を抑えるためにサービスの立ち上げはクラウドを選択する会社も多数出てきています。 クラウドを選択した場合、そのままシステムが肥大化すると逆にオンプレミスのシステムの方が安くなる分岐点が存在します。 その分岐点に達した時にオンプレミスに戻す際は仮想化を選択することでよりリーズナブルにシステムを集約、低コスト化を実現できることも忘れてはならないポイントとなります。
仮想化として事実上の標準となっているVMware社製品や追随する製品であると個人的には考えているNutanix社製品、VMwareの仮想環境ベースでの活用を可能とするZerto製品など、各社製品とのコラボレーションや仮想化技術をベースとした新しいサービスが続々と登場してきており、今後しばらくは仮想化技術の活用がより加速化していくのではないかと予想されます。
こちらについては、項目3のところで取り上げます。
2.ラクスにおける仮想化についての現状
現在ラクスにおいては、旗艦製品と位置付けることができる楽楽精算を筆頭に楽楽販売、楽楽明細、楽楽勤怠といった楽楽シリーズ、メールディーラ等の多様な製品群を擁しております。
これらの製品群において、仮想化がメイン基盤となっている商材もあるようですが、一部の商材においては物理機での構築や運用を主としており、仮想化技術の導入についてはこれからという商材も存在します。
一方、販売増に伴いシステム規模が拡大している商材においては、運用コストの低減、メンテナンスの容易さなどを加味すると仮想化の検討や導入を行う動きはより推進されていくことが予想されます。
3.仮想化関連製品及びツール
仮想化技術において既に業界標準となっていると言えるVMware製品が導入候補として挙げられるかと思いますが、昨今、仮想化関連製品も多様化を極めている状況であると言えます。
ここでは個人的に別のプロジェクトでも扱ったことのある製品をはじめ、仮想化を取り巻く製品群の一部について取り上げ、考察してみたいと考えております。
仮想化プロダクトとして既に一般化しているVMware製品やHyper-Vについては、敢えてこちらで取り上げることは致しません。
現在の個人的な業務範囲内においても、深く扱っている技術や商品であるというわけではありませんが、過去に別のプロジェクトに参画した際に扱った製品もあり、仮想化技術を取り扱う際に重要な商品及び技術ではないかという認識を持っているので、個人的な経験も含めてここで取り上げておきたいと思います。
Nutanix
Nutanixは、米国発祥のクラウドソフト会社として2009年からサービスを開始し、日本市場には2012年より日商エレクトロニクスによって導入が開始されました。
Nutanixという名前は製品名としても使用されており、最先端のハイパーコンバージドインフラストラクチャ（HCI：Hyperconverged-infrastructure）と呼ばれています。
ハイパーコンバージドインフラストラクチャ（HCI）においては、物理的なストレージ筐体を不要とし、複数サーバ上のストレージを仮想的な共有ストレージとして利用できる点が一つの特長となっており、仮想サーバやストレージ、付随するネットワーク等をまとめて管理できることから、シンプルな構成管理を可能としています。
個人的には複数のカタカナ用語を連結されると意味が把握しにくいイメージがあるのですが、仮想化ベースのITソリューション提供会社であり、より多くの機能を一括的な形で提供された仮想化製品となります。
実際、私自身がラクスへ入社する前にNutanixの担当者とお話をする機会があり、そこで質問をしてみたのですが、Nutanix製品の実体は、VMWare製品と同じようなサービスやソリューションを提供しているものといった認識で概ね間違いないとのことでした。
提供されているサービスとして、まず挙げられるのが、Nutanixのハードウェアです。
サーバのようなものですが、ブロックという単位で区切った1ユニットまたは2ユニットサイズの筐体の中にノードを1台から4台まで収納できます。
筐体自体には電源ユニットとファンのみが搭載され、ファームウェアアップデートの手間を省いている点が特徴の一つとなっています。
ここでNutanix的観点から定義されているノードという表現が少々難解なのですが、ブレードサーバに格納する各サーバ単位のことを指すようです。
各ノードには仮想化されたCPUやメモリ、独自機能によってストレージ化されたディスクを保有しており、わずか2ユニットのスペースに仮想化基盤の構築が可能となります。
また、こちらのノードはオンラインでのスケールアウトが可能となっています。
ノード関連の特徴として、RAIDを採用しておらず、ノード単体での管理が可能であるという点があります。
ノード単体が破損した場合でも稼働の継続ができ、ノードはオンラインでの交換が可能であり、さらには交換後に自動データコピーによる復元機能もあるので、高い可用性機能が実装されていると言えます。
次に、ソフトウェアで制御できる範囲が広い点が特徴の一つとなります。
CPUとメモリの仮想化機能、ディスクストレージ化機能、リソース一元機能など多様な機能をNutanixの専用ソフトで管理することができます。
ノードごとに仮想基盤を分散させることで、ノードの自由な拡張やバックアップによる可用性を確保できるなどの柔軟性が高い点は、大きな特徴であると言えます。
このことをSoftware-defined*2と呼ぶそうですが、ここでも個人的にはあまり意味の理解が容易ではないのですが、要するにソフトウェアによってNutanixが管理する多様な機能をコントロールするといったニュアンスであると理解しました。
各機能の管理については、GUI形式のPrismと呼ばれるコントローラによって実現されています。
Prismにおいては、VMware vSphere Clientで確認するような要領でダッシュボードが実装され、CPU使用率、メモリ使用率、ディスク使用率、IOPS、帯域、遅延状況などを見える化し、障害状況も一発で確認可能なようです。同様に仮想マシンの作成、削除、バックアップ等の設定も可能となり、統合管理機能の一元化を図っていると言えます。
上記から、Nutanixに関しては、ハードウェア筐体のみならず仮想化実現ツールを含めてAll in oneで提供されているサービスであるということが大きな特徴となります。
基本はVMwareの仮想化ソフトに似ているが、多様な機能の一元管理が可能となっており、その利便性から今後より一般化していくのではないかと予想しております。
Zerto
Zertoは、2009年に米国はボストンにおいて創業された企業で、現時点ではHP社の傘下に入っています。
主力製品はZerto IT Resilience Platformと呼ばれるもので、主に仮想化基盤向けのDR*3対策ソフトに強みを発揮しています。
個人的にも前職で仮想マシンのシステム移行作業へ従事していた際に使用していたプロダクトでした。
他製品と比較してもユーザーフレンドリーなWebUIが印象的で、移行作業自体も失敗することは稀なケースと言えるほどで、パフォーマンス的にもかなり安定した製品でした。
主観的に言えば、VMware製品ベースでの使用が想定されているようにも見受けられます。
個人的にも間接的に聞いた話では、VMware社側からのZerto製品への評価も高いらしいとのことで、今後一層重要度が増すDR対策製品・サービスとしてデファクトのプロダクトとして主流となっていくのではないかと予想しております。
Zerto製品の最大の強みは、とりわけ仮想化における仮想環境のレプリケーション機能であると言えます。
これは、プライベートクラウド、ハイブリットクラウド、パブリッククラウド上の異なるストレージ間や、異なるハイパーバイザー間でもレプリケーションが可能なことを売りにしていることからも伺い知ることができます。
前職で参画したプロジェクトにて扱った際にもサーバのハードウェア保守期限切れ対策として実施したマイグレーション時に大きな効力を発揮しておりました。
Zerto主要機能の一つであるZerto Virtual Replicationの特徴について取り上げたいと思います。
基本的な機能としては、仮想環境のレプリカ作成となります。
想定状況は多岐に渡るかと思いますが、例えば災害発生時などに仮想環境において稼働するサーバを素早く別のプラットフォームへ移行することで、サービス停止を回避する対策として用いられることが多いようです。
また、昨今、目に付くようになってきたランサムウェア対策としても有効性があるように見受けられます。
ランサムウェアによってサーバへのアクセスが制限された場合、レプリケーション機能を用いて仮想環境を復元することによって、データへのアクセスを可能とする手法も用途の一つとしてあるようです。
いずれにしても、サービス可用性の確保という昨今における最大の課題への対処製品としても有効なプロダクトと言えるのではないかと考えます。
Zerto一般情報によると、レプリケーション時には、VMware vSphere、Hyper-V、IBM Cloud（ベアメタル）、AWS、Microsoft Azure間での利用ができ、異なる仮想環境間においてもプラットフォームに依存しない柔軟なデータの保護が可能となっているそうです。
実際には、VMware vSphere上で使用するケースが多いのではないかと思いますが、多様な仮想環境下において互換性の高いサービスとなっています。
実際にVMの仮想化環境で利用したケースで考えると、ESXiホストにVRA*4、vCenterへの紐づけが必要なZVM*5のインストールが必要という状況でした。
これ以外には特に複雑な設定作業等は発生しなかったと記憶しております。
次に、実際に参画プロジェクトにて実施したプラットフォーム間の移行作業について簡潔に触れてみたいと思います。
私が参画したプロジェクトでは、基本的にVMware環境の仮想マシンを別のESXiへ移行する際にZertoを移行ツールとして用いていたのですが、作業自体は通常2日間のスケジュール感で実施しておりました。
初日は、当時の現場では事前同期を実施する日として位置付けられ、ZertoにおけるVPGの作成日として設定されていました。
VPG（Virtual Protection Group）というのは、リカバリーサイト（移行先）での復旧の単位であるとされています。
例えば、移行時に移行グループを作成して複数の仮想マシンを分類し、まとめて処理できる機能があるようです。
ただ、私が参画したプロジェクトの現場では仮想マシンのグルーピングはせずに、1台単位でVPGを作成して移行を実施しておりました。
その意味で、当時の現場では、VPG作成というのは単に本番移行実施前の事前同期を作成するといったものが一般的な認識となっておりました。
他方で、同日に複数のVPG作成が必要な場合もあり、1アカウントで6パラ（6チーム体制）にて6種類のVPG作成を実施した実績もありました。
しかしながら同時並行による影響のためか、VPG作成自体は問題なく完了しましたが、各VPG作成に当初の想定以上の時間を要したこともあったため、同じアカウントでの多数同時並行でのVPG作成作業は可能な限り避けるのが無難であると言えそうです。
ディスク容量の大きい仮想マシンについては、VPG作成が完了するまでに時間を要することが多く、午前中にVPG作成作業を実施、そのまま放置し翌日に作成が完了したことを確認するなどということもありました。
他方で容量が少ないものに関してはVPG作成も短時間で完了し、そのまま同日に移行作業自体を続行することも可能でしたが、顧客と移行スケジュールを調整済みとなるため、VPG作成日と本番移行日は別日で実施するのが通例となっておりました。
Zerto上での操作はVPG作成や本番移行を含めて基本的には全てGUI形式のインターフェースで非常に操作が容易であった記憶があります。
プロジェクト内において通常は事前に設定値を記載したパラメータシートを仮想環境ごとに作成し、当シートを元に作業を進める形となっておりました。
蛇足ですがこのパラメータシートがかなりの曲者でして、入力項目が多岐に渡る上、移行対象が多数となる場合には、シート自体のデグレや更新漏れ等が発生し、場合によっては移行当日にパラメータ内容を修正（レビュー済みであるにもかかわらず）といったこともありました。
状況によって柔軟に対応することも必要ということを痛感するとともに、Zerto製品の使いやすさによって設定値の間違いに気づけたことについても思い起こしました。
無事にVPGの作成が完了すると、翌日にはいよいよ本番移行を迎えます。
VPG作成自体は仮想マシンを停止させる必要はなく、作成に何時間要したとしてもサービス停止は発生しないのですが、本番移行を実施する際にはサービス停止を伴います。
そのため、サービス停止の許容時間やマストのサービス再開時間を想定した上でスケジュールを立てなくてはなりません。
Zertoを利用した移行時では発生件数自体は僅かであった記憶がありますが、他方、他社製品を利用した移行時に移行先環境で正常に仮想マシンを起動させることができず、結果ステップバックと呼ばれる移行前の状態への切り戻しが必要となる事態も発生しました。
その意味でZertoマイグレーション機能はVMware仮想環境の移行において相性がよく、移行作業時における安定性が高い印象を受けました。
本番移行については、同じくZertoのGUI画面にて、下段の「Actions」から「Move VPGs」を選択します。
前提作業としては仮想マシンの停止が必要となります。
この本番移行作業は前日に作成したVPGの実際の移行を行なうものとなり、前日のVPG作成時点からの本番移行作業における差分同期もセットで実施する形となります。
よって、通常はVPG作成後の翌日に移行を実施すれば同期すべき差分は最小で済み、実際の本番移行にそれほど時間を要しないため、VPG作成時点からMove VPGs実施までの間隔は可能な限り短縮すべきであると言えます。
VPG作成からMove VPGs実施までに何日も空いてしまうとそれだけ多くのデータ差分が発生するので、本番移行作業も時間がかかってしまう結果となるためです。
無事に本番移行作業が完了すると、移行先の環境にて仮想マシンがパワーオンの状態で立ち上がってきます。
その後は新環境に合わせてネットワークアダプタの修正を含む各種設定変更を実施し、旧環境からの移行が完了となります。
Zerto製品は非常にシンプルかつ安定性があり、障害発生が少なく高いパフォーマンス性能を備えたプロダクトとして、またDR対策製品としても、今後普及が加速化していくのではないかと予想しています。
Docker
Dockerは、コンテナ型仮想化の代表的なソフトで2013年に登場しました。
一般的にはコンテナの実行やコンテナイメージの作成や配布を実行するためのプラットフォームであるされています。
コンテナ自体はOS上で実行されているプロセスのことを指し、それゆえOS上で共有されることになるため、OSのバージョン等による差分が発生した場合に動作しない等の影響を受ける場合があります。
コンテナ型とは、サーバ仮想化の一類型のことで、アプリケーションと実行環境をひとまとめにし、OS単位ではなくアプリケーション単位で仮想化を実現する仕組みのことを指します。 仮想マシンやゲストOSが不要となるというメリットがあり、ホストOS上にコンテナ型仮想化ソフトウェアをインストールすることでコンテナ同士を組み合わせて使用することも可能となります。
一般的にデータはコンテナに含めないことで使用されることになるため、アプリケーション用のコンテナを破棄してもデータ自体が喪失することはなく、新しいコンテナを作成することでデータの継続的な使用が可能となります。
Dockerはコンテナ技術のデファクトスタンダードツールであるとされ、設計思想としてユーザーファーストを掲げている通り、一般的には使用しやすいというフィードバックも多いようです。
その理由としては、オンプレミスからクラウドへの移行が容易であったり、高い可用性及び有用性からアプリケーションを開発しやすいプラットフォームである点が挙げられています。
また、Docker Hubと呼ばれるライブラリのようなアプリケーション導入済みのコンテナイメージを集めたサービスも豊富に提供されており、必要なコンテナは容易に入手可能となっています。
Docker Hubについてですが、これはDocker社提供のコンテナレジストリサービスのことであり、ここからコンテナイメージの取得及びソフトウェア実行が可能となっています。
コンテナレジストリというのは、Dockerにて使用するコンテナイメージの保管および配布を担う構成要素のようなものとなります。
上記の通り、コンテナはその実体はプロセスであるがゆえ、プロセスごとにコンテナを分類することが推奨されています。
これは、分類することによって、負荷分散によってパフォーマンス低下の改善や共有プロセスへ同時にアクセスすることによる競合状態の発生回避にも寄与できるためであるとされています。
他方、コンテナが分類されることでシステムによっては増加した複数コンテナの管理が複雑かつ困難となったり、1つのシステムにパッチ適用をする場合などに、コンテナごとに対応が必要になったりするなどの煩雑さが発生するというデメリットもあります。
増加し過ぎたコンテナ管理の問題に対応するために、Swarm modeと呼ばれるクラスタ管理機能も備えています。
Swarm とは日本語で言うところの「群れ」のことであり、Swarm modeで有効・無効を選択し、有効とされたノード群をクラスタとしての集合体として管理することが可能となります。
コンテナの管理については、コンテナの作成や削除による方法がありますが、削除する際には注意が必要となります。
コンテナ自体を削除すると、コンテナ上のデータも消えてしまうためです。
対処方法としては。Dockerに備えられた「ボリューム」と呼ばれる機能を使用することが考えられます。
ボリュームというのは、Dockerが管理するディレクトリのようなものであり、通常のファイルシステムと同様に名前での管理が可能であり、複数コンテナにデータを配布するなどのマウント機能も備えています。
またこのボリューム機能を使用すれば、複数コンテナでのファイルシステム共有も可能となります。
Dockerの機能の一つとして、コンテナを実行するためのテンプレートであるコンテナイメージの中にあるファイルシステムに「差分管理」という仕組みがあります。
これは、マスター的な情報がベースとしてあり、そのマスターとの差分点を記録することによって変更内容を管理する手法であり、これによりファイルの高速なデプロイを実現しています。
Kubernetes
KubernetesはDockerと同様にコンテナ型の仮想化ソフトの一種として、Dockerより1年遅れの2014年に登場しました。
開発したのはGoogle社であるとされています。
なお、Kubernetesというのはギリシャ語で「操縦士」という意味があるそうです。
コンテナオーケストレーションツール*6とも呼ばれている通り、コンテナの指揮が可能ということで、自動化することによってコンテナの管理及び運用を容易化するものとされています。
コンテナの運用管理における必要な作業としては、負荷分散、死活監視、スケーリングの3種類を挙げることができます。
負荷分散
負荷分散については、複数コンテナがある場合に特定のコンテナへのリクエストが集中しないようにする処理のことを指します。これにより処理時間の短縮や単位時間あたりに処理可能なリクエスト数を増加させ、システム性能向上へ寄与します。
死活監視
死活監視については、コンテナが正常に稼働しているかを確認及び監視する機能のことを指します。
死活監視の方法としては、各コンテナへリクエストを送信し、返答の有無を確認する手法があります。返答がある場合には正常稼働していると判断できるため、Ping疎通確認のようなものと同様であると言えます。
スケーリング
スケーリングについては、コンテナへのリクエストの規模に応じてコンテナ数を増減させることを可能とする機能です。
例えば、CPUやメモリ等に閾値を設定し、ある基準を超える場合にはコンテナを追加するといったような設定が可能となります。
Kubernetesがコンテナ管理をする上で、最小となる単位のこと「Pod」と呼びます。
1つのPod内では複数のコンテナ起動が可能となります。この複数のコンテナ起動管理を可能とするのが、Kubernetesの特徴の一つであると言えます。
他方で、同じタイミングでの起動が必要ではないコンテナは別のPodで管理するのが効率的であるとも言えます。
また、各Podをグループ化して管理する単位のことを「レプリカセット」、レプリカセットをグループ化して管理する単位のことを「デプロイメント」と呼びます。
Kubernetesのコンテナへのアクセスを実現するのは、「サービス」という機能です。
サービスは、コンテナへアクセスするためのエンドポイントを提供する役割を担っています。
エンドポイントは仮想のIPアドレスを持っており、当仮想IPアドレスへアクセスすることで、エンドポイントにてコンテナの仮想IPアドレスへの変換が行われ、コンテナへのアクセスが可能となります。
エンドポイントはいわば、各コンテナへのアクセスの仲介を行なっている機能であると言えます。
また、サービスには負荷分散の機能も実装されています。
ラウンドロビン方式で各Podへのパケット転送をサービスが制御することで、負荷を分散し、サービス可用性を高めています。
Pod内に複数のコンテナを保有している場合、コンテナ間の通信はlocalhostにて可能となります。
他方、Pod間通信にはPodに割り当てられた一意の仮想IPアドレスを介して実行されます。
コンテナという手法に関しては、仮想化技術の中でも比較的新しい範疇に分類されるのではないかと思います。
Dockerが誕生してから僅か1年後に管理機能を向上させるようにKubernetesが登場してきたように非常にスピーディなペースで次々と新たなものが開発されてきている分野であるという印象を持っており、今後、更にコンテナの進化版のような技術が登場することになるのではないかと予測しております。
4.今後の仮想化活用にむけて
今後、仮想化環境をメインプラットフォームとする方向性へシフトしていく可能性は十分にあり、むしろかなり高い確率でそうなっていくのではないかと予想しております。
運用面で考えると本質的には物理環境と仮想環境で大きな差分はなく、仮想サーバが1台でもあれば、オンプレミスと近い運用設計が必要となります。
オンプレミスでの運用管理方法をそのまま再利用とまではならないまでも、これまでの運用方法を参考にしながら仮想化環境の運用方法を再設計することも可能となるのではないかと考えます。
コスト的な観点では物理サーバに対して仮想サーバが安価であることは一般的な共通認識であると言えます。
他方で、安価な物理サーバを利用した運用を実施する場合、必ずしも仮想サーバが常に優位な選択肢であるとは限らない場合があるというのも事実です。
仮想化導入時にプロプライエタリな製品等の導入を選択肢とする場合、費用対効果を含め多様な視点から比較したうえで仮想化技術を導入すべきなのかを検討することが重要です。
パフォーマンスの安定性を考慮する場合は仮想化技術の導入を無思慮に推進するよりも、物理サーバでの安定した性能を追求する手法も一つの手段です。仮想化を推進する際、オンプレミスなシステムと性能を比較した場合、性能はオンプレミスよりも劣る場合があることは考慮が必要な点となります。
パンデミックなど、昨今の予想できない事態の発生に備え、リモートワーク等を含めて遠隔で操作するVDI、リモートデスクトップの仮想化といった手法の採用も一般化しています。 その潮流の一環として、仮想化技術の活用も有効な選択肢の一つとなっていくのではないでしょうか。
5.まとめ・総括
いかがでしたでしょうか。
ここまで仮想化について個人の主観的な視点に依拠して奔放闊達な形で考えてみた内容を記述してきました。
仮想化のデファクトスタンダードとされるVMware社製品のみならず、VMware製品と類似する機能を強化してAll in oneとリニアにスケールする性能を提供するNutanix製品、VMwareと合わせて利用されることで効果を発揮すると思われるZerto移行ツールなど、ソフトウェアの形態も多種多様に変化してきていると言えます。
それほど昨今の技術進化のスピードは著しく、ICT業界従事者としては常に動きをウォッチすることが求められていることには変わりなく、この風潮は一層加加速化しうると言うこともできるかと思います。
仮想化技術自体は一定の市民権を獲得しているようにも思われ、とりわけVMware製品が築いた牙城はそう簡単には崩壊しないのではないかとも言えます。
Nutanix製品が仮想化製品としてVMware製品にとって代わることがあれば、個人的には興味深いことであると思っております。
新しい技術や製品は最初に開発した事業体が大きなシェアを占めることになるのは明白であり、どれほど模倣に長けた企業であっても二番煎じの位置から秀でるのは容易なことではないと考えられます。
それを踏まえると、標準化された製品をベースに如何に更なる利便性を高めて、付加価値のあるサービスを提供できる技術、とりわけクラウドとの連携によるハイブリットDC化が次の動向となっていくのではないかと思われます。
仮想化関連技術に関して言えば、前述したZerto製品のように今後は仮想化技術とその他商品とのコラボレーション的な活用方法も、仮想化技術の主流の一つとなっていくのではないかと予想しております。
当ブログを最後まで読んでいただき、ありがとうございました。
◆ 関連する求人情報はこちら！
・インフラエンジニア／マネージャー（東京） | 株式会社ラクス
・インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス
・インフラエンジニア[東京/楽楽明細] | 株式会社ラクス
・インフラエンジニア（大阪） | 株式会社ラクス
・インフラエンジニア[東京/楽楽労務] | 株式会社ラクス
・SREエンジニア[東京/インフラ] | 株式会社ラクス
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
rakus.connpass.com
