WebロールとWorkerロールの連携手段の選択とアーキテクチャ(続き)

2013年6月24日 | By TatsuakiSakai | Filed in: Micosoft Azure.

このシリーズも随分御無沙汰してしまいました。

Windows Azureに関するビッグニュースが続いたこともあって、そちらを優先的にお伝えしてきた・・・という言い訳をしておきます(^^ゞ

さて、前回、WebロールとWorkerロールの疎結合連携に関して書かせていただきました。

今回は、密結合連携に関して記述したいと思います。

密結合連携は本来、スケーラビリティの面からあまりお勧めしたくない手段ではあります。

しかしながら、リアルタイム性を重視する場合においては、ある程度スケーラビリティを犠牲にしてでも密結合を利用しなければならない場合も存在します。

実際、プロジェクトの現場ではこの密結合連携を使う場面に多く遭遇します。

この場合、WebロールとWorkerロールの連携、またはWorkerロール間の連携にWCFなどを用います。

また、リアルタイム性を重視した密結合の連携の中にも複数のパターンが存在し、それぞれの場面において使い分けることができます。

これは、クラウドサービスで利用可能なエンドポイント形式に起因するもので、ロードバランサを経由してエンドポイントにアクセスするか、ロードバランサを経由せずにダイレクトに各インスタンスのエンドポイントにアクセスするかのいずれかです。

これら2種類のパターンについてそれぞれ考えていきましょう。

  1. ロードバランサを経由したコミュニケーション

    WebロールおよびWorkerロールで外部に後悔することを前提としたエンドポイントにInputエンドポイントがあります。

    この形式のエンドポイントを指定することで、ロードバランサが有効となり、各インスタンスへリクエストが振り分けられます。この方式の特徴は、密結合でありながらロードバランサによる負荷分散が有効となるため、スケールアウトのメリットを享受することが可能です。

    しかしながら、Webロールからリクエストが発行され、Workerロールでリクエストを処理している際の遅延がWebロールにも波及するため、WebロールとWorkerロールのワークロードを確実に分離することができません。

    そのため、WebロールおよびWorkerロールに責務を分離する意味が薄れてしまいます。

    しかしながら、ワークロードの分離よりも、ユーザに対する応答性を重視する場合などにこのパターンを採用するケースが考えられます。

    ある程度ピーク時のトラフィックが見積れるような状況であれば、応答性を重視するこのデザインも有効であるといえます。

     

  2. インスタンスへの直接的なコミュニケーション

    同一のクラウドサービスに属する各インスタンスがロードバランサを介することなく特定のインスタンスと直接的にコミュニケーションするためのエンドポイントがクラウドサービスでは提供されています。それがInternalエンドポイントです、また、リモートデスクトップ接続のように、外部からロードバランサを介することなく、直接特定のインスタンスに接続する場合に利用するためのInstanceInputエンドポイントがあります。

    これらインスタンスに対する直接的なコミュニケーションが可能なエンドポイントは、スケーラビリティ確保を最も重要なソリューションとしない場合に限定して利用することをお勧めします。

    たとえば、外部の監視サービスが、各インスタンスの死活状況を一転間隔毎にInstanceInputエンドポイント経由で問い合わせる場合などの利用が想定できます。

    また、クラウドサービスでゲートキーパーデザインパターンを採用し、よりセキュアなWebアプリケーションをクラウドサービスで実現するような場合に、Webロールの1インスタンスとWorkerロールの1インスタンスをInternalエンドポイントで紐づけ、一体として実行させるような場合に適用することが想定されます。

    このように、スケーラビリティよりもセキュリティや可用性(ここでいう可用性はダウンしていないということ)を重視する場合に、このデザインが有効であるといえます。

     

このように、TCPエンドポイントを利用した直接的なコミュニケーションを適宜使い分けることで応答性の向上やセキュリティ確保などといったスケーラビリティ確保以外の要件にも対応できるようになります。

こうした柔軟なアーキテクチャデザインを採用できる点が、Windows Azureクラウドサービスの強みであります。

特に大量のリクエストを処理したり重要なデータを取り扱ったりする際にクラウドサービスが選択されているのはこうしたアーキテクチャの柔軟性に起因しているといえます。

クラウドサービスが登場してから3年以上経過し、ようやく仕様も安定化してきた感があります。

個人的には、日本へのリージョン追加やIaaS型サービスの提供との相乗効果で、よりクラウドサービスを採用したアプリケーションの開発が増えるのではないかと期待しています。

当初予定していた内容と少々変わってしまいましたが、全8回ということで一旦このシリーズを完結したいと思います。


Comments are closed here.