クラウド&データセンター完全ガイド：特集
“IoTレディ”なデータセンターの要件を探る
IoTビジネスをドライブするデータセンター[Part2]
2016年6月28日 13:00
IoTビジネスをドライブするデータセンター
[Part2] Strategic Points
“IoTレディ”なデータセンターの要件を探る
データセンターは、コンピューティングモデルとユーザーニーズの遷移に応じて、これまでもさまざまな要件の変化に対応してきたが、今、新たにIoTへの対応にも迫られている。ここでは、IoTのメガトレンドがデータセンターの要件にどのような影響を及ぼすのかを整理しておきたい。
トレンド遷移で変化し続けるデータセンター
データセンターの役割や備えるべき機能は、時代に応じて段階的に変化してきた。比較的安定していたのは、メインフレームがITの主役だった時代で、この時にデータセンターに求められていたのは「絶対にトラブルを起こさない」信頼性・堅牢性であった。
その後、1990年代半ばよりインターネット時代に入ると、従来のデータセンターは「インターネットデータセンター」となり、広帯域インターネット接続が必須要件となった。
以降、社会全体でIT活用が拡大していく過程で、データセンターに収容されるIT機器の台数は増大を続け、排熱の効率的な管理や電力消費量の抑制など、高効率化に向かうようになっていった。
そして、2000年代半ばから2010年代にかけて、仮想化技術やクラウドコンピューティングが台頭してくると、コスト効率が従来以上に重要視されるようになった。とりわけ仮想化が広範に普及したことで、データセンターをまるごと仮想化する「Software-Defined Data Center（SDDC）」という発想も生まれた。このレベルに到達し、データセンターには、ユーザーの要求に応じて瞬時に新しいサービスを提供できるような俊敏性・柔軟性が要求されるようになってきている。
要件の“切り替わり”ではなく“積み上げ”
データセンターにとって悩ましいのは、こうしたトレンドの変化が、要件の“切り替わり”ではなく要件の“積み上げ”として作用する点だ。つまり、メインフレームからインターネットへと移り変わった際に、メインフレームならではの高度な信頼性や堅牢性が必要とされなくなったわけでなく、現実には従来どおりの信頼性・堅牢性を維持したうえで、インターネット接続性の強化も求められたわけだ（図1）。
その後の変化でも同様で、電力効率の向上やPUE値の低減が求められた際にも、そのためには他の面が軽視されるようなことはなかった。結果的に、データセンターは変化するというよりも進化し続けるほかないという状況に置かれている。こうした状況は、相対的に限られた大手事業者に有利で、小・中規模の事業者は求められる進化に追従するための投資で困難に直面するケースが多くなる傾向だ。
IoTに対応しやすいデータセンターとは
しかし、IoTの時代においては、上述したような状況が多少変化するかもしれない。もちろん、新たな要件に対応するために進化を続けなくてはならないことに変わりはないのだが、一方でクラウドベースの大規模事業者では対応しにくく、地方に拠点を置く小・中規模のデータセンターのほうがユーザーにとって都合がよいといった用途も出てくることが期待される。
クラウド化の急速な進展により、グローバルに事業を展開する大規模データセンター以外は生き残りが難しい――そんな予測が巷間で囁かれてきた。ところが、IoTの発展によって地理的な条件が新たに見直され、データの発生源に極力近い場所のデータセンターを活用することの価値が再評価される可能性がある。
IoTへの対応といっても、極端な言い方をすればデータセンターを利用するユーザー企業が実行しているアプリケーションレイヤの処理であり、インフラとなるデータセンターが従来とまったく異なるものに変わることにはならないだろう。とはいえ、「IoTで求められる処理をより実行しやすいデータセンター」という観点で考えることはできそうだ。以下、ネットワーク、ストレージ、地理的条件、分析環境といった各側面から考察してみる。
さまざまなネットワークへの対応
IoTでは、まずセンサーを通じたデータ収集が話題に上ることが多い。Part1でも触れた、電力会社でのスマートメーターが典型的な例となる。こうしたIoTに直接かかわるデータ収集の部分で、データセンターが関与する要素は実のところあまりない。データセンターがかかわってくるのは、収集されたデータを集約し、蓄積するところからになるだろう。
センサーからの情報を受け取る仕組みにはさまざまな実装が考えられる。各センサーがそれぞれ直接インターネットに接続するケースもあるし、独自のネットワークを通じて中継ノードなどに情報を送り、中継ノードでいったん集約した情報をまとめて送信するやり方もありうる。
その際、中継ノードとの接続も、独自ネットワークの場合もあればインターネットの場合もあるだろう。以前であれば、モバイルデバイスなどが通信を行う場合にデバイスに通信モジュールとしてPHSや携帯電話のネットワークと接続する機能を組み込んでおき、これらの公衆通信回線からさらにデータセンターへとデータを転送するやり方がよく採用された。
現在では、各種スマートデバイスがWi-Fiや3G/4Gネットワークを通じて直接インターネット接続を行う例が増えているが、インターネットに直接接続することが常に最良の手段だとはかぎらない。特にセキュリティ面では、強固な防御を施すのが困難なセンサーデバイスを直接インターネットに接続してしまうと情報漏洩などのトラブルにつながる危険もある。従来からデータセンターでは必要に応じて各種のIXや他のデータセンター、ネットワークキャリアとのピアリングによる接続や、ユーザー企業との直接専用線接続など、さまざまなネットワークとの接続を行ってきたが、今後は新たにIoT向けのセンサーネットワークとの接続に対応していく必要が生じる可能性がある（図2）。
こうした、いわゆる“ラストワンマイル”の問題は2000年頃、ブロードバンド接続の普及初期にも見られたものだ。地域の基幹となる電話局までは比較的容易に光ファイバー網を敷設できても、そこからユーザーの自宅までをどうやって接続するかという点に関しては、接続先の数が膨大になることから、コスト効率の高い解決策が見つからないと急速な進展が望めない。センサーに関しても同様で、配置するセンサー数が増えれば増えるだけ、そのセンサーからのデータをどうやって収集するかが問題になる。
個々のセンサーがそれぞれ独自にインターネット接続を確保する場合は、データセンターはインターネットとの接続さえ確保していればそれ以上の対応は必要ないことになる。だが、それが難しい場合はセンサーの設置場所に近いデータセンターほど有利になる可能性がある。
どのようなセンサーをどのくらいの数設置するのか、といった要件に依存する話だが、例えば比較的低コストなキャパシティネットワーク接続が可能なWi-Fiの場合、無線LAN帯域混雑の問題があるため、あまり多数のセンサーをカバーすることはできない。スーパーやコンビニの店舗などで活用されるPOSレジでは、店舗内に中継サーバーを設置していったんデータを集約し、一定間隔で本社に送信するというかたちをとっている例が多いようだ。こうした場合はあまり問題にならないが、電力のスマートメーターのようなケースでは、地域の世帯数が膨大になるうえ、電力の消費パターンを知ることで、ある程度住民の生活リズムを把握できる可能性が出てくることからセキュリティへの配慮も必要だ。
一時期話題に上った電灯線を介したデータ通信のような技術が利用できればよいが、そうでない場合は各戸に設置されたスマートメーターからどうやってデータを集めるかというのは難しい問題になる。データセンターのカバー領域外の問題も多いが、IoTの活用を考えるユーザー企業からの相談やリクエストに柔軟に対応できるような準備をしておくことが重要だ。
ストレージの要件
センサーに注目が集まりがちではあるが、IoTにおける本来の主役はデータである。データセンター側で直面する可能性の高い問題としては、ストレージ容量の継続的な増大であろう。
オフィスの情報化が進んで業務の大半がデジタル化されたが、文書ファイルのような、人間が直接作成・更新する類のデータに関しては、データ量は確実に増加しているものの爆発的というペースにはなっていない。一方で、デジタルカメラ／ビデオなどが生成する写真・映像データはあっという間に増大してストレージ容量を逼迫する。
IoTではセンサーの種類や数、データの生成頻度などによってそのサイズはまちまちだが、生成されたデータを継続的に保存するのであれば、その量は増加の一途をたどっていくことは間違いない。
用途やデータの性質によってその重要性は変わってくるが、必ずしもローデータをすべて長期間にわたり保存する要はない。とはいえ、どのくらいの量のデータをどのくらい期間保存するかは、ユーザー企業の意向によって決まる話であり、データセンターを運用管理する側としては、多様なリクエストに応じられる体制を整えておくことが求められる。
また、IoTでは、センサーの精度や信頼性にも依存する話ではあるものの、基幹業務系システムのような「データエラーは絶対起こらない」というレベルまでは求められないことが多い。例えば、温度センサーのようなデバイスでは、センサー自体がエラーを起こす可能性も想定されており、すべてのデータが完全に残っていることを必須条件にするようなシステムの組み方はしないことが一般的だろう。
Part1で述べたように、データセンター内部でも温度センサーを活用した空調制御の事例があるが、こうしたシステムの場合、おおよその温度分布が分かれば制御は可能であり、毎秒ごとの温度データが完全に揃っていないとダメという場面はまずない。温度センサー自体の動作不良で突発的に異常値を送信してくることもあれば、本来のデータ送信タイミングでデータを送信できない場合もあるだろう。こうした軽微なエラーをあらかじめ想定したうえで構築されたシステムであれば、逆に収集されたデータが永続的に完全に保存されなくても、ある程度のレベル以下に収まるのであればデータ喪失なども許容できるかもしれない。
こうしたIoTデータの特性を鑑みれば、そこで使われるストレージの選定方針も自ずと定まってくるわけで、最高レベルのデータ保護を実現するハイエンド向け製品よりも、むしろバイト単価が低廉で容量拡張が容易な製品のほうが適切なケースが多いだろう。
かなり大規模なIoTプロジェクトであれば、現在、クラウド環境向けに急速に市場を拡大しているスケールアウト型分散ストレージシステムも選定候補になりえる。データへのアクセス方法に応じて、オブジェクト型がよいのか、ファイル／ブロック単位型がよいのかは変わるが（図3）、いずれにしてもコストを抑えつつ、必要に応じて段階的に容量を追加していくようなニーズにはうまく適合するはずだ。
新世代のストレージ技術で言えば、SDS（Software Defined Storage）の活用も有効だろう。毎回一定のサイズのデータを定期的に繰り返し送出するタイプのセンサーを使っている場合、データ量の増加ペースは事前に予測可能であり、計画的な増強が可能だ。一方、データ量の増加ペースが一定でない場合も当然考えられ、この場合は状況に応じて柔軟に拡張できるストレージであることが求められる。
IoTに限らず、個々のデータ量は大きくないものの継続的にデータが流れてくるようなシステムでは、容量監視を怠ってデータ溢れを起こすような事態を起こさないよう警戒する必要がある。想定外のデータ増加に迅速に対応しなくてはならないのは当然だが、ストレージの容量増加に人手を要するようだとデータセンター側の運用管理コストが増大してしまうため、可能なかぎりの自動化を実現しておきたいところだ。そうした要件にはSDSの導入も1つの選択肢となりえよう。
地理的な広がりの配慮
IoTでは、センサー網がどのような規模になるかによってシステムのありようが大きく異なる。例えばビル管理システムのケースを想定してみよう。ビル内の各所に温度センサーや湿度センサー、エアフローセンサーといった環境条件計測に加え、煙探知機や火災検知器といった各種の災害対策、人感センサーやドアの開閉センサーなどによるセキュリティシステム、電力消費量などの各種のデータを総合して全体最適を実現するかたちだ（図4）。
利用されるセンサーの種類がまちまちで送られてくるデータの形式もさまざまで量も多いという条件から複雑なシステムになることは必然である。だが、一方でセンサーの設置場所は対象となるビルの敷地内で収まることがほとんどで、その意味ではごく局所的なシステムだと言える。このようなケースには、まずビル内にデータの集約と解析を行うサーバールームのような拠点を設けてしまうのが手っ取り早く、地理的な広がりについてはあまり心配する必要はないだろう。
次に、電気やガス、水道といった公益事業でIoTを活用するケースを考えてみる。この場合、ある一定地域の消費者全体を地理的にカバーする話になる。しかも、通常はある町内のみという規模ではなく、営業地域全体では複数の県にまたがる広がりがあり、各県ごと、市町村ごとに営業拠点を置くような階層的な組織構造になっていることだろう。こうした場合、収集したデータをいかにして集約し分析していくかを適切に設計することが重要だ。
各戸のサービス利用量を逐次収集するような場合、例えば毎分の使用量を計測してその結果を送信する、といった場合、毎分に発生する使用量のデータはせいぜい数バイト程度のサイズかもしれないが、これを1日分集め、さらにある地域の全世帯分を集め、という形で集約していくと総量としては相当規模に達することになる。小さなデータをこまめに転送している場合にはその通信に要する時間やコストはあまり気にならないかもしれないが、集約して膨大なデータ量になると、これを別の場所に転送するためにはどのくらいの時間を要するかを把握しておかないと大変なことになる。
日常的にも経験しているとおり、例えばテキストのみで書かれたメールを送信するのは一瞬だが、オンラインストレージなどにギガバイト（GB）クラスのデータを送信しようと思うと数十分程度かかるのと同じことが起こると思えばよい。この場合、データの移動に要する時間やコストをどう考えるかによって対応は変わるが、可能であればそもそも集約してサイズが大きくなったデータは極力移動しない方向でシステムを設計するのが賢明だ。
先の公益事業の例で言えば、各戸から収集したローデータは地域拠点の営業所で保存し、そのデータを解析して得られた集計結果だけを本社などに送信するという形である。当然、こうした階層は何段階にもなる可能性がある。例えば、市町村レベル、郡レベル、県レベル、営業エリア全域、といった具合だ。もちろんデータの内容やそれをどう解析して利用するのかといった詳細は個々に異なってくるわけだが、データセンターの視点で言えば、地域毎に小規模なデータセンターを分散しておいてそこにデータを集約／解析する一方、複数のデータセンターを仮想的に統合してデータも仮想的に統合し、単一のデータセットとして解析対象にできるような構造にするというアプローチが考えられる。
データは地理的に分散しているが、解析指示は中央から一括で行え、全データを対象とした解析を随時実行できるという環境だ。リモートリプリケーションなど遠隔地にデータをコピーする技術はさまざまある。こうした技術を活用してデータを中央にすべて集めるアプローチもあるが、データをコピーせずに済ませる方法も今後は重要になってくるのではないだろうか。
Hadoopをはじめとするデータ分析基盤
データセンターに、IoTデータが集約されるのは当然として、その後のデータ分析処理の実行基盤としての役割もある。データ分析プラットフォームにはさまざまあるが、昨今企業から注目を集めているのは、やはりオープンソースの高速分散処理フレームワークの「Apache Hadoop」だろう。
Hadoopは分散ストレージとセットになっており、データの蓄積と分析を同じ場所で実行することでデータの移動を避けるアプローチを採っている。そのため、地理的に分散する可能性があるIoTで利用する解析プラットフォームとしても有効と言える。
また、コモディティサーバーをノードとして利用し、クラスタを構成することで蓄積可能なデータ量と分析処理能力をスケールアウト型で拡張できる点も、IoTのようなアプリケーションに向く。もともとはビッグデータの文脈で注目されたHadoopだが、IoTをデータの入口、ビッグデータをデータの出口（後処理）と位置づけるなら、IoT対応の一環としてビッグデータ処理への対応も含まれることに違和感はない。
Hadoopへの対応はすでにさまざまなクラウドサービス事業者によって開始されている。例えば、Hadoopディストリビューションの提供を行う米クラウデラ（Cloudera）がマイクロソフトと協業し、「Cloudera Enterprise」をMicrosoft Azure認定ソリューションとして利用可能にする計画を発表している。また、国内でもIIJやNTTコムウェアなどの事業者がHadoopをクラウドサービスとして提供することを発表済みだ。
また、事業者以外でも最近のトピックとしては、独SAPが2015年5月、「SAP HANA Cloud Platform for the Internet of Things」の提供開始を発表している。IoTのためのインフラを提供するサービスと位置づけられており、IoTのためのプラットフォームがまるごとクラウドサービスとして提供されるようになるものと期待できる。
Hadoopを活用する環境の構築には相応のノウハウが必要なので、IoTやビッグデータ処理に関心を持つ企業であっても、自身でHadoop環境の構築からすべてを行うのは敷居が高いのも事実だ。そこで、データセンターのサービスメニューとしてHadoopが提供されれば関心を持つというユーザーは多いだろう。
DC自身のIoTソリューション提供力が問われる
クラウドの広範な普及によって、従来型の「所有するIT」から「必要な時に必要な分だけ利用するIT」へとユーザー企業の意識が切り替わりつつある。このため、データセンターもユーザー企業のニーズに対応し、サービスメニューを拡充させていくことが必要だろう。IoTに関しては、センサーネットワークの構築からデータの収集／整理、後処理としての分析まで、さまざまな要素の組み合わせで構成される複雑なシステムとなるため、独力でシステムを完成させられるユーザー企業はそう多くはないはずだ。
従来はシステムインテグレーター（SIer）がこうしたニーズに応えていたわけだが、IoTともなればこれまで述べてきたとおりデータセンター側でも対応すべき要素があり、すべてをSIer任せ、データセンターはSIerにラックスペースを提供するだけ、という取り組みでは限界があるのも確かだ。データセンター自身のソリューション提供力を高めていくと共に、SIerとの連携をこれまで以上に密にし、共同でソリューションを構築／提案できる体制を整えていくことも、広い意味ではデータセンターのIoT対応という範疇に含まれてくるのではないだろうか。