マイクロサービスとは

現在のアプリケーション開発と IT システム管理は、クラウドによって推進されています。 最新のクラウド アプリケーションは、高速かつアジャイルであり、非常にスケーラブルで信頼性が高い必要があります。

コンテナーを使用すると、これらの要件をすべて満たすアプリケーションをデプロイするのに役立ちます。 しかし、戦略的な設計パターンに従わずにアプリケーションをコンテナーに入れることは、車に乗り込み、地図や GPS を使わずに見知らぬ街に行く道を見つけるようなものです。 最終的には目的地に到着するかもしれませんが、そのルートは直接的なものでも、最も効率的でものでもないでしょう。

このようなシナリオでは、マイクロサービス アーキテクチャが役立ちます。 マイクロサービスを使用すると、最新のクラウド アプリケーションの機敏性、スケーラビリティ、信頼性の要件に完全に適したソフトウェアの開発とデプロイにアプローチできるようになります。

マイクロサービス アーキテクチャとは

マイクロサービス アーキテクチャでは、大規模なアプリケーションは小さなサービスのセットに分割されます。 各サービスは独自のプロセスで実行され、HTTP/HTTPS、WebSocket、Advanced Message Queuing Protocol (AMQP) などのプロトコルを使用して他のプロセスと通信します。 各マイクロサービスは、特定のコンテキスト境界内で特定のエンドツーエンドのドメインまたはビジネス機能を実装します。 個々のマイクロサービスは自律的に開発され、独立してデプロイ可能である必要があります。 最後に、各マイクロサービスは、関連するドメイン データ モデルとドメイン ロジックを所有する必要があります。 マイクロサービスは、さまざまなデータ ストレージ テクノロジ (SQL、NoSQL) とさまざまなプログラミング言語に基づくことができます。

マイクロサービスの主な特性のいくつかを以下に示します。

• これらは小さく、独立しており、疎結合されています。
• 各マイクロサービスには、小規模な開発チームで管理できる個別のコードベースがあります。
• これらは個別にデプロイされます。 チームは、アプリケーション全体を再ビルドしたり再デプロイしたりすることなく、既存のマイクロサービスを更新することができます。
• そのデータまたは外部状態は、それぞれのデータベースに保持されます。 モノリシック アーキテクチャの場合とは異なり、マイクロサービスではデータベースは共有されません。
• これらは、明確に定義された API を使用して相互に通信します。 各サービス内部の実装の詳細は、他のサービスに開示されません。
• これらは、ポリグロット プログラミングをサポートします。 たとえば、Web アプリケーションを構成するマイクロサービスは、同じテクノロジ スタック、ライブラリ、またはフレームワークを共有する必要はありません。

マイクロサービス アーキテクチャを使用して開発する理由

マイクロサービスは通常、よりシンプルな顧客要件の機能をカプセル化し、これをユーザーがスケールアウトまたはスケールインできます。 これらは個別にテスト、デプロイ、管理できます。 マイクロサービス アプローチの重要なベネフィットは、チームが特定のテクノロジを使用するよりも顧客のシナリオによって動かされることです。 小規模な開発チームがそれぞれ、顧客のシナリオに基づいてマイクロサービスを開発します。 チームは使用するテクノロジを選びます。

マイクロサービスによって長期的な機敏性が実現されます。 マイクロサービスは、それぞれが細かい自律的なライフサイクルを持つ、多数の独立して展開可能なサービスに基づいてアプリケーションを作成できるようにして、複雑かつ大規模で高度にスケーラブルなシステムの保守性をサポートします。

また、個別にスケールアウトできることもマイクロサービスのメリットです。 ユニットとしてスケールアウトする必要がある単一のモノリシック アプリケーションの代わりに、特定のマイクロサービスをスケールアウトできます。 スケーリングする必要のないアプリケーションの他の領域をスケールアウトするのではなく、需要をサポートするために処理能力またはネットワーク帯域幅を増やす必要がある機能領域のみをスケーリングできます。 つまり、必要なハードウェア数が少ないため、コストを削減できます。

このマイクロサービス アプローチを使用すると、複雑かつ大規模でスケーラブルなアプリケーションの特定の小さな領域を変更できるため、各マイクロサービスのアジャイルな変更と迅速な反復が可能になります。

細かいマイクロサービスベースのアプリケーションを設計することで、継続的な統合と継続的デリバリーの方法を実現できます。 また、短期間でアプリケーションに新しい関数を配信できるようになります。 マイクロサービスを分離して実行およびテストし、サービス間の明確なコントラクトを維持しながら自律的に進化させることができます。 インターフェイスまたはコントラクトを変更しない限り、任意のマイクロサービスの内部実装を変更することや、他のマイクロサービスを中断することなく新機能を追加することができます。

コンテナーの役割

コンテナリゼーションは、ソフトウェア開発のアプローチであり、アプリケーションまたはサービス、その依存関係、その構成 (展開マニフェスト ファイルとして抽象化) がコンテナー イメージとしてパッケージ化されます。 コンテナ化されたアプリケーションをユニットとしてテストし、ホスト オペレーティング システムにコンテナー イメージ インスタンスとしてデプロイできます。

ソフトウェア コンテナーは、さまざまなコードと依存関係を含むことができるソフトウェアの展開の標準ユニットとして機能します。 これは、出荷コンテナーが船、列車、またはトラックによってあらゆる種類の商品を輸送する方法に似ています。 開発者や IT プロフェッショナルは、コンテナ化されたソフトウェアを使用して、変更をほとんどまたはまったく行わず、異なる環境にコードと依存関係をデプロイできます。

アプリケーションのコンテナ化が、マイクロサービス アーキテクチャ パターンを実装するための優れた方法であるように思えたとしたら、それは正解です。 コンテナーを使用するベネフィットは、マイクロサービス アーキテクチャを使用するベネフィットとほぼ一致しています。

コンテナリゼーションのもう 1 つの利点はスケーラビリティです。 短期的なタスクに使用する新しいコンテナーを作成すると、すばやくスケールアウトできます。 アプリケーションの観点から、イメージのインスタンス化 (コンテナーの作成) は、サービスまたは Web アプリのようなプロセスのインスタンス化に似ています。

つまり、コンテナーには、アプリケーション ライフサイクル ワークフロー全体にわたり、分離、移植性、機敏性、スケーラビリティ、コントロールの利点があります。

このモジュールでビルドするマイクロサービスは、.NET CLI を使用して公開された Docker コンテナーで実行されます。

.NET SDK コンテナーの発行

.NET 7 では、dotnet publish コマンドを使用してコンテナー イメージを作成する機能が .NET SDK に追加されました。 このツールは、プロジェクトのプロパティとその出力に基づいて一連の推論を行います。 次に、.NET は、Dockerfile が作成するのと同じイメージを作成します。 新しいアプリケーションを作成してイメージとして発行するのに、わずか 2 つのコマンドで済む可能性があります。

dotnet new webapi
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

上記の .NET CLI コマンドは、新しい Web API を作成し、コンテナーとしてアプリを発行します。

• OS として LINUX をターゲットにする (--os linux)。
• x64 アーキテクチャを指定する (--arch x64)。
• リリース構成を使用する (-c リリース)。

生成されるコンテナーの多くの側面は、MSBuild プロパティによって制御できます。 一般に、 Dockerfile でコマンドを使用していくつかの構成を設定できる場合は、MSBuild を使用して同じ操作を行うことができます。

.NET でマイクロサービスをビルドする理由

.NET Core に始まり、現在のイテレーションに至るまで、.NET はクラウドネイティブ ファーストとして構築されています。 これはクロスプラットフォームで実行されるため、Docker イメージは Linux のフレーバーに基づいている可能性があり、.NET コードはその場合も実行されます。 Microsoft は Docker 用の .NET イメージを既に作成しています。 また、.NET は非常に高速です。 ASP.NET Kestrel Web サーバーは、常に他の Web サーバーよりも優れたパフォーマンスを発揮します。

Docker

Docker は、クラウドまたはオンプレミスで実行できる移植可能な自己十分なコンテナーとしてアプリケーションのデプロイを自動化するために使用できる オープンソース プラットフォーム です。 Docker は、このテクノロジを推進し、進化させている会社でもあります。 組織としての Docker は、クラウド、Linux、Windows のベンダー (Microsoft を含む) と協力関係を築いています。

Docker コンテナーは、オンプレミスの顧客のデータセンター内、外部サービス プロバイダー内、クラウド内など、どこでも実行できます。 Docker イメージ コンテナーは、Linux と Windows 上でネイティブに実行できます。

イメージとは

開発者が Docker を使用するときは、開発者はアプリまたはサービスを作成します。 次に、アプリまたはサービスとその依存関係をコンテナー イメージにパッケージ化します。 イメージとは、アプリケーションまたはサービスと、その構成と依存関係の静的な表現です。

そのイメージは、実行されると、コンテナーになります。 コンテナーは、イメージのメモリ内インスタンスです。

コンテナー イメージは変更できません。 イメージを作成した後は、そのイメージを変更することはできません。 イメージを変更できないため、アプリまたはサービスとその依存関係を変更する必要がある場合は、新しいイメージを作成します。 この機能により、運用環境で使用するイメージが、開発およびテストで使用されるイメージと同じであることが保証されます。

Dockerfile とは

Dockerfile は、Docker イメージをビルドする方法の手順が含まれるテキスト ファイルです。 Dockerfile は、イメージの構築と構成用に設計された最小限のスクリプト言語で記述されます。 Dockerfile には、基本イメージから始まるイメージの構築に必要な操作も文書化されています。

アプリケーションを含む Docker イメージを作成するには、通常、基本イメージを識別することから始めます。 次に、基本イメージにファイルと構成をさらに追加します。 適切な基本イメージを特定するプロセスは、通常、Docker Hub 上で検索することから始めます。 既にアプリケーション フレームワークと、Ubuntu や Alpine などの Linux ディストリビューションのすべてのユーティリティとツールが含まれている既製のイメージを検索します。 たとえば、コンテナーにパッケージ化する ASP.NET アプリケーションがある場合、Microsoft は、ASP.NET ランタイムを既に含む mcr.microsoft.com/dotnet/aspnet という名前のイメージを発行します。

基本イメージでコンテナーを起動し、変更を加えて、イメージをカスタマイズできます。 変更には通常、ローカル ファイルシステムからコンテナーへのファイルのコピーや、コードをコンパイルするためのさまざまなツールとユーティリティの実行などのアクティビティが含まれます。

Dockerfile は、アプリケーションを実行するために必要な (アプリケーション自体を含む) 正確なソフトウェアが含まれた Docker イメージを作成する命令のセットです。