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

  • 10 分

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

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

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

Logical diagram of a monolithic architecture.

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

すべてのサービスが 1 つのユニットに含まれています。 この配置により、ビジネスが拡大し、それに伴いシステム負荷が増大するにつれて、課題が発生します。 たとえば、次のような課題があります。

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

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

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

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

Logical diagram of a microservices architecture.

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

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

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

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

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

マイクロサービス アーキテクチャを選択するのには、どのような理由があるのでしょうか。 マイクロサービス アーキテクチャには、主に次のような利点があります。

  • 機敏性
  • 短いコード、小規模チーム
  • テクノロジの組み合わせ
  • 回復性
  • スケーラビリティ
  • データの分離

機敏性

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

短いコード、小規模チーム

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

小規模なチーム編成は機敏性も向上させます。 "2 枚のピザ ルール" も、チームは 2 枚のピザが行き渡る人数に抑える必要がある、となっています。 これは正確な基準ではなく、チームの食欲によって変わることは言うまでもありません。 しかし、重要なのは、大規模なグループでは、コミュニケーションに時間がかかり、管理オーバーヘッドが増大し、機敏性も低下するため、生産性が低くなる傾向があるという点です。

テクノロジの組み合わせ

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

回復性

個々のマイクロサービスが使用できなくなっても、上流のマイクロサービスが障害を正しく処理するように設計されている限り (サーキット ブレークの実装など)、アプリケーション全体が動かなくなることはありません。 ユーザーまたはサービス コンシューマーにとってのベネフィットは、アプリケーションでの Always On エクスペリエンスです。

スケーラビリティ

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

データの分離

マイクロサービス アーキテクチャでは、影響を受けるマイクロサービスが 1 つのみであるため、データ スキーマの更新を実行する能力が向上します。 モノリシック アプリケーションでは、スキーマの更新が困難になることがあります。 アプリケーションのさまざまな部分で同じデータがタッチされる可能性があり、スキーマの変更にはリスクが伴います。 マイクロサービス アーキテクチャを使用すると、スキーマを更新しながらも、API サーフェスの状態を変えずに維持することができます。 サービス コンシューマーは、基になるデータ アーキテクチャに関係なく、同じエクスペリエンスを得られます。

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

マイクロサービス アーキテクチャには、多くの利点がありますが、それですべてが解決するわけではありません。 マイクロサービス アーキテクチャには、一連の独自の課題があります。

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

複雑さ

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

開発とテスト

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

ガバナンスの欠如

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

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

小さく細分化されたサービスを数多く使用すると、サービス間の通信が増える可能性があります。 サービス A が B を呼び出し、B が C を呼び出すといったように、サービスの依存関係のチェーンが非常に長くなると、これらのネットワーク呼び出しによる余分な待ち時間が、問題になる可能性があります。 API を慎重に設計します。 過剰な呼び出しが必要な API は避け、シリアル化形式について検討し、非同期通信パターンを使用する場所を探してください。

データ整合性

マイクロサービスごとに、独自のデータの永続化が行われます。 結果として、データの整合性が難しくなることがあります。 可能であれば、最終的な整合性を優先します。 また、データが重複し、データ アーキテクチャが無秩序に広がることもあります。 この状況では、サービスとデータの重複により、未処理のストレージ コストとデータ プラットフォーム サービスのコストが増加する可能性があります。

管理

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

バージョン管理

サービスの更新プログラムによって、その依存元のサービスが中断されてはいけません。 複数のサービスが、任意の時間に更新されることがあります。 慎重な設計を怠ると、下位互換性または上位互換性に問題が生じる可能性があります。 新しい API バージョンの採用が遅れたサービスで、以前の API に必要なリソースやメンテナンスが増えることがあります。

スキル セット

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

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

この背景情報に基づくと、マイクロサービス アーキテクチャが最適な状況には、どのようなものがあるでしょうか?

  • リリースの早さが要求される大規模なアプリケーション。
  • 高い拡張性が求められる複雑なアプリケーション。
  • 豊富なドメインまたは多数のサブドメインを持つアプリケーション。
  • 小規模な開発チームで構成される組織。