少し間が空いてしまいましたが、9/9に開催された勉強会「第4回 クラウドごった煮」に参加してきました。同僚の喜多がノリノリで発表してくれたので、私は二言三言のコメントだけでしたが、なかなかシビアな会で楽しかったですよ。

その時の発表の模様(ustreamの録画)と、プレゼン資料はGIOろぐで公開しているのでそちらをご覧下さい。当日お話ししきれなかった件についても責任者の小川から補足が入っています。

GIOの技術の系譜

さて、喜多さんの発表の中で「IIJグループは昔からクラウド的なサービスを展開していた」という説明がありました。

クラウドごった煮#4 喜多さんプレゼンから
クラウドごった煮#4 喜多さんプレゼンから

このスライドで紹介しているとおり、IIJ GIOは何もないところから生まれたサービスではなく、それまでに積み重ねられた経験や想いがあって作り上げられたサービスなのです。今回のblogではGIOに繋がる二つのエピソードを紹介しようと思います。

IIJサービス設備:NHN

IIJはインターネット接続サービスから始まった会社ですが、初期の頃からサービスの一環として、お客様向けのメールサーバやWebサーバの提供を行ってきました。サービスをご利用頂くお客様が増え、それに連れて利用するサーバも増えて行きます。新しいサービスを開始する時はもちろん、サービスを提供開始した後も、機材の追加やパフォーマンス改善の為の構成変更など、サーバ関係の作業は頻繁に発生していました。

多くのお客様を収容するサービスでは、システム全体として非常にシビアな性能が要求されるため、サービス毎に最適な構成を検討し、機材を調達していました。このため、故障対応のためや急な増設のための予備の機材もサービス毎に個別にもつ必要があり、データセンターやオフィスに様々な予備機材が積み上がるような状態になっていました。

また、これらの機材の運用は直接IIJのスタッフが行っており、構成変更や故障時の機器交換のためにいちいちデータセンターに出かけていって作業を行っていました。場合によっては深夜や休日でも、緊急の機器交換のためにデータセンターに駆けつけることもあり、スタッフの運用負荷は低くありません。このような運用を行うために、駆けつけがしやすいようにと交通の便の良い都内・東京近郊のデータセンターを使っていたのですが、サービスの規模が大きくなると一つのデータセンターではスペースが足りなくなり、複数のデータセンターに機材を分散せざるを得なくなっていました。データセンター分散は、障害対策という点で良いところもあります。

結局、最盛期には200ラック以上に渡って合計数千台のサーバを運用するに至ったわけですが、このような状況では機材のやりくりも困難ですし、何より運用上の人的負荷がとても大きくなってしまいました。また、IIJのお客様が増えるにつれデータセンターの需要も高まり、東京近郊の立地の良いデータセンターはIIJのサービス設備で利用するよりお客様専用ラックとして提供したいと言われるようになりました。

NHN化による利点
NHN化による利点

そこで、IIJのサーバ運用チームは標準化とリモートからのメンテナンス性を向上させるべく、新しいインフラの構築に着手しました。これがNHN(Next Host Network)と呼んでいる構成です。

NHNでは、標準化されたサーバをあらかじめ大量に設置しておくサーバプールという考え方が導入されています。新しいサービスを立ち上げる時や、既存サービスの増強を行う場合、このサーバプールの中から必要な台数のサーバを確保します。これらのサーバは遠隔から管理できるようになっており、OSのインストール、ネットワークの切り替え(VLAN)を行うために現地に出向く必要はありません。リモートからの操作だけで、従来個別に設置・配線していたような構成を作ることができるのです。

また、主なサーバはディスクレス化されています。この種のインフラの中で最も障害が発生しやすいのはサーバですが、仮にサーバが壊れた場合でも現地に駆けつけて筐体を交換するのではなく、リモートからの操作でストレージを別の筐体からマウントするように設定を変更し、再起動を行います。こうすることによって、サーバのハードウェア障害の場合でも速やかに復旧をさせることが可能になりました。1

このように、リモートからの管理性を強化した結果、東京近郊のデータセンターではなく、少々駆けつけに時間がかかるような遠隔地にあるデータセンターに機材を設置したとしても、十分な速さで障害対策できる見込みがついたのです。

NHNは2008年度から順次IIJサービスに導入され、従来個別に設置されていたサーバなどの機材を順次統合しています。当初は「標準化されたサーバではサービスに適した性能が得られないのではないか」という声が社内からもあがりました。しかし、だからといっていつまでもインフラ効率化の問題に手をこまねいているわけにはいかないと、サービス開発部門でもNHNの特性を理解しながらアプリケーションの開発を行うようになりました。このようにして、IIJサービスのサーバインフラの大きな効率化が達成できたのです。

インテグレーション案件:リソースオンデマンド

典型的なECサイト
典型的なECサイト

さて、もう一つ別の話を紹介します。IIJグループのIIJテクノロジー(2010年にIIJと合併)は、システムインテグレーション事業を中心に手がけていました。インターネットバブルも華やかなりし1990年代後半、世の中はECサイトが大流行し、IIJテクノロジーもいくつもの案件を手がけることになりましたが、この頃は商用サイトで使われる実績ある構成にはそれほどバリエーションがなく、手がけるシステムの多くがほとんど同じ構成となっていました。

しかし、一方でインフラを構成する機材の調達は案件毎に個別に対応していました。インテグレーション案件では、どのような機材を導入すべきかはIIJテクノロジーからご提案いたしますが、最終的に機材はお客様の資産としてご購入頂くというのが一般的です。個別に調達を行う場合、当然毎回納期の調整に始まる一連の手間がかかりますし、最終的にお客様にお買い上げ頂くと言うことは「資産償却」や「リース化」といったお客様側での経理上の処理も必要になります。

また、システムには負荷の高い時と低い時があります。負荷の高い時にだけそれに合わせて追加の機材を導入できれば理想的ですが、「購入」という形態ではそのような機動的な動きは困難です。結局ピーク時の最も負荷の高い時に合わせて調達を行わなければならず、負荷の低い時期には有効活用されない機材ができてしまい、コスト上も、データセンターの専有スペースという点でも無駄を感じる事例が少なくありませんでした。

リソースオンデマンドによる利点
リソースオンデマンドによる利点

そこで、IIJテクノロジーでは2000年に「リソースオンデマンド」と名付けたサービスを開始しました。これは、典型的な構成のシステムで使われる機器類をIIJテクノロジーがあらかじめ調達しておき、お客様には必要な時に必要な台数の機材をお貸しするというものです。これにより、お客様にいちいちサーバを「購入」して頂く必要がなくなりました。必要な規模のサーバを月額いくらで「借りる」という事ができるようになったのです。もちろん納期に悩まされることもありません。

また、「借りる」という形態であれば、負荷が高いと思われる時期だけ追加でサーバを投入することも容易になります。特にリソースオンデマンドでは、常に稼働している「Static Server」と、Static Serverをクローンして投入する事を想定した「Dynamic Server」という考え方を取り入れていました。特に負荷が高いことが予測される場合、事前にIIJテクノロジーに依頼を頂ければ、Static Serverを元に追加のDynamic Serverを用意して、処理能力を拡張することができます。もちろんDynamic Serverは期間限定で利用し、負荷が下がれば解約することができます。これで余計なコストも発生しません。

また、このようにサーバ等が標準化されることで、システムの監視や運用手順の標準化もやりやすくなります。監視システムの共有化、テンプレート化などを行う事で、運用フェーズに移行する時の負担を軽くすることができるのです。

ちなみに、このリソースオンデマンドサービスは、当初はECサイトでの利用を想定したのですが、ITバブルの崩壊に伴いECサイトの需要が激減してしまいました。とはいえ、リソースオンデマンドの考え方自体はECサイトだけでなく、他のシステムでも適用できます。もともとECサイト向けに考えていた構成でも、CAFIS2や、各社の物流・基幹系との連動のために、閉域網を使った外部システムとの連携は行っていたのですが、この構成をより拡張することで、今まで企業のオフィスにあった基幹系システム系をデータセンターに追い出し、オフィスとの間を閉域網で繋ぐという発展が考えられ、以後エンタープライズ(基幹系)向けにもリソースオンデマンドサービスを提案していくことになりました。

GIOへの流れ

ここまで二つのエピソードを紹介しましたが、これらはいずれも「クラウド」という単語を意識して行ったものではありません。しかし、ご紹介したとおりそこで実行されたものは、今となってみればとても「クラウド」的な取り組みでした。

ディスクレスサーバとVLANを組み合わせたNHNの構成は、いまどきのIaaSで使われる構成そのものです。実際、GIOで提供されている仮想サーバは、NHNの構成を元にハイパーバイザを組み合わせて仮想サーバの性能のクラス分けと権限分離を行ったものがベースになっています。また、リソースオンデマンドにおける「購入ではなく、借りる」という考え方は、その後「クラウド」として取り上げられた考え方そのものです。さらに、リソースオンデマンドで多数のシステムを構築した経験から、クラウドを使ったシステムの構築において、閉域網との接続が重要であると認識しています。それ故にIIJ GIOでは閉域網との接続が柔軟に行えるような仕組みを用意することにしたのです。

どうしても「クラウド」という単語が先行してしまいがちですが、あちこちで言われているとおり、クラウドで実現されている技術や考え方には以前から存在したものがいくつもあります。IIJでも2010年から「IIJ GIO」というブランドを打ち出していますが、その中身は2010年から考え出した物ではなく、それ以前から考え、普通に実行してきた物だと言うことを、知って頂きたいと思いました。

そんな気持ちを秘めてお話ししたのが、冒頭に紹介したクラウドごった煮のプレゼンだったのです。今回のは持ち時間5分という厳しい制限があったため、溢れる想いが多すぎて最後まではお伝えできませんでしたが……その一部をこの記事で感じて頂ければ幸いです。

関連コンテンツ


  1. その代わり、ストレージについては従来より信頼性の高い物を使用しています []
  2. クレジットカード決済システム []

Comments are closed.