Cisco Japan Blog

アーキテクチャ

  • アーキテクチャ

    ネットワーク アーキテクチャ考 (20) 「ネットワークはシステムだ!」

    - January 26, 2017

    ネットワークはシステムです。システムとは「相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体」を意味します。

    続きを読む
    タグ
  • アーキテクチャ

    ネットワーク アーキテクチャ考 (19) 「Buzzword とイノベーションと」

    - July 31, 2016

    唐突な質問ですが、みなさま、Buzzword とどう付き合ってますか。 おっとその前に、Buzzword とは何かを定義しなくてはなりません。ここではOxford、Merriam-Webster、そして Wikipedia の定義を引用してみます。 Oxford: 「A word or phrase, often an item of jargon, that is fashionable at a particular time or in a particular context(ある時期やある文脈において流行している語やフレーズ、多くの場合業界隠語)」 Merriam-Webster: 「An

    続きを読む
    タグ
  • アーキテクチャ

    ネットワーク アーキテクチャ考 (18)  「Digital Ageへ」

    - December 22, 2015

    これまで比較的方法論や要素技術を取り上げることが多かったのですが、年末にあたり、今回は少し視点を高くしてみます。「今我々はどこに向かっているのか。」 これについて、回答は明解です。「Digital Age(ディジタル時代)」へ。もしかしたら期待していたよりも急速な勢いで、現在我々は、ディジタル時代へと向かっています。「インターネット時代」において、人類は国境のない自律分散ネットワークを構築しました。これはすごいことです。技術が政治や経済の遥か先を先導し、現代に至った訳です。そして今「ディジタル時代」へ。 「ディジタル時代」においては、あらゆるものがネットワークに繋がり、多量かつ多種多様なデータが統計的・人工知能的に解析処理されます。 全てが瞬時に検索・照合・取引・流通可能となり、従来の、有形資産のみに依拠する業態や、権威だけに基づいた統治は存続が困難になるでしょう。 様々なディストピア的な事態も想定されます。しかし、現在のテロが多発する世界情勢を鑑みると、国家や政治などの権威が、人間の持つ負の感情を増幅していると言わざるを得ません。個人同志だったら、お互いの心を開くことにより、負の感情を増幅させることなく、むしろ分かり合い、喜びや悲しみなどの感情を分かち合うことが可能です。だから私は「ディジタル時代」に望みを託します。技術を中立に、公正に、活用することにより、できるだけ権威を集中させない。権威やそれを取り巻く世間の状況に過度に依存することなく、個人個人が尊重されれば、負の感情が増幅することはない。 何だか話が大それたものになってしまいましたが、ネットワーク システムのアーキテクチャを考える時も、中央集権的権威や命令型(Imperative)制御よりも、自律性、分散性、宣言的(Declarative)制御、オープン性、モジュラー性を重用することによって、システムの多様性、進化、頑健性、スケール性を支えて行きたい、と、強く考えています。 …次回からは、要素技術を中心としたアーキテクチャ論に戻ります。モデル・パターン駆動性、オープンソース活動、ステートの削減などについて、記述して行く予定です。 来年もどうぞよろしくお願い申し上げます!  

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (16) 「モジュラー性・オープン性とパッケージング、そしてダイクストラ」

    - June 30, 2015

    これまで私は至るところで、「仮想化アーキテクチャでは、モジュラー性・オープン性が重要。垂直統合してしまったら意味が無い。」と述べてきました。 今でもその考えは変わっていません。コモディティ化した汎用ハードウェアと仮想化アーキテクチャで実現するソフトウェア中心のシステムは、新たなサービスの柔軟かつ迅速な展開、小規模スタートや実験的展開、顧客の細かい要求に応じたテーラーメイド サービスなどに、大きな価値を発揮します。これらは、これまで周到な設備計画が必要だったハードウェア中心のシステムでは実現できなかったことです。しかし、その機能の性能最適化をしたければ、目的に特化したハードウェア システムの方が、コスト、スペース、電力等、あらゆる面で適しています。既に機能が固定化されているような既存サービスの置き換えや、大容量高性能を目指すシステムには、仮想化アーキテクチャは勧められません。 しかし、しかし…。現実というものは、そんなに簡単に割り切れるものでもありません。「仮想化システムだから性能出なくても仕方ない。性能よりも重視すべきはモジュラー性とオープン性、云々かんぬん…」とか言ったら、お客様は間違いなく離れてしまいます。 では、オープン性やモジュラー性を保ちながら性能を最適化することは可能なのでしょうか。いや、すみません、無理です。現実問題到底無理です。どんなハードウェアや NIC(Network Interface Card)を使おうが、どんな HostOS/Hypervisor を使おうが、どんな Virtual Switch(OVS, Linux-bridge, VPP*1、Snabbswitch*2、DPDK-OVS*3など)を使おうが、ある一定の性能値を保証する、なんてことは、できる訳ありません。 これまでシスコとしては、まずは User Space の Virtual Switch として、性能最適化した VPP(Vector Packet Processing)を開発したりしていますが、基本オープンという方針を貫いていました。(この辺については、ネットワーク アーキテクチャ考 (13) 「仮想化:性能面の課題」 をご参照ください。)しかし、これではどうにも立ち行かなくなってきました。そこで紆余曲折の上の解が「パッケージング」です。NFV OS(仮称)というもので、転送の高速化、低遅延化(VM 間、ホスト間)、VNF

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (15) 「SDN/NFV これまでの振り返りとこれから」

    - May 17, 2015

    SDN/NFVは、アーキテクチャ変遷の一つの可能性です。通信事業者は、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。そのため、「アーキテクチャ変遷」を大きなテーマの一つとしているこのBlogでも、SDNやNFVについてのいくつかの、総論的な話題を取り上げてきました。 しかしこの辺でそろそろ一旦振り返り、次のステップに踏み出したいと思います。そこで今回は、振り返りのきっかけになったことと、今後考察して行きたいことを書きます。 Network Programmabilityと宣言的プログラミング 対立する価値の統合 White Box SwitchとForwardingのコモディティ化 Traffic Modelの変化とこれからの可能性 1. Network Programmabilityと宣言的プログラミング 振り返りのきっかけになったことの一つは、ネットワークプログラマビリティ勉強会[1]です。ここでは、「実際にやってみたレポート」から、理論的なことまで、「ネットワークプログラマビリティ」に関するあらゆることが、ゆるやかに、そして和気あいあいと議論されています。私も若手に混じってスタッフをさせて戴いており、先日は発表の機会も戴いたので、「宣言的(Declarative) vs 命令的(Imperative)か」というプログラミングパラダイム議論を、ネットワークプログラマビリティに適用させた発表をさせて戴きました[2]。現時点ではまだ試論の域を出ていないのですが、今後もっと考察を重ねて行きたいと考えています。 プログラマビリティや自動化の必要性は論を俟たないとして、これからは、それをどう行うか、の議論に注力する必要があると感じています。システムは放っておくとどんどん複雑化します。ソフトウェア中心のシステムであれば尚更です。この状況で、制御を記述する方法もどんどん複雑化してしまったら、手に負えないシステムになりかねません。ネットワークプログラマビリティと言ってもひたすらコーディングすればよい訳ではなく、数学的、論理学的理論に基づいたコーディングスタイルが必須となると考えています。特にネットワークのような複数の要素が接続される分散システムの場合は、手許にリソースがあるシステムのプログラミングよりも、より不確定性が高いのです。 2. 対立する価値の統合 もう一つのきっかけは、先日Ciscoのセミナーで実施させて戴いたパネルディスカッション[3]です。NTTコミュニケーションズ、KDDI、Softbankという大手通信事業者から第一線のアーキテクトにご登壇戴き、NFVを中心としたアーキテクチャの現状と今後に関する考察を、率直に議論しました。この時の内容は、InSPireという弊社のWeb Magazineに投稿いたしましたので、ぜひご覧戴きたいと思います。 ”Service Provider Architecture” のこれから – NFVの現状、課題、可能性そしてその先へ いくつかの興味深い考察がなされたのですが、特に印象に残ったのは、アーキテクチャ変遷時には、異なるそして時には対立しうる複数の価値の統合が求められる、ということです。”Agile Devops”(迅速に開発と運用のフィードバックループを廻す)vs “Carrier-Grade”

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (14) 「『仮想化』は何のため(再び)、そして変革へ」

    - February 19, 2015

    前回、前々回と、仮想化における課題を書きました。しかし、これらはまだ初期段階の課題です。現時点での仮想化、少なくとも SP(サービスプロバイダー)領域で NFV と呼んでいるものは、従来のアーキテクチャで実装した機能をほぼそのまま VM でエミュレートしているに過ぎません。仮想化ならではの恩恵を活かすためには、現在のプロセス モジュール構成でよいのか、そのまま VM に載せるのではなくコンテナとして実装した方が良いのではないか、プログラミング パラダイムやコーディング手法自体を見直した方がよいのではないか、などのことを、じっくり吟味する必要があります。 もう一つ。「仮想化の目的はコスト削減」と言う声を多く聞きますが、これには異を唱えたい。もちろん仮想化によって、初期投資を削減することはできます。しかし、ある程度のキャパシティ、性能を実現しようとすると、仮想化だけではコスト削減にはなりません。むしろ、仮想化のオーバーヘッドがある分、電源容量なども増大する可能性があります。さらに、オープンソースを含めた、より多様で複雑なインテグレーションが必要となるため、そのままではコストは増大する傾向にあります。 これらのコスト上昇リスクを抑えるためには、入念な検討が必要です。一方、仮想化の目的や大義名分をコスト削減だけに置いてしまうと、仮想化プロジェクトの予算は削られ、限られたリソースで無理難題を強いられることになりますから、プロジェクトは成功するどころか疲弊して迷走します。せっかくの変革の契機なのに、これでは本末転倒です。既存の価値のままコスト削減を追求するのではなく、新たな価値を追求する方が良いと思います。 では仮想化の価値とは一体何でしょうか。以前「仮想化は何のため」というエントリーで、次の 2つを挙げました。 必要なときに必要なサービスやリソースを、迅速にそして自動的に提供することを可能にすること あるオブジェクトを仮想化エンティティへと断片化することにより、並列分散処理を行うこと しかし、何よりもまず重要なのは、これら仮想化アーキテクチャのメリットを十分に活かせるような、これまでの技術実装やアーキテクチャの見直し、サービスの迅速な展開を実現するアジャイル体制への変革なのではないかと、最近は痛感しています。これは言う程簡単なことではありません。現在の構造にもそれを必要として来た理由がある訳ですから。 このことを同僚と議論していたら、最近彼が出たアジャイル基礎のセミナーで、Kotter の 8つのステップが取り上げられた、と話してくれました。Kotterの『Leading Change』[1]!元は 1995年の Harvard Business Review の論文ですが、書籍化され何度となくベストセラーになっています。私も数年前、行き詰まりを感じていたときに当時の上司に読まされました。なかなか継続的に実践するのは難しいのですが、よい機会なのでここに引用させて戴こうと思います。現実を直視し、徹底的に危機感を持ち、チームを形成して行動し、周囲に影響を与え、文化として定着させる。これぞ、生きて仕事をすることの醍醐味というものではないでしょうか。変革を愉しみましょう!! The Eight-Stage Process of

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (13) 「仮想化:性能面の課題」

    - February 9, 2015

    前回の投稿では、仮想化における運用面の課題を書きました。今回は、もう 1 つの大きな課題である性能面を検討します。 1)  仮想化環境における転送性能最適化について 仮想化アーキテクチャのインフラストラクチャとなるサーバは CPU に特化したハードウェアであるため、当然、NPU(Network Processing Unit)や ASIC(Application Specific Integrated Circuit)に比べると転送性能は低いです。さらに、ハードウェアで行う割り込みや I/O などの各種処理を仮想化レイヤにてエミュレーションする必要があるため、オーバヘッドが大きくなります。 これまで、データセンターの仮想化においては、転送性能よりも柔軟性やスケーリングといった効用の方が大きく上廻っていたため、あまり転送性能の最適化は問題視されてこなかったのだと思います。しかし、通信事業者の場合、ネットワークサービスの提供に必要な品質と性能を安定的に供給する必要があるため、やはり転送性能を重視することになります。 そのため、転送性能最適化の方法論が必要になる訳ですが、仮想化アーキテクチャにおいてどのように性能を最適化させるか、という問題は、仮想化アーキテクチャの理念にも関わります。 サーバ ハードウェア、ハイパーバイザ、Guest OS、アプリケーションが垂直統合されたシステムの場合は、各コンポーネントの提供する仮想化支援機構、 機能および動作振る舞いを全て掌握できるため、比較的容易に転送性能の最適化を行うことができます。しかし、仮想化の特性を最大限に活かすためには、垂直統合型よりも水平統合型アプローチの方が適しており、そのためには可能な限り、特定のベンダーや特定の技術組み合わせに依存せずに、性能最適化を行えるような方法論が必要となります。 2) 転送性能最適化に関する取り組み シスコでは、高付加価値高性能な ASIC の設計開発に力を入れてきており、これは今後とも継続します。一方これと並行的に、市販ハードウェアを利用した性能最適化のための技術開発も恒常的に行っています。ここでは、それらの性能最適化技術をいくつか紹介したいと思います。 a) Hypervisor bypass

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (12) 「仮想化:運用面の課題」

    - January 9, 2015

    仮想化は目的ではなく、アーキテクチャ変遷における一つの通過点と捉えています。とはいえ、ネットワーク機能の仮想化により、下記のようなメリットを実現できる可能性があります。 コスト削減と技術革新の高速化 サービス開発サイクルの短縮化 オープン性とエコシステムの促進 柔軟なスケーリング 障害の限局化とシステムとしての高可用性 一方、仮想化によるアーキテクチャ変化は、新たな課題をもたらします。今回は、運用面の課題を書きます。 1) 状態監視方式について まず、現在確立している状態監視や障害箇所特定などの運用管理方式を、仮想化アーキテクチャに適応させる必要があります。これまでは、どのネットワーク機能がどのハードウェアで動作しているかは明白でしたが、仮想化環境においては、仮想化インスタンスとハードウェアなどのインフラとの関係が分離されています。さらに、システムの負荷状況に応じて、VNF(Virtual Network Function)を構成するコンポーネントを増加させたり、または VNF 自体を増やしたりすることが考えられますが、その場合、VNF が接続されている全体のネットワークトポロジーも追随して変更される可能性がある。このため、システムに柔軟性や弾力性を与えると同時に、それをダイナミックに運用管理可能とするオーケストレーション システムが重要になります。 2) ネットワーク運用との役割分担、または融合 次に、ネットワーク運用との役割分担の問題があります。これまでは、ネットワーク運用と、サーバやアプリケーション ソフトウェア運用との間に明確な責任分解点がありましたが、仮想化環境においては、仮想化インスタンス間の通信が、同一サーバ内・同一ハイパー バイザ内で閉じる場合もあれば、同一ラック内で閉じるケース、データセンター内で閉じるケース、さらには複数サイトにまたがる場合などが考えられます。そのため、どのように責任分解するかが新たな課題です。例えば、サーバ上に実装されている仮想スイッチも、ネットワーク管理者の責任下とすることも考えられるし、ACI(Application Centric Infrastructure)モデル[1]のように、アプリケーションの観点から、必要となるネットワークを設定・管理する方式も考えられます(図1)。また、VNF に割り当てる IP アドレス、仮想ネットワークに割り当てる IP アドレスや vlan tag

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (11) 「『NFV』- 逆説に本質が宿る」

    - September 7, 2014

    最近の私は「仮想化」には嵌まっています。以前「SDN と仮想化」というエントリーで、「ネットワーク アーキテクチャが変遷する際には必ず仮想化を伴っている」という観測を書きました。あれから 9ヶ月が経過していますが、日々その裏付け事例が増えていると感じています。その時も書いたように、共起関係からは因果関係を帰結できないので、アーキテクチャ変遷が仮想化を要請するのか、仮想化がアーキテクチャ変遷を喚起するのかは分かりませんが、「ネットワーク サービスの仮想化」という側面から見ると、後者の様相が強いかもしれないです。 例えば、相変わらず定義が定まらない“SDN”ですが、「(VMなど)仮想インスタンス間を接続するネットワーキング手法」と考えると、非常にすっきりします。ad hoc に生成され移動する仮想インスタンスのために、いちいちコマンドラインで「機器の設定」なんてやってられないのは明らかです。勿論、ネットワークを使うのは仮想インスタンスだけではないけれども、少なくとも SDN ブームの出発点として仮想化を位置づけると、SDN の意義がクリアになります。 「仮想」という逆説 仮想化の意義については前回も書いたのですが、そもそも、なぜ仮想化がそんなにも自分をわくわくさせるのか、について考えてみました。そして思い当たったのが、「仮想とは大いなる逆説である」ということです。通常、仮想化は「非-現実」とか「非-物理的なもの」とかと捉えられますが、virtual の語源を繙くとラテン語の virtualis。何と「美徳」の virtue と同じ語源で、exellence(卓越)、 potency(力)、efficacy(有効性)を表すとのこと[1]。「現実」ではないものが、実は「力」や「有効性」を持っている、というのですから、何と言う逆説! 確かに、He/She is a virtual member of the team. というとき、正式には(例えば人事的には)そのチームには属していないけれども結構実力は買われている、とかいう場合がありますよね。まぁ、実力が無ければ、正式に組織に属していないのにわざわざメンバーとして招聘されることもないのでしょう。また、VPN は、Virtual Private Network(仮想専用網)ですが、共通インフラストラクチャ上、場合によってはグローバル

    続きを読む
    タグ
  • SDN

    ネットワーク アーキテクチャ考 (10) 「『仮想化』は何のため」

    - June 7, 2014

    仮想化アーキテクチャの周辺は日々進化していて、落ち着く暇がありません。この春 Cisco は、通信事業者向けの、仮想化環境における Orchestration Layer アーキテクチャとして、ESP(Evolved Service Platform)を発表しました。しかしこれは製品でもなくソリューションでもなく、概念的フレームワークであるため、現場は扱いに困ります。この概念的フレームワーク、深く読めば、ACI(Application Centric Infrastructure)や InterCloud などとも共通する遠大な構想に裏付けられているのですが、いざ、このフレームワークを見せられても、それだけでは何も言っていない。具体的な解を提供しないといけないときに、遠大な構想などを持ち出したら、お客様からは話をはぐらかしているように捉えられてしまいます。この辺が最近感じている難しさであり、もどかしさであります。なお、多少は具体的な解の例として、日経コミュニケーション『SDN のすべて』特集に、Segment Routing について記事を執筆させていただきました。これは SDN といっても、主に WAN(広域ネットワーク)を対象とした「シンプル化」への一つの解になりますが、ご覧いただけたら嬉しいです。 仮想化の2つの意義 仮想化の意義は、突き詰めて言えば次の2つになると考えます。まず、 必要なときに必要なサービスやリソースを、迅速にそして自動的に提供することを可能にすること。Everything as a Service、XaaS、いわゆるクラウドサービスです。これは、仮想化されたエンティティをリソース プールとして集積し、必要に応じて(On demand)迅速に(Agile)、割当てて提供することにより実現されます。もうひとつは、あるオブジェクトを仮想化エンティティへと断片化することにより、並列分散処理を行うことです。以前から分散システムは存在していましたが、断片化の単位が柔軟になり、かつ Map Reduc アルゴリズム[1]が登場したために、並列分散処理を有効活用できるアプリケーションが急速に増えました。並列分散処理の適用は一般的には難しいとされていたので、ここ10年の進展は目覚ましいものです。前者の仮想化はコンピュータそのものをエミュレートする Virtual

    続きを読む
    タグ