次の方法で共有


マイクロサービス アーキテクチャの設計

マイクロサービスは、回復性を維持し、効率的にスケーリングし、独立してデプロイし、急速に進化するクラウド アプリケーションを構築するための一般的なアーキテクチャ スタイルです。 実際の価値を実現するには、マイクロサービスの設計とアプリケーション開発に別のアプローチが必要です。

この一連の記事では、Azure でマイクロサービス アーキテクチャを構築する方法について説明します。 これには、次のガイダンスが含まれています。

  • マイクロサービスのコンピューティング オプション: Azure Kubernetes Service (AKS)、Azure Container Apps、Azure Functions など、マイクロサービスの Azure コンピューティング サービスを評価します。 スケーラビリティ、管理オーバーヘッド、デプロイ モデルの要件に基づいて、各サービスを使用するタイミングについて説明します。

  • サービス間通信: 同期と非同期のアプローチを使用して、マイクロサービス間の効果的な通信パターンを設計します。 信頼性の高いサービス間通信のための REST API、メッセージング パターン、イベントドリブン アーキテクチャ、サービス メッシュ テクノロジについて説明します。

  • API 設計: マイクロサービス アーキテクチャの原則をサポートする適切に設計された API を作成します。 API のバージョン管理戦略、エラー処理パターン、疎結合と独立したサービスの進化を促進する API を設計する方法について説明します。

  • API ゲートウェイ: API ゲートウェイを実装して、認証、レート制限、要求ルーティングなどの横断的な問題を管理します。 ゲートウェイがクライアントの対話を簡素化し、マイクロサービス エコシステム全体で一元的なポリシー適用を提供する方法について説明します。

  • データに関する考慮事項: データ整合性パターン、分散トランザクション、適切なデータ ストアの選択など、マイクロサービス アーキテクチャにおけるデータ管理の課題に対処します。 サービスの境界を越えてデータ整合性を維持するための戦略について説明します。

  • コンテナー オーケストレーション: コンテナー オーケストレーターを使用して、コンテナー化されたマイクロサービスを大規模にデプロイおよび管理します。 Kubernetes などのプラットフォームで、運用環境で目的のシステム状態を維持するために、デプロイ、スケーリング、負荷分散、正常性管理を自動化する方法について説明します。

  • 設計パターン: 接続タスクをオフロードするためのアンバサダー パターン、リソース分離のバルクヘッド パターン、増分アプリケーション リファクタリング用の Strangler Fig パターンなど、マイクロサービスに固有の実証済みの設計パターンを適用します。

[前提条件]

これらの記事を読む前に、次のリソースから始めます。

アーキテクチャの例

ドローン配送ワークロードのアーキテクチャを示す図。

この図は、AKS 内で動作する高度なシステム アーキテクチャを示しています。 レイアウトは左から右に流れます。 これは、AKS 境界の外側に配置された Client というラベルの付いたコンポーネントから始まります。 クライアントは、AKS 環境内にあるインジェスト サービスにデータを送信します。 方向矢印は、最初のデータ転送を示すインジェスト サービスにクライアントを接続します。 その後、インジェスト サービスはデータを Service Bus に転送します。 Service Bus から、データはワークフロー サービスに移動します。 ワークフロー サービスは、3 つの特殊なサービスのいずれかにタスクを送信します。 これらのサービスには、配信サービス、ドローン スケジューラ サービス、パッケージ サービスが含まれます。 これらの各サービスは、個別のアイコンにつながる矢印で表される、独自の外部システムまたはストレージ ソリューションに接続されています。 配信サービスとドローン スケジューラ サービスは両方ともデータをストレージまたはデータベース コンポーネントにルーティングし、パッケージ サービスはクラウドまたは外部システムに接続します。 クライアントを除くすべてのコンポーネントは、AKS というラベルが付いた点線の境界内に囲まれています。これは、それらがその環境内で管理されていることを示します。

このアーキテクチャの Visio ファイル をダウンロードします。

Scenario

Fabrikam, Inc. はドローン配送サービスを作成します。 同社はドローン航空機の艦隊を管理しています。 企業がサービスに登録すると、ユーザーは、ドローンで商品を集荷して配送するように依頼できます。 顧客が集荷をスケジュールすると、バックエンド システムによってドローンが割り当てられ、推定配送時間がユーザーに通知されます。 配送中、顧客は継続的に更新された推定到着時間 (ETA) を含め、ドローンの場所を追跡できます。

このソリューションは、航空宇宙および航空機産業に適しています。

このシナリオには、かなり複雑なドメインが含まれます。 ビジネス上の懸念事項としては、ドローンのスケジュール設定、パッケージの追跡、ユーザー アカウントの管理、履歴データの格納と分析などがあります。 Fabrikam は、まず市場に参入し、その後、迅速に繰り返し新しい機能を追加したいと考えています。 アプリケーションは、高いサービス レベル目標 (SLO) を使用してクラウド規模で動作する必要があります。 Fabrikam では、システムのさまざまな部分に、データ ストレージとクエリに関する要件が非常に異なることも想定されています。 Fabrikam は、考慮事項に基づいて、ドローン配送アプリケーションのマイクロサービス アーキテクチャを選択します。

マイクロサービス アーキテクチャとその他のアーキテクチャ スタイルを選択する方法の詳細については、 Azure アプリケーション アーキテクチャ ガイドを参照してください。

このアーキテクチャでは、 AKS で Kubernetes を使用します。 ただし、アーキテクチャに関する大まかな決定事項と課題の多くは、コンテナー オーケストレーターに適用されます。

次のステップ