マイクロサービスと分散オブジェクトの第一法則

私がエンタープライズアプリケーションアーキテクチャのパターンを書いたとき、「分散オブジェクト設計の第一法則：「オブジェクトを分散しない」」という言葉を造りました。近頃、マイクロサービスへの関心が高まっているため、マイクロサービスはこの法則に反しているのか、そしてもしそうだとしたらなぜ私がそれを支持しているのかという質問をいくつか受けました。

この第一法則の記述において、「分散オブジェクト」というフレーズを使用していることに注意することが重要です。これは90年代後半から00年代初頭にかけて流行していた考え方ですが、その後（当然のことながら）廃れてきました。分散オブジェクトの考え方は、オブジェクトを設計し、それらの同じオブジェクトをインプロセスでもリモートでも使用することを選択できるというものです。リモートとは、同じマシン内の別のプロセス、または異なるマシンを意味する場合があります。DCOMやCORBA実装などの巧妙なミドルウェアがインプロセス/リモートの区別を処理するため、システムを記述し、アプリケーションの設計方法とは無関係にプロセスに分割することができました。

私が分散オブジェクトの概念に反対した理由は、オブジェクト境界の背後に多くのものをカプセル化できるものの、リモート/インプロセスの区別をカプセル化できないためです。インプロセスの関数呼び出しは高速で常に成功します（例外は、呼び出し自体ではなくアプリケーションによるものです）。しかし、リモート呼び出しは桁違いに遅く、リモートプロセスまたは接続の障害によって呼び出しが失敗する可能性が常にあります。

この違いの結果、APIのガイドラインが異なります。インプロセス呼び出しは細かくすることができます。100個の製品の価格と在庫状況が必要な場合、製品価格関数に100回、在庫状況に100回呼び出すことができます。しかし、その関数がリモート呼び出しである場合、通常はそれらをすべて1回の呼び出しにまとめて、100個すべての価格と在庫状況を一度に要求する方が良いでしょう。その結果、製品オブジェクトへのインターフェースが大きく異なります。したがって、同じクラス（主にインターフェースに関するもの）をインプロセスとリモートの両方で透過的に使用することはできません。

私が話をしたマイクロサービスの支持者は、この違いをよく理解しており、インプロセス/リモートの透過性について話す人はいませんでした。そのため、彼らは分散オブジェクトがしようとしていたことをしようとしておらず、したがって第一法則に違反していません。代わりに、彼らはHTTPまたは軽量メッセージングを介した粗粒度のドキュメントとのやり取りを提唱しました。

したがって、本質的に、分散オブジェクトに関する私の見解とマイクロサービスの支持者の間には矛盾はありません。この本質的な非矛盾にもかかわらず、今まさに問われるべき別の質問があります。マイクロサービスは、モノリスよりもはるかに多くのリモート接続を介して通信する小さな分散ユニットを意味します。それは、文字どおりには満たしていても、第一法則の精神に反していませんか？

多くのシステムで分散設計を行う正当な理由があることを認めつつも、分散は複雑さを増幅する要素であると考えています。粗粒度のAPIは、細粒度のAPIよりも扱いにくいです。リモート呼び出しの失敗、および整合性と可用性への影響について、何をするかを決定する必要があります。プロトコル設計によってリモート呼び出しを最小限にしても、それらに関するパフォーマンスの問題についてさらに考える必要があります。モノリスを設計する場合、モジュール間の責任の割り当てについて心配する必要がありますが、分散システムでは、モジュール間の責任の割り当てと分散要因について心配する必要があります。

小さなマイクロサービスは確かに理解しやすいですが、このことがサービス間の相互接続に複雑さを押し付け、それが明確ではなく、問題が発生したときに把握するのが困難になることを懸念しています。リモート境界を超えてリファクタリングを行う必要がある場合、リファクタリングははるかに困難になります。マイクロサービスの支持者は、非同期通信によって得られる結合の低減を謳っていますが、非同期性もまた、複雑さを増幅する別の要素です。クッキーカッター型スケーリングを使用すると、分散の複雑さを増すことなく、大量のトラフィックを処理できます。

したがって、私は分散に警戒しており、デフォルトではモノリシックな設計を好みます。そうであれば、なぜマイクロサービスについて多くの労力を費やし、それを提唱している同僚を支援してきたのでしょうか？その答えは、私の直感は常に正しいとは限らないからです。Netflixや（おそらく）Amazonなどのよく知られた公開事例、またはThoughtworksの内外で私が話をしたさまざまなチームなど、多くのチームがマイクロサービスのアプローチを採用し、成功を収めていることは否定できません。私は生粋の実証主義者であり、たとえその理論が私の直感よりもはるかに精緻に練られていたとしても、経験的証拠は理論よりも優先されると信じています。

まだ問題は解決されていないと考えています。ソフトウェアデリバリーにおいて、成功は非常に曖昧なものです。NetflixやSpotifyなどの組織は、マイクロサービスによる初期の成功を喧伝していますが、EtsyやFacebookなど、はるかにモノリシックなアーキテクチャで成功した例もあります。チームがマイクロサービスでどれだけ成功したと考えているとしても、唯一の真の比較は反事実です。つまり、彼らはモノリスの方がうまくいったでしょうか？マイクロサービスアプローチは比較的最近のものであるため、10年もののレガシーマイクロサービスアーキテクチャから、私たちが嫌うような古いモノリスと比較できる証拠はほとんどありません。そして、私たちが特定していない要因があり、状況によってはモノリスの方が優れている一方で、他の状況ではマイクロサービスの方が有利である可能性があります。ソフトウェア開発における証拠収集の難しさから考えると、たとえ多くの年が経っても、どちらか一方を支持する説得力のある決定が下されない可能性の方が高いです。

この不確実性を考えると、私のような著者ができる最も重要なことは、たとえそれらが矛盾していたとしても、私たちが学んだと思う教訓をできるだけ明確に伝えることです。読者は自分で決定を下します。私たち著者の仕事は、それらの決定が、アーキテクチャのどちら側に立とうとも、十分な情報に基づいたものになるようにすることです。

---