最近、「オーケストレーション」という言葉を耳にする機会が増えました。仮想化された要素を構成し、モニターし、柔軟なサービス提供に役立てるために、オーケストレーションは重要な役割を果たします。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 に関するアーキテクチャアプローチ
Cisco は伝統的に（?!）、管理システム系に弱いと言われていました。実際そのとおりで（!!）、イノベーションは専らルータやスイッチに起こり、管理システムはどうしても後手後手になります。新機能が開発されたとしても、管理システム側の追随には時間がかかり、ようやく対応したら、ルータやスイッチの側ではもう次のことを考えているのです。しかも Cisco は自律分散型の組織で、それぞれのBU（Business Unit, 事業部）が、それぞれのイノベーションに凌ぎを削っており、社内競合も珍しくありません。それらを統合的に扱う管理システムの開発なんて、無理難題という他ありません。
しかし、最近のクラウドやSDN/NFVブームにより、知やアルゴリズムの統合が重視されることになり、管理システム系の重要性が大いに見直されることになりました。Cisco もこの分野に、かつてない程の投資をしています。それで NMS（Network Management System）担当の重役とかいう人々が日本にやってきたりするのですが、時々困惑することがあります。彼らは往々にして、次のようなことを言います。
「まずは、ビジネス上の課題があり、システムはその課題を解決するために存在する。そのためにシステムはどうあるべきか、ネットワークはどうあるべきか。これを顧客とともに考えるところから始めるべきである」
これは全くその通りで正論なのですが、なかなかそのとおりには実践できません。技術者はビジネス課題に疎いからでしょうか。多少はその傾向があるのかもしれませんが、私はそれには異を唱えたい。決して技術者はビジネス課題に疎遠であってはなりません。ではなぜ困惑するのか。それは、まずビジネス課題ありきで、そこから専らトップダウン的に技術に落として行く、という方法に無理があるのではないか、という懸念からです。
ある課題に対するソリューション、そしてソリューションを実装する手段としての技術要素には山ほど選択肢があります。しかし、技術要素や方式そのものが問題になる場合もあるのです。単なる目的から手段への一方向ではなく、目的と手段が相互に影響するフィードバック、フィードフォワード モデルの方が、今のアーキテクティングには適しているのではないかと考えます。また、現在求められているのは、管理システムというよりは、オーケストレーションです。オーケストレーションが「自律的で多数の要素を有機的にまとめあげるためのレシピまたはプログラムをつくること」だとすると、まずはその自律的な要素のふるまいや特性をよく知る必要があり、そこから、ビジネス課題に合わせてどう統合して行くか、という視点も必要になります。
なお、以前と違うところは、要素自体が、当初からその機能にアクセスするためのデータモデルを具備する、ということが定着してきていることです。これにより、「管理システム側の追随」というタイムラグはなくなります。
オープン性、モジュラー性、拡張性
では、オーケストレーションシステムに求められる特性は何でしょう。私が最も重要視したいのはオープン性（Openness）、そしてモジュラー性（Modularity）と拡張性（Extensibility）です。
最初に「オープン」であること。オープン性については、二重三重の意味があります。今後様々な環境で動作させることを考えると、できるだけ特定のハードウェアや Hypervisor に依存せずに動作することが求められます。また、複数のベンダー製品、複数のシステムを対象にする必要があるため、モジュール間のプロトコルや API はオープンであるべきです。さらに、複数の組織のオーケストレーション システムやそのサブシステムを相互接続できる必要もあります。そして、最後になりましたが、オープンソースを柔軟に活用できるようにすべきです。現在仮想化基盤においては、すぐれたオープンソース ソフトウェアが凌ぎを削っています。Configuration Management Tool ひとつをとって見ても、puppet, shef, cloudify, juju, saltstack などがあります。「巨人の肩の上に立つ」ではありませんが、コミュニティに参加して切磋琢磨するのと、独自に一から開発するのでは、スピード面でも品質面でも雲泥の差が出てしまいます。
モジュラー性や拡張性は、オープン性に随伴する、と言って良いでしょう。モジュラー性がなければオープンにできないし、モジュラー性がありオープンであれば、拡張が可能になります。
オーケストレーションは遍在し、再帰する
オーケストレーションについて議論するときに気をつけないといけないのは、「オーケストレーション システムは遍在し、かつ再帰する」ということです。仮想化基盤（NFVI）のオーケストレーションに対して、アプリケーション（VNF）側でのオーケストレーションが存在する可能性があるし、上位のオーケストレーション（メタ オーケストレーション）、下部のオーケストレーション（サブ オーケストレーション）が存在する可能性もあります。その都度どこに注目して議論をしているかを明確にしないと、話が噛み合なくなります。
ETSI NFV 参照アーキテクチャの図および参照点は、共通の想定を持って議論できる、という点で非常に有用です。ただしその一方で、一面的にしか書かれておらず、遍在や再帰を表せていない点に、留意が必要です。オーケストレーションは階層化される可能性があるし、単一のデータセンター要素だけでシステムが構成されるとは限りません。同一サイトであっても複数のデータセンター要素により構成される場合もあるし、地理的にサイトが分散される場合もあります。そのため、例えばSDN controller（data-planeをprogrammingするもの）を NFV 参照アーキテクチャのどこに位置づけるべきか、という議論がありますが、この機論は、 SDN で制御する対象のスコープをどう捉えるかに依って変わって来るため、それだけでは意味が無いことになってしまいます。
Authors
