Webアプリケーションのためのマイクロサービスアーキテクチャ

マイクロサービス：アプリケーションを独立したサービスとして構築する

従来のWebアプリケーションは単一のユニット、つまりモノリスとして構築されます。ユーザー、製品、注文、支払いを処理するすべてのコードが1つのコードベースに存在し、1つのアプリケーションとしてデプロイされます。マイクロサービスは異なるアプローチを取ります。各ビジネス機能は、独自のコードベース、データベース、デプロイサイクルを持つ独立したサービスになります。

分割することの利点

マイクロサービスの主な利点は独立性です。チームは互いに干渉することなく、異なるサービスで同時に作業できます。各サービスは独立してデプロイできるため、支払いサービスへの変更でアプリケーション全体を再デプロイする必要はありません。サービスは独立してスケーリングできます。製品カタログがユーザーアカウントよりも多くのトラフィックを受ける場合、カタログサービスのみをスケーリングします。

マイクロサービスを使用すると、異なるジョブに異なるテクノロジーを使用することもできます。製品カタログはNode.jsとMongoDBで最適に動作するかもしれませんが、支払いサービスはトランザクション保証のためにJavaを必要とします。また、1つのサービスがクラッシュしても、他のサービスは実行を継続でき、障害の影響範囲を制限できます。

課題

マイクロサービスは大きな複雑さをもたらします。単一のデータベースクエリの代わりに、ページを組み立てるために複数のサービスに対して複数のネットワーク呼び出しを行う必要があるかもしれません。ネットワークレイテンシが要因になります。サービス間でのデータ一貫性の確保は、モノリシックデータベースよりも困難です。複数のサービスにまたがる問題のデバッグには、分散トレーシングが必要です。

サービス間通信は慎重な設計が必要です。同期呼び出し（HTTP/gRPC）はシンプルですが、カスケード障害を引き起こす可能性があります。非同期メッセージング（メッセージキューやイベントバス経由）はサービスを疎結合にしますが、複雑さが増します。サービスが互いを見つけられるようにサービスディスカバリが必要です。クライアントに単一のエントリポイントを提供するためにAPIゲートウェイが必要です。また、障害の拡散を防ぐためにサーキットブレーカーが必要です。

マイクロサービスが適している場合

マイクロサービスはすべてのプロジェクトに適した選択肢ではありません。シンプルなアプリケーションを構築する小規模チームにとっては、モノリスの方が開発が速く、管理が容易です。マイクロサービスは、複数のチームがそれぞれ異なるビジネスドメインを所有し、システムの異なる部分に異なるスケーリング要件がある場合に価値が発揮されます。

多くの成功したチームは、適切に構造化されたモノリスから始め、必要に応じてサービスを分割します。ドメイン境界を理解する前にアプリケーションを分割する時期尚早なマイクロサービスは、多くの場合、最初のモノリスよりも管理が難しい分散の混乱を招きます。

主要なパターン

マイクロサービスを採用する場合、複雑さを管理するのに役立ついくつかのパターンがあります。APIゲートウェイパターンは、クライアントに単一のエントリポイントを提供し、リクエストを適切なサービスにルーティングします。Sagaパターンは、一連のローカルトランザクションを調整することで分散トランザクションを管理します。CQRSパターンは読み取り操作と書き込み操作を分離します。そして、イベントソーシングパターンは変更を一連のイベントとして保存し、完全な監査証跡を提供します。