編集で原稿がどう変わるかの実例(OpenFlow記事)

＠IT(ITmedia)で「JANOG29レポート〜過熱しすぎていませんか？ OpenFlowを巡る期待と現実」という記事を書きました。

で、単に「記事を書きました」と紹介するだけだと味気ないので、編集をして頂く前の原稿をここで紹介します。 まず最初に＠ITに掲載されている編集後の記事をご覧頂き、そのうえで私が提出した初稿をご覧頂くと「編集前と編集後の違い」が良くわかると思います。

今回は、原稿初稿を提出後に＠ITの編集者のかたから「ここがわかりにくい」というフィードバックや、「この部分を図にして欲しい」というリクエストを頂きつつ記事を修正しています。 執筆者に原稿中のわかりにくい部分や表現が足りない部分を指摘して気がつかせるというのも編集者の大事な役割なのではないかと私は考えています。 今回の記事では、私が自分で修正版原稿を提出するだけではなく、編集者のかたによる文章表現の調整も行われています。

商業用の文章を書いたり、本を書いたりすると非常に良くわかるのですが、編集は非常に大切です。 しかも、編集者の技量や、編集者と執筆者の相性によっても最終的なアウトプット品質が変わります。

通常は「著者」や「記者」だけに注目が集まりがちですし、著者が独自に電子出版が可能となったことで一部で編集者を軽視するような雰囲気もあるように感じることがありますが、「編集というプロセスが品質に与える影響ってこういうものだ」というような雰囲気を以下の原稿を見て感じて頂ければと思います。

初稿原文

以下が提出した原稿です。

OpenFlow - 期待と現実のギャップ

ここ半年ぐらい、OpenFlowという単語がBuzzっています。 OpenFlowは、色々と新しいことが可能と思える仕様であり、仮想化されたクラウド環境の構築に利用可能な技術として注目されています。

OpenFlowによって実現可能かも知れないと思えることは多いものの、同技術対応製品の多く未発表であるため、OpenFlowに対する期待と実際に実現可能であることの現実にはギャップがあります。 JANOG29で行われたOpenFlowセッションで、そのような期待と現実の「ギャップ」に対して、OpenFlow製品を開発しているベンダーから戸惑いの声もあがっていました。

同セッションでは、OpenFlowが有用であると思われるユースケースが語られるとともに、過度な期待と現実のギャップが今後のOpenFlow普及に悪影響を与える可能性が懸念されていました。

参考リンク
http://www.janog.gr.jp/meeting/janog29/program/openflow.html
JANOG29: で、実際OpenFlowで何ができるの？

◆ OpenFlowの主な用途

OpenFlowは、主にデータセンター内での仮想化環境とともに利用されるだろうとされている技術です。

仮想サーバの統合管理を行うときに、スイッチ部分を制御するためにOpenFlowを使うという用途が株式会社NTTデータの馬場氏によって紹介されました。 ライブマイグレーションに対して自動追尾が可能というメリットも強調されていました。 「5年前からOpenFlowに取り組んでいる」という日本電気株式会社の岩田氏も、主なターゲットはデータセンター内での仮想化であると述べています。 JANOG29では、OpenFlowコントローラのベンダーであるニシラ・ネットワークスの進藤氏がOpenFlowを「USBのようなもの」と表現しています。

データセンター以外の用途も検討されています。 NECビッグローブ株式会社の淀野氏は、仮想化されたネットワークの管理自動化に関して模索中であると発表されていました。

このようにハイエンドでの利用が想定されていることや、まだ普及まであることから、初期のOpenFlowスイッチはデータセンター内で利用されるようなクラスの値段であり、家庭やSOHO環境等で利用されるようなスイッチと比べて高価なものとなります。

初期のOpenFlowは、データセンター内で利用されている各種技術同様に、多くのユーザにとってはブラックボックス内で知らないうちに動いているものになるでしょう。 位置づけとしては、MPLSのような感じかも知れないと考えています。

◆ OpenFlowは普及するのか？するとしたらいつ頃か？

OpenFlow製品が登場してすぐに一般的に普及するようなことは、恐らくありません。 JANOG29セッションでは「OpenFlowは普及するの？」というQ&Aがありましたが、

各ハードウェアベンダー発表者の方々は、個人的な予想と前置きしつつ、2012年は徐々に製品が出始める時期であり試行導入がメインとなり、2013年以降が普及時期だという意見を述べられていました。 基本的に今年と来年に初期製品が出て、そのフィードバックを活かした製品が出るのが、2014年以降という意見もありました。

ニシラ・ネットワークスの進藤氏は「USBが普及したと思いますか？同様に思えるようになったときがOpenFlowが普及したと言える時期だと思います」と感想を述べられていました。

◆ 「日本はOpenFlowクレイジーだ」

昨年時点で一部で言われていた話ではありますが、OpenFlowに関しての報道の過熱は主に日本などのアジア圏で顕著であり、アメリカ国内ではさほど盛り上がっているわけではありませんでした。 2012年末頃に遅れてアメリカでも話題になりはじめましたが、日本の方が盛り上がっているようです。

JANOG29では、「日本に来た某B社のCEO曰く」として、以下のようなものが紹介されていました。

画像：某B社CEOの発言(Ustream中継より)

この発言後に行われた秋のOpenFlow Summit後はアメリカでも話題が増えつつあるとしつつも、アメリカから見れば日本でのOpenFlowの話題は多少過熱気味であり、「日本はOpenFlow Crazy」とも見えるようです。 なお、このときのCrazyは恐らく頭がおかしいという悪い意味ではなく、「熱狂的だ」というプラス面も含めたCrazyだと思われます。 Crazyという単語は良い意味でも使われます。 どちらにせよ、日本とアメリカでOpenFlowに関しての熱が全く異なることが良くわかります。

JANOG29では、「正直、日本ではBuzzっていると推進側としても思う」とのコメントも登場しました。 そのような背景もあり、OpenFlowを推進する立場であるベンダーがどういうところを狙っているかなどに関して、JANOG29のOpenFlowセッションで語られていました。

◆ 本質的な実装はこれから

ブロケードコミュニケーションズシステムズ株式会社の高嶋氏は、「OpenFlowの仕様だけを見ると、色々とできそうに見えてしまいますが、本質的な実装はこれからです」と述べています。 「OpenFlowの仕様そのものも開発途上であり、製品も一部の先進的なものが存在するのみである」のが現状です。

最初に出る製品というのは、実験的な試みであることが多く、色々と制約があります。 プロトコル上は余地があったとしても、実装上の制約によって実現不能なものも色々ありそうです。

NECビッグローブ株式会社の淀野氏は、いままで分散管理していた設定をコントローラで一元管理できる点が魅力としつつも、OpenFlow製品は発展登場であり、様々な課題があると述べています。 たとえば、現時点では発売されているOpenFlowスイッチが少なく機器の価格がまだ高価であること、コントローラの処理能力や堅牢性や拡張性を意識した作りになっていなさそうであること、現時点で既存の機器構成を全て変更してOpenFlowスイッチを新たに導入するのはまだ難しいこと、VXLANやTRILLでも課題の解決が可能そうであることなどがあげられていました。

株式会社NTTデータ馬場氏によって相互接続性実験の結果も紹介されていました。 同社のOpenFlowコントローラプロトタイプと、アリスタネットワークス、エクストリーム ネットワークス、日本電気、ブロケードの4社によるOpenFlowスイッチの相互接続試験が昨年行われました。 その4社の他に、プロントと名前が言えないベンダが2社のものもあったようです。 検証実験に関して、「マルチベンダ環境はOpenFlowのバージョンが同じであってオプション機能を使わないのであれば問題はないのではないか」と感想が述べられていました。 「バッドノウハウというか失敗事例」として、フロー設定の書き込みタイミングが製品によって異なることや、ARPやDHCPやVRRPなどによるマルチキャストやブロードキャストがOpenFlowネットワークの外から次々と入ってくるのでそういったものをどうやって処理するのかなどが苦労した点としてあげられていました。

参考リンク
http://www.nttdata.co.jp/release/2011/100302.html
NTTデータニュースリリース：次世代ネットワーク技術「OpenFlow」を活用したクラウド環境構築の検証実験に成功

Q&Aでは、タプル数を多くなると機器のコストが高くなってしまうのではないかという指摘が行われていましたが、それに対して「コメントしづらい」としつつも「用途を限定したうえで最適化されたハードウェアの実装も将来的には必要になるかも知れない」というコメントがされていました。

このように、初期のOpenFlow製品には足りないところがある可能性があり、それに落胆して徐々に熱が醒めていってしまう恐れも指摘されていました。 登場前からあまり過熱し過ぎずに、暖かく見守る必要がありそうです。

◆ OpenFlowコントローラに対するDDoS

JANOG29セッションのQ&Aで、OpenFlowスイッチがDDoSやポートスキャンに対してどのように対処可能なのかに関しての質問が出ていました。 OpenFlowは、設定によっては新しいフローが到着する度に「このフローどうなの？」とコントローラに問い合わせる場合があり、コントローラに負荷がかかるとネットワーク全体に影響が出てしまう可能性があるのではないかという内容です。 そのような状況が発生する例として、「安いVPSサービスに繋げると大量のポートスキャントラフィックが到着してしまう」と質問では述べられていました。

それに対する答えとして、「OpenFlowスイッチにはプロアクティブなものとして、予想されるようなフローをあらかじめ書き込んでおかなければなりません。そうしないとドンドンコントローラに問い合わせが来てしまいます。それでも防げない状況はありますが、インテグレータとしては本格運用の前に試験をします。試験の段階でフローを書き込ませるといった工夫をしています。」と述べられていました。

この質問は、実はOpenFlowが抱える大きな問題の一つですが、JANOG29セッションでは「大きな課題の一つ」とされ、その部分の工夫はコントローラベンダの実装依存であるようです。

さらに、このような問題を緩和させるために、単一のコントローラが管理するドメインの範囲を小分けにして、影響範囲を限定させることや、予想可能なエントリをあらかじめ手：動設定しておくなどのワークアラウンドが必要であることも紹介されていました。 実際にOpenFlowを導入するとなるとノウハウが必要なのかも知れません。

◆ 「○○と何が違うの？」という疑問

JANOG29のQ&Aで多かった質問が、「OpenFlowって既存の○○と何が違うの？」という質問でした。 VXLANやTRILLといった新しいデータセンター系技術、従来のオーバーレイや遠隔操作系技術をあげた質問があったようです。

それに対して、ニシラ・ネットワークスの進藤氏は「データプレーンとコントロールプレーンを分ける技術は昔からあり、最近ではVXLANやTRILL、古い所ではATMやMPLSやnetconfなどがありますが、OpenFlowとこれらを直接比べるのは適切ではありません。それぞれ、それぞれの特定領域を解決するための道具やプロトコルであって、ガチンコでOpenFlowとあたるものではないと思っています。VXLANに関しては、yet another tunneling protocolなのでそれでOpenFlowと同じことができるというのはナンセンスであると思っています。何かが何かを置き換えるものではありません」と述べていました。

現時点では、今後発売されるOpenFlow専用スイッチの多くは、既存スイッチへの負荷機能として提供される予定とされているものが多いです。 そのため、「すでに○○の機能がそのスイッチに入ってるけど、OpenFlowになったときの違いはなに？」という話になりがちなのかも知れません。

ただ、現時点ではまだ製品も多く出ているわけではないので、既存のプロトコルと何がどう違っており、どのような用途が良いのかに関しては、これからなのかも知れません。

◆ OpenFlowの今後

OpenFlowは、今までベンダーがやろうとしなかった方式に切り込んでいる仕様であり、発展や派生を考えると非常に面白いプロトコルです。 ただ、最初に期待が過熱し過ぎると、実際に出てきた初期製品を見て落胆してしまい、結果として市場導入が失敗してしまうのではないかという恐れが一部で出始めています。

OpenFlowは、ゆったりと暖かく見守った方が良いのではないかと思い始めた今日この頃です。

最近のエントリ

• 日本のIPv6採用状況が50％を超えている件について
• 「ピアリング戦記」の英訳版EPUBを無料配布します！
• IPv4アドレス移転の売買価格推移および移転組織ランキング100
• 例示用IPv6アドレス 3fff::/20 が新たに追加
• ShowNet 2024のL2L3
• ShowNet 2024 ローカル5G

過去記事

過去記事一覧