前回のエントリーでは「パッケージング」について書きました。これまでモジュラー性やオープン性を最重要視して来たが、ある程度の「パッケージング」概念を取り入れることにより、性能のチューニングや、組合せ発散による現実的な問題（検証工数など）に対処する、というアーキテクチャ選択肢もあり得る、という主旨でした。この方針はさらに推進され、Intel 社との NIC、NSH などにおける連携[*1]、Redhat 社、Canonical 社などとの Hypervisor、Openstack Distribution におけるの連携などが推進されて行くことになります。
今回はしかし、この「パッケージング」の対極概念である「分解（De-Aggregation）」について書きます。分解というのは大変強力な概念です。スケーラビリティ、保守性、障害箇所の特定や切り離し、継続性など、多くのことがモジュラに分解することによって解決することは、私たちも日々のエンジニアリングの現場で感じていることです。ところで「分解」の概念が明文化は、何と 17 世紀のデカルトにまで遡ります。デカルトは「方法序説」第 2 部で次の準則を挙げています[*2]。
- 私が明証的に真理であると認めるものでなければ、いかなる事柄でもこれを真なりとして認めないこと
- 検討しようとする難問をよりよく理解するために、多数の小部分に分割すること
- もっとも単純なものからもっとも複雑なものの認識へと至り、先後のない事物の間に秩序を仮定すること
- 最後に完全な列挙と、広範な再検討をすること
1 は明証・実証の重要性、2-4 は分解の重要性を述べている訳です。（3 は一旦分解してから再統合すること、4 は分解したものに過不足がないかの再検討をすることなので、2-4 をまとめて「分解」の概念と捉えています。）これらは科学的精神の基本の基であり、21 世紀に生きる私たちにとっても当然に重要です。
Map & Reduce などのアルゴリズムは、この分解の概念を使って高度な並列性とスケーラビリティをもたらした、ブレークスルーの例です。アーキテクチャ変遷期にも、分解して統合し直す、ということがよく行われます。プログラミング パラダイムのオブジェクト指向も、それまでの手続き型言語に対する分割とモジュラー化の捉え直しです。またネットワークを例に取ると、電話網の進化も、MPLS も、そして最近の SDN も、そのコンセプトや内容が微妙に異なるものの、「Software と Hardware の分離」「Control Plane と Data Plane の分離」が行われた、と捉えることができます。
このように、昔も今も「モジューラ性と疎結合性」は重要なアーキテクチャ理念であります。
しかし分解にばかり重きを置くと，実際の適用にあたっていろいろ問題が出てきます。私見ではありますが、大きく２つの問題があると考えています。
1 つめは、「一体どこまで分解すべきなのか」という問題です。これは目的によって異なるので、ひとつの正答はありません。例えば、ある書物を分解する際、分解の単位は何にするか。章なのか、パラグラフか、センテンスか、句や節か、語（ワード）なのか。まさかアルファベットの単位まで分解することはないだろう、と思うかもしれませんが、アルファベット出現頻度分析を行う場合などは、アルファベットにまで分解することになります。逆に言えば、アルファベットにまで分ける、ということは出現頻度分析でも行わない限りは意味のない分解になる、ということになりますが…。要するに「意味のある」分解単位を決定するためには、その分解の意味を吟味する必要があります。
人間の個人を英語で「individual」と言うのは、なかなか深いものがあります。人間の身体はこれ以上分解できない、分解したら意味がない。しかし臓器移植や、脳移植、頭部移植[*3]などの可能性は、この単位も絶対ではないかもしれない、ということを示唆しています。勿論、この分解を進めることに意味があるかどうかについては、さまざまな側面からの十分な検討が必要になるでしょう。
2 つ目の問題は、「分解するからには、分解前の全体がわかっている必要があるが、その全体が不明な場合どうするか」という問題です。（ところで、「わかる」という日本語を漢字で書くと、「分かる」もしくは「解かる」です。分解できなければ「わかった」ことにはならない、ということか!!!）先ほどの人間を例に取りますと、個人まで分解する前の「全体」は、組織と社会とかになるのでしょう。しかし、その組織や社会って何かといえば、簡単には定義できません。
ソフトウェアの場合、目的とスコープが明確でトップダウンで設計するのなら、全体が明確に定義でき、それを分解したものが各モジュールということができます。しかし実際は、モジュールをボトムアップ的に組み合わせて新たな機能や価値を提供する場合も多いものです。ネットワーク システムでいえば、各モジュールをつなげたものがネットワークになりますので、基本的にはボトムアップ的です。「最初に全体ありき」ではなく、「最初にモジュールありき」という場合もあり得るということです。こう考えると、意味のあるモジュール単位を決定するのは、非常に重要なことであると、改めて思います。
なんでこんなことを書いているかとういと、お気づきの方もいらっしゃるかと思いますが、SDN で Control Plane と Data Plane の分解が進む現在、Network Device という観点でこの分解をどこまで進めるべきか、という点について模索しているからです。私の現在の考えでは、上述したようなボトムアップ的・自己組織化的なネットワーク特性を考えると、モジュールが自律性を持つレベルの分解度合いがよいと考えます。OS まで分離する完全な White Box 化には懐疑的ですし（コンピューティング領域ではある程度成功したモデルではありますが）、ましてCPU やメモリといった部品にまで分けるのは意味がないと考えています。
ただ、自分の子供が臓器移植でしか生きられないような状況になった場合、「意味が無い」とか言ってる場合ではなくなると思うのと同様、シスコの製品が市場に受け入れられるにはそうするしかない、と判断される場合は、そうするしかないのかもしれません。
最終的には適度によいアーキテクチャに収斂する、ということを信じていますけれども！
[*1] http://www.cisco.com/c/dam/en/us/solutions/collateral/service-provider/network-functions-virtualization-nfv/nfv-partnership.pdf
[*2] https://ja.wikipedia.org/wiki/方法序説
[*3] http://www.cnn.co.jp/world/35062759.html
Authors
1 コメント
De-aggregationよりもDis-aggregationの方が適切だったかな？