Download to read offline
![クラウド型データセンタにおける SDN の適用事例
Case Studies of SDN in Cloud Datacenter
土屋 太二*1
川村 聖一*1
Taiji TSUCHIYA Seiichi KAWAMURA
*1
NEC ビッグローブ株式会社 基盤システム本部
NEC BIGLOBE, Ltd. Platform System Division
1. はじめに
近年、サーバ仮想化技術や自動構築技術の発展により、
オンデマンドでインフラを提供する IaaS 型クラウドサービ
スが幅広く展開されている。データセンタ事業を展開する
BIGLOBE においても法人向けサービスとして、用途に応
じた数種類のクラウドサービスを提供している [1] 。
クラウドサービス事業をさらに発展・拡大させていくた
めには、ユーザからのあらゆる要求に対してスピーディか
つ柔軟に対応していく必要があるが、その実現のためには
データセンタにいくつかの課題が存在する。これらの課題
を解決するため、BIGLOBE では SDN ( Software Defined
Network ) を利用した自動構築システムを自社開発し、ク
ラウド型データセンタへの試験導入を開始した。
本論文では、導入した SDN 自動構築システムについて
説明する。
2. SDN 自動構築システム開発の背景
SDN 自動構築システムを開発した背景として、本章では
クラウド型データセンタへの要件と BIGLOBE が目指す姿
について述べる。
2.1 SI 案件の構築スピード向上
近年のコンテンツサービス業界の競争激化により、サー
ビスの開発ライフサイクルが急激に短縮化されている。そ
れに伴い、インフラ提供のリードタイムについてもスピー
ドが求められるようになった。
この要求に対応して BIGLOBE では、リードタイム短縮
の取り組みとして 5 分でインフラを提供するパブリックク
ラウド型の自動構築システムを導入済みである[2]。これに
より、サービスの早期リリースを実現している。
ただし、このシステムでは比較的シンプルなネットワー
ク構成を前提にしており、柔軟性をある程度犠牲にするこ
とで 5 分での自動構築を実現している。したがって、複雑
なネットワーク構成や特殊作業が必要となる SI 案件では、
このシステムの適用が不可能である。この場合、インフラ
を構成する各装置 ( ネットワーク / サーバ / ロードバラン
サ ) を連係させるための設計作業と手動の作業が必要であ
り、リードタイムとして 3 週間を要する。
この課題を解決するため、BIGLOBE では SI 案件に対し
てもスピーディかつ柔軟な対応が可能な自動構築システム
の実現を目指している。
2.2 セキュアなインフラの提供
ユーザにとって安心・安全なインフラを提供することは
ク ラウドサ ービス 事業者と しての 必 須要件 である。
BIGLOBE では、IaaS 型クラウドサービス実現のために物
理サーバのリソースを複数のユーザで共有するマルチテナ
ント方式を利用している。この場合、ユーザ同士が互いの
環境に疎通できないセキュアなインフラ環境が要求される。
マルチテナントを実現するために VLAN によるネットワ
ークの分離とアクセスコントロールリスト（ACL）を利用
しているが、VLAN にはプロトコルの仕様上 ID を 4094 個
しか持てないという制約が存在する。1 つのサービスにつ
き、インターネットアクセス用 / 管理用 / DB 用といった複
数のセグメントを持つことを考慮すると、実質 1000 程度
のサービスの収容が限界である。したがって、収容するサ
ービス数がこれを超える場合には、VLAN の依存関係が無
い隔離されたネットワーク環境を別途用意する必要があり、
大幅な追加作業を要する。
この課題を解決するため、BIGLOBE では VLAN 数の制
限に依存しないアーキテクチャの導入を目指している。
3. 課題解決の方針
3.1 各装置と連係した自動構築システムの導入
2.1 章で述べた課題を解決するには、これまで手動で実
施していた作業を代替する自動構築システムが必要である。
このために、まずインフラを構成する全ての装置を集中
制御する自動構築システムの導入を検討する。各装置のリ
ソース情報や構成情報を連係して管理・制御することで、
パブリッククラウド型のシステムでは不十分であった、ユ
ーザからの多様な要求に対応することが可能となる。
次に、自動構築システムのアーキテクチャについて検討
する。作業者がシステムを利用して各装置を一括操作する
ため、システム側で各装置のユーザインタフェース差異を
吸収し、共通化されたユーザインタフェースで操作する仕
組みを採用する。そのため、各装置の操作モジュールと、
それらを集中的に制御・管理するクラウドコントローラを
開発する。クラウドコントローラで全装置を一括制御する
ことで、手動作業を排除することが可能となる。これによ
り、作業工数を大幅に削減し、構築スピード向上を実現す
る。
3.2 オーバーレイネットワークの導入
2.2 章で述べた課題を解決するために、VLAN に代わる
ネットワーク分離の仕組みとして、オーバーレイ方式の仮
想ネットワーク導入について検討する。
利点として、まず物理ネットワーク上にオーバーレイネ
ットワークを構築することで、物理装置での制約にとらわ
れない柔軟なネットワーク設計が可能になることが挙げら
れる。これにより、VLAN の ID 数を越えるセグメント数
であってもネットワーク分離が可能になる。次に、オーバ](https://image.slidesharecdn.com/ieice2013biglobe-160703075310/85/SDN-Paper-Case-Studies-of-SDN-in-Cloud-Datacenter-1-320.jpg)
![ーレイ方式では、トンネル終端装置を用いてパケットをカ
プセル化することで仮想ネットワークの構築が可能となる。
このことにより、既存のネットワーク装置を特別な機能の
追加やリプレイスすることなく流用可能である。さらに、
トンネル終端装置についても一般的なサーバを用いて実現
可能であることから、低コストで初期導入できるメリット
がある。
オーバーレイネットワーク実現のためのトンネリングプ
ロトコルとして VXLAN [3] を導入する。VXLAN の特長の
1 つとして、トンネル終端ポイントで MAC アドレスを学
習することが挙げられる。これにより仮想マシンと仮想ネ
ットワークの関連付け情報の保持が可能になる。もう 1 つ
は、VLAN では ID を 4094 個までしか持てなかったことに
対して、VXLAN では ID として VNI(VXLAN Network
Identifier)を約 1677 万個まで利用可能なことであり、実質、
上限数を意識せずにネットワーク分離を実現できる。
次に、オーバーレイネットワークを制御する仕組みとし
て OpenFlow [4] を導入する。OpenFlow は SDN を実現する
上で代表的なアーキテクチャであり、ネットワーク通信を
「制御」と「転送」に分離でき、自動化に向けた集中制御
に適している。OpenFlow では、受信パケットの転送ルー
ルを定義したフローテーブルに基づいて通信を行う。フロ
ーテーブルに仮想ネットワークと物理ネットワークの対応
関係を記述することで、オーバーレイネットワークの制御
が可能になる。この仕組みを利用して仮想ネットワークコ
ントローラを実装することで、クラウドコントローラを介
して自由に仮想ネットワークの構成変更が可能になる。
4. SDN 自動構築システムの適用
BIGLOBE で自社開発した SDN 自動構築システムの概要
を図 1 に示す。ここではシステムの中心的な位置付けにあ
るクラウドコントローラと仮想ネットワークコントローラ
について述べる。
図 1 自動構築システム 概要
4.1 クラウドコントローラの実装
クラウドコントローラは、仮想ネットワーク / 物理ネッ
トワーク / サーバ /ロードバランサの各装置を包括的に制
御・管理するためのモジュールである。インフラ構築で必
要となる全てのリソース情報を DB で一元管理しており、
各装置間で矛盾の無い設定が可能である。
クラウドコントローラは GUI を通して作業者からの命令
を受け付け、それをリソース情報から具体的な設定情報に
落とし込み、各装置のコントローラモジュールに指示を出
す。これにより、作業者は各装置のインタフェースやリソ
ース情報を意識せずに作業できる。
4.2 仮想ネットワークコントローラの実装
仮想ネットワークコントローラは、オーバーレイネット
ワークを制御するためのモジュールである。本システムで
構築するオーバーレイネットワークの概要図を図 2 に示す。
本システムでは、筆者らがゲートウェイサーバと呼称する、
Open vSwitch [5] が動作するサーバをトンネル終端装置と
して設置し、VLAN と VXLAN の変換処理を実現している。
Open vSwitch のフローテーブルに VLAN ID と VNI の対応
関係を記述し、Open vSwitch がフローテーブルに従って転
送 処 理 を 行 う 。 仮 想 ネ ッ ト ワ ー ク コ ン ト ロ ー ラ が
OpenFlow プロトコルを用いてフローテーブルを動的に更
新していくことで、ユーザの要求に応じた柔軟な構成変更
が可能になる。本システムでは、OpenFlow プログラミン
グフレームワークである Trema [6] を利用して仮想ネット
ワークコントローラの実装を行った。
図 2 仮想ネットワーク 概要
5. 考察
クラウド型データセンタに SDN 自動構築システムを試
験導入した結果と考察について述べる。
5.1 構築スピードについて
インフラ構築作業における一連の作業を自動化したこと
により、従来は 3 週間必要であった SI 案件のリードタイム
を１週間に短縮することができた。今後は、GUI やクラウ
ドコントローラの機能性を高めて作業プロセスをさらに集
約し、一日以内のリードタイムを計画している。
5.2 セキュリティについて
オーバーレイネットワークを導入したことにより、
VLAN では困難だったネットワーク分離の制限緩和を実現
した。ただし一部実装上の制約により、現時点では限定的
な緩和になってしまっている。この状況について、詳細を
説明する。
まず、仮想ネットワークと物理ネットワークの対応関係
について、理想的には図 3 のように仮想マシンのホストサ](https://image.slidesharecdn.com/ieice2013biglobe-160703075310/85/SDN-Paper-Case-Studies-of-SDN-in-Cloud-Datacenter-2-320.jpg)
![ーバとゲートウェイサーバの関係は１対１であることが望
ましい。このことで一台のホストサーバにつき VLAN ID
4094 個が使用可能であるため、ユーザ数が多い場合でも実
質、制限無くマルチテナントを実現できる。ただし、この
場合、仮想マシンのライブマイグレーション機能の制約に
よって、ホストサーバ間に跨った仮想マシン移動の機能実
装が困難であった。この問題を回避するために、現状のシ
ステムでは、図 4 で示すように複数のホストサーバに対し
て１台のゲートウェイサーバを設置している。これにより、
複数台のホストサーバで VLAN ID を共有することにはな
るが、ホストサーバ間の仮想マシンの移動を実現した。
5.3 自社開発における利点
利点の一点目は、ベンダロックインから解放されたこと
である。従来、ネットワーク装置の新機能導入にあたって
は、製品ベンダの開発ロードマップやベンダロックインに
制限されることがあり、運用者はベンダに期待して待つこ
としかできなかった。しかし SDN を利用して自社で作り
込むことができ、自社戦略に合わせたタイミングでリリー
スすることが可能になった。
二点目は、低コストでシステムを導入できたことである。
従来、ネットワークの新機能を導入する場合には、その機
能に対応した高価な装置の追加導入が必要であった。これ
に対して、本システムの導入では、ハードウェア面では必
要機器の大部分に既存装置を流用しており、またソフトウ
ェア面においてもオープンソースを利用して実装している。
これに加えて、VLAN 数の制限が緩和されたことで、デー
タセンタを増設する場合でも低機能・低価格なネットワー
ク装置で実現可能になった。
図 3 ゲートウェイサーバとホストサーバが 1 対 1 の場合
図 4 ゲートウェイサーバとホストサーバが１対多の場合
5.4 自社開発における課題
しかし、自社開発によって新たな課題も発生した。
一点目は SDN 関連プロトコルの課題である。本システ
ムで利用した OpenFlow や VXLAN は、まだ仕様策定中の
プロトコルであり、今後仕様が変更される可能性を秘めて
いる。このため、システム実装においてもプロトコルの修
正や変更を想定した設計や開発が必要になる。
二点目として、オーバーレイネットワークの運用機能の
課題である。オーバーレイネットワークの障害発生時にお
いて、物理装置の故障箇所や影響範囲の特定について、従
来の物理装置の監視運用のみでは解決できない問題が多い。
このため、物理ネットワークと仮想ネットワークの関連付
ける手段を検討し、開発を進めている。
三点目は、技術者育成の課題である。SDN 自動構築シス
テムの開発には、サーバ / ネットワーク / プログラミング
の総合的な知識と高い技術力が求められる。継続的に自社
開発を進めていくためにも BIGLOBE では技術者の育成を
組織レベルで計画的に取り組んでいる。
6. おわりに
本論文では、IaaS 型クラウドサービスにおける問題を解
決するために、クラウド型データセンタに SDN を適用し
た事例を紹介した。インフラ構築における一連の工程を自
動化できたことにより、リードタイムの短縮および作業工
数の削減を実現した。またオーバーレイネットワークを導
入し、ネットワーク分離数の制限を緩和したことで、ユー
ザの多様な要求に対して、セキュアなインフラを柔軟に提
供可能な仕組みを実現した。
SDN では、Openflow 以外にも、今後はさらに新しいプ
ロトコルや多彩なソリューションの多く登場することが予
想される。近い将来、さらに進化した SDN を活用するこ
とで、ユーザにとって革新的かつ魅力的なサービス提供が
実現できるようになることを期待する。
参考文献
[1] “BIGLOBE ビジネスサービス”,
http://business.biglobe.ne.jp/
[2] “BIGLOBE クラウドホスティング”,
http://business.biglobe.ne.jp/hosting/cloud/
[3] “VXLAN: A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks draft-mahalingam-dutt-
dcops-vxlan-02.txt”,
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-
02
[4] “OpenFlow Switch Specification”,
http://www.openflow.org/documents/openflow-spec-
v1.0.0.pdf
[5] “Open vSwitch”, http://openvswitch.org/
[6] “Trema”, http://trema.github.com/trema/](https://image.slidesharecdn.com/ieice2013biglobe-160703075310/85/SDN-Paper-Case-Studies-of-SDN-in-Cloud-Datacenter-3-320.jpg)
Uploaded byTaiji Tsuchiya
クラウド型データセンタにおけるSDNの適用事例（Paper） Case Studies of SDN in Cloud Datacenter
電子情報通信学会 2013年総合大会より
More Related Content
Similar to クラウド型データセンタにおけるSDNの適用事例（Paper） Case Studies of SDN in Cloud Datacenter
![[SDN JAPAN 2013] IaaS事業者が考える真のSDN](https://cdn.slidesharecdn.com/ss_thumbnails/sdnjapan2013iaassdnidc-130920041843-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
クラウド型データセンタにおけるSDNの適用事例（Paper） Case Studies of SDN in Cloud Datacenter
- 1. クラウド型データセンタにおける SDN の適用事例 CaseStudies of SDN in Cloud Datacenter 土屋 太二*1 川村 聖一*1 Taiji TSUCHIYA Seiichi KAWAMURA *1 NEC ビッグローブ株式会社 基盤システム本部 NEC BIGLOBE, Ltd. Platform System Division 1. はじめに 近年、サーバ仮想化技術や自動構築技術の発展により、 オンデマンドでインフラを提供する IaaS 型クラウドサービ スが幅広く展開されている。データセンタ事業を展開する BIGLOBE においても法人向けサービスとして、用途に応 じた数種類のクラウドサービスを提供している [1] 。 クラウドサービス事業をさらに発展・拡大させていくた めには、ユーザからのあらゆる要求に対してスピーディか つ柔軟に対応していく必要があるが、その実現のためには データセンタにいくつかの課題が存在する。これらの課題 を解決するため、BIGLOBE では SDN ( Software Defined Network ) を利用した自動構築システムを自社開発し、ク ラウド型データセンタへの試験導入を開始した。 本論文では、導入した SDN 自動構築システムについて 説明する。 2. SDN 自動構築システム開発の背景 SDN 自動構築システムを開発した背景として、本章では クラウド型データセンタへの要件と BIGLOBE が目指す姿 について述べる。 2.1 SI 案件の構築スピード向上 近年のコンテンツサービス業界の競争激化により、サー ビスの開発ライフサイクルが急激に短縮化されている。そ れに伴い、インフラ提供のリードタイムについてもスピー ドが求められるようになった。 この要求に対応して BIGLOBE では、リードタイム短縮 の取り組みとして 5 分でインフラを提供するパブリックク ラウド型の自動構築システムを導入済みである[2]。これに より、サービスの早期リリースを実現している。 ただし、このシステムでは比較的シンプルなネットワー ク構成を前提にしており、柔軟性をある程度犠牲にするこ とで 5 分での自動構築を実現している。したがって、複雑 なネットワーク構成や特殊作業が必要となる SI 案件では、 このシステムの適用が不可能である。この場合、インフラ を構成する各装置 ( ネットワーク / サーバ / ロードバラン サ ) を連係させるための設計作業と手動の作業が必要であ り、リードタイムとして 3 週間を要する。 この課題を解決するため、BIGLOBE では SI 案件に対し てもスピーディかつ柔軟な対応が可能な自動構築システム の実現を目指している。 2.2 セキュアなインフラの提供 ユーザにとって安心・安全なインフラを提供することは ク ラウドサ ービス 事業者と しての 必 須要件 である。 BIGLOBE では、IaaS 型クラウドサービス実現のために物 理サーバのリソースを複数のユーザで共有するマルチテナ ント方式を利用している。この場合、ユーザ同士が互いの 環境に疎通できないセキュアなインフラ環境が要求される。 マルチテナントを実現するために VLAN によるネットワ ークの分離とアクセスコントロールリスト（ACL）を利用 しているが、VLAN にはプロトコルの仕様上 ID を 4094 個 しか持てないという制約が存在する。1 つのサービスにつ き、インターネットアクセス用 / 管理用 / DB 用といった複 数のセグメントを持つことを考慮すると、実質 1000 程度 のサービスの収容が限界である。したがって、収容するサ ービス数がこれを超える場合には、VLAN の依存関係が無 い隔離されたネットワーク環境を別途用意する必要があり、 大幅な追加作業を要する。 この課題を解決するため、BIGLOBE では VLAN 数の制 限に依存しないアーキテクチャの導入を目指している。 3. 課題解決の方針 3.1 各装置と連係した自動構築システムの導入 2.1 章で述べた課題を解決するには、これまで手動で実 施していた作業を代替する自動構築システムが必要である。 このために、まずインフラを構成する全ての装置を集中 制御する自動構築システムの導入を検討する。各装置のリ ソース情報や構成情報を連係して管理・制御することで、 パブリッククラウド型のシステムでは不十分であった、ユ ーザからの多様な要求に対応することが可能となる。 次に、自動構築システムのアーキテクチャについて検討 する。作業者がシステムを利用して各装置を一括操作する ため、システム側で各装置のユーザインタフェース差異を 吸収し、共通化されたユーザインタフェースで操作する仕 組みを採用する。そのため、各装置の操作モジュールと、 それらを集中的に制御・管理するクラウドコントローラを 開発する。クラウドコントローラで全装置を一括制御する ことで、手動作業を排除することが可能となる。これによ り、作業工数を大幅に削減し、構築スピード向上を実現す る。 3.2 オーバーレイネットワークの導入 2.2 章で述べた課題を解決するために、VLAN に代わる ネットワーク分離の仕組みとして、オーバーレイ方式の仮 想ネットワーク導入について検討する。 利点として、まず物理ネットワーク上にオーバーレイネ ットワークを構築することで、物理装置での制約にとらわ れない柔軟なネットワーク設計が可能になることが挙げら れる。これにより、VLAN の ID 数を越えるセグメント数 であってもネットワーク分離が可能になる。次に、オーバ
- 2. ーレイ方式では、トンネル終端装置を用いてパケットをカ プセル化することで仮想ネットワークの構築が可能となる。 このことにより、既存のネットワーク装置を特別な機能の 追加やリプレイスすることなく流用可能である。さらに、 トンネル終端装置についても一般的なサーバを用いて実現 可能であることから、低コストで初期導入できるメリット がある。 オーバーレイネットワーク実現のためのトンネリングプ ロトコルとして VXLAN [3]を導入する。VXLAN の特長の 1 つとして、トンネル終端ポイントで MAC アドレスを学 習することが挙げられる。これにより仮想マシンと仮想ネ ットワークの関連付け情報の保持が可能になる。もう 1 つ は、VLAN では ID を 4094 個までしか持てなかったことに 対して、VXLAN では ID として VNI(VXLAN Network Identifier)を約 1677 万個まで利用可能なことであり、実質、 上限数を意識せずにネットワーク分離を実現できる。 次に、オーバーレイネットワークを制御する仕組みとし て OpenFlow [4] を導入する。OpenFlow は SDN を実現する 上で代表的なアーキテクチャであり、ネットワーク通信を 「制御」と「転送」に分離でき、自動化に向けた集中制御 に適している。OpenFlow では、受信パケットの転送ルー ルを定義したフローテーブルに基づいて通信を行う。フロ ーテーブルに仮想ネットワークと物理ネットワークの対応 関係を記述することで、オーバーレイネットワークの制御 が可能になる。この仕組みを利用して仮想ネットワークコ ントローラを実装することで、クラウドコントローラを介 して自由に仮想ネットワークの構成変更が可能になる。 4. SDN 自動構築システムの適用 BIGLOBE で自社開発した SDN 自動構築システムの概要 を図 1 に示す。ここではシステムの中心的な位置付けにあ るクラウドコントローラと仮想ネットワークコントローラ について述べる。 図 1 自動構築システム 概要 4.1 クラウドコントローラの実装 クラウドコントローラは、仮想ネットワーク / 物理ネッ トワーク / サーバ /ロードバランサの各装置を包括的に制 御・管理するためのモジュールである。インフラ構築で必 要となる全てのリソース情報を DB で一元管理しており、 各装置間で矛盾の無い設定が可能である。 クラウドコントローラは GUI を通して作業者からの命令 を受け付け、それをリソース情報から具体的な設定情報に 落とし込み、各装置のコントローラモジュールに指示を出 す。これにより、作業者は各装置のインタフェースやリソ ース情報を意識せずに作業できる。 4.2 仮想ネットワークコントローラの実装 仮想ネットワークコントローラは、オーバーレイネット ワークを制御するためのモジュールである。本システムで 構築するオーバーレイネットワークの概要図を図 2 に示す。 本システムでは、筆者らがゲートウェイサーバと呼称する、 Open vSwitch [5] が動作するサーバをトンネル終端装置と して設置し、VLAN と VXLAN の変換処理を実現している。 Open vSwitch のフローテーブルに VLAN ID と VNI の対応 関係を記述し、Open vSwitch がフローテーブルに従って転 送 処 理 を 行 う 。 仮 想 ネ ッ ト ワ ー ク コ ン ト ロ ー ラ が OpenFlow プロトコルを用いてフローテーブルを動的に更 新していくことで、ユーザの要求に応じた柔軟な構成変更 が可能になる。本システムでは、OpenFlow プログラミン グフレームワークである Trema [6] を利用して仮想ネット ワークコントローラの実装を行った。 図 2 仮想ネットワーク 概要 5. 考察 クラウド型データセンタに SDN 自動構築システムを試 験導入した結果と考察について述べる。 5.1 構築スピードについて インフラ構築作業における一連の作業を自動化したこと により、従来は 3 週間必要であった SI 案件のリードタイム を１週間に短縮することができた。今後は、GUI やクラウ ドコントローラの機能性を高めて作業プロセスをさらに集 約し、一日以内のリードタイムを計画している。 5.2 セキュリティについて オーバーレイネットワークを導入したことにより、 VLAN では困難だったネットワーク分離の制限緩和を実現 した。ただし一部実装上の制約により、現時点では限定的 な緩和になってしまっている。この状況について、詳細を 説明する。 まず、仮想ネットワークと物理ネットワークの対応関係 について、理想的には図 3 のように仮想マシンのホストサ
- 3. ーバとゲートウェイサーバの関係は１対１であることが望 ましい。このことで一台のホストサーバにつき VLAN ID 4094個が使用可能であるため、ユーザ数が多い場合でも実 質、制限無くマルチテナントを実現できる。ただし、この 場合、仮想マシンのライブマイグレーション機能の制約に よって、ホストサーバ間に跨った仮想マシン移動の機能実 装が困難であった。この問題を回避するために、現状のシ ステムでは、図 4 で示すように複数のホストサーバに対し て１台のゲートウェイサーバを設置している。これにより、 複数台のホストサーバで VLAN ID を共有することにはな るが、ホストサーバ間の仮想マシンの移動を実現した。 5.3 自社開発における利点 利点の一点目は、ベンダロックインから解放されたこと である。従来、ネットワーク装置の新機能導入にあたって は、製品ベンダの開発ロードマップやベンダロックインに 制限されることがあり、運用者はベンダに期待して待つこ としかできなかった。しかし SDN を利用して自社で作り 込むことができ、自社戦略に合わせたタイミングでリリー スすることが可能になった。 二点目は、低コストでシステムを導入できたことである。 従来、ネットワークの新機能を導入する場合には、その機 能に対応した高価な装置の追加導入が必要であった。これ に対して、本システムの導入では、ハードウェア面では必 要機器の大部分に既存装置を流用しており、またソフトウ ェア面においてもオープンソースを利用して実装している。 これに加えて、VLAN 数の制限が緩和されたことで、デー タセンタを増設する場合でも低機能・低価格なネットワー ク装置で実現可能になった。 図 3 ゲートウェイサーバとホストサーバが 1 対 1 の場合 図 4 ゲートウェイサーバとホストサーバが１対多の場合 5.4 自社開発における課題 しかし、自社開発によって新たな課題も発生した。 一点目は SDN 関連プロトコルの課題である。本システ ムで利用した OpenFlow や VXLAN は、まだ仕様策定中の プロトコルであり、今後仕様が変更される可能性を秘めて いる。このため、システム実装においてもプロトコルの修 正や変更を想定した設計や開発が必要になる。 二点目として、オーバーレイネットワークの運用機能の 課題である。オーバーレイネットワークの障害発生時にお いて、物理装置の故障箇所や影響範囲の特定について、従 来の物理装置の監視運用のみでは解決できない問題が多い。 このため、物理ネットワークと仮想ネットワークの関連付 ける手段を検討し、開発を進めている。 三点目は、技術者育成の課題である。SDN 自動構築シス テムの開発には、サーバ / ネットワーク / プログラミング の総合的な知識と高い技術力が求められる。継続的に自社 開発を進めていくためにも BIGLOBE では技術者の育成を 組織レベルで計画的に取り組んでいる。 6. おわりに 本論文では、IaaS 型クラウドサービスにおける問題を解 決するために、クラウド型データセンタに SDN を適用し た事例を紹介した。インフラ構築における一連の工程を自 動化できたことにより、リードタイムの短縮および作業工 数の削減を実現した。またオーバーレイネットワークを導 入し、ネットワーク分離数の制限を緩和したことで、ユー ザの多様な要求に対して、セキュアなインフラを柔軟に提 供可能な仕組みを実現した。 SDN では、Openflow 以外にも、今後はさらに新しいプ ロトコルや多彩なソリューションの多く登場することが予 想される。近い将来、さらに進化した SDN を活用するこ とで、ユーザにとって革新的かつ魅力的なサービス提供が 実現できるようになることを期待する。 参考文献 [1] “BIGLOBE ビジネスサービス”, http://business.biglobe.ne.jp/ [2] “BIGLOBE クラウドホスティング”, http://business.biglobe.ne.jp/hosting/cloud/ [3] “VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks draft-mahalingam-dutt- dcops-vxlan-02.txt”, http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan- 02 [4] “OpenFlow Switch Specification”, http://www.openflow.org/documents/openflow-spec- v1.0.0.pdf [5] “Open vSwitch”, http://openvswitch.org/ [6] “Trema”, http://trema.github.com/trema/