マイクロサービスプレミアム

ここ1年ほど、マイクロサービスアーキテクチャが話題の中心となっています。最近開催されたO'Reillyソフトウェアアーキテクチャカンファレンスでは、ほとんどすべてのセッションでマイクロサービスについて語られていました。これには、誰もが過剰な期待に対する警戒心を抱くほどでした。この結果、チームがマイクロサービスを過度に受け入れようとする傾向が見られるようになりました。[1]マイクロサービスにはそれ自体が複雑さをもたらすことを理解していないのです。これはプロジェクトのコストとリスクを増大させ、深刻な問題に陥ることがよくあります。

マイクロサービスに対するこの過剰な期待は迷惑ですが、私はこの用語が、しばらく前から存在しているものの、議論しやすくするために名前が必要だったアーキテクチャのスタイルを表すのに役立つと考えています。ここで重要なのは、この過剰な期待に対してどれだけ不満を感じるかではなく、提起されているアーキテクチャ上の疑問です。マイクロサービスアーキテクチャは、あなたが取り組んでいるシステムにとって良い選択肢なのでしょうか？

興味深い質問に対するまともな答えは、常に「場合による」から始まります。

-- Kent Beck

私の答えも「場合による」から始めなければなりませんが、その後、焦点を「何に」依存するかに移す必要があります。マイクロサービスを使用するかどうかの要となるのは、検討中のシステムの複雑さです。マイクロサービスのアプローチは、複雑なシステムを処理するためのものですが、そのためには、独自の一連の複雑さをもたらします。マイクロサービスを使用する場合、自動デプロイ、監視、障害への対処、結果整合性、および分散システムがもたらすその他の要因に対処する必要があります。これらすべてに対処するためのよく知られた方法はありますが、それは余分な労力であり、ソフトウェア開発に携わる人で時間を持て余している人はいないように思われます。

したがって、私の主な指針は、モノリスとして管理するには複雑すぎるシステムがない限り、マイクロサービスを検討することさえしないでくださいということです。ほとんどのソフトウェアシステムは、単一のモノリシックアプリケーションとして構築する必要があります。そのモノリス内の適切なモジュール性に注意を払う必要がありますが、それを個別のサービスに分割しようとしないでください。

マイクロサービスへの移行を促す複雑さは、大規模なチームへの対応[2]、マルチテナンシー、多くのユーザーインタラクションモデルのサポート、異なるビジネス機能の独立した進化、およびスケーリングなど、多くのソースから発生する可能性があります。しかし、最大の要因は、純粋なサイズです。人々は、修正やデプロイをするには大きすぎるモノリスを持っていることに気づくのです。

この時点で、私はある種の不満を感じます。モノリスに起因するとされる多くの問題は、そのスタイルに不可欠なものではありません。モノリスでは継続的デリバリーを行うことが不可能であるため、マイクロサービスを使用する必要があると言う人がいますが、FacebookやEtsyなど、クッキーカッターデプロイアプローチで成功している組織はたくさんあります。

システムが大きくなるにつれて、修正や置き換えが容易な部分を持つためにはマイクロサービスを使用する必要があるという議論も聞きました。しかし、モジュール境界が明確に定義された単一のモノリスを作成できない理由はありません。少なくとも理論上は理由はありません。実際には、モジュール境界が破られやすく、モノリスが巨大化し、絡み合ってしまうことが多すぎるようです。

また、マイクロサービスシステム間でサービスサイズに大きなばらつきがあることも忘れてはなりません。私は、20のサービスを持つ60人のチームから、200のサービスを持つ4人のチームまで、マイクロサービスシステムが変化するのを見てきました。サービスサイズがプレミアムにどの程度影響するかは明らかではありません。

規模やその他の複雑さの要因がプロジェクトに影響を及ぼし始めると、多くのチームがマイクロサービスの方が良い状況であると気づいています。しかし、そのような複雑さに直面していない限り、マイクロサービスのアプローチは高いプレミアムをもたらし、開発を著しく遅らせる可能性があることを忘れないでください。したがって、マイクロサービスの必要性を回避できるほどシステムをシンプルに保てるのであれば、そうしてください。