【環境クラウドサービスの実証実験に係る現状と課題】
NTTコミュニケーションズ株式会社真田氏より資料WG環6－1について説明。
三井情報株式会社菊地氏より資料WG環6－2及び6－3について説明。
○ モデルBについて、既存のシステムをインターネットにつないだ瞬間にハッキングされて隔離しなければならないようなケースはあったのか。
○ 実証実験では、そのようなネットワークセキュリティ上の懸念から既設のネットワークを活用できないケースがあったため、無線カード等を利用してインターネットへ接続することとした。
○ 環境分野のファシリティー業界は、ICT業界とは違ったモデルであることをしっかりガイドラインに出しておかないといけない。インターネットに直接つなげずに安全性が確保されたリンクを経由して接続した方法は、具体的なセキュリティ対処方法としてガイドラインに記載することができるだろう。
○ モデルCについて、センサ数増加への対応は100台のセンサを利用して十分な検証結果が得られたとのことだが、もう少し成果の説明をしてもらいたい。
また、環境にやさしい仕組みをつくっていくためにセンサがエネルギーを使っているという状態はあまり好ましくないという認識があるが、そういった意味でセンサの故障を検知する仕組みについて、故障なのか、パワーオフなのか、という区分けを考慮したのか教えてほしい。
○ 環境的な制約から、今回の実証実験では100台で実証実験を行った。当方としては100台のセンサの負荷がバースト的に増加することがあれば、スケーラビリティに対応できない部分を解決すればよいと考え、センサの負荷が直線的に増加するのであれば実証実験は成功であるという形をとった。
また、故障検知について、故障とパワーオフの区別がつかないような場合もあったため、故障の状態を分離できる部分のみステータスをとるという形で対処した。
○ 我々がIETF等で、IPv6のネットワーク技術を利用した環境クラウドをつくっていくためのプロトコルの拡張としてRPL等の技術開発を行ってきた経緯を踏まえ、センサは、使用しないときは動作をオフにした方がよく、かつ、オンのときも転送するパケットサイズをできるだけ最小化しようという認識を改めて共有したい。
○ そうした技術が、今まさに標準化の土俵に乗っている点をガイドラインの中で記述した方がよいだろう。
センサネットワークを無線と有線とどちらで構築するかは、コストやセキュリティの問題がからむところだが、こうした問題は実証実験の中で出てきていさるのか。
○ 今回、無線でセンサを構築した理由は、コスト軽減はもちろん、ユーザ側からすると有線の工事に対して多少の抵抗があったことが挙げられる。その際、センサ及び環境クラウド間の通信を暗号化することでセキュリティの確保を図っている。
○ モデルB、Cにおいて、「ゲートウェイ」という言葉が出てきているが、これはどのようなものか。
○ モデルB、Cともに、サーバと接続する機器が全くない状態からスタートしているので、センサ群に何かしらのローカルコントローラを置いて、サーバと接続する仕組みが必要となる。また、インターネットを介して制御を行うことについて、制御とは、インターネットが切れた場合でも継続的に行われなければならないものであるため、その制御のエージェントもゲートウェイに載せている。
○ 世の中で既に使われている制御システムはIPアドレスを利用していない。BACnet／IPというのも、実はインターネットプロトコルではないIPを利用している。今回の実証実験は、既存の制御システムを利用して実証することを前提としているので、インターネットプロトコルとは違うシステムとの相互接続をするためのゲートウェイが必要になる。
○ 資料6－2の16ページで、いきなりゲートウェイの話が出てくるので、その前にもう少し説明があった方がよいだろう。
【「IPv6環境クラウドサービスの構築・運用ガイドライン」に係る提案】
NTTコミュニケーションズ真田氏より資料WG環6－4について説明。
○ 資料6－2の5ページでは、アプリケーションレイヤ、プラットフォームレイヤ、インフラレイヤ、この3つの領域でカテゴライズして整理するという説明があったので、それが資料6－4で記載された各モデルの要件でいうとどれが該当するのか。
また、現状はデータセンターのオーナー、運用管理者をサービサーに位置づけているようだが、今後現れるサービス形態として、データセンター事業者と、システムレイヤの運用管理を行うサービサー、その環境を利用してアプリケーションレイヤで運用管理するサービサーが分離する可能性がある。こうした場合のガイドラインの位置づけを教えてもらいたい。
○ アプリケーションレイヤ、プラットフォームレイヤ、インフラレイヤの切り分けについては、資料6－4の31ページに記載したとおり、この3つの領域でガイドラインを記述することが望ましいと考えている。今回の各モデルの研究結果等をすべて3つの領域にマッピングしていないが、これに基づいてガイドライン上では各レイヤに必要な記述をすることになると考えている。
データセンター事業者とサービサー、アプリケーションレイヤで運用管理するサービサーの分離については、事業者が分離することを前提に、例えば資料6－4の21ページの責任分界点の設定等を記述している。
○ 当初から、当ガイドラインは、一般的な情報セキュリティの部分を掘り下げて記載するというより、環境やファシリティーなどの部分に特化したところを抽出することが自然であり、いわゆる一般的な情報セキュリティの部分については、他のガイドライン等の記述をレファレンスして構わないという位置づけがスターティングポイントであった。
○ 当ガイドラインの中には、一般的なクラウドに適用できる情報も網羅されていると思う。環境クラウドを考えるときに、当然、クラウドに関する一般的な部分と、環境クラウド特有の部分を、特に今回のIPv6とIPv4の混在環境のときにどのように対処すべきかを、明確に抽出しておくべきではないか。
○ ガイドライン全体として、抜けがないようなフレームワークが必要だが、IPv6や環境クラウドに特化した記載も必要であろう。例えば、IPv6、IPv4はどのように調達すればよいかを記載した方がよい。
○ アプリケーションレイヤ、プラットフォームレイヤ、インフラレイヤという切り分けでガイドラインを構成するのであれば、それぞれレイヤの提供者が注意すべき観点、その理由をガイドラインに記載すれば、実際にビジネスを始めようとしたときに、非常に分かりやすいガイドラインとなるだろう。
○ 上質なシステムでは、セキュリティパッチがきちんと当てられていて、IDS（Intrusion Detection System）やファイアウォールが適用されているのが前提であるが、既存のビル管理システムは、セキュリティについては何の対策もされていないので、そもそもインターネットにつなげられないというところからスタートすることとなる。そこで、無線を経由してビル管理システムとインターネットをつなぐ手法を紹介すれば、オープンな環境クラウドにビル管理システムをつなぐ際のティップスとなるだろう。
○ IPv6環境クラウドのシステム特有の部分は詳細に書き、それ以外の一般的なクラウドに適用できる部分は、別のガイドラインの参照方法として記載すると使いやすいのではないか。
○ 今回の実証実験の中で得られた知見をインプットできるところに濃淡があり、淡の部分も可能な限り網羅的に記載するようにしたが、指摘を踏まえて、濃の部分を一層具体的に記述するようにしたい。
○ 既存のシステムとの相互接続は大変重要なキーファクターだと考える。このガイドラインのポイントの一つとして、環境クラウドのオープン化を進めながら既存のシステムとどう付き合うかが運用上・設計上の重要な課題になっていくと思う。また、相互接続を前提としていない契約形態が多いため、例えば既存のシステムをインターネットにつないだ際にウィルスに感染してしまったら、復旧等に係る費用負担を求められることが想定されるという点も、ビジネス上大きなポイントとなるので、ガイドラインでも触れた方がよい。
○ 今回の実証実験でIPv4とIPv6の混在環境での問題点について検証したのか。もし検証していれば、その結果をガイドラインに盛り込むことで、今後のIPv6への移行を促進する取組に説得性が出てくると思う。
○ 末端のセンサが全部IPv6化しているかというとそうではなくて、IPv4のセンサも混在していたので、既存のv4のセンサを前提にゲートウェイで収集し、ゲートウェイから先はIPv6で構築している。その際、特に大きな問題点は無かったと認識している。
○ IPv4は、アドレス空間が窮屈であるため、ネットワークの設計が面倒であることや、そもそもIPv4アドレスを取得できなくなる問題もある。
○ 6lowpan、RPL、APIのインターフェースのコアの部分の技術などが、直近1～2年の間に標準化されてきているため、こうしたIPv6の技術進化に関する事項をガイドラインに記載すれば、IPv6を利用する重要性を訴えられると思う。
○ IPv4は枯渇するため、もう取得できなくなるという点をガイドラインの最初に記載した上で、IPv6を利用する重要性を訴えるとよい。
○ 最後の調整でよいと思うが、実際のシステム・コンフィグレーションを生々しく記載することができれば、実際にシステムを運用する方々にとって価値のあるガイドラインになるだろう。
○ 協力会社と調整の上、記載できる事項を検討してみる。
○ 既存のセンサネットワークはIPv4ですらないという前提であれば、IPv4からIPv6へ移行するという記載は、メインに据えなくてもよいのではないか。
○ 現在は、空調メーカー独自のプロトコルをセンサネットワークに利用しているのが一般的である。それを共通のプロトコルであるLONWORKSに変換して、それをまたTCP／IPに変換している。
○ 独自のプロトコルから、IPv4を飛ばしてIPv6で構築するというストーリーだと、フォールバック問題がシリアスな問題になってくる。
また、東京都で実施した調達の仕様書を参照するなど、仕様書の書き方を具体例で示すことは、ユーザからすると非常にうれしいだろう。この仕様書には、なぜ施設をオープン化するかということが、趣旨とともに記載されているので参考になるのではないか。
○ 資料6－4の19ページでは、アプリケーションの開発・運用管理について記載しているが、一般的なクラウドのための記述に見える。今回の実証実験を踏まえて、もう少し環境クラウドに特化した知見を盛り込むことはできないか。例えば、環境クラウドにおけるデータの収集、可視化、分析というプロセスについて、何らかのガイドラインが必要なのではないか。
○ 資料6－4の19ページでは、標準的なWEB APIを介したデータアクセス手段の提供をモデルCの特徴として記載しており、環境クラウドで利用するアプリケーションを想定した記述と考えているが、19ページのアプリケーションの開発・運用管理の記述と、30ページにおける環境負荷軽減効果の可視化の記述を合わせ、どういう形でガイドラインに素材を提供できるか検討したい。
○ 現在、BEMS、HEMSの業界は、アプリケーションとデータベースの分離が行われておらず、APIがないと認識している。そのため、例えばある会社にロックオンされてBEMSのアプリケーションを動かさなければならないというときは、かなり苦労したと思う。
○ アプリケーションとデータベースの分離について、標準化の動きを反映して、どちらかというと推奨するように記載することが重要である。
○ 資料6－4に記載された「FIAP」に関しては、「IEEE1888」と書き換えてもらって差し支えない。
【その他】
次回WGについては別途連絡。
以上
