第 (N+1) 次オブジェクト指向問答

Masayoshi Hagiwara @masayh

マイクロサービスを全社システムに適用した場合：アプリが2000として、1アプリ10マイクロサービスとして、2万。重複などを整理して1万マイクロサービスとすると、それらを連携する仕組みをP2Pで構成するのはほぼ論理的には絶望的。少し考えるとまったくスケールしないことがわかる。

Masayoshi Hagiwara @masayh

マイクロサービスの統制をどうするかの問題。運用管理のコストは劇的に上がるが、それよりも変更の迅速化の利点が上回れば採用は有効とする。社内で採用が進めば進むほど、マイクロサービスの数は増大するので、コストがあがり、採用の有効性は減ってしまう。自己矛盾を起こす技術。

Masayoshi Hagiwara @masayh

マイクロサービスを設計の方法論をDDDとするMSの戦略。DDDはオブジェクト指向分析設計の古典だが、それ以降あまりソフトウェア工学が進歩していないので、よりどころにする合理性はわからないでもないが、マイクロサービス向きなのかどうかは疑問。しかも、スケールしない問題をどう解決するか

Masayoshi Hagiwara @masayh

マイクロサービス間の依存関係を非同期やスキーマの独立など物理的に排除したところで、ビジネス上のかかわりから意味的な依存関係は排除できないので、表面的な独立性は維持できていても、論理的な依存関係は排除できていない。見えない分より、管理コストは高まる。

Masayoshi Hagiwara @masayh

マイクロサービスを提唱したFowler氏の性格やポジションの戦略があるのだろう。同じく言えるのが、reactive manifesto（reactiveの概念ではない）もポジションの戦略。

Yuta Okamoto @okapies

本当に大規模なマイクロサービス群になってくると、一周回ってサービス間の依存関係の記述みたいな話が出てくるのかなぁ。どのくらいの規模からの話なのかは想像もつかないけど。

Yuta Okamoto @okapies

コンピュータシステムをスケールさせるより開発者の組織をスケールさせる方が難しい、っていうのが根本的な所としてあるからマイクロサービスだっ！ってことになってるんだろうけど、いずれにせよ見えないコストは積み上がり続ける、と。

Yuta Okamoto @okapies

コンポーネント (C) とグラフ (G) が再帰的に積み上がっていく構造、つまり: アクター (C) → データフロー DSL (G) → マイクロサービス (C) → 分散配備 DSL (G) → … みたいなアーキテクチャって可能なのかなぁ、と最近よく考えてる。

まろ@関数型言語作曲機械学習勉強してない @_marony

これ、関数は小さくクラスは小さくとかも同じなんですけど、局所化していた複雑さを関係に逃がしてるだけだと思うんですよね

Yuta Okamoto @okapies

@_marony まぁ、短期的には確実に扱いやすくなるので意味はあると思うんですけどね。大規模化した時にどうかって話はありそうです。

まろ@関数型言語作曲機械学習勉強してない @_marony

@okapies 弊社のシステムが昔から単機能な多くのサービス群からできていて、単体のサービスの障害はあまりないですが依存関係によるものには苦しめられてます。ソースから追うのが難しく複雑で数人しか全体像を把握してません。

Yuta Okamoto @okapies

@_marony なるほど。例えばですけど、そこを可視化するツールがあれば何とかなりそうですかね（実現可能性は置いておいて。

まろ@関数型言語作曲機械学習勉強してない @_marony

@okapies 依存関係は自動で可視化できると思います。そこは僕も把握してます。時間や状態も含めてとなるとなかなか難しいです。業務の都合上、その辺りが複雑なので。

Yuta Okamoto @okapies

@_marony なるほど…。軽減はできそうですけど根絶は厳しいでしょうねぇ。

Yuta Okamoto @okapies

単機能のモノが組み合わさった複雑なシステムのバランスが崩れた時の対処の難しさというのは、まさに人体が典型ですね。腰痛の治療の難しさってそういうことみたいだし（腰をさすりながら。