【10分でわかる💻💻💻】マイクロサービスアーキテクチャ〜ざっくり概要だけ〜
どうも、ちゃんなるです🐻
職場でここ数年、巨大なモノリシックアプリケーションのマイクロサービス化が進められています。
ですが私はその作業に関わってなく、マイクロサービスの知識があまりありません…。
なので、今回「マイクロサービスアーキテクチャ」をざっくりと紹介します🖐️
マイクロサービスアーキテクチャの概要
マイクロサービスアーキテクチャは、アプリケーションを小さな独立したサービスに分割するアプリケーションアーキテクチャのひとつです。
アプリケーションの柔軟性・拡張性・保守性の向上が目的です。
各サービスは、独自のプロセスとデータストアを持ち、APIを介して相互通信します📡 また、サービスが独立しているため個別に開発・デプロイ・スケーリング・保守することができます👏
マイクロサービスアーキテクチャの基本概念と設計原則
対比されるアーキテクチャ「モノリシックアーキテクチャ」
大きな単一機能を持ち、単一の塊で構成されているため、システムやソフトウェアが1つのモジュールでできており、分割されていない設計のことを指します。
メリットは、システム全体が1つのモジュールで構成されているため、システム全体を把握しやすく、開発や運用が比較的簡単であることです。また、あらゆるサポートを一元的に提供できるため、問題が発生した場合に対処しやすい場合もあります。
デメリットは、システムの一部を変更する際、全体を修正・テストする必要が生じることで、システムの規模が大きくなるほど開発速度の低下が問題として取り挙げられます。
単一責任原則
各マイクロサービスは、1つの責任のみを持つように設計する必要があります。
これにより、サービスが容易に理解、開発、テスト、デプロイメントされることが可能になります。
※下記がわかりやすいと感じました
ドメイン駆動設計
ドメイン駆動開発（DDD）は、ユーザーが従事する業務に合わせてソフトウェアを開発する手法であり、ユーザーの業務知識をコードに反映させることができます。*1
このDDDは、マイクロサービスの境界を明確に定義するのに役立ちます。
障壁の高いコンポーネント設計
マイクロサービスは、内部実装の詳細をサービス自身の外側に対して隠蔽し、明確に定義されたインターフェース（例えばHTTP API）を通じてのみ他のサービスと通信するという点が非常に重要です。
これにより、各サービスが独立して進化し、互いに影響を与えずに変更できます。
RESTful APIとの関連性
マイクロサービス間の通信には、通常RESTful APIが使用されます。
RESTful APIは、HTTPプロトコルを使用してリソースにアクセスする方法であり、マイクロサービス間の連携をHTTP通信で行うことが一般的です。
※RESTful APIについての詳細は省略します。RESTful APIの満たすべき条件は下記サイトを見てみて下さい。
マイクロサービスアーキテクチャのメリットとデメリット
メリット：スケーラビリティと柔軟性の向上
各サービスは独立してデプロイおよびスケールできるため、システム全体のパフォーマンスと可用性が向上します。
メリット：独立したチームでの開発
各サービスが独立して開発およびデプロイされるため、サービスとチームを一意に結びつけることでフルサイクル開発化*2に繋がり、自律的な開発チームが築ける可能性があります。
これにより、開発サイクルが短縮され、より迅速に機能を市場に投入することができます。
デメリット：複雑さの増加と運用コスト
マイクロサービスアーキテクチャのデメリットは、システムの複雑さが増加し、運用コストが高くなることです。
サービス間の通信、データ管理、セキュリティ、および監視など、多くの側面で追加の調整が必要となります。 ただし、適切なツールとプロセスを用いて運用管理を行うことで、これらの課題を軽減することが可能です。
まとめ
マイクロサービスアーキテクチャは、スケーラビリティ、柔軟性、および独立したチームでの開発を促進する一方で、複雑さや運用コストが増加することが挙げられます。
適切な設計原則、実装手法、および運用管理を用いることで、マイクロサービスアーキテクチャを効果的に活用し、ビジネスの成長を促進することができます。
