昨日、デザインパターンの記事をアップしてから「もう少し補足した方がよかったかなぁ」と思うところがあり、この記事を書いております。
実は、デザインパターンのお話を進める前に、クラウドファースト時代のアーキテクチャに関して補足説明をした方が良いのでは、、、と思ったのです。
昨年北米で開催されたMicrosoft Tech・Edのセッションに面白いものがありましたので、これを紹介させてください。
Designing Cloud Architecturesというタイトルのセッションからわかる通り、「クラウドのアーキテクチャはこうデザインすべし！」と示唆に富んだ内容です。
Channel 9でセッション動画を見ることができますので、英語でOKという方はそちらも併せてどうぞ。
さて、このセッションで語られている「アーキテクチャデザイン時に考慮すべきこと」は以下の3点です。
・フェイルセーフ
クラウド上で実行されるサービスやアプリケーションは「落ちる」という前提でデザインする必要があります。これまで、オンプレミスで実行されるアプリケーションは「落ちる」ということは異常事態として扱ってきました。しかし、物理的に離れた場所に分散して配置されるクラウドファーストのアプリケーションやサービスはネットワークやハードウェア障害による停止は日常的に発生するものとして扱う必要があります。ハードウェアが壊れることとプリンタの用紙が切れることは同程度のイベントであると考えておくと良いかもしれません。いくらクラウドのSLAが99.95%であるからと言って、自身のサービスも99.95%のSLAでいいという訳ではありません。デザイン次第では、99.95%以上のSLAを保証することも可能なのです。
・スケール
良くある誤解として「クラウドはいくらでもスケールアウトすることが可能である」ということがあります。確かに、データセンターには桁違いのコンピューティングリソースが存在します。しかしながら、実際にはユーザが想定した負荷の範囲内でスケールを調整する必要があります。仮想マシンであれば、スケールアウトするためのインスタンスを停止状態で待機しておく必要がありますし、クラウドサービスでは負荷に応じてインスタンス数を適宜調整する必要があります。そのため、繁閑の差を十分に測定しながらスケーリングを決定しなければなりません。従来の場合は、ピーク時のスループット確保に必要なリソースを(最大値で)用意すればよかったところを、クラウドでは(コストメリットを出すために)負荷に応じて最適にリソースのサイズや数を調整する必要が生じます。この点が、これまでよりも難しいと思われる点でもあります。
・インテグレーション(統合)
クラウドに対する神話の1つとして語られるものの１つに「すべてをクラウド化してしまう」というものがあります。しかしながら、現実的にはクラウド化することが困難な状況を伴うのが大半のケースです。これは単純に技術的な制約によるものではなく、法規制や商習慣などに起因するものが多くあります。特に、日本においては個人情報保護法や商法などの法規制により海外にデータを保存することが許されない場合があります。こうした場合、永続化して情報を格納する部分とそれを一時的に利用する部分に分けて考える必要があります。これにも多くのトレードオフを伴うため、クラウド化に際しては慎重に検討する必要があります。また、オンプレミスで稼働中の他システムと連携するシナリオも考えられます。こうした場合、どのように連携すべきかを十分に検討する必要があります。
それでは、各考慮点についてより深く掘り下げて考えていきましょう。
フェイルセーフに対する考慮点
フェイルセーフに対するアプローチとして「冗長化」と「信頼性向上」があります。
ハードウェアは壊れるものですから、当然ながら冗長化による稼働率向上を図ることは、クラウドファーストなアーキテクチャにおいて重要な考慮点です。
Windows Azureでは、多くの冗長化アプローチが採用されていますので、これらのサービスを適用するだけで冗長化をすることも可能です。
たとえば、ストレージはローカル冗長及び地理冗長による冗長化を標準機能として提供しています。SQL データベースも標準で3重化されています。
このようにWindows Azureのサービスを活用するだけでもアプリケーションを冗長化することが可能です。
信頼性向上においても、Windows Azureは様々なサービスを提供しています。
たとえば、クラウドサービスにおけるインスタンス状態の監視機能です。一定時間間隔でPingを発行し、応答の無いインスタンスは停止～再起動を試みるといった自動修復が存在します。
また、クラウドサービスはマルチインスタンス構成することで、障害ドメインと更新ドメインを分け、単一障害点を除去するアプローチを採用しています。
仮想マシンにおいては可用性セットを構成することで、同様の機能を実現しています。
その他にも、アプリケーションレベルではIntelliTrace および様々な診断機能を活用し、開発の段階でアプリケーションの信頼性を向上することが可能ですし、障害発生時には一時的エラー処理アプリケーションブロックを利用してエラー処理を実行することで、耐障害性の高いアプリケーションを実現することができます。
また、この際に昨日紹介したHealth Endpoint Monitoringパターンを適用して監視を強化することも信頼性向上のためのアプローチです。
このように、フェイルセーフに対する考慮点はケース by ケースですが、一般的なプラクティスは導入可能です。どのプラクティスを導入するかはアーキテクトが決定しなければなりません。
フェイルセーフに対するプラクティスには、ほんの一例ですが以下のようなものがあります。
・Windows Azure の機能を活用する
ストレージの冗長化や障害ドメインなどの活用など
・単一障害点の除去
インスタンスやネットワークの多重化の検討など
・故障モード解析の実施
設計段階でFEMAなどを実施し、障害の影響度を事前に評価し、設計の品質自体を向上させる
・一時的エラー処理の活用
一時的エラー処理アプリケーションブロック(Transient Fault Handling Application Block)を利用したエラー処理の実現
・グレイスフル デグラデーション(IE6 & 7に対する制限等)
古い環境に合わせるのではなく、最新の環境に最適化し、古い環境には制約を設けるなどの考慮
・人的要因の排除(オペレーションミスの防止等)
確認ページの設置など
このようにしてフェイルセーフを除去することで、より安全なアプリケーションを実現することができます。
次回は、スケールに対する考慮点とインテグレーションに対する考慮点をご紹介したいと思います。
Comments are closed here.