次の方法で共有

ASP.NET Core Web アプリの Azure ホスティングに関する推奨事項

ヒント

このコンテンツは、ASP.NET Core と Azure を使用した最新の Web アプリケーションの設計に関する電子ブックからの抜粋です。 .NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できます。

PDF をダウンロードする

ASP.NET Core と Azure eBook の表紙サムネイルを使用して最新の Web アプリケーションを設計します。

「基幹業務リーダーは、IT 部門をバイパスしてクラウドからアプリケーションを取得し (SaaS とも呼ばれます)、雑誌のサブスクリプションと同様に料金を支払っています。 また、サービスが不要になったら、隅に未使用の機器を残さないままサブスクリプションを取り消すことができます。
- Daryl Plummer、Gartner アナリスト

アプリケーションのニーズとアーキテクチャに関係なく、Microsoft Azure でサポートできます。 ホスティングのニーズは、静的な Web サイトや、数十のサービスで構成される高度なアプリケーションと同じくらい簡単です。 ASP.NET Core モノリシック Web アプリケーションとサポート サービスには、いくつかのよく知られた構成が推奨されます。 この記事に関する推奨事項は、完全なアプリケーション、個々のプロセス、またはデータのいずれであっても、ホストされるリソースの種類に基づいてグループ化されます。

Web アプリケーション

Web アプリケーションは、次の方法でホストできます。

  • アプリサービスウェブアプリ

  • コンテナー (いくつかのオプション)

  • 仮想マシン (VM)

これらの中で、App Service Web Apps は、単純なコンテナー ベースのアプリなど、ほとんどのシナリオで推奨されるアプローチです。 マイクロサービス アーキテクチャの場合は、コンテナーベースのアプローチを検討してください。 アプリケーションを実行しているマシンをより詳細に制御する必要がある場合は、Azure Virtual Machines を検討してください。

アプリサービスウェブアプリ

App Service Web Apps は、Web アプリケーションをホストするために最適化されたフル マネージド プラットフォームを提供します。 これは、ビジネス ロジックに集中できるサービスとしてのプラットフォーム (PaaS) オファリングですが、アプリの実行とスケーリングに必要なインフラストラクチャは Azure によって処理されます。 App Service Web Apps の主な機能:

  • DevOps の最適化 (継続的インテグレーションと配信、複数の環境、A/B テスト、スクリプトのサポート)。

  • グローバルスケールと高可用性。

  • SaaS プラットフォームとオンプレミス データへの接続。

  • セキュリティとコンプライアンス

  • Visual Studio の統合。

Azure App Service は、ほとんどの Web アプリに最適な選択肢です。 デプロイと管理はプラットフォームに統合され、サイトはトラフィックの負荷が高い場合に迅速にスケーリングでき、組み込みの負荷分散とトラフィック マネージャーによって高可用性が提供されます。 オンライン移行ツールを使用すると、既存のサイトを Azure App Service に簡単に移動できます。 Web アプリケーション ギャラリーからオープンソース アプリを使用することも、任意のフレームワークとツールを使用して新しいサイトを作成することもできます。 WebJobs 機能を使用すると、バックグラウンド ジョブ処理を App Service Web アプリに簡単に追加できます。 ローカル データベースを使用してオンプレミスでホストされている既存の ASP.NET アプリケーションがある場合は、移行する明確なパスがあります。 App Service Web App は、Azure SQL Database と共に使用できます (または、必要に応じて、オンプレミスのデータベース サーバーへのセキュリティで保護されたアクセス)。

オンプレミスの .NET アプリから Azure App Service への推奨される移行戦略

ほとんどの場合、ローカルでホストされている ASP.NET アプリから App Service Web アプリへの移行は簡単なプロセスです。 アプリ自体をほとんどまたはまったく変更する必要はなく、Azure App Service Web Apps が提供する多くの機能をすぐに利用できます。

クラウド用に最適化されていないアプリに加えて、Azure App Service Web Apps は、多くの ASP.NET Core アプリなど、多くの単純なモノリシック (非分散) アプリケーションに最適なソリューションです。 このアプローチでは、アーキテクチャは基本的で、理解と管理が簡単です。

基本的な Azure アーキテクチャ

通常、このようなアプリを管理するには、1 つのリソース グループ内の少数のリソースで十分です。 多くの個別のプロセスで構成されるアプリではなく、通常は 1 つのユニットとして展開されるアプリは、この 基本的なアーキテクチャ アプローチの候補として適しています。 アーキテクチャ的には単純ですが、このアプローチでは引き続き、ホストされているアプリをスケールアップ (ノードあたりのリソースの増加) とスケールアウト (より多くのホストされたノード) の両方でスケールアップして、需要の増加に対応できます。 自動スケーリングを使用すると、需要とノード間の平均負荷に基づいてアプリをホストするノードの数を自動的に調整するようにアプリを構成できます。

コンテナ向けの App Service Web アプリ

Web アプリを直接ホストするためのサポートに加えて、 App Service Web Apps for Containers を使用して、Windows および Linux 上でコンテナー化されたアプリケーションを実行できます。 このサービスを使用すると、ビジネスに合わせてスケーリングできるコンテナー化されたアプリケーションを簡単にデプロイして実行できます。 アプリには、上記の App Service Web Apps のすべての機能があります。 さらに、Web Apps for Containers では、Docker Hub、Azure Container Registry、GitHub を使用した合理化された CI/CD がサポートされています。 Azure DevOps を使用して、レジストリに変更を発行するビルドパイプラインとデプロイ パイプラインを定義できます。 その後、これらの変更をステージング環境でテストし、デプロイ スロットを使用して運用環境に自動的にデプロイできるため、ダウンタイムなしのアップグレードが可能になります。 以前のバージョンへのロールバックは、同じように簡単に行うことができます。

Web Apps for Containers が最も理にかなっているシナリオがいくつかあります。 コンテナー化できる既存のアプリがある場合は、Windows コンテナーでも Linux コンテナーでも、このツールセットを使用して簡単にホストできます。 まずコンテナーを発行し、選択したレジストリからそのイメージの最新バージョンをプルするようにWeb Apps for Containersを構成します。 これは、従来のアプリ ホスティング モデルからクラウド最適化モデルに移行するための "リフト アンド シフト" アプローチです。

コンテナー化されたオンプレミスの .NET アプリケーションを Azure Web Apps for Containers に移行する

この方法は、開発チームがコンテナー ベースの開発プロセスに移行できる場合にも適しています。 コンテナーを使用してアプリを開発する "内部ループ" には、コンテナーを使用したアプリのビルドが含まれます。 コードとコンテナー構成に加えられた変更はソース管理にプッシュされ、自動化されたビルドは Docker Hub や Azure Container Registry などのレジストリに新しいコンテナー イメージを発行する役割を担います。 これらのイメージは、次の図に示すように、追加の開発および運用環境へのデプロイの基礎として使用されます。

エンド ツー エンドの Docker DevOps ライフサイクル ワークフロー

コンテナーを使用した開発には、特に運用環境でコンテナーを使用する場合に、多くの利点があります。 同じコンテナー構成を使用して、ローカル開発マシンからシステムのビルドとテスト、運用まで、アプリを実行する各環境でアプリをホストします。 この方法により、マシンの構成またはソフトウェアのバージョンの違いに起因する欠陥の可能性が大幅に低下します。 コンテナーは任意の OS で実行できるため、開発者はオペレーティング システムを含め、最も生産性の高いツールを使用することもできます。 場合によっては、多くのコンテナーを含む分散アプリケーションが、1 台の開発マシンで実行するために非常に多くのリソースを消費する場合があります。 このシナリオでは、次のセクションで説明する Kubernetes と Azure Dev Spaces の使用にアップグレードすることが理にかなっている場合があります。

大規模なアプリケーションの一部が独自の小さな独立した マイクロサービスに分割されるため、追加の設計パターンを使用してアプリの動作を改善できます。 API ゲートウェイは、個々のサービスを直接操作する代わりに、アクセスを簡素化し、クライアントをバックエンドから切り離すことができます。 異なるフロントエンドに個別のサービス バックエンドを用意することで、サービスをコンシューマーと連携して進化させることもできます。 共通サービスには別の サイドカー コンテナーを介してアクセスできます。これには、 アンバサダー パターンを使用した一般的なクライアント接続ライブラリが含まれる場合があります。

いくつかの一般的な設計パターンが示されたマイクロサービス サンプル アーキテクチャ。

マイクロサービス ベースのシステムを構築するときに考慮する設計パターンの詳細について説明します。

Azure Kubernetes サービス

Azure Kubernetes Service (AKS) は、ホストされている Kubernetes 環境を管理するため、コンテナー オーケストレーションの専門知識がなくても、コンテナー化されたアプリケーションを迅速かつ簡単にデプロイおよび管理できます。 また、アプリケーションをオフラインにすることなく、オンデマンドでリソースをプロビジョニング、アップグレード、スケーリングすることで、継続的な運用とメンテナンスの負担をなくします。

AKS は、その責任の多くを Azure にオフロードすることで、Kubernetes クラスターを管理する複雑さと運用上のオーバーヘッドを軽減します。 Azure は、ホストされている Kubernetes サービスとして、正常性の監視やメンテナンスなどの重要なタスクを自動的に処理します。 また、マスターではなく、クラスター内のエージェント ノードに対してのみ支払います。 マネージド Kubernetes サービスとして、AKS では次の機能が提供されます。

  • Kubernetes バージョンのアップグレードと修正プログラムの自動適用。
  • クラスターのスケーリングが簡単です。
  • 自己復旧のホストされているコントロール プレーン (マスター)。
  • コスト削減 - エージェント プール ノードの実行に対してのみ支払います。

Azure が AKS クラスター内のノードの管理を処理する場合、クラスターのアップグレードなど、多くのタスクを手動で実行する必要がなくなりました。 Azure はこれらの重要なメンテナンス タスクを自動的に処理するため、AKS ではクラスターへの直接アクセス (SSH など) は提供されません。

AKS を利用しているチームは、Azure Dev Spaces を利用することもできます。 Azure Dev Spaces は、チームがマイクロサービス アーキテクチャ全体または AKS で実行されているアプリケーションを直接操作できるようにすることで、チームがマイクロサービス アプリケーションの開発と迅速な反復に集中するのに役立ちます。 また、Azure Dev Spaces では、残りの AKS クラスターや他の開発者に影響を与えることなく、マイクロサービス アーキテクチャの一部を個別に個別に更新する方法も提供されます。

Azure Dev Spaces ワークフローの例

Azure Dev Spaces:

  • ローカル コンピューターのセットアップ時間とリソース要件を最小限に抑える
  • チームがより迅速に反復できるようにする
  • チームが必要とする統合環境の数を減らす
  • 開発/テスト時に分散システム内の特定のサービスをモックする必要を取り除く

Azure Dev Spaces の詳細

Azure Virtual Machines

App Service で実行するために大幅な変更を必要とする既存のアプリケーションがある場合は、クラウドへの移行を簡略化するために Virtual Machines を選択できます。 ただし、VM を正しく構成、セキュリティで保護、保守するには、Azure App Service と比較して、はるかに多くの時間と IT の専門知識が必要です。 Azure Virtual Machines を検討している場合は、VM 環境の修正プログラムの適用、更新、管理に必要な継続的なメンテナンス作業を考慮してください。 Azure Virtual Machines はサービスとしてのインフラストラクチャ (IaaS) ですが、App Service は PaaS です。 また、Windows コンテナーとして Web App for Containers にアプリをデプロイすることが、シナリオで実行可能なオプションであるかどうかを検討する必要があります。

論理プロセス

アプリケーションの残りの部分から切り離すことができる個々の論理プロセスは、"サーバーレス" の方法で Azure Functions に個別にデプロイできます。 Azure Functions を使用すると、特定の問題に必要なコードを記述するだけで、実行するアプリケーションやインフラストラクチャについて心配する必要はありません。 C#、F#、Node.js、Python、PHP など、さまざまなプログラミング言語から選択でき、タスクの最も生産性の高い言語を選択できます。 ほとんどのクラウドベースのソリューションと同様に、使用した時間に対してのみ料金を支払い、Azure Functions を信頼して必要に応じてスケールアップすることができます。

データ

Azure にはさまざまなデータ ストレージ オプションが用意されているため、アプリケーションは該当するデータに適切なデータ プロバイダーを使用できます。

トランザクション データの場合、Azure SQL Database が最適なオプションです。 高パフォーマンスの読み取り主データの場合、Azure SQL Database によってサポートされる Redis キャッシュが適切なソリューションです。

非構造化 JSON データは、SQL Database 列から Azure Storage の BLOB またはテーブル、Azure Cosmos DB まで、さまざまな方法で格納できます。 これらの中で、Azure Cosmos DB は最適なクエリ機能を提供し、クエリをサポートする必要がある多数の JSON ベースのドキュメントに推奨されるオプションです。

アプリケーションの動作を調整するために使用される一時的なコマンドまたはイベント ベースのデータは、Azure Service Bus または Azure Storage キューを使用できます。 Azure Service Bus は柔軟性を高め、アプリケーション内およびアプリケーション間の簡単でないメッセージングに推奨されるサービスです。

アーキテクチャに関する推奨事項

アプリケーションの要件によって、そのアーキテクチャが決まります。 さまざまな Azure サービスを利用できます。 適切なものを選択することは重要な決定です。 Microsoft では、一般的なシナリオ用に最適化された一般的なアーキテクチャを特定するのに役立つ参照アーキテクチャのギャラリーを提供しています。 アプリケーションの要件に密接に対応する参照アーキテクチャを見つけたり、少なくとも開始点を提供したりする場合があります。

図 11-1 は、参照アーキテクチャの例を示しています。 この図では、マーケティング用に最適化された Sitecore コンテンツ管理システム Web サイトに推奨されるアーキテクチャ アプローチについて説明します。

図 11-1

図 11-1 サイトコア マーケティング Web サイトのリファレンス アーキテクチャ。

リファレンス – Azure ホスティングに関する推奨事項

前の

  • Last updated on