Internet Infrastructure Review（IIR）Vol.60
2023年9月26日発行

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

IIJとクラウドの変遷～30周年特別コンテンツ～

3.1 はじめに

IIJは、インターネット接続をはじめとした通信サービスを中核に様々な関連サービスを提供してきました。これらのサービスを提供するための「サービスホスト」は30年間に渡り継続的に拡張されており、現在はサーバ数千台にも及んでいます。また、一方でクラウドサービス「IIJ GIO」としてお客様にコンピューティングリソースを提供することも行っており、こちらもサービス開始以降10年間でサーバ数万台規模のインフラへと成長しました。

今回はIIJがこれまで歩んできた30年を振り返り、前半ではIIJのサービスホストが時代背景を踏まえながらどのように変化してきたのか、またその過程においてどのような工夫を行ってきたのか紹介していきます。後半では、世代を経るごとに大規模なサービスインフラへと進化してきた顧客向けクラウド基盤「IIJ GIO」の変遷を紹介します。

拡大する

図-1 クラウドの変遷

3.2 1990年代：サービスホストの始まり

個別構築の時代

IIJが創業した1992年以降、メールやWebサービス提供のためのサービスホストは急速に数を増やしました。1990年代末期にはIIJサービス向けに東京都内の複数のデータセンターに分散して、200ラック以上、数千台規模のサーバを利用するようになりました。サービスごとにラックを確保し、個別に設備調達して構築していましたので、構成変更の度に現地作業が発生していました。そのような状況だったため、物理環境へのアクセスの容易さから、東京近郊の立地の良いデータセンターを利用しサーバ運用を最適化していました。

最初期にはUNIXワークステーションをサーバとして利用していましたが、コストパフォーマンスの観点からPC/AT互換機や、PC/ATベースの産業用PCの利用へと移行しました。まだラックマウントタイプのPCサーバは市販されておらず、市販の部品を利用してIIJのスタッフが自らサーバを組み立てるようなこともしていました。マザーボードやCPUを入れ替えて使ったり、IIJのスタッフが自分でRAIDを組んだり、マシンが故障したらすぐに交換できるように体制を整えたりと、大手町のデータセンターの中で様々な作業を行いました。低予算で設備や機材を用意することはできましたが、ハードウェアの故障の原因である電源や冷却ファンの故障といった物理的トラブルも増えました。

当時の商用UNIXワークステーションに搭載されていたOSは、価格の割に機能が十分ではなく、自分たちでの改良も困難でした。また、当時はまだLinuxが登場した直後で、実用的に使えるような状態ではありませんでした。そこで、IIJではBSD（カリフォルニア大学バークレー校の開発者グループによって生み出されたソフトウェア群）に由来するPC-BSDのライセンスを取得し、自分たちでサーバ用に再構成することにしました。これにより、格段にサーバの自由度が上がりました。ソフトウェアもハードウェアも手作りでした。こんなにサーバのコストと品質にこだわっていたのは、日本ではIIJぐらいだったと思います。

当時のインターネットでは深夜23時以降に電話料金が定額になる「テレホーダイ」が広く利用されていたため、個人向けWebサイトのアクセスピークは深夜23時でした。このため、日中は問題なく動作していたのに、深夜にWebサーバへのアクセスが集中しサーバの負荷が上がり、消費電力が増えすぎてブレーカーを落としてしまい、ラックごと電力供給が止まることもありました。

この頃のストレージは、サーバ内蔵ストレージを利用する場合と、大容量が必要な場合はサーバとSCSIケーブルでストレージを接続するDASが主流でした。1990 ～2000年代はまだ物理的に必要な容量とサーバ1台あたりの容量がどれくらいで、何台並べてどう構成したら費用がどうなるか、予算内に収めるためにはどこのハードウェアベンダーのサーバを使えば良くて、データセンターはどこに置くのか、そんな計画と計算が必要でした。ストレージの大障害を経験したこともあり、バックアップや余裕を持ったサイジングは絶対に必要だ、と身をもって学習しました。

3.3 2000年代：サービスホスト個別構築からの脱却

次世代ホストネットワーク「Next Host Network」誕生

Next Host Network（以下、NHN）は2008年度にサービスホスト運用の効率化を目的に、サーバ構成やサーバ運用ネットワークを再設計し開発されたIIJサービス向け基盤です。これ以前は、前述の通りサービスごとに設備調達を行いシステムを構築していたため、全体的に見て基盤にかかる費用が増加の一途でした。構成変更のたびに個々の拠点で現地作業が発生したり、運用も個々に定義され煩雑になってしまいました。また、それぞれのサービスの需要増に備え余裕のあるキャパシティを確保していましたが、需要の予測が外れれば設備転用が難しく、採用した機器も原則保守契約を結ぶため保守費用も増大しました。ファシリティについても、当時はシステムに問題があればすぐに駆けつけられるように立地の良い都市型データセンターを利用していたため、費用は高騰する一方でした。

このような慢性的な高コスト構造から脱却するには、基盤の根本的な在り方を再検討する必要がありました。数々の問題を解決に導くべく、個別に構築していたシステムを集約し、遠隔でも同等のサービスレベルで提供可能な運用が適用できる基盤として実装されたのがNHNです。国内に分散するデータセンター内のサーバ数千台を4年計画で順次リプレースし、これまでDASに格納していたデータはiSCSIストレージに統合、新たに導入するディスクレスサーバと併せてサービス需要に応じてIPネットワーク上で柔軟に組み替えることで、フレキシブルなサービスホストの提供を基本コンセプトにしました。

基盤設計方針としては、サーバは故障を前提に、ストレージは信頼性の高いもの、ネットワークは複雑なことをせずシンプルに再設計しました。現地作業を削減し、基本はリモート対応する運用方式への転換です。サーバ機器の故障ポイントは多岐に渡り、故障は避けられず故障率の低減には限界があるため、故障しても影響の少ない構成にしました。サービスごとのラック割を廃止しサーバプール方式を採用して収容効率を向上させ、現地作業は集約し外部業者へ委託できるようになりました。サーバ構成を画一化し構成管理負荷を低減しつつ、仮想化技術との組み合わせにより自由度も向上し、機器設置以降の作業をリモートで実行可能になりました。ストレージ機器のHDD単体の故障は避けられないですが、サービス停止に繋がる故障は回避できるよう、これまでより信頼性の高い構成にする必要がありました。そこでPXE Bootと、コントローラとパスを二重化したiSCSIストレージを利用し、安価で信頼性の高いディスクレスサーバ環境を構成し、故障時にはサーバ機器を切り替えるだけで復旧可能になりました。ホスト収容エッジスイッチの故障は、これまでの経験上さほど多くありませんでしたので、NIC冗長化設定などは必要な箇所のみ実施するシンプルな構成にしました。構成情報に基づき自動的にスイッチのVLAN設定を書き換える仕組みを導入し、物理配線の変更なしにネットワークを構成することで、設定ミスと運用コストの削減を図りました。NHNでは主にコストパフォーマンスに優れるハードウェアベンダー製のx86サーバを採用し、OSはCentOSなどのLinux OSのみでしたが、後にWindows ServerやVMware基盤も提供。ストレージはローエンドクラスながら保守性の高いストレージを採用し、それまで専門家任せだったストレージの保守作業が簡略化されたことで、IIJのスタッフでも自営保守しやすく、年間保守コストの削減に貢献しました。以下からNHNの各世代の特徴を紹介します。

NHN Gen1：2008年に提供開始したNHN第1世代インフラです。DASの排除を目的にiSCSIストレージを採用したのが特徴で、ストレージとして基本領域（60GB）と拡張領域（160GB）の2領域を提供していました。NHN Gen1ではサーバ4ラックとストレージ4ラックのセット構成を1ユニットとしていましたが、在庫リソースがなくなると同一L2領域での拡張ができず、ユニットごとの在庫調整が困難でした。ユニット間のサーバインスタンスの移動もできません。アップリンクが1Gbpsだったため、トラフィック増により上流帯域の逼迫も問題でした。

NHN Gen2：NHN Gen1での問題点を解消すべく設計され、2012年に提供開始した第2世代インフラです。ユニット構成はNHN Gen1と同様ですが、ラック収容効率が2倍に向上（1ラック40台）。JuniperのVirtual Chassis（以下、VC）を採用し、アップリンクの10Gbps化、各サービス固有のNHN標準以外の機器を受け入れるラックの確保や冗長電源、NICBondingに対応したのが特徴です。しかし、NHN Gen2ではToR用として採用したスイッチの不具合によりネットワークが全断するという問題も起きました。VCを組むユニット全体に障害が波及し、復旧に時間を要する事態となりました。

NHN Gen2コンテナ：松江データセンターパークに導入された、コンテナ型DCモジュールIZmo/Sに最適化されたNHNです。IZmo/Sの搭載ラック数に合わせ、1ユニット当たり8ラックサーバ288台構成（後にサーバを16台抜いてストレージを4台投入）としたのですが、NHN Gen2コンテナはスリムコンテナ仕様で空間効率が高かった半面、コンテナ内の通路が狭く、メンテナンス性が著しく悪いことが運用上の問題となりました。

3.4 2010年代～現在：次世代サービス基盤「Type-N」登場

サービスホストはType-Nへ

2014年10月、NHN第3世代インフラとして新たにType-Nシリーズを提供開始しました。これまでサーバはベアメタルサーバ単位で提供していましたが、Type-Nシリーズから仮想マシン単位の提供も開始しました。ベアメタルサーバーまでは必要のない、より小スペックなニーズにも応えらえるようになりました。以下からType-Nの各世代の特徴を紹介します。

Type-N：2014年に提供開始したNHN第3世代インフラです。ルータにL2スイッチを収容するそれまでの形態から、L2コアスイッチへL2スイッチを収容する形式に変えることで、同一L2面をユニット間で提供可能となり、持込ラックとの接続性も向上し、ユニットごとの在庫調整も不要となりました。通常のサーバの他、ハイメモリサーバやHDDを大量搭載したストレージサーバも利用可能になりました。しかし、Type-Nではサーバの1GbE NIC向けに採用したスイッチの性能が乏しく、接続可能な機器台数の限界値が低いことが問題となりました。

Type-N100：Type-Nをベースに、コンテンツ配信サービス向けに開発された広帯域提供インフラです。名前は100Gbps提供インフラに由来し、ロードバランサー専用ユニットやMPLSを使用し直接IX接続を担うIIJ BBのルータとも接続可能なことが特徴です。メモリブートが必須（iSCSIストレージは提供しない）で、一時ログやキャッシュ用途としてSSD 1TBを搭載しました。

Type-N2：2017年に提供開始したNHN第4世代インフラです。1Gネットワークを廃止し、エッジまでフル10G化したのが特徴です。ハイメモリサーバはVMware基盤を前提としたクラスタ型アプリケーション向けにユニット追加の対応を行い、ハードウェアの性能向上によりシステムの集約率も向上しました。しかし、Type-N2ではストレージ性能が一部アプリケーションの要求水準を満たせないことが問題となりました。

Type-N3：2018年に提供開始したNHN第5世代インフラです。CPUに当時最新のIntel CPUを採用し、フラッシュストレージ（NVMe SSD）搭載によるIO性能の大幅向上に合わせ、ネットワーク性能も大幅な向上を狙いました。Type-N3ではストレージとして提供していた基本領域と拡張領域は廃止し、全領域を1つのPV（フィジカルボリューム）として提供しました。

Type-N4：2019年に提供開始したNHN第6世代インフラです。引き続きCPUに当時最新のIntel CPUを搭載しつつもOCP準拠サーバ（後述）を新たに採用し、調達コストと消費電力の削減を図りました。ネットワークはエッジ～コア間をこれまでの10 ～20Gbpsから40Gbpsに増強し、コアスイッチにシャーシ型製品を採用することで、将来の設備増強に耐えうる構成としました。

ストレージは、2019年からミッドレンジクラスのストレージをメインストレージとして採用。2021年には性能や信頼性は当然として、これまで築き上げてきた様々な手順や枠組みをそのまま適用できる運用面を大きく評価して、初代のNHNで採用したものと同じメーカの後継機種を採用しています。また、自社構築、自社運用を基本としているNHNにとって、OSやファームウェアのセルフアップデートを含めた自営保守が可能なストレージ製品は、コスト面でも大きなメリットがあります。

OCPサーバの導入

OCP（Open Computing Project）は2011年にFacebookをはじめとしたハイパースケーラーが提唱した新しいサーバの規格です。メーカ主導で開発・製造が行われる従来型のサーバと比較して、OCPではサーバを利用するクラウド事業者が部品の選定や調達・製造に深く関与するといったスキームの違いがあります。

IIJとしてもOCPサーバに関心はあったものの、2017年頃までは当時調達していた一般的なサーバメーカに比べて調達価格が高過ぎて割に合わない状況が続いていました。ところが、2018年に入り円高の進行や半導体業界の過剰在庫により、DIMMやSSDなどの価格が下落傾向に転じます。こうした市況を踏まえ、本格的な導入検証に着手しました。為替の影響を直接受けたり、ハードウェア面では新たにOCP専用ラックや集中電源が必要なことやBIOSやBMCのテストは発注側が実施しなければならないこと、運用面では保守はパーツ交換（自営保守）のみ、ODMベンダーとのやり取りは英語等々、様々な課題や懸念事項が山積したものの、それを上回る導入メリットがあると判断し、OCPサーバを導入することを決断しました。実際にOCPサーバを導入した結果、調達費用は最大35％減、電力消費量は最大30％減の削減効果を達成できました。特に調達費用は当初見込んでいた10％減を大幅に上回る削減効果を得ることができ、その後のOCPサーバ導入拡大の契機となりました。ただし、現状ではエンタープライズ向けでは明らかに適さない用途・領域が存在することも分かっています。2019年夏には既存設備同様OCPサーバにおいてもマルチベンダー体制を確立し、技術的リスクと調達リスクの分散を図っています。

続いて、顧客向けクラウド基盤「IIJ GIO」の変遷を紹介します。

3.5 2000年代：IaaS（Infrastructure as a Service）の先駆け

リソースオンデマンドサービス「IBPS」提供開始

1990年代後半にはServer Side JavaやASPが使えるようになりインターネット決済のインフラが実現されると、動的サイトを利用したECサイトが多数登場するようになりました。ECサイトのシステムアーキテクチャは、どのお客様サイトの構成でも似たようなものであったため、予め機器を用意して部品化しておき、ユーザからオーダーがあったら必要な部品を組み合わせて提供すれば効率が良くなる、そう考えて作ったのが、現在のクラウドサービス「IIJ GIO」の前身である、リソースオンデマンドサービス「IBPS（Integration & Business PlatformService）（注1）」です。

当時グループ会社だったアイアイジェイテクノロジー（2010年4月にIIJに吸収合併）から2000年3月に提供開始されたIBPSは、インターネットビジネスで必要となるサーバ機器からソフトウェア、決済/物流コンポーネント、監視・運用管理に至るまで、企業ニーズに合わせて必要な部品を組み合わせ、システム全体をアウトソーシング・サービスとして提供するサービスです。インターネットビジネスの早期展開を必要とする企業からの要望に応え、開発期間と初期投資を従来の1/2以下（当社比）で提供することを可能としました。

IBPSが提供する主な4つのサービス

• データマネジメントサービス（DMS）：IIJが保有するストレージリソースをオンデマンド提供。お客様のサービスレベル、利用形態に応じて選択可能なストレージ接続方式（NAS・SAN）・容量・性能のストレージ領域を提供することで、ストレージコストの最適化を実現。別ディスクによる高速バックアップも提供することで、これまでの手間と時間のかかるテープによるバックアップ業務からお客様を解放
• ネットワークマネジメントサービス（NMS）：IIJが保有するネットワークリソースをオンデマンド提供。ロードバランサーやファイアウォールなどをプール化し機能として提供すると共に、典型的な構成はセットメニュー化することで低コストを実現
• サーバマネジメントサービス（SMS）：IIJが保有するサーバリソースをオンデマンド提供。お客様専用のサーバ構成情報をプロビジョニングツールで管理することで構築作業を半自動化し、お客様固有ニーズに応じたシステムを短時間で利用可能
• 運用管理サービス：IBPS上に構築されたお客様システムの運用・監視を代行することで、システムに係るTCOの削減に貢献

必要なときに必要なリソースを使い、いらなくなったら解約できる。ユーザは一切資産保有リスクを持たなくて良い。IBPSは今でいうIaaSに相当するサービスでした。フロントエンドのサーバは当初UNIXサーバ（SPARC Solaris）でしたが、後にx86サーバに移行したものの、ミドル/バックエンドはDB用途でUNIXサーバが残りました。従来はラックマウント型サーバを利用していましたが、2007年8月に国内初のリソースオンデマンド型のサーバ提供を開始したSMSでは国内の大規模サーバ基盤で初めてブレードサーバを導入。スペースを節約できる上に、設定済みのシャーシにCPUブレードを挿すだけで利用できる点を評価しました。

2003年10月にはIBPSサービス開始当初から提供していたデータマネジメントサービスを機能拡張し、総容量40TBの大規模ストレージサービスを提供開始。ミッドレンジストレージでは柔軟なリソース管理とコスト削減を狙って、ストレージ仮想化ソフトウェアを採用しました。2007年にはデータマネジメントサービスを設備更改し、ストレージGB単価を1/2（注2）に削減しました。データマネジメントサービスではSAN品目とNAS品目をそれぞれ提供していましたが、適度な価格で高品質なFiber Channel（以下、FC）を利用できるサービスが提供されるとFC-SANのストレージ利用が拡大していきました。NASについては、当初は汎用サーバとクラスタソフトウェアで組み合わせたNASやNAS専用のストレージアプライアンスを利用していました。特に2000年代前半のNAS製品は1TBを超えるボリュームをサポートしている製品が少なく、大容量のNASを利用したい場合などは汎用サーバ＋FC-SANのストレージ＋クラスタソフトウェアを組み合わせたNASを構築していました。2000年代後半になると、NAS製品が大容量のボリュームをサポートし始めたため、NAS専用のストレージアプライアンスにシフトしていきます。

L2リングプロトコル構成を採用した2008年以降

サービス基盤のネットワーク技術においては、2008年以降はL2リングプロトコル構成を採用しました。多段リング物理構成が日本国内のDC収容規模に適しており、効率の良いシステムを構築できるメリットを持ちながら、システム増強もCore/Edgeに関わらず容易に拡張可能でした。ただし、収容ノードのインタフェースが10GbE以上になると1GbE以下の機器構成に比べ選択できる機種が減少するため、収容ノード数に制約が発生するのがデメリットでした。L2リング構成はメーカ独自仕様が多く、異なるメーカ間での互換性がありません。そのため、ベンダーロックインとなってしまう可能性が高く、利用可能な機器の選択肢が少なくなるというのも問題でした。

拡大する

図-2 L2 リングプロトコル構成（2008年～）

様々な基盤に採用されるストレージアレイシステム

サービス基盤のストレージ技術においては、2000年にIBPSを開始した当時からサービス基盤にはストレージアレイシステムを採用しています。主にハイエンド～ミッドレンジクラスのストレージを性能要件に合わせて数種類、調達や技術的なリスク分散も兼ねて採用していました。そして現在もIIJGIOとNHNにおいては、それぞれの基盤にストレージアレイシステムを採用しており、ストレージの容量は日々増え続けています。

ストレージ運用は、導入当初はストレージに関する知識が乏しいこともあり、ストレージの構成変更や監視はすべて各製品ベンダーに運用を依頼して行っていました。しかし、この運用方法だと例えばLUNを1個作成するだけでもそれなりのキャッシュアウトとリードタイムが発生してしまうため、IIJのスタッフがストレージの操作について学び、自社でストレージの構成変更ができるようになることで、運用コストの削減を図りました。監視については当初からIIJの標準監視サービスを利用していましたが、順調にサービスが成長していく中で、障害が発生してしまった際に標準監視サービスが圧迫され、ストレージ運用チームが障害を認知するのに遅延が生じるようになったため、ストレージ設備専用の監視システムを構築しました。

3.6 2010年代：本格的なクラウド時代へ

クラウドサービス「IIJ GIO」誕生

IIJは10年以上に渡るIaaSビジネスの経験とサービス基盤の進化の過程で、IBPSサービスにおける仮想化の適用やプロビジョニングシステム、監視システムの内製、サーバ・ネットワーク・ストレージ設備の大規模更改といった、様々な課題を乗り越えてきました。そのノウハウを結集させて開発したのがクラウドサービス「IIJ GIO」です。ユーザが自社でIT資産を所有することなく、企業のビジネスインフラとして耐えうる高い可用性とセキュリティレベルを維持したサービスレベルの高いシステム環境を、より安価に利用できるという、クラウドのメリットを訴求したサービスでした。

第一弾として、企業の多様なニーズにきめ細かく対応するプライベート型クラウドサービス「IIJ GIOコンポーネントサービス」を2009年11月より提供開始し、続いて、パッケージ化された安価なパブリック型クラウドサービス「IIJ GIOホスティングパッケージサービス」を2010年6月に提供開始しました。

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

IIJ GIOホスティングパッケージサービスは、用途に合わせてあらかじめパッケージングされたプランをユーザ自身がオンライン上で選択するだけで、ECサイトや高機能なネットビジネスの情報システム基盤を手軽に構築することができるのが特徴でした。仮想化技術を駆使したサービスアーキテクチャにより、システム要件に応じてサーバリソースを柔軟に選択できるほか、IIJ独自開発の制御機能によりレイヤー2ネットワーク上で複数台のサーバリソースの自動的な割り当ても可能にしました。また、オープンソースソフトウェア（OSS）を採用し、リソースの割り当てを制御するプロビジョニングツールや複雑な運用、監視を自動化する管理ツールを自社開発することで、運用・コスト両面での大幅な効率化を図りました。更に、基盤を集約することによりハードウェア調達コストを抑え、安価な価格設定を可能することで、仮想サーバ1台当たり月額8000円からの低価格を実現しました。2013年9月にはIaaSを操作するAPIを公開し、多数の仮想サーバを一度にデプロイするなどの定型操作をユーザ独自のプログラムを作って自動化したいというニーズに対応しました。

IIJ GIOコンポーネントサービス

IIJ GIOコンポーネントサービスは、サーバやストレージ、ネットワークといった各システム構成要素を”コンポーネント（部品）”として提供することで、様々なメニューの中からユーザの要望に合った最適な構成を組み合わせ可能な、柔軟性の高いエンタープライズ向けIaaS型クラウドサービスです。オンプレミス環境と直接広域ネットワークで接続することで、プライベートクラウドとして利用することも可能です。IIJ GIOコンポーネントサービスの主要なコンポーネントは「ベースサーバ」と2012年8月に提供開始した「仮想化プラットフォームVWシリーズ（以下、VWシリーズ）」です。ベースサーバは、他の顧客と物理サーバを共用する仮想サーバ「Vシリーズ」、1台丸ごと専有できる物理サーバ「Xシリーズ」の2種類を提供しました。VWシリーズは、物理サーバに米VMware社の仮想化ソフト「VMware vSphere ESXi」を搭載した顧客専有環境を、管理サーバであるVMware vCenter Serverと共に管理者権限付きで提供しました。それゆえに、システム構成の自由度ではオンプレミス環境と遜色なかったため、新規にサーバ統合やクラウド構築を検討しているユーザだけでなく、既にVMwareで仮想インフラを構築・運用しているユーザも安心して利用することができました。

IaaSとして、サーバリソース以外の機能も提供しました。1つめは、ベースサーバやVWシリーズで標準提供されるネットワーク機能を強化する「ネットワークアドオン」です。共用のインターネット接続回線を専用回線（プライベート接続）に変更することで、インターネットVPNや閉域網（広域ネットワーク）を使って安全にオンプレミス環境と接続することができます。また、WAN回線のキャリアを分けるマルチキャリア構成にすることもできます。2つめは、「ストレージアドオン」です。金融機関でも利用されるハイエンドなストレージを提供する「スタンダード」、一般的なWebシステムなどのデータ管理に適したミッドレンジの「ベーシック」の大きく分けて2種類を用意し、ネットワーク経由でNASストレージ、FC-SANストレージ、またはiSCSI-SANストレージとして提供しました。3つめは、Oracle Database、MySQL をDBaaS（DataBase as aService）として提供する「データベースアドオン」です。2012年7月に提供開始したデータベースアドオンは、国内のデータベース市場で圧倒的なシェアを持つOracle Databaseを国内事業者としては初めて月額料金で提供。ユーザのデータベースライセンスへの初期投資や保守費用負担の軽減、投資リスクの回避を実現しました。本サービスでは、多くのリレーショナルデータベースの導入・運用経験を基に、IIJがデータベースのインスタンスの設計・運用を行い、IIJ GIOの仮想サーバ群から利用できるようにしています。更に、閉域網またはインターネットVPN経由で既存のオンプレミス環境との接続も可能としました。2014年5月には価格改定を実施し月額料金を最大56％値下げし、同年10月にはMicrosoft SQL Serverをラインナップに追加するなど積極的なサービス開発を展開しました。4つめは、クラウド上で利用するソフトウェアライセンスを月額料金で提供する「ライセンスアドオン」です。MicrosoftSPLAをはじめとして、利用ニーズの高いRed Hat、VMware、Arcserve、Trend Micro各社の製品、サービス等を月額料金で提供しています。

2014年1月にはIIJ GIOコンポーネントサービスのラインアップを強化し、既存の「ベースサーバ Vシリーズ」の機能を拡充した後継サービス「ベースサーバ VシリーズG2」（以下、Vシリーズ G2）を追加しています。Vシリーズ G2では、当時最新だったWindows Server 2012 R2に対応するほか、CPU、メモリとディスク容量を増強し、旧シリーズのWindowsラインアップと比べ、CPUは3倍の最大24ICU（注3）、メモリは6倍の最大48GBを搭載したラインアップを提供しました。また、サーバ設備は東日本及び西日本のサイトで提供することとし、ディザスタリカバリ用途にも利用可能となりました。

第2世代クラウドサービス「IIJ GIO インフラストラクチャー P2」登場

2015年10月、「IIJ GIO」で提供しているIaaSを刷新し、新たなラインアップとして「IIJ GIOインフラストラクチャーP2」（以下、IIJ GIO P2）を提供開始しました。これまでIaaSのラインアップとして、オンラインで手軽に導入できるパブリッククラウド「IIJ GIOホスティングパッケージサービス」と、多様なITリソースを組み合わせてシステムを構成できるオーダーメイド型の「IIJ GIOコンポーネントサービス」を提供してきましたが、IIJGIO P2はより信頼性・処理性能を高めたパブリッククラウドと、オンライン申し込みで即時利用を可能にしたプライベートクラウドを1つに融合し、幅広いユーザのニーズをすべてカバーするサービスを目指しました。IIJ GIO P2は、仮想サーバを中心とした共有リソースを提供する「パブリックリソース」と、VMware仮想化環境と物理サーバを専有リソースとして提供する「プライベートリソース」、パブリックリソースとプライベートリソースの両方のサーバで利用できる「ストレージリソース」から構成され、ユーザは最適なリソースを組み合わせてシステムを構築できます。更にIIJ GIO P2はマルチキャリア対応やプライベートセグメントの延伸など外部接続性にも優れ、オンプレミスや他社クラウドサービス環境とシームレスな連携が可能です。

パブリックリソース：仮想サーバを中心とした共有リソースを提供し、開発環境、簡易なWebサービスから高いI/O性能が求められるオンラインゲームやECサイトのプラットフォームまで、幅広い用途に対応できるパブリッククラウドで、ユーザは用途に応じて特徴の異なる3つのタイプから自分に最適なサーバリソースを選択できます。

• 「性能保証タイプ」は、安定した処理性能を必要とするユーザ向けに、CPUが確実に割り当てられる仮想サーバを提供。月額固定料金で安心して利用できます。
• 「ベストエフォートタイプ」は、CPUを分配利用することで低コストを実現した仮想サーバを提供し、1時間単位の従量課金で、コストの最適化を図ることが可能です。
• 「専有タイプ」は、高負荷に耐えうる高いI/O性能を求めるユーザ向けに、仮想化された専有サーバを提供します。物理的に他のサーバから切り離されたセキュアな環境で、SSDまたはサンディスク社製高速フラッシュストレージを搭載したサーバを利用できます。

3つのサーバタイプの組み合わせやタイプ変更はオンラインで自由に行うことができ、更に稼働中の仮想サーバからOSイメージを専用領域に保管することで、それを元にした迅速なサーバ構築が可能です。運用負荷が軽減し、高負荷時のスケールアウトやパッチの適用にもスピーディーに対応することができます。カスタムOSイメージを保管する専用領域は保管容量に応じた従量課金のため、無駄なコストも発生しません。

プライベートリソース：オンプレミス環境で構築されたシステムをそのまま移設でき、企業の基幹システムにも利用できる信頼性の高いプライベートクラウドです。VMware仮想化環境と物理サーバを中心としたラインアップを提供し、ユーザ専用のリソースとして利用することができます。また、これまでのIIJ GIOコンポーネントサービスでは対応していなかったオンライン申し込みが可能になり、ユーザはコントロールパネル経由でサービスの即時利用（標準モデルの場合）とサーバリソースのセルフ管理が可能となり、1日単位で必要なリソースを増減できます。最大24コア対応のCPU、192GBのメモリ、帯域10Gbpsのネットワーク対応など、これまでのIIJ GIOコンポーネントサービスに比べて、選択できるサーバの性能が向上しています。更にディスクなどのサーバスペックはオンライン上でカスタマイズすることが可能で、より大容量なメモリの搭載によりシステムの集約率を高め、ユーザ自身でシステム要件に沿ったサーバを設計・構築することができます。

IIJ GIO P2ラインナップ拡充と西日本リージョン提供開始

2018年6月にはIIJ GIO P2で提供している「仮想化プラットフォームVWシリーズ（以下、P2 VWシリーズ）」のサーバ性能を強化し、従来提供しているCPUコア数の倍となる48コアのCPUリソースを搭載した「VW48-1024-FC-10G」、及び96コアを搭載した「VW96-1024-FC-10G」を追加し、それぞれ2018年6月1日、2018年10月以降より提供開始しました。追加する品目は、AIの情報処理やSAP S/4 HANAなど、取り扱うデータの処理にハイコア・ハイメモリが求められるアプリケーションのインフラ需要を想定したものです。

同じく2018年6月、IIJ GIO P2において西日本リージョンを開設し「パブリックリソース」を提供開始し、同年10月より「プライベートリソース」「ストレージリソース」を提供開始しました。東日本リージョン、西日本リージョン間はIIJの提供するプライベートバックボーンサービスで結ばれており、広帯域なリージョン間ネットワークを無償で利用することができます。また、地理的に十分に離れたリージョン間でサービスを利用することで、ユーザはBCP（事業継続計画）に基づいたシステム構成をとることができるなど、利用用途の拡大を図りました。

2020年7月にはP2 VWシリーズの機能を強化し、仮想マシンを容易かつ低コストでバックアップできる「バックアップセット/VWオプション」を提供開始しました。バックアップセット/VWオプションでは、米ルーブリック社のバックアップ製品「RCDM（Rubrik Cloud Data Management）」を活用し、仮想マシンのバックアップに必要なコンポーネントを一括で提供します。本オプションを利用することにより、ユーザはバックアップ設定メニューから必要なプランを選択するだけで容易にバックアップ及びリストアが行えます。取得したデータは暗号化され、IIJのクラウド上にあるバックアップサーバに保存するため、ユーザ側でのバックアップシステムの構築や運用が不要になり、コスト削減、運用負荷軽減にもつながります。

L2 MLAG構成からL2 over L3構成へ

サービス基盤のネットワーク技術においては、2014年以降はL2 MLAG構成を採用しました。収容ノードのインタフェースが10GbE以上でも一定のスケールを実現できるのがメリットです。MLAGを実装しているのはデータセンタースイッチメーカのため、ハードウェア、ソフトウェア共にデータセンター向けに最適化されていますが、どのようなファシリティにも適用できる設計ではない点に注意が必要です。どちらかといえば広大な面積を持ったフロア向けの設計であるため、機器を設置するフロア面積や、給電・冷却の能力によってはスイッチの収容ポートを使い切るだけの機器が設置できず、シャーシを採用する前提（収容ノード数を確定した前提）でフロア構成が設計できる場合でないと、効率良く利用できないといった状況に陥りやすいと考えられます。

拡大する

図-3 L2 MLAG構成（2014年～）

2017年以降はL2 over L3構成を採用しました。MLAG同様のメリットを踏まえつつ、インターネットで長く利用され実績のあるL3技術で柔軟な物理トポロジを実現できるのが強みです。ただし、当時のVxLANの実装では設計に制約があり、どのVTEPにどのVLANを設定するかなど、動的な制御を実現するには標準実装が成熟しておらず、静的な設定で管理できる現実的な位置にVTEPを置いた設計としました。

拡大する

図-4 L2 over L3構成（2017年～）

ストレージ設定の自動化

「IIJ GIO」では、ユーザからストレージの申し込みがあった場合、2010年頃まではストレージを運用しているエンジニアが手動でストレージとFCスイッチの設定変更を行っていました。この頃まではストレージの設定変更を行う業務は多くても週に1回程度と頻度が少なかったため、エンジニアによる手動の設定変更でもサービス仕様として設定されているリードタイムに十分に間に合いました。しかし、2010年を過ぎると週に1回の業務が週に数回、更には1日に数回発生するようになり、いずれは人手を介した作業が困難になると予想されたため、ストレージの設定変更をすべて自動化するようなシステムを設計・構築しました。

ストレージ設定の自動化を行うためには、市販のアプリケーションなどを利用すれば簡単なのですが、市販のアプリケーションはストレージ設定の自動化だけでなく、それ以上の機能を有するものが多く（かつ高価なため）、ストレージの制御部分は自作をしました。ストレージ制御はPythonやRubyなどのスクリプト言語を使って記述しています。本来、各種言語からストレージの構成変更を行う場合、ストレージ管理の仕様であるStorage Management Initiative - Specification（SMI-S）や独自APIを経由して構成変更を行うことが望ましいです。当時使用していたストレージやFCスイッチそれぞれ単体ではSMI-SやAPIに対応しておらず、別途専用の（高価な）アプリケーションが必要であったため、標準で提供されているストレージを制御するコマンドラインアプリケーションを使用しました。コマンドラインアプリケーションの入出力は人間が操作することを想定して作られておらず、とりわけ出力はスクリプト言語で制御するには非常に扱いにくい形式であることが多く、作成したプログラムも相当面倒な文字列処理を行う必要がありました。また、使用していた機器の一部は、コマンド及びパラメータに誤りがあってもリターンコードが0（正常終了）を返すため、独自のエラー処理を追加する必要もありました。

最も手間がかかるのは、ストレージアレイシステムやFCスイッチのファームウェアをバージョンアップするときです。バージョンアップ後のコマンドライン出力結果がバージョンアップ前と比較して変更が発生する製品もあり、本番でバージョンアップする前に開発環境で事前のテストを行う必要がありました。最近のストレージやFCスイッチは、構成管理を行うソフトウェアであるAnsibleなどへの対応が進んできていることから機器単体でのAPI実装が進み、かつPythonなどでストレージ制御に使えるモジュールを各ストレージベンダーが提供するようになったため、当時と比べると非常に簡単にプログラムを組むことができます。2010年以降のストレージ選定においては引き続き前世代からの調達方針を踏襲していましたが、性能要件の拡大と我々の採用条件をクリアするストレージアレイ製品の増加により、採用するストレージ製品も増えてきています。

3.7 2020年代～現在：更なる進化を目指して

「IIJ GIOインフラストラクチャーP2 Gen.2」提供開始

IIJ GIOブランドで開発・提供してきたパブリック型IaaSとプライベート型IaaSを完全統合し、オンプレミスからの移行を容易にする次世代モデルのIaaSを「IIJ GIOインフラストラクチャーP2 Gen.2（ピーツージェンツー）」（以下、GIO P2Gen.2）として2021年10月1日に提供開始しました。

拡大する

図-5 コントロールプレーン／データプレーン完全分離構成（2021年～）

GIO P2 Gen.2の特徴は、仮想基盤にVMwareを採用しオンプレミス環境の設計思想や運用体制をそのまま持ち込み可能とすることで、GIO P2から引き続きオンプレミスのVMware環境からのクラウド移行需要を狙ったものになります。もちろん、後継サービスとして既存ユーザの新たな受け皿としての役割も担っています。また、GIO P2 Gen.2は一般的なプライベートクラウドのような「サーバ単位」ではなく、「仮想リソースプール」から最小「1vCPU/4GBメモリ」というリソース単位で自由に仮想マシンを作成可能です。つまり、現在ユーザの環境で動いているマシンスペックをそのまま移行することができます。この形式であればイメージを持ち込んだり、P2VやV2Vを実施することで既存環境の物理マシン・仮想マシンを移行することも可能です。ファイルサーバやActive Directory、データベースなど、企業のIT環境に必要なコンポーネントを備えた各種マネージドサービスなども提供される上、ハイパーバイザや、サーバ、ストレージ、ネットワークなどのハードウェアは抽象化されるため、ユーザは機器の差異を意識する必要はありません。これは、GIO仮想化プラットフォーム VWシリーズが抱えていた、ユーザがハイパーバイザの管理を行うことで生じる脆弱性対応のためのソフトウェアアップデートの作業や、ハードウェア更改のための移行作業をユーザ自身が行う負担を大幅に軽減します。他社パブリッククラウドとの閉域接続を提供するネットワークサービスなど、IIJの各種サービスと連携することにより、パブリッククラウドへの将来的な移行を見据えた利用も可能です。もちろん、プライベートクラウドと同様に自由にリソースを選んでシステム環境を構成できる「フレキシブルサーバリソース（FSR）」に加えて、VMware vCenterServerをフル権限で利用できる従来のP2 VWシリーズと同等の「デディケイテッドサーバリソース（DSR）」も継続して提供しています。

GIO P2 Gen.2「フレキシブルサーバリソース（FSR）」では、米VMware社が提供するサービスプロバイダ向け製品であるVMware Cloud Director（VCD）を採用し、ハイパーバイザ（vSphere）層を利用者から隠蔽することで、vSphere並みに柔軟なリソース制御権限をユーザに提供しつつ、ハイパーバイザやハードウェアのライフサイクル管理をサービスプロバイダとしてIIJが受け持つという、新しい共同責任モデルを定義することでハイパーバイザのネットワークをIIJが管理・運用できるようになりました。また、サービスの機能として移行機能を提供し、お客様は最小限の停止時間、操作でクラウド移行を実現できます。併せて、ハイパーバイザ層のネットワークを効率的に運用するため、vSphereと統合的なインテグレーションが行えるVMware NSX-T DataCenter（以下、NSX-T）を採用し、IaaSのネットワークを大幅に改善させました。GIO P2 Gen.2では、レイヤー3で構成したIPファブリックのアンダーレイネットワーク上にNSX-Tでオーバーレイネットワークを構成し、テナントごとのネットワークを完全に分割しVPC（VirtualPrivate Cloud）として提供できるよう設計しています。これまでIIJ GIOで培った大規模サーバプールの運用ノウハウと組み合わせることで、物理的なコンピューティングリソース（CPU、メモリ、ストレージ）の配置に縛られることなく、利用者にリソースを割り当てることを可能にしています。

SDN技術を活用したオーバーレイネットワーク

複数のユーザを収容するIaaSにおいて、リソースを効率的に提供するため物理リソースを共有すると共に、ユーザ間のセキュリティを保証することは、基盤を設計する上で最低限求められてきたことです。ユーザのコンピューティングリソースであるサーバの仮想化技術は十分に成熟した製品が市場にありましたが、ネットワークの仮想化は既存のプロトコルとの相互接続性も担保する必要もあり、実装は慎重に進められてきました。近年、ハードウェアの性能向上とSDN技術の発達によりネットワークの仮想化技術も大規模なネットワークで採用できる技術になってきています。GIOの基盤も早くからネットワークの仮想化技術の1つであるオーバーレイネットワークを評価し、それぞれの世代で信頼できる技術を採用してきました。

GIO P2 Gen.2では、これまで性能を確保するためネットワークハードウェアの機能で終端していたオーバーレイネットワークを、ホスト内の仮想スイッチで終端する方式に変更したことで、ユーザ間の分割はもとより、ユーザシステムと物理基盤システムの完全な分離を実現しています。これにより、基盤システムの変更によるユーザシステムへの影響はより小さくなり、新しい機能の追加が容易になりました。

また、物理層と疎結合であるということは、IaaSをマルチサイトで展開する上でも有利に働きます。既存のGIOと同様に、東日本・西日本といった少数の拠点に大規模に設備を展開し、その間をシームレスに接続することができるだけでなく、災害に備えより小さな規模で各地に分散配置することも容易になることが期待できます。

反面、これまでハードウェアの制限で個々に分割・管理していた各デバイスの設定は、ソフトウェアでの処理に変わることで制限がなくなり非常に膨大な情報量になります。人が把握できる量を超えるため、これまでのように人で変更して回る運用は品質を担保する上で変えていかなくてはいけません。同時に、ユーザにタイムリーに利用していただくため、これまで静的に設定していた各デバイスも、動的に変更可能にする必要があります。これらを実現するためオーケストレーター（商用プロダクトをベースに不足している機能や追加機能を自社開発）を採用し、設定情報を一元管理しています。設定情報が一元化されることで、連携サービスもAPIを介してのシステム間での処理が可能になり、関連サービスも安全でスピーディーに利用を開始できるようになっています。

3.8 まとめ

IIJの30年の歴史をサービス基盤の観点から振り返りました。様々なIIJサービスを支えるサービスホスト基盤は、安定性と効率性のバランスを求めながら日々生まれてくる技術革新を見極め、時流に合わせて取り込みながら進化を続けています。今年で24年目を迎える「IIJ GIO」は、今もなおビジネスインフラに求められる多様なニーズに応えるため、サービスラインアップを拡充し続けています。近年では、AI技術をベースとしたデジタル社会基盤の需要が高まってきており、それを実現する超高密度AI計算基盤の提供に向けて取り組みを進めているところです。IIJでは現在開発中のサービスや基盤技術について、今後も市場のニーズに沿う形で皆様に提供し続けてまいります。

1. （注1）サービス開始当初の名称はiBPSとしていたが、2002年にIBPSへとリブランド。
2. （注2）当時はムーアの法則がよく効いていた時代でもあったのです。
3. （注3）ICUはCPU性能指標です。24ICU=6Core×2相当。

3. フォーカス・リサーチ（2） IIJとクラウドの変遷～30周年特別コンテンツ～

• 3.1 はじめに
• 3.2 1990年代：サービスホストの始まり
• 3.3 2000年代：サービスホスト個別構築からの脱却
• 3.4 2010年代～現在：次世代サービス基盤「Type-N」登場
• 3.5 2000年代：IaaS（Infrastructure as a Service）の先駆け
• 3.6 2010年代：本格的なクラウド時代へ
• 3.7 2020年代～現在：更なる進化を目指して
• 3.8 まとめ