0

Azure クラウド サービスを使用したエンタープライズ アプリケーションの設計に関していくつか質問があります。

バックストーリー

SQL バックエンド上の約 12 個の WCF Windows サービスで構成されたシステムがあります。現在、約 10 のクライアントがありますが、システムのスループット要求がおそらく 100 倍に増加し、100 に成長する可能性があると予想しています。現在のシステムは設計が不十分で、単純にスケーリングできません。そのため、Azure プラットフォームでリエンジニアリングを行うのに適切な時期であると思われます。

プロセスフロー

簡略化した一連のサービスとプロセス フローについて簡単に説明した後、Azure クラウド サービスを利用して新しいシステムを構築することに関していくつかの質問をさせてください。

サービス A は外部システムにログオンし、データを継続的にダウンロードします

サービス B は 2 番目の外部システムにログオンし、データを継続的にダウンロードします

サービス A と B のそれぞれにログインできるインスタンスは 1 つだけです。

A と B の両方が、2 つの外部ソースからのデータを調整するサービス C にデータを渡します。

検証および調整されたデータは、C からサービス D に渡され、サービス D はいくつかのアカウンティング機能を実行してから、結果のデータをサービス E および F に渡します。

サービス E は継続的に外部システムにログインし、データをアップロードします。

サービス F はレポートを生成し、FTP などを介してクライアントに公開します

システムは実際にはこれよりもはるかに複雑ですが、上記は関連するプロセスを示しています。システムは 1 日 24 時間、週 6 日稼動しています。キューは、すべてのサービス間でメッセージをバッファリングするために使用されます。

Azure 永続 VM を使用してこのシステムを構築し、サービス バスやキューなどを利用することもできますが、それは垂直スケーリング戦略に結びついてしまいます。次の質問が与えられた場合、どのようにクラウド サービスを利用して実装できますか。

質問

  1. サービス A、B、および E が外部システムに永続的にログインしている場合、それぞれのアクティブなインスタンスは 1 つしか存在できません。これらを単一インスタンスのワーカー ロールとして実装すると、ダウンタイムとパッチ適用の問題が発生します (これは容認できません)。それぞれのインスタンスを 2 つ作成した場合、Azure でワーカー ロールを使用してアクティブ/パッシブ負荷分散を実装する標準的な方法はありますか?それとも、独自のロード バランサーを構築する必要がありますか? 私が考えていなかったこの問題に対する別の解決策はありますか?

  2. サービス C と D は、複数の worker ロール インスタンスを使用してスケーリングするのに適した候補です。ただし、各インスタンスは関連データを処理する必要があります。たとえば、それぞれが 5 つの個別のクライアントのデータを処理する 4 つのインスタンスを持つことができます。各インスタンスによってグループ (クライアント中心) で処理されるメッセージを取得するにはどうすればよいでしょうか? また、パッチ適用が行われる場合などに、1 つのインスタンスから残りのインスタンスに負荷をどのように再配分するか。たとえば、5 つのクライアントのデータを処理するインスタンス 1 が OS パッチ適用のためにダウンした場合、そのクライアントのデータは次のようにする必要があります。再起動するまで、残りのインスタンスによって処理されます。同様に、追加のワーカー ロールをスピンアップすることにした場合、どのように負荷を再分散できますか?

あなたが提供できる洞察や提案は大歓迎です。

マット

4

2 に答える 2

0

まず、ステップをバックアップします。Windows Azureのアプリケーションアーキテクチャを検討するときに最初に行うことの1つは、そのアプリがWindowsAzureへの移行に適しているかどうかを確認することです。特に、アプリケーションでの統合の程度に注目します。クラウドで統合を行う場合、統合は常に予想よりも困難です。ほとんどのワークロードを単一の常時接続で実行する必要がある場合は、クラウドに頼る可用性とスケーラビリティを得るのに苦労します。

アプリケーションの詳細を知らなくても、例として、サービスAとBが金融データプロバイダーからのフィードであると想定します。データフィードのプロバイダーは、その機能に非常に優れており、可用性が高く、エンタープライズグレードのコストに対して「エンタープライズグレード」(それが意味するものは何でも)を提供します。それらのアーキテクチャも古いものであり、場合によっては非常に堅固です。したがって、最初に、フィードプロバイダー(ログイン/接続を提供し、データをプルすることを期待します)にWebサービスを介してデータをプッシュするように依頼することを検討してください。公開されたWebサービスは、スケーリングとパフォーマンスのソリューションであり、AzureのテーブルストレージからDynamoDBのような高スループットのデータベースサービスまで使用されます。(私は、Amazon S3のようなサービスがどのようにミッキーマウスであるかを説明するために、エンタープライズデータプロバイダーに挑戦します。

あなたが発見しているように、あなたの代替案は、あなたのアーキテクチャがあなたのデータ供給者の単一ノードモデルに適合することを確実にするためにたくさんのものを構築することです。それは可能ですが、分散コンピューティングの原則をすべて手作業で実行するために、多くのエンジニアリング資金を費やすことになります。アクティブ-パッシブアーキテクチャを使用する場合は、パッシブノードがいつアクティブになるかを決定するためにリーダー選出アルゴリズムを実装する必要があります。これは、アクティブノードが消えたように見えるかもしれないが、まだ処理中であるように聞こえるほど簡単ではありません。その場所に別のノードをスロットする必要はありません。したがって、ハートビートを実装するか、ノードについて何かを行うためにどのノードが稼働しているかを監視する以外に何もしない別の「監視」ノードを実装します。ダウンタイムとパッチ適用は許容できないとおっしゃっています。では、何が許容できるのでしょうか?数分または数秒、または1秒未満ですか?パッシブノードが他のノードが中断したところから引き継ぐようにしますか、それとも再開しますか?

これらすべてを実装するための開発コストは、高可用性の物理サーバーを構築してホストするコストよりも低いことがわかるでしょう。おそらく、負荷を分離して、物理ボックス上のco-loでデータフィードサービスを実行し、WindowsAzureで処理を大幅に強化することができます。Azure VMは、役割ほどリサイクルされませんが、少なくともエンタープライズグレードのハードウェアよりも問題が発生する可能性があるため、私はAzureVMを見ることさえしません。データフィードのサプライヤとの話し合いから始めます。ソリューションがある場合もあれば、一緒に石畳にすることができる場合もあります(たとえば、1つの価格で2つのログインがあり、「2番目の」アカウント/インスタンスはほとんどの場合データを破棄します)。

従来のエンタープライズ統合には十分注意してください。彼らは、今日のクラウド指向の世界では奇妙に見えることを求めています。たとえば、発信サービスに固定IPアドレスを指定するように要求されました。他の人のアーキテクチャを回避するために作成する必要のあるコードは、物理サーバーの購入に費やしたほうがよい場合があります。データプロバイダーを押し戻す—90年代から抜け出す時が来ました。

[免責事項]「企業」、特に金融サービスを利用している企業は、要件が特別であると言い続けています。つまり、スループット、セキュリティ、規制、可用性の向上です。非常に少数のケース(高頻度取引など)を除いて、私はこれのほとんどで「ブル」と呼ぶ傾向があります。彼らは、多額のIT予算と、豪華なランチに連れて行く高価なキットのベンダーの影響を受けており、サーバーを抱き締める信念に教え込まれています。エンタープライズハードウェア/ソフトウェア/サービスビジネスに関する私の個人的な見解は、この答えに影響を与えました。あなたのマイレージは異なる場合があります。

于 2013-03-11T14:45:51.433 に答える
0

質問 #1: 独自の負荷分散を実装する必要があります。外部システムへの接続をアクティブに保ちながら、Blob Storage Lease 機能を使用して、1 つのインスタンスからストレージ内の一部の BLOB にミューテックスを保持できるため、これはそれほど複雑ではありません。接続がまだアクティブで成功していることがわかっている場合は、X 期間ごとにリースを更新できます。ロール内の他のすべてのワーカーは、そのリースをチェックして、期限切れかどうかを確認できます。有効期限が切れると、次のワーカーが飛び込んでリースを取得し、外部ソースへの接続を開きます。

質問 #2: Azure Service Bus を調べてください。クライアントが関連メッセージを処理できるようにする機能があります。詳細はこちら: http://geekswithblogs.net/asmith/archive/2012/04/02/149176.aspx すべてのキューイング方法論は、メッセージが取得されても、構成可能な時間内に処理されない場合は、次に利用可能なインスタンスがそれを取得して処理できるように、キューに戻します

AzureWatchなどを使用して、キュー (ストレージまたはサービス バス) の深さを監視し、C ロールと D ロールのインスタンス数を一致するように自動スケーリングできます。ロール A、B、E のインスタンス ステータスを監視して、正常なインスタンスが常にそこにあることを確認し、準備ができているインスタンスの数が 0 になった場合は自動スケーリングします。

HTH

于 2013-03-11T04:29:47.103 に答える