当ブログは移行しました。

http://www.symmetric.co.jp/blogに移行しました。
5秒後に自動的に移動します。
移動しない場合はこちらをクリックしてください。

携帯コンテンツ変換の選定基準:ネットワーク設計とセッション

携帯コンテンツ変換を選定する際、重要なポイントの1つは製品自体がセッションを使う処理をするかどうかです。携帯コンテンツ変換製品がセッションを使う機能がある場合、ネットワーク設計に大きな制約が生じます。セッションを使用する代表的な機能が、「ページ分割」と「クッキーエミュレーション」です。

セッションを使うと次のような制約が発生します。

  • アクセス端末は常に同じ特定変換サーバを通過する必要がある
  • このため単純なラウンドロビンが使用できず、パラメータ等による振分けが必要となる
  • アプリケーションもセッションを利用し、特定サーバでの処理を要求する場合がある
  • この時、1つの携帯からは特定変換サーバと特定Webサーバを通過するように、ネットワーク設計しなくてはならない。
そこで3つのサーバ構成が考えられます。

セッションありサーバ型の構成及びアクセスルート



左図は2段にロードバランサを配置する構成は、もっとも素直な構成です。しかし、複雑な設定を必要とし、ローバランサを2段にすることでコストが格段に高くなってしまいます。

中央の図は変換サーバが特定のWebサーバとだけ通信することでアクセスルートを固定しています。この場合の問題点は、Webサーバに障害が起きてもフェールオーバされない点です。

右図は変換サーバを1台にしてアクセスルートを固定し、ダウンした時にはスタンバイ機でフェールオーバします。問題はローバランサが2段となりコスト高である点とフロントにボトルネックが発生する点です。

3つの設計を考えると、セッションが繋がっている場合にはどれもうまく動きますが、アプリケーションのセッション同様に何らかの原因でセッションが切れてしまった場合のことを考えておかないといけません。アプリケーションの場合にはセッション切れを検知すれば、それに対応する動きを構築することができます。しかし、ネットワークの中間に位置する変換サーバは、セッションが切れていることを検知することもできず、検知できたとしても何もすることができません。変換サーバはいつまでも無駄なセッション情報を持ち続けてしまいます。中間サーバーでセッションを使うということは、本質的に問題があると言ってもよいでしょう。

セッションがを極力切れないようにするためには、必然的に右図の変換サーバが1つの形態に落ち着きます。コスト的にも1番低く済ますことができます。

ラウンドアバウトの設計方針はセッションレス動作であり、セッションを一切使いません。どんな機能もセッションを使わない設計に腐心しています。セッションレスには、次のようなメリットがあります。
  • ロードバランサに特殊な設定をすることなく、単純なラウンドロビンが利用できる
  • サーバリソースを無駄なく使える
  • フロントにボトルネックが一切発生しない
  • ロードバランサは1段であり、コストが安い
セッションレスの場合のアクセスルート


携帯コンテンツ変換はセッションレスで動作することが望ましいと言えます。これが先に記述した、ページ分割機能は問題があると書いた理由です。


製品サイト「製品比較:システム構成の比較」でもラウンドアバウトとサーバ型コンテンツ変換の構成比較を図解しています。

0 コメント:

コメントを投稿