2009/03/14

サービス型アプリケーションは本当に危険か?

先のポスト「障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)」で今回の報道について、言いたいこともありますが、それは別の機会にと言いましたが、丁度良いタイミング(?)で[WSJ] Gmailでまたも障害発生 - ITmedia Newsしてくれました。

と言うことで、今回も、Gmailの障害をダシに、ちょっと違う話を。


どうも一般的に、GoogleのようなサービスやAmazon.com、Salesforce.comなどが提供しているサービスを使うことは、企業にとってリスクを伴うことも判明しつつある(ITmedia)と言って、イタズラに不安を煽る傾向があるようです。

サービスが危険であるという主張の裏にある理由を推測すると、
  1. 相手が信じられない (狭義のセキュリティ的に)
  2. 相手のデータ保護が信じられない (耐久性的に)
  3. 途中の通信が信じられない (可用性的に)
    があると思います。

    1.はどうでしょうか。
    故意または過失により情報漏洩等が発生した場合、社内情報部門と、サービス提供他社でどちらが強く責任を追及されて社会的制裁を受けるかと言うと、明らかにサービス提供他社でしょう。
    必然的に、セキュリティ確保に積極的になるのはサービス提供他社になるはずです。

    2.はどうかと言うと、
    データの耐久性をあげるには、データを冗長化する必要があります。
    災害対策ともなると、冗長化した情報の少なくとも1セットは遠隔地に保管する必要があります。
    一般的にこの冗長化はハードウェア、通信コスト、運用の人的コスト等、非常にコストがかさみます。
    システムの規模が巨大になれば、または、システムの重要度が金融の勘定系のようにクリティカルになれば、これらのコストが見合うかもしれません。 しかし、いくらメールシステムやCRMが重要であると言っても、ユーザ企業がデータの冗長化を徹底するのは困難かもしれません。
    それに対して、データの冗長化に関しては規模の経済が生かせるサービス型の方が有利と言えます。

    3つの理由のうち、合理性があるのは3.だけでしょう。
    システムの構成要素として、過去メール閲覧においてインターネットが追加になります。
    構成要素が増えれば、必然的に潜在的な障害ポイントが増えるので可用性の観点では絶対的に不利です。

    まとめると、インターネットを利用することによる可用性の低下のデメリットと、他の要因によるメリットを総合的に見て判断すべきでしょう。

    個人的には、インターネットを利用することによる可用性の低下を他のメリットが上回るので、積極的にサービス型のアプリケーションを使うべき、と思います。


    やや蛇足ですが、メールシステムの可用性について。

    今回の2回のGmail障害における障害ポイントはインターネットではなかったので、3.インターネットの可用性の問題には該当しません。
    また、メールの場合は元来インターネットからやってくる情報なので、MUAのサービス化に伴うリスクの増大は、MTAを含むメールシステム全体から見ると相対的に少ないものです。
    さらに言うなら、メールのようなコミュニケーションツール、すなわち相手あってのシステムの場合、個々のユーザにとってのシステム(MUA/MTA)の可用性が同じなら、起こる障害はみんな同時の方が良いはずです。
    自分のシステムだけ元気でも、相手のシステムが不調ならコミュニケーションできないことに代わりがありませんから。
    そういう意味でも、多数のユーザが同時に障害に巻き込まれるサービス型の方が有利のはずです(心情的には逆だと思いますが)。



    続けて、メールシステムのデータ耐久性(Durability)について。

    メールシステムを純粋にコミュニケーションツールとして捉えた場合、可用性が最も重要ですが、今やメールは記録システムになっているでしょう。
    この場合、可用性以上にデータ耐久性が重要です。
    自社システムのメールサーバ容量の制限から、個人PCのMUAにメールアーカイブを保存している場合と、サービス型のメールMUAを比較した場合のデータ耐久性のどちらが優れているかは、もう説明の必要は無いですよね。

    ホワイトデーは雨のち晴れ

    今日はホワイトデー。
    朝は大雨でしたが、かみさんとランチに出かけたときはあがっていました。
    夕方、運動不足解消のため散歩したときには、下のようなきれいな富士山が見えました。
    晴れたものの、春なのでかすんでいます。
    おかげで何ともやわらかい色の写真が撮れました。
    コントラスト検知式のコンデジオートフォーカスまでやわらかくなりましたが。(^^)

    2009/03/08

    Stainlessで同一サイト複数セッション!

    興味のある記事を見つけました。

    Chromeを超えた? 1タブ1プロセスのブラウザ最新版「Stainless 0.5」 | パソコン | マイコミジャーナル

    見出しによると、プロセスがタブごとに分かれていることが売りとなっています。
    Web/ブラウザがOSになったとか言われていますが、ある意味OSの備えるべき保護機能を普通に地味に実装したと言えます。

    これはこれで興味深いのですが、プロセス云々が非機能であるのに対し、
    私が注目したのはこちらです。
    Google Chromeを含む他のブラウザにない機能の例としては、異なるタブ/証明書を使い1つのサイトへ同時のログインを可能にする新機能「パラレルセッション機能」と、独自のcookie保管機構が挙げられた。
    Webアプリは最近少し触れるようになった初心者ですが、ちょうど興味を持っていたところにこのニュースでした。

    なぜこんなことが話題になるかと言うと、一重に、
    HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、(中略) ステートレスなプロトコルである(HTTP cookie - Wikipedia)
    からですね。
    これに対してクッキーが導入されブラウザ(プロトコル)がステートフルになったわけですが、こいつがブラウザグローバル。
    すなわち(URLでは区別されるが)ブラウザのウィンドウやタブ間で区別されないと言うことです。(IEには例外があるってほんと?)

    これがユーザにどういう影響を及ぼすかと言うと、タブやウィンドウを複数開いても、異なる複数のGoogleアカウントのGmailを同時に読むことが出来ない、と言うことになります。

    これに対して不満を持っている人も少なからずいるようです。

    例に挙げたGmailの通知機能限定ですがFirefoxの有名なアドオンにtLo : Gmail Managerと言うのがあり、複数アカウントのGmailの着信通知や未読件数表示が可能です。
    汎用的には、クッキーのセットをタブごとに変更できるアドオンにNektra.com > CookiePie FireFox/Flock/GNU IceWeasel Extensionがあります。(使ってみたところ今ひとつ安定しませんでしたが)
    同時ではありませんが、クッキーのセットお手軽に切り替える類似目的のアドオンにCookieSwap :: Firefox Add-onsなんていうのもあります。
    また、先の記事では否定されていたChromeですが、 プライベートブラウジング(incognito)機能は、オープンな私と慎重な私で多重ログインする機能と見ることも出来ます。

    まとめると、
    Web/ブラウザが一人前のOSになるには、
    複数のステートを管理出来ることが重要だが、
    これにはブラウザ側が何らかの対処が必要で、
    その一つの解がStainlessであり、
    その他アドオンも複数あります、
    ということのようです。


    ところで、これはブラウザだけの問題ではなく、クライアントをクッキー(とSSLセッション)だけで区別しているプロトコルの問題でもあるように思います。
    SSL通信路やCookieによる設定等の状態は共有したいが、案件毎にセッションを区別して管理したいとなると、とたんに破綻します(RESTfullに解決する方法はありそうだが)。


    これに対して、WebのOS化に熱心なGoogleあたりが何かしてくるような気もしますが...

    今後の動きに注目したいと思います。

    # Webアプリ初心者への突っ込み歓迎