IIJ GIO 松江データセンターパーク見学ツアーに行ってきた（３） GIO編
IIJ GIOの歴史
90年代後半よりIIJではデータセンターサービスを提供していた
次第にJavaやASPとDBの組み合わせが実用化し、動的なWebサイトが増加してきた
動的サイトでオンライン決済が出来るようになり、ECサイトが激増した
このECサイトは、どこも殆ど同じシステム構成で良かった為、同じ物を繰り返し作るのは無駄が多い
予めハードウェアはIIJ側で用意してしまい、システムの共通化出来る部分をサービスとして提供する事を考えた→リソースオンデマンドサービス「IBPS」
※当時の提供会社はIIJの子会社であるIIJ-Tech（2010年吸収合併）
自動化出来ている部分は今のクラウドより少なく、仮想化が流行る前なので物理サーバでの提供だが、コンセプトは今のIaaSに近い
その後、時代の流れでターゲットをECサイトから企業内システムに移していった
閉域網への接続、仮想化対応、自動化対応などを進めて行き、企業内にサーバルームを持つ代わりに使えるようなサービスへ進化させていった
IIJ GIOはこのサービスを発展させ、クラウドサービスとして提供するもの
だが、「クラウド」である事にこだわっているのではなく、あくまで、すぐに必要なだけのリソースを顧客へ提供する仕組みを実現するのが目的
サービス内容
Iaas/HaaS
PaaS
- 仮想デスクトップ（Cytrix, Microsoft）
- Ruby on Railsがクラウドで動くMOGOKのベータ版を今秋提供予定
聞いてみた
後日、疑問に思ったことをメールで質問してみた。
Q.
IIJ GIOはIBPSから進化して来ているという経緯もあり「企業内システム」として使われる割合が高いと思うが、そういう前提がある事でAmazonやGoogleなどの他のクラウドサービスとクラウド内部のシステム構成や必要な要素技術が異なっている事はあるか。
A.
他のサービスのシステム構成はわかりませんので、コメントは差し控えますが、IIJ GIOが「企業内システム」で多く御採用されている我々なりの分析をコメントします。
一番大きな違いはプライベートIPアドレス空間の持ち込みが自由にできるということかと思います。
これは主に企業内でのセキュリティの考え方への適合と移行作業の容易性のためにIBPS時代からの設計思想となっています。
企業内(特に管理がしっかりしている大企業)ではネットワークセグメントをセキュリティゾーンで分離する傾向があります。もちろん、最近では勝手グローバルIPアドレスを使っているお客様はほとんどいない状況です。
そのため、企業のネットワーク管理者の方々は、プライベートIPアドレス空間の中でこのセグメントはグローバルIPアドレス空間で外界にさらされているセキュリティゾーンであるとか、このセグメントはDMZのセキュリティゾーンとか、このセグメントは一般社員が通常の仕事で直接アクセスできるセキュリティゾーンとか、場合によっては機密情報を格納するDBを格納するセキュリティゾーンとかを分けたりということをされています。
そのような社内ネットワーク環境のアドレス計画がある中でシステムが動いている訳です。
過去の経緯で昔作った業務用ソフトウェアの中にはIPアドレスがハードコーディングされているようなコードが動いていることがあったりします。
プライベートIPアドレスを持ちこめるおかげでIPアドレスを変更せずにオンプレミスからクラウド環境へシステムを移行できるため、お客様は移行作業費の低減メリットを享受できるのです。
A.
誤解を与えるといけませんので、最初に宣言しておきますが、IIJ GIOは1つのシステムで大規模なサーバを扱え、また広帯域のインターネットバックボーンに直結できるスケールするサービスであります。
その上でご質問にお答えしますと、確かに「企業内システム」ですとスケールとあまり関係ないシステムが多いとは思います。
しかし、一部のシステムに関してはスケール(増やすも減らすも)も重要な課題の1つです。
例えば以下のようなケースが該当します。
- M&Aが激しい業界の場合、急に従業員数が増えることがあるが、ITを存続させる会社側のシステムがその変化に対応出来る必要がある。
- 経理システムや営業管理システムは毎月の締めのタイミングで負荷がぐっと上がるが、それ以外の負荷は小さい
- 財務システムは四半期に一度強烈な稼働を行うがそれ以外はあまり負荷はない
一方で、時間単位でも負荷が変わるものがあります。
例えば、
- 勤退管理システムだと、通常朝と夕方しか負荷はかかりません。
ところが、時間単位の課金まで社内システムに対してお客様が求めているかというと決してニーズは多くなく、要はきちんと動いて安ければよいという事や予算編成上毎月の支払が固定でわかった方がよいということがありますので、時間課金のニーズはサービス開始当初思っていた程多くは聞かれないというのが現状です。
しかし、我々は「クラウド」という言葉にとらわれず、お客様のニーズを出来るだけ広範に拾えるサービスの実現を考えていますので、今後も機能の拡張やサービスの改善を続けていきたいと思います。
感想
個人的には、クラウドというと「ユーザのWebアプリケーション向けにスケールするインフラを貸し出すサービス」というイメージが強かった。
勿論様々な用途に利用されている事も認識してはいたが、例えばWeb系向けとエンタープライズ向けではニーズがまるっきり違うのではないか、どんな用途が求められていても全て「クラウド」と一緒くたにして呼んでいいものだろうか、と若干違和感を持っていた。
（そういう単語だと言われればそうかもしれないし、NISTのクラウドの定義に照らせば正しいのかもしれないが）
今回、元々「クラウド」が出てくる前から顧客のニーズに対応するために提供していたリソースオンデマンドサービス（IBPS）を発展させて出来たのがGIOで、「クラウド」である事にこだわっているのではなく、あくまで、すぐに必要なだけのリソースを顧客へ提供する仕組みを実現するのが目的、と聞いてしっくりきた。
「IIJ GIOコンポーネント」では、サーバとして物理サーバが選べ、企業内のプライベートIPなネットワークと繋がり、新規契約・増設はIIJの方々と打ち合わせを行って、見積もりを貰う事が前提である。
これは、多分あまり「クラウドっぽくない」。
が、ユーザのニーズを満たす為に敢えてそうする必要がある。
社内システムをGIOへ移行する為には、WebUIやAPIでノードを即時追加出来る事よりも、企業内のプライベートIPなネットワークにきちんと繋がったり、性能の高い物理サーバが選べたり出来る事の方がより重要なのだろう。
しかし、クラウドとしての仕組みが全くニーズに合っていないという事ではなくて、「すぐに」「必要なだけ」リソースを提供するのに最適な形が、現在ではクラウドという形式になっている、という事ではないかと思う。
また、クラウドの形式に則る事で、企業内システムとして使っているユーザが多くても、同じクラウドシステムの上で「クラウドらしい使い方」を提供する事も出来、別々のシステム／サービスとして分ける必要がない。恐らくこの方がリソースの利用効率も高そうだ。
