Cotoami のアーキテクチャを、どのような体制、あるいは場を作って開発したいのかという観点から考えてみたい。いわゆるコンウェイの法則に沿ったシステムデザインである。
現状のシステム、つまり Oinker.me のアーキテクチャは以下のようになっている。
Grailsフレームワークを利用して実装されたアプリケーションサーバーが中心となり各種サービスの連携を計る、いわゆるオーケストレーション (orchestration) モデルのアーキテクチャである。
マイクロサービス本でも指摘されているように、オーケストレーションは素直なアーキテクチャではあるが、システムを拡張する度に指揮者となるサービスに手を入れる必要がある。例えば、現状 Oinker の検索エンジンは壊れているのだが、この修正を誰かに頼みたいと思ったら、まず指揮者となるサービス（Grailsアプリケーション）について理解してもらう必要がある（「え、今更Groovyを勉強しないといけないの？」）。これは指揮者が肥大化すればするほど骨の折れる作業になる。
多くの組織で開発言語を統一しようとするのは、おそらくこのオーケストレーションの仕組みに起因している。メンバーが同じ言語や環境に習熟していないと共同開発が難しくなるのである。
しかし、新しいものを生み出そうとする場合、様々なレベルにおいて多様性を損なう事は長期視点で考えるとマイナスになると筆者は考える。システムデザインにおいて「一貫性」は抗い難い誘惑だ。しかし、システムや組織が進化するためには、多少のいびつさを許容しなければならない。そのいびつさを許容する仕組みが、最近耳にする事が多くなって来た「コレオグラフィ (choreography)」モデルのアーキテクチャにあるのではないかと考えている。
ThoughtWorksのサイトに、オーケストレーションとコレオグラフィの違いを表す図が紹介されている。
- Scaling Microservices with an Event Stream | ThoughtWorks
オーケストレーション:
コレオグラフィ:
コレオグラフィアーキテクチャによって、システムを構成する各サービスの連携が疎結合に保たれ、かつ、非同期の連携なので全てのサービスが同じ負荷に耐えなくても良いというおまけも付いてくる。システムに新たな機能を追加する場合に参照するのは、指揮者となるサービスではなく、システムの拡張点となるイベントである。追加機能の起点となるイベントだけに着目すれば良いので、イベントを受け取れる限り、どのような言語・環境でサービスを開発しても良い。既存システムを変更せずに機能を追加出来るのはもちろん、いらなくなった機能を捨てたり、新しい言語で実装し直したり、ということも容易になる。
と、ここまではあくまでWebや書籍でかじった知識で書いている机上の空論に過ぎないので、この考えがどれぐらい有効なのかはまだ分からない。Cotoamiプロジェクト上で検証して行きたいと思う。
今のところの感覚では、イベント駆動という連携が、RESTのような従来型の連携に比べて複雑なのは明らかで、だからこそ、コレオグラフィは同じ言語で実装された統一的なプラットフォームの上で実現するという流れが強いように感じる。だけども、それではサービスの多様性を実現するための疎結合という理想からは離れてしまう。おそらくこの辺にコレオグラフィの辛みがあるのかもしれない。
あまり意識されないかもしれないが、言語やプラットフォームを統一するのは、それはそれである種の密結合である。今は目眩を覚えるほどの多様性が言語やフレームワークにある時代である。その多様性の中で独自性を得ようとするエンジニアの力を借りるために、この密結合はデメリットとして働くのではないかと今のところは考えている。
ゆびてく 