inSPire は、シスコがサービス プロバイダー向けに厳選した、シスコの高度な技術と最新のニュースをお届けするニュースマガジンです。

【コラム】”Service Provider Architecture” のこれから - NFVの現状、課題、可能性そしてその先へ

河野 美也 >プロフィール
シスコシステムズ合同会社
Principal Systems Engineer

アーキテクチャを変える、ということは、簡単なことではありません。その理由はクレイトン・クリステンセンが「イノベーションのジレンマ」[1]で考察しているとおりです。しかし、通信サービス事業者のアーキテクチャは確実に変化しています。

かつて通信事業者の中心的サービスは電話でした。しかしインターネットが台頭するやいなや、通信事業者は、IPによるデータに最適化されたネットワークを構築しました。さらに、電話やビデオを含む全てのサービスを、IP/MPLSネットワーク上で提供するようになりました。そして今、通信事業者は、SDNや仮想化、NFVといった手段を基に、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。

ここ数年SDN/NFVへの市場の関心が続いていますが、マーケットに流布される言説にはbuzzword(何となく説得力がありそうだけれども曖昧な言葉)やhype(誇大な広告)が含まれます。今回のEPNセミナーでも、SDN/NFVに関する技術やソリューションを、できるだけ実例などを交えながら紹介しましたが、メーカーからの一方的なプレゼンではやはり良い面だけがクローズアップされることは否定できません。そこで今回は、セミナーの最後にパネル ディスカッションの機会を設け、実際の事業者の立場からのご意見、ご提言を戴くことにしました。年度初のお忙しい中、NTTコミュニケーションズ 棚橋 弘幸様、KDDI 大垣 健一様、ソフトバンクモバイル 西 和人様という、それぞれ業界の第一線でご活躍されているアーキテクトにご登壇戴くことができました。この場を借りまして厚くお礼申し上げます。

パネル ディスカッションのテーマとして、次の2つを掲げました。

  • Reality check!
  • What is your takeaway?

テーマ1はreality check。現実を直視しようという試みです。NFVの一般的な効用として、「新たなビジネス機会」「迅速なサービス展開」「運用コスト削減」「設備コスト削減」といったものが挙げられていますが、実際のところどうなのか。

テーマ2では、パネリストの方々それぞれのtakeaway(得たこと、重要と思うこと)をお伺いしました。多くのbuzzwordやhypeの中から、また実際の課題などを通じて、通信事業者のアーキテクトたちは何を本質と捉え、今後に向けてどう活かして行こうと考えているのか。

これらを通じて、次のサービス プロバイダー アーキテクチャ変遷への手がかりを得られるのではないか、というのが、今回のパネルディスカッションのテーマを計画した大きな狙いです。

まずテーマ1. Reality Checkでは、現状の課題が浮き彫りにされました。まず運用面では、 構築やプロビジョニングはスピーディで楽になったが、 トラブル シューティングの難易度が高くなった、という指摘がありました。NFVでは、サーバHW、Hypervisor、Guest OS、仮想アプライアンス、と構成要素が多岐に渡り、かつその組合せがすぐに指数関数的に増えますので、切り分けだけでも大変です。性能面も、まだまだ期待通りのレベルに到達してはいません。「チャンピオン データ」は意味が無い、という指摘もありました。全ての構成要素を恣意的に最適化してデータを出されても困る、前提条件が明確化され、かつ、構成要素間のインタフェースがオープンでないと、仮想化アーキテクチャにおいては意味が無い、ということです。

費用対効果の面においても、現状では専用機に比べて優位とは言えない、という指摘がありました。オンデマンドでスケールすると言っても、ライセンス体系によってはメリットにならないし、アプライアンス単体でVM版の方が 安かったとしても、別途オーケストレータの開発費用が必要になるし、サーバの保守費もかかる。サブスクリプション型のビジネス モデルに向けて、コスト体系の再検討をする必要がありそうです。また、 まずは、テーラー メードの個別ネットワーク サービスの提供を目指す、という考え方も提示されました。確かにNFVは、これまでとは異なるトラフィック モデルに対応する、とか、他サービスへの影響の無い自己完結型システムをトライアル的に作成する、などの用途に適していると言えそうです。

さらに、文化の違いというか、社会的役割の違いのようなものにも気づかされました。

通信事業者において基準となる性能の考え方は「ゼロロス パケット スループット」です。 1パケットでもロスするようであれば、それはsustainableなスループットとは言えないので、実効スループット値として提示できません。しかし仮想化環境では変動要素が多いため、たとえリソースにまだ余力がある状態でもパケット ロスする可能性があります。そのため、ゼロロスを基準とすると、かなり低い値を出さざるを得ないことになります。少なくともこのままでは、アプリケーション アプライアンスはよいとしても、安定性や継続的な高スループットを求められる通信インフラに、仮想化は向かないと言わざるを得ない。

また、実際の主要クラウド サービスにおける可用性データが紹介されましたが[2]、1時間以上のサービス ダウンも結構起こっており、場合に依っては10数時間に渡るダウンが現実に起こっていることがわかります。そのような中、通信事業者によるサービスの場合、「 継続時間1時間以上、影響利用者3万人以上の障害は、重大事故として監督官庁である総務省への報告義務がある」とのことで、何だか戦々兢々とします。標準化状況も途上で、相互接続を担保するようになる状況には程遠い、という指摘もありました。

テーマ2の ”What is your takeaway?” では、 かなり奥の深いアーキテクチャ考察がなされることになりました。

最大の問いは、異なる、時には相反する多元的な価値を、どのように統合するか、統合できるのか、という問題と言えるかもしれません。

例えば、「ネットワークとサーバの両方の構築運用ノウハウが必要」、という指摘がありましたが、元々、ネットワークエンジニアに求められるスキルと、サーバ エンジニアに求められるスキルは少し異なる面があります。ネットワークエンジニアにとっては、ノードへの設定内容および状態(operational data)、ノード間の接続関係、プロトコルとその状態遷移、パケット ダンプなどがエンジニアリングの手がかりであり、比較的ブラック ボックス的、かつボトム アップ的です。一方、サーバ エンジニアには、OS, Hypervisorの知識と活用能力はもとより、プログラミング能力が求められます。「コードを読み書きしてなんぼ」なので、比較的ホワイト ボックス的アプローチと言えます。

また、「Telecom Devops」という概念も提示されました。これも、事前に綿密な予測と計画が求められる”Telecom”的アプローチと、設計者と運用者が一体となりその時々の状況にアジャイルに適応する”Devops”的アプローチという、相反する価値の統合が求められます。

さらに、「SDN/NFVの自動化/中央集権化は、自律分散協調型の現ネットワークの置き換えになり得るのか」という問いも出てきました。これも、自動化/中央集権化という価値と、自律分散協調という価値を、どう統合するか、という問題と捉えられます。(自動化は、必ずしも中央集権でなくても可能ですが、 制御が論理的には一元化されていないと制御不能のような状態にもなり得るため、やはり無視はできません。)このように、アーキテクチャ変遷期を乗り越えるためには、異なる複数の価値を取捨選択、統合して行く必要に迫られる訳です。

ここで一つヒントとなると思ったのが「モデル駆動型(Model-driven)アプローチ」です。 プロシージャ的なコードによりトップ ダウンで制御対象を制御する自動化の方法に比べて、制御対象に自らの機能や能力を宣言して貰い、それを抽象化しモデルとして操作する方法は、制御対象の自律分散性を損なわず、かつ中央の集中システムがボトルネックになりにくいため、頑健性やスケール性を保ちながら明示的な制御ができる可能性があります。プログラミング パラダイム議論の「命令的(Imperative)か宣言的か(Declarative)か」にも少し似ています。勿論、モデル駆動型アプローチが全てを解決する訳ではないので、今後より深く考察、検証していくつもりです。

この他にも、数々の印象深い考察がありました。例えば「自動化はパンドラの箱」。開けてしまったらもう戻れない。レイ・カーツワイルのシンギュラリティ[3]にもあるように、人工知能の指数関数的進歩は停められない。「発生する大量のイベントをどう扱うか」、という問いもありましたが、ネットワークの運用も、 これからはまさに、ビッグ データとディープ ラーニング、コグニティブ コンピューティングなどを駆使して自動運用、自動障害解析や回復をして行く、ということになるのでしょう。人間が指差し点検で設定を確認していた、なんて時代がそんなに昔ではなかったことを考えると、かなり大きな変革可能性です。我々としては、どう使いこなすか、適用領域をどのように設定するか、「自動化を容易にするアーキテクチャとはどのようなものか」、 ということを検討しなければなりません。

事前打ち合わせをした訳でもないのに、三人のご登壇者がかなり共通の現状認識をお持ちだったことも、印象的でした。一時間という短い時間でしたが、仮想か物理か、ということも超越した沢山の宿題を戴いた気がします。事業者にせよメーカーにせよ、それぞれ立場は異なり競合することもありますが、同じ時代を共有するコミュニティとして、共に、様々な課題を解決して行けたらと思います。なお、「課題解決に不可欠なものは、アーキテクチャ、実装、それを支える標準化、そして集合知」という提言もありました。そして「実装 = とにかくまともに動くもの」、「アーキテクチャ = 見誤ってはならないもの」と。「実装がきちんと動く。」「アーキテクチャを見誤ってはならない。」大変重要なことです。しっかりと胸に刻みたいと思います。ありがとうございました。

当日の資料は下記に公開しています。よろしければぜひご覧下さい。

当日の資料はこちら[PDF:9MB]
  • [1] "The Innovator's Dilemma - When new technologies cause great firms to fail", Clayton M. Christensen (1997) 邦訳「イノベーションのジレンマ: 技術革新が巨大企業を滅ぼすとき」翔泳社 (2000)
  • [2] https://cloudharmony.com/status
  • [3] “Singularity is near - When Humans Transcend Biology”, Ray Kurtzweil (2005) 邦訳「ポスト・ヒューマン誕生―コンピュータが人類の知性を超えるとき」日本放送出版協会 (2007)
バックナンバー
Issue 18(2015年1月)Issue 17(2014年10月)Issue 16(2014年7月)Issue 15(2014年5月) Issue 14(2014年1月) Issue 13(2013年10月) Issue 12(2013年7月) Issue 11(2013年5月) Issue 10(2013年1月) Issue 09(2012年11月) Issue 08(2012年7月) Issue 07(2012年5月) Issue 06(2012年2月) Issue 05(2011年11月) Issue 04(2011年7月) Issue 03(2011年5月) 2011春の特別号(2011年3月) Issue 02(2011年2月) 創刊号(2010年10月) 創刊準備号(2010年7月)