負荷分散エンドポイント
ご存知のように、アプリケーションの要求を議論する仮想マシンは、特定のオープンポート（80、8080、443など）を介してこれを行います。 複数の仮想マシンがある場合、内部Microsoft Azureロードバランサーはこれらの仮想マシン間でトラフィックを分散します。 ゼロダウンタイムアップグレードでこの機能を使用する方法について考えてみましょう。
単一のクラウドサービス内に複数の仮想マシンがあるとします。 内部ロードバランサーは、1つのDNSのフレームワーク内、つまり1つのクラウドサービスのフレームワーク内でのみトラフィックを再分配することを思い出してください。
これらの仮想マシンにアプリケーションのバージョン1.0を使用させます。 タスクは、いつものように、ユーザーに見えないようにアプリケーションをバージョン1.1にアップグレードすることです。
負荷分散エンドポイントアプローチは、次のメカニズムを提供します。元のバージョンと同じポートと構成を使用して、既存のクラウドサービス内に追加の仮想マシンを展開します。 これを行う最も簡単な方法は、スケーリングを使用することです。 4台の2台の車があったとしましょう。これにより、更新中のアプリケーションパフォーマンスの低下も回避できます。
その後、クラウドサービスの一部として、仮想マシン上のアプリケーションのバージョンを次々と更新します。 当然、現在更新されている仮想マシンへのトラフィックのリダイレクトを回避するために、対応するポートを無効にする必要があります。 その後、内部ロードバランサーは、アプリケーションの古いバージョンと新しいバージョンの間でトラフィックの再分配を開始します。
たとえば、すべての仮想マシンを更新するか、4つの2つのうち2つを更新してから、古いバージョンのアプリケーションで不要な仮想マシンを単純に削除できます。 再び縮小してみましょう。
このアプローチの長所と短所を見てみましょう。
長所：
- シンプルなスケーリングプロセス
- IaaS展開のサポート
- アプリケーションの更新中にパフォーマンスの低下なし
- 追加の財務コストは、更新時にのみ必要です
短所：
- 更新プロセスは完全に手動であるか、自動化が必要です
- アップグレードプロセス中の追加費用
- 古いバージョンと新しいバージョンの仮想マシンの構成は一致する必要があります
- PaaS展開の一部としてのアプリケーションの更新はサポートされていません
ご覧のとおり、この方法はフォールト/更新ドメインを備えたトレーシングペーパーに近いものであり、Microsoftはこれを使用して、クラウドサービスまたは可用性セットの一部として複数の仮想マシンに99.95％SLAを提供します。 唯一の違いは、更新メカニズムを手動で実行するか、たとえばMicrosoft Azure Automationを使用して自動化する必要があることです。
したがって、この更新メカニズムは、IaaSの一部としてデプロイされたアプリケーションに実際に非常に適用可能です。
交通マネージャー
私たちが検討した以前の方法はすべて、アプリケーション展開の1つのアプローチのフレームワーク内でのみ使用するのに適しています。 ただし、論理的な問題が発生します。 PaaSとIaaSの両方の展開で使用できるツールは本当にありませんか？
本当にそのようなサービスがあり、Traffic Managerと呼ばれます。 特定のクラウドサービス用に内部ロードバランサーを構成することはできませんが、Traffic Managerはトラフィック分散を構成する機能を提供します。
異なる仮想マシン間だけでなくクラウドサービス間でもトラフィックを分散でき、この同じトラフィックを分散するアルゴリズムを決定できます。
そのため、Traffic Managerを使用するときにゼロダウンタイムアップグレードシナリオを実装するには、ユーザートラフィックを特定のクラウドサービスのDNSではなく、Traffic Managerプロファイルの作成時に決定されたDNSに誘導する必要があります。 {name} .trafficmanager.netのようになります。 もちろん、必要に応じて、名前レジストラの目的のCNAMEにバインドできます。
アプリケーションのバージョン1.0がprod.cloudapp.netクラウドサービス内でホストされているとします。 新しいバージョンでは、別のクラウドサービスを作成しています。 stage.cloudapp.netとしましょう。 新しいバージョンのアプリケーションをデプロイした後、トラフィックを古いバージョンのアプリケーションから新しいバージョンにリダイレクトできます。
したがって、すべてのトラフィックがアプリケーションの新しいバージョンに移動するとすぐに、古い環境を削除できます。
このアプローチの長所と短所を見てみましょう。
長所：
- 隔離されたテスト環境
- 仮想マシン、クラウドサービス、Microsoft Azure Webサイトのサポート
- アプリケーションの新しいバージョンと古いバージョンの仮想マシンの構成は異なる場合があります
- 必要に応じて、「すべてを元に戻す」機会があります
短所：
- Traffic Managerサービスの追加費用
- アップグレードプロセス中の追加費用
- 更新プロセスは完全に手動であるか、自動化が必要です
- ネームレジストラーのDNSキャッシュの更新には時間がかかります
説明したサービスには、前述のすべてのサービスよりもかなり深刻な利点がいくつかあります。 実稼働環境で使用することは完全に正当化されますが、使用する際の追加コストについて覚えておく必要があります。
Microsoft Azureプラットフォームに適用できるゼロダウンタイムアップグレードメカニズムについてお伝えしたかったのはこれだけです。 何かを見逃した可能性があります。 これについてのコメントで退会してください！
ご清聴ありがとうございました！