Internet Infrastructure Review（IIR）Vol.64
2024年9月

2. フォーカス・リサーチ（1）

仮想化技術の変遷とIIJの取り組み

2.1 はじめに

私たちの生活の中で「クラウド」は既に意識されない、あたりまえの言葉として浸透してきています。今日では世界中の企業で様々なクラウドサービスが提供され、それを支える基盤も日々拡大しています。

その中の1つであるIIJのクラウドサービスの基盤の変遷については、過去の記事で紹介してきました^（注1）が、今回はクラウドコンピューティングという概念を実現し、また様々な進化を遂げてきた仮想化技術を見ていくことにしましょう。

2.2 仮想化技術の歴史

2.2.1 最初の仮想化

「仮想化」とはコンピュータのリソースを抽象化することを指し、ソフトウェアと物理的なハードウェアの間に抽象化したレイヤーを提供して、そのリソースを管理するための様々な技術のことを言います。その歴史を紐解くと1960年代までさかのぼることになります。

「仮想化」という言葉が誕生した背景には、それ以前のコンピュータ開発の事情がありました。1940〜1950年代ごろのコンピュータは機種ごとにアーキテクチャが異なることが通常でしたが、それまでの機種の設計を参考にすることで新規設計のリスクを避けたり、他の開発元のコンピュータで利用されているプログラム・ライブラリを流用するためなどの目的で、それまでの機種と命令セットの「互換性」を持たせたり論理設計を共通にした互換機と呼ばれる機種が登場しました。

1950年代の後半には、前の世代の機種の命令セットをマイクロコードでエミュレーションして上位互換を提供する機種も現れ、1960年代に入ると、コンピュータ・アーキテクチャを標準化して互換性を維持する流れが進みます。この頃の各機種の命令セットをエミュレーションした互換性を「仮想機械」と呼び（実際このように呼ばれるのは更に先にはなりますが）、「仮想化」という言葉が使われるようになりました。

そして、1964年には1つのコンピュータで複数の仮想OSを実行できる、最初の「ハイパーバイザ」が登場しましたが、ご存知のとおり、その後「仮想化」の普及は2000年代まで待つことになります。

この頃の「仮想化」は、大きく高価な1台のコンピュータを複数のユーザで利用できるようにするためのもので、そのユースケースも給与計算のバッチ処理などの何千ものルーティンタスクを高速で利用する事業部門のものが中心でした。

それから数十年の間に、この単一機器を複数ユーザで利用するという課題に対し他のアプローチで解決する動きが生まれました。その1つである「タイムシェアリング」という考え方は、これまで「仮想化」によりハードウェア機能で「仮想機械」ごと論理的に分離していたユーザをオペレーティングシステム（以降OS）内で分離するという解決策を提示しました。これにより、当時の「仮想化」は特定の分野の利用にとどまり、ハードウェアの機能による「仮想化」は、一旦下火になります。なお、この「タイムシェアリング」は、現在私たちがシステムの中で利用しているUNIXやLinuxを生み出すきっかけになりました。

2.2.2 「x86仮想化」による仮想化技術の再燃

1990年代に入り、多くの企業は物理サーバとそれを提供する単一ベンダーのソフトウェアを利用する垂直統合なシステム（メインフレーム）を採用しており、既存のアプリケーションを他のベンダーが提供するハードウェアを利用して動かすことはできませんでした。

一方、1980年代に米IBM社のPCに採用され、x86アーキテクチャを引っ提げて頭角を現してきた米Intel社（以降Intel）は1993年にCPU Pentiumを発表し、また、この頃商用インターネットの普及や米Microsoft社（以降Microsoft）のWindowsの発売などにより、パーソナルユースのコンピュータ市場は急激に拡大していきました。この状況にこれまで自社アーキテクチャでコンピュータを開発していたメーカ各社はIntelのCPUを採用した互換機を次々に開発することになりました。

続いて2001年にIntelはサーバ向けCPU Xeonを発表し、メインフレーム及びUNIXが中心だった企業システムは低価格かつ汎用的なIA（インテルアーキテクチャ）サーバに置き換えが進んでいくことになります。

しかし、IntelのCPUは複数のOSでの利用を想定していないアーキテクチャになっており、これまでの「仮想化」は適用できないものでした。これに対し、ソフトウェアによる「仮想化」を実現したのが、1999年2月8日に発表された米VMware社のVMware Virtual Platformです。

初期の「x86アーキテクチャ向けのソフトウェア仮想化」（以降x86仮想化）は当時のホストOS（WindowsやLinux）上に仮想レイヤーを稼働させる方式で提供していましたが、ホストOSを経由するためオーバーヘッドが大きく、商用サービスに適用できる性能はありませんでした。そのため、汎用ホストOSを必要とせず、仮想レイヤーを提供できる独自のkernelを持つ「ハイパーバイザ」製品が登場することになりました。

この時期のx86仮想化は、後述する「ハードウェア仮想化支援機能」なしに仮想化をする場合、特定の命令の実行を捉えて動的に置き換える動的命令変換技法を必ず使用します。この技法は、本質的に仮想化可能なアーキテクチャでの仮想機械に比較すると性能に対する何らかのオーバーヘッドを抱えていました。

性能問題を解決する対策として、ハードウェアをエミュレーションするのではなく、ゲストOSに変更を加えて利用することができる特殊なAPIを提供する仮想機械を「準仮想化」と呼び、初期のサーバの仮想化に利用されることになります。代表的な製品はオープンソースのXen（2.xまで）などがありました。

それに対し、仮想化レイヤーにてCPUの特権命令を変換し、仮想機械上で動作するゲストOSには特別な修正を行わず、そのまま動作させることが可能な仕組みを「完全仮想化（ネイティブ仮想化）」と呼び、当時、準仮想化に対応していなかったWindowsなどのOSも広く動作させることができました。代表的な製品としてはWindows Virtual Server、VMware Server、VMware ESXなどがありました。

2.2.3 ソフトウェア仮想化の限界とハードウェアによる仮想化 支援機能の登場

前述したとおり、従来の仮想化の問題点はCPUがハードウェアで処理することをソフトウェアで実行するため、仮想化によるオーバーヘッドは無視できないものとなっていたことです。とりわけ、デバイス、OS、アプリケーション間でデータの授受によるI/Oの遅延は満足できるものではありませんでした。それ故に、初期の頃のハイパーバイザを利用した仮想化は、機器が古すぎて限界になったアプリケーションを動作させるために移行したゲストOSや、アプリケーション開発のために検証用に動作させるといった目的で緩やかに利用され、当時の高スペックで高速に動作するメインフレームやUNIXサーバを置き換えるほどの勢いはありませんでした。

2000年代後半になりIAサーバが市場シェアを伸ばす中、性能に伸び悩んでいたIntelがCPUを64bitマルチコアアーキテクチャへ変えるタイミングで米Advanced Micro Devices社も同時期にハードウェア仮想化支援機能を実装し、仮想化が急激に進むことになります。これはソフトウェアで処理していた一部の機能 Virtual Machine Monitor（以降VMM）をCPUで処理し、大幅にオーバーヘッドを削減するものでした。

VMMは、端的に言うとOSがユーザ・アプリケーションに対して果たしている役割をゲストOSに対して提供するものです。OSはデバイスやメモリなどの物理リソースを管理し、メモリ空間をプロセス（ユーザ・アプリケーション）ごとに隔離しています。これと同様にVMMはゲストOSごとに物理リソースをエミュレーションし、ゲストOSからの要求を調整し、ゲストOSごとのメモリ空間を隔離しています。

このVMMの処理が高速化することで、ゲストOSの性能は向上し、「ハイパーバイザ」中心の「サーバ仮想化」が受け入れられるようになりました。

2.2.4 「サーバ仮想化」の成熟とクラウドの出現

CPUに実装された仮想化支援機能により、仮想化によるオーバーヘッドを大幅に削減することに成功した各ハイパーバイザは商用での利用へ大きく前進することになり、また、これまで準仮想化の方法でゲストOSを提供していた製品（Xen 3.0 以降など）もゲストOSの完全仮想化を実現し、仮想化製品の開発競争が俄かに加熱することになります。

米Google社（以降Google）のCEO Eric Emerson Schmidt氏がSearch Engine Strategies Conferenceでのスピーチ^（注2）の中で「cloud computing」を初めて使ったのはこの頃で、以後私たちの知る「クラウド」という言葉が使われ始めました。

これに続くように、MicrosoftはServerの1つの機能としてCPUの仮想化支援機能に対応したHyper-Vを実装し、同様にオープンソースではLinuxのカーネルの機能に統合する形でKernel-based Virtual Machine（以降KVM）の1.0がリリースされ、これまで先駆をなしてきた製品と並び、仮想化市場の発展を加速させていくことになります。

2008年、Googleが文字通りのクラウドを意識したPaaSサービスGoogle App Engine（以降GAE）を発表すると、米Amazon社の自社システムにおけるIAサーバのリプレース後の余剰リソースを貸し出す目的から先行して展開していたAmazon Web Services EC2（以降AWS EC2）と並んでクラウドの市場を切り拓きました。IIJも商用としては2010年にIIJ GIO（ジオ）ブランドでクラウドサービスを展開し現在まで開発・提供しています。

ハイパーバイザの性能の課題が解消すると、今度は仮想化製品の操作・管理の難しさに問題が移ります。ハードウェアのサーバと同様にシステムの要素であるネットワークやストレージなどの設定は、IAサーバで緩やかに統一されてきたサーバとは異なり、メーカ、機種ともども別のアーキテクチャを採用しているものが多く、それらを操作する専門の知識が必要でした。また、物理的なリソース間で仮想機械を移動させ、可用性と共に効率性・安定性を向上させる必要がありました。これら従来の物理リソースで個々に実現していたことを、システムを構成する要素として抽象化し、総合的に制御する仕組みとして「オーケストレータ」と呼ばれる製品が登場しました。代表的な製品にはVMware vRealize Orchestrator、OpenStack、Apache CloudStackなどがあります。

2.2.5 マイクロサービス・アーキテクチャとOSレベルの仮想化

様々な技術的解決策で課題をクリアしてきたハイパーバイザですが、その技術の恩恵を受けたビジネス環境は年々変化のスピードが増していきました。クラウドというリソースを迅速に展開できる仕組みもできてはきたものの、ソフトウェアを開発する技術者にとっては必要なライブラリ以外のインフラ要素が多く、ビジネスに追随するためには大きな労力が必要になってきました。

この課題を解消するためのソフトウェアの開発手法として、マイクロサービス・アーキテクチャと呼ばれる複数の小さく疎なソフトウェアの集合体でアプリケーションを構成する開発手法が考え出されました。これに必要なリソースはアプリケーションを実行する環境のみという小さなものであったため、OSのすべての機能ではなくその一部を仮想化して提供するコンテナ技術が採用されることになり、コンテナ管理システムという更に新しい仮想化を包含した製品が生まれることになりました。代表的なものにはKubernetes、またその派生であるRed Hat OpenShift Virtualizationなどがあります。

このように、各時代における技術の進歩に伴いユーザの課題感は移り変わり、それに応じて役割を変えて進歩してきたのが仮想化技術です。

2.3 技術の選定とサービス開発

技術が課題を解消し、その技術を内包した製品が市場を拡大することで、私たちのサービスは多様化し、また差異を生むことができるのですが、すべての製品が期待するレベルで動作するものでないことはご承知のとおりです。

したがって、新しい製品が提供されるようになったからといって、それをすぐにユーザの利用する環境に適用するということはありません。しかしながら、前節で述べてきたように近年の仮想化技術の進歩は早く、真贋を見極める時間が十分にあるとは言えないため、サービスの要求事項を固めてから検討を始めるよりも、更に早い段階で技術を吟味し開発の方向性を決める要素を確認する必要が出てきました。また、現在のサービスで採用されていない製品に関しても、何らかの技術的な進展などによって、急激に市場が拡大する可能性を持っているため、その製品を取り巻く市場と併せて確認し続けています。

具体的な製品の評価プロセスは大きくは2つで、基本機能の確認と、サービスごとの確認です。前者の基本機能は製品として実装がうたわれている「機能」そのものと、その想定する性能になります。評価する製品にもよりますが、インフラ層であれば分かりやすく物理的な機器などの動作とカタログ値もしくは限界値の挙動を見ますし、仮想化層であれば構成する機器の組み合わせとハイパーバイザの動作と性能などを評価します。ずっと同じ評価をするということではなく、サービス運用の中で得られた知見（主に品質に関わる可用性や完全性など）を加え、徐々に共通の確認事項は増えていきます。後者のサービスごとの確認は、基本的にはサービスの要求事項を基にSLAを満たすための機能面、非機能面を評価することになります。この場合はシステムとして組み上げた場合、つまりユーザに提供する部分と運用管理する部分（維持保守だけでなく、ユーザにリソースを払い出す仕組みなど）を確認します。比較的上位のソフトウェアやアプリケーションとの連携などが主です。

サービスの品質を維持し運営していくにはもう1つの重要な視点があります。新しい製品が出てくるということは、既存もしくは古い世代の製品の寿命が定まるため、これらを採用しているシステムの変更対応を考えなくてはなりません。また後継の製品が今までの仕組みを踏襲するものであれば良いのですが、全く別のアーキテクチャになったり、全く別のライセンス契約になったりしたときに、サービスを継続して提供できるかどうかの見極めが必要になってきます。このような状況へ遅滞なく対処するために製品の特色に注目するのではなく、類似製品と共通に実装されている機能が何であるか、またその性能はどのくらいであるか、といった製品間の相互互換性を把握していることが重要です。これらの観点でも前述の早期に技術を理解・把握することが、市場における競合製品について機能・非機能両面での要求事項を整理しておくために必要になってきます。

最後にサービスで提供する製品として評価するのはコストです。ユーザの期待する機能を満たしていても、利用する目的に合わない費用感であれば採用されることはありません。他社製だけでなく自社製の製品であっても、これらの面で適切でなければ選択することはありません。

このような面で製品を評価し、その時期に確立された技術を取り入れ、用途に応じた基盤をIIJでは開発してきました。

2.4 IIJにおける実例の紹介

IIJ GIOホスティングパッケージサービス

IIJ GIOコンポーネントサービス ベースサーバVシリーズ 　 Linuxタイプ

IIJでは2008年ごろから社内のサービスホスト基盤の設計を見直し、画一的な構成のリソースをプールに集約して、需要に応じてリソースを分割利用する方式にしました。このとき、物理サーバのリソースを分割して利用するための仮想マシンモニタには、Xenを採用しました。このIIJ社内での運用実績とノウハウをもとに、2010年にリリースしたIIJ GIOホスティングパッケージサービスとIIJ GIOコンポーネントサービスVシリーズLinuxタイプの基盤でもXenを採用しました。

Xenハイパーバイザは、管理特権ドメインのdom0とユーザドメインのdomUをそれぞれ完全に隔離し、リソース配分とメモリ保護を行います。dom0は特権を持つ管理ドメインとして、ハードウェア管理とXenハイパーバイザの操作を行います。domUはユーザの仮想マシンであり、独立して動作し、Xenハイパーバイザによって他のドメインと隔離されています。このように各ドメインが完全に隔離され、セキュリティと安定性が確保されています。

当時はまだハードウェアによる性能支援が乏しい中、XenではゲストOSがXenに最適化されている場合に準仮想化（Paravirtualization）によって実用的な性能で利用できたこと、ソースコードが公開されていて透明性の高い開発が活発に行われていたことが採用の決め手となりました。

サービスを安定して提供するために、Xenハイパーバイザに対してIIJサービスで必要とする改変を加えたり、継続して安定利用するためにバージョンを固定して先行バージョンからパッチをバックポートするほか、ネットワークセキュリティ仕様を定め、仮想サーバから発生するパケット偽造や他の仮想サーバへの攻撃によるセキュリティ脅威の防止策を組み込むなど、これまで培ったノウハウをもとに対応してきました。また、顧客にITリソースを提供するIIJ GIOの基盤では、これまでのIIJサービスホストの運用ノウハウをベースに、リソースの確保から利用開始、返却まで一連のデリバリを自動化し運用を効率化するためのオーケストレータを独自開発しました。構成情報を一元管理し、連携して設定を書き換える自動制御の仕組みを構築することで、人の手ではとても対応できない膨大なリソースをミスなく、またリソースの配分を計算して公平かつ効率良く利用できました（図-1）。

拡大する

図-1 IIJ GIOホスティングパッケージサービス / IIJ GIOコンポーネントサービス ベースサーバVシリーズ Linuxタイプ

ライブマイグレーションによって無停止で機器の保守が可能になるなど、仮想化技術の活用を前提に構成を単純化することで、数千台規模のサーバで構成されるサービスであっても十分な品質を確保できました。このとき得られた数々の知見が、後継サービスのIIJ GIOインフラストラクチャーP2 パブリックリソースにも活かされています。

IIJ GIOコンポーネントサービス ベースサーバVシリーズ 　 Windowsタイプ

IIJ GIOコンポーネントサービスはエンタープライズシステムをターゲットとしており、システムインテグレーションのパーツとして必要な様々なコンポーネントを提供する方針で開発されました。

ユーザの社内IT環境ではWindows Serverのコンポーネント（Active Directoryやファイルサーバ、WSUSなど）が利用されていることが多く、エンタープライズシステムをクラウド上に移行するためにはWindows Serverをクラウド上で利用できることが必要です。このため、Windows Serverを安定的に稼働・提供するための基盤としてHyper-Vを利用した仮想化基盤を別途構築しました。

Microsoftは2009年にWindows Server 2008 R2をリリースしましたが、Windows Server 2008 R2で利用可能なHyper-V 2.0では、1つのストレージ領域（LUN）に複数の仮想マシンを保持した上で複数の仮想化ホストから同時にRead/Writeを行えるクラスター共有ボリューム（CSV）が実装され、仮想マシンのライブマイグレーションも可能となるなど、マルチテナントのサービス提供基盤として必要最低限の機能が利用可能になりました。

仮想マシンのライフサイクル管理やコンポーネントの監視など、基盤運用で必要となる機能はSystem Center製品群により一通り提供されていましたが、GUIからの操作を前提としており、自動化やオーケストレーションのためにはMicrosoftが提供するDynamic Datacenter Tool Kit（DDTK）というフレームワークを使用した開発が必要でした。

IIJ GIOコンポーネントサービス ベースサーバVシリーズ Windowsタイプの基盤では、IIJ社内でサービスの運用担当者が利用するオーケストレーションツールと、ユーザが仮想マシンの操作を行うためのコントロールパネルを、DDTKを使用して独自に実装しました（図-2）。

拡大する

図-2 IIJ GIOコンポーネントサービス ベースサーバVシリーズ Windowsタイプ

その後、Windows Serverの世代が新しくなるにつれて、サービスの運用に便利な機能が数多く実装されました。仮想マシンを稼働させたまま仮想マシンの保存先ストレージを変更できるストレージ ライブマイグレーションもその1つです。

初期の基盤ではこの機能が利用できないため独自に移行ツール（仮想マシンの停止が必要だが、作業開始後のロールバックにも対応した独自ツール）を実装していましたが、Windows Server 2012以降のサービス提供基盤ではストレージ ライブマイグレーションを利用することで、よりユーザへの影響を低減しつつサービスのメンテナンスや障害対応を実施できるようになりました。

管理ツールとしては引き続きSystem Centerを利用しつつ、サービスプロバイダ向けのREST APIを提供するService Provider Foundation（SPF）を利用することで、開発工数を削減しつつIIJとして必要なオーケストレーション機能を実装しました。

当初はWindows Server向けのサービス提供基盤として開発されたHyper-Vベースの基盤ですが、サポートやライセンスの観点で他のOSについてもHyper-Vベースの基盤上で提供されるなど、時期に応じて様々な利用がなされてきました。

数百台規模でHyper-Vの仮想化ホストが稼働し、Windows ServerやHyper-Vの進化に合わせてより安定したサービスが提供できるよう細かなアップデートを続けてきましたが、後継となるIIJ GIO P2の各サービスが提供されたことにより2023年9月にサービスの提供を終了しました。

IIJ GIOインフラストラクチャーP2 パブリックリソース

IIJでは2015年に、自社開発したSoftware Defined Networking（SDN）を活用して更にスケールできるIIJ GIOインフラストラクチャーP2パブリックリソースをリリースしました。仮想マシンモニタにはKVMを、仮想マシンエミュレータにQEMUを採用しました。初期のIIJ GIOをリリースした2010年からの5年間は、世の中ではサーバ仮想化を取り巻く各種技術が洗練され普及した時期でもありました。IIJ社内の仮想サーバを提供するサービスホスト基盤でも、世間の流行に応じてKVM+QEMUへの乗り換えを進めてきました。

KVMはLinuxカーネルと緊密に統合され、Linuxの機能やセキュリティアップデートを直接利用できます。Intel VT-xなどのハードウェアによる仮想化支援機能を活用でき、I/OやCPUリソースを効率良く利用できます。仮想マシンは独立したQEMUプロセスとして実行され、他の仮想マシンからの隔離が強化されています。

KVMとQEMUの組み合わせは設定や管理の難易度が高く、特に顧客への提供を前提にした大規模な環境では、高度な専門知識が求められます。IIJ社内でKVM+QEMUによる仮想化環境の運用実績がありノウハウがあったこと、ハードウェア仮想化支援の進化により完全仮想化（Full Virtualization）でも実用的な性能で動作し、ゲストOSで準仮想化の対応が不要でSEIL（ザイル）/x86^（注3）やWindowsの提供が可能であったことが、採用の決め手になりました。

サービスでの提供に当たっては、Linuxカーネルと緊密に統合されたKVMの特性から、IIJで独自性のある改変は積極的には行わない方針としました。独自開発したオーケストレータを自社開発のSDNに対応させるなど必要な機能追加を施し、先駆サービスのノウハウが詰まった開発資産を活用しています（図-3）。

拡大する

図-3 IIJ GIOインフラストラクチャーP2 パブリックリソース

ライブマイグレーションの積極的な利用など、これまで実現した運用の方式を踏襲しながら、更にスケールした規模であっても高い品質を安定して維持できるサービス運用を継続しています。

IIJ GIO仮想化プラットフォーム VWシリーズ

IIJ GIOインフラストラクチャーP2 プライベートリソース

IIJ GIOインフラストラクチャーP2 Gen.2 　 デディケイテッドサーバリソース

IIJでは2012年より企業向けのホステッドプライベートクラウドとして、VMware vSphere（以降、vSphere）をハイパーバイザに採用したサービスを展開しています。一般的なクラウドサービスでは、仮想マシンのスペックはクラウドサービス事業者が指定したインスタンスモデル（vCPU数、メモリ容量、OS種別など）でユーザのシステムを構成する必要があり、ピーク設計に慣れていないユーザには適切なメニューを選択することが難しい面がありました。本サービスでは占有されたハイパーバイザを直接ユーザが操作できることで、仮想マシンの設計や利用するOSの選択を自由に行うことができ、ユーザの考えるリソース配分でシステムを構成することが可能になります（図-4）。

拡大する

図-4 サービスの責任分界点

vSphereは利用しているユーザが多かったこともさることながら、適用できるハードウェアの種類も多く、事業者として提供しやすい製品でした。また、技術的にも、ユーザ間の分離はネットワークではVLAN、ストレージはデータストア向けに論理的にディスクを切り出す機能など、一般的に製品が実装している機能で充足できるため、特殊な開発（特別なプロトコルを開発するなど）はなく規模に合わせて開発することができました。

したがって、オンプレミスでvSphereを利用してプライベートクラウドを構築していたユーザが、大きな変更なしでクラウドサービスにスムーズに移行できる基盤として、3世代、10数年に渡って提供しているサービスです。

IIJ GIOインフラストラクチャーP2 Gen.2 　 フレキシブルサーバリソース

IIJでは2021年に第3世代のパブリックリソースサービスである、IIJ GIOインフラストラクチャーP2 Gen.2 フレキシブルサーバリソース（以降FSR）の提供を開始しました。前述の占有されたハイパーバイザを直接ユーザが操作できるサービスでは、ユーザがvSphereを直接操作できることで自由度の高いシステム構築が可能になった反面、仮想化基盤のバージョンアップやメンテナンスなどをユーザ自身が対応する必要があり、運用面で課題がありました。

FSRではVMware Cloud Director（VCD）を採用することで、CPU、メモリといった個々のリソースを抽象化しユーザへリソースプールとして見せることで、vSphereを操作する場合と同様にリソースを切り分けシステムを構築できる仕組みを提供しています。ハイパーバイザ層はユーザから隠蔽しますが、リソース制御の権限はvSphere並みにユーザが利用でき、ハイパーバイザやハードウェアのライフサイクル管理をIIJが担当し、前述の課題を解決しています。

本基盤の設計はユーザへのメリットだけでなく、ユーザ環境（ソフトウェア中心）と事業者の運用環境（ハードウェア）を完全に分離しており、これまで基盤維持のために重要ではあるもののユーザ都合で行いにくかったメンテナンスなどもIIJが積極的に対応できるため、IIJにとってもより安定したサービス基盤を実現しています。また、近年の様々なビジネス要求に応えられる継続的な開発・変更が行える基盤となりました。

2.5 まとめ

仮想化技術について、その歴史や変遷から、IIJでのこれまでの実例について解説しました。今世の中の動向として、仮想化技術についてその選択を迫られている時期かと思います。本稿が、最適な技術を選択、駆使していく、その一助になれば幸いです。IIJでは、仮想化技術の導入と運用において積極的な取り組みを行い、業務の効率化とコスト削減を実現しています。また、もう1つの側面として、記憶に新しいだけでも半導体不足やオープンソースの脆弱性が報道されるなど、サプライチェーンに対する潜在的な脅威についても考慮する必要があります。企業買収などにより従来どおり製品が提供されない状況が発生した場合でも、事業者としてユーザへ安定したサービスを提供するために多くの選択肢を準備するべく、仮想化技術の進展、製品を追い続けています。

今後も最新の技術動向を注視し、仮想化技術の進化に対応、活用していくことで、ユーザに対して更なる価値を提供していきます。

1. （注1）Internet Infrastructure Review（IIR）Vol.60 フォーカス・リサーチ（2） IIJとクラウドの変遷～30周年特別コンテンツ～（https://www.iij.ad.jp/dev/report/iir/060/03.html）。
2. （注2）Google Press Center、「August 9, 2006　Search Engine Strategies Conference Conversation with Eric Schmidt hosted by Danny Sullivan」（https://www.google.com/press/podium/ses2006.html）。
3. （注3）SEIL/x86はIIJが開発したx86アーキテクチャベースのプラットフォーム上で動作する高機能ソフトウェアルータ。

2. フォーカス・リサーチ（1）
仮想化技術の変遷とIIJの取り組み

• 2.1 はじめに
• 2.2 仮想化技術の歴史
• 2.3 技術の選定とサービス開発
• 2.4 IIJにおける実例の紹介
• 2.5 まとめ