従来のモノリシック アプリケーションは、単一の統合されたユニットとして構築されます。すべてのコンポーネントは密結合され、リソースとデータを共有しています。特にアプリケーションの複雑さが増すにつれて、スケーリング、デプロイ、メンテナンスに問題が生じる可能性があります。一方、マイクロサービス アーキテクチャでは、アプリケーションが小規模な独立したサービス スイートに分割されます。各マイクロサービスは、独自のコード、データ、依存関係を持つ自己完結型です。この方法には以下のような潜在的メリットがあります。

• スケーラビリティの向上: 個々のマイクロサービスは、固有のニーズに応じて個別にスケールできます
• 復元力の向上: 1 つのマイクロサービスに障害が発生しても、必ずしもアプリケーション全体に影響が及ぶわけではありません
• クラウド費用の最適化: 従来のマイクロサービスでは、インフラストラクチャが複雑になり、隠れた費用が発生する可能性があります。組織では多くの場合、クラウド費用の可視性を高め、個々のサービスが予算を超過することなく効率的にスケーリングされるようにするために、マイクロサービスと並行して FinOps アプローチを採用しています。

• e コマース: プラットフォームはマイクロサービスを使用して、商品カタログ、ショッピング カート、注文処理を個別に管理
• ストリーミング サービス: マイクロサービスが動画エンコード、コンテンツ配信、レコメンデーション エンジンを処理し、数百万人のユーザーに同時にサービスを提供
• 金融サービス: 金融機関は、不正行為の検出や支払い処理にマイクロサービスを使用し、市場の変化やセキュリティ要件に迅速に対応

分散システムの複雑さを管理し、パフォーマンスを最適化するために、現在ではアーキテクトはさまざまなコア設計パターンを利用しています。

数十もの独立したサービスにわたって単一のリクエストを追跡するのは複雑になるため、オブザーバビリティはマイクロサービスにとって不可欠です。最新のチームは、指標、ログ、トレースを組み合わせて使用し、システムの健全性を把握しています。Gemini Cloud Assist などの AI を活用したツールを活用して、分散アプリケーションの異常を自動的に特定し、コンテキストに応じたトラブルシューティングを提供することで、オブザーバビリティをさらに強化できます。

分散マイクロサービス環境では、ネットワーク障害によってリクエストが再試行されることがあります。べき等性は、設計の基本原則です。べき等性により、オペレーションを複数回実行しても、初回実行時と同じ結果が得られることが保証されます。これは、決済処理、注文管理、イベント ドリブン システムにおいてデータの整合性を維持するために不可欠です。

最新のアーキテクチャでは、イベントを使用した非同期通信がますます好まれるようになっています。EDA では、サービスがイベント（状態の変化）をメッセージ ブローカーにパブリッシュし、他のサービスがこれらのイベントをサブスクライブします。これにより、疎結合が促進され、障害の分離が改善されます。