システムアーキテクチャをネットワークとして考える

ぼくはアーキテクチャなる概念が好きでそんなことばかり言っているのだが、とてもじゃないが伝わりやすい概念ではない。IT開発の現場においてむろん重要な概念であるし、エンジニアに限らず伝わると良いのにとよく考えているので、つらつらと書いてみる。

アーキテクチャとネットワーク

アーキテクチャを単純に訳すと"構造"ということになる。検索すればいろいろな定義が見つかるわけだが、ぼくがアーキテクチャという語で多くの場合にイメージすることはネットワークである。

ある要素を点として、点を線でつなげていった図をイメージすればよい。人同士の繋がりを表現すれば人のネットワークであるし、システム間の繋がりであればシステムのネットワークである。

ネットワーク図は要素間の関係を線として表現し、要素間のホップ数（経由する要素の数）によってコストを表現する。更に要素間で矢印の向きや繋がりの重み付けを加えることもできる（が、ぼくはそこまで考えないことが多い）。

現実世界のネットワークをイメージする

ネットワークをイメージするにあたっては、現実に存在するネットワークのことを考えたい。

すぐ思い浮かぶネットワークのひとつが人間関係ではないか。仕事に寄せれば、組織図のようなネットワークが浮かぶ。ある部署のメンバ間は多くの線を結び合い、密なネットワークを作る。一方で部署間の人間を結ぶ線は少ない。

この疎密が情報密度の差をつくる。密なネットワークを作る要素が多すぎるとネットワークを情報が流れすぎてパンクするし、集団内の依存関係が強まりすぎてネットワーク構造の変更が容易でなくなる（属人化など）。かといってつながりがあまりにスカスカでは情報伝達に多くの要素を経由する必要があり伝達効率が悪く、情報が偏り失われていく。

インターネットは遠回りしてでもちゃんと情報が伝達されることを重視したネットワーク構造をとっている。しかし組織ネットワークでは情報の伝達効率も重視したいので、それなりには密なネットワークでなければならない。つまり、どこをどのくらい密にして、どこをどのくらい疎にするかを考える必要がある。

ネットワークにおける疎密を考える

ITソフトウェアアーキテクチャの問題として、たびたび密結合について語られる。密結合は相互に依存関係を持つ結合を指す。結合の片側を変更するともう片側も変更しないといけない性質のことであり、一般に良くないことであるとされる。

時折すべてを疎結合にしなくてはならない、とでもいうような主張をされることがある。その極端さはネットワークで考えてみるとわかるのではないかと思う。すべてを疎にすることも、すべてを密にすることも、コミュニケーションの問題を引き起こす。むろん意図的に偏らせることは構わないのだが、そうしたトレードオフの中で決定されるべきことだ。

ITであればドメイン駆動設計におけるコアドメインの考え方は似たものであると思う。コアドメインは事業の中心領域のことであり、そこが市場競争力を持つゆえにビジネスロジックは必然的に複雑化する。こうした複雑性を管理するためにドメイン駆動設計はあるのであって、サービスに存在する複雑性をなくすことなどできない。コードやサービス上にある複雑である領域の内側を密につなぎ、それ以外の領域とを疎につなぐように設計しようとする。

ネットワークの指向性を調整する

ここまでで重要なことは、ネットワークは指向性を持つということだろう。その指向性が強いか弱いかはものによるが、少なくともネットワークは客観的で絶対的なものなどではない。ネットワーク構造に現れるコスト、ギャップ、インセンティブが構成要素の行動を決定づけ、ネットワーク全体の意志をつくる。なので目的に対して適切な指向性を持つネットワークを作ることが求められる。

構成要素の行動を変えたいときには、構成要素自体を変えるというよりも、ネットワーク構成を揺り動かす。構成要素はすぐ変わったりしない（というか変わることなどないのかもしれない）。責務や名前や接続を調整するなどのネットワーク上のつなぎ変えにより、ネットワーク上でのその構成要素の意味や意義を変える。こうした作業でネットワークの指向性をそのときどきの目的に対して調整してゆく。

アーキテクチャ設計においてはこうした変更を含むフィードバックサイクルの設計が肝心である。指向性やネットワーク構造の変化を受けて、ネットワークを変化させてゆく。

補足として

とはいえ、アーキテクチャという言葉が指すものはもちろんそれだけではない。ネットワーク構造だけでは実際のコードやデータや人の動きなどを考えることはできない。しかし、具体的な要素≒人、実装、金みたいなものから目を離して抽象的に考えたいとき、それは有用な視点を提供してくれると思う。

仕事として上流レイヤを考えることが多くなり最近とみに思うのだが、IT開発者がアーキテクチャについて学んだ方が良い理由は別にインフラを理解したり全体を意識した設計をできるようになどではなくて、ITシステムを考えるときに人とか金とかを同じ俎上に載せて考えられる視点が必要だからなのではないか、と思えている。

ITシステムをただのコードの連なりと見ていてはトレードオフの判断は難しい。レイヤが違う話を同じ俎上に乗せるには抽象化が必要だ。その一つの見方としてネットワークがある、と思う。