クラウド&データセンター完全ガイド：特集
高効率ITインフラを支えるテクノロジー
クラウド大競争時代「日本のデータセンターの生きる道」[Part3]
2016年10月21日 18:00
クラウド大競争時代「日本のデータセンターの生きる道」
[Part3] Infrastructure Technology
高効率ITインフラを支えるテクノロジー
データセンターファシリティの進化は一種の踊り場状況に達しており、ファシリティ側の取り組みだけでは大幅な効率向上や機能強化は望みにくい状況にある。一方、IT側の進化は止まらず、CPU／サーバーの電力効率の向上からソフトウェアによる自動化で運用効率を向上する動きまで、さまざまな取り組みが継続中だ。
クラウドサービスの発展に伴う変化
クラウドコンピューティングサービスは、今や完全にITの主流に躍り出たといって過言ではないだろう。当初はレンタルサーバーの新しい形態の体で、アマゾン ウェブ サービスなどからIaaSの提供が始まり、その後は上位層のSaaSやPaaSと共に普及が進んでいる。
コンシューマー市場でのソフトウェアの利用は、そのプラットフォームがPCからスマートフォンやタブレットへと急速にシフトしつつある。その際スマートフォンアプリではアプリ単体でローカルに機能を実装している例はむしろ少なく、たいていはクラウドサービスとしてのインターネット経由での提供となっている。このように、クラウドが至る所で活用されているのが現在である。
当然、こうしたサービスを支えるデータセンターインフラ側でもトラフィックの相手側がPCからモバイルキャリア中心に切り替わりつつあるなど、「モバイルファースト」へのシフトは如実に表われてきているようだ。こうしたトレンドは、今後、データセンターがピアリング先を選定する際の判断基準を変えることにもつながっていくかもしれない。
国内データセンターに対するユーザーニーズ
クラウドサービスの発展に関連して、海外クラウドベンダー／事業者の日本市場参入の動きも顕著になってきた。例えば、マイクロソフトは2014年2月、同社のIaaSプラットフォームであるMicrosoft Azureのためのデータセンターを国内に開設した。当初から東日本と西日本の2拠点体制で相互バックアップを可能にするなどの高信頼性を意識した構成を採ったことは、国内ユーザーのデータセンターニーズを的確に掴んだ結果だろう。そして、2014年秋にはAzureに加えて、SaaSとして提供しているオフィスアプリケーション「Offi ce 365」などを、国内データセンターを拠点にサービスを提供することが発表された。
こうした人気のあるクラウドサービスが、従来はシンガポールなどの海外データセンターが拠点だったのが、今後は日本国内のデータセンターから利用できるようになったわけだ。この結果、「データを国外データセンターに置くことはできない」といったルールを定めている国内企業などもこうしたクラウドサービスを利用できるようになる。
クラウドサービスは、当然のことながら基本的には地理的な条件に依存せず、インターネット接続さえ確保されれば世界中どこからでも利用可能という点が大きなメリットである。そのため、グローバルに展開する大手事業者は運用コストを引き下げるために都合のよい立地を世界中から選定して大規模なデータセンターを建設する取り組みを行ってきた。例えば、寒冷な気候を生かした自然冷却を活用するために、北欧にデータセンターを置くといった具合だ。
こうした手法で運用管理などのランニングコストを引き下げ、それをユーザーの利用価格に反映させる海外大手の攻勢に、国内データセンター事業者はとうてい太刀打ちできない、という見方もある。
だが、先のAzure日本データセンターの開設は、グローバルで効率を追求するだけではすべてのユーザーニーズをカバーしきれないことの証左とも言える。国内データセンターでのサービス提供が行われないとサービスそのものを利用しないというユーザー企業が実際にどれほどいるかは完全に把握しかねるが、マイクロソフトによれば、国内にデータセンターを建設したことで契約数の伸びが向上したとのことで、国内データセンターを期待するユーザーは相当数存在すると思われる。国内の事業者は、こうしたニーズを逃さずに対応していくことが今後ますます重要となるだろう。
“Software-Defined”のトレンド
クラウド以外のテクノロジーに着目すると、昨今は、SDN（Software-Defined Networking）、SDDC（Software-Defined Data Center）、SDS（Software-Defined Storage）と「SDx」流行りの状況が続いている。もはや何にでもSDを付ける風潮ではあるが、運用効率の向上という面で着実に成果を上げつつあることも確かである。
もともとは、サーバー仮想化が進展したことで、システムの構成変更に要する時間が劇的に短縮されたことが発端だ。仮想サーバーであれば、新しいサーバーを準備するのにわずか数分しかからないとなると、ネットワークやストレージの準備のために「2営業日をいただきます」とは言いにくくなる。また、仮想サーバーの俊敏な特性を生かすなら、ネットワークやストレージ、極論すればデータセンター全体がそのスピードに追従できるよう再構成されなくてはならない。これがSDDCの基本的な考え方だ（図1）。
ただし、SDDCというコンセプト自体には「どのようなやり方でそれを実現するか」という点までは含まれておらず、現実には要素技術ごとにバラバラに開発が進んでいる。サーバー仮想化はすでにほぼ完成し、現在は、ネットワーク（SDN）とストレージ（SDS）についての対応が進み、同時に、これら全体を統合する運用管理インタフェースとして「クラウドオーケストレーター」などと呼ばれる管理ソフトウェアが完成度を高めつつある状況だ（後述）。
SDNの進展
SDNに関しては、早期から研究が進められていたOpenFlowに加え、仮想サーバーとの組み合わせで相性のよいオーバーレイ型ネットワーク仮想化が急速に発展してきている。現状では、ある程度の規模のITインフラを運用する企業やデータセンター事業者のラックレベルでのネットワーク構築にはオーバーレイ型が使いやすく、バックボーン接続レベルのネットワークではOpenFlowがメリットを生かしやすい、といった形で棲み分けがなされるようになってきている。
例えば、さくらインターネットではOpenFlowスイッチの機能を用いてDDoS攻撃のパケットを振り分けてLAN内への浸入を防ぐ、一種のインテリジェント・パケットフィルタとして活用していることを公表している（図2）。市販のネットワークスイッチでOpenFlow対応製品が増えてきており、数年後にはデータセンターに採用されるスイッチは基本的にOpenFlow対応が当たり前という状況が予想される。機材の置き換えが完了し、ファシリティ内のネットワーク全体が完全にOpenFlow対応機器のみで構成されるようになれば、それを活用するさまざまな取り組みが行われることになると思われる、だが現状ではまだデータセンター事業者の間でOpenFlowの活用に向けた顕著な動きは見えておらず、一部の先進的な事業者が検証を行っている段階だ。
一方、オーバーレイ型ネットワーク仮想化では、トンネリングを活用して1つの物理ネットワーク上に複数の論理ネットワークを重畳（オーバーレイ）していく。従来は拠点間接続に使われていたVPNをノード間接続に使うとの見方もできる。仮想サーバー中心でサービスを構成している場合、ネットワークもオーバーレイ型仮想化を採用しておけば、新規のサーバーノードの追加や既存のネットワークの構成変更などが迅速に行える。
データセンター事業者の内部利用として、運用管理の効率化／コスト削減のために活用することも可能だが、ライセンス形態によっては必ずしもコスト削減にはつながらないという指摘もある。オーバーレイ型ネットワーク仮想化では、従来のネットワーク機器のような「一度購入すればあとは使い放題」という考え方ではなく、サーバーノード数に応じた利用ライセンスの形で課金されることが多く、膨大な数のサーバーを運用する事業者ではライセンスコストが膨れ上がってしまう懸念があるためだ。
このほか、オーバーレイ型ネットワーク仮想化をユーザーのセルフサービス環境のための基盤技術として活用することも始まっている。これはIaaSなどで顕著な例だが、新規に仮想サーバーを追加し、ネットワークの構成を変更して使い始めるまでの環境構築作業をユーザーがすべて自身でやってしまいたいというニーズがあるためだ。従来のレンタルサーバーの考え方なら、受け付けから提供開始まで数営業日だったのが、セルフサービス化することで、数分でシステムの稼働を開始できる。
こうしてクラウド時代ならではのスピード感で、こうしたサービス提供を求めるユーザーも増えてきている。その対応は事実上、SDNの仕組みなくしては無理である。事業者の中には、こうしたセルフサービス型で提供する仮想サーバー環境に限定してオーバーレイ型ネットワーク仮想化を導入する取り組みが始まっており、今後の普及が目される。
OpenStackがクラウドオーケストレーターの事実標準に
SDN関連のソフトウェアの現状についても触れておこう。一時期「クラウドOS」などと呼ばれていたIaaSの管理プラットフォームは、先に述べたように今ではクラウドオーケストレーターという、より動作が分かりやすい具体的な名称に切り替わりつつある。上述のOpenStackは、ITベンダーの広範な支持を集め、クラウドオーケストレーターのデファクトスタンダードと言える地位を確立しつつある。
クラウドオーケストレーターはもともと、サーバー仮想化プラットフォームに対して指示を送ることで仮想サーバーの運用管理を一元的に実行する目的から開発が始まっている。そのため、現時点において仮想サーバーのハンドリングに関してはほぼ満足できる完成度に達している一方、仮想ネットワークへの対応はまだ十分とは言えないレベルにとどまるようだ。
この点では、SDN側でOpenStackに対応する動きが顕著であり、SDNプラットフォーム側にOpenStackとの連携を実現するためのAPIを準備することでOpenStackを介した一元管理が可能になるという形にまとまりつつあるようだ。仮想サーバーの運用に関しては、VMwareやKVMなどで構築された仮想化インフラをOpenStackで管理する形が主流だが、SDNに関しても同様に、SDN環境を別途構築したうえで、その運用管理をOpenStackで行うという形が予想される。
なお、初期にはCloudStackも有力視され、特にアジア圏のデータセンター事業者を重視して手厚い対応がなされたこともあり、国内事業者での採用機運が高まったが、現在ではOpenStackに押されている（表1）。機能面では大差はなく、使い勝手に関しては一長一短という感じで明確な優劣が付いているわけではないが、主要なサーバーおよびネットワーク機器ベンダーがこぞってOpenStack対応を進めている状況だ。
また、クラウド環境のためのセルフサービスインタフェースとしてデータセンター／クラウド事業者が独自ツールを開発して運用する例も初期には見られたが、この動きは現時点では完全に過去のものになっている。セルフサービスクラウドの提供で先行した事業者は、当時適切なツールが存在していなかったこともあって自社開発せざるをえなかったのだが、こうした事業者も現在ではおおむねOpenStack採用に切り替え始めている。自社開発ツールの場合、利用製品ごとに都度、動作検証を行う必要を考えれば、OpenStackそのままでは自社のニーズに合わないという場合でも、OpenStackをベースにカスタマイズを行う方針が望ましいだろう。
DCIMによる運用管理の統合化
データセンターの運用管理が高度化するにつれ、ソフトウェアによる支援も発展してきた。DCIM（Data Center Infrastructure Management）ソフトウェア製品分野では、データセンターの運用にかかわるさまざまな情報を収集し、統合管理できる仕組みが整いつつある。
サーバーを対象とした統合監視ツールは、CPUやメモリの使用率やストレージの残り容量、筐体内温度センサー情報などを取得し、安定稼働に寄与する。そこにSNMP経由でのネットワーク機器などのモニタリング情報も加えて、より広範な運用管理を可能にする製品もある。DCIMは、このように監視対象をIT機器からデータセンターファシリティ側にまで拡張していく取り組みだ（画面1）。
機器搭載センサーと連携した運用監視・管理
DCIMから得られる典型的なメリットとしては、例えば、サーバーのCPU温度に基づいてマシンルームの空調機の運転制御を行うといったことが挙げられる。
また、CPUの演算負荷が高まると消費電力が増大し、電力が熱に変わることで温度が上昇するというプロセスが進行するが、冷却制御を温度センサーからの情報に基づいて実行すると、どうしてもタイムラグが生じる。そこで、CPUの電力消費量増大を検知し「この後CPUの温度が上昇する」という情報に基づいて冷房を強めることができれば、必要なタイミングで必要なだけきめ細かく冷房できる可能性がでてくる。
現状ではタイムラグとそれに基づくオーバーシュートがあり、どうしても過剰に対応する傾向がある。冷房機の運転を強めてから特定のサーバーの吸気温が低下するまでにも相当なタイムラグがあり、さらに一度上昇したサーバー筐体内の温度は、CPUの負荷が減少して発熱量が減少した後、しばらくしてから下がり始めることになる。このようなラグの影響を最小化し、適切なタイミングで適切な制御を行うのに、現状ではまったく情報が不足しているが、今後、各社のさまざまな機器の情報が公開されることで、それらを統合して適切に制御する新たなソリューションの登場が期待できる。
プロセッサーベンダーのインテルでは、こうした将来を見越してCPUやマザーボードにさまざまなセンサーを埋め込み、こうした情報を外部に出力可能とすると同時に、データフォーマットやデータにアクセスするためのAPIの共通化に向けた取り組みを開始している（画面2）。運用監視ツール側での適切な対応のためには、ある程度の標準化が行われないと対応が煩雑になり、結果として普及が遅れることになるためだ。極端な話、IAサーバーでもCPUがインテル製かAMD製かで情報取得の手法も得られるデータの形式も内容もまるでバラバラということでは運用管理ツールを作る負担が無駄に重くなってしまう。
データセンターがまるごと巨大コンピューターに
DCIMの取り組みは最終的に、データセンターファシリティとIT機器とを統合的に管理するための体制の確立というところに帰着する。従来は、データセンターは器としての機能、品質を高めつつ、中に納められるIT機器については注文を付けないというスタンスであった。それが無駄を省いてコストパフォーマンスよく高効率を目指すという今のユーザーニーズに対応するには、中身と器がそれぞれバラバラという状況で発生する無駄を無視できない。相互の稼働状況をとりまとめ、統合的な制御を可能にするところから着手し、究極には、IT機器とデータセンターを設計レベルで適合させるレベルまで到達する可能性がある。例えば、データセンター側で環境制御を適切に行うことができれば、サーバー内部にファンを内蔵する必要すらなくなり、その分サーバーの消費電力量を削減できるといったことが実現できるかもしれない。
あるいは、データセンターのマシンルーム／ラックの設計を一から見直すことで、より冷却しやすいサーバー筐体デザインが登場するかもしれない。データセンターを建物として建設し、内部に部屋を作ってそこにIT機器を設置するという従来のやり方から、将来的には、データセンターをまるごと巨大なサーバー筐体として設計し、内部にCPUやメモリを直接並べていくような形にまで至る可能性もないとは言えないだろう。
「データセンター規模の巨大コンピューター」というコンセプト自体はすでに運用面では現実のものとなりつつある。この先の進化によっては、ハードウェア的な視点においてもその言葉どおりの存在としてデータセンター全体がコンピューターになるかもしれない。クラウドが語られ始めた黎明期には、こうした将来を見据えたビジョナリーが「世界には数台のコンピューターがあればよくなる」といった予言も聞かれたが、現在は多少違う様相を見せてもいる。
それは、日本国内で顕著に見られるとおり、クラウドを実現するファシリティが地理的にどこに存在するのかを気にするユーザーが一定数存在するという問題だ。過渡期に特有の保守的な心情と見なすことができるかもしれないが、今後もずっと継続する深刻な要件である可能性も否定できない。グローバルでの競争に備えた規模を追求する一方、特定の地理的エリアに根ざしたサービスを提供する体制を整えるという、今後のデータセンターに求められる新たな要件が明らかになってきているのが現状だと言えよう。