マイクロサービスとは何か？

明確に言うと、万能のアーキテクチャは存在しません。最良や最悪のアーキテクチャもなく、ビジネスに最も適したアーキテクチャがあるだけです。

マイクロサービスの紹介

マイクロサービスアーキテクチャは、大規模なソフトウェアシステムを開発、デプロイ、および保守しやすくすることを目的とした柔軟でスケーラブルなソフトウェアアーキテクチャです。

マイクロサービスの基本的な考え方は、大規模なソフトウェアシステムを複数の比較的独立したサービスに分割し、各サービスが単一の機能に集中することです。

マイクロサービスアーキテクチャにおけるサービスは、ネットワークを介して通信するプロセスであり、HTTPやgRPCなどの技術に依存しないプロトコルを使用して目標を達成します。これにより、さまざまなビジネスニーズに応じて異なるサービスを組み合わせることが可能になります。

ソフトウェアアーキテクチャの進化

スタートアップアーキテクチャとしてモノリシックアーキテクチャを使用することから始めましょう。ビジネスが成長するにつれて、異なるアーキテクチャでどのような問題が発生するかを見ていきます。

モノリシックアーキテクチャ

モノリシックアーキテクチャは、アプリケーションのコンポーネントや機能がモジュール型アプリケーションのように疎結合ではなく密結合されている自己完結型として設計されています。モノリシックアーキテクチャを使用する多くの利点があり、そのため多くのアプリケーションがこの開発パラダイムを使用して作成されています。

典型的なモノリシックアプリケーションのデプロイの概要。この設計は確かにデプロイを簡単にしますが、ロールアップデートは困難であり、モジュールが失敗した場合に壊滅的な結果をもたらす可能性があります。

例えば、モノリシックアプリはスループットの点でモジュール型アプリよりも優れたパフォーマンスを発揮する可能性があります。各コンポーネントと関連するコンポーネントのコードがアプリケーションの実行またはコンパイルに必要であるため、モノリシックアプリはテストやデバッグが簡単になる場合があります。

モノリシックアプリケーションは過去に成功を収めてきました。しかし、クラウド時代において、モノリシックアプリケーションがクラウドベース環境にデプロイされるにつれて、モノリシックアーキテクチャに不満を抱く人が増えています。変更サイクルが結びついており、アプリケーションの小さな部分に変更を加えると、モノリス全体を再構築してデプロイする必要があります。

開発者は、更新ごとにコードベース全体を再コンパイルし、変更された部分だけでなく、モノリシックアプリケーション全体を再インストールする必要があります。これにより、継続的または定期的なデプロイが困難になり、アプリケーションとチームの敏捷性が低下します。

モノリシックアプリケーションを時間とともに良好な構造でモジュール化して維持することは困難であり、内部モジュールにのみ影響を与えるべき変更を維持することが難しくなります。スケーリングは、リソースを必要とする部分だけでなく、アプリケーション全体をスケーリングすることを要求します。

サービス指向アーキテクチャ

サービス指向アーキテクチャ（SOA）は、必要な機能を実行する個別で疎結合されたソフトウェアエージェントで構成されるアプリケーションを指すソフトウェアアーキテクチャであり、ソフトウェアコンポーネントを再利用可能にするためにサービスインターフェースを使用する方法を定義します。これらのインターフェースは広範な通信プロトコルを利用するため、重要な統合を必要とせずに新しいアプリケーションに迅速に追加できます。

典型的なSOAデプロイの概要。このようなアーキテクチャでは、単一のサービスの失敗の影響が効果的に軽減され、単一のサービスの反復率が向上します。

このようなアーキテクチャは、チームの拡大を管理するのに適しており、各チームが特定のサービス自体に集中できるようにします。 過去の重荷からチームを解放し、一つのタスクに集中して正しく実行できるようにします。

SOAとモノリシックアーキテクチャの利点は以下の通りです：

保守性の向上：各サービスは独立したエンティティであるため、ロールアップデートや保守が簡単で、他のサービスにリスクが及びません。
信頼性の向上：モノリシックアーキテクチャで使用されるような大きなコードブロックは、サービスよりもデバッグやテストが困難です。その結果、SOAベースの製品はより信頼性が高くなります。
並列開発：サービス指向アーキテクチャは、レイヤーがあるため開発プロセスにおける並列性を促進します。独立したサービスを同時に作成して完了することが可能です。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャは、アプリケーションを構成する一連の自律コンポーネントを構築することに焦点を当てたSOAの一形態です。単一の分割不可能な全体として構築されたモノリシックアプリケーションとは異なり、マイクロサービスアプリはAPIで結合された複数の独立したコンポーネントで構成されます。

アーキテクチャの範囲は、SOAとマイクロサービスの主な違いです。マイクロサービスアーキテクチャとは異なり、SOAモデルでは、サービスやモジュールが組織全体で共有および再利用されることが許可されています。言い換えれば、マイクロサービスはアプリケーションに焦点を当てているのに対し、SOAはエンタープライズスコープを持っています。

その他の違いは、以下の表にまとめられています：

	SOA	マイクロサービス
アーキテクチャ	サービスはエンタープライズレベルで再利用および共有されます	サービスは分離され、独立して動作します
粒度	比較的大きく、モジュール化されたサービス	ビジネスに特定の目的や機能を提供する、より小さく柔軟なサービス
通信	ESB	API
結合	リソース共有/疎結合	境界コンテキスト
相互運用性	Simple Object Access Protocol (SOAP)、Advanced Messaging Queuing Protocol (AMQP)、Microsoft Messaging Queuing (MMQ) などの複数のメッセージプロトコルをサポート	HTTP、Representational State Transfers (REST)、Java Messaging Service (JMS) などの軽量で言語に依存しないメッセージングプロトコルを使用
データガバナンス	コンポーネント共有の結果として、エンタープライズ全体で共通のデータガバナンス	サービスの独立した性質により、チーム間で一貫したデータガバナンスがありません
ストレージ	特定のアプリケーション内のすべてのサービスで共有される単一のデータストレージレイヤー	各サービスに必要なデータサーバーまたはデータベースを独立して使用

典型的なマイクロサービスのデプロイの概要

モノリシックアーキテクチャとマイクロサービスアーキテクチャのスケーリング戦略

詳細はこちらをご覧ください https://martinfowler.com/articles/microservices.html

モノリシックアーキテクチャと比較して、マイクロサービスアーキテクチャは反復開発方法論やアジャイル手法にも柔軟に対応します。さまざまなコンポーネント間の疎結合により、スケーラビリティが高く、個別にテスト可能です。さらに、モジュールは独自のデータベースを持ち、互いに通信し、プログラムの起動を高速化します。

マイクロサービスが必要な理由

マイクロサービスを利用することで、開発デリバリーサイクルの効率を大幅に向上させ、プロセスの敏捷性を高めることができます。 DevOpsとマイクロサービスの組み合わせにより、変更や新機能のデリバリーが加速されます。マイクロサービスは、モノリシックアプリケーションを含む大規模なソフトウェア開発プロジェクトよりも迅速に構築できます。変更の管理が容易で迅速です。

マイクロサービスの変更は、モノリシックなものよりも流動的でスムーズです。モノリシックアプリケーションのようなウォーターフォールはマイクロサービス開発プロセスにはありません。各マイクロサービスは独立しており、任意のプログラミング言語や構造で開発できます。

マイクロサービスの失敗は、大規模システムの失敗よりも深刻ではありません。モノリシックアプリケーションの一部の失敗は、通常、システム全体に重大な悪影響を及ぼします。マイクロサービス設計では、問題を迅速かつ簡単に解決できます。問題を認識し、分離し、補償します。マイクロサービスを使用するアーキテクチャでは、パフォーマンスのボトルネックを回避するためにマイクロサービスを拡張できます。モノリシックアプリケーションの運用上のウォーターフォールは、欠陥のあるマイクロサービスの新しいバージョンを迅速に作成することで回避できます。

マイクロサービスの利点

従来のアーキテクチャに対するマイクロサービスの利点は以下の通りです。

モジュール性：大規模なソフトウェアシステムを複数の比較的独立したサービスに分割し、各サービスが特定の機能を実行する責任を持ちます。これにより、さまざまなビジネスニーズに応じて異なるサービスを組み合わせることが可能になります。
スケーラビリティ：マイクロサービスアーキテクチャの重要な利点はスケーラビリティです。各サービスが比較的独立しているため、実際のニーズに応じて各サービスを動的に拡張または縮小することが可能です。これにより、ビジネストラフィックの変動により適切に対応できます。
デプロイ性：マイクロサービスアーキテクチャにより、各サービスを独立して柔軟にデプロイできます。これにより、新機能をより迅速にデプロイし、システム全体に影響を与えずに迅速に反復することが可能になります。
拡張の容易さ：マイクロサービスアーキテクチャは、各サービスに単一の責任と機能を与えます。このようなアーキテクチャでは、従来のソフトウェアアーキテクチャのモジュールよりもマイクロサービスの更新と再構成が容易であり、単一のサービスの失敗の影響範囲を管理できます。
保守の容易さ：マイクロサービスアーキテクチャにより、各サービスが小さくなり、特定の機能のみを実行する責任を持ちます。これにより、保守が容易になり、障害の修復が迅速になります。
技術的多様性：マイクロサービスアーキテクチャにより、各サービスが特定の技術スタックに制限されなくなります。サービス間のデータ相互作用は標準化されたインターフェースを介して実現され、現在のサービスシナリオに最適な技術スタックを使用してサービス開発を行うことができ、最適なソリューションを実現します。

まとめ

ソフトウェアアーキテクチャは、変化する要件に対応するために進化し、しばしば新しい懸念事項を統合します。マイクロサービスアーキテクチャは、クラウドネイティブ時代において徐々に人気を集めています。より良いマイクロサービスアーキテクチャを構築するために、APISIX、最高のAPIゲートウェイ、およびAPI7.aiをご覧ください。