Windows Azureクラウドサービス再入門の続きをお届けしていきたいと思います。
当初の予定では「ServiceDefinition.csdefとServiceConfiguration.cscfg」に関してお届けする予定でしたが、予定を変更してお送りします。
といいますのも、いくつかの連携方法をご紹介しながらも、「どれを利用したらよいのか？」を全く説明していなかった・・・という反省に基づき、流れ的に「今でしょ！」という状況でしたので、ここでご紹介させていただくことにしました。
-
レスポンスタイムとスケーラビリティの相反関係
クラウドサービスは基本的にスケールアウトによりスケーラビリティを確保するアーキテクチャモデルです。
負荷に応じてインスタンス数を増やし、スケーラビリティを確保することが基本的な対応となります。
仮想マシンなどでは実行中にインスタンスサイズを変更することが可能ですが、クラウドサービスは実行中にインスタンスサイズを変更することができないため、実質的にスケールアウトOnlyのスケーリングとなります。
そのため、WebロールとWorkerロールを連携させる場合は、スケールアウトを許容するために双方の結合を疎結合にしておく必要があります。
しかし、リアルタイム性を要求する場合において疎結合による連携の許容が難しいケースもあります。この場合は、WCF による直接的なコネクションを採用することでリアルタイム性を確保することで回避可能ですが、スケーラビリティを犠牲にすることになります。
このように、クラウドサービスの適用においてレスポンスタイム(リアルタイム性)とスケーラビリティに相反関係が存在していることがわかります。それでは、利用可能な連携手段とレスポンスタイム＆スケーラビリティの関係を見てみましょう。
接続手段
スケーラビリティ
リアルタイム性
キューサービス
◎
△
サービス バス
◎
△
WCF（TCP）
△
◎
評価基準はあくまで私見ですので、いろいろと議論の余地はあるかと思います。
しかしながら、WCFサービスを利用する場合、ある程度のスケーラビリティを犠牲にする必要があることには異論はないかと思います。
また、キュー サービスとサービス バスが同評価になっておりますが、両者の差別化には違った評価軸が必要となるため、スケーラビリティとリアルタイム性のみの評価軸では同列としています。
それでは、それぞれのケースにおいて採用すべきアーキテクチャについて解説していきましょう。 -
スケーラビリティを重視する際に採用すべきアーキテクチャ
スケーラビリティを重視する場合、WebロールとWorkerロールのワークロードを分離することが肝要になってきます。
Webロールのトラフィックが逼迫している事態をWorkerロールに波及させるのは良いデザインではありません。
逆に、Workerロールがバックエンド処理によりCPU利用率100%近辺でフル稼働している状況下においても、その状態がWebロールの実行に影響を与えるべきではないことも自明でしょう。
そこで、Webロール & Workerロールを疎結合で連携させるというソリューションに到達するのは容易に想像できることと思います。
それでは、疎結合の連携をどのように実現させればよいでしょう？
先に、2種類の手段を挙げてしまっておりますので、どのようにも何もありませんが、2種類の手段の適用をそれぞれ考えていきたいと思います。
もちろん、サードパーティによる同様のサービスや他のクラウドベンダによる類似サービスもありますが、レイテンシーやコストを勘案すると、キューサービスまたはサービス バス(Queue) の2択に落ち着くでしょう。
それぞれ類似のサービスですが、実は両者には明確な違いがあります。
まず、この比較をする前にCAP定理の話をしなければなりません。
実は両者にはCAP定理におけるC(一貫性)およびA(可用性)のどちらに重きを置いているかに違いがあるように見受けられます。
一貫性に重きを置いているサービスは、サービス バス(Queue)になるでしょう。
サービスバスはトランザクショナルなメッセージングをサポートしており、送信されたメッセージは確実に受信者に届けることが可能です。
しかし、Queueサイズが最大5GBであったり同時に100接続以下であったりと可用性(ここでいう可用性はいつでもリクエストを受け付けてくれるかということ)に制約があります。
一方、キューサービスはメッセージが確実に送達されることが保証されていない代わりに、無制限にメッセージをポストできるなど可用性を重視した構造になっています。（Queueはストレージサービスの1種であるため、3重化による冗長化や同時接続数5,000以下をサポート）
そのため、どちらを選択するかは一貫性を重視するか可用性を重視するかが判断基準になってくるでしょう。
エンタープライズ向けのサービスのように、一貫性を重視したい場合にはサービス バスを利用するとよいでしょうし、ソーシャル向けやキャンペーンサイトの応募受付のように「祭が来ても落ちないぞ！」というサービスを実現したい場合には、キューサービスを使う・・・などというシナリオが考えられます。
また、双方を組み合わせた構成も可能でしょう。
たとえば、まずはリクエストを一旦受け付けておき、ディスパッチャが優先度などを加味して複数のサービス バスにリクエストを振り分けるようなケースを考えてみましょう。
まずは、可用性重視のキューサービスでリクエストを受信し、受信したリクエストは各サービスに確実に転送する。
こうすることで、可用性を確保しつつ一定の制約のもとで一貫性も維持することが可能になります。
ほんの一例ではありますが、こんなアイディアもあります。
スペースの関係で、今回はスケーラビリティ重視のケースをご紹介しました。
次回は、リアルタイム性を重視するアーキテクチャを考えてみたいと思います。
Comments are closed here.