マイクロサービスへの執着がもたらすマクロインフラ問題

コンテキスト

クラウドとインフラのコード化は、我々の業界を革命的に変えました。それによって、シンプルで適応性の高い方法でインフラを調達できるようになりました。

これにより、巨大なモノリシックアプリケーションの開発から、互いに連携するマイクロサービスの開発へと移行することが可能になりました。

マイクロサービスの最も受け入れられている定義の一つがこんな感じです：

他のサービスとリソースを共有せず、独立してデプロイされるべきで、短い時間で書き直せるほど小さな自己完結したコードの一部分です。

これはソフトウェアプロジェクトの個々の部分を考えるときは素晴らしいことのように聞こえますが、システム全体とその動作を考えると、ソフトウェアは決して完全に孤立して動作するわけではないという点を考慮する必要があります。目的を達成するためには他のシステムとのやり取りが必要です。

過去のモノリシックアプリケーションの多くは、決して起こらないかもしれない変更を可能にするために、設計が複雑になりすぎるという問題を抱えていました。

これはマイクロサービスでも起こりうるのでしょうか？

問題点

ドメインの明確さ

システムが小さな部品でどんどん成長すると、全体の構図を理解することがより複雑になります。

部品が小さすぎると、ドメインイベントはネットワークのノード間での情報交換になり始めます。これによって、システムのドメインに関する知識の結束力が失われ、システム全体を通じたコンセプトやアクターの実際の意図と能力を掴むのが難しくなります。

バベルの塔の問題

システムの部品が多くなるほど、異質性が高まります。これは同時に統合やフレームワークが増え、学習曲線が急になり、配信に影響を及ぼすより複雑な環境になります。システム内で、いつ、どこで新技術を追加するかのバランスが必要です。判断は好みではなく、ニーズに基づいて行わなければなりません。

暗黙のランタイム依存関係

システムが分割されるほど、特定のノードへの依存が高まります。これは、インフラパズルのピース間に多くの依存関係を引き起こし、「神」のようなインフラポイントがシングルポイントオブフェイルになったり、特定の順序で一気にデプロイされるような依存インフラのチェーンが生じます。

隠された複雑さ

マイクロサービスの環境が成長すればするほど、監視、アラート、メインシステムの一部としては使用されていない他のサービス向けのサポートインフラが必要になります。これは通常、別の努力が必要であり、コストを伴います。システムが成長するにつれ、これらの隠れた複雑さがシステムのすべてのノードにとっての依存関係となり、それらの依存関係を進化させたり変更したりする作業が複雑なものになります。

使わない場合があるがなぜ？

マイクロサービスの主な考え方の一つは、仮定をすばやく検証することでした。新しいサービスやインフラを設計する前に、実験に必要なドメイン知識を含む既存のサービスやインフラが現在のエコシステムに存在するかどうか自問自答する必要があります。注意を払わないと、実験は実験ではなくなります。それらはMVPとなり、単独のノードとして持つためだけに、再びドメイン知識が実装されます。

自分自身の繰り返し

独立したコードのピースを作るとき、私たちのシステムのそれぞれのノードで必要とされ、繰り返されるある程度のブートストラッピングが常にあります。これは、コードの重複セットだけでなく、開発時間のコストも引き起こします。高い粒度のシステムでプロジェクトをブートストラッピングすることは、標準化が複雑になる可能性があります。

マイクロサービス、クラウド、サービスとしてのインフラは確かに私たちの業界を革命的に変えましたが、何にでもバランスが必要です。適切なツールを使い、コードレベルだけでなくインフラレベルでも過度の工夫をしないようにすることが大切です。何もかもがコストを伴うからです。

結論

結論として、マイクロサービスへの執着がもたらすマクロインフラは、増加した複雑さや付随するコストの増加、システムの変更や更新における課題を引き起こす可能性があります。マイクロサービスは拡張性や柔軟性の向上などの利点を提供する可能性がある一方で、組織は特定のニーズを慎重に考慮し、アーキテクチャに適切な粒度を選択することが重要です。

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/alvarolorentedev/double-edge-microservices-macro-infrastructure-due-to-microservice-obsession-2k44