平成 26 年度クラウドオープンネットワーク
国際研究開発拠点形成事業
報告書
2015 年 3 月 31 日
一般社団法人沖縄オープンラボラト
目次
1.
本事業の概要
1.1
本事業の目的
1.2
本事業の活動概要
2.
平成 26 年度事業概要事業報告
2.1
SDN・クラウドコンピューティング融合テストベッド研究活動
2.1.1
SDN・クラウドコンピューティング融合テストベッド研究活動概要
2.1.1.1 テストベッドの機能拡張
2.1.1.1.1 OpenStack の新バージョン対応
2.1.1.1.2 テストベッドへの OpenStack 自動構築ツール Fuel の組み込み
2.1.1.2 テストベッド機器の拡張検証
2.1.1.2.1 目的
2.1.1.2.2 高集積サーバ
2.1.1.2.3 検証
2.1.1.2.4 検証環境
2.1.1.2.5 検証結果
2.1.1.2.6 今後へ向けて
2.1.1.3 Open Flow Patch panel
2.1.1.3.1 必要性
2.1.1.3.2 開発の目的
2.1.1.3.3 要件
2.1.1.3.4 方式
2.1.1.3.5 モジュール構成
2.1.1.3.6 設計
2.1.1.3.7 OpenFlow 統計情報
2.1.1.3.8 今後の課題
2.1.1.4 SDN コントローラ多様化/オーケストレーション
2.1.1.4.1 SDN コントローラについて
2.1.1.4.2 SDN コントローラの多様化
2.1.1.4.3 今後の取り組み
2.1.1.5 サービスチェイニング
2.1.1.5.1 サービスチェイニング環境構築プロジェクト
2.1.1.5.2 サービスチェイニング システム構成
2.1.1.5.3 サービスチェイニング環境構築 検証
2.1.1.5.4 サービスチェイニング環境構築 検証結果
2.1.1.5.5 今後の課題
2.1.1.6 VNF 高速化
2.1.1.6.1 VNF 高速化プロジェクトの目的
2.1.1.6.2 VNF(Virtual Netwok Function)
2.1.1.6.3 DPDK(Data Plane Development Kit)
2.1.1.6.4 Lagopus
2.1.1.6.5 VNF 高速化環境構築
2.1.1.6.6 今後の課題
2.1.1.7 Inter-Cloud 機能の実現 - 広域拠点間接続
2.1.1.7.1 検証概要
2.1.1.7.2 検証環境
2.1.1.7.3 サイト間接続方式
2.1.1.7.4 広域サービスチェイニング
2.1.1.7.5 検証
2.1.1.7.6 今後の課題
2.1.1.8 APP フレームワークの実現-クラウドネイティブ（Rack）
2.1.1.8.1 RACK とは
2.1.1.8.2 RACK 検証の目的
2.1.1.8.3 RACK 環境の自動構築と RACK アプリケーションの動作検証
2.1.1.8.4 Web UI の構築
2.1.1.8.5 課題
ii
2.1.1.8.6 今後の取り組み
2.1.1.9 Ryu Certification
2.1.1.9.1 Ryu Certification
2.1.1.9.2 Ryu Certification 環境構築の目的
2.1.1.9.3 Ryu Certification 構成
2.1.1.9.4 Ryu Certification 試験の流れ
2.1.1.9.5 Ryu Certification サーバ構築
2.1.1.9.6 Ryu Certification 試験実行手順
2.1.1.9.7 今後の課題
2.2
対外活動（展示会、学会発表）
2.2.1
展示会出展
2.2.1.1 Interop Tokyo 2014
2.2.1.2 SDN Japan 2014
2.2.1.3 Okinawa Open Days 2014
2.2.1.4 OpenStack Days Tokyo 2015
2.2.1.5 展示会まとめ
2.2.1.6 今後の活動や出展に向けての課題
2.3
Service Design Study Group
2.3.1
活動の背景
2.3.2
活動のアプローチ
2.3.3
ワークショップ
2.3.3.1 第 1 回ワークショップ
2.3.3.2 第 2 回ワークショップ
2.3.3.3 第 3 回ワークショップ
2.3.3.4 第 4 回ワークショップ
2.3.3.5 第 5 回ワークショップ
2.3.3.6 スペシャルセッション
2.4
SDN・クラウドコンピューティングを担う技術者育成
2.4.1
SDN・クラウドコンピューティングを担う技術者育成に関する活動状況および実績
iii
2.4.2
SDN・クラウドコンピューティングを担う技術者育成に関する実施結果の振り返り
2.4.3
各イベントの具体的な内容および考察（Basic プログラム）
2.4.4
各イベントの具体的な内容および考察（Advance プログラム）
2.4.4.1 SDN/クラウドプログラムコンテスト
2.4.4.2 コードレビュー（Okinawa Open Days 2014 内 BoF）
2.4.5
2.5
SDN・クラウドコンピューティングを担う技術者育成に対する今後の課題
SDN・クラウドコンピューティング関連の国際会議開催
2.5.1
SDN・クラウドコンピューティング関連の国際会議開催に関する活動状況および実績
2.5.2
「クラウド/SDN インフラセキュリティハッカソン」の具体的な内容
2.5.3
「Okinawa Open Days 2014」の具体的な内容
2.5.4
SDN・クラウドコンピューティング関連の国際会議開催に関する実施結果の振り返り
2.5.4.1 「クラウド/SDN インフラセキュリティハッカソン」について
2.5.4.2 「Okinawa Open Days 2014」について
2.5.4.3 参加者の状況について
2.5.4.4 メディアの反応について
2.5.4.5 実施結果の考察
2.5.5
3.
SDN・クラウドコンピューティング関連の国際会議開催に対する今後の課題
今後の課題
iv
１.本事業の概要
SDN・クラウドコンピューティング技術の進展によって、従来の専用機器や専用システムは汎
用サーバで置き換えられ、ネットワークの構成もソフトウェアでの制御へと進展して行く。その
ような未来を見据え、本事業においては、図 1-1 の領域を活動領域とする。
本事業では Software Defined-Networking（以下、SDN）・クラウドコンピューティングを融合
する先端的な国際研究活動と国際イベントなどの開催、さらに当該技術を駆使できる人材育成に
関する事業を行う。
図 1-1 本事業の活動領域
1.1 本事業の目的
昨今、クラウドサービス利用の拡大、スマートフォンの普及、センサ情報の活用の進展等に伴
うネットワーク利活用環境の変化や、これらを活用した情報通信サービスの多様化が進んでい
る。情報通信サービスを支えるクラウド技術およびネットワーク技術も早急なピッチで技術革新
が進んでいる。
クラウド技術は、従来より Google、Amazon に代表される巨大データセンタ事業者が潤沢な資
金を投入し自社内部で技術開発し、それを商用環境に導入しており、技術的優位性、先行者有利
を享受してきた。それに対し、他の事業者や企業ユーザは市販のソフトウェアを使わざるを得な
い状況であり、独自機能の作りこみや展開のスピードという観点で不利な状況であった。その状
況において、OpenStack という、クラウド技術をオープンソースで開発するプロジェクトが、事
業者やベンダを集積して開始され、世界中の優秀なエンジニアが優良なソフトウェア開発を進め
ている。その結果、オープンソースをベースとした新たなクラウド技術は、今まで主導権を握っ
1
てきた巨大データセンタ事業者に対抗できる手段として、大きな注目を集めている。一方、ネッ
トワーク技術に関しては米国を中心とする巨大ネットワーク装置ベンダがネットワーク市場にお
いて覇権を握っており、国内ベンダはグローバルでの存在感を発揮できないでいる。さらに、新
機能の開発や標準化の主導権はネットワーク装置ベンダが持つようになったが、通信事業者にお
いて新機能をネットワークサービスに取り入れるためには、専用のハードウェア装置を導入する
必要があり、ユーザニーズへの迅速かつ柔軟な対応が困難になってきていた。このような状況の
中で、ソフトウェアでネットワークを制御する SDN 技術が登場し、大きな注目を集めている。
SDN では「OpenFlow」と呼ばれるネットワーク標準が登場し、OpenFlow に準拠したパケット転送
に特化した廉価なハードウェアを提供する装置ベンダが登場したため、通信事業者は OpenFlow
標準に準拠したハードウェアを導入した上で、ソフトウェアの改造のみで新たなサービスを提供
することが可能となった。その結果、データセンタ、企業ネットワーク等を中心に SDN 導入が急
速に進んできている。また、OpenStack や OpenFlow は、両者ともソフトウェアにより ICT リソー
スを制御するため親和性も高く、クラウドやネットワークという従来の技術分野の壁を越えた統
合オペレーションの期待が高まっている。
沖縄オープンラボラトリ（以下、OOL）では、実利用につながる技術開発を目的とし、沖縄 IT
津梁パーク内に OpenStack や OpenFlow を中心とした最新のクラウド技術および SDN 技術の検証
を可能とするテストベッドを構築して研究開発を進めている。また、研究開発活動や当ラボで主
催する各種イベントを通じて、最先端の ICT 技術の普及、及び ICT 技術に精通した技術者の人材
育成を行うことを目的とし活動している。
1.2 本事業の活動概要
今年度は、クラウドおよび SDN 技術を融合した検証基盤であるテストベッドを中心とした研究
開発活動を行った。テストベッドについては、昨年度の活動において沖縄 IT 津梁パーク内に、
検証設備を導入して検証環境の構築自動化などを実現したが、今年度はテストベッド自体の広域
化や規模拡張ならびに高機能化を目指すとともに、クラウドおよび SDN 技術の実利用を想定した
研究開発テーマを選定し、様々な研究開発活動を行った。「2.1 SDN・クラウドコンピューティ
ング融合テストベッド研究活動」に今年度の活動結果を報告する。
これらの研究活動の成果については、展示会や学会発表などを通じて外部への発表を行った。
「2.2 対外活動（展示会、学会発表）」に今年度の活動結果を報告する。
新たな取り組みとして、次世代 ICT 基盤技術を活用する様々な分野の専門家を招聘し、利用者
の視点においてディスカッションを行う Service Design Study Group を開催した。「2.3
Service Design Study Group」に今年度の活動結果を報告する。
クラウドおよび SDN 技術は、情報通信分野における最も期待されている技術分野であるが、両
方の技術に精通した技術者は数少ない状況である。このことから、今年度はクラウドと SDN の技
術融合をテーマのひとつとし、両技術を網羅したハンズオンセミナーを開催するなどの取組を行
った。また沖縄県の教育機関や関連施設などとも協力して、産学横断的な技術者育成を推進し
た。「2.4 SDN・クラウドコンピューティングを担う技術者育成」に今年度の活動結果を報告す
る。
またこれらの技術領域では、技術進歩が著しく、最新動向を定期的に集積・発信する必要があ
るため、国内外において企業・研究機関の SDN・クラウドコンピューティングの有識者が一堂に
会し、技術テーマに関して議論・情報交換・発信を行うことが有益である。本事業では、昨年度
に引き続き、海外から有力な研究者を招聘した国際イベントを沖縄県内で開催することにより、
2
技術交流の場を提供するとともに、沖縄県の国際交流拠点としての地位向上に寄与した。「2.5
SDN・クラウドコンピューティング関連の国際会議開催」に今年度の活動結果を報告する。
本事業における今後の課題については、「3
今後の課題」で総括する。
3
2.平成 26 年度事業概要事業報告
本事業の概要で示した活動のうち、第 2 期となる 2014 年度の事業（以降、平成 26 年度事業）
活動を以下に示す。
・SDN・クラウドコンピューティング融合テストベッド研究活動
・対外活動（展示会、学会発表）
・Service Design Study Group
・SDN・クラウドコンピューティングを担う技術者育成
・SDN・クラウドコンピューティング関連の国際会議開催
2.1 SDN・クラウドコンピューティング融合テストベッド研究活動
2.1.1 SDN・クラウドコンピューティング融合テストベッド研究活動概要
SDN・クラウドコンピューティング融合テストベッド研究活動においては、テストベッドの機
能拡張や、新たな機器の導入検証を行うとともに、各種研究テーマに応じた研究開発プロジェク
トを立ち上げ、テストベッドを活用して研究開発活動を行った。
テストベッドのシステム構成を以下に記載する。
4
図 2.1.1-1 テストベッドのシステム構成
SDN・クラウドコンピューティング融合テストベッド研究活動結果を以下に記載する。
2.1.1.1 テストベッドの機能拡張
以下に、本年度対応したテストベッドの機能拡張について記載する。
2.1.1.1.1 OpenStack の新バージョン対応
OpenStack は 6 カ月ごとにメジャーバージョンアップがおこなわれている。昨年のテストベッ
ドで OpenStack 自動構築ツールとして採用した OpenOrion では、Folsam、Grizzly がサポートさ
れていたが、その後 Havana、Icehouse、Juno がリリースされており、テストベッドでも新バー
ジョンをサポートするため対応を行った。
① Havana サポート
Rackspace 社より Havana 対応の Cookbook がリリースされた。テストベッドで Havana 対応を実
現するため、OpenOrion に Havana Cookbook の組み込みを行った。
② OpenOrion への Havana Cookbook の組み込み
Havana Cookbook を OpenOrion に組み込む際に Cookbook と OpenOrion の WEB 側処理に、一部
I/F の変更があり OpenOrion の改造が必要となった。 また、Havana 選択のためメニュー追加を
行った。
5
Chef サーバの設定メニュー
より、Havana を選択できる
よう対応
図 2.1.1.1.1-1 OpenOrion 「Havana」バージョン選択メニュー
③ Icehouse、Juno のサポート
テストベッドで OpenStack 自動構築ツールとして利用する OpenOrion は、Rackspace 社の
Rackspace Private Cloud ツールをベースツールとして活用している。しかし Private Cloud ツ
ールは、v9.0(Icehouse サポート)から、テストベッドで採用している v8.0?と互換性がないこと
が判明した。そのため、OpenStack の新バージョンに対応した自動構築ツールについては他のオ
ープンソースソフトウェア（以下、OSS）を含めた選定検討を行い、検討の結果、Mirantis 社が
開発した Fuel を採用することとした。採用の理由として Fuel は、新バージョンのサポートが早
く、現在 Open Souce のコミュニティで活発に開発がおこなわれているためである。
2.1.1.1.2
テストベッドへの OpenStack 自動構築ツール Fuel の組み込み
① 利用機器の予約機能を提供する CloudShell の OpenStack 自動構築ツール選択対応
CloudShell 予約画面にて RESOUCE ATTRIBYTES の Server Type に FuelServer(Icehouse)、
FuelServer(Juno)を追加し、利用者が利用するバージョンに応じて Server Type を選択できるよ
うに対応した。
6
CloudShell より、Server Type を選択
できるように対応を行った。
FuelServer(Icehouse)を選択すること
で、OpenStack Icehouse バージョン、
FuelServer(Juno)を選択することで、
OpenStack Juno バージョンが利用可能
となる。
図 2.1.1.1.2-1 CloudShell 「Server Type」選択画面
② OpenStack 自動構築ツール Fuel の組み込み
OpenOrion は、テストベッド上で１つの OpenOrion サーバを構築し、全利用者でシステムを共
有している。しかし、Fuel を同様に共有可能なシステムとして提供を考えた場合、ユーザ管理の
機能が Fuel に備わっていないため 大きな改修が必要となる。ユーザ管理機能の追加を行った場
合、開発が盛んな Fuel のバージョンアップの阻害要因になりかねない。よって、利用者の予約
環境内サーバに Fuel サーバを自動インストールすることで個別に提供する形態を採用した。
③ Fuel 環境のため Clonezilla サーバの構築
利用者サーバに対して、Fuel 環境をインストールするにあたり テストベッドの機能として提
供している、バックアップ／リストア機能を利用することにした。従来のバックアップ／リスト
ア機能は、Clonezilla Live 版の ISO イメージを各サーバに配置することで実現している。しか
し、Fuel による OpenStack 環境構築は、PXE※ブートを用いた OS インストールから実行されるた
め現在の機構は採用できない。そのため、従来の方式を廃止し、Clonezilla サーバを利用した
PXE ブート方式を採用することとした。
※PXE：コンピュータのブート環境のひとつで、インテルの策定したネットワークブートの規格
7
Fuel 利用開始時
利用者予約環境の内、１
台を Fuel サーバとする。
その指定したサーバに、
Fuel サーバのイメージを
リストアする。
利用者予約環境
Fuel 環境構築完了
図 2.1.1.1.2-2 Clonezilla サーバを利用した Fuel 環境構築イメージ
2.1.1.2 テストベッド機器の拡張検証
以下に、テストベッド機器の拡張検証に関する活動結果を記述する。
2.1.1.2.1 目的
OOL で昨年度構築したテストベッドは、多種多様な通信機器を組み合わせ構築されている。会
員（正会員、賛助会員、特別会員）が利用できるテストベッドリソースとして、実行サーバ、実
行スイッチ、測定器が用意されているが展示会のデモンストレーションや、多数のリソースを必
要とする開発が平行して実施されると、リソースが不足する事態が確認されている。そこでテス
トベッドのリソース拡張を目的とした検証を実施した。
テストベッドで会員が利用可能な機器一覧を表 2.1.1.2.1-1 に示す。
表 2.1.1.2.1-1 テストベッド利用可能機器一覧
8
品名
機器種類
設置場所
Centec V350
スイッチ
306 サーバ室
Centec V350
スイッチ
306 サーバ室
PF5240F
スイッチ
306 サーバ室
PF5240F
スイッチ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
Express 5800/R120d-1E
サーバ
306 サーバ室
IXIA
測定器
306 サーバ室
2.1.1.2.2 高集積サーバ
高集積サーバはラックマウントサーバにくらべ、省スペース、省電力を実現することが可能と
なる。OOL では現在サーバとしてラックマウントサーバを利用しているが、今後テストベッドの
リソース、各開発・検証で必要なサーバ台数を考えると、高集積サーバの導入も考慮すべきであ
り検証を実施した。
①SeaMicro SM15000
SeaMicro SM15000（以下、本シャーシ）は、複数の省電力プロセサを搭載した極小の物理サー
バ（以下、内蔵サーバ）を１筐体に集積したものであり、SeaMicro 社が開発した高集積サーバで
ある。
本シャーシは、以下の特徴を有している。
・「消費電力量」と「機器設置スペース」という、データセンタの最重要課題を解決
・ 消費電力を 1/2 に、スペースを 1/3 に帯域を 10 倍に
・ ソフトウェアの修正を必要とせず“プラグ・アンド・プレイ”で利用可能
本シャーシの仕様を図 2.1.1.2.2-1 に示す
9
 筐体内に 64 枚の C-card を収容。
 各 C-card 上に 8GB or 16GB or 32GB
のメモリを搭載。
 1TB HDD x6 枚
 480GB SSD x2 枚
図 2.1.1.2.2-1 SeaMicro SM15000 仕様
2.1.1.2.3 検証
テストベッドにリソースを追加する場合に、OpenFlow Patch panel(以下、OF-Patch)に接続す
る必要があり機器によりドライバ等の開発が必要になる。まず OF-Patch への接続の前段階とし
て、本シャーシを単独で利用し、仕様・動作を確認した上で、OF-Patch への接続可否と可の場合
の必要工数を算出することとした。
2.1.1.2.4 検証環境
① ネットワーク構成
検証用のネットワーク構成図を図 2.1.1.2.4-1 に示す。
10
図 2.1.1.2.4-1 ネットワーク構成図
eth0（PXE ブート用）、eth1（管理用）、eth2（内部管理用）を表している。
また、内臓サーバに対して OOL の管理用ネットワークセグメントを割り当てた場合、枯渇してし
まう恐れがある。そのため、内蔵サーバには別のネットワークセグメントを割り当て、vyos にて
ルーティングすることにより、管理用ネットワークセグメントの枯渇を回避した。
※vyos：OSS のネットワーク・オペレーティング・システムで、ソフトウェアベースのルーティ
ング、ファイアウォール、VPN などの機能を提供
② ストレージの割り当て
本シャーシには、ストレージとして、HDD 6TB（1TBx6）と SSD 960GB(480GBx2)が搭載されてい
る。これを本シャーシ内の 64 台の内蔵サーバに、以下のように割り当てを実施している。な
お、Srv 0/0 のストレージ容量の割り当てが少ないのは、vyos のみを仮想 OS として起動させて
いるためである。
内蔵サーバへのリソース割り当てを図 2.1.1.2.4-2 に示す。
11
Srv No MEM(GB) VOL
0/0
8 2/HDD0_1TB/VOL0
1/0
8 2/HDD0_1TB/VOL1
2/0
8 2/HDD0_1TB/VOL2
3/0
8 2/HDD0_1TB/VOL3
4/0
8 2/HDD0_1TB/VOL4
5/0
8 2/HDD0_1TB/VOL5
6/0
8 2/HDD0_1TB/VOL6
7/0
8 2/HDD0_1TB/VOL7
8/0
8 2/HDD0_1TB/VOL8
9/0
8 2/HDD0_1TB/VOL9
10/0
8 2/HDD1_1TB/VOL0
11/0
8 2/HDD1_1TB/VOL1
12/0
8 2/HDD1_1TB/VOL2
13/0
8 2/HDD1_1TB/VOL3
14/0
8 2/HDD1_1TB/VOL4
15/0
8 2/HDD1_1TB/VOL5
16/0
8 2/HDD1_1TB/VOL6
17/0
8 2/HDD1_1TB/VOL7
18/0
8 2/HDD1_1TB/VOL8
19/0
8 2/HDD1_1TB/VOL9
20/0
8 2/HDD2_1TB/VOL0
21/0
8 2/HDD2_1TB/VOL1
22/0
8 2/HDD2_1TB/VOL2
23/0
8 2/HDD2_1TB/VOL3
24/0
8 2/HDD2_1TB/VOL4
25/0
8 2/HDD2_1TB/VOL5
26/0
8 2/HDD2_1TB/VOL6
27/0
8 2/HDD2_1TB/VOL7
28/0
8 2/HDD2_1TB/VOL8
29/0
8 2/HDD2_1TB/VOL9
30/0
8 2/HDD3_1TB/VOL0
31/0
8 2/HDD3_1TB/VOL1
Capacity(GB)
8
102
102
102
102
102
102
102
102
107
94
94
94
94
94
94
94
94
94
85
94
94
94
94
94
94
94
94
94
85
94
94
Srv No
32/0
33/0
34/0
35/0
36/0
37/0
38/0
39/0
40/0
41/0
42/0
43/0
44/0
45/0
46/0
47/0
48/0
49/0
50/0
51/0
52/0
53/0
54/0
55/0
56/0
57/0
58/0
59/0
60/0
61/0
62/0
63/0
MEM(GB)
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
32
32
32
32
32
32
32
32
32
32
32
32
32
32
32
32
VOL
2/HDD3_1TB/VOL2
2/HDD3_1TB/VOL3
2/HDD3_1TB/VOL4
2/HDD3_1TB/VOL5
2/HDD3_1TB/VOL6
2/HDD3_1TB/VOL7
2/HDD3_1TB/VOL8
2/HDD3_1TB/VOL9
2/HDD4_1TB/VOL0
2/HDD4_1TB/VOL1
2/HDD4_1TB/VOL2
2/HDD4_1TB/VOL3
2/HDD4_1TB/VOL4
2/HDD4_1TB/VOL5
2/HDD4_1TB/VOL6
2/HDD4_1TB/VOL7
2/HDD5_1TB/VOL0
2/HDD5_1TB/VOL1
2/HDD5_1TB/VOL2
2/HDD5_1TB/VOL3
2/HDD5_1TB/VOL4
2/HDD5_1TB/VOL5
2/HDD5_1TB/VOL6
2/HDD5_1TB/VOL7
2/SSD0_480GB/VOL0
2/SSD0_480GB/VOL1
2/SSD0_480GB/VOL2
2/SSD0_480GB/VOL3
2/SSD1_480GB/VOL0
2/SSD1_480GB/VOL1
2/SSD1_480GB/VOL2
2/SSD1_480GB/VOL3
図 2.1.1.2.4-2 内蔵サーバへのリソース割り当て
③ OS インストール
内蔵サーバへの OS インストールイメージを図 2.1.1.2.4-3 に示す。
12
Capacity(GB)
94
94
94
94
94
94
94
85
112
112
112
112
112
112
112
147
112
112
112
112
112
112
112
147
112
112
112
111
112
112
112
111
図 2.1.1.2.4-3 OS インストール
事前に本シャーシの外部に MAAS サーバを準備し、本シャーシ内の各内蔵サーバが PXE ブート
することにより、予め MAAS サーバ上で指定された登録済の OS（Ubuntu）が自動的に本シャーシ
内の対象内蔵サーバにセットアップされる。
④ 検証内容
・OpenStack 環境構築
通常、OpenStack 環境を構築するに当たり、<OpenStack Install Guide>に沿って、セットアッ
プ手順を手動で実施する必要がある。しかし、複数サーバに対して、この方法での環境構築をし
た場合、構築作業に時間がかかり、また、構築作業過程において、ミスを起こしてしまう可能性
が高くなる。今回は、MAAS＋juju を使用することで、OpenStack 環境の構築作業を簡易に実施で
きることを確認した。
※参考
<OpenStack Install Guide>
http://docs.openstack.org/icehouse/install-guide/install/apt/content/
・SeaMicro 内部スイッチ
テストベッドに接続するためには、OF-Patch へ接続する必要がある。
13
本シャーシは、複数の内蔵サーバでネットワークを構築するために SeaMicro 内部スイッチを
内蔵している。ここでは、OpenStack の環境構築の作業を通じて、SeaMicro 内部スイッチの仕様
や動作を確認する。
2.1.1.2.5 検証結果
検証結果を以下に示す。
① OpenStack 環境構築
本シャーシの OpenStack インストールイメージを図 2.1.1.2.5-1 に示す。
図 2.1.1.2.5-1 OpenStack インストール
MAAS による OS インストール後に、juju を使用して OpenStack のモジュールをデプロイするこ
とは確認できた。
しかし、各 OpenStack ノード間の連携完了までにコンピュートノードが起動しない等の現象を
確認しており安定した OpenStack の自動構築の確認には至らなかった。また検証の一環として、
juju のバージョンをあげて確認を行ったが、デプロイ時点でエラーとなることを確認した。ま
だ、juju は開発段階であることもあり、安定性にかけていると考える。なお、発生したエラーに
ついては、継続して原因を確認中である。
② SeaMicro 内部スイッチ
14
本シャーシの内部スイッチは L2 スイッチである。接続イメージを図 2.1.1.2.5-2 に示す。
1Gbps（以下 1G）の物理ポートは、本シャーシに外向け８ポート、内蔵サーバ８ポートがあり、
各々のポートは、内部スイッチのポートと１対１で接続されている。また各ポートには VLAN が
設定可能である。
図 2.1.1.2.5-2 (a) 内部スイッチ接続イメージ（1G）
また、10Gbps（以下 10G）の物理ポートは、本シャーシに外向け４ポート実装されている。
10G ポートは、VLAN を設定することで複数の内蔵サーバで共有することが可能である。
15
図 2.1.1.2.5-2 (b) 内部スイッチ接続イメージ（10G）
上記の検証結果より本シャーシの内部スイッチ（L2 スイッチ）は論理的なネットワークの分離
を対象としており、一方で、OF-Patch は物理的な機器間の接続を対象としている。したがって
OF-Patch で本シャーシの内部スイッチを直接制御して、内蔵サーバの機器間接続を実現すること
は困難と考える。
③ 利用実績
・RACK（Real Application Centric Kernel 別途説明） デモ用環境の構築
・RACK の調査・検証用に Server 11 台に環境提供
・Handson 向け環境の提供
OpenStack ハンズオン環境を手軽に提供できることを目的に今回は、対象人数 Max40 名に対し
て、Server 31 台に OpenStack 環境提供
2.1.1.2.6 今後へ向けて
以下について、検証を実施する予定である。
① OpenStack の自動構築
PXE ブート（MAAS＋juju、Fuel 等）環境における自動構築の実現に向けた検証を行う。
今後、テストベッドへ Fuel の採用が決定しているため、優先的に検証する予定である。
16
② テストベッドへの組み込み
利用者向けの環境を提供するにあたり、OF-Patch による機器間の接続機能が重要となる。しか
し、現仕様で VLAN 制御をサポートしていない OF-Patch との連携は困難な状況であることが判明
している。OF-Patch の仕様拡張を含めた、別案の検討を進めていく予定である。
17
2.1.1.3 Open Flow Patch panel
以下に、OF-Patch に関する活動結果を記述する。
2.1.1.3.1 必要性
OOL では、OpenStack/SDN 実証検証環境としてテストベッドを提供している。検証環境では機
器の変更、ネットワークトポロジの変更などが頻繁に発生するが、従来は物理的な配線を手動で
差し替えて変更するため、技術者が現地へ行き配線を行わなければならない。遠隔地に検証環境
がある場合は移動する時間やコストがかかる。また、手動で配線を差し替えるため、接続間違い
や、ルーズコンタクトを起こすリスクがある。その際、図 2.1.1.3.1-1 の様に配線が複雑に絡ま
り、また配線にタグがついていない、タグが間違っている、接続先が分からない配線が存在する
こともある。
OOL のテストベッドでは機器の変更、ネットワークトポロジの変更を遠隔より行う必要があ
る。また、出来る限り検証環境に影響を与えない方式で実装を行う必要がある。
図 2.1.1.3.1-1 従来の配線状況
2.1.1.3.2 開発の目的
前述のとおり、テストベッドは遠隔よりネットワークトポロジの変更を行う必要があるため、
OOL では SDN 技術である OpenFlow を用いた OF-Patch を開発した。OF-Patch は複数の OpenFlow
スイッチを１つの大きなパッチパネルとして見せており、OpenFlow コントローラにより制御す
ることで、ソフトウェアによるネットワークトポロジの変更が行えるため、遠隔操作での接続変
更がグラフィカルユーザインタフェース（以降、GUI）上で可能となる。GUI 上で各機器の名前、
ポート名を表示し、接続確認のためのポップアップ表示に接続情報を表示して注意を促すこと
18
で、接続間違いの低減が可能となる。さらに、あらかじめ機器間を物理的に接続しておくこと
で、配線変更によるルーズコンタクトなどの問題が解消される。
2.1.1.3.3 要件
OF-Patch の要件として、従来のパッチパネル相当の機能であること、パッチポート間の接続お
よび切断ができること、GUI による容易な配線変更が行えることなどがある。表 2.1.1.3.3-1 に
OF-Patch の要件と今年度の実装状況を示す。
表 2.1.1.3.3-1 OF-Patch の要件及び実装状況
要件
内容
実装状況
ポート間の接続
OF-Patch のポート間が接続できること
対応済み
ポート間接続の切断
OF-Patch のポート間接続が切断できること
対応済み
ポート指定接続操作
機器のポートを直接指定して配線操作を行えること
対応済み
機器指定接続操作
各機器（サーバ、スイッチなど）のポートを表示せ
ず、ポートを意識せず、機器同士を直接接続する操作
を行えること
対応済み
GUI での操作
GUI 上で容易に接続・解除できること
対応済み
単体動作
OF-Patch 単体で動作できること
対応済み
連携動作
予約機能（CloudShell）と連携して動作できること
対応済み
自動経路選択
GUI 上で接続を行うと、自動で経路を選択すること
対応済み
大規模化
複数のスイッチを組み合わせて、一つの大きな OFPatch として動作すること
対応済み
多拠点接続
複数拠点の OpenFlow コントローラを制御できること
未対応
トランザクション処
理
複数ユーザから同時使用された場合に、問題なく動作
できること
未対応
設定変更が実際に正常完了したか確認できること
19
2.1.1.3.4 方式
昨年度の OF-Patch は単独の OpenFlow スイッチのみでの構成であったが、本年度は OF-Patch
の大規模化として、複数の OpenFlow スイッチを組み合わせて一つの大きなパッチとして動作す
る必要がある。複数スイッチ間の接続方式は、Leaf – Spine 方式を採用した。
① Leaf – Spine 方式
Leaf – Spine 方式とは、検証対象のサーバ、スイッチ等の機器を接続するスイッチを Leaf
スイッチとし、各 Leaf スイッチを束ねるコア側のスイッチを Spine スイッチとして構成した
ネットワークである。
OF-Patch では図 2.1.1.3.4-1 の通り、標準的な 1G OpenFlow スイッチ（ 1G ポートが 48 ポー
ト、 Uplink 用 10G ポートが 4 ポート）を Leaf スイッチとして使用し、標準的な 10G
OpenFlow スイッチ（ 10G ポートが 48 ポート）を Spine スイッチとして使用した構成を想定し
ている。従来のパッチパネルと同様に各ポートは一対一で接続し、ポート間は 1G の帯域を保証
する。 Leaf – Spine 間の接続については、 Leaf スイッチの 1G ポート × 40 個を Uplink 用
10G ポート × 4 個で Spine スイッチへ接続する。 1G ポート × 10 個分を Uplink 用 10G ポ
ート 1 つに割り当てることで、各ポート 1G の帯域を保証する。 Leaf スイッチの各 Uplink 用
ポートをそれぞれ別の Spine スイッチに接続することで Spine スイッチは 4 台と決まる。各
Spine スイッチは 48 ポートであるため Leaf スイッチは最大 48 台と決まる。この構成で Leaf
スイッチ 48 台 × 40 ポートで最大 1920 ポートを接続可能なパッチパネルとなる。
図 2.1.1.3.4-1 Leaf – Spine 方式
20
② Leaf – Spine 間のトラフィック多重方式
Leaf スイッチの 10 本分の 1G ポートを Uplink 用の 10G ポート 1 本に多重するため、通信元の
機器が接続された Leaf スイッチでトラフィックを多重して Spine スイッチへ送り、Spine スイッ
チでそれぞれのトラフィックを通信先の機器が接続された Leaf スイッチへ振り分ける必要があ
る。また、通信先の Leaf スイッチで通信先の機器が接続されたポートに振り分ける必要があ
る。
トラフィックの多重方式は従来のパッチパネルのように検証環境に影響を与えないよう考慮す
る必要があり、VLAN 等での多重はタグ分フレームサイズが増加するため検証環境の帯域に影響を
与えてしまう。また、検証環境が VLAN を使用している場合に、Leaf スイッチ及び Spine スイッ
チが 2 重タギングに対応している製品でない場合に VLAN を使用できない懸念などがある。
検証環境に影響を与えない Leaf–Spine 間のトラフィック多重方式として MAC アドレス書換え
方式を採用した。これは、通信元の Leaf スイッチにて送信元 MAC アドレス、送信先 MAC アドレ
スを OF-Patch の内部的な管理アドレスに書き換え Spine スイッチに送り、Spine スイッチで管理
アドレスを基に宛先 Leaf スイッチにそれぞれのトラフィックを振り分ける。通信先の Leaf スイ
ッチで管理アドレスを基に元の MAC アドレスに書き直して検証機器へ転送を行う。この方式の場
合、MAC アドレスのフィールドを書き換えるのみであるためフレームサイズの増加が無く検証環
境の帯域に影響を与えない。また、MAC アドレスのフィールド書換えは OpenFlow1.0 から対応し
ている基本機能であり、標準的な OpenFlow スイッチで基本的に備えている機能であるため、現
在市場に出回っている多くの OpenFlow スイッチを OF-Patch に使用可能と考える。
③ 経路選択方式
Spine スイッチは最大 4 台あり、Leaf スイッチから Spine スイッチに転送する際に、どの
Spine スイッチを経由するか経路を選択する必要がある。例えば 1 番目の Spine スイッチから順
に埋めていく方法や各 Spine スイッチに均等にトラフィックを振り分ける方法等がある。一つの
Spine スイッチに片寄せすると、そのスイッチに障害が発生した場合に影響が大きい。
OF-Patch は Leaf–Spine 間の帯域使用率に応じて各 Spine スイッチに均等にトラフィックを振
り分ける方式を採用した。データベースに Leaf–Spine 間の Link に帯域使用率（使用量／容量）
を設定する。具体的には分母に Leaf-Spine 間の帯域である 10G を設定し、分子に Leaf スイッチ
の 1 ポート分使用する毎に 1G を加算することで重み付けを行う。辺の重みを基に経路選択を行
うダイクストラ法を用いて、Leaf-Spine 間の Link に設定した重み（帯域使用率）を用いて経路
選択を行う。
帯域使用率の算出について、現在 1 ポート使用する毎に単純に 1G を加算しているが、今後、
ポートのトラフィックを測定し実測に基づいた値を加算することで，より正確なトラフィック均
等振り分けを検討する。
2.1.1.3.5 モジュール構成
OF-Patch のモジュール構成を図 2.1.1.3.5-1 に示す。
21
図 2.1.1.3.5-1 OF-Patch のモジュール構成
OF-Patch は、 OF-Patch GUI、 OF-Patch マネージャ、 OpenFlow コントローラ（以下、
OFC）、 OpenFlow スイッチ（以下、OFS）の機能から構成される。図 2.1.1.3.5-1 のオレンジ枠
で示すモジュールについて開発を行った。
OF-Patch GUI モジュールについては、Web ブラウザ上で動作するアプリケーションであり、グ
ラフィカルな表示を支援する D3.js ライブラリを用いて、優れたユーザビリティなインタフェー
スを実現する。OF-Patch マネージャは OF-Patch GUI からの設定指示を受け、データベースへの
データ登録を行うとともに、OFC に対しポート接続の設定変更指示を行う。データベースについ
てはグラフデータベースである OrientDB を用いており、現在主流のリレーショナルデータベー
スに比べ高速に配線の経路計算をおこなうことができる。OF-Patch における OFC は Ryu を採用し
ている。
① OF-Patch GUI
OF-Patch のユーザ操作機能として、ネットワークトポロジの変更を容易に行えるよう GUI を
開発した。OF-Patch GUI の機能は以下の通りである。
・ポート指定接続画面
・機器指定接続画面
ネットワーク接続・切断を容易に行えるよう以下の操作が可能である。
・接続したいポートとポートをクリックすることで接続できる
・切断したいリンクをクリックすることで切断できる
・ドラッグ操作による表示位置の移動
22
・スクロール操作による拡大・縮小
・機器のマウスオーバによる機器間の接続のハイライト表示、及び機器情報のポップアップ表示
・ポートのマウスオーバによるポート情報のポップアップ表示
・リンクのマウスオーバによる接続情報のポップアップ表示
・commit、cancel、undo、redo の機能
② ポート指定接続画面
ポート指定接続画面を図 2.1.1.3.5-2 に示す。
図 2.1.1.3.5-2 ポート指定接続画面
ポート指定接続画面では、各機器の名称と機器に属するポートおよびポート間の接続状況の表
示を行う。OF-Patch で実行するポート間の接続をパッチリンクと定義する。機器のポートとポー
トをクリックすることでパッチリンクによる接続操作が行うことができる。また、パッチリンク
をクリックすることで切断操作が行うことができる。スクロール操作で拡大・縮小が実行でき、
機器、ポート、パッチリンクをマウスオーバすることで各種情報の表示が可能である。
③ 機器指定接続画面
機器指定接続画面を図 2.1.1.3.5-3 に示す。
23
図 2.1.1.3.5-3 機器指定接続画面
機器指定接続画面では、各機器の名称とパッチリンクの表示を行う。この画面では機器同士の
繋がりのみの表示のため、どの機器同士が接続されているか容易に確認することができる。画面
上の機器と機器をクリックすることでパッチリンクによる接続操作が行うことができ、パッチリ
ンクをクリックすることで切断操作が行うことができる。機器に属するどのポートを使用して接
続するかについては OF-Patch マネージャにて自動的に選択される。このため、ポートを意識せ
ず単純に機器と機器を指定した接続操作を行うことができる。
④ OF-Patch マネージャ
OF-Patch では OF-Patch GUI を用いて、機器間を簡易に接続および切断し、接続構成を変更可
能である。OF-Patch マネージャは、OF-Patch GUI の表示に必要な接続構成情報の提供や OFPatch GUI からの指示に従い接続構成の変更を行う。そのために、OF-Patch マネージャはデータ
ベースへ情報の取得や変更を要求し、OFC へ OF-Patch 用スイッチのフロー変更を要求する機能
を持つ。また、OFC の IP と OF-Patch を構成する全ての OF-Patch 用スイッチの DatapathID
を管理する。OF-Patch マネージャの開発には Java と Apache Tomcat を用いた。OF-Patch マネー
ジャは以下の機能を有する。
・OF-Patch GUI への各機器、各リンク情報の提供
・OF-Patch GUI からのパッチリンク追加、削除の受付
・データベースへのパッチリンク情報変更要求
・OFC へのパッチリンク変更要求
・無効な要求の排斥
・OFC と OF-Patch 用スイッチの所属管理
24
⑤ OF-Patch マネージャ API
OF-Patch GUI と OF-Patch マネージャ間の通信は REST を用いて行われ、JSON データを転送す
る。OF-Patch マネージャの REST API の機能を表 2.1.1.3.5-4 に示す。
表 2.1.1.3.5-4 OF-Patch マネージャの REST API 機能
機能
説明
機器、リンク情報の取得
機器、リンク情報を取得する。
リンク情報の更新（接続、切
断）
OF-Patch GUI に表示している機器、リンク情報の接続、切
断状態を更新する。
⑥ データベース
OF-Patch は、実際の物理配線情報を管理し、機器間の接続に必要なフロー情報を OF-Patch 用
スイッチに設定する事で機器間接続を実現する。そのため、機器情報管理機能、リンク情報管理
機能、指定された機器間で最も効率的な経路を検索する機能が必要となる。これらの機能は主に
データベースを用いて実現される。従来から利用されているリレーショナルデータベース(以
下、RDB)の場合、データは表のような構造で管理されているため、機器情報管理機能は効率的な
管理ができるが表のデータ数に比例して検索時間がかかることと、配線と機器のつながりをデー
タ上に定義することはデータ量が増加し、冗長となり管理面において不利となる。
一方、グラフデータベースは、バーテックスとそれを結ぶエッジによって構成されたネット
ワークを表現しており、それにより、配線と機器のつながりをデータ上に定義することで、接続
情報管理や経路検索を容易かつ高速に行うことが可能である。したがって、グラフデータベース
を採用することとした。尚、グラフデータベースの中でも SQL に近い構文を持ち、Java との親和
性が高い OrientDB を使用した。
⑦ OF-Patch OpenFlow コントローラ
OFC は、OF-Patch 用スイッチを制御するアプリケーションである。OFC の機能を以下に示す。
・OF-Patch 用スイッチのフロー追加・削除
・OF-Patch マネージャからのフロー追加・削除受付
⑧ OpenFlow コントローラ API
OF-Patch マネージャと OFC 間の通信は REST を用いて行われ、JSON データを転送する。OFC が
OF-Patch マネージャに提供する REST API を表 2.1.1.3.5-5 に示す。
25
表 2.1.1.3.5-5 OpenFlow コントローラの REST API
機能
説明
フローの追加
OF-Patch マネージャからの接続要求を受け、OF-Patch 用スイッ
チ上にフローを追加する。
フローの削除
OF-Patch マネージャからの切断要求を受け、OF-Patch 用スイッ
チ上のフローを削除する。
⑨ 開発環境・ライブラリ
OFC の開発環境およびライブラリを以下に示す。
・言語： Python
・ライブラリ：Ryu
2.1.1.3.6 設計
① フローテーブル設計
OF-Patch の Spine スイッチ、 Leaf スイッチに設定するフローについて記載する。Leaf スイ
ッチに設定するフローについては同一 Leaf スイッチ内でパッチリンクする場合と、 Leaf スイ
ッチを跨いでパッチリンクする場合の 2 パターンが存在する。 Spine スイッチについては Leaf
スイッチから上がってきた複数パッチリンクがトランクされた通信を、パッチリンク毎に分離し
宛先 Leaf スイッチに向けて送付する。その際に内部的な MAC アドレスをマッチ条件としてフロ
ーを設定する。
② Spine スイッチのフローテーブル設計
表 2.1.1.3.6-1
Spine スイッチのフローテーブル設計
No.
Match 条件
Instruction
１
Priority = 200
＊（全て）
Actions：drop
２
Priority = 800
in_port,
Actions：output
Idle_timeout = 65535
dl_src(ソース MAC アドレス)
③ Leaf スイッチのフローテーブル設計
26
表 2.1.1.3.6-2
Leaf スイッチのフローテーブル設計
No.
Match 条件
Instruction
１
Priority = 200
＊（全て）
Actions：drop
２
Priority = 400
in_port
Actions：CONTROLLER
３
Priority = 600
in_port
Actions：drop
Idle_timeout = 600
４
Priority = 800
in_port
Actions：output
５
Priority = 800
in_port,
Actions：
Idle_timeout = 65535
dl_src(ソース MAC アドレス)
output,
set_field:内部 MAC アドレス>eth_src,
set_field:内部 MAC アドレス>eth_dst
④ データスキーマ
OF-Patch のデータベースは、機器情報、機器に属するポート情報、物理配線情報、OF-Patch
用スイッチ上のパッチリンク情報、内部 MAC アドレス情報を持つ。機器情報および機器に属する
ポート情報を表 2.1.1.3.6-3 に示す。
表 2.1.1.3.6-3 機器情報および機器に属するポート情報
機器情報（Device）
機器に属するポート情報（Port）
{
{
"@rid": "#11:0",
"@rid": "#12:0",
"@class": “node”,
"@class": “port",
"name": “PICA-P-3290-SW01”,
"deviceName": “PICA-P-3290-SW01",
"type": “Leaf”,
"name": " ge-1/1/1”,
"number": "1“
27
}
“datapathId”: ”
5e3e089e01e99558”,
“ofcIp”: “172.16.1.9:28080”
}
機器情報は、機器名、機器のタイプ、ポート情報、OF-Patch 用スイッチである場合、
DatapathID 情報、OFC の IP を持つ。ポート情報はポート名とポート番号、どの機器に属するか
の情報を持つ。
物理配線情報は機器間の接続情報、内部バス情報は機器内の接続情報を両方向で持つ。物理配
線情報および内部バス情報を表 2.1.1.3.6-4 に示す。
表 2.1.1.3.6-4 物理配線情報および内部バス情報
物理配線情報（Cable）
内部バス情報（bus）
{
{
"@rid": "#17:0",
"@rid": "#15:0",
"@class": “cable",
"@class": “bus",
“in": “#12:51”,
“in": “#11:1”,
“out": “#12:177”,
“out": “#12:53”,
“used": "1024"
“used": "0"
}
}
パッチリンク情報は接続元ポート、接続先ポート、OF-Patch 用スイッチ情報、接続元機器名と
ポート、接続先機器名とポート、シーケンスナンバー情報を持つ。シーケンスナンバーは同一
Leaf スイッチ内の接続では 1 のみ、 Leaf スイッチを跨ぐ場合は、接続先 Leaf スイッチのパ
ッチリンクが 1、経由する Spine スイッチのパッチリンクが 2、接続元 Leaf スイッチのパッチ
リンクが 3 となる。内部 MAC アドレス情報は接続元 Leaf スイッチの機器名、インポート情報、
発信元 MAC アドレス、宛先 MAC アドレス、内部 MAC アドレスを持つ。尚、内部 MAC アドレスは
Leaf スイッチの機器名、インポート、発信元 MAC アドレス、宛先 MAC アドレスを基に生成され
る。パッチリンク情報および内部 MAC アドレス情報を表 2.1.1.3.6-5 に示す。
表 2.1.1.3.6-5 パッチリンク情報および内部 MAC アドレス情報
パッチリンク情報（PatchWiring）
内部 MAC アドレス情報（internalMacMap）
28
{
{
"@rid": "#18:0",
"@rid": "#19:2485",
"@class": “patchWiring",
"@class": “internalMacMap",
“in": “#12:289”,
"deviceName": “PICA-P-3290-SW01",
“out": “#12:292”,
"inPort": "1”,
“parent": “#11:9”,
"srcMac": "94:de:80:ea:b2:16”,
“inDeviceName": “Server1”,
"dstMac": "33:33:00:00:00:16”,
“inPortName": “eth2”,
"internalMac": "1653“
“outDeviceName": “Switch2”,
}
“outPortName": “eth-0-1”,
“sequence": “1”
}
⑤ 動作フロー
OF-Patch の動作フローは接続動作時、切断動作時、OpenFlow スイッチが OpenFlow コントロ
ーラに接続した時の 3 パターンあり、接続動作は Leaf スイッチを跨ぐ場合のパッチ接続、同一
Leaf スイッチ内でのパッチ接続の 2 パターンがある。図 2.1.1.3.6-6 (a)に同一 Leaf スイッチ
内での接続時の動作フロー、図 2.1.1.3.6-6 (b)に Leaf スイッチを跨ぐ場合の接続時の動作フ
ローを示す。
図 2.1.1.3.6-6 (a) 同一 Leaf スイッチ内接続時動作フロー
29
図 2.1.1.3.6-6 (b) Leaf スイッチを跨ぐ接続時動作フロー
同一 Leaf スイッチ内でのパッチ接続であるか、Leaf スイッチを跨ぐ接続であるかの判断は
OF-Patch マネージャにて、データベースの接続情報より自動的に判断する。OF-PatchGUI からは
単純に接続元機器、接続元ポートと接続先機器、接続先ポートの情報を OF-Patch マネージャへ
要求するのみである。
以下、図 2.1.1.3.6-6 (a)
同一 Leaf スイッチ内接続時動作フローについて説明する。
(１) 接続要求を受信
(２) 同一 Leaf スイッチ内でのパッチ接続の場合は Patch link を Leaf スイッチ 1 つ分のみ
生成する。
(３) OFC へフロー設定要求を行う。このとき設定するフローは表 2.1.1.3.6-2 Leaf スイッチの
フローテーブル設計 No.4 の単純なポート to ポートのフローを双方向で設定する。
(４) Leaf スイッチへフローを設定する
以下、図 2.1.1.3.6-6 (b)
Leaf スイッチを跨ぐ接続時動作フローについて説明する。
(１) 接続要求を受信
(２) Leaf スイッチを跨ぐ場合のパッチ接続の場合は Patch link を 接続元 Leaf スイッチ、
経由する Spine スイッチ、接続先 Leaf スイッチの 3 組生成し、接続元、接続先それぞれの
Leaf スイッチに表 2.1.1.3.6-2 Leaf スイッチのフローテーブル設計 No.2 のパケットインを
OFC へ通知するフローを設定する
30
(３) OF-PatchGUI へ応答
(４) 接続元機器からの通信が発生
(５) マッチするフローがあるか検索される。初回の場合、No.2. で設定したパケットインフロ
ーがマッチする
(６) OFC へパケットイン通知が発生する
(７) OFC より OF-Patch マネージャへパケットイン情報（Leaf スイッチの dpid、インポート、
送信元 MAC アドレス、送信先 MAC アドレス）を通知する
(８) dpid、インポート情報を基に Patch link 情報を検索する
(９) dpid、インポート、送信元 MAC アドレス、送信先 MAC アドレスを基に 内部 MAC アドレスを
生成する
(１０) 送信先 Leaf スイッチ、 Spine スイッチ、送信元 Leaf スイッチの順で OFC へフロー設
定要求を行う。このとき設定するフローは、Leaf スイッチに対しては、表 2.1.1.3.6-2 Leaf ス
イッチのフローテーブル設計 No.5 のフローを双方向で設定する。Spine スイッチに対しては、
表 2.1.1.3.6-1 Spine スイッチのフローテーブル設計 No.2 のフローを双方向で設定する。
(１１) OFC より、各 OpenFlow スイッチへフローを設定する。
切断時の動作フローを図 2.1.1.3.6-7 に示す。
図 2.1.1.3.6-7 切断時の動作フロー
切断時は Patch link よりフローを削除すべき Leaf スイッチ、 Spine スイッチを検索し、
対象の Leaf スイッチ、 Spine スイッチより削除対象のフローを削除する。その後、接続情報
（Patch link 、 Internal Mac）を削除する。
31
OpenFlow スイッチが OFC に接続した時の動作フローを図 2.1.1.3.6-8 に示す。
図 2.1.1.3.6-8 OpenFlow スイッチが OFC に接続した時の動作フロー
OpenFlow スイッチが OFC に接続した時、まず、 Spine スイッチ、 Leaf スイッチ共に表
2.1.1.3.6-1 Spine スイッチのフローテーブル設計、表 2.1.1.3.6-2 Leaf スイッチのフローテ
ーブル設計の No.1 の ALL Drop のフローを設定する。次にデータベース上の接続情報（Patch
link、Internal Mac）を検索し、OpenFlow スイッチに設定すべきフローが存在する場合は
OpenFlow スイッチにフローを設定する。例えば OpenFlow スイッチを再起動した場合や、
OpenFlow スイッチを取り替えた場合（dpid を取替え前のものと同一にする必要有）には自動で
接続が復旧される。
2.1.1.3.7 OpenFlow 統計情報
① OpenFlow 統計情報とは
OpenFlow スイッチに保存される統計情報。機器情報、パケットの送受信情報、エラー状況、ポ
ート情報、フロー情報など（以降、OpenFlow 統計情報）。これらを収集・解析することで OFPatch 用スイッチの稼働状況を容易に確認することができる。
② モジュール構成
OpenFlow 統計情報を定期的に自動で収集・蓄積を行う OF-Patch Stats（以降、OFP Stats）、
操作補助のための OFP Stats GUI を開発し、OF-Patch に組み込んだ。構成を図 2.1.1.3.7-1 に示
す。動作概要としては、まず OFP Stats が OpenFlow 統計情報を収集、自身の DB へ保存する。DB
保存後、OFP Stats GUI は OFP Stats へアクセスし、OpenFlow 統計情報を要求、取得したデータ
を Web ブラウザ上に表示する。OFP Stats、OFP Stats GUI の詳細については後述する。
32
図 2.1.1.3.7-1 OFP Stats, OFP GUI 構成図
③ Open Flow Patch Stats モジュール
定期的な自動実行または手動での実行により OFC へ StatsRequest（OpenFlow 統計情報の収集
開始）を行う。OFC から OFS へ Request が到達後、OFS は OFC、OFP Stats へと返答を行う。OFP
Stats は取得した OpenFlow 統計情報を内部の DB（MySQL サーバ）へ保存する。また、外部からの
DB へのアクセスのため REST API を実装した。実装した REST API の一例を表 2.1.1.3.7-2 に示
す。開発は Java、Python で行った。
表 2.1.1.3.7-2 Stats 実装 REST API
REST API
メソッド
処理内容
/ofpm/stats/datapathid_list
GET
OFC-OFS 接続情報を取得
/ofpm/stats/desc
GET
機器情報を取得
/ofpm/stats/port
GET
ポート情報を取得
/ofpm/stats/port_desc
GET
ポート詳細情報を取得
/ofpm/stats/flow
GET
フロー情報を取得
/ofpm/stats/set_desc_stats
POST
機器情報を更新
/ofpm/stats/stats_req_start
POST
統計情報の取得を開始
/ofpm/stats/stats_req_stop
POST
統計情報の取得を中断
④ OFP Stats GUI の要件および実装状況
OFP Stats へのアクセスは手動の REST 通信により行うことができるが、ユーザビリティが低
い。操作性や視認性、データの解析を容易にするため、OF-Patch 同様に専用の GUI を開発した。
OFP Stats GUI は Web ブラウザ上で動作し、Javascript による REST 通信を実装、ユーザビリテ
33
ィ向上のため Bootstrap と呼ばれる HTML/CSS ツール集を使用して構築した。OFP Stats GUI の要
件と開発状況を表 2.1.1.3.7-3 に示す。
表 2.1.1.3.7-3 統計情報取得 OFP Stats GUI の要件および開発状況
要件
Desc Stats Request
（機器情報一覧取得）
Port Stats Request
（ポート情報取得）
Port Desc Start Request
（ポート詳細情報取得）
Flow Stats Request
（フロー情報取得）
内容
実装状況
OFP Stats GUI から情報取得要求・表示できるこ
と
対応済み
OFP Stats GUI 上で情報取得要求・表示できるこ
と
対応済み
OFP Stats GUI 上で情報取得要求・表示できるこ
と
対応済み
OFP Stats GUI 上で情報取得要求・表示できるこ
と
対応済み
OFP Stats GUI から OF-Patch DB への統計情報収
集を開始できること
未対応
OFP Stats GUI から OF-Patch DB への統計情報収
集を中断できること
未対応
Stats Request Start
（OpenFlow 統計情報の収集開
始）
Stats Request Stop
（OpenFlow 統計情報の収集中
断）
OFP Stats GUI のページ遷移図を図 2.1.1.3.7-4 に示す。Web ブラウザから OFP Stats GUI へ
アクセスすると、OF-Patch を構成する機器の一覧画面「①機器情報一覧」が表示される（ここが
トップページとなる）。詳細を確認したい機器を選択し、「②ポート情報」に遷移する。その後
は「③ポート詳細情報」、「④フロー情報」を選択できる。トップページへはいつでも戻ること
ができる。
34
図 2.1.1.3.7-4 OFP Stats GUI 遷移図
各遷移画面とその機能の詳細を説明する。
⑤ 機器情報一覧画面
機器情報一覧画面を図 2.1.1.3.7-5 に示す。
図 2.1.1.3.7-5 OFP Stats GUI 機器情報一覧表示画面
機器情報一覧画面では、各機器（OFS）の統計情報を表示する。具体的には機器名称や DPID
（接続情報）、シリアルナンバー、製造元、製品型番、OS バージョンなどが確認できる。DPID
をクリックすると、その機器のポート詳細画面へ遷移する。また、OFP Stats に対し、OpenFlow
統計情報の収集・蓄積を開始させるボタンを用意した（ボタンの表示のみで機能は未実装、以降
の画面も同様）。
35
本画面に限らず OFP Stats GUI のすべての画面では、ソート、フィルタリング機能を実装して
おり、MAC アドレスやポート番号、設定日時、パケット量などページ内のすべてのカラムでソー
トとフィルタリングが可能である。例えば、ある宛先向けのフローがどれだけ存在しているか、
どのポートに設定しているか、などを一覧として確認できる。
⑥ ポート情報画面
ポート情報画面を図 2.1.1.3.7-6 に示す。
図 2.1.1.3.7-6 OFP Stats GUI ポート情報画面
ポート情報画面では、「I. 機器情報一覧」で選択した機器のポート毎の詳細情報を表示す
る。具体的には、フロー登録日時、フロー設定期間、ポート番号、送受信パケット数、CRC エラ
ー数、ドロップパケット数などである。発生したエラーが確認できるので、障害時やデバッグ時
などの原因特定に役立つ。左側のメニューボタンにより他の画面へ遷移する。
⑦ ポート詳細情報画面
ポート詳細情報画面を図 2.1.1.3.7-7 に示す。
36
図 2.1.1.3.7-7 OFP Stats GUI ポート詳細情報画面
ポート詳細情報画面では、ポート自体の情報を表示する。具体的にはリンク速度、設定日時、
MAC アドレス、ポート番号などである。任意のポート毎にリンクアップ状態や稼働状況を確認で
きる。左側のメニューボタンにより他の画面へ遷移する。
⑧ フロー情報画面
フロー情報画面を図 2.1.1.3.7-8 に示す。
図 2.1.1.3.7-8 OFP Stats GUI フロー情報画面
フロー情報画面では、スイッチに設定されたフロー情報を確認することができる。具体的に
は、設定日時、フロー設定期間、フロー優先度、パケット数、OXM（マッチ条件）、Action（パ
ケット処理内容）などである。使用例として、どのような転送設定がされているか、どのような
37
パケットを対象となっているか、優先順位はどうか、処理されたパケットはどの程度かなどを確
認できる。左側のメニューボタンにより他の画面へ遷移する。
2.1.1.3.8 今後の課題
今後取り組んで行く必要がある課題、機能を以下に示す。
① OF-Patch を OSS として提供
開発した OF-Patch をテストベッドの一機能としての利用のみでなく、 OSS 化し、本技術を会
員含め多数の方に利用して頂くことにより、普及促進することが重要である。また、開発に加わ
って頂くことで OF-Patch の機能改善・拡張、バグフィックスを進めていくことが可能である。
現在、テストベッド認証機能との連携など、テストベッド固有のシステムとの連携部が幾つか存
在するため、OF-Patch 単独で動作するよう改善が必要であり、また、インストールマニュアル等
を整備する必要がある。
② 10Gbps OF-Patch の開発
現在の OF-Patch は 1G の帯域を保証するものである。今後、10G のポートを持つ OFS を用いる
ことで、10G をパッチ可能な OF-Patch を開発する必要がある。
③ 拡張機能の検討
検証環境では流れているパケットについて、トラフィックの測定やパケットキャプチャを行う
ことが多々ある。このため、ミラーポートへの転送やトラフィック測定の拡張機能の検討が必要
である。
④ OF-Patch の状態監視、耐障害性、トランザクション処理の検討
OF-Patch を構成する OF-Patch マネージャ、OFC、OF-Patch 用スイッチの状態を監視し、障害
が発生した場合に通知や迂回路を設定する機能が必要である。また、OF-Patch マネージャは正
常に処理を終えることができなかった場合、データベースと実際のパッチリンクの不整合を発生
させないために、以前の状態へロールバックする必要がある。
38
2.1.1.4 SDN コントローラ多様化/オーケストレーション
2.1.1.4.1 SDN コントローラについて
SDN コントローラとは、ネットワークを構成する各要素を統合して管理するソフトウェアやア
プライアンスを指す言葉であり、SDN コントローラから各要素を管理/制御するためのプロコトル
が「OpenFlow」となる。実現可能な技術としては、パケットの転送処理、VPN、帯域制御
（QoS）、ネットワーク仮想化、ロードバランスなどがあり、利用者は環境に合わせた機能のみ
を対象の物理/仮想 OpenFlow 対応スイッチに実装する事が可能となっている。
現在広く利用されている、または開発が続けられている SDN コントローラとして、Trema、
Ryu、OpenDaylight、POX などがある。
2.1.1.4.2 SDN コントローラの多様化
現在、SDN コントローラは多様化の兆しをみせている。当初、SDN コントローラと OpenFlow コ
ントローラ（Ryu、Trema など）は同義として扱われることが多く、OpenFlow 対応スイッチを使
用したネットワーク構築に必要なコンポーネントの一つにすぎなかった。また、レガシースイッ
チのみで構成された従来のネットワークは SDN コントローラの管理/制御下におくことが出来
ず、SDN との連携が難しいものとなっている。この事から、SDN の有用性は認知しているが、実
際にユーザ企業では非常に導入しづらいものとなっていた。
しかし、現在の SDN コントローラは多様化するに伴い、定義が変わりつつある。これまでのよ
うに OpenFlow 対応スイッチのみを管理/制御対象としたものから、レガシースイッチ/ルータと
の連携を意識した NetConf、LISP、BGP、SNMP などのプロトコルを採用し、また、それらを使用
したレガシーネットワークの管理/制御や、OpenStack 等の仮想化基盤との連携、その他にも
OpenFlow 対応スイッチのコンフォーマンステストなど、測定器としての利用シーンなども検討さ
れている。
2.1.1.4.3 今後の取り組み
OOL では、SDN コントローラへの取り組みとしてレガシーネットワーク(Layer2 ネットワーク、
広域ネットワーク)、OpenFlow ネットワークなどの複数のネットワーク技術を連携させ、統合し
た１つの E2E(End-to-End)ネットワークの実現を目指している。
この E2E ネットワークを実現するにあたり、昨今 SDN コントローラのプラットフォームとして
高い注目を浴びている OpenDaylight を採用する。数ある SDN コントローラから OpenDaylight を
選んだ背景は、OpenDaylight が広範なネットワーク技術をサポートしていることである。複数の
ネットワーク技術を統合するために、他の SDN コントローラで実現しようとすると、サポートす
るネットワークプロトコル(SouthBoundProtocol とも呼ばれる)も少なく(OpenFlow、OVSDB、
NetConf など)あらゆるネットワーク機器を制御するために種類の違う複数の SDN コントローラを
連携させる必要があり、それらの SDN コントローラを一元管理するのは困難かつ非常に大きな手
間がかかる。
しかし、OpenDaylight の SDN コントローラはほぼ全てのネットワーク機器を制御するためのネ
ットワークプロトコルをサポートしているため、OpenDaylight のみで複数ネットワークが制御で
きるので、管理が簡単になるのは大きなメリットと考える。
この理由より、OOL では OpenDaylight を活用し、Proof Of Concept（以下、POC）を通じて統
合した E2E ネットワークの技術検証を実施する。
39
① 目的
OpenDayLight で各種ネットワークを統合することを目的とする。最初の取り組みとしては、
OpenFlow、BGP、SNMP を選定し、これらのプロトコルを連携させた POC を実施することにより、
実現性を評価する。
② OpenDaylight とは
OpenDaylight とは、Linux Foundation Collaborative Project の１つであり、オープンソー
スの SDN コントローラプラットフォームである。SDN コントローラではなくプラットフォームと
して公開してある理由は、コントローラ、インタフェース、プロトコルといった多様な実装のコ
ンポーネントをプラグインとして、他のコンポーネントの動作を止めることなく追加削除するこ
とが可能なためである。そのため、拡張性に優れ、開発をスムーズに行うことができる。
OpenDaylight は 2014 年 2 月に 1st バージョンである「Hydrogen」がリリースされ、現バージ
ョンの「Helium」では、開発に参画しているベンダ数が 40 を超え、SDN のプラットフォームとし
て高い注目を浴びていることもあり、今後の SDN 技術において重要なコンポーネントになると考
える。
OpenDaylight は機能を Project という単位で表現しており、複数の Project で構成される。以
下に Project コンポーネントのアーキテクチャ図 2.1.1.4.3-1 を示す。
図 2.1.1.4.3-1 OpenDaylight ソフトウェアアーキテクチャ
40
それぞれの Project は、大半が一つのベンダによって開発されているものが多いが、一部複数
ベンダが共同で開発しているものもある。
③ OpenDaylight を用いた POC
本節では、統合した E2E ネットワークを実現するために、最初にどういう目的でこの POC を開
発したか、次に数ある OpenDaylight の Project の中から、POC で使用する Project の概要、検証
環境、検証結果、最後に POC 開発で見つかった問題点、今後の課題について述べる。
OpenDaylight ではこれらのプロトコルをサポートする Project として、OpenFlow は VTN
Project、BGP は BGPCEP Project、SNMP は SNMP4SDN Project が対応する。ソフトウェアアーキテ
クチャで示すと以下の赤枠のモジュールが該当する。
図 2.1.1.4.3-2 POC で使用するソフトウェアコンポーネント
④ OpenDaylight Project 概要
本節では、今回使用する OpenDaylight の Project の概要について述べる。
・VTN(Virtual Tenant Network)
41
VTN とは、SDN コントローラ上でマルチテナント(※1)型の仮想ネットワーク(※2)を提供する
Project である。Southbound プロトコルは OpenFlow に対応しており、OpenFlow スイッチのみサ
ポートする。
※1:マルチテナント
物理ネットワーク上に、相互に隔離された複数の仮想面を構築し、それぞれの仮想面をテナント
としてユーザに払い出す。テナントごとに物理的に独立したネットワーク構成をとる必要がないた
め CAPEX や OPEX が削減できる。
※2:仮想ネットワーク
物理的なネットワーク機器の構成や設定を変更することなく、論理的にネットワークの構成を変
更可能なネットワーク。
VTN には以下のコンポーネントがあり、それらを使うための機能セットを利用することでマルチ
テナント仮想ネットワークを表現する。
表 2.1.1.4.3-3（a） コンポーネント一覧
コンポーネント
説明
vBridge
仮想 Layer2Switch
vRouter
仮想 Layer3Router
vTep
TEP(Tunnel End Point)
vTunnel
オーバーレイトンネル
vBypass
制御ネットワーク間のコネクティビティ
仮想インタフェース
interface
仮想ノードのエンドポイント(ポートのようなもの)
仮想リンク
vLink
仮想インタフェース間のリンク
仮想ノード
(vNode)
表 2.1.1.4.3-3（b） 機能セット一覧
42
機能
説明
VTN の追加、削除、変更
仮想ネットワークのプロビジョニング
VTN コンポーネントの追加、削除、変更
仮想ネットワーク上のフロー制御
flow filter(通過、廃棄、リダイレクト)
仮想ネットワーク上の QoS 制御
policing(帯域制御、通過、廃棄)
トラフィックの統計情報
仮想ネットワークのモニタリング
障害イベント
仮想ノードを作成した後、物理ネットワークのどの機器が紐付くかの情報(スイッチの dpid や
ポート番号など)を登録する必要がある。紐付ける方法として以下の機能が VTN に備わってい
る。
表 2.1.1.4.3-4 マッピング種別一覧
mapping key
マッピング種別
物理
論理(仮想)
Port mapping
Switch ID and Port ID vBridge interface
VLAN mapping
VLAN ID
vBridge
MAC mapping
MAC address
vBridge
例えば、Port mapping を使う場合、仮想ノードの「vBridge」を作成し、vBridge に対して
「interface」を追加する。追加した interface に対してマッピングさせる dpid とポート ID(ポ
ート番号)を登録する。
VTN には二つのソフトウェアがある。以下にそれぞれの役割を示す。
・VTN Manager
・OpenDaylight の SDN コントローラ内のコンポーネントとして実装
43
・REST API 経由で VTN モデルを作成することが可能
・作成した VTN モデルに従ってパケットの転送制御を行う
・VTN Coordinator
・Opendaylight の SDN コントローラとは別の独立したコンポーネントとして実装
・REST API 経由で VTN モデルを作成することが可能
・複数の SDN コントローラ(VTN Manager)に跨る VTN を制御
今回の POC では１つの SDN コントローラのみ使用しているため VTN Coordinator は使用しない。
以下の図に示す物理ネットワーク構成において、VTN を使って h1 と h3、h2 と h4 を同じテナント
に所属させるようなマルチテナント型の仮想ネットワークの作成手順を示す。
図 2.1.1.4.3-4 物理ネットワークと仮想ネットワーク間のマルチテナント
h1 と h3 を接続する場合
１．VTN1 を作成する
２．VTN1 内に vBridge を作成する
44
３．vBridge に interface を作成する(今回の場合 2 台の端末を繋げるので 2 つ作成)
４．vBridge の interface に h1 に繋がっている SW2 の datapathid とポート番号を登録する
５．h3 について 4 の手順を繰り返す
h2 と h4 についても同様に作成。この場合、h1 から h3 にはパケットが届くが、h2 と h4 にはパケ
ットは届かない。同様に h2 から h4 にはパケットが届くが、h1、h3 にはパケットは届かない。
・SNMP4SDN
SNMP4SDN とは、従来のスイッチ(Layer2 スイッチ)を制御する Project である。対応プロトコ
ルは SNMP。元々Layer2 スイッチは SNMP をサポートしており、機器監視などで利用される。
SNMP4SDN では標準 MIB（※1）で用意されている VLAN 情報と FDB(Forwarding DataBase)の書き換
えを行っている。従来では VLAN の設定を変更するには、人が対象の機器にログインして CLI ベ
ースで設定する必要があったが、SNMP4SDN では OpenDaylight の SDN コントローラから SNMP を利
用して設定変更が実施できる。したがって、機器ごとの設定マニュアルなどを覚える必要がな
く、プログラマブルに制御することで、OPEX も抑えることができる。ただし、現在は標準 MIB の
みを使用しているので必要な OID（※2）がない機器については SNMP4SDN では制御することがで
きない。
※1:MIB(Management Information Base)
情報を管理するためのフォーマット。機器の名称やインタフェースの情報や稼働時間など、一般
的に利用されるものが定義されているものを標準 MIB という。MIB は独自に拡張して定義すること
も可能。
※2:OID(Object ID)
MIB 上で定義された情報にアクセスする時に使用する ID
以下の図 2.1.1.4.3-5 に SNMP4SDN を利用した Configuration を示す。
45
図 2.1.1.5.3-5 SNMP4SDN を利用した Configuration
以下の表 2.1.1.4.3-6 に SNMP4SDN で使用される OID を示す。
表 2.1.1.4.3-6 OID 一覧
OID
説明
1.0.8802.1.1.2.1.4.1.1.5
リモートシステムに接続されているシャーシコンポーネント情報
1.0.8802.1.1.2.1.3.2.0
ローカルシステムに接続されているシャーシコンポーネント情報
1.0.8802.1.1.2.1.3.7.1.3
ローカルシステムに接続されているポートコンポーネント情報
1.0.8802.1.1.2.1.4.1.1.7
リモートシステムに接続されているポートコンポーネント情報
1.3.6.1.2.1.17.7.1.4.3.1.1
VLAN 名
1.3.6.1.2.1.17.7.1.4.3.1.2
ポートごとの許可するタグ VLAN 情報
1.3.6.1.2.1.17.7.1.4.3.1.3
ポートごとの許可しないタグ VLAN 情報
46
1.3.6.1.2.1.17.7.1.4.3.1.4
ポートごとのタグなし VLAN 情報
1.3.6.1.2.1.17.7.1.4.3.1.5
VLAN のステータス(有効、作成、削除など)
・BGP(Border Gateway Protocol)
BGP とは主にインターネット(Layer3 ネットワーク)の中核をなす自律型のルーティングプロト
コルである。OpenDaylight の BGPCEPProject では OpenDaylight の SDN コントローラから各 BGP
スピーカ(ルータ)に対して Configuration を行うことで Layer3 ネットワークを統合管理するこ
とを目指している。BGP を使った構成を以下の図 2.1.1.4.3-7 に示す。
図 2.1.1.4.3-7 BGP を使った構成
・OpenStack Service
OpenDaylight には OpenStack の Neutron と連携するためのインタフェースが実装されている。
OpenStack Service と連携できる project には VTN があり、連携イメージを以下に示す。
47
図 2.1.1.4.3-8 OpenStack-OpenDaylight 連携イメージ
⑤検証
SDN コントローラ多様化/オーケストレーションについての検証は、OpenDayLight 機能検証を
実施し、その後、OpenFlow-SNMP 連携機能検証を実施した。
■OpenDaylight 機能検証構成
OpenDaylight の機能検証構成を図 2.1.1.4.3-9 に示す。
48
図 2.1.1.4.3-9 OpenDaylight 機能検証構成
図 2.1.1.4.3-9 の構成では VTN と SNMP4SDN の機能検証を行っている。VTN では OpenStack の仮
想ネットワークを構築、SNMP4SDN では Layer2 スイッチの VLAN 情報を書き換えスイッチに接続さ
れている端末の通信を制御する。この構成では、互いのネットワークは独立して制御している。
■評価環境
・サーバ/クライアント
表 2.1.1.4.3-10（a） 評価環境サーバ/クライアント
スペック
Node
OS
CPU コア数 メモリ
OpenDaylight Controller ubuntu 12.04 LTS サーバ 2 コア
4GByte
OpenStack Control Node
ubuntu 14.04 LTS サーバ 4 コア
8GByte
OpenStack Compute Node
ubuntu 14.04 LTS サーバ 4 コア
8Gbyte
49
SNMP4SDN Node1
Windows 7
2 コア
4Gbyte
SNMP4SDN Node2
Windows 7
2 コア
4Gbyte
・スイッチ
表 2.1.1.4.3-10（b） 評価環境スイッチ
Switch Node
型番
OpenFlow Switch
HUAWEI CE6850
Layer 2 Switch
HP ProCurve Switch 2510
Layer 2 Switch
NEC QX-S4020P
Layer 2 Switch
Allied Telesis CentreCOM 8216XL2
Layer 2 Switch
Cisco WS-C2960-24TT-L
OVS
Open vSwitch ver 2.10
Layer2Switch は複数のスイッチを切り替えて評価を実施した。
【検証結果・課題】
・VTN 機能
オーケストレータに OpenStack を使用し、OpenStack Neutron の ML2 Driver に OpenDaylight
用の Driver(OpenStack iceHouse 版からデフォルトでコミットされている)を利用することで、
OpenStack の仮想ネットワークをマルチテナント型で自動構築することができた。
・SNMP4SDN 機能
評価環境で示すように 4 台の Layer2 Switch で検証を行った。SNMP4SDN で使用する OID への対
応機器一覧を表 2.1.1.4.3-11 に示す。
50
表 2.1.1.4.3-11 L2 スイッチ OID 対応可否一覧
型番
OID 対応可否
HP ProCurve Switch 2510
○
NEC QX-S4020P
○
Allied Telesis CentreCOM 8216XL2 ×
Cisco WS-C2960-24TT-L
×
OID に対応している機器に関しては VLAN-ID を変更することで接続されている機器間の通信を
制御することができたが、未対応の機器に関しては VLAN-ID を変更することができず、機器間の
通信を制御することができなかった。
【問題点・解決案】
・VTN と SNMP4SDN モジュールのインストール順によって正常に動作しない場合がある。
OpenDaylight のバグであるが、情報がなくインストール順についても検証が進んでおらず解決
は困難である。
・OpenStack 連携で VTN を使用した場合、OpenStack の各ノードに作成される OpenvSwitch 間に
物理スイッチ(OpenFlow スイッチ)がある場合、正常に通信が行えなかった。
原因は現時点で不明であり、今後の課題として解決する必要がある。
・SNMP4SDN モジュールの VLAN 設定機能にバグがあった。
プログラムを修正し、適用し直すことで解決した。
・SNMP4SDN モジュールの VLAN 設定は最新リリースの Helium 版ではタグ付き VLAN しか設定でき
なかった。
次期リリースでタグなし VLAN の設定機能がリリースされる予定である。
■OpenFlow-SNMP 連携検証構成
OpenFlow-SNMP 連携検証構成を以下の図 2.1.1.4.3-12 に示す。
51
図 2.1.1.4.3-12（a） OpenFlow-SNMP 連携検証構成１
図 2.1.1.4.3-12（b） OpenFlow-SNMP 連携検証構成２
図 2.1.1.4.3-12 の構成は以下のユースケースを想定している。
・企業内での利用
・プライベートクラウドを OpenStack で構築
52
・プライベートクラウドのネットワークは OpenvSwitch で構成
・オフィスネットワークは OpenFlow スイッチで構成
・オフィス内からプライベートクラウドのネットワークに Layer2 で接続を行う
この図では、Lyaer2 スイッチを SNMP4SDN から VLAN-ID を切り替えることでプライベートネッ
トワークとオフィスネットワークの接続を制御する。プライベートネットワークとオフィスネッ
トワークを VTN からマルチテナント型ネットワークを作成しようとしたが、OpenFlow スイッチの
物理トポロジーを検出するための LLDP を Layer2 スイッチが透過せず、物理トポロジーが検出で
きなかった。そのため、今回は Layer2 スイッチを HUB に置き換えて検証を実施した(図
2.1.1.4.3-12（b）)。
■評価環境
・サーバ/クライアント
表 2.1.1.4.3-13（a） 評価環境サーバ/クライアント
スペック
Node
OS
CPU コア数
メモリ
OpenDaylight Controller ubuntu 14.04.1 LTS サーバ 2 コア
4GByte
OpenStack Control Node
ubuntu 14.04.1 LTS サーバ 4 コア
8GByte
OpenStack Compute Node
ubuntu 14.04.1 LTS サーバ 4 コア
8Gbyte
Tenant1 Node
Windows 7
2 コア
4Gbyte
Tenant2 Node
Windows 7
2 コア
4Gbyte
・スイッチ
表 2.1.1.4.3-13（b） 評価環境スイッチ
Switch Node
型番
OpenFlow Switch
HUAWEI CE6850
Layer 2 Switch
NEC QX-S4020P
53
OVS
Open vSwitch ver 2.10
【検証結果・課題】
・OpenFlow-SNMP 連携検証構成１
プライベートクラウドの仮想ネットワークとオフィスの物理ネットワークを VTN から制御を行
おうとしたが、正常に動作させることができなかった。原因としては VTN で OpenFlow のネット
ワーク制御を行うためには OpenFlow スイッチ間の物理トポロジーを OpenDaylight の SDN コント
ローラが知る必要があるが、仮想ネットワークと物理ネットワーク間に SNMP と連携させるため
に接続した Layer2Switch が LLDP を透過させなかったためである。
【問題点・解決案】
LLDP 通信を行う際に使用される宛先マルチキャストアドレスとして、OpenDaylight の SDN コ
ントローラではフレームを透過しないアドレスが指定されている(このため Layer2Switch でフレ
ームがフィルタリングされ、その先の OpenFlow スイッチまでフレームが届かないのでトポロジ
ー検出が行えない)。
OpenDaylight コントローラ側にフレーム透過用のマルチキャストアドレスを指定すれば解決でき
そうだが、検証が必要である。
・OpenFlow-SNMP 連携検証構成２
OpenFlow-SNMP 連携検証１で Layer2Switch が原因のため LLDP が透過しなかったので、
Layer2Switch を HUB に置き換えて検証を行った。HUB に置き換えた場合、LLDP を透過し、正常に
物理トポロジーを検出することができ、VTN で仮想ネットワークと物理ネットワークをマルチテ
ナント型で接続することができた。
【問題点・解決案】
仮想ネットワークは OpenStack のネットワーク・VM 作成時に OpenDaylight 用 ML2Driver が自
動で VTN の作成を行っているが、物理ネットワーク側は手動で VTN の設定を行う必要がある。
OpenStack 環境とそれ以外の環境を統合管理するアプリケーションが必要である。
【今後の取り組み】
今回の POC では OpenFlow を使った仮想ネットワークと物理ネットワークの連携検証は実現で
きたが、複数ネットワーク技術(OpenFlow と SNMP)の連携は問題が発生した。しかし、原因は判
明し、その解決策までは明らかにできたので、継続して検証を続ける。さらに、WAN まで範囲を
広げたネットワーク連携の検証を行う。
54
￥
図 2.1.1.4.3-14 WAN 構成のマルチネットワーク連携
55
2.1.1.5 サービスチェイニング
従来のネットワークでは、装置への機能追加や機器の設定変更には長期期間を要する。また、
追加/変更において多大なコストが必要であるという課題がある。これに対し、サーバの仮想化
技術の発展により、従来は専用ハードウェアで実現されていたネットワーク機能が仮想化（ソフ
トウェア化）し、クラウドに集約できるようになると期待される。ネットワーク機能を仮想化
し、クラウドに集約する Netwok Function Virtualization(以下、NFV)を適用することで、機能
追加が用意になり、迅速なサービス追加や導入コストの低減が可能となる。一方、さまざまなネ
ットワーク機能が仮想化され、クラウドに集約されると、それらのネットワーク機能を必要なと
きに利用できるように、パケットをネットワーク機能に転送する機能が必要となる。サービスチ
ェイニングはユーザ毎に適切なネットワーク機能を経由するようにパケットの転送経路を制御す
る技術であり必要なときに必要なネットワーク機能の利用を可能とする。
2.1.1.5.1 サービスチェイニング環境構築プロジェクト
OOL のテストベッドを利用する会員へハードウェア構成からテストまでを Software-Defined 化
することを目的とする。サービスチェイニング プロジェクトでは図 2.1.1.5.1-1 の「Virtual
Network Function（以下、VNF）を選択し Chain を構成」の実現へ向けた環境の構築および検証
を行う。
図 2.1.1.5.1-1 沖縄オープンラボラトリ
56
テストベッド構想
① 構築環境
・利用機器およびソフトウェア
OOL 内の機器およびソフトウェアを利用し検証環境を構築した。
・物理サーバ
Express5800/R120d-1E 2 台
② 仮想化サーバ
・仮想サーバ: KVM
・仮想ゲスト OS: Ubuntu
③ ソフトウェア
・Cloudshell
2.1.1.5.2 サービスチェイニング システム構成
OOL では Cloudshell を利用し、サービスチェイニング環境の構築を行う。Cloudshell からサ
ービスチェインの構築は図 2.1.1.5.2-1 に示す構成にて実現する。
図 2.1.1.5.2-1 システム構成
57
① Gateway サーバ
Cloudshell 上で作成したトポロジーを OpenStack 上で構築されるまでは以下の流れにて行われ
る。本プロジェクトでは VNF 構築のためのオーケストレータ（Ansible、Chef、SaltStack）の選
択を可能とするため、Cloudshell と OpenStack 環境間に Gateway サーバ（以降、GW）を配置する
こととする。Cloudshell からサービスチェイニング構築を行うためのオーケストレータを選択す
ると、GW にて指定されたオーケストレータでの処理はすべて自動で行われる仕組みとなってい
る。
(１) Cloudshell から利用したい VNF を選択し、各 VNF を接続する。
(２) Cloudshell のトポロジーコマンドから GW に対して REST API でトポロジーを送信
(３) GW は受けたトポロジーを基に heat テンプレートを作成
(４) 作成されたテンプレートを OpenStack heat api を利用し OpenStack 環境での VNF を作成
(５) VNF に対し ssh にてアクセスし、各種 VNF サービスに必要となる iptables および flow 等の
設定を変更
② サービスチェイニングドライバ
Cloudshell ではトポロジーに対する処理を行うためにトポロジードライバを作成することがで
きる。本プロジェクトでは Cloudshell 上で配置した論理トポロジー（サービスチェイニング用
のトポロジー）を OpenStack 上に構築するために専用のトポロジードライバ（サービスチェイニ
ングドライバ）を作成した。
サービスチェイニングドライバでは、Cloudshell 上で配置された論理トポロジーを json 形式
で GW に送ることを可能にした。また、オーケストレータの選択をそれぞれトポロジーコマンド
として用意し、各オーケストレータの選択をトポロジーコマンド上での選択とした。図
2.1.1.5.2-2 のとおり、Cloudshell 上に作成したサービスチェイニング用のエンバイロンメント
にてドライバを設定した。
58
図 2.1.1.5.2-2 ドライバの指定
2.1.1.5.3 サービスチェイニング環境構築 検証
図 2.1.1.5.3-1 に示すとおり、クライアントからコンテンツサーバへのアクセスを想定し、コ
ンテンツサーバ、クライアント間にサービスチェイニングを構築する。イントラネット内のクラ
イアントからのアクセス検証のためファイアーウォールを配置し、および、コンテンツサーバに
対してのアクセススループットを向上させるため TCP ブーストを配置する。また、クライアント
からコンテンツサーバへのアクセス経路を変更、選択ができるようルータの配置も行う。
59
図 2.1.1.5.3-1 検証トポロジー構成
① Cloudshell に配置する検証トポロジー環境
Cloudshell 上に配置する VNF の目的について記載する。
表 2.1.1.5.3-2 検証にて利用する VNF
Cloudshell 上で配置する VNF
目的
ファイアーウォール
イントラネットからのアクセスの制御
TCP ブースター
パケットのスループット向上を図る
ルータ
パケットの経路選択および変更
60
図 2.1.1.5.3-3 Cloudshell 上に配置した VNF
2.1.1.5.4 サービスチェイニング環境構築 検証結果
本プロジェクトでは Cloudshell 上で配置した TCP ブースター、ファイアーウォール、ルータ
および各 VNF の接続が OpenStack 環境上に構築できることの検証を行った。以下の手順にて確認
を行った。
Cloudshell 上でトポロジー画面からサービスチェイニング構築コマンドを実行した。
図 2.1.1.5.4-1 Cloudshell からサービスチェイニング構築実行画面
61
OpenStack 環境上に Stack（heat テンプレート）が作成されたことを確認した。
図 2.1.1.5.4-2 heat テンプレート作成確認
各種 VNF がインスタンスとして作成されたことを確認した。
図 2.1.1.5.4-3 VNF 作成確認
62
各種 VNF がネットワーク上接続されたことを確認した。
図 2.1.1.5.4-4 VNF 間ネットワーク構成確認
2.1.1.5.5 今後の課題
本検証ではオーケストレータとして、Open Stack Heat を利用した。今後は各種オーケストレ
ータ（Ansible、Chef、SaltStack）を利用したサービスチェイン構築における検証を実施する。
VNF として利用可能なサービスを追加し、動作検証を実施する。
サービスチェイニング内に配置されたサービスの動的な追加/削除機能を実装する。
63
2.1.1.6 VNF 高速化
VNF 高速化プロジェクトの成果報告を以下に述べる。VNF 高速化プロジェクトのプロジェクト
オーナーは賛助会員であるブロケードコミュニケーションズシステムズ株式会社、メンバーに同
じく賛助会員であるイクシアコミュニケーションズ株式会社(以下、イクシア)、伊藤忠テクノソ
リューションズ株式会社等、多くの賛助会員が参加したプロジェクトである。
2.1.1.6.1 VNF 高速化プロジェクトの目的
仮想アプライアンスの高速化を”Lagopus”を用いて実行する。仮想アプライアンスは汎用サ
ーバ上の仮想化ソフトウェア環境で稼働するソフトウェアである。手軽に使える一方でパフォー
マンスが出ない懸念がある。KVM 上で動作する DPDK の対応が出来ていない仮想アプライアンスの
性能向上を目的として、KVM のブリッジ機能を”Lagopus”に置き換え、その上で仮想アプライア
ンスを実行することにより性能向上を図る。
2.1.1.6.2 VNF(Virtual Netwok Function)
ソフトウェアで実現された仮想化されたネットワーク機能を提供する技術である。
NFV(Netowork Functions Virtualisation)と呼ばれる仮想化技術を使いネットワーク機能を汎用
サーバ上で実現する機能のメインフレームワークである。
2.1.1.6.3 DPDK(Data Plane Development Kit)
Intel 社が開発した Linux 上で、ネットワーク処理に特化したアプリケーションを作成するた
めのソフトウェアライブラリー群である。DPDK を利用することで、ネットワークパケット処理を
行うアプリケーションを作成することが可能である。
DPDK を利用するアプリケーションは Linux カーネルを通過することなく、ネットワークインタ
ーフェイスカードが受信したパケットを直接処理することが可能になる。DPDK を利用すること
で、アプリケーションに特化したネットワーク専用の CPU コアが割り当てられる。CPU コアの性
能を限界まで使用することにより、ネットワーク性能を飛躍的に向上することが出来る。
2.1.1.6.4 Lagopus
日本電信電話株式会社の未来ねっと研究所が、総務省の委託研究「ネットワーク仮想化技術の
研究開発」の O3 プロジェクトに参画のうえで研究開発を進めているソフトウェアスイッチであ
る。OpenFlow1.3.4 に準拠し、データセンタだけでなく、広域ネットワークで利用される様々な
プロトコルに対応している。DPDK 技術を利用することにより、広域ネットワークで要求される大
規模・広帯域な通信処理を可能としている。
2.1.1.6.5 VNF 高速化環境構築
VNF 高速化プロジェクトで構築した環境を以下に述べる。
① SDN Japan 2014 出展構成
64
SDN Japan 2014 に以下の図 2.1.1.6.5-1 のようなネットワークを構築し、展示を行った。テス
トベッドのサーバ 3 台と Lagopus(RS670-S16A)、テストツールにイクシアの IxVM を使用した。ネ
ットワーク及びテストツールの全てが仮想化された VNF 環境を構築した。
図 2.1.1.6.5-1 SDN Japan 2014 出展構成
SDN Japan2014 では、DPDK を利用したネットワークアプリケーションが動作し、VNF が構築で
きることを確認した。
② Okinawa Open Days 2014 出展構成
Okinawa Open Days 2014 に以下の図 2.1.1.6.5-2 のようなネットワークを構築し、展示を行っ
た。テストベッドのサーバ 2 台、テストツールにイクシアの IxVM を使用した。ネットワーク及
びテストツールの全てが仮想化された VNF 環境を構築した。DPDK を使う 2 つのアプリケーション
(Lagopus と Vyatta5600)を 1 台の汎用サーバ環境に実装した。
65
図 2.1.1.6.5-2 Okinawa Open Days 2014 出展構成
Okinawa Open Days 2014 ではネットワークの転送レートを測定した。データ転送レートは約
500Mbps が測定された。DPDK を使用しながらも転送レートが約 500Mbps に止まった理由は以下の
2 つと推測される。
・汎用サーバで使用しているネットワークインターフェイスカードがギガビット・イーサネット
であった。
・IxVM は DPDK に対応していない仮想アプライアンスであり、さらに KVM の Hypervisor が Linux
カーネルの Bridge を使用しているので、これらがボトルネックとなり速度が出なかった。
66
図 2.1.1.6.5-3 Okinawa Open Days 2014 展示画面
2.1.1.6.6 今後の課題
VNF 高速化プロジェクトの目的である“DPDK の対応が出来ていない仮想アプライアンスの性能
向上”は、Lagopus の開発が遅れているため達成できなかった。KVM のブリッジ機能に使用でき
る Lagopus ver.0.3 がリリースされ次第、再度評価を行い“DPDK の対応が出来ていない仮想アプ
ライアンスの性能向上”を実証する。
67
2.1.1.7 Inter-Cloud 機能の実現 - 広域拠点間接続
ネットワークの高速化、広帯域化、データセンタの広域化により、複数拠点をまたぐ分散仮想
データセンタが期待される。分散仮想データセンタでは、サイト A とサイト B と 2 つのデータセ
ンタにてそれぞれ 50％ずつのリソースを持ち、それをアクティブ／アクティブで稼働させること
で 100％のリソースを持つことが可能となる。遊休リソースはなくなり、災害時などには被害を
受けていないサイトに片寄せすることで事業継続も確保できる。縮退時 50％稼働というのは従来
のスタンバイサイトと同じだが、イニシャルコストおよびランニングコストを、大きく削減でき
る。
2.1.1.7.1 検証概要
OOL では広域データセンタ間での仮想データセンタにおける検証を想定し、OOL および台湾の
Institute for Information Industry（以下、III）間を VPN にて接続し、VNF をそれぞれの拠点
に配置しサービスチェインの構築を行う。沖縄に配置されたクライアントから台湾のサーバにチ
ェインを経由するアクセスを行い、サービスの動作確認を行う。
図 2.1.1.7.1-1 広域サービスチェイニング概略図
2.1.1.7.2 検証環境
① 利用機器およびソフトウェア
OOL 内、III 内それぞれの機器およびソフトウェアを利用し検証環境を構築した。
68
② ネットワーク機器
[OOL]
・Express5800/R120d-1E
[III]
・Express5800/R120d-1E
③ 仮想化サーバ
[OOL]
・仮想サーバ: KVM
・仮想ゲスト OS: Ubuntu
[III]
・仮想サーバ: VMware ESXi
・仮想ゲスト OS: Ubuntu
④ ソフトウェア
・SoftEther VPN サーバ
・SoftEther VPN クライアント
2.1.1.7.3 サイト間接続方式
沖縄-台湾間は SoftEther VPN を利用しインターネット経由での接続とした。OOL に
SoftEtherVPN サーバを設置し、III から接続するサーバに SoftEther クライアントを導入するこ
とで、インターネット経由での拠点間サーバの VPN 接続を可能とした。
① サイト間接続に利用した SoftEther VPN について
SoftEther VPN (“SoftEther”は「ソフトウェアによるイーサネット」を意味する）は、OSS
で、使用が簡単な、複数 VPN プロトコルに対応した VPN ソフトウェアである。SoftEtherVPN は
Windows、Linux、Mac、FreeBSD、および Solaris 上で動作することができる。
② 沖縄-台湾間の通信速度の測定
沖縄-台湾間を SoftEther にて VPN 接続を確立し、ping による速度測定を実施した。
69
③ 環境
[OOL]
・サーバ名： novacom1
・ホスト名： openstack
・ip アドレス: 192.168.2.54
[III]
・サーバ名： oolOpenStack
・ホスト名： ool
・ip アドレス: 192.168.2.210
④ 速度測定結果
沖縄側拠点から台湾側拠点へ ping 疎通にて速度の計測を行った。速度計測の結果、おおよそ
1.8Mbytes/sec という結果であった。以下は ping 実行結果である。
ool@oolOpenStack:~$ ping –c 5 192.168.2.54
PING 192.168.2.54 (192.168.2.54) 56(84) bytes of data.
64 bytes from 192.168.2.54: icmp_seq=1 ttl=64 time=151 ms
64 bytes from 192.168.2.54: icmp_seq=2 ttl=64 time=68.5 ms
64 bytes from 192.168.2.54: icmp_seq=3 ttl=64 time=68.9 ms
64 bytes from 192.168.2.54: icmp_seq=4 ttl=64 time=70.1 ms
64 bytes from 192.168.2.54: icmp_seq=5 ttl=64 time=69.1 ms
--- 192.168.2.210 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 68.545/85.685/151.544/32.935 ms
2.1.1.7.4 広域サービスチェイニング
① サービスチェイニング
本検証では台湾にあるイントラネットに沖縄のクライアントからアクセスすることを想定す
る。パケット遅延発生装置（Delay）およびファイアーウォールをサービスとし、パケット遅延
発生装置を沖縄、ファイアーウォールを台湾に配置する。それぞれのサービスは各拠点に配置
し、チェインを構築することにより、両拠点に配置するクライアント、サーバ間の通信にサービ
ス適用を行った。
70
図 2.1.1.7.4-1 沖縄-台湾間をまたぐサービスチェイニング
② VPN as a Service
複数の拠点内に存在するテナント間でのセキュアな接続を想定し、VPN as a Service（以降、
VPNaaS）を利用する。下図 2.1.1.7.4-2 の示す通り 沖縄、台湾 はそれぞれ net1, net2 が内部
ネットワークとなっている。それぞれの拠点内で外部ネットワークと内部ネットワークを接続す
るルータを Router1, Router2 とした。対向先のネットワークに向けた経路情報を明示的に設定
しない限り、net1 と net2 間は通信できないため、図で示す設定にて拠点間の VPN 接続を確立
した。図 2.1.1.7.4-3 から図 2.1.1.7.4-6 では VPNaaS の設定内容を記す。
71
図 2.1.1.7.4-2 VPNaaS 接続図
図 2.1.1.7.4-3 沖縄側 VPNaaS 設定 1
図 2.1.1.7.4-4 沖縄側 VPNaaS 設定 2
72
図 2.1.1.7.4-5 台湾側 VPNaaS 設定 1
図 2.1.1.7.4-6 台湾側 VPNaaS 設定 2
③ VXLAN
当検証ではルーティングを気にすることなくサービスチェイニングの構築が行える環境を実現
するために VXLAN オーバーレイを利用する。
データセンタ間でサーバリソースを共有する場合は、大規模 L2 ネットワークが必要となり、
構築と管理が困難となる。VXLAN は標準の L3 の IP ネットワーク上で動作するため、大規模 L2
ネットワークの構築を行う必要がない。
73
図 2.1.1.7.4-7 VXLAN 接続図
2.1.1.7.5 検証
本検証では沖縄をクライアント、台湾に設置したサーバをイントラネットに見立て、沖縄にあ
るクライアントから台湾に設置された http サーバから index.html をダウンロードした。構成は
図 2.1.1.7.5-1 のとおりである。
図 2.1.1.7.5-1 サービスチェインによる通信間経路
① 検証内容
パケット遅延は以下 2 つの設定を行い、それぞれの設定にてファイルのダウンロード速度の遅
延を確認した。
１．遅延あり
遅延: 200ms
74
パケットロス: 5%
２．遅延なし
遅延: なし
パケットロス: なし
② 検証結果
各設定においてクライアントが http サーバから特定ファイルのダウンロードが完了までに要
する時間はは以下のとおりである。
遅延あり: 600ms
遅延なし: 200ms
拠点を跨いだサービスチェインが動作することを確認した。
2.1.1.7.6 今後の課題
今回の検証では SoftEther VPN を利用した拠点間の接続を確立したが、速度が
1.8[Mbytes/sec]と低速なため、拠点間通信の速度改善について検討する。
75
2.1.1.8 APP フレームワークの実現-クラウドネイティブ（Rack）
2.1.1.8.1 RACK とは
RACK とは、Real Application Centric Kernel の略称で、CTC が開発し、OSS として公開して
いるアプリケーションフレームワークである。その基本概念となる OpenStack Native
Application は、OpenStack のリソース（たとえば、仮想マシンや仮想ネットワーク）を、アプ
リケーションから直接利用して動作するソフトウェアの事である。RACK は、”After the Cloud"
と呼ばれる OpenStack 上で直接動作するアプリケーションを簡単に作成するための仕組みを提供
しており、プログラマは RACK を使うことで、OpenStack との連携を意識せずに、OpenStack 上の
リソースをスケールさせることができ、かつ、従来のアプリケーションを最小限の移植作業で
RACK アプリケーションとして動作させることができる。
RACK の概念は以下のとおりである。
・機能（※）を持たせた仮想マシンを 1 つの実行バイナリファイルとして扱う。
※"機能"とは、アプリが動作するために必要な OS、ミドル、プログラムの事を指す。ここでの
プログラムは RACK の API を呼び出して動作するように作る。
・この実行バイナリを、OpenStack 上に展開することで、この仮想マシンは Linux プロセスのよ
うに振る舞い、何らかの仕事をする。
・このプロセスは、プログラムの中で記述に基づき、Fork して子プロセスを生成し、プロセス間
で通信を行う。
図 2.1.1.8.1-1 RACK の概念
76
2.1.1.8.2 RACK 検証の目的
OpenStack 上でアプリケーションがリソース（仮想マシンや仮想ネットワーク、その他）を自
律的にスケールさせるにあたり、仮想マシン間を連携させる場合、OpenStack API や外部ツール
を使用する必要がある。場合によっては、アプリケーション独自で機能を実装しなければならな
く、敷居が高い。RACK では、アプリケーションがプロセスやコンピュータリソースを扱うように
OpenStack の仮想マシンやその他リソースを操作することができるため、クラウドネイティブな
アプリケーション開発の敷居が低くなると考えられる。
OOL では、RACK が普及することにより、OpenStack を使ったアプリケーション開発が活発にな
ることを期待しており、以下のアプローチで、RACK の普及、開発促進に向けて活動する。
（アプローチ）
・RACK は、初期リリース段階で、アプリケーション利用実績が乏しいため、実際に利用する環境
を構築し、アプリケーションの動作を検証する。その検証を通じて、見つけた課題や問題点を開
発者へフィードバックを行う。
・RACK 対応アプリケーションを開発・利用しやすい環境を整える。
2.1.1.8.3 RACK 環境の自動構築と RACK アプリケーションの動作検証
① 目的
・RACK 環境の自動構築
RACK の公開後に環境構築方法を確認したところ、手順が煩雑なことがわかった。RACK アプリ
ケーションの動作検証では、分散処理の有用性を確認するために、OpenStack の構成台数、仮想
マシン数などいくつかの条件を変えた環境を構築する必要がある。従って、アプリケーションの
動作検証を行う前に、環境の自動構築が必要と考えた。
・CloudShell による RACK 環境の自動構築
テストベッドでは、検証機器の管理、デプロイ等は CloudShell を利用している。よって今回
の自動構築は、CloudShell を利用することとした。利用者が検証を実施する際、CloudShell の
エンバイロンメント上から RACK 環境構築の操作を行うことで自動構築が開始される。自動構築
は、CloudShell サーバと構成管理ツール Ansible が連携し、環境構築を行うことで実現される。
本機能の拡張にあたり、CloudShell の RACK 環境構築用ドライバを作成した。
77
図 2.1.1.8.3-1 自動構築のモジュール関連図
・RACK アプリケーションの動作検証
RACK アプリケーションを動作させ、分散処理の効果を確認する。
複数の仮想マシンで分散して円周率の計算を行う RACK のサンプルアプリケーション（モンテ
カルロ）を実行した結果を以下に示す。本検証により RACK による複数の仮想マシンでの分散処
理の有意性を確認した。
② 検証結果
表 2.1.1.8.3-2 RACK アプリケーションの検証結果
構成
構成１
構成２
サーバ台数
2
11
仮想マシン数
5
20
試行回数
3000000000
3000000000
実行時間（秒）
423
135
78
図 2.1.1.8.3-3 分散処理検証中画面
2.1.1.8.4 Web UI の構築
① 目的
RACK アプリケーションの実行はコマンドラインで行う前提となっており、繰り返しアプリケー
ションを実行する場合に手順が煩雑となる。その煩雑な手順を自動化し、Web 上からアプリケー
ションを実行できるようになれば、検証作業や RACK を使ったアプリケーション開発に貢献でき
ると考え、RACK アプリケーションを実行するための Web UI を開発するに至った。
② 機能概要
WebUI を使用するには、以下に示す通り Push 工程、Build 工程、Load&Run 工程の順に行う。
(１) アプリケーションのソース環境を GitHub にアップロードする。（Push 工程）
(２) 仮想マシンイメージを作成する（Build 工程）
(３) アプリケーションを実行する（Load&Run 工程）
79
図 2.1.1.8.4-1 WebUI 使用の流れ
図 2.1.1.8.4-2 WebUI 画面
80
③ 機能説明
(１) OpenStack 環境情報の設定
RACK アプリケーションは、OpenStack 環境上に実行環境を構築する。OpenStack へアクセスす
るには、URL や認証情報が必要となる。Web UI では、ユーザが入力した OpenStack 環境情報を
Web UI サーバ上に構築したデータベースに保存する。
OpenStack 環境情報は、複数の環境を設定することができ、ユーザは、Web UI 上で現在作業中
の OpenStack 環境を確認し、別の環境へ切り替えることができる。
(２) アプリケーションの仮想マシンイメージ作成（Application Builder 機能）
RACK では、アプリケーションから複数のプロセス（仮想マシン）を起動できるが、その際使用
する仮想マシンイメージは共通である。GitHub に登録されているソースや、必要なソフトウェア
のインストールスクリプト等の格納場所をあらかじめ指定しておけば、その格納場所からダウン
ロードし、アプリケーションが動作する仮想マシンイメージを作成する。作成したイメージ
OpenStack へ登録する。WebUI ではこれらの工程（BUILD 工程）を自動で行う。
BUILD 工程は同時に実行できる。また、表示画面では登録したアプリケーションは一覧表示、
及び各アプリケーションの Build 状態（実行中／完了）を確認できる。
(３) アプリケーションの実行（Application Runner 機能）
（２）で作成したイメージを指定して、アプリケーションを実行することができる。なお、
RACK アプリケーション毎に OpenStack 仮想ネットワーク環境を選択でき、各 RACK アプリケーシ
ョンを平行して実行することが可能である。また、RACK 上のファイルシステムのパスを指定して
おけば、アプリケーションの実行結果などを取得できる。
④ 実装方法
RACK は python で作成されており、OpenStack や RACK の関連ライブラリが python で実装され
ていることから、python ベースのコンポーネントを選択し、組み合わせて、Web UI サーバを構
築した。
81
図 2.1.1.8.4-3 WebUI の構成
主なコンポーネントは以下の通りである。
(１) RACK Application Test Suite
・OOL で開発したモジュールである。
・後述の各コンポーネントを使い、RACK の仮想マシンイメージ作成、アプリケーション実行の
自動化を行う。
(２) Django
・Web Application Framework である。
・ブラウザからの要求を受け付け、(1)の RACK Application Test Suite を呼び出す。
(３) OpenStack Client Library
・OpenStack の各コンポーネントのクライアントである。
・アプリケーションの Build 工程にて、アプリケーションの仮想マシンイメージを起動して、
Build 後のスナップショット作成や、アプリケーション実行時に選択する flavor 情報（※）の取
得などに使用する。
※仮想マシンのスペック情報のこと
82
(４) RACK Client Library
・RACK のクライアントである。
・Application の起動・監視・削除や、RACK の共通ファイルシステムから実行結果をダウンロー
ドする際に使用する。
(５) Fabric Library
・OSS のデプロイツールである。
・SSH 通信で仮想マシンへ接続し、任意のコマンドを実行する。
2.1.1.8.5 課題
実行状況ログの収集手段が確立されていないことが課題である。アプリケーション開発工程で
実行中のログを確認できれば、デバッグに有効である。
RACK のコマンド、API ライブラリでもその手段がないため、WEBUI でのログ収集の仕組み作
り、または RACK 本体へのログ API の機能追加を開発者と連携しながら検討していく必要があ
る。
2.1.1.8.6 今後の取り組み
・ユースケースの提案
・RACK を使ったアプリケーションの開発
・RACK API の不足機能を開発者にフィードバックし RACK の機能強化
83
2.1.1.9 Ryu Certification
OpneFlow の仕様準拠度テスト”Ryu Certification”を利用した、検証環境構築について述べる
2.1.1.9.1 Ryu Certification
テストパターンに従って試験対象の OpenFlow スイッチに対し、フローエントリやメーターエ
ントリ、グループエントリの登録、パケット印加を実施する。OpenFlow スイッチのパケット書き
換えや転送、破棄の処理結果と、テストパターンに記述された推測される処理結果の比較を行う
ことにより、OpenFlow スイッチの OpenFlow 仕様準拠度を検証するテストである。
2.1.1.9.2 Ryu Certification 環境構築の目的
OpenFlow スイッチの性能を評価するにあたり、OpenFlow 仕様準拠度のテストである”Ryu
Certification”を活用することにより、OpenFlow プロトコル ver.1.3 の準拠度を調査する環境
を構築する。新たな OpenFlow スイッチを導入する際、OpenFlow メッセージの処理の違いやバグ
などについて事前に調査することが可能になる。また、OOL 会員が新たに OpenFlow スイッチを開
発した場合、OOL に構築されている検証環境を利用することにより、中立機関である OOL を通じ
て OpenFlow の準拠度テスト結果を公表することが出来る。
2.1.1.9.3 Ryu Certification 構成
Ryu Certification 構成は以下の図 2.1.1.9.3-1 のようになる。OOL の環境では OFC は Ryu、補
助スイッチは Lagopus を使用している。補助スイッチの役割として OFC からのフローエントリ登
録や Packet-In メッセージ送信、スループット計測用のフローエントリ登録、Packet-Out メッセ
ージ受信によるパケット送信を正確に行う必要がある。
図 2.1.1.9.3-1 Ryu Certification 構成図
(RyuBook1.0 http://osrg.github.io/ryu-book/ja/html/switch_test_tool.html より)
84
2.1.1.9.4 Ryu Certification 試験の流れ
Ryu Certification 試験は以下の図 2.1.1.9.4-1 のような流れで実施される。OFC はテストパ
ターンファイルに記載されているフローエントリやメーターエントリ、グループエントリを試験
対象スイッチに登録する。次に補助スイッチが OFC からの Packet-Out メッセージを受信し、試
験対象スイッチにパケットを送信する。試験対象スイッチはパケット処理後、補助スイッチにパ
ケットを送信する。補助スイッチはパケットを受信し、OFC に Packet-In メッセージとして転送
する。
図 2.1.1.9.4-1 Ryu Certification 試験イメージ
(RyuBook1.0 http://osrg.github.io/ryu-book/ja/html/switch_test_tool.html より)
① OOL 独自テストパターン作成
Ryu Certification は OpenFlow の仕様準拠度を調査する試験である。いわば、OpenFlow スイ
ッチの単体試験である。しかし、運用に導入する際には単体試験だけでは評価が足りないので、
OOL では複数のフローエントリを組み合わせた独自のテストパターンを作成し、Github に公開し
た。
(URL: https://github.com/oolorg/ool-ryu-certification)
85
図 2.1.1.9.4-2 公開テストパターン
2.1.1.9.5 Ryu Certification サーバ構築
OOL で構築した Ryu Certification サーバは、CI(Continuous Intergration)環境を構築するこ
とにより、継続的に Ryu Certification 試験を実施する。さらに、Ryu Certification 試験結果
を Github に公開する。また、Ryu Certification サーバは Docker を利用して構築した。
① Dockerfile 公開
OOL で構築したサーバの Dockerfile や環境構築に必要な設定ファイルを github に公開した。
公開された Dockerfile を利用すると Ryu Certification 試験を実施する CI 環境が簡易に構築出
来る。
(URL:https://github.com/oolorg/ool-ryu-certification/tree/docker)
86
図 2.1.1.9.5-1 公開 Dockerfile
2.1.1.9.6 Ryu Certification 試験実行手順
OOL で継続的に実施されている Ryu Certification 試験の実行手順を以下に記載する。この試
験実行手順を実行すると通常の Ryu Certification に加え、OOL 独自のテストを実施し、試験結
果が github に公開される。
(１) Web ブラウザを利用し、Ryu Certification サーバにアクセスする。
(２)“OOL_Ryu_Certification”をクリックする。
87
図 2.1.1.9.6-1 スタート画面
(３) 画面左端にある一覧からパラメータ付きビルドをクリックする
図 2.1.1.9.6-2 OOL_Ryu_Certification プロジェクト画面
(４) 試験対象スイッチ名称(TARGET)と試験対象スイッチの dpid を指定する。OOL では試験対象
スイッチ名称を”開発企業名_スイッチ名”としている。
(５) ビルドを押下し、Ryu Certification 試験を実施する。
88
図 2.1.1.9.6-3 試験設定画面
(６) Ryu Certification 試験終了後、github(URL:https://github.com/oolorg/ool-ryucertification/tree/gh-pages)にアクセスし、試験結果を確認する。
図 2.1.1.9.6-4 Ryu Certification 試験結果画面
89
2.1.1.9.7 今後の課題
OOL 独自のテストパターンの充実を図る。現在、OOL が公開しているテストパターンは少な
い。今後、実運用を想定したテストパターンを作成し、公開する。
90
2.2
対外活動（展示会、学会発表）
以下に、本年度に行った展示会、学会発表等を記載する。
2.2.1
展示会出展
OOL では、以下を目的として展示会に出展した。
・ラボの活動を理解・賛同してもらう
・ラボの活動に意見をもらい、協力や入会を促す
出展した展示会は以下である。
(1) Interop Tokyo 2014（2014/6/11～6/13
幕張メッセ）
(2) SDN Japan 2014（2014/10/30～10/31 恵比寿ガーデンホール）
(3) Okinawa Open Days 2014（2014/12/11～12/12
沖縄県市町村自治会館）
(4) OpenStack Days Tokyo 2015（2015/2/3～2/4 グランドプリンス高輪）
以下に順に記載する。
2.2.1.1 Interop Tokyo 2014
「Interop Tokyo」は、時代の先端をゆく最新の技術や製品の発表、デモンストレーションの
場として毎年多くの注目を浴びるイベントであり、Interop Tokyo 2014 では述べ 132,609 名の入
場者があった。
OOL の展示ブースでは、多くの正会員・賛助会員・特別会員の担当者だけでなく、会員以外で
37 社、49 名の訪問があった。
展示ブースでは以下の展示を行った。
・テストベッド
・広域オートスケール
91
「テストベッド」では、OOL に構築しているクラウド／SDN 検証環境を紹介し、「広域オート
スケール」では、広域ネットワーク上でのオートスケールの仕組みを、クラウドおよび SDN の技
術を活用して実現した POC を紹介した。
図 2.2.1.1-1 テストベッド画面イメージ
図 2.2.1.1-2 広域オートスケール
また、会員企業と連携し、IXIA、QualiSystems の各ブースと OOL のテストベッドを接続した出
展も実現した。
展示ブースのデモでは、「ShowNet デモンストレーション部門」において、OOL の活動内容が
認められてファイナリストの１つに選ばれ、知名度を上げる一つの要因になった。
92
2.2.1.2 SDN Japan 2014
「SDN Japan」は、SDN に関する最新の情報提供の場であり、参加者が企業や組織の枠を超えて
ビジネス面や技術面などに関する議論を交わす機会を提供することを目的としている。2012 年よ
り毎年１回開催されている SDN に特化したイベントである。SDN Japan 2014 では述べ 949 名の入
場者があった。
OOL の展示ブースでは、多くの正会員・賛助会員・特別会員の担当者だけでなく、会員以外で
23 社、28 名の訪問があった。
展示ブースでは以下の展示をおこなった。
・テストベッド
・サービスチェイニング
「テストベッド」では、OpenFlow スイッチをパッチとして用いてベアメタルでサーバとスイッ
チを自由に構成できることを紹介し、「サービスチェイニング」では、複数のオーケストレータ
と VNF から任意のサービスを選択してチェインを構成するシナリオを紹介した。
93
図 2.2.1.2-1 OpenFlow-Patch パネル
図 2.2.1.2-2 サービスチェイニング
2.2.1.3 Okinawa Open Days 2014
94
「Okinawa Open Days 2014」は、クラウドと SDN を融合した唯一のイベントである。クラウド
技術のなかでもホットトピックである OpenStack と、OpenFlow をはじめとした SDN 技術を沖縄か
ら発信し、広くオープンに情報収集・意見交換の場を作る国際会議として、OOL が主催してい
る。2013 年に続き 2 回目の開催となった。
Okinawa Open Days 2014 では述べ 554 名の入場者があり、OOL の展示ブースでは、約 20 社の
訪問があった。
展示ブースでは以下の展示をおこなった。
・サービスチェイニング
・VNF 高速化
・クラウドネイティブ
・マルチネットワーク連携
「サービスチェイニング」では沖縄と台湾の OpenStack 間を接続してチェインを実現するデモ
を、「VNF 高速化」では賛助会員のブロケードコミュニケーションズシステムズと連携し、高速
SDN ソフトウェア「Lagopus」を利用した仮想アプライアンス高速化のデモを、「クラウドネイテ
ィブ」では RACK を利用した検証環境の WebUI プロトタイプを、「マルチネットワーク連携」で
は OpenDaylight を利用した OpenStack 仮想ネットワークとレガシーネットワーク制御のデモを
紹介した。
図 2.2.1.3-1 サービスチェイニング
95
図 2.2.1.3-2 VNF 高速化
図 2.2.1.3-3 クラウドネイティブ
図 2.2.1.3-4 マルチネットワーク連携
96
2.2.1.4 OpenStack Days Tokyo 2015
「OpenStack Days」は、OpenStack に関する最新の情報提供の場であり、参加者が企業や組織
の枠を超えてビジネス面や技術面などに関する議論を交わす機会を提供することを目的としたイ
ベントである。OpenStack Days Tokyo 2015 では述べ 3,000 名の入場者があった。
OOL の展示ブースでは、多くの正会員・賛助会員・特別会員の担当者だけでなく、会員以外で
39 社、42 名の訪問があった。
展示ブースでは以下の展示をおこなった。
・サービスチェイニング
・クラウドネイティブ
「サービスチェイニング」では Patch VM を導入し VNF をダイナミックに追加・削除するデモ
を、「クラウドネイティブ」では RACK を利用した検証環境を WebUI により操作できるデモを紹
介した。
図 2.2.1.4-1 サービスチェイニング
97
図 2.2.1.4-2 クラウドネイティブ
2.2.1.5 展示会まとめ
展示会に参加して来場者と情報交換することによって今後の活動の参考になり、また OOL の知
名度が徐々に上がってきたことが収穫である。2015 年 2 月に開催された OpenStack Days Tokyo
2015 では OOL 常駐が初めて講演をおこない、聴講者の半分以上が OOL のことを知っているという
状況であった。
今後も、次世代 ICT 基盤技術の実用化や普及を目的として活動成果を展示会に出展していきた
い。
① 活動について評価されたこと
・会員になることでテストベッドを利用でき、また、いろいろなベンダの OpenFlow スイッチや
高価な測定器などを利用できる
・評価環境を自動構築できる
・人材育成できる
② 活動内容、テストベッドに対する要望
・e ラーニングを実施してほしい
・グローバルに活動してもらえると入会しやすい
・活動成果の公開に期待する
・物理サーバを大量に使用したい
98
③ OOL の組織、またメンバーにとって良かったこと
・会員と連携した展示をおこなうこともでき、会員と一体感をもつことができた
・OOL のロゴ楯、チラシを会員ブースに設置してもらい、OOL の展示ブースへの集客のために協
力関係を築けた
・展示会への出展前と比較して会員数が増え、多少なり出展の効果があったと思われる
・東京など人が多く集まる場所でいろいろな来場者と話し、セミナーなどに参加することで、沖
縄で作業するだけでは得られにくい知見を得られた
2.2.1.6 今後の活動や出展に向けての課題
・会員と今まで以上に連携した活動
・活動成果の公開
・OOL のさらなる知名度の向上
・会員入会に興味ある会社へのアプローチ
99
2.3
2.3.1
Service Design Study Group
活動の背景
SDN およびクラウドコンピューティングを融合した次世代の ICT 技術は、コンピュータ/ネット
ワークシステムにおいて、そのインフラストラクチャー(サーバ、ネットワーク、ストレージな
ど、以下インフラ)の構築、監視・更新設定などの運用の効率化、自動化への期待が大きい。
これまでのシステム・プラットフォームでは、想定される処理能力やデータ量、セキュリティ
などの制限に対して、最大の要求を前提にインフラの設計・構築を行うことが多い。一度構築し
稼動したインフラは、容易に止めたり、変更、拡張したりすることができず、その後に要求が変
更されたとしても、問題を回避しつつの稼動・運用か、大規模な入れ替えを行うことになる。
SDN やクラウドコンピューティングは、これらインフラの問題を解決する主要な技術要素とな
る。しかしながら、技術は効果的に使用することで、はじめて、その価値を得ることができる。
コンピュータ/ネットワークシステムを使用する場面において、それを使用する人、直接使用
する端末や機器、そのサービスを支えるサーバや専用装置、それらをつなぐ有線ネットワークや
モバイルネットワークなどの通信環境が、必要なときに、必要なリソース同士が、最適に結びつ
き、そこで処理をされ、流れるデータや操作などの制御が適切に実行されることが本来のインフ
ラのあるべき姿である。
ここでは動的、適切に配置、配分、接続されるこれらコンピュータ/ネットワークシステムの
リソースの提供と制御ができるインフラを効率的に実現することを念頭に活動を行う。例えば、
金融決済、オンラインリアルタイムゲーム、遠隔医療、高精度画像放送、スマートシティなど、
各分野により、その求められる要件が異なることは容易に推測される。
Service Design Study Group(以下、SDSG)では、これらを推測だけでなく、各分野の現場にお
いて、過去から現在に至る中で、各業務の推進や改善、IT 化などの施策に取り組まれて来た専門
家や研究者等を各業界から招聘し、これまでの取り組み、業界の最新動向、将来構想等に関する
講演や、参加者とのディスカッションの場をつくることを目的とする。ここでは、研究者の知見
を広げ、新しいユースケースの発見に繋げることや、そこで課題とされた事柄について、先進的
に研究・実証実験を行うための導入部分となることを想定している。
2.3.2
活動のアプローチ
SDN や NFV、クラウドコンピューティングのような、新しい概念を持つアーキテクチャについ
ては、現時点で存在する課題を解決することだけでなく、未来の社会を想定し、それを実現する
ための方法を検討する方法（バックキャスティング・アプローチ）が有効であると考える。
このバックキャスティング・アプローチにより、最先端の活動をしている多くの専門家や研究
者、サービサー、メディア関係者等と、インフラエンジニア視点では無い、最新情報、将来構想
等についてディスカッションを行うことが有効と考える。
バックキャスティング・アプローチは、将来を予想する際に、持続可能な目標となる社会の姿
を想定し、その姿から現在を振り返って今何をすればいいのかを考える方法である。 現状にと
らわれず、「すべて思うとおりになるとしたら、どういう姿にしたいか」を想い描きビジョンと
100
して設定することで、その上で、実現するために今取り組むべき施策を抽出することを念頭に置
く。
図 2.3.2-1 バックキャスティング・アプローチ
2.3.3
ワークショップ
SDSG では、先に述べたように、各業界・分野の専門家を招聘し、新しいユースケースの発見に
繋げる場をワークショップとして設定する。2014 年度は以下の、5 回のワークショップと、その
活動の延長で 1 回のスペシャルセッションを実施した。
表 2.3.3-1
2014 年度ワークショップ実施状況
テーマ
内容
実施日
第1回
映像
映像ビジネスの未来
2014 年 5 月 20 日
第2回
観光・公共政策
観光の未来と地域活性化
2014 年 8 月 25 日
101
第3回
医療・ヘルスケ
ア
医療社会の未来
2014 年 9 月 12 日
第4回
メディア
放送というメディアは未来をどうデザインするのか？
2014 年 11 月 28
日
第5回
ゲーム
いまゲーム業界で求められているサーバインフラとネッ
トワーク技術について
2015 年 2 月 20 日
ICT と医療イノベーションで世界が変わる：生体の可触
化と直感的医療
2014 年 12 月 12
日
スペシャ 医療
ルセッシ
ョン
2.3.3.1 第 1 回ワークショップ
①
テーマ
映像「映像ビジネスの未来」
②
日時・場所
2014 年 5 月 20 日（火） 13:00 – 16:30
NEC 芝クラブ 205
③
講師
・Videyo Japan
土田圭介
1995 年 マイクロソフト(株)入社、Redmond で Windows 開発の後、2003 年に帰国、2009 年
まで APAC のデジタルメディア担当。2010 年にベンチャーを起業、2014 年に Vidyo 入社。
・Ustream Asia Inc.
本島昌幸
1996 年 マイクロソフト(株)入社、1998 年よりデジタルメディアを担当、テクニカルエバ
ンジェリスト。2004 年にソフトバンク BB(株)入社、技術戦略室を経て、映像関連子会社立ち
上げに関わる。現在 TV バンク(株)及び Ustream Asia(株)にて CTO。
④
講演内容
・Videyo Japan
土田圭介
102
【Videyo の事業紹介】
QOS が保障されない環境においても快適なビデオ会議環境を提供する。
Quality に関する層ごとにビデオデータを分割し取り扱う技術を保有する。この技術によ
り、一般的な技術では 5%のパケットロスでビジュアルコミュニケーションに支障をきたす
が、この技術により 20%のロスでもコミュニケーションを成立させることができる。これに
より、インフラのリソースに負荷をあまり与えることなく、リソースやデバイスに合わせた
コミュニケーションを実現する。
マスメディアというより、N 対 N のコミュニケーションに適した方法である。
【ビデオの未来】
世の中にカメラデバイスがあふれており、これらをもっと使うコミュニケーションの世界
があってしかるべき。教育、医療、IoT 等へ、今までの限界を超えたアプリケーションがあ
ってよいのではないか。多数複数拠点・カメラを 1 箇所でコントロールする仕組みなどは面
白い。
・Ustream Asia Inc.
本島昌幸
【UStream の事業状況】
9100 万時間/年(常時 5 千人～1 万人視聴/日本×10 倍(世界))、5 千～8 千チャンネル/常時
(日本は 20%程度)
コンテンツモニタリング(常時監視)体制。通報の仕組み。地域によりレギュレーションに差
がある。
PlayStation4 や安価なライブ配信用配信デバイスによりライブ配信が容易にできるような
環境が整いつつあり、配信機会が増えてきている。
ソーシャルストリームとピークの関係性がある。
配信の分散に関しては、コンテンツパターンにより CDN の準備パターンをあらかじめテー
ブルで用意しておき、それに個別の対応を加える。
【ライブの未来】
UStream としてはインフラを提供するだけのためコンテンツの戦略はない。
ソーシャルとの関係とサイクルがある。
配信以外のエンコーダ、スイッチング、プロダクションなどが End2End でクラウド化され
る可能性が高い。
今後動画広告の伸びが期待でき、いろいろなベンチャーが出てくる。
スマートテレビは、デバイスや視聴方法の多様化が明らかになり、位置感が明確になる。
103
⑤
今後の取り組むべき施策について
Google のビデオ会議の仕組みなども提供する Vidyo の土田氏から、Vidyo の仕組みを支え
る技術等を含め、ビジネスへの動画活用の現場について紹介があった。
特に、品質観点のレイヤーで切った動画データを、出力先の環境に合わせてルーティング
を行う技術には、本来の SDN のあるべき姿として、単に半静的なポイント同士をヘッダ的属
性情報のみでつなげる考え方だけでなく、流れるデータの配信元、配信先の状況や状態、ま
たそこで流れているデータの全体から見た場合の到達可否や優先度などに応じて、配信制御
を行う技術として成立させなければいけないのではないかと考える。また、その制御方式に
のみに頼ることなく、データ側も、配信制御される単位に分割されるべきであり、インフラ
側とマーケット側の両側の取り組みがあってこそ成立することであると考えると、なすべき
ことが見えてくるはずである。
Ustream Asia で CTO を務められる本島氏からは、大量のライブ動画トラフィックを扱う
UStream を支えるインフラの現場やその将来について説明があった。
同じライブでも、マスメディアに近いものと、監視カメラに近い、特定の人にしか視聴さ
れないものなど、目的や視聴パターンは多岐多様で、それぞれに適したインフラのあり方
や、サービスやその運用についても異なる要件が求められるものと考えられる。
後にも出てくることであるが、スマートフォンや PlayStation4 などデバイス側の進化によ
り動画はもちろん、ライブ配信の環境は整い、さまざまな局面で使われることになるだろ
う。これらをふまえ、一律でインフラを扱うのではなく、制御すべき要素を見極め、その要
素ごとと、その間の最適化をふまえた技術検討や検証活動が必要であると考える。また、ソ
ーシャルとの関係性はライブ内容や地域などに深い関係性があることがあり、ソーシャルコ
ンテンツを、意図をもってどのように全体を最適化していくかということはサービス視点だ
けではなく、インフラ視点でもそれをサポートできる仕組みが求められる。
図 2.3.3.1-1 第 1 回ワークショップの様子
104
2.3.3.2 第 2 回ワークショップ
①
テーマ
観光・公共政策「観光の未来と地域活性化」
②
日時・場所
2014 年 8 月 25 日（月） 13:00 – 17:00
イトーキ東京イノベーションセンターＳＹＮＱＡ
③
講師
・沖縄ツーリスト（株） 会長 東良和
1983 年 早稲田大学社会科学部卒（社会科学士）、1990 年 米国コーネル大学ホテル経営学
部大学院卒、1983 年 日本航空株式会社入社、1990 年 沖縄ツーリスト株式会社入社、2004
年 同社代表取締役社長＆CEO 就任（2014 年 2 月より会長＆CEO）
その他役職：一般社団法人日本旅行業協会理事、沖縄県ユネスコ協会 会長、沖縄経済同友会
副代表幹事、沖縄県教育委員会委員（2009 年 12 月任期満了）、WUB(Worldwide Uchinanchu
Business Association)沖縄顧問、沖縄県観光教育研究会 会長、Visit Japan 大使（国土交
通大臣 任命）、文部科学省日本ユネスコ国内委員会委員
主な委員会等：観光立国推進戦略会議ﾜｰｷﾝｸﾞｸﾞﾙｰﾌﾟﾒﾝﾊﾞｰ 内閣府・国交省（2004 年～07
年）、沖縄県振興審議会 第 13・14 期委員 沖縄県（2008 年～2012 年）、沖縄県振興審議会
産業振興部会部会長 沖縄県（2009 年～2012 年）、沖縄県観光審議会 会長 沖縄県
（2011 年～2013 年）
受賞等：1995 年 6 月 ツアーオブザイヤー・グランプリ受賞（日本旅行作家協会主催）、
2003 年 2 月 沖縄県ビジネスオンリーワン賞受賞『ECO マリンクラブ』事業、2013 年 3 月
ダイバーシティ経営企業 100 選（経済産業省）
・（株）MM 総研／国際大学（グローコム） 中島洋
日本経済新聞編集委員、慶応大学教授などを経て現職。IT 社会や IT 産業に関連した講
演・執筆活動を展開する。祖先が琉球王朝につながる縁で、近年は沖縄県の産業復興に携っ
ていて、特にＩＴ企業の沖縄誘致政策に協力している。
1947 年生まれ。東京大学大学院(倫理学)修士修了。73 年日本経済新聞社入社。産業部で
24 年にわたり、ハイテク分野、総合商社、企業経営問題などを担当。88 年から編集委員。こ
の間、日経マグロウヒル社（現日経 BP 社）に出向し、日経コンピュータ、日経パソコンの創
刊に参加した。97 年-02 年慶応義塾大学教授。98 年-08 年日経ＢＰ社編集委員。98 年-06 年
エヌ・ラボ株式会社代表取締役社長。
現在、MM 総研・代表取締役所長(03 年 12 月 1 日-)、首都圏ソフトウェア協同組合理事長、
全国ソフトウェア協同組合連合会会長、日本個人情報管理協会（略称 JAPiCO）理事長、オー
プン・コーポレイツ・ジャパン（OCJ）理事長、沖縄データセンター顧問などを兼務。
公職として、日本生産性本部・情報化推進国民会議・専門委員会委員長、IPA 未踏事業・審
105
議委員、BPIA 常任理事、企業情報化協会(ＩＴ協会)理事、総務省系 ASP・SaaS 普及促進協議
会副会長、総務省系データセンター促進協議会副会長、美ら島(ちゅらしま)沖縄大使などを
務めている。また、これまで、経済審議会専門委員、沖縄振興審議会専門委員、沖縄 IT 津梁
パーク検討委員会座長、沖縄ユビキタス特区「環境家計簿（えこ花）実証実験推進協議会委
員長」などを務めた。
日本経済新聞に連載中の大型特別企画広告シリーズ「キーワードで読むガイアの夜明け」
を監修、メールマガジンなど、定期コラムを多数、連載中。
④
講演内容
・沖縄ツーリスト（株） 会長 東良和
【沖縄リーディング産業としての観光】
第 5 次観光振興基本計画目標フレーム
１）観光収入
1 兆円
２）一人当たり消費額 10 万円
３）平均滞在日数
5日
４）人泊数
4,027 万人（国内客 3,152 万 外国客８７５万）
５）入域観光客総数
1,000 万人（国内客 800 万、外国客 200 万うち空路 175 万）
泊数の伸びが重要であり課題である(ハワイは平均 9 泊)
国際観光にはまだ伸びしろがある。
【沖縄観光の課題】
・航空座席の安定的な増加
・地元からの情報発信力の強化
・人材確保・人材育成と生産性向上
・働き手不足を解消する方策とイノベーション
・国家観光戦略特区に向けて（提案）
提供航空座席数の安定した増加とそれを支援する仕組みの構築
・ショッピングツーリズム日本一を目指して
従来と新規の外国人旅行者消費税免税制度の緩和
・ファミリーMICE リゾート沖縄の実現
子ども連れでも出張＆リゾートが楽しめる先進都市へ
・本格的医療ツーリズムの前の受入整備
海外旅行傷害保険加入外国人旅行者のキャッシュレス診療を
106
・海外競争力を欠くサービスの集約
特にエステ・スパ等、健康・美容産業のハード整備を官主導で（公設民営）
・多様化・高度化するニーズに対応するためのセントラルキッチン等
・持続可能な観光財源確保のための「沖縄観光宝くじ」の創設
・旅行業・運送業・通訳ガイド・道路や建築の規制緩和等
・沖縄観光の付加価値向上の為の時差、1 時間の導入
・（株）MM 総研／国際大学（グローコム） 中島洋
民間で進まないことを行政が呼び水として進める役割。
公共データはオープン化を前提とする。
【オープンデータがもたらすビジネスモデル】
・無償データ提供、有償加工サービス
リナックスやＨＡＤＯＯＰなどのフリー製品モデル
データは無償提供、データ加工サービス、分析ツールで課金
・内部相互補助、多面市場
無償提供し、別のビジネスに活かす、付加価値にする（グーグルマップ型）
・ネットワーク効果
協力、依存関係を含むエコシステムを形成
オープンイノベーション、同人市場、ロングテール
・ビッグデータ活用、より細かいニーズに対応
⑤
今後の取り組むべき施策について
沖縄県の観光の発展に大きく寄与されてこられた沖縄ツーリスト(株)殿の視点で、沖縄県
のリーディング産業である観光事業のさらなる発展のための課題と、幅広い視点での提言に
ついて説明があった。
様々な産業に広くかかわる観光産業において、IT を含むシステムの整備には多様な問題が
散見する。もちろん、デバイスの発展や通信網の整備、制度や政府支援策などの影響も大き
いが、例えば、ショッピングツーリズムの仕組みやビックデータとしての取り扱い、医療ツ
ーリズムの仕組み、サービス集約の情報流通・共有の仕組みなど、人材育成の仕組み、外国
語対応の仕組みなど、IT による仕組みの提供により敷居を大きく下げる可能性は十二分にあ
ると考える。
単なるバイト列であるデータではなく、活きたデータをどう取り扱うべきか、また、偏っ
た視点でなく、マクロな視点で世の中の仕組みを見ていく必要性を感じる。
107
沖縄に居を置く OOL として、先端的な ICT がどこまで「観光」の発展や多産業のつながり
に貢献ができるのか、引き続き取り上げていく。
同様の方向性において、多業種をつなぎ活性化する仕組みとして、公共の役割とデータオ
ープン化の施策は、クローズドなマーケットに対して、多くの相乗効果を産むことが予想さ
れる。クラウドが公共性や標準化を促進することにより、競争領域はビジネスモデルであ
り、仕組みは共有化されることで意味を持つ時代が来ることも予想され、そのためのオープ
ン活動の意義あいもますます高くなるものと考える。
これらの目線で、今後の活動の指針を立てて行く。
図 2.3.3.2-1 第 2 回ワークショップの様子
2.3.3.3 第 3 回ワークショップ
①
テーマ
医療・ヘルスケア「医療社会の未来」
②
日時・場所
2014 年 9 月 12 日（金） 14:00 – 17:30
イトーキ東京イノベーションセンターＳＹＮＱＡ
③
講師
・金沢大学附属病院 長瀬啓介
筑波大学 医学専門学群
1991/03 卒業 医師
筑波大学 博士課程 医学研究科
筑波大学 臨床医学系
生理系専攻 1997/03 修了 博士（医学）
講師 (1998/4/1-2003/1/31)
108
筑波大学 臨床医学系
助教授 (2003/2/1-2004/3/31)
京都大学 医学部附属病院
金沢大学 附属病院
助教授/准教授 (2003/6/1-2008/7/31)
教授 (2008/8/1-現在)
金沢大学 附属病院 副病院長 (2010/4/1-現在)
電機会社で設計をしていた父親の影響で、電子回路を組み立てることを遊びとして育つ。
結局医学部に入り医学部の学生をする傍ら、情報処理の専門学校での非常勤講師、コンピュ
ータ関係のライターをして過ごす。卒業後、医師として研修し呼吸器内科を専門として診療
する一方、大学院では医療経営学・医事法制・医療情報学の領域での研究を行い、以降これ
らの領域で研究・教育活動を行っている。
主たる研究主題は、人工知能技術の診療支援に対する応用、経営情報データベースの人工
知能技術による利用、通信用電磁波の医療機器への干渉、医療における通信技術の応用、医
療における患者の意思決定、国際化した環境における医療マーケティング、医療における企
業統制である。
所属学会： 日本医療・病院管理学会 評議員(2012-)、日本医療情報学会 評議員、理事
(2008-2012)、日本内科学会、日本呼吸器学会 呼吸器専門医、日本医事法学会、日本医療マ
ネジメント学会
・神戸大学大学院 医学研究科／株式会社 Eyes, JAPAN 顧問 杉本真樹
1996 年に帝京大学医学部を卒業。医師免許取得。専門は外科学。2004 年、医学博士の学位
取得。06 年より医用画像解析アプリ OsiriX(オザイリクス)の開発・普及に貢献。08 年、米
国カリフォルニア州退役軍人局 Palo Alto 病院客員フェロー。09 年より神戸大学大学院医学
研究科消化器内科学 特命講師。14 年より Apple にて世界を変え続けるイノベーターとして
紹介。(「Thirty Years of Mac」http://www.apple.com/30-years/2010/)
手術ナビゲーションシステム、3D プリンタによる生体質感造形など、医療・工学分野での
最先端技術開発で数多くの特許を取得。また国家プロジェクトとして先端医療産業特区, 生
命医学イノベーション創出リーダー養成プロジェクト等の推進を通じ,医療関連産業の集積に
よる経済活性化, 科学教育, 若手人材育成を精力的に行っている。また医療・教育・ビジネ
スなどの多分野にてプレゼンテーションセミナーやコーチングを多数開催。TEDxOsaka・
TEDxTiTec・TEDxSapporoSalon, TEDxFukuokaChange, TEDxKagoshimaUniversity にてスピー
カー。
所属学会等：日本外科学会 専門医・ガイドライン検討委員会委員、日本消化器内視鏡学会
専門医、日本内視鏡外科学会 技術認定取得者・医工連携推進委員、日本コンピュータ外科
学会 評議員、日本デジタル教科書学会 研究委員会副委員長、一般社団法人メディカル・
イメージング・コンソーシアム 理事
兼任：帝京大学 医学部医療情報システム研究センター客員教授、千葉大学 フロンティア
メディカル工学研究開発センター特別研究准教授、群馬大学 大学院医学系研究科 機能形
態学 客員准教授、九州大学 大学院医学研究院 先端医療医学講座 協同研究員、国立病院
機構 東京医療センター臨床研究センター 院外研究員、IMS 東京腎泌尿器センター大和病院
Robotic Surgery Center 技術顧問、有限会社ニュートン・グラフィックス 技術顧問
109
④
講演内容
・金沢大学附属病院 長瀬啓介
【医療への科学技術の適用】
人体という不変な事に対して科学技術や知識や知恵により変革の可能性を見出す、これま
での取り組み。
・人工知能（推論エンジン）を使った診断支援システム
・医療でのシームレスなユビキタスＭ２Ｍ通信基盤としての移動体通信（携帯電話）利用
・柔軟でセキュアな通信基盤
SDN/OpenFlow の導入
・通信基盤の広域化に対応した医療機器への脅威対策
・医療の国際市場化と国際医療協力
－幸福の追求
・神戸大学大学院 医学研究科／株式会社 Eyes, JAPAN 顧問 杉本真樹
【現場の最先端医療への ICT 技術の応用－直感的医療－可視化・可触化】
バーチャルだけでは伝わらないことを、3D プリンタに代表される IT を使って実体化し伝
えることの重要性。
・ソーシャルネイティブ、タブレットネイティブにおけるチーム医療
・医療画像の含めた可視化による、患者と医師間のコミュニケーションの充実
・ビックデータの応用
・将来的な遠隔医療もふまえた、先端技術を投入したロボット手術の発展
・3D や高精度画像、高速伝送技術を使った自然な画像による手術
・ウェアラブル端末やモーションキャプチャーによる直感的な手術
・プロジェクションマッピングによる人体への医療データの投影
・人体に合わせた素材での 3D プリンティングによる臓器の可視化、可触化
⑤
今後の取り組むべき施策について
IT 含めた技術にも造詣が深く、技術者とともに医療への新しい技術の検証や導入を追求
してきた長瀬先生から、これまでの取組や考え方について説明があった。
不変である人体に対して、変革の可能性を見出す要素として医療への科学技術の適用を進
めてきた中で、リスクを十分に考慮しつつも、SDN などの新しい IT 技術について、専門化
と共同で取り組み、適用し、実際に成果を上げてきている。
あくまで発注・請負という関係でなく、変革と成長を目指し、ともに取り組む姿勢と、そ
の場の創生について、OOL という団体であるからこそできることが多々あることを感じさせ
られるとともに、その立ち位置が明らかになったと考える。また、先端技術の医学応用を意
欲的に進めている杉本先生より、実際の活用や検証の様子の紹介などを交えて、先端技術を
110
活用した医療の一端について説明があった。
患者と向き合うために進めてこられた先端技術を使った可視化から可触化というアプロー
チに、医療にとどまらない可能性を感じることができた。
ロボットアーム等を活用した遠隔医療への展望、プロジェクションマッピングを活用した
可視化手術、タブレット端末や VR の応用、3D プリンタを活用した可触化の効用など、医療
データと最新の機器の組み合わせにより、先端 ICT が医療に大きく貢献できる可能性があ
る。
医療データの管理と共有・伝送、医療機器の制御、視覚化技術等、取り組むべき事項を選
択し、医療現場とともに継続的に取り組むべきと考える。
図 2.3.3.3-1 第 3 回ワークショップの様子
2.3.3.4 第 4 回ワークショップ
①
テーマ
メディア「放送というメディアは未来をどうデザインするのか？」
②
日時・場所
2014 年 11 月 28 日（金） 14:00 – 17:00
沖縄県市町村自治会館
③
講師
・TBS ディグネット 取締役 中尾聡
1987 年 TBS(現 TBS テレビ）入社
メディア系および事業系の職種を歴任
インターネット、BS デジタル、ワンセグ放送等デジタルメディアの立ち上げを多数経験
2010 年より TBS ディグネット取締役を担当
111
・琉球放送(RBC) テレビ編成局編成部 平川靖士氏
琉球大学卒業後、１９９６年、琉球放送株式会社入社。 東京支社営業部を経て休職、２
００１年国際大学（新潟県）国際経営学研究科 E ビジネス経営学コース入学。 ２００２
年卒業して復職後、報道部、本社テレビ営業部、東京支社営業部を経 て、２００９年よ
り本社編成部（テレビ）。
④
講演内容
・TBS ディグネット 取締役 中尾聡
・これまでの放送のデジタル、ネット、ソーシャルへの取り組み
・新しいテレビのあり方として、時間と空間の超越、双方向/ソーシャル、デバイスの
多様化、高精細化や新放送ネットワークの登場
・従来のマス広告モデルから脱却し、新しいコミュニケーションとビジネスを創出
・琉球放送の平川氏を交え、地方局の取り組みについて、人材や資金、権利の問題などに
課題を抱えながらも、放送のワークフローの発展や、ネットの活用に取り組んできた現
場の実情について紹介
⑤
今後の取り組むべき施策について
TBS という代表的なマスメディアの中で、常に新しい時代を先取りし、サービスとの融合
に取り組んできた中尾氏より、未来のメディア、テレビの方向性について説明があった。
様々な放送デバイスやネットの登場、また動画の高解像度化により従来のマス広告モデル
にから脱却し、新たな映像としての発展や、サービスの一部としてコミュニケーションを構
成するエコシステムの構築など、今後のメディアの方向性が示されたと考える。
従来のテレビ世代からは創造ができない社会とメディアの関わりの時代が目の前に来てい
る実感を持てることができたことで、サービス視点であるべきインフラの形を描く必要性を
強く感じることができた。
デバイスの多様化は進んでいるものの放送という形態は現在でも様々な生活やコミュニケ
ーションの入り口となっている。そこにおいてこれまでのデータを流すという考え方でな
く、その内容に着目し、同期や制御を加えることでさらなる発展が起きることを想定し、デ
ータ処理の方法論を考えていきたい。また、ネットサービスの発展で、メディア素材の取り
扱いの幅が広がり、例えば沖縄をはじめとした地域性を活かしたデータの取り扱いにより、
国際的なことやマスの視点から独立した、あらたな地域に根ざしたメディアの形態もあるの
ではないかと感じるところがある。
データ活用軸のひとつとして地域を置いた仕組みを構築できる可能性についても取り組み
の価値があると考える。
112
図 2.3.3.4-1 第 4 回ワークショップの様子
2.3.3.5 第 5 回ワークショップ
①
テーマ
ゲーム「いまゲーム業界で求められているサーバインフラとネットワーク技術について」
②
日時・場所
2015 年 2 月 20 日（金） 15:00 – 17:00
IT 津梁パーク
③
講師
・株式会社モノビット 代表取締役社長 本城 嘉太郎
1978 年生まれ。神戸出身。19 歳の時に出会った UltimaOnline、Diablo に衝撃を受け、将
来ネットワークゲームを作ると決意。システムエンジニア、コンシューマゲームプログラマ
を経て、2005 年にネットワークゲーム制作会社モノビットを創業。20 タイトル以上のネット
ワークゲームの開発と運営を手がける。2013 年にゲーム向け通信ミドルウェア『モノビット
エンジン』を販売開始。個人活動として、C マガジン記事執筆、CEDEC 講演、スッキリ!!出演
など。
・一般社団法人 沖縄ゲーム企業コンソーシアム 事務局長/株式会社ブリブザー 渋川 浩史
・株式会社ブリブザー 卜部(うらべ) 俊一郎
④
講演内容
・株式会社モノビット 代表取締役社長 本城 嘉太郎
113
日本の OnlineGame の歴史(特にサーバインフラの推移やビジネスモデルや規模について)
今後のゲーム業界やオンラインゲームの動向について
一般的なゲームインフラの構成について
今後のゲームインフラのトレンドについて
今後ビジネス的に期待されるゲーム周辺のキーテクノロジー
・動画配信
・リアルタイム通信
・セキュリティ
⑤
今後の取り組むべき施策について
特に日本においてはオンラインゲームの歴史が浅く、デバイスやビジュアルの面では技術
的に先行しているように感じながらも、サーバ系技術については発展途上の面があることが
分かった。しかしながら、トラフィックや処理負荷の特異性やその増減の激しさという面で
見ると非常にシビアなインフラ構成や運用が求められる分野でもあり、典型的なインフラの
モデルとして真っ先に取り組むべき要素があるものと考えられる。
また講演内でもあったように、デバイス側の移り変わりも激しく、サーバとクライアント
の関係性や、機器同士の通信という意味合いでは、様々なモデルが想定され、その多様性に
ついても取り組むべき価値が多々あると考える。
合わせて、リアルタイム性を考慮すると、大量の個人単位のプレイデータを処理し、状態
として反映しなければならないという処理のモデルについてもビックデータの典型的なパタ
ーンとして考慮したい。
ゲームというのは、ゲーミフィケーションといわれるように、例えば、観光や教育など社
会生活を円滑にわかりやすくしていく側面があり、今後の他業種への応用についても考慮し
ながら真っ先に取り組むべきモデルになると考える。
図 2.3.3.5-1 第 5 回ワークショップの様子
114
2.3.3.6 スペシャルセッション
①
テーマ
医療「ICT と医療イノベーションで世界が変わる：生体の可触化と直感的医療」
②
日時・場所
2014 年 12 月 12 日（金） 10:00 – 12:00
沖縄県市町村自治会館
③
講師
・神戸大学大学院医学研究科
特命講師 杉本真樹
医用画像解析、手術支援システム、生体医工学など、医療・工学分野での最先端技術開発
を進めながら、医療関連産業の集積による経済活性化, 科学教育, 若手人材育成を精力的に
行っている。また医療・教育・ビジネスなどの多分野にてプレゼンテーションセミナーやコ
ーチングを多数開催。2014 年 Apple 社 WEB サイトにて世界を変え続けるイノベーターに選
出。
・医療法人おもと会 大浜第一病院
内視鏡外科部長
稲嶺進
2001 年中頭病院在職中に内視鏡手術に衝撃を受け沖縄市の中頭病院にて本格的な内視鏡手
術を開始。県内で初めてとなる胃癌に対する腹腔鏡下胃切除術、胃全摘術、高度肥満に対す
る腹腔鏡下ルーワイ胃バイパス術、腹腔鏡下大腸全摘を導入してきた。本邦でほとんど行わ
れていなかった高度肥満の腹腔鏡手術の技術を 2004 年に導入、その技術を胃癌手術に応用
し、2007 年には本邦初の完全腹腔鏡下胃切除術を施行し学会報告。そして、2010 年には胃癌
に対する腹腔鏡下胃全摘で食道空腸吻合を針糸だけを用いて行う難易度の高い手術を本邦で
初めて成功させた。その後症例を重ね、その術式に対して 2012 年 11 月の日本内視鏡外科学
会でアワードを受賞。
④
講演内容
・神戸大学大学院医学研究科
特命講師 杉本真樹
「第 3 回ワークショップ」と骨子は同様。特にロボット(Pepper など)、およびアナログと
デジタルの融合について重点をおいた講演であった。
杉本先生の講演に続き、稲峰先生を交え、地域医療の格差について議論を行った。先端医
療の導入の遅れ(医療情報の活用の遅れ)から始まり、ビックデータとしての医療データの価
値(糖尿病手術に外科治療が有効であること etc.)まで議論が発展した。その中で地域だから
こそしがらみがなく破壊的イノベーションを起こせることもあるということが確認された。
115
⑤
今後の取り組むべき施策について
第 3 回ワークショップの内容から、特に医療データの活用についてさらに押し進んだ議論
が行われた。
健康と医療にかかわる医療データをビックデータとしての分析・解析を加えることで新た
な医療の可能性を見出すことができる可能性と、それらを知らしめることで価値を産むとい
うことを再確認した。データについては、貯めるだけでなく、伝送すること、解析するこ
と、わかる形にすること、知らしめることで価値を産む。このようなトータルデザインのも
とに技術の適用を思考することが重要である。
図 2.3.3.6-1 スペシャルセッションの様子
116
2.4
SDN・クラウドコンピューティングを担う技術者育成
SDN・クラウドコンピューティングは、情報通信分野において今最も期待されている技術の一
つであるが、その技術を習得している技術者は未だ少ない状況にあり、また、SDN・クラウドコ
ンピューティングの普及に不可欠なドキュメント類などをはじめとした支援環境が不足している
状況にある。
これらのことから、昨年度に引き続き SDN・クラウドコンピューティングの更なる実利用の促
進・拡大に必要不可欠な高付加価値 IT 人材の育成・確保および全体的な技術力の底上げを目指
し、沖縄県内の教育機関や関連施設を中心に、国内外に向けての産学横断的に推進することを目
的とする。
昨年度実施したイベントを踏襲しつつ、今年度は、SDN・クラウドコンピューティング技術を
同時に学べる多様なイベントを開催し、業界の中でも貴重な機会を提供した。 SDN・クラウドコ
ンピューティング技術の全体的な技術力の底上げを目的とした Basic プログラム(図 2.4-1)と、
各オープンソースコミュニティで活躍できる先端的なエンジニア育成を目的とした Advance プロ
グラム(図 2.4-2)を、今年度の実施のポイントとした。
また、 昨年度の成果（コンテンツ）の積極的活用やハンズオンセミナーの強化に取り組むと
ともに、現地教育機関と連携しながら、国外の学生や若手エンジニアへの SDN・クラウドコンピ
ューティング技術の普及促進を図った。
① 技術者育成（Basic プログラム）
SDN/クラウドコンピューティング技術の全体的な技術力の底上げを目的として、以下の各種の
技術者育成プログラムを実施した。
(1) 座学セミナー・ハンズオンセミナーの実施
SDN・クラウドコンピューティング技術研鑽を図るための座学セミナーやハンズオンセミナー
などを開催した。
(2) 国際会議（Okinawa Open Days 2014）の実施
2.5 SDN・クラウドコンピューティング関連の国際会議開催を参照
117
!
•
•
•
Okinawa Open Laboratory
図 2.4-1 技術者育成（Basic プログラム）
② 技術者育成（Advance プログラム）
各オープンソースコミュニティで活躍できる先端的なエンジニア育成を目的として、以下の各
種の技術者育成プログラムを実施した。
(1) OSS コードレビューの実施
SDN・クラウドコンピューティング技術を実現するために必要な OSS のプログラム（コード）
を読み解く（レビュー）ことで、OSS のバグを取り品質向上させることと、コードレビューする
ことによる SDN プログラム開発能力向上を目指す。
(2) アプリケーションプログラムコンテストの実施
SDN・クラウドコンピューティングに関するアプリケーションのプログラムコンテストを開催
し、独創性のある開発ができる技術者の支援と人材交流の場を設ける。
(3) 国際交流会の実施
『2.5 SDN・クラウドコンピューティング関連の国際会議開催』を参照
118
!
•
•
Okinawa Open Laboratory
図 2.4-2 技術者育成（Advance プログラム）
今年度は、具体的に以下の技術者育成プログラムを実施した。
① 技術者育成（Basic プログラム）
(1) 座学セミナー・ハンズオンセミナーの実施
SDN・クラウドコンピューティングの最新技術動向や本事業で培った研究内容を沖縄県内会場
およびサテライト会場を用いて広く共有した。また、OpenFlow コントローラやクラウドコントロ
ーラを実機の活用した演習により、最新技術の理解を深めた。
② 技術者育成（Advance プログラム）
(1) OSS コードレビューの実施
各 OSS コミュニティで活躍している最先端のエンジニアを講師に招き、直接指導・アドバイス
することで高いレベルのプログラム開発能力を育成した。
(2) アプリケーションプログラムコンテストの実施
テーマに基づく SDN・クラウドコンピューティング関連のアプリケーションプログラムを、国
内外および産学問わず広く募った。また、応募者にはプログラムのデモンストレーション・プレ
ゼンテーションを実施させ、優秀な人材を選考した。ここで選考した人材は、Okinawa Open
Days 2014 にて表彰式を実施し、将来の高付加価値 IT 人材の候補と見做し、オープンソースコミ
ュニティの国際会議に招待した。
119
③ コンテンツの整備
個別の学習が可能な様に、今年度のイベントの成果（講演資料、講演撮影ビデオ）を OOL のホ
ームページに掲載し、有効活用するように整備した。
2.4.1
SDN・クラウドコンピューティングを担う技術者育成に関する活動状況および実績
技術者育成プログラムの活動状況および実績を、表 2.4.1-1 と表 2.4.1-2 に示す。昨年と比較
して、各イベントに対し十分な準備時間を設け、合計 12 イベントを実施した。
表 2.4.1-1
技術者育成（Basic プログラム）
120
表 2.4.1-2
技術者育成（Advance プログラム）
また、各イベントについて、以下 URL の OOL ホームページにイベントレポートとして講演資料
および講演ビデオを掲載した（図 2.4.1-3）
http://www.okinawaopenlab.org/report
121
図 2.4.1-3 イベントレポート
2.4.2
SDN・クラウドコンピューティングを担う技術者育成に関する実施結果の振り返り
①参加者の比率について
各イベントにおける沖縄県内からの参加者の比率および、社会人・学生の比率を図 2.4.2-1 か
ら図 2.4.2-14 に示す。
◎沖縄県内からの参加者の比率
122
図 2.4.2-1
参加者の沖縄県内の比率（第 1 回ハンズオンセミナー）
図 2.4.2-2
参加者の沖縄県内の比率（第 1 回ハンズオンセミナー）
123
図 2.4.2-3
参加者の沖縄県内の比率（第 1 回 SDN/クラウドセミナー）
図 2.4.2-4 参加者の沖縄県内の比率
（Okinawa Open Days 2014 内スペシャルトラック Ryu/Lagopus ハンズオンセミナー）
124
図 2.4.2-5 参加者の沖縄県内の比率
（Okinawa Open Days 2014 内スペシャルトラック OpenStack ハンズオンセミナー）
図 2.4.2-6
参加者の沖縄県内の比率（第 2 回ハンズオンセミナー）
125
図 2.4.2-7
参加者の沖縄県内の比率（第 2 回ハンズオンセミナー）
◎社会人・学生の比率
図 2.4.2-8
社会人・学生の比率の比率（第 1 回ハンズオンセミナー）
126
図 2.4.2-9
社会人・学生の比率の比率（第 1 回ハンズオンセミナー）
図 2.4.2-10 社会人・学生の比率（第 1 回 SDN/クラウドセミナー）
127
図 2.4.2-11 参加者の沖縄県内の比率
（Okinawa Open Days 2014 内スペシャルトラック Ryu/Lagopus ハンズオンセミナー）
図 2.4.2-12 参加者の沖縄県内の比率
（Okinawa Open Days 2014 内スペシャルトラック OpenStack ハンズオンセミナー）
128
図 2.4.2-13
社会人・学生の比率（第２回ハンズオンセミナー）
図 2.4.2-14
社会人・学生の比率（第２回ハンズオンセミナー）
県外２拠点を含めたサテライト形式で実施した第１回 SDN/クラウドセミナーおよび Okinawa
Open Days 2014 スペシャルトラック内に開催した Ryu/Lagopus および OpenStack ハンズオンセミ
ナーを除き、沖縄県内からの参加者の比率が高かった。したがって昨年に引き続き、初級編、中
級編を中心として SDN/クラウド技術に関する県内の学生および若手エンジニアに対する訴求とい
う点では貢献できたと考えられる。
129
また、社会人・学生の比率については、社会人の比率が高かった。学生が参加しやすいセミナ
ーの参加手法の検討が課題であり、来年度はこの課題を考慮に入れた形での実施を予定してい
る。
2.4.3
各イベントの具体的な内容および考察（Basic プログラム）
① 第 1 回ハンズオンセミナー
開催概要とプログラムを図 2.4.3-1 から図 2.4.3-4 に示す。
図 2.4.3-1 開催概要（第 1 回 ハンズオンセミナー
130
OpenDayLight 編）
図 2.4.3-2
プログラム（第 1 回 ハンズオンセミナー
図 2.4.3-3
開催概要（第 1 回 ハンズオンセミナー
131
OpenDayLight 編）
OpenStack 編）
図 2.4.3-4
プログラム（第 1 回 ハンズオンセミナー
OpenStack 編）
OpenDayLight 編は OpenDayLight のハンズオンセミナーを実施するのが本邦初公開であったこ
とと、OpenStack 編についても、OpenStack ユーザ会として、OpenStack のハンズオンセミナーを
実施するのが国内初めてという事がトピックである。
イベント実施後のアンケートからは、以下のようなコメントがあった。
（OpenDayLight 編）
•
情報が少ない中、有益な情報を入手でき良かった。
132
•
資料の内容が充実していて良かった。フレームワークの説明をもう少し詳しくして欲しかっ
たです。
•
内容が充実して良かったと思います。時間がもう少しあるとよかったです。
（OpenStack 編）
•
OpenStack を使ったのは初めてでしたが、自分でもいろいろ触ってみたくなりました。
Ansible も今まで 使ったことがなかったので、業務でも使っていきたいです。
•
資料が充実しており、説明もわかりやすかった。業務に応用できそうなハンズオンテーマで
良かった。
•
有意義な教育でした。このような教育をこれからも開催して欲しいです。
このことから、ハンズオンセミナーは、SDN/クラウドコンピューティング技術を同時に学べる機
会として、学生、若手企業エンジニアに対して、大きく貢献できたと考えられる。一方、アンケ
ートには以下のようなコメントもあった。
（OpenDayLight 編）
•
事前の資料配布などで、大まかな流れを教えてもらえれば、事前準備がもう少し出来たのて
、事前の情報がもう少しいただければと思います。
゙
•
プログラム内容は導入にふさわしいものであったと感じています。大変満足でした。ただ
VTN のハンズオンにはコピー&ペーストが多く、ミスが減った反面、学習効果としては下がっ
てしまったのではないかと感じております。
•
ハンズオンについて:内容が駆け足だったのでもう少しゆっくり進めてほしい。
（OpenStack 編）
•
午後の実習はちょっと詰め込みすぎと思いました。
OpenDayLight 編は本邦初公開のハンズオンセミナーだったこともあり、講義側の準備不足が若
干あった。また、両ハンズオンセミナー共に講義時間の配分に対する課題もあった。来年度は、
これらの課題を考慮に入れた、講義準備、時間配分を行って行きたい。
② 第 1 回 SDN/クラウドセミナー
開催概要とプログラム、ネットワーク構成図を図 2.4.3-5 から図 2.4.3-7 にそれぞれ示す。
133
図 2.4.3-5 開催概要（第 1 回 SDN/クラウドセミナー）
134
図 2.4.3-6（a） プログラム（第 1 回 SDN/クラウドセミナー）
135
図 2.4.3-6（b） プログラム（第 1 回 SDN/クラウドセミナー）
136
MCU:
Okinawa Open Laboratory
図 2.4.3-7
ネットワーク構成図（第 1 回 SDN/クラウドセミナー）
中級を対象とし、沖縄発で東京、大阪に対して実施したサテライトセミナーに対するアンケー
トからは、以下のようなコメントがあった
•
OpenStack の Ironic や Neutron の新しい機能の説明がよかった。SDN の Lagopus の概要から
詳細がわかってよかった。
•
学生として参加しましたが、とても興味深い話が多く、沖縄という身近なところで行われて
いる各プロジェクトに関して様々なお話を聞かせ ていただき、充実したセミナーとなりま
した。
•
Openstack サミットに参加された方より、直接お話しを聞く事ができ、その他開発に関わっ
ている方の話を直接伺え 大変勉強になりました。
•
リモート会場の音響、映像がすごくクリアでよかった。
このことから、沖縄発で日本の各地へ SDN/クラウド技術の最新動向を発信したことにより、
OOL が先進な情報発信に取り組んでいることを伝えることが出来たと考えられる。また、今回
は、昨年に引き続き、シスコシステムズ合同会社の協力により、クラウド型のテレビ会議システ
137
ムを使用して映像中継を行った事が大きなトピックであり、前回のサテライトセミナーよりもセ
ットアップが短縮された。
一方、アンケートにはこのようなコメントもあった。
•
プログラム毎に聴者に求められるレベルがだいぶ違うので、レベルを合わせることや事前資
料(予習)があると嬉 しかったです。あと、佐藤氏の講演が一番とっかかりやすいので、プ
ログラムの順番を変えた方が良かったと思います。
•
全体的に内容が難しく感じ、理解はちゃんとできませんでした。
このことから、来年度はセミナーの対象となるレベルを定義し、講義についてもこのレベルを
意識した内容で作成するように心がけていきたい。
③ Okinawa Open Days 2014 内スペシャルトラック（Ryu/Lagopus ハンズオンセミナー
/OpenStack ハンズオンセミナー）
プログラムを図 2.4.3-8、図 2.4.3-9 にそれぞれ示す（開催概要は Okinawa Open Days 2014 を
参照）。
138
図 2.4.3-8 プログラム
Okinawa Open Days 2014 内スペシャルトラック（Ryu/Lagopus ハンズオンセミナー
図 2.4.3-9 プログラム
Okinawa Open Days 2014 内スペシャルトラック（OpenStack ハンズオンセミナー）
139
イベント実施後のアンケートからは、以下のようなコメントがあった。
（Ryu/Lagopus ハンズオンセミナー）
•
大変わかりやすい内容でした。ただ後半時間が足りていなかったのが残念でした。
•
継続されることを望みます。
（OpenStack ハンズオンセミナー）
•
学生として参加して難しい部分が多々あったのですが講師陣の親切なサポートもあり理解を
深めることが出来ました。
•
実際手を動かしてコマンドを打ったりととても楽しかったです。仮想的にルータを設置した
りなどの構築をしたことがなかったので すべてが初体験でとても興味深く充実したハンズオ
ンでした。
•
勉強になりました。後はもう少し自分でいじってみます。
このことから、講師陣の分かりやすい内容と手厚いサポートにより、参加者が大変満足してい
る事が伺える。
一方、アンケートにはこのようなコメントもあった。
（Ryu/Lagopus ハンズオンセミナー）
•
ハンズオン全体の流れを最初に説明したほうがいいのではないか。(特に Ryu ハンズオン)よ
くわからないまま作業を追っていた感じがす
•
時間が短く感じました。
（OpenStack ハンズオンセミナー）
•
Open Stack と言うより Ansible の半造音のような感じで期待は外れだった。例えばスナップ
ショットやそこからの戻し テンプレート化、ほかのクラウドからの移行、V2V(テナント間の
移動)など OpenStack にしぼってもいろいろなテーマが あったような気がする。
このことから、第１回ハンズオンセミナーと同様、時間配分に課題を残しているため、来年度
の考慮ポイントとして改善していきたい。
④ 第 2 回ハンズオンセミナー
開催概要とプログラムを図 2.4.3-10 から図 2.4.3-13 にそれぞれ示す。
140
図 2.4.3-10
開催概要（第２回 ハンズオンセミナー
SDN 編）
プ ロ グラ ム
平成27年2月6日（ 金） 13:00 - 17:00
概要
（ 内容）
- Dockerで ベアメ タ ル or VM環境内に実験NW環境を 作る → 箱庭NW
- Dockerの使い方
- Dockerを 駆使し た網ト ポロ ジ の作り 方
- BGPを 題材にし た箱庭ネッ ト ワーク を 構築する
（ 到達目標）
- 基本的な L2/L3のNWの知識の習得 - Dockerの使い方を 習得
- Dockerを 用いてNWト ポロ ジ を 構築する 方法を 習得
- BGPを 使っ たネッ ト ワーク の実験
・ 応募資格
以下の予習を 実施する こ と ま たは相当する レ ベルを 有する こ と
* 事前準備
1)
http://www.itbook.info/
・ ネッ ト ワーク エ ン ジニア のためのネッ ト ワーク の基礎(1)-(3)
・ TCP/IP(1)-(4)
・ イーサネッ ト
・ ルーティ ン グ
・ その他ネッ ト ワーク 豆知識
を 読破し て おく こ と
2)
持参する PCの仮想環境上に、 Ubuntu Server 14.04.1 LTS
( http://www.ubuntu.com/download/server ) を イ ン スト ールし て おく こ と 。
ま た、 Ubuntu仮想マシ ン から イ ン タ ーネッ ト に接続でき る 設定になっ ている こ と 。
プ ロ グラ ム/ア ジェ ン ダ
* 事前準備
1) * 予習の状況確認
- 質疑応答
- 簡単な 到達度確認テス ト
* BGPソ フ ト ウェ ア の説明（ 座学）
* Dockerと は（ 座学）
* Dockerを 使っ て シ ン プルな NWを 構築
* Dockerを 使っ て DCク ラ スタ を 構築
- BGPを 使っ たDCネッ ト ワーク
*質疑応答
図 2.4.3-11
プログラム（第２回 ハンズオンセミナー SDN 編）
141
図 2.4.3-12 開催概要（第２回 ハンズオンセミナー
OpenStack 編）
プ ロ グラ ム
平成27年2月7日（ 土） 13:00 - 17:00
概要
最近かなり 注目さ れて いる 技術に、 コ ン テ ナ型の仮想化技術があり ま す。
今回のセミ ナーでは、 コ ン テ ナ管理ソ フ ト ウェ ア の"Docker"や、
そのベース になる "LXC"を Ubuntu上にイ ン スト ールし ま す。
ハン ズオン を 交えて、 こ れら 新技術の使い方、 ま た、 内部的な仕組みの
理解を 深めて いただければと 思っ ていま す。
ま た、 2014年11月に発表さ れた"LXD"[1]に関し ての、 機能プ レ ビ ュ ー
も 行う つも り です。 "LXD"は、 通常のハイ パーパイ ザーと は異な り 、
"LXC"に対し て、 現在のハイパーパイ ザー技術が提供し て いる よ う な機能
を 実現する も ので す。
http://www.ubuntu.com/cloud/tools/lxd
* 事前準備
持参する PCの仮想環境上に、 Ubuntu Server 14.04.1 LTS
( http://www.ubuntu.com/download/server ) を イ ン ス ト ールし て おく こ と 。
ま た、 Ubuntu仮想マシ ン から イ ン タ ーネッ ト に接続でき る 設定になっ ている こ と 。
プ ロ グラ ム/ア ジェ ン ダ
* LXCの基本(座学)
* Apparmorの捕捉説明(座学)
* LXC環境の構築(ハン ズオン )
- LXC環境イ ン ス ト ール
- ホス ト 側の設定
- 基本操作
* ト ラ ブルシ ュ ーティ ン グ(ハン ズオン )
* OpenStackから のLXC利用(座学)
* LXCのユースケース (座学)
* 質疑応答
図 2.4.3-13
プログラム（第２回 ハンズオンセミナー OpenStack 編）
トピックとしては、クラウド/SDN 技術の中でも最新技術である、コンテナ仮想化技術を使った
142
ハンズオンセミナーであったことである。また、OpenStack 編については、Canonical 社とし
て、ハンズオンをはじめて実施した。
イベント実施後のアンケートからは、以下のようなコメントがあった。
（SDN 編）
•
わかりやすい解説で大変勉強になりました。
•
中級者向けとのことであったが入門に感じた。しかし非常にわかりやすい内容になっていた
と思う。
•
もう一度同じテーマをしてほしいです。理解度を向上させる為、再度受講したいと思いま
す。
（OpenStack 編）
•
非常にわかりやすい説明で理解できました。
•
再受講したいので同じテーマを希望します。
このことから、講師陣の分かりやすい内容と手厚いサポートにより、参加者が大変満足してい
る事が伺える。
一方、アンケートにはこのようなコメントもあった。
（SDN 編）
•
4 時間ではかけあしすぎて難しいかなと思いました。
（OpenStack 編）
•
HandsOn の資料をもっと step by step で表現してほしい。
•
もう少し時間を長くしても良いのではと思いました。
このアンケートからも時間配分が課題となっている事がわかった。
⑤ 沖縄オープンラボラトリ活動報告会
実施直後のため、報告書別紙に内容を盛り込む。
2.4.4
各イベントの具体的な内容および考察（Advance プログラム）
143
2.4.4.1 SDN/クラウドプログラムコンテスト
開催概要、選考委員とプログラム、最終選考メンバー、コンテスト結果を図 2.4.4.1-1 から図
2.4.4.1-5 にそれぞれ示す。
図 2.4.4.1-1 開催概要（SDN/クラウドプログラムコンテスト）
図 2.4.4.1-2 選考委員（SDN/クラウドプログラムコンテスト）
144
図 2.4.4.1-3 プログラム（SDN/クラウドプログラムコンテスト）
図 2.4.4.1-4 最終選考メンバー（SDN/クラウドプログラムコンテスト）
145
図 2.4.4.1-5 コンテスト結果（SDN/クラウドプログラムコンテスト）
トピックとしては、今年度は、国際的なコンテストに向け、年度当初に掲げていた英語をベー
スにしたイベントとしたことである。ホームページ案内は日英両方で行い、プレゼンテーショ
ン・デモンストレーション、質疑応答は英語で実施した。
最終選考会では、内容についても、学生、社会人のオリジナリティに溢れたアイデアであり、
また、急遽、選考委員として OpenStack Foudation Tom Fifield 氏も参加するなど、質疑応答
も大変活発に行われた。
今年度は、最終選考会を Okinawa Open Days 2014 の前日に行い、表彰式を Okinawa Open Days
2014 内で行った。各賞の発表と、グランプリの神戸情報大学院大学(KIC) 横山研究室チームの
鄒 暁明氏、鄒 明氏、後藤 聡文氏が開発した「Visualizing SDN and Virtual Environments
with Augmented Reality」いついては、プレゼンテーションとデモンストレーションを行い、イ
ノベーティブなアイデアで、会場内は盛り上がった。Okinawa Open Days 2014 のアンケートでも
•
プログラム 1 つ 1 つの内容が深く、非常に有意義な時間を過ごせました。個人的には最後の
プロコングランプリのプレゼンも聞けたので満足です。
といった意見があり、Okinawa Open Days 2014 と連携した効果的なイベントとなった
グランプリを受賞した発表者の指導教官である、神戸情報大学院大学 横山輝明講師からは以
下のようなコメントを頂いている。本プログラムコンテストが、一つの大きなマイルストーンに
なっていることが伺える。
146
今年度の反省点は、沖縄県内の学生・エンジニアからの応募がなかったことであり、来年度は
プログラムコンテストを支援できるような工夫も行って行く予定である。
2.4.4.2 コードレビュー（Okinawa Open Days 2014 内 BoF）
プログラムを図 2.4.4.2-1 に示す（開催概要は Okinawa Open Days 2014 を参照）。
147
図 2.4.4.2-1 プログラム（Okinawa Open Days 2014 内 BoF）
このイベントは、Okinawa Open Days 2014 の１日目の夕方から懇親会と平行して開催された。
コードレビューは軽い飲食を行いながら実施された。クラウド/SDN のオープンソース プラット
フォームである「Docker」「Vyatta」「OpenFlow」に関する第一線の関係者が参加し、開発者の
想いやアーキテクチャの紹介、利用方法、最新動向などを紹介する BoF（birds-of-a-feather）
と、これらのプラットフォームを使ったプログラミングを行い、開発者とのディスカッションを
実施した。
普段直接話す事のない第一線のエンジニアと話す機会は大変貴重なイベントであり、45 名の参
加者と活発な議論が展開された。
このように、現在最先端で活躍している SDN 業界、クラウド（OpenStack）業界、各々のキー
マンを講師に起用したイベントを開催した。講義内容についても、基礎の部分から設計思想の解
説やプログラミングコードのレビューなどの高度な内容にも対応したものであった。昨年度に引
き続き、SDN、クラウド技術を同時に学べることができる、国内外からみても業界内で数少ない
イベントであり、多くの好評を得た。また今年度の実績の特徴は以下が挙げられる。
•
今年度当初に計画した、クラウド/SDN を同時に学べるイベントを当初計画した 12 イベント
目標 100％達成
•
実施については、年間スケジュールを用意し、内容の精査、余裕を持った事前周知等を行
い、参加者に無理をかけない対応を行った
•
プログラムコンテストを英語で実施した
148
•
ハンズオンセミナーを強化した（２８名から８０名に増加）
上記のポイントで、本事業を実施したことで、都心でもなかなか体験できない先端的な講義内
容を沖縄県内で実施・発信したことについては、業界としても大きな注目を集めており、沖縄県
の技術者育成に対し大きく貢献したと考えられる。
2.4.5
SDN・クラウドコンピューティングを担う技術者育成に対する今後の課題
今年度の活動の結果、課題は以下の 3 点である。
まず 1 点目は学生向けのプログラムが不足していることである。
国際会議を含めた座学セミナー、ハンズオンセミナー実施後のアンケートでは、
•
学生向けのもっと分かりやすい内容の講座を行ってほしいです。
•
学生でもわかりやすいコースをやって欲しい。最先端の技術なのでわからない事が多いの
で、質問する時間も必要だと思いました。
という意見が散見した。また、セミナーの都度、県外から講師を招聘して行う事も、講師側の
稼働負担になっている。これらの課題を解決するため、基本的な座学セミナー、ハンズオンセミ
ナーに関しては、一定以上のスキルを持ったエンジニアでも講師となれる様に、今までのセミナ
ー素材を活用したパッケージを用意する。また、パッケージを利用し、OOL メンバーを講師とし
て学生向けの基本的な座学セミナー、ハンズオンセミナーを実施する予定である。
2 点目は、Advance プログラム（プログラムコンテスト、コードレビュー）についての参加者
が少なかったことである。特にプログラムコンテストは、県内の参加者がゼロであった。来年度
に向けては、プログラムコンテスト県内参加者を目指して、セミナー等のイベントだけでなく、
継続的なサポートが出来るような取り組みを検討する。
3 点目は、成果（コンテンツ）の積極的活用ができなかったことである。ほぼ全ての講演のビ
デオ、講演資料をアーカイブして OOL のホームページに掲載しているので、来年度は、これらの
素材をコンテンツとして活用するための具体的な実施案を検討して実践して行きたい。
149
2.5
SDN・クラウドコンピューティング関連の国際会議開催
SDN・クラウドコンピューティングについては、技術進歩が著しく、最新動向を定期的に集
積・発信する必要があるため、昨年度に引き続き、国際会議を沖縄県内で開催した。国内外にお
ける企業・研究機関の SDN・クラウドコンピューティングの有識者を一堂に集積し、技術テーマ
に関して議論・情報交換・発信を沖縄県内で行った。具体的には、国内外から SDN・クラウドコ
ンピューティング技術分野における有識者を招聘し、講演やパネルディスカッションを実施し
た。また、展示ブースを設け、SDN・クラウドコンピューティング技術の先端企業や学術機関か
らの出展を募り、製品やソリューションの紹介、並びにデモンストレーションを実施した。昨年
度の課題を踏まえ、SDN・クラウド技術を融合させたプログラムを充実させることと、本格的な
国際イベントに向けて同時通訳などの言語面でのサポートを充実させることを、今年度の実施の
ポイントとした。
また、SDN・クラウド関連のコミュニティメンバーと各コミュニティの現状および共通的な課
題に対するディスカッションを行った。
2.5.1 SDN・クラウドコンピューティング関連の国際会議開催に関する活動状況および実績
国際交流会として、クラウド/SDN インフラのセキュリティの観点から、セキュリティ・クラウ
ド/SDN に関係するエキスパートが一堂に会すハッカソンイベント「クラウド/SDN インフラセキ
ュリティハッカソン」を実施した。これは、OOL と、インターネット・クラウドなどのインフラ
セキュリティを研究する日欧国際共同研究コミュニティの NECOMA プロジェクト(NipponEuropean Cyberdefense-Oriented Multilayer threat Analysis)との共催であり、OpenFlow、
OpenStack へコントリビューションしている一線級のエンジニアが一堂に会し、堅牢なクラウド
/SDN インフラの開発を目指したディスカッションを行った。
国際会議については、昨年に引き続きクラウド（OpenStack）技術と SDN 技術を融合した唯一
のイベント｢Okinawa Open Days 2014｣を開催し、今年度は以下の２点をトピックとした。
•
昨年は同時期の中で個別に開催していた、「OpenStack Day」、「SDN Japan」のプログラム
を完全に融合し、ICT への関心と利用率の高い意思決定者、マーケティング担当者、クラウ
ド/SDN 技術に触れていきたいエンジニアを対象者としたジェネラルトラックと、クラウド
/SDN 技術に触れており、よりスキルを深めていきたいエンジニアを対象としたスペシャル
トラックという形で実施した。
•
国際的なイベントとして、国外、特にアジア地域の参加者を多く募るため、ジェネラルトラ
ックは全てのプログラムを英語で聴ける環境を用意した。
150
2.5.2 「クラウド/SDN インフラセキュリティハッカソン」の具体的な内容
図 2.5.2-1 開催概要（クラウド/SDN インフラセキュリティハッカソン）
151
図 2.5.2-2 イベントスケジュール（クラウド/SDN インフラセキュリティハッカソン）
2.5.3 「Okinawa Open Days 2014」の具体的な内容
開催概要を図 2.5.3-1、プログラムを表 2.5.3-2 から表 2.5.3-5 に示す。
図 2.5.3-1
開催概要（Okinawa Open Days 2014）
152
表 2.5.3-2
１日目プログラム（Okinawa Open Days 2014 ジェネラルトラック）
153
表 2.5.3-3
１日目プログラム（Okinawa Open Days 2014 スペシャルトラック）
表 2.5.3-4
２日目プログラム（Okinawa Open Days 2014 ジェネラルトラック）
154
表 2.5.3-5
２日目プログラム（Okinawa Open Days 2014 スペシャルトラック）
今回のプログラムの検討・講師の調整については、OpenStack ユーザ会、SDNJapan 実行委員
会、アカデミア、OOL から人選し、実行委員会を設立して実施した。
2.5.4 SDN・クラウドコンピューティング関連の国際会議開催に関する実施結果の振り返り
2.5.4.1 「クラウド/SDN インフラセキュリティハッカソン」について
2.5 日に渡るハッカソンは１日目に OpenFlow コントローラセッション、２日目に OpenStack
セッションが行われ、非常に濃い議論が展開された。クラウド/SDN のインフラにおいて、コント
ローラなどの開発が積極的に行われているが、コントローラそのもののセキュリティについての
議論はまだ十分ではない。今後、インターネットと同様な環境にコントローラが設置された場合
は、外部からの攻撃などを考慮に入れた堅牢性の検討が必要である、という共通認識のもと、実
際に OpenFlow コントローラの「Ryu」、OpenStack のコードを見ながら、課題提起とその課題に
対する解決策のディスカッションが行われ、さらに具体的にコーディングをして、解決策の提案
が行われた。その中でもトピックとして、以下の 3 つが挙げられる。
•
Security investigation discussion on OpenStack are very useful. Yuki-san's slide
is very good input for me and a nice startpoint
155
（参考資料）
OpenStack security
discussion
Cloud/SDN infrastructure security
Hackathon in Okinawa
Youki Kadobayashi / NECOMA Project / NAIST
図 2.5.4.1-1
The Slide of Youki Kadobayashi, Ph.D. Associate Professor
•
implementation for cloud security, 1) disable/enable PORT status automatically via
Neutron API, 2) sflow exporter
•
Extending Ryu-BGP: adding TCP-MD5, route filtering (ongoing), programmable route
injection
これらは、各 OSS コミュニティに反映されるよう検討が進んでおり、本ハッカソンが一定の成
果があったことを表している。
2.5.4.2 「Okinawa Open Days 2014」について
Okinawa Open Days 2014 では、昨年の来場者を上回り以下のような来場者を記録した。
•
Okinawa Open Days 2014 全体 延べ 554 名（登録 259 名※関係者除く）

１日目 293 名、２日目 261 名

（参考）Okinawa Open Days 2013: 延べ 500 名
•
スペシャルトラック

Ryu/Lagopus ハンズオン 15 名（登録 35 名）

OpenStack ハンズオン 15 名（登録 40 名）
•
Service Design Study Group
•
協賛セッション（NEC-SI）
23 名（登録 43 名）
24 名（登録 50 名）
156
•
協賛セッション（NEC）

SDN 事例セッション

SDN テクニカルセッション
38 名（登録 58 名）
26 名（登録 46 名）
•
懇親会 131 名（登録 140 名）
•
BoF 45 名
また、本イベントは沖縄県の後援ならびに、協賛９社１団体、協力５組織であった。
（昨年は協賛４社、協力２組織、１社）
図 2.5.4.2-1
Okinawa Open Days 2014 関係団体
2.5.4.3 参加者の状況について
Okinawa Open Days 2014 における参加者の比率を図 に示す。
◎沖縄県内からの参加者の比率
157
図 2.5.4.3-1 参加者の沖縄県内の比率（Okinawa Open Days 2014）
◎社会人・学生の比率
図 2.5.4.3-2 社会人・学生の比率の比率（Okinawa Open Days 2014）
沖縄県外からの参加者の比率が多いが、各イベントで 200 名以上が沖縄県内からも参加してお
り、多数の沖縄県内の技術者に対して国際会議を体感する場を創出できたと考えられる。また、
課題としては、海外からの参加者が昨年の 13 名から 22 名になり、増加したものの、全体からの
158
比率を考えると国際会議としては十分ではないので、来年度は Okinawa Open Days 2014 に対す
る海外へのプロモーション、参加に対する勧誘を強化していきたい。
また、学生の参加は 110 名となり、SDN・クラウドコンピューティング関連の最先端な国際会
議に学生も触れた事が分かる。
2.5.4.4 メディアの反応について
メディアについては、翁長知事の初公務であった事もあり、沖縄テレビの夕方のニュースに取
り上げられた。その他の掲載されたメディアについては、以下の通りである。
•
沖縄テレビ 12/11 OTV SUPER NEWS
•
琉球新報 12/7 朝刊、12/14 朝刊
•
沖縄タイムズ 12/11 朝刊、12/12 朝刊、12/14 朝刊
•
クラウド Watch 12/10

http://cloud.watch.impress.co.jp/docs/news/20141202_678364.html
沖縄県内の新聞一般紙の記事を図 2.5.4.4-1 に示す。
図 2.5.4.4-1 沖縄県内の新聞一般紙の記事
159
国内インターネットメディアの記事を図 2.5.4.4-2 に示す。
図 2.5.4.4-2 国内インターネットメディアの記事
写真 2.5.4.4-3 翁長沖縄県知事の県庁ご挨拶
2.5.4.5 実施結果の考察
Okinawa Open Days 2014 のアンケート結果から以下のようなコメントがあった。
•
ジェネラルトラック

プログラム 1 つ 1 つの内容が深く、非常に有意義な時間を過ごせました。個人的には最後
のプロコングランプリのプレゼンも聞けたので満足です。

プログラムやコンセプト、大変良い内容でした。

私自身は学生であり、実際の業務等には関わった事は無いのですが、今現在主流である技
160
術をたくさんの企業の視点から 知ることが出来、大変為になりました。又、今回 2 日間参
加して自分の知識不足を痛感したので、ここで初めて知った事はしっかりと勉強していき
たいと思います。

この分野では、基礎的な内容だったと思いますが、私のレベルでは SDN、NFV などについて
理解を深めることができました。 大変参考になりました。以降、参加の機会があれば予
め、ひととおりの勉強をして、基本的な知識はあるという状態で、受講したいです。パネ
ルディスカッション実例の 1 つだったと思います。インドでアウトソーシングが多いとい
う話はおもしろかったと思います。

今回初めて参加させて頂きました。同時通訳の設備は、大変良かったと思います。通訳の
内容も、専門用語が大変多いにも かかわらず、ほぼ完ぺきだったのではないでしょうか。
質の高いものでした。
•
スペシャルトラック

実際の業務での取り込みにおける経験を交えて語られていて、基盤導入に関して苦労され
た点が良く理解できました。

SDN テクニカルセッション今日一番の収穫でした。

説明がとてもわかりやすく、内容も事例を元にしているため、非常に勉強になりました。
今回のプログラム内容および同時通訳、プログラムコンテストの併設等の仕掛けについては、
狙い通りの結果となった。また、このイベントをきっかけとして、SDN・クラウドコンピューテ
ィングを勉強したい、技術を身につけたいという意思を持った学生が散見されたのが本イベント
を行った大きな成果であった。
一方でこのようなコメントもあった。
•
ジェネラルトラック

情報を学習している学生向けの内容もやってほしい

まだまだ未熟者なため内容をあまり理解できなかったのが残念でした。次参加する機会が
有るならもっと知識を持って参加したい

学生向けのもっと分かりやすい内容の講座を行ってほしいです。

学生でもわかりやすいコースをやって欲しい。最先端の技術なのでわからない事が多いの
で、質問する時間も必要だと思いました。わがままな要望になりますが、学生向けの少し
レべルをおとしたイベントなどがあればと思いました。もう少し親近感がわくよ うな話
題。学生もできる、と実感できるようなハンズオンにチャレンジしてみたい。

正直に言うとレベルが高すぎてよく分からなかった。でもその「分からない」から「知り
たい」に変り、調べて自分の力になった と思うとてもいい経験になった。
161
人材育成の章でも触れたが、学生向けのセミナーの開催を希望しているコメントが多く、来年
度のセミナー構成でこの意見を反映したいと考えている。
スペシャルトラックについての課題提起のコメントは少なく、スペシャルトラックに関する参
加者の満足度が高い事が伺える。
2.5.5 SDN・クラウドコンピューティング関連の国際会議開催に対する今後の課題
今年度も昨年度に引き続き、SDN とクラウドの二つの技術の融合をテーマとした国際会議
「Okinawa Open Days 2014」を開催した。先にも述べた通り、SDN とクラウドの二つの技術テー
マを一堂に会したイベントは業界唯一である。今年度はプログラムを融合に向けプログラム構成
を見直し、国際会議に対応すべく、同時通訳を用意した。これらのプログラム構成は国内外でみ
てもかなりレベルの高い内容であったと自負する。
一方で、国外からの参加者がまだ十分でないことから、来年度はプログラムのレベルを保ちつ
つ、参加者の対応・準備を検討していくことで、名実共に国際的な会議として実施し、沖縄県の
国際研究拠点としての地位向上に貢献して行く。
162
3.今後の課題
本事業における今後の課題を以下に総括する。
SDN・クラウドコンピューティング融合テストベッド研究活動では、クラウドおよび SDN 技術を
融合した検証基盤であるテストベッドを中心とした研究開発活動を行った。研究開発のテーマは、
テストベッド自体の広域化や規模拡張ならびに実利用を想定した高機能化を中心に選定した。今年
度の活動の結果、設定自動化や機能の高度化など、今後の実用化につながる成果を得ることができ
た。今後は、引き続き実用化に向けたテーマを中心に研究開発を行うとともに、オープンソースな
どによる成果の公開に取り組むこととする。
対外活動（展示会、学会発表）では、SDN や OpenStack に関するイベントや展示会を選定し、研
究成果の展示やデモンストレーションを行った。来場者と情報交換することによって今後の活動の
参考となる情報を得ることができ、また研究成果のアピールや OOL の知名度向上にも貢献できた。
今後も国内外においてイベント、展示会への出展や学会発表は継続し、また会員と連携したデモン
ストレーションの機会を増やすなど、より効果的な成果アピールが出来るよう取り組むこととす
る。
Service Design Study Group では、新たな取り組みとして、次世代 ICT 基盤技術を活用する様々
な分野の専門家を招聘し、利用者の視点においてディスカッションを行った。今年度の活動の結
果、今後の研究開発テーマに対する新たな知見を得ることができた。今後は本活動に継続的に取り
組むとともに、沖縄県内企業ならびに、ICT 技術分野以外の専門家と協業してクラウドおよび SDN
技術を活用した新たなユースケース開発に取り組むこととする。
SDN・クラウドコンピューティングを担う技術者育成では、ハンズオンセミナーやコードレビュ
ーなどの技術者育成プログラムを実施した。今年度は技術者のレベルによってプログラムを分け、
より効果的な育成結果が得られるよう取り組み、参加者からも好評を得た。一方、学生向けのプロ
グラム整備の必要性や成果（コンテンツ）の積極的活用といった新たな課題も明確になった。今後
は沖縄県内の学術機関等と連携して明確となった課題を考慮した育成プログラムを検討し、さらな
る SDN・クラウド技術の普及促進および技術者育成に取り組むこととする。
SDN・クラウドコンピューティング関連の国際会議開催では、昨年度に引き続き、SDN とクラウド
の二つの技術の融合をテーマとした国際会議「Okinawa Open Days」を中心としたイベントを沖縄
県内で開催した。Okinawa Open Days 2014 では、SDN・クラウド技術を融合させたプログラムを充
実させることと、同時通訳などの言語面でのサポートを充実させることをテーマとして取組み、昨
年度以上の来場者を実現するなど、大きな成果を上げた。一方で、国外からの参加者がまだ十分で
ないことから、今後はプログラムのレベルを保ちつつ、国外からの参加者に対する事前準備などを
検討していくことで、国際的にも認知度が高い国際会議として成長させ、沖縄県の国際研究拠点と
しての地位向上に貢献して行く。
163

コンピュータネットワーク分野の技術動向と展望（加藤）

全サイバーメディアセンターシンポジウムを開催します

iPOP2014で展示・デモの解説 - ITU-AJ

2013.07.17 エヌ・シー・エル・コミュニケーション株式

アテナ工業株式

基幹ネットワーク高度化への取組み を強化・加速

NTTコミュニケーションズ 技術開発部の取り組み