携帯コンテンツ変換ASP：プロキシ型の２URLとドコモ無変換の問題

プロキシ型携帯コンテンツ変換ASPでは、２つのURLが存在します。１つは元のコンテンツのあるWebサーバで、もう1つが変換プロキシサーバです。多くの場合、まず本当のURLを持っているコンテンツサーバにアクセスし、au/softbankの時は変換サーバにリダイレクトされます。そして、この事がこの方式の問題となるケースがあります。

プロキシ型変換ASPの場合には、本当のアプリケーションのあるサーバとプロキシサーバの両方がインターネットに出ているために２つのURLが存在します。また、コンテンツがドコモ端末基準で作られているため、一般にドコモ端末からのアクセスはコンテンツ変換サーバを通しません。このことは３つの点で有利です。

1. 最大シェアのドコモが通過しないので、顧客企業はその分従量コストが節約できる
2. ドコモ端末のパフォーマンス劣化が起きない
3. ASPシステムキャパシティを節約できる

ところが、本来同じURLで使いたいコンテンツに、物理的にも離れている２つURLを使ってアクセスするとややこしい問題も出てきます。以下に一例を挙げます。

• テスト環境をどうやって構築するのか？
• SSLドメインの設定はどこにするのか？
• 公表するURLを維持するためにDNSをどのように設定すべきか？
• SEO対策できるURLはどこになるか？

こうした問題は一度乗り越えれば、運用中は問題が大きくなることはないのですが、実際には課金方法と相まって問題が大きく複雑化していきます。これはASP課金体系がサイトやドメイン単位だったり、基本料金を過ぎて従量課金領域になると、auやソフトバンクでも通さなくてもよいページは通さない、ということにするからです。つまり、追加料金を発生させない、もしくは軽減するための努力をサイトの修正毎に行うことになったりします。

その結果、コンテンツ毎に変換の使用が複雑に入り混じることになります。変換プロキシの使用/不使用はURLに影響を与え、アプリケーション自体にも影響を与え、サイト全体を複雑なアクセスパスにしてしまいます。

一方、ラウンドアバウトホスティングであれば、１つのコンテンツについて常にURLは１つであり、大きなコストを掛けることなく複数のコンテンツ毎に別のURLを持つこともできます。固定料金であるため、大量のアクセスがあっても料金を気にする必要もありません。システム特性及び課金体系両面から、プロキシ型の持つ問題を心配する必要がありません。