.NET マイクロサービス アーキテクチャの重要なポイント

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

PDF をダウンロードする

概要と重要なポイントとして、このガイドの最も重要な結論を次に示します。

コンテナーを使用する利点。 コンテナー ベースのソリューションは、運用環境での依存関係の失敗によって発生するデプロイの問題を減らすのに役立つため、重要なコスト削減を実現します。 コンテナーにより、DevOps と運用操作が大幅に向上します。

コンテナーはユビキタスになります。 Docker ベースのコンテナーは、Microsoft、Amazon AWS、Google、IBM などの Windows および Linux エコシステムの主要ベンダーによってサポートされる、業界の事実上の標準になりつつあります。 Docker は、クラウドとオンプレミスの両方のデータセンターで間もなく普及する可能性があります。

デプロイの単位としてのコンテナー。 Docker コンテナーは、サーバー ベースのアプリケーションまたはサービスの標準的なデプロイユニットになりつつあります。

マイクロサービス。 マイクロサービス アーキテクチャは、自律的なサービスの形式で多数の独立したサブシステムに基づいて、分散および大規模または複雑なミッション クリティカルなアプリケーションに推奨されるアプローチになりつつあります。 マイクロサービス ベースのアーキテクチャでは、アプリケーションは、個別に開発、テスト、バージョン管理、デプロイ、スケーリングされるサービスのコレクションとして構築されます。 各サービスには、関連する自律データベースを含めることができます。

ドメイン駆動型の設計と SOA。 マイクロサービス アーキテクチャ パターンは、サービス指向アーキテクチャ (SOA) とドメイン駆動設計 (DDD) から派生します。 ビジネス ニーズとルールが進化する環境向けにマイクロサービスを設計および開発する場合は、DDD のアプローチとパターンを検討することが重要です。

マイクロサービスの課題。 マイクロサービスは、独立したデプロイ、強力なサブシステム境界、テクノロジの多様性など、多くの強力な機能を提供します。 ただし、断片化された独立したデータ モデル、マイクロサービス間の回復性のある通信、最終的な整合性、複数のマイクロサービスからのログ情報と監視情報の集計による運用の複雑さなど、分散アプリケーション開発に関連する多くの新しい課題も発生します。 これらの側面では、従来のモノリシック アプリケーションよりもはるかに複雑なレベルが導入されます。 その結果、マイクロサービス ベースのアプリケーションには特定のシナリオのみが適しています。 これには、複数の進化するサブシステムを持つ大規模で複雑なアプリケーションが含まれます。 このような場合は、長期的な機敏性とアプリケーションのメンテナンスが向上するため、より複雑なソフトウェア アーキテクチャに投資する価値があります。

任意のアプリケーションのコンテナー。 コンテナーはマイクロサービスに便利ですが、Windows コンテナーを使用する場合は、従来の .NET Framework に基づくモノリシック アプリケーションにも役立ちます。 Docker を使用する利点 (多くのデプロイから運用環境への問題の解決、最新の開発およびテスト環境の提供など) は、さまざまな種類のアプリケーションに適用されます。

CLI と IDE。 Microsoft ツールを使用すると、好みのアプローチを使用して、コンテナー化された .NET アプリケーションを開発できます。 Docker CLI と Visual Studio Code を使用して、CLI とエディター ベースの環境を使用して開発できます。 または、Visual Studio とその Docker 固有の機能 (マルチコンテナー デバッグなど) を使用して、IDE に重点を置いたアプローチを使用することもできます。

回復力のあるクラウド アプリケーション。 クラウドベースのシステムと分散システム全般では、常に部分的な障害のリスクがあります。 クライアントとサービスは個別のプロセス (コンテナー) であるため、サービスはクライアントの要求にタイムリーに応答できない場合があります。 たとえば、部分的な障害やメンテナンスのためにサービスが停止している可能性があります。サービスがオーバーロードされ、要求に対して応答が遅くなる可能性があります。または、ネットワークの問題のために短時間アクセスできない可能性があります。 そのため、クラウドベースのアプリケーションでは、これらの障害を受け入れ、それらの障害に対応するための戦略を用意する必要があります。 これらの戦略には、再試行ポリシー (メッセージの再送信または要求の再試行) や、繰り返される要求の指数関数的な負荷を回避するためのサーキット ブレーカー パターンの実装が含まれます。 基本的に、クラウドベースのアプリケーションには、クラウドインフラストラクチャまたはカスタムソリューションに基づいた回復力のあるメカニズム、またはオーケストレーターやサービスバスによって提供される高レベルなメカニズムが必要です。

セキュリティ。 コンテナーとマイクロサービスの最新の世界では、新しい脆弱性が公開される可能性があります。 認証と承認に基づいて、基本的なアプリケーション セキュリティを実装する方法はいくつかあります。 ただし、コンテナーのセキュリティでは、本質的に安全なアプリケーションをもたらす追加の重要なコンポーネントを考慮する必要があります。 より安全なアプリを構築する重要な要素は、他のアプリやシステムと安全に通信する方法を持つことです。多くの場合、資格情報、トークン、パスワードなどを必要とします。これは、一般的にアプリケーション シークレットと呼ばれます。 セキュリティで保護されたソリューションでは、転送中や保存中にシークレットを暗号化したり、最終的なアプリケーションで使用されたときにシークレットが漏洩するのを防いだりするなど、セキュリティのベスト プラクティスに従う必要があります。 これらのシークレットは、Azure Key Vault を使用する場合と同様に、安全に保存して保持する必要があります。

オーケストレーター。 Azure Kubernetes Service や Azure Service Fabric などのコンテナー ベースのオーケストレーターは、重要なマイクロサービスおよびコンテナー ベースのアプリケーションの重要な部分です。 これらのアプリケーションは、高い複雑さ、スケーラビリティのニーズを伴い、絶えず進化しています。 このガイドでは、マイクロサービス ベースおよびコンテナー ベースのソリューションにおけるオーケストレーターとその役割について説明しました。 アプリケーションのニーズが複雑なコンテナー化されたアプリに移行している場合は、オーケストレーターの詳細を学習するための追加のリソースを探すと便利です。

前の