Cisco Japan Blog

SDN

  • SDN

    ネットワーク アーキテクチャ考 (9) 「Orchestration !」

    - February 18, 2014 - 0 Comments

    最近、「オーケストレーション」という言葉を耳にする機会が増えました。仮想化された要素を構成し、モニターし、柔軟なサービス提供に役立てるために、オーケストレーションは重要な役割を果たします。ETSI NFV(Network Function Virtualization)アーキテクチャを見ても、End-to-End Reference Architecture の大きな部分を、「Management and Orchestration」が占めています。(NFV 参照アーキテクチャについては、以前のエントリをご参照ください。)そこでは、Management and Orchestration の最上位に「Orchestrator」というエンティティが位置づけられていますが、では Orchestration、そして Orchestrator って一体何なのでしょう。本日は、オーケストレーションのアーキテクチャ側面を取り上げます。   Orchestration とは何か オーケストレーションという言葉は、複雑で規模性の高いコンピュータやネットワーク システムの資源(仮想・物理)を活用し、いかに効率よく運用するか、という文脈で使われています。語源は勿論オーケストラ(管弦楽団)であります。私事ながら、楽器を演奏する者としては、 このための用語としてオーケストレーションという言葉が選択されたことに、感慨を禁じ得ません。いわゆる「制御」とか「管理」とかとは異なる何か、ということを、これほど端的に表現できる言葉は他にないだろうと思われます。オーケストラを構成する要素(奏者)は、それぞれに自律的であり、管理や制御されることを忌み嫌うタイプです。傍目からは、指揮者がオーケストラを統率しているように見えるかもしれませんが、実態は大きく異なります。指揮者のやっていることは、音楽を表現するということに対する、哲学というか基本的な考え方の共有です。肝要なのは、奏者の自発性をいかに引き出し特性を活かすか、というところです。そうでなければ、いきいきとした音楽は生まれません。 話が少しずれました。ここでのトピックは、指揮ではなくオーケストレーションでした。オーケストレーションとは、楽器編成、旋律・副旋律・伴奏・リズムなどの楽曲要素に関する役割分担や受け渡しなどについての指定を行うことです。実行の前に予め楽譜(管弦楽のスコア)にするという点で、料理のレシピやコンピュータのプログラムに近いかもしれません。ほとんどの場合曲は既にあるという前提なので、作曲自体とも異なります。ただ「オーケストレータ」という言葉は、音楽の文脈では使われないですね。ある意味では編曲にあたるかもしれませんが、編曲者という感じではないです。管弦楽法の実践者とでも言うべきでしょうか。 いずれにせよ、オーケストレーションとは「自律的で多数の要素を有機的にまとめあげるためのレシピまたはプログラムをつくること」と定義できると思います。こう考えると、「Controller」「Manager」「Orchestrator」とか言う言葉は、きちんと使い分けて使いたいものです。現実は、ほとんどの場合、渾然となってしまっているのですが…。先日も、「このESC(Elastic Service Controller)というモジュールが、Orchestrator の役割を担います」などとお客様に説明しながら、内心では「えええ、Controller がOrchestrator?!」と自己ツッコミ入れまくり、絶句しそうになりました。   Orchestration

    続きを読む
    Tags:
  • SDN

    ネットワークアーキテクチャ考 (8) 「Overlay と Underlay の連携」

    - January 8, 2014 - 0 Comments

    という訳で、「SDN的な何か」の動機となる要求はネットワーク仮想化だった、ということです。また前回は、「仮想化への要請があったから SDN が活況なのか、SDN が活況だから仮想化がブームになったのか。共起関係から因果関係を帰結することはできないので、今はどちらなのかはわからない」と書きました。しかし、SDN と仮想化の共起に先立つ物として、クラウドの興隆があったことは疑いの余地はないでしょう。そしてそこに強く関係しているのが、設備投資から消費へ、という経済的動向です。   設備投資から消費へ 大分前のことですが、“Consumption Economics”[1]という本を読みました。英米で話題になったのでご存知の方も多いと思います。そこでは、ハイテク業界の購買モデルについて論じられています。—  これまでは購買側がリスクを取り、年月をかけて効果や効用を生み出して投資を回収していたが、これからの時代の購買者は、そのようなリスクはもう取らない。必要なときに必要な機能を、そこそこの(good enough)品質で使えれば良い。— これはしかし未来予測でも何でもなく、実際に現実に起こっていることである、と実感せざるを得ません。 必要なときに必要な機能をそこそこの品質で、という仮想化指向の傾向は、必ずしも絶対的なものではないと思います。第 3 回で述べた「アーキテクチャ変遷のパターン」でいうと、「仮想」と「物理」という対極概念間で行きつ戻りつする、「1.対極概念間の揺り戻し」に相当するものと考えられます。実際、ガートナーは「クラウド化の流れは近いうちに止まる」という発表をしました[2]。 しかし、少なくとも現時点では仮想化への要求は強く、また目的とする効果を得るために、設備投資するのではなく「必要な機能を使う」という考え方は、魅力的な発想です。技術者としては、どのようにこれを実装するか、というところに注力したいと思います。   How good is good enough? 「必要なときに必要なだけ」、というのは、技術的には、仮想化環境において、柔軟かつ迅速な CRUD(Create, Read, Update, Delete)を実現する、ということになるでしょう。ネットワークはそもそも、レイヤリングとパケット カプセル化という点で十分仮想的なのですが、決定的に欠如していたのは、オペレーターやアプリケーションから見たときの柔軟かつ迅速な CRUD でした。そこで現在は、CRUD

    続きを読む
    Tags:
  • SDN

    ネットワークアーキテクチャ考 (7) 「SDN と仮想化」

    - December 4, 2013 - 0 Comments

    先日 SDN を取り上げたとき、SDN の狭義の定義は「Flow/Path Programmability」ではないか、と書きました。何もかもが“SDN”という文脈に絡めとられ用語が膨張して行くのは、市場の活性化にはよいのかもしれませんが、技術者としては気持ち悪く、どうにも傍ら痛い。そこで、仮にでもよいから定義しておこうと思ったのです。「私が SDN という用語を使う場合、特に注釈がない限りは Flow/Path Programmability という意味です」と言えれば、少なくとも漠然とした会話にならずに済みます。しかし、そんなものが定着することもなく、“SDN 的な何か”が模索され続けています。一方で、「Beyond SDN」というフレーズ[1]も出ています。定義も無かったのに、今度は超えてしまうのか―。:)  マーケティング畏るべし。   SDN – 最初の定義 「Flow/Path Programmability」という定義に根拠がない訳ではありません。Software-Defined Networking という言葉が最初に使われたのは、2009年 4月の MIT Technology Review [2] だそうですが、そこでは「SDN」という言葉が明確に「Flow Programmability」を意味していました。ただ、「Flow」と言うと、多くのネットワーク技術者にとってはセッション レイヤ以上の個別フローを表すことが多いと思われたため、「Path」という表現を追加したいと思いました。Path であれば、Aggregated Flow(複数のフローをまとめて扱う)も包含できますし、L3 Path

    続きを読む
    Tags:
  • アーキテクチャ

    ネットワークアーキテクチャ考 (6) 「NFV-2」

    - November 13, 2013 - 0 Comments

    細々と、ネットワークアーキテクチャに関する連載を続けています。今は希有のアーキテクチャ揺籃期ですから、書いておきたいことがどんどん溜まってきます!が、筆無精、遅筆のためなかなか進みません。前回、NFV(Network Function Virtualization; ネットワーク機能仮想化)を取り上げましたが、今回はその続きを書きます。 NFVにおける-ilities この連載の初回(序論)で、「あるシステムの性質や能力(-ilities)を規定するのはそのシステムのアーキテクチャである」ということを書きました。(特性や能力を表す英単語は Availability、Scalability、Flexibility、Security、Extensibility、Elasticity… のように -ility という語尾がつくことが多いことから、それらが「-ilities」 と総称されます。) 当初サーバ仮想化が普及したときのアーキテクチャ指針は、専ら「 シンプルに」ということだったのではないかと思います。Scalability や Performance の面も、単にブレードを増やすことにより Scale Out させることができる。High Availability にしても、あるブレードが壊れたらそれを自動的に切り離し、即時に別のブレードに VMインスタンスをクローンすればよい。シンプルに、Scalability、Availability、Flexibility、Extensibility、 Elasticity… を実現できるのが、仮想化アーキテクチャの強みです。 しかし、通信事業者が目指す NFV は、そうも言ってられません。「キャリア グレード」という社会的要請、そして通信事業者やシステム提供側のエンジニアリングに対する指向というものもあり、仮想化環境においてもやはり「High Availability」「High Performance」「High

    続きを読む
    Tags:
  • アーキテクチャ

    ネットワークアーキテクチャ考 (5) 「NFV !」

    - August 27, 2013 - 0 Comments

    前回のブログ記事では「アーキテクチャ変遷」の一例として SDN(Software Defined Networking)を取り上げました。SDN についてはまだまだ書かなくてはならないことが残っていますが、それらはひとまず今後に廻し、今回は NFV(Network Function Virtualization)を取り上げます。   NFVとは NFV とは Network Function Virtualization の略で、「ネットワーク機能の仮想化」を意味します。欧州電気通信標準化機構(ETSI, European Telecommunications Standards Institute)(*) が NFV ISG (Industry Specification Group) を立ち上げ、米国や日本などヨーロッパ以外の通信事業者も加わって積極的に活動を行っているため、今、SDN とともに現在業界の注目を浴びています。  前回の記事のなかで SDN は「ネットワークのあり方に関する再定義」と書きましたが、NFVは「通信事業者による、(データセンターが既に行っている)仮想化の再定義」と捉えられます。

    続きを読む
    Tags:
  • SDN

    ネットワークアーキテクチャ考 (4) 「SDN!」

    - July 15, 2013 - 0 Comments

    前回のブログで「次は SDN に関して書く」と宣言してから大分時間が経ってしまいました。SDN(Software Defined Networking)という言葉は、バズワード的な性質が強く、また市場も擾乱しており、個人やコンテクストによって意味することが異なるため、端的に書くのが難しい話題です。 SDNの喧噪 SDN とは「パスやフローといったデータ プレーンの Programmability」または「データ プレーンを Programming すること」を指す、というのが、現時点における最も一般的な定義だと思います。巷では、「SDN/Openflow」のようにわざと曖昧にさせているような記述もよく目にしますが、これは『フローの Programmability、およびそのための 1 つの手段としての Openflow』と捉えられます。また、データプレーンのみならず、コントロール プレーンやマネージメント プレーンの Programmability を意味する場合もあります。ルータやスイッチのSDK、シスコで言うと ONE-PK(Open Network Environment-Programmers’ Kit)を使えば、データプレーンのみならず、設定・照会可能な要素のほぼすべてを、API で操作することができます。これらは、上位システムへの抽象化・API 提供への要請に応えようとするものです。(なおこれらの API は、共通的なものから、IETF の I2RS

    続きを読む
    Tags:
  • アーキテクチャ

    ネットワークアーキテクチャ考 (3) 「アーキテクチャの変遷」

    - May 16, 2013 - 1 Comment

    このブログでは「ネットワークアーキテクチャ」について検討しており、今回は第3回目になります。第1回目の序論であげた、5点のアーキテクチャの特質のうち、今回は「アーキテクチャの変遷」について検討したいと思います。 人々は、アーキテクティングの過程で、システムの要素やその機能のみならず、複数の要素の組み合わせ・つながり方・構造、といったものを規定して行きますが、その論拠というか根底には「理念」のようなものがあります。そして、アーキテクチャやその理念は、かなり普遍的なものですが、絶対的なものではないので、時流や文化によって変遷します。 アーキテクチャ変遷の困難性 基本的には、一度アーキテクチャが決定しそれが軌道に乗ると、通常それを変遷させることは非常に困難です。 理由はいくつかあります。まず、成功しているアーキテクチャには、それをさらに促進する正のフィードバック ループが形成されます。例えば、あるサービスのユーザが増えれば増えるほど、ユーザの利便性は増し、かつコストは下がります。また、あるアーキテクチャが主流になると、業界全体がそれに合わせた製品を開発することにより、エコシステムが形成されていきます。 もう 1 つの観点として、あるパラダイムにいると、そのパラダイムにおける環境や条件が人々にとってあまりにも当たり前になり、暗黙の前提をおくようになります。そして、無意識にその前提に縛られた上での改良や拡張に注力し、新たなアーキテクチャ可能性に気づきにくくなります。 Thomas Kuhn は、「科学革命の構造」[1] の第8章で次のように述べています。 「あるパラダイムから新しいものへ移る移り行きは、(中略)古いパラダイムの整備と拡張で得られる累積的な過程とは、はるかに隔たっている。」 また、有名な Christensen の「イノヴェーターのジレンマ」[2]では、次のように述べられます。 「業界におけるほとんどの技術進歩は持続的である。(-中略-)disruptive な技術は、少なくとも短期的には、一時的に品質や性能を下げることがある。しかしながら、皮肉なことに、現在先導している企業の失敗を促進するのは、disruptive な技術である。」 さらにこのブログでもよく取り上げている「Art of System Architecting」[3]でも、次のように記述しています。 「現在成功している製品をつくったチームは、その製品を進化させるにはベストだが、新たな代替品をつくるためには向いていないことが多い。」 変遷が困難な例は、探そうと思えばいくらでも見つかります。例えば、昔のタイプライターの機構から決まったと言われるキーボードの qwerty 配列。今はタイプライターなんてどこにもありませんし、人間工学的に決して合理的ではない配列だそうですが、未だにそれを変えることができないでいます。IPv6 の普及にも随分時間がかかっています。 しかしそれでも、人々が望む望まないに関わらず、技術的ブレークスルーの出現や時代の要請によって、アーキテクチャは変遷して行きます。ではどのようにその変遷は起こっているのでしょうか。

    続きを読む
    Tags:
  • アーキテクチャ

    ネットワーク アーキテクチャ考(2) 「トレードオフ」

    - April 22, 2013 - 0 Comments

    アーキテクチャとトレードオフ この Blog では、「ネットワーク アーキテクチャ」について検討して行きます。前回は序論として、アーキテクチャの特質を 5点挙げてみました。そこで、これからの数回を使って、その特質について、少し深堀したいと思います。今回は、「トレードオフ」について述べます。 前にも書きましたが、「機能」は有用性が高いほど良いと言えます。今やネットワークのない生活は考えられませんが、ネットワークは速ければ速いほど良いし、少しでもつながりにくいと、とても不便に感じます。(子供が、くだらない(?)サイトを閲覧しながら、訳知り顔で「今日は何だかネットワークが重いなぁ」とか言うと、ひっぱたいてやろうかと思います。) しかしアーキテクチャには必ずトレードオフがあり、単純に、例えば「遅延は少なければ少ないほど良い」とは言えません。映像を伝送するときは遅延自体よりも遅延揺らぎ(ばらつき)の方が問題になるし、ストレージを接続する場合はパケット ロスは許されません。そこで、遅延を犠牲にしてバッファリングすることによって、揺らぎやロスを防いでいます。 なぜ、アーキテクチャを検討するときにトレードオフを考慮しなければならないのでしょうか。ひとつには、現実には制約がある、ということです。際限なくリソースやスペース・電力が使えるのであれば、性能も稼働率も規模も高めることはできます。しかし、現実の環境を考えると、決してそうはいきません。もうひとつは、アーキテクチャが、複数の要素の組み合わせ・つながり方・構造、といったものを対象とする、ということです。そして多くの場合、それぞれの要素は異なる特性を持ちます。先ほどの遅延の例ですと、遅延、パケットロス、遅延揺らぎはそれぞれ異なる要請を持ちます。遅延を防ぐためにはバッファは最小化すべきですが、一方、パケットロスを防ぐためには中継ノードに適量のバッファを持たせる必要があります。さらに、遅延揺らぎを防ぐためには、出口の(Egress)ノードにバッファを持たせ、出力間隔を揃える必要があります。またネットワーク仮想化の議論では、リソースを共有しつつ、適度な分離をどのように実現するかが焦点になりますし、ネットワーク設計では、要素自体の信頼性や性能だけではなく、その接続構造(つなぎ方)如何により、稼働率や性能を最大化することが求められます。品質や性能が思わしくないときには、通常、品質や性能の悪い要素を探し出してそれを改善する、ということが行われますが、それだけでは十分ではありません。要素間の接続の方法を見直す必要があります。 システム工学との違い – Art? トレードオフを問題にするのは、アーキテクチャの領域だけではありません。システム工学はまさに、あらゆる制約事項の中で、様々なトレードオフを考慮し、最適解を検討するための工学、ということができます。システム工学と言っても、対象とする「システム」によって異なるとは思いますが、実際、ネットワーク設計に必要となる待ち行列理論、フィードバック制御、シャノン情報理論、信頼性理論、シミュレーションやシステムズ ダイナミクスなどは、システム工学の知見に学ぶことができます。では、アーキテクティングはシステム工学とは何が違うのでしょうか? 上手く言えないのですが、アーキテクチャにはシステム工学が扱う事柄に加えて、どうしても芸術的・審美的・思想的な「何か」があると思います。美しい数学、美しい音楽と同じように、美しいアーキテクチャというものは存在するように思います。 「システム アーキテクチャ」に関する専門書が少ないことも、アーキテクチャが審美的なものを含んでいることを物語っているのではないかと思います。「美」とかいうことを持ち込んだ途端、証明し難く、論自体の信頼性を失ってしまうために、なかなか学術的な文脈には載せられないのです。そして前回ご紹介したおそらく唯一のシステムアーキテクチャの専門書は、「The “Art” of Systems Architecting」という、開き直った(?)表題になっています。 普遍的な美などというものが存在するか、というのは、神が存在するか、という議論にも似ているかもしれません。私は現実論者で神の存在は信じていませんが、普遍的な美のようなものはあるのではないかと思っています。例えば、バッハの音楽。自然の息をのむような美しさ。ただこれは、単なる個人的見解であることは言うまでもありません。 「いいとこ取り」は成立するか アーキテクチャとトレードオフに関して、一つ気になっていることを述べておこうと思います。それは「いいとこ取り」は可能なのか、ということです。異なるアーキテクチャが対峙するとき、それを調停させるために、よく「融合」とか「いいとこ取り」とか言われます。「通信と放送の融合」などです。また IP NGN は「電話の信頼性と IP の柔軟性のいいとこ取り」と言われていました。確かにシステム工学では、異なる要素が拮抗する中で最適解を求めるので、それを以て「いいとこ取り」と言えるかもしれません。しかしアーキテクチャの場合は、そのアーキテクチャに由来する性質が、表面に見えているもの以外の関連事項およびそのダイナミクスをも含むので、いいとこ取りはそんなに簡単ではないということを肝に銘じておかなければなりません。人間の性質に例えると、決断が早く果敢な

    続きを読む
    Tags:
  • アーキテクチャ

    ネットワーク アーキテクチャ考(1) 「序論」

    - April 1, 2013 - 2 Comments

     はじめに(このブログについて) この度、シスコが運営する公式ブログに書かせて戴くことになりました。ただし、「あくまでも個人の見解でありシスコの意見ではない」という免責事項がつきます。公式なサイトから公式見解でない情報を発信するというのは、何だかパラドクス的な感じがしますが、本質は往々にしてパラドクスに宿るのです。この貴重な機会と場を戴いたことに感謝し、日頃なかなかまとめて考察することができない「ネットワークアーキテクチャ」について、検討していきたいと考えています。   なぜ今「ネットワーク アーキテクチャ」か 現在は、希有な業界変遷期と言えると思います。業界構造も、主要なプレイヤーも、大きく変遷しつつあります。このような時代に、ネットワークがどのように適応し進化して行くかを見据えるためには、そのアーキテクチャに関する考察が必須になります。 私はこれまでずっと、ソフトウェアやネットワークといったシステムにかかわる仕事をしてきましたが、その過程で学んだことは、「アーキテクチャ」の重要性です。システムの「機能」を規定するのはロジックやアルゴリズムですが、可用性(availability)、拡張性(scalability)、相互運用性(interoperability)など、そのシステムの「性質や能力(-ilities)」を実現するのは、そのシステムの「アーキテクチャ」です。実際、どんなにそのシステムの機能が優れていても、混雑してくると応答時間が許容範囲を超えて遅くなる、拡張したいのにリソースの増強ができない、何かのモジュールに障害があるとシステム全体がダウンしてしまう、ということがよく起こるわけですが、このような場合、間違いなく「アーキテクチャが悪い」と言えます。すなわち、モジュール単体がどんなに素晴らしくても、それらのつながり方や構造如何によって、問題が起こり得る。特にネットワーク システムの場合は、モジュール単体では成立せず、何か別のモジュールとつながってこそのネットワークであるため、常に「アーキテクチャ」を検討する必要がつきまといます。   「アーキテクチャ」の特質 では、「アーキテクチャ」とは何でしょうか。今や情報がこんなにあふれているのに、意外に専門書は少ないように思います。様々なアーキテクチャフレームワーク・方法論 [1]、[2]、[3] を除くと、「システムアーキテクチャ」の理論的専門書としては、私の知る限り、『The Art of Systems Architecting』[4]が唯一無二ではないでしょうか。(他にもあれば教えてください。)「ネットワーク アーキテクチャ」に至っては、人々やそのコミュニティによって、=OSI参照モデルだったり、=プロトコルだったり、=トポロジーだったり、=インターネットそのものだったりします。さらには、マーケティング用語やコンセプト(SoA: Service Oriented Architecture、SDN [Software Defined Networking] Architecture ― すみません、これ私もよく使うのですが ― などなど)だったりする場合もあります。 かくいう状況ですので、ネットワーク

    続きを読む
    Tags: