モノリシックアーキテクチャとマイクロサービス アーキテクチャ

  • 10 分

Fabrikam は、新しいドローン サービスを既存のアプリケーションに統合しました。 彼らは、このソリューションがアプリケーションに適した長期的な計画ではないことを認識しています。 既存のシステムはモノリシック アーキテクチャですが、それは正確に何を意味しますか?

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

モノリシック アーキテクチャは、アプリケーションのすべてのコンポーネントが 1 つのユニット内に併置されるアーキテクチャです。 このユニットは、通常、アプリケーションの単一のランタイム インスタンス内で制約されます。 従来のアプリケーションは、多くの場合、Web インターフェイス、サービス レイヤー、データ レイヤーで構成されます。 モノリシック アーキテクチャでは、これらのレイヤーはアプリケーションのインスタンスに結合されます。

モノリシック アーキテクチャの論理図。

モノリシック アーキテクチャは、多くの場合、小規模なアプリケーションに適したソリューションですが、アプリケーションの成長に伴って扱いにくい場合があります。 当初は小規模なアプリケーションであったものが、スケーリングが困難で、デプロイが困難で、イノベーションが困難な複雑なシステムになる可能性があります。

すべてのサービスは 1 つのユニット内に含まれます。 この取り決めは、ビジネスとその後のシステム負荷の増大に伴う課題をもたらします。 これらの課題の一部を次に示します。

  • サービスを個別にスケーリングすることは困難です。
  • コードベースの拡大に合わせてデプロイの開発と管理が複雑になり、リリースと新機能の実装が遅くなります。
  • アーキテクチャは 1 つのテクノロジ スタックに関連付けられており、新しいプラットフォームと SDK のイノベーションを制限します。
  • データ スキーマの更新はますます困難になる可能性があります。

これらの課題は、マイクロサービス アーキテクチャなどの代替アーキテクチャを調べることで対処できます。

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

マイクロサービス アーキテクチャは、小規模で、独立した、疎結合のサービスで構成されます。 各サービスは、個別にデプロイおよびスケーリングできます。

マイクロサービス アーキテクチャの論理図。

マイクロサービスは、1 つの小規模な開発者チームが作成および保守できる十分な小ささです。 サービスを個別にデプロイできるため、チームは、アプリケーション全体を再構築したり再デプロイしたりすることなく、既存のサービスを更新できます。

各サービスでは、通常、その固有データが処理されます。 データ構造が分離されているため、スキーマのアップグレードや変更は他のサービスに依存しません。 通常、データの要求は API を介して処理され、明確に定義された一貫性のあるアクセス モデルが提供されます。 内部の実装の詳細は、他のコンシューマーには表示されません。

各サービスは独立しているため、さまざまなテクノロジ スタック、フレームワーク、SDK を使用できます。 サービスは、リモート プロシージャ コール (RPC) やその他のカスタム通信メソッドではなく、適切に定義された API を使用して、サービス間通信の REST 呼び出しに依存しているのが一般的です。

マイクロサービス アーキテクチャは、テクノロジには依存しませんが、多くの場合、コンテナーやサーバーレス テクノロジが実装に使用されているのが見受けられます。 開発アクティビティの速度と品質を高めるため、継続的デプロイと継続的インテグレーション (CI/CD) がよく使用されます。

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

マイクロサービス アーキテクチャを選択する理由 マイクロサービス アーキテクチャには、いくつかの主な利点があります。

  • 敏捷
  • 小さなコード、小さなチーム
  • テクノロジの組み合わせ
  • レジリエンス
  • スケーラビリティ
  • データの分離

敏捷

マイクロサービスは個別にデプロイされるため、バグ修正や機能リリースが管理しやすくなります。 アプリケーション全体を再デプロイせずにサービスを更新し、問題が発生した場合は更新プログラムをロールバックできます。 多くの従来のアプリケーションでは、アプリケーションの 1 つの部分でバグが見つかった場合、リリース プロセス全体が中止になる可能性があります。 その結果、バグ修正が統合、テスト、公開されるのを待って新機能が保留される可能性があります。

小さなコード、小さなチーム

マイクロサービスの規模は小さく、1 つの機能チームによって構築、テスト、およびデプロイできます。 小さなコード ベースを理解しやすくなります。 大規模なモノリシック アプリケーションでは、コードの依存関係が時間の経過と同時に絡み合う傾向があります。 新しい機能を追加するには、さまざまな場所でコードに触れる必要があります。 マイクロサービス アーキテクチャでは、コードやデータ ストアを共有しないことで依存関係が最小限に抑えられます。 これにより、新しい機能を簡単に追加できます。

チーム サイズが小さい場合も、機敏性が向上します。 "ツーピザルール" は、チームは 2 枚のピザで充分なほど小さくあるべきだと言います。 明らかに、それは正確な指標ではなく、チームの好みに依存します。 しかし、重要なのは、通信が遅くなり、管理オーバーヘッドが増加し、機敏性が低下するため、大規模なグループの生産性が低下する傾向があるということです。

テクノロジの組み合わせ

Teams は、サービスに最適なテクノロジを選択できます。 必要に応じて、テクノロジ スタックの組み合わせを使用できます。 各チームは、サービスを個別にサポートするテクノロジを進化させることができます。 この独立により、サービスはさまざまな開発言語、クラウド サービス、SDK などを使用できます。 Teams では、サービスのコンシューマーに対する外部からの影響を最小限に抑えながら、サービスに最適なオプションを選択できます。

レジリエンス

個々のマイクロサービスが使用できなくなった場合、アップストリームマイクロサービスが障害を正しく処理するように設計されている限り(たとえば、回線切断を実装するなどして)、アプリケーション全体が中断されることはありません。 ユーザーまたはサービス コンシューマーにとっての利点は、アプリケーションの常時接続エクスペリエンスです。

スケーラビリティ

マイクロサービス アーキテクチャを使用すると、各マイクロサービスを他のマイクロサービスとは別にスケーリングできます。 アプリケーション全体をスケールアウトすることなく、より多くのリソースを必要とするサブシステムをスケールアウトできます。 この配置により、アプリケーションの全体的なパフォーマンスが向上します。 また、コストを最小限に抑えるのにも役立ちます。 アプリケーション全体をスケールアップするのではなく、必要なサービスにのみリソースを追加できます。

データの分離

マイクロサービス アーキテクチャでは、影響を受けるマイクロサービスが 1 つだけであるため、データ スキーマの更新を実行する機能が向上します。 モノリシック アプリケーションでは、スキーマの更新が困難になる可能性があります。 アプリケーションの異なる部分はすべて同じデータに触れる可能性があるため、スキーマの変更が危険になります。 マイクロサービス アーキテクチャを使用すると、スキーマを更新できますが、API サーフェスはそのまま維持できます。 サービス コンシューマーは、基になるデータ アーキテクチャに関係なく、同じエクスペリエンスを持ちます。

マイクロサービス アーキテクチャの潜在的な課題

マイクロサービス アーキテクチャには多くの利点がありますが、万能薬ではありません。 マイクロサービス アーキテクチャには、独自の一連の課題があります。

  • 複雑さ
  • 開発とテスト
  • ガバナンスの欠如
  • ネットワークの輻輳と待機時間
  • データ整合性
  • 管理
  • バージョン管理
  • 技能セット

複雑さ

マイクロサービス アプリケーションは、同等のモノリシック アプリケーションよりも多くの動的パーツで構成されています。 各サービスはより単純ですが、システム全体としてはより複雑です。 サービスの検出、オーケストレーション、自動化のツールを使用すると、アプリケーション全体で管理すべき要素が増える可能性があります。

開発とテスト

他の依存サービスに依存する小規模なサービスを作成するには、従来のモノリシック アプリケーションまたは階層型アプリケーションの記述とは異なるアプローチが必要です。 既存のツールは、サービスの依存関係を操作するように設計されているわけではありません。 サービス間の境界を越えたリファクタリングは、難しい場合があります。 また、特にアプリケーションが急速に進化している場合は、サービスの依存関係をテストすることも困難です。

ガバナンスの欠如

マイクロサービスを構築する際に分散アプローチをとることにはメリットがありますが、問題が発生しやすくもなります。 多くのさまざまな言語やフレームワークを使用するために、アプリケーションの維持が難しくなることがあります。 チームの柔軟性を過度に制限することなく、プロジェクト全体に標準を導入することが有益な場合があります。 統一された標準の必要性は、特に、ログ記録やメトリックなどの横断的な機能に適用されます。

ネットワークの輻輳と待機時間

多くの小さく細分化されたサービスを使用すると、よりインタラクティブな通信が可能になります。 サービスの依存関係のチェーンが長すぎる場合 (たとえば、サービス A が C...を呼び出す B を呼び出すなど)、これらのネットワーク呼び出しの余分な待機時間が問題になる可能性があります。 API を慎重に設計します。 過度におしゃべりな API を避け、シリアル化形式について考え、非同期通信パターンを使用する場所を探します。

データ整合性

各マイクロサービスは、独自のデータ永続化を担当します。 その結果、データの整合性が困難になる可能性があります。 可能であれば、最終的な整合性を優先します。 また、データが重複し、データ アーキテクチャが広がる場合もあります。 このような状況では、サービスとデータの重複によって生のストレージ コストとデータ プラットフォーム のサービス コストが増加する可能性があります。

管理

マイクロサービスで成功するには、成熟した DevOps カルチャが必要です。 サービス間で相互に関連付けられたログを記録することは難しい場合があります。 通常、ログ記録は単一のユーザー操作を要求するために複数のサービスの呼び出しを関連付ける必要があります。

バージョン管理

サービスの更新プログラムは、依存しているサービスを中断してはいけません。 任意の時点で複数のサービスを更新できます。 慎重に設計しないと、下位互換性または前方互換性に問題が発生する可能性があります。 新しい API バージョンの導入に遅れがあるサービスでは、古い API に必要なリソースとメンテナンスが増える可能性があります。

技能セット

マイクロサービスは高度な分散システムです。 多くの場合、これらの分散システムでは、適切に開発、管理、保守するために別のスキル セットが必要です。 成功のために必要なスキルと経験がチームにあるかどうかを慎重に評価してください。 チームが能力を進化させるために必要な時間と計画を考慮します。

マイクロサービス アーキテクチャを選択する必要があるタイミング

この背景情報に基づいて、マイクロサービス アーキテクチャが最も適している状況は何ですか?

  • 高いリリース速度を必要とする大規模なアプリケーション。
  • 高度にスケーラブルである必要がある複雑なアプリケーション。
  • リッチ ドメインまたは多くのサブドメインを持つアプリケーション。
  • 小規模な開発チームで構成される組織。