Azureマイクロサービスとアプリサービスの開発 NCache
録画されたウェビナー
RonHussainとAdamJ.Kellerによる
Azureクラウドアプリのパフォーマンスとスケーラビリティを最適化して、ピーク負荷で実行します。 高速でスケーラブルな共通のデータリポジトリを使用して、データやセッションを失うことなくAzureサービスアプリケーションのエクスペリエンスを向上させます。
このウェビナーは、AzureMicroservicesとAppServicesをクラウド内の.NET分散キャッシュと統合する方法を示しています。
カバーします：
- Azureマイクロサービスとアプリサービスの概要
- NuGetパッケージを使用して NCache クライアントアプリケーションリソース
- 作成 NCache AzureServicesからのAPI呼び出し
- Azureでの分散キャッシュの作成とデプロイ
- AzureServicesのキャッシュを使用する
- AzureMicroservicesとAppServicesを実行しているキャッシュを監視する
今日選択したトピックは NCache これは、Azureサービス内の主要な分散キャッシュシステムです。 今日の私の主な焦点は、Azureマイクロサービスです。 マイクロサービスのアーキテクチャの詳細について説明します。 マイクロサービスで分散キャッシュが必要な理由、制限事項について詳しく説明します。次に、アプリサービスMicrosoft Azure Webアプリケーションサービスプロジェクトについても説明します。この場合、Webアプリケーションには分散キャッシュシステムも必要になる可能性があります。データの処理、セッションの場合、出力キャッシュ。 それで、私が強調しようとしているそれらの種類の機能。 今日取り上げる主な議題は、このウェビナー内の実践的な部分で、デプロイメントアーキテクチャに焦点を当てます。 分散キャッシュがどの程度正確にデプロイされ、アプリケーションがどの程度正確にそれに接続する必要があるか。
Azureマイクロサービスとアプリサービス
そこで、最初に、Azureマイクロサービスとアプリサービスに関するいくつかの紹介の詳細について説明します
マイクロサービスとは何ですか？
マイクロサービスとは何ですか？ ですから、これは私たちが最近よく耳にする非常に一般的な用語です。 これはプラットフォームであり、MicrosoftAzureによって提供されています。 いくつかのAWSがあり、次にいくつかのサードパーティプロバイダーもあります。 通常、私はAkka.NETという名前を付けます。これは、Javaでも非常に人気のあるプラットフォームであり、.NETにも採用されています。 マイクロサービスは、顧客のビジネスシナリオをカプセル化するプラットフォームであり、顧客がアプリケーション内で抱えている特定の問題を処理します。 したがって、小さなエンジニアリングチームによって開発される可能性があります。 任意のプログラミング言語で書くことができます。
ステートフルである可能性がありますが、ステートレスである可能性がありますが、アプリケーション内で独立しているものです。 したがって、個別にバージョン管理、実装、デプロイできます。マイクロサービスアーキテクチャの優れている点は、個別にスケールアウトできることです。 アプリケーション全体をスケールアウトする必要はありません。 これらの特性を満たすアプリケーション内の部分であれば、マイクロサービスとして実装できます。 アプリケーションはそれをマイクロサービスリソースとして使用でき、アプリケーション全体のスケーラビリティを気にすることなく、この特定の部分をスケールアウトできます。 そのため、アプリケーション内のさまざまなセグメントに対して、よりきめ細かいアプローチが可能になります。
ここでは、マイクロサービスが明確に定義されたインターフェイスプロトコルであり、他のマイクロサービスとも相互作用するというXNUMXつの共通点を強調しました。 そして、それらはMicrosoft Azureで取得するものである一意の名前を持ち、障害が発生した場合に一貫性を保ち、使用できるようにする必要があります。 つまり、これはマイクロサービスのもうXNUMXつの重要な特徴です。 これは、MicrosoftMSDNWebサイトからコピーしたものです。 ですから、マイクロサービスとは何かを誰もが知っていると確信しています。 だから、これはマイクロサービスに関するいくつかの基本的な詳細をカバーする必要があります、いいですか？
MicrosoftAzureサービスファブリック
これは、アプリケーションタイプがステートフルまたはステートレスのサービスタイプである場合の図です。 私はすでにそれをカバーしました。
独自のマイクロサービスを持つことができる別のアプリケーションタイプがあり、コードや構成のバックエンドデータソースと通信している可能性があります。 Webサービスを呼び出している可能性があります。 また、アクセスする必要のあるデータが含まれている可能性もあります。これは、マイクロサービスがどのようにアーキテクチャ化されているかというアイデアにすぎません。 複数のアプリケーションが存在する可能性があり、各アプリケーションが複数のマイクロサービスを持つ可能性があります。マイクロサービスは、サーバーのクラスター、インスタンスクラスターです。 マイクロサービス内にパーティションを作成できます。 これは主にステートフルマイクロサービスです。 複数のマイクロサービスがある場合は、ステートフルまたはステートレスのマイクロサービスを選択できます。
それらがステートフルマイクロサービスである場合、データパーティションがあり、次に他のパーティションのレプリカがあります。 したがって、いずれかのパーティションがダウンした場合、バックアップが自動的に使用可能になります。 つまり、これはMicrosoft Azureの一部であり、これはマイクロサービスアーキテクチャの一般的な部分でもあり、Amazonも同じ種類の質問形式を持つAkka.NETを提供します。 したがって、マイクロサービスは、デフォルトでそのアーキテクチャ内でそれ自体の中に状態を提供するものです。 したがって、次のような分散キャッシングが必要な場所を強調します。 NCache。 なぜ分散キャッシュが必要で、いくつかのボトルネックがあるのか、このウェビナーの一部として分散キャッシュが対処するのに役立ついくつかの問題があります。これについては、これから説明します。
Azure WebAppServicesの概要
次に、AzureWebアプリケーションサービスについても説明します。 MicrosoftAzureにWebアプリケーションを展開する方が簡単です。
VM全体を用意する必要はありません。 それは実際にあなたのDevOps時間、必要な専門知識の量、それにかかる時間を削減します、それは管理されるものです。 したがって、インスタンスベースのアプリケーションをMicrosoftAzureにデプロイするだけで済みます。 これは、アプリケーション専用の完全に分離された環境です。 スケールアウトできます。 複数のアプリケーションをホストできます。 モバイルアプリ、Web、またはファンクションアプリのいずれか、この時点で必要な方を使用して、MicrosoftAzureWebアプリサービスモデルを使用できます。
そして、それは非常にスケーラブルであり、分離が保証されていることはすでに述べました。 安全なネットワークアクセスを取得すると、高いメモリ使用率や必要なその他のリソースを使用することもできます。 そして、これはほとんどのデプロイメントが実際に行っている移行であり、VM全体をWebフォームでホストするのではなく、VM全体を管理する必要があるWebガーデンシナリオでは、インスタンスベースのアプローチを使用できます。サービスベースのアプリケーションをデプロイでき、データベース呼び出しを使用できるセッションを使用できる典型的なMVCアプリケーションである可能性があります。 したがって、あらゆる種類の通常のMVC Webアプリケーション関連の概念ですが、デプロイメントがわずかに異なるだけです。
分散キャッシング
AzureマイクロサービスとAzureWebアプリケーションサービスを定義したので、そうですか？ つまり、Microsoft Azureのマイクロサービスはサービスファブリックプロジェクトですが、Webアプリサービスはアプリサービスプロジェクトです。 そこで、その周辺の詳細を強調し、分散キャッシュで使用するために必要なネットワーク部分について説明します。
インメモリ分散キャッシュとは何ですか？
まず、分散キャッシングの概念全般について説明します。
分散キャッシュとは何ですか？ 分散キャッシュは安価なキャッシングサービスのクラスターであり、メモリとそのリソースを計算能力、次にストレージ能力のためにプールします。分散キャッシュの場合は、メインストレージを提供するメモリです。 したがって、すべてのメモリリソースを論理容量にプールします。
次に、すべてのキャッシュサーバー間でキャッシュの更新を同期できます。 たとえば、特定のサーバーに適用される更新は、すべてのキャッシュサーバーに適用されます。 したがって、分散キャッシュは、論理容量に結合された複数の安価なキャッシュサーバーのクラスターです。 Microsoft Azureには複数のサーバーがあり、これらはVMになります。 それで、 NCache 仮想マシンにデプロイされます。 これは現在の展開オプションです。 NCache Dockerにデプロイすることもできますよね？ つまり、これは別の展開オプションです。 したがって、VM上で実行されているキャッシュサーバーは、Microsoft Azure内の個別のリソースとして扱われ、これが、これまでの典型的な展開です。 NCache サーバー側の構成が関係します。
分散キャッシュの次の特徴は、すべてのキャッシュサーバーですべてのキャッシュ更新を同期する必要があることです。 2 3 4のキャッシングサーバーがあり、それらはデータの一貫したビューを持っている必要があります。 データは、それに接続されているすべてのアプリケーションで同じ状態として表示される必要があります。
そして、容量が増えるにつれて、メモリとトランザクションを直線的にスケールアウトする必要があります。より多くのストレージが必要になり、より多くのキャッシングサーバーを導入するだけで、直線的に大きくなるはずです。 そして..次に、レプリケーションはデータをレプリケートする必要がある別の部分です。サーバーがダウンした場合に追加されるデータについては、自動的にレプリケートされる必要があります。 レプリケーションは操作に基づいて実行する必要があり、サーバーがダウンした場合にデータを利用できるようにする必要があります。
したがって、これらは分散キャッシュのいくつかの一般的な特性です。
データストレージはスケーラビリティのボトルネックです
通常、アプリケーションは、アプリサービスであれ、マイクロサービスであれ、一部のバックエンドデータソースと通信している可能性があります。 Microsoft Azureでは、同じVネットまたはクロスVネット上にある可能性のある、後続のサーバーインスタンスを持つことができますが、それでもデータベースサーバーと通信します。
そのため、速度が遅くなる可能性があり、あまりスケーラブルではない可能性があります。 したがって、MicrosoftAzureにも分散キャッシュレイヤーを導入する方が理にかなっています。 また、マイクロサービスのアプリ内サービスに関するユースケースについても説明します。
NCache 展開
これはの典型的な展開です NCache.
したがって、Microsoft Azureには、水平方向に拡張できるVMがあり、仮想ネットワークを作成し、VMを作成してから、インストールするだけで済みます。 NCache それらのVMで、またはAzureまたはAWSイメージを使用します。 つまり、アプリケーションはマイクロサービス、APIアプリ、他のVM上の一般的なIISホストアプリに接続できます。または、すべてがこれに接続できるアプリサービスである可能性があり、バックエンドデータソースへのアクセスを節約できます。 だから、それはの典型的な展開の一般的な考え方です NCache マイクロサービスとAzureアプリサービスのデプロイに移ったら、これを再検討します。 クラウドでは、これはわずかに変化します。 それで、それについて話します。
のXNUMXつの一般的な使用法 NCache
わかった！ これは、このウェビナー内で最も重要なスライドです。 Microsoft Azureサービスのどこで分散キャッシュを使用するのかを強調したいと思いますよね？ したがって、通常は、一元化されたソースからのデータにアクセスする必要があり、非常に高速なリポジトリを必要とするWebアプリケーション、Webサービス、バックエンドアプリケーション、ウィンドウサービスについて話します。 つまり、これは典型的なユースケースです。 Microsoft Azureには、すでに非常にスケーラブルなプラットフォームがあります。 アプリケーションは直線的にスケールアウトできます。これは、WebフォームやWebガーデンの典型的なケースです。
そこで、MicrosoftAzure内でサービスに使用できるいくつかの重要なユースケースをリストアップしました。
アプリのデータキャッシュまず、データキャッシュに使用できます。これは、MicrosoftAzureマイクロサービスとアプリサービスに適用されます。 ステートレスなサービスがあるとしたら？ ステートフルサービスには独自のパーティション分割のセットが必要であり、レプリカもありますが、ステートレスにはレプリカがないためです。 つまり、重要な側面のXNUMXつは、ステートレスアプリケーションを使用しているにもかかわらず、データの信頼性を維持したいということです。 したがって、その場合は、データを分散キャッシュに入れることができます。 分散キャッシュは、設計上、レプリケーションの側面と高可用性の側面をカバーできます。 したがって、ステートレスマイクロサービスでもデータを利用できるようになります。
また、次の利点は、マイクロサービスまたはアプリサービス内にもある可能性があります。Webアプリケーションがある場合は、SQLサーバーなどのバックエンドデータソースと通信する可能性があります。 そのため、SQLサーバーは低速です。 膨大なトランザクション負荷を処理できるものではありません。 これに対応して、分散キャッシュには複数のサーバーを含めることができます。これらのサーバーは線形にスケールアウトされ、論理容量に結合されます。 したがって、その場でさらに多くのサーバーを追加できます。 そして、Microsoft Azureでは、それを管理するのは非常に簡単です。 新しいVMを生成するだけで、キャッシングサーバーを追加するにつれて容量がXNUMX倍になります。 したがって、データキャッシングのユースケースは、まず最初にメモリ内にあります。 そのため、容量データベースが超高速であり、Microsoft SQLサーバーと比較して、MicrosoftAzureでも非常にスケーラブルなプラットフォームです。 したがって、これらは、MicrosoftAzureアプリサービスとMicrosoftのユースケースで得られるXNUMXつの利点です。 紹介するだけです NCache API呼び出しを行うと、キーと値のペアでデータを追加し続けます。
ASP.NET固有のキャッシュXNUMX番目の使用例は、MicrosoftWebアプリサービスに固有のものです。 これは、ASP.NET固有のキャッシュに関するものです。 だから、あなたがアプリサービスを持っているなら、あなたは使うことができます NCache、アプリサービスが話しかける場所 NCache セッションおよび出力キャッシュデータ用。 ちなみに、このユースケースはASP.NETアプリサービスにも適用されるため、オブジェクトキャッシングAPIを使用することもできます。 したがって、セッション状態は通常、スティッキーセッションの負荷分散が必要な同じアプリサービスインスタンスの一部になるか、データベースの一部になる可能性があります。 いずれにせよ、スティッキーセッションの場合、デフォルトのオプションであるスティッキーロードバランシングが必要な場所に制限があります。 そして、データベース側では、再び低速になり、単一障害点にもなります。
アプリサービスでは、 NCache セッションプロバイダーとして、まず第一に、それは非常にスケーラブルです。 これは非常に高速であり、単一障害点はありません。 セッションはサーバー間で複製されるため、ASP.NETアプリケーションに分散キャッシュを使用することを検討する必要があります。 そして、これはマルチサイト展開でもあり得ます。これは、XNUMXつのサイトにXNUMXつのアプリケーションを展開して、同じサイトのキャッシングサーバーと通信し、通信する機能を備えている場合にも、今日取り上げる予定です。サイト全体でサーバーをキャッシュすることもできます。 また、Azure内で必要な構成を強調しますが、それはAzure内では不可能です。 NCache MicrosoftAzure内の分散キャッシングオファリング。
XNUMX番目のユースケースは、出力キャッシュに関するものですよね？ したがって、静的ページは、アプリサービスとしてデプロイされたWebアプリケーション内のアプリサービス内で使用できます。 静的ページがある場合は、それらのページのコンテンツをキャッシュします。 ページ出力全体をキャッシュすることができ、次に同じページにアクセスする必要があるときにそのページ出力を使用できます。 だから、それは別の利点です。 これは、典型的なASP.NETのパフォーマンスとスケーラビリティのウェビナーで取り上げています。ここでは、ASP.NETのパフォーマンスを最適化するためのXNUMXつの異なる方法について説明しています。 したがって、同じ概念がMicrosoft Azureアプリサービスにも適用され、Webアプリケーションがアプリサービスとして展開されます。
Pub/Subおよびランタイムデータ共有現在、XNUMX番目に重要なユースケースであり、マイクロサービスに関してはこれが最も重要な部分です。 アプリサービスにも適用されますが。 アプリサービスでは、あるアプリケーションサービスが別のアプリケーションサービスと通信するデータ共有が必要な場合もあれば、XNUMXつの異なるアプリケーション間で共有されるデータである場合もあります。 そのため、性質は異なりますが、同じデータに依存しているWebアプリケーションがあります。 レポートアプリケーションがあり、その消費者がいる可能性があります。または、製品カタログの観点からプロデューサーがあり、それに依存する必要がある別のアプリケーションがあり、最初のアプリケーションに基づいていくつかのレポートを生成する必要があります。 。 したがって、そのユースケースでは、アプリケーションが別のアプリケーション間でデータを共有する必要があります。 したがって、データベースを使用してデータを共有する方法はありませんが、それは低速であり、場合によっては単一障害点にもなります。 アプリケーションはクライアントサーバーモデルでキャッシュに接続できるため、分散キャッシュの方が理にかなっています。 複数のアプリケーションが同じ層に接続でき、同じキャッシュ層に接続できます。その後、同じキャッシュリソースを使用して同じデータにアクセスできます。これは、オンにできる機能です。
Azureマイクロサービスでは、それを別のレベルに引き上げる必要があります。 Azureマイクロサービスでは、これらはクラスター化されており、ステートフルおよびステートレスになる可能性があることは既に説明しましたが、そうではありませんか？ 要件がある可能性がありますが、これは、マイクロサービスがマイクロサービスとも対話する必要がある可能性があることを私が述べたものですよね？ そのため、設計上、マイクロサービスアーキテクチャでは、サービスインスタンスが相互に対話する必要があり、次に相互にデータを共有する必要がある場合があります。 そして、マイクロサービスプラットフォームに関する限り、これは非常に重要な要件です。 複数のアプリケーションインスタンスが相互にデータを共有する必要があるだけです。 XNUMXつのマイクロサービスがデータを送信し、他のマイクロサービスインスタンスで利用できる場合、ステートフルであるか、同じ回線で複数のアプリケーションを相互作用させることができますが、XNUMXつのマイクロサービス内ではこれは必須であり、したがって多くのサードパーティプロバイダーはオファリングの一部としてデータ共有とpub/subモデルを提供しますよね？
したがって、Microsoft Azureでは、あるアプリケーションがストアと通信する場所でデータ共有を処理する必要があり、別のアプリケーション、別のマイクロサービスインスタンスで必要なデータがある場合は、それを処理するためのプラットフォームが必要です。 NCache データが一元的に利用できるプラットフォームを提供します。 非常に高速なリポジトリです。 複数のマイクロサービスインスタンスの上に非常にスケーラブルであり、異なるサービスまたは同じサービスのインスタンスがこのキャッシュに接続でき、そこからデータ共有機能を使用できます。 したがって、データはより高速な方法で一元的に利用できます。
次に、トピックベースのpub/subモデルがあります。 そこからメッセージングプラットフォームがあります。 したがって、メッセージを送信することができます。データ駆動型メッセージ、アプリケーション駆動型メッセージ、またはトピックベースのメッセージで、プロデューサーアプリケーションは、データをキャッシュに送信し、そのメッセージがすべての受信者に送信されるマイクロサービスのインスタンスです。この加入者側で。 また、同様に、サブスクライバーがプロデューサーになる場合もあります。 したがって、複数のAzureマイクロサービスインスタンス間でpub/subメッセージングを使用できます。 複数のインスタンス間でのイベント駆動型のデータ共有の場合もあります。 そして、その上に、イベント通知と継続的なクエリシステムがあります。 これはSQLコマンドである可能性があり、それに基づいて、これからデータ駆動型メッセージを取得できるデータセットを再度定義できます。 つまり、これは、MicrosoftAzureマイクロサービス内でMicrosoftAzure分散キャッシュを使用することを検討するユースケースです。
NCache MSAzureでの展開シナリオ
次に、AzureWebアプリケーションサービスについても説明します。 MicrosoftAzureにWebアプリケーションを展開する方が簡単です。
わかった。 これで、XNUMX種類のシナリオが正しくなりました。 したがって、すべてを同じリソースグループ内または同じ仮想ネットワーク内の単一サイトの単一リージョンに展開することが望ましいでしょう。 だから、私はすでにそれについて議論しました NCache はMicrosoftAzureのVMにデプロイされますが、アプリケーションは、これらのVMにアクセスするVMのいずれかです。 NCache または、これらはAzureサービスである可能性があり、今日はAzureサービスに焦点を当てます。 VMの場合は、VMを生成し、iASに移動し、そこでアプリケーションをホストしてから、アプリケーションをに接続するという非常に一般的なケースです。 NCache NCache APIまたはセッションストアプロバイダー。 ただし、サービスに関しては、ネットワーク構成を行う必要があります。 だから、あなたのサービスが話しかけるように NCache.
そのため、Azureサービスと NCache 同じサイトの同じリージョンにデプロイされます。 そのため、Azureサービスを展開するときは、同じリソースグループに接続する必要があります。また、同じ仮想ネットワークにも接続する必要があります。 したがって、これが推奨されるアプローチです。 仲介者は必要ありません。 複数のホップが存在することはありませんが、物事を遅くすることはありません。 だから、それは私たちのサイトに推奨されるシナリオです。
XNUMX番目のシナリオ、これも非常に有効なシナリオであり、複数のサイトがある可能性があります。 キャッシュとアプリケーション、マイクロサービスアプリサービスは、相互に接続できる必要があるのと常に同じリージョンにある必要があります。 以来 NCache TCP-IPプロトコルです。 したがって、すべての通信にIPアドレスとポートを使用し、これらはTCP-IPポートです。 したがって、アプリケーションが近くにあるようにデプロイする必要があります。 それらは互いに組み合わせて展開されます。 それらは近くにあり、利用可能な異なるホップではありません。 そのため、アプリケーションと同じサイトにキャッシュをデプロイすることをお勧めしますが、マルチサイト機能を使用しているシナリオが存在する可能性があります。 アプリケーションが別のサイトのキャッシュと通信する必要がある場合、またはキャッシュが相互に通信する必要がある場合。 したがって、サイト間通信が必要です。 NCache 同様に。
だから、それは私がこれらの1つのシナリオをカバーすることになる議題です。 シナリオXNUMXは、すべてがアプリケーションに近いシングルにあることをお勧めします。 シナリオXNUMXは、複数のサイトがあり、サイトXNUMXのアプリケーションがサイトXNUMXのキャッシングサーバーと通信する場合と、キャッシングサーバーの場合があります。 たとえば、WANレプリケーション機能の場合、サイトXNUMXのキャッシュとサイトXNUMXのキャッシュの間にブリッジを設定できます。
シナリオ1：Azureサービスと NCache （推奨）
そのため、Azure Servicesの単一サイトの展開では、これに関するいくつかの詳細な手順について説明します。 アプリケーション開発について、どのように紹介するかについてお話します NCache アプリケーション内で呼び出します。参照例として、このためのサービスプロジェクトを使用します。 大丈夫。 したがって、これは、このウェビナーで取り上げる予定のすべての詳細を網羅する必要がある図です。
すでに述べました NCache サーバーはMicrosoftAzureのVMになります。 右？ したがって、これらのVMをサポートする仮想ネットワークを管理する必要があります。 NCache これらにインストールする必要があります。次に、アプリサービスとしてデプロイされるWebアプリケーション、APIアプリ、またはマイクロサービスアプリの可能性があります。 それらはすべてサービスインスタンスです。 それらは基盤となるVMではありません。 つまり、インストールできないということでもあります NCache これらのリソースでは、これをアプリケーションリソースの一部として含める必要があります。 そのため、ここで強調するNuGetパッケージがあります。 わかった！ つまり、Webアプリがあり、次にAPIアプリがあり、マイクロサービスやその他のアプリもある可能性があります。
したがって、これは典型的な単一サイトの展開であり、アプリケーションとのVMSをホストする同じAzure仮想ネットワークがあります。 NCache。 そして、これで私たちが実際に行っているのは、Webアプリケーションとサービスアプリ間のポイントツーサイトVPNであり、 NCache サービス。 だから、それは全体的なネットワーキングがどのように見えるかです。 これは、実際にサービスプロジェクトを使用するのと同じ仮想ネットワークの一部です。 紹介します NCache その中のリソースは、サーバー側のリソースを作成します NCache。 つまり、VMが稼働しているので、アプリケーションに戻って、アプリケーションを同じ仮想ネットワークに接続します。 NCache VMは存在します。 つまり、それは単一のサイトになり、キャッシングサービスと同じ仮想ネットワークを使用することになります。
それでは、これらの手順を実行してみましょう。
わかった！ 最初のステップはあなたが持っていることです NCache サーバー側のどちらかをウォームアップしてセットアップします。これは、実際にはAzure仮想マシンをセットアップすることを意味します。 NCache この手順は、単一サイト展開であろうとマルチサイト展開であろうと、あらゆる種類の展開に共通です。 単一サイトの展開の場合、必要なのは NCache サーバーがセットアップされ、VMであり、 NCache それらにインストールされます。 では、すぐにAzureポータルに移動しますよね？ また、リソースグループに移動すると、リソースグループが作成されたので、並べ替えます。 私の最初のリソースグループはデモリソースグループXNUMXですよね？ そして、ここにはあらゆる種類のVMがあります。たとえば、デモVM XNUMXがあり、次にデモVM XNUMXもあります。実際、同じ仮想ネットワークを使用しています。 これらのデモマシンの両方に同じ仮想ネットワークを使用しました。
さっそくお見せしましょう。ここに持ってきましょう。 わかった！ つまり、西ヨーロッパに展開されているデモVM 1があり、次にデモVM 2があり、次にデモVMv-net10.4.0.4があります。 それをクリックすると、デモVM10.4.0.5とデモVMXNUMXの一部が表示され、これらはIPアドレスXNUMXとXNUMXです。 だから、それは私たちのXNUMXつを表しています NCache VMと私がすぐにこの環境にあなたを連れて行くならここに。
つまり、私が実際に行ったことは、VMを作成したことです。空の2012年または2016年のイメージで十分です。その後、次の場所に移動しました。 Alachisoft ウェブサイトとあなたが必要とするすべて、特別なインストーラーはありません NCache. 既存のインストーラーを使用するだけです。 ダウンロード ページに移動し、30 日間の試用版をダウンロードします。 NCache 私たちのウェブサイトからそしてあなたがそれをしたら私はインストールしました NCache デモVM1とデモVM2で。次に、デモVネットキャッシュも作成しました。 キャッシュの作成手順は非常に簡単です。 デモキャッシュに移動して、キャッシュトポロジ、非同期を取得し、デモVM 1を指定するだけで、デモVM2はIPをそのまま選択する必要があると思います。 はい、そうです。 したがって、これらのサーバーは相互に通信できます。
私が取ったもうXNUMXつのステップは、プレゼンテーションに戻った場合、セットアップに必要なステップです。 NCache MicrosoftAzureのサービス。 Azure仮想ネットワークを作成しますよね？ それはあなたがあなたの環境にすでに持っているかもしれない何かです。 次に、それらのAzure仮想ネットワーク上にVMを作成します。 したがって、専用のVMセットを使用できます。 NCache; サーバーXNUMXサーバーXNUMXサーバーXNUMX。 次に、同じサブネットを維持していることを確認します。 それは私たちがお勧めするものであり、それからあなたはインストールします NCache それらすべてのVMで。 それからもう一つのことはあなたが開くことです NCache 通信用のポート。 XNUMX種類のポートがあり、XNUMX種類のネットワークに関する考慮事項が必要です。 XNUMXつは、内部ファイアウォールを無効にする必要があり、次にこれらのVMが存在するネットワーク上に、ネットワークセキュリティグループが必要です。
たとえば、VM XNUMXネットワークセキュリティグループのデモでは、これらのポートはすでに開いていますよね？ だから、私がすぐにあなたに見せれば NCache ポート、必要なのはポート9800と48250だけです。これは、インバウンド通信とアウトバウンド通信用です。 9800および48250したがって、これにより、使用しようとしているアプリケーションが確実に使用されるようになります。 NCacheポート9800を使用するは、これらのキャッシングサーバーに接続でき、管理しようとしているアプリケーションに接続できます。たとえば、これを管理しようとしている別のVMが存在し、仮想ネットワークを越えている可能性がありますが、これはの一部です。同じリソースグループであるこれらのネットワークセキュリティグループを使用すると、これらのポートでこの通信を実行できます。 だから、それだけです。 それはあなたが持っている必要がある考慮事項です。
キャッシュサーバー自体のファイアウォールをオフにしました。 そして、これらのポートは開いていて、キャッシュを作成したばかりで、統計を見ることができます。 これらのマシンでストレステストツールアプリケーションを直接実行するだけで、すぐに実行できます。少し遅れがありますので、ご容赦ください。 そして、私はこれらにもいくつかのストレスをシミュレートすることができます。 申し訳ありませんが、V net one cacheを実行し、これらXNUMXつのキャッシングサーバーでアクティビティをシミュレートします。 したがって、サーバー側のセットアップに関する限り、これは非常に簡単です。 ここで、アプリケーションに戻ってそれを確認する必要があります。 うん！ そこに行きます。 ですから、私たちは活動を始めています。それで、私たちは元気です。 これを閉じます。
単一サイトのデプロイのステップ2：環境にAzureサービスをデプロイする次に、仮想マシンを構成したので、キャッシュクラスターも作成しました。次に、このキャッシュクラスターと通信できるWebアプリケーションが必要です。 だから、私はすぐにここで私のプレゼンテーションに戻りますよね？
したがって、アプリケーションの観点から、本当に必要なのは、アプリケーション間、アプリサービス内のポイントツーサイトネットワーク構成が必要です。 NCache。 それで、まず第一に、私はすでにそれをしましたね？ それを強調するだけです。 リソースグループに戻ると、デモリソースグループ1があります。つまり、デモ仮想ネットワークゲートウェイがあります。 これにゲートウェイを作成しましたよね？ そして、サイトへのポイントがあります。 これは、デモv-netを使用する仮想ネットワークゲートウェイであり、キャッシュサービスの主要なネットワークです。 したがって、ここに戻ると、この図を見ると、実際にはこの仮想ネットワークの一部である仮想ネットワークゲートウェイが使用されており、まもなく展開するアプリケーションはサイトを指すようになります。これが同じ仮想ネットワークに接続されるように、これの間で通信が行われています。 これがMicrosoftAzureの要件です。 アプリサービスが仮想ネットワーク上にあるリソース（VMなど）と通信するには、サイトへのポイントを設定する必要があります。
だから、ここに戻ってきます。 つまり、デモリソースグループがあります。 ポイントツーサイトをお見せしても、ここに来てみましょう。ポイントサイト間構成をお見せすると、アプリサービスの一般的なIPであるこのIPがあります。 したがって、アプリサービスがデプロイされたら、それをクリックして、対応する仮想ネットワークに接続します。
それで、プロジェクトに戻ります。以前は表示しなかったと思いますが、これはサービスアプリであるサンプルアプリケーションです。 何が必要かをお見せします。 したがって、右クリックすると、MicrosoftAzureでNuGetパッケージを利用できるようになります。
たとえば、 Alachisoft.NCache.SDK。 これらは私たちと一緒に個人的に入手できますよね？ これらは、アプリケーションにすべての NCache のインストールがないため、リソースをポイントします NCache クライアント側で。 典型的 NCache 展開とは、クライアントがインストールされ、サーバーがインストールされていることです。 それで、それをカバーしますよね？ しかし、サービスではそれはインスタンスです。 そのため、基盤となるVMにアクセスできません。 したがって、その場合はNuGetパッケージが必要です。 したがって、すべてのリソースは、アプリケーション内で必要な一部になります。 だから、これは私がすでにインストールしたヌガーパッケージです。 それが実際にすべてを追加したもの NCache クライアントサイトのライブラリですね。 つまり、いくつかの構成も追加されています。 つまり、client.ncconfがあります。これは、任意のキャッシュに接続するメインファイルです。
たとえば、名前であるV net oneキャッシュに接続するための設定がすでにあり、それらに接続するための内部IPアドレスもあります。 次に、このアプリケーションを公開すると、このアプリケーションはVM 10.4.0.4の場合は10.4.0.5に、VMXNUMXの場合はXNUMXにアクセスできるようになります。 したがって、このパブリックIPがアプリケーションにアクセスできるサイト間通信のポイントがあることを確認する必要があります。そうしないと、このキャッシュに接続できなくなります。
それで、アプリケーションに戻って、私はいくつかのキャッシュ呼び出しを示しています。 したがって、このMVCプロジェクト内には、このキャッシュインスタンスがあるメインコントローラーがあり、次にキャッシュインスタンスを使用しています。 InitializeCache。 ここでこの方法に行きましょう。 したがって、これは初期化されたメソッドです。 NCache.initializeCacheを呼び出してから、cache.insertを呼び出してアイテムを追加し、Cache.deleteを呼び出してそのアイテムを削除し、cache.getを呼び出してアイテムを元に戻します。負荷テストを実行したかどうかわからない場合は、そうです。 したがって、実際にアイテムをロードする別のメソッドロードテストがあります。XNUMX個のアイテムがキャッシュにロードされ、それらも取得されます。 したがって、これは、アプリケーションが関係するだけでなく、メインロジックも処理する必要があります。
私があなたに示すいくつかの見解があります。 したがって、削除、取得、インデックス作成、負荷テストもあり、これらは単にアプリケーションから呼び出されます。 だから、私がすることは、これらが基本的なものになることです NCache 呼び出します。 したがって、次に行うことは、これをMicrosoftAzureにデプロイすることです。 ですから、私はすでにすべてのリソースグループとネットワーキングピースをここに設定しました。 ただし、本当に必要なのは、Microsoft Azureアプリの場合、サブスクリプションに基づいて新しいWebアプリ名を作成するだけです。 しばらく待ちましょう。 つまり、サブスクリプションを選択します。 どうぞ。 そのため、Visual Studioエンタープライズを自動的に選択し、次にリソースグループを選択しました。デモリソースグループを使用する予定です。 つまり、私は単一サイト展開を使用しています。 したがって、これは同じリソースグループの一部であり、サービスプランを選択してから、[作成]を選択します。 ここにも新しいものを入れることができます。 それで、その場所でさえ西ヨーロッパですよね？ これで[OK]を選択してから、[作成]を選択すると、自動的に開始されます。
それ以来、私はすでにこれを行っています。 したがって、次に行うことは、Web構成に移動し、VネットキャッシュXNUMXを使用していることを確認し、client.ncconf内にVネットキャッシュXNUMXがあることを確認します。 したがって、このアプリケーションは同じサイトにデプロイされます。 同じリソースグループが終了したら、それを自分の一部である仮想ネットワークに接続します NCache サーバーVM。
Microsoft Azureに戻ると、すぐにリソースグループXNUMXに移動すると、このアプリケーションがどこかにあるはずです。 どうぞ！ それをクリックしてから、デプロイされた後、このアプリケーションのネットワーク部分をクリックすると、そうですか？ しっくり来る！ それで、あなたはネットワーキングに行き、それをクリックし、そしてそれはすでにデモv-netに接続されていますよね？ 私はすでにこれをしましたね？ それで、あなたの場合、仮想ネットワークゲートウェイへのサイト接続をポイントすると、デモリソースグループがXNUMXつになりますよね？ ここでこれを元に戻します。 したがって、仮想ネットワークを作成したら、ポイントツーサイトを作成すると、このアプリサービスのIPが公開されます。アプリサービスを展開した後、仮想ネットワークに接続する必要があります。 だから、これはここで必要な追加のステップです。 だから、私のアプリケーションはロードされているといいのですが。 待ってますね！
サーバー側でコンテンツをクリアし、アイテムを挿入します。 キャッシュに正常に追加されました。 そして、あなたはそれでXNUMXつのアイテムを見ることができます私はすぐにそれを手に入れます。 申し訳ありませんが、実際にカウンターを表示することはできませんが、実際に取得したので、削除できますよね？ つまり、同じ仮想ネットワークの一部であるため、比較するとはるかに高速です。
次に、いくつかの負荷テストをシミュレートします。数千のアイテムを追加するだけで、いくつかのアクティビティが表示されます。 行きますよね？ つまり、600秒あたりのリクエスト数とそれらのアイテムが追加されているので、ここに約400個のアイテムが表示され、ここに約XNUMX個のアイテムが表示され、それらのアイテムは取得されません。 つまり、これは、マイクロサービス、アプリサービス、APIアプリ、サービスモデルにデプロイされたアプリケーションなど、サービスの典型的なデプロイです。 NuGetパッケージを導入し、サイトへのポイント接続を作成するだけです。 NCache ネットワークゲートウェイ、次にアプリケーションインスタンスを介してVMをVMに接続できます。 つまり、これらはすべてMicrosoftAzureネットワーク構成であり NCache TCP-IPチャネルで公開するプライベートIPアドレスが必要なだけです。 だから、それが私たちに必要なすべてです。
シナリオ2：Azureサービスのマルチサイト展開と NCache
それで、次に利用できる時間が少ないので、最後の10分間で、マルチサイトのシナリオもカバーすると思います。 構成はほぼ同じです。
WebアプリまたはMicrosoftサービスまたはアプリサービスをXNUMXつのAzure仮想ネットワークまたはXNUMXつのサイトに展開してから NCache VMまたは別のサイトであり、そのために本当に必要なのは、ここではローカルネットワークゲートウェイ、ここでは仮想ネットワークゲートウェイであり、これらXNUMXつの間にサイト間接続が必要です。 繰り返しになりますが、これらはすべてMicrosoft Azureの設定であり、サイト間接続を使用してXNUMXつの側が相互に接続できるようになっています。 NCache それらを利用し、内部IPは両側にマッピングされます。 だから、あなたの NCache サーバーの内部IPは、アプリケーションサービスの仮想ネットワークにマッピングされます。その逆も同様です。
そのために、構成を簡単に説明します。 リソースグループに戻ると、デモリソースグループ3がありますよね？ つまり、それは別の仮想ネットワークです。 そして、ここにデモv-net 4があり、この仮想ネットワークにもデモVM10とデモVM4.0.4のXNUMXつのボックスがあります。したがって、この環境はXNUMXです。これは別の仮想ネットワークです。 別の仮想ネットワークの例えを別のサイトとして使用しているだけでも、サイト全体に及ぶ可能性があります。 ただし、クロスサイトの場合もあれば、MicrosoftAzureの別のリージョンにある別のデータセンターの場合もあります。
マルチサイト展開の手順：環境にAzureサービスを展開するしたがって、本当に必要なのは、すでに説明したのと同じ設定を維持することです。
VM部分を同じ仮想ネットワークの同じサブネット上に維持し、キャッシュを作成し、そのキャッシュを開始します。次に、アプリケーションはクロスサイトであるキャッシュに接続する必要があります。 そのためには、サイト間のコミュニケーションが行われている必要があります。 そして、このデモリソースグループに戻ってきたら、デモ仮想ネットワークとデモ仮想ネットワークゲートウェイがあるので、そうですね、仮想ネットワークゲートウェイ2ですね。 つまり、これは2番目のサイトのゲートウェイです。 したがって、接続に移動すると、デモ2のサイト間接続があります。 したがって、デモXNUMXローカルネットワークゲートウェイへのサイト間接続があります。 だから、それは私が設定したものですよね？ つまり、これにより、仮想ネットワークXNUMXがサイト全体にある仮想ネットワークXNUMXに接続できるようになります。 だから、これはまさに私たちがやったことです。
すぐにお見せします NCache ここでは何も変わらないアプリケーション。 キャッシュの名前を変更するだけで、スタックの一部として持っているキャッシングサーバーに接続するためのIPアドレスが必要になります。 したがって、V-netをキャッシュし、同じアプリケーションを使用して接続します。もう一度公開する必要がありますが、デモリソースグループ3でまだ公開していることに注意してください。 一方、仮想マシンはデモリソースグループ1にあります。 そして、これはVM 2であり、ここにはXNUMXつのキャッシュサーバーがあります。 したがって、サイト間の接続をすでに構成したまま、これをもう一度公開します。 これを公開するだけで、同じアプリケーションがネットワークを越えて、仮想ネットワークXNUMXから仮想ネットワークXNUMXまでサイトを越えて行き、これに接続できるようになります。 それで、私はそれが公開されるのを待つだけです、そしてそれから私はここに戻って、そしてもう一度あなたにネットワーキングの部分を見せます。
したがって、実際に必要なのは、仮想マシンの同じセットアップ、ここに同じ仮想ネットワーク、同じサブネットを維持し、VMSを生成し、インストールすることです。 NCache それらで、ファイアウォールを無効にし、ネットワークセキュリティグループを設定して、 NCache ポートが開いている場合、に接続するサービスとして、アプリケーション間にサイト間接続が必要です。 NCache サービス。 したがって、アプリサービスが接続されている仮想ネットワークが既にある場合は、仮想ネットワーク1が仮想ネットワーク2と通信できるようになり、クロスサイトが存在することを確認する必要があります。これはまさに私が行ったことです。 MicrosoftAzureでも同様です。 したがって、公開は成功しました。 これだったと思います。 閉じて、アイテムを挿入しますね。 そして、そこにアイテムが追加されているかどうかを見てみましょう。 そこで、アイテムが追加されました。 つまり、今ではサイト間で、あるサイトから別のサイトへと話し合っており、このアイテムを取得すると、取得されるだけです。 削除すると、このアイテムはデモVM 3から削除され、アイテムはありません。同様に、同じ環境の使用を開始する負荷テストをシミュレートしますが、それ。
つまり、私のサイト2で、アプリサービスはサイトXNUMXのキャッシュサービスと通信しています。 彼らはサイトを横切っています。 その一部となる可能性のあるWANレプリケーションまたはWAN遅延があるため、これは推奨されるシナリオではありません。 したがって、すべてを同じサイトに保持することをお勧めしますが、たとえば、マルチサイトセッション機能に基づく、のバナーアプリケーション機能に基づくシナリオが存在する可能性があります。 NCache。 オンプレミスアプリケーションがAzureと通信している場合もあれば、AzureアプリケーションがXNUMXつのオンプレミスと通信している場合もあります。 したがって、これらは要件であり、負荷テストも完了し、正常に実行されました。
つまり、Azureのデプロイについて説明します。
.NETの分散キャッシュオプション
この時点で言及したいことがいくつかあります。 Redis 比較も。
Azureについて話しています。 だから、私たちは間違いなく話します Redis。 だから、それは私たちのウェブサイトで利用可能です。 NCache 100％.NETです。 それはc-sharpで開発されました。 .NETとJavaで完全にサポートされています。 比較において、 Redis 舞台裏はLinuxであり、VMSを制御することはできません。 の NCache VMSを完全に制御できます。 サーバーサイドコードを実行できます NCache 同様に、WindowsバージョンのMicrosoftバージョン Redis あなたが安定していることを知っているということではありません。 これは、舞台裏で使用され、サービスモデルとして提供されるLinuxバージョンです。 その後、 NCache Dockersでも使用できます。 使用する予定がある場合 NCache サーバー側のDockerコンテナでは、これを使用できます。
次に、展開オプションに関する詳細についても説明します。 インストールするだけです NCache サーバー部分では、Azureのリリースを私たちの側から取得します。 これはサーバーのみのリリースであり、アプリケーションにNuGetパッケージを装備させる必要があります NCache それは、サポートチームや営業チームからも入手できるものです。 だから、それは公に利用できないものです。 これは意図的なものですが、リクエストするだけで、AzureとNuGetパッケージのリリースが提供されます。その後は、単一サイトのセットアップまたはマルチサイトのセットアップが必要なのはネットワークの一部です。 通常、単一サイトをお勧めします。その場合、ポイント間通信が必要であり、マルチサイトではサイト間通信が必要です。
これでプレゼンテーションは完了です。