シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。

Azure上で動くWebサービス「スワップスクエア」の構築方法

»

 スワップスクエア。聞いたことがない言葉だと思うが、これは前回のコラムで私が紹介した、Microsoftのクラウド、Azure上に私が構築した書籍管理・物々交換のWebサービスである。

 ということで、前回予告したように、本システムについて、技術的に突っ込んで中身を説明してみる。

Azureに関して

 スワップスクエアはクラウドに乗せたシステムだが、実際のアプリジェーションは普通のウェブアプリケーションと基本的に何も変わらない。ASP.NET MVC3+JQuery+NHibernate+SQL Serverで普通にWebアプリケーションを作っている。マイクロソフトの「既存のWeb applicationを容易にAzureに移せるようにする」という方針の賜物だろう。普通、クラウドとくれば、Relational DBを使わずに作るらしいが、AzureはMicrosoftのRelational DBである、SQL Serverをサポートしている。ということで、現状はAzure特有の機能を一切使っていない。しかし、将来使用を考えているものに以下が有る。これらは、基本的にスケーラビリティーが重要になって来る段階で、必要になってくるものと判断している。

構成情報の格納場所を今までのWeb.configから、ServiceDefinition.csdfとServiceConfiguration.cscfgに移す。

 クラウドの大きなメリットの1つとして、Webサーバ数や、ワークロードを処理するサーバ数を簡単に変更できることがある。Azureではサーバ数を自動制御するためのAPIが公開されており、時間帯に応じてサーバ数を自動的に変えることや、実際の負荷をアプリケーション自体が『感じて』サーバ数を変えるようにすることも可能だ。そうやって変えるサーバ数だが、サイトにアクセスするユーザーが大きなものになると、5~10個と増えていくものだと思う。その時、構成情報がWeb.configにあるままだと、サーバ一毎にコピーを載せなければならないうえ、有効にするためにはWebのプロセスを再起動しなければいけないため、メンテナンス工数が大きなものになる。ところが、AzureがサポートするServiceDefinitoin.csdfとServiceConfiguration.cscfgを使うと、すべてのサーバに一斉に、しかもダイナミック、つまりWebのプロセスを再起動することなく変更できる。SeriviceDefintion.csdfとServiceConfiguration.cscfgの違いだ。ServiceDefinition.csdfは、どういう構成情報があるかという構成情報のメタ情報だ。SeriviceConfiguration.cscfgには、実際の構成情報が入る。

セッション情報の格納場所を、Blob storageに移す。

 Azureでも、InProcのセッション、つまりサーバのメモリ上にセッション情報を格納する方式はサポートされる。しかし普通のWebサーバでクラスタを作るときに使われる、StateServer(セッション情報の格納用に特別のサーバを準備)や、SQL Server(SQL Server上にセッション情報を保存)はサポートされない。そこで、Azureで複数のWeb Serverを使う時までに、セッション情報を複数のサーバでシェアする仕組みが必要になってくる。現状、それはBlob storage上に用意するらしい。スワップスクエアでは、セッション管理は1つの独立したクラスで実装しているので、そのクラスを入れ替えるだけで、セッション情報の格納場所を変えることができる

データをTable Storageに移す。

 Relational DBの欠点はスケーラビリティの低さだ、サイトの負荷が増えて、DBの能力の増強が必要になった時に、できることは限られてくる。1つは、単純にDBが乗るサーバの性能を上げること。もう1つは、DBに乗せるデータを分割し、複数台のDBサーバで処理ができるようにすること。最初のオプションは簡単だが、コストの問題がある。また、サーバの性能をあげると言っても、それには限界がある。2番目のソリューションはアプリケーションの構造自体を変える必要があり、難易度が高い。

 そこで、一般に高いスケーラビリティが前提のクラウドコンピューティングでは、Relational DBは使われない傾向にある。その代わりに使うのが、Table storageだ。実際、スワップスクエアがSQL ServerからTable storageに代えないと立ちいけない状態までに負荷が大きくなるのが、いつになるのか分からないが、その時は、多分それほど大きな変更なくTablle Storage使用に切り替えることができると思う。ApplicationのアーキテクチャでDBアクセス層がRepository patternを使いきれいに分離できているからだ。

Azureの課金について

 他のShared Hostingの費用と比較して、格段に値が張る。現在使っているのが、S(Small)インスタンスという、1,6GHzのSingle coreのサーバで、通常価格が$0.12/Hour。1カ月使い続けるとして、 $87/Month。それとは別に、データ転送、Storage、そしてSQL Serverなども別料金で課金される。合わせると、多分$100/Monthを超えるだろう。少なくとも今の段階のスワップスクエアは趣味レベルで、収入はゼロ。とても、この額は払えない。

 それでも、今回Azureに乗せることにしたのは、パソナテックなどがやっている、6カ月分の使用料のキャッシュバックキャンペーンがあったからだ。マイクロソフト自体も全世界的にキャンペーンをやっている最中で、今年の9月30日まで無料というパッケージもあるが、それはコンピューティングインスタンスがXS(Extra small)と小さい。実際それも試したが、とても実用的な性能を出せるものではなかった。

 ということで、少なくとも6カ月間はAzure上で運用することにした。そして、もし6カ月後、収益が出る状態になっていれば、そのままAuzreを使う。その場合、性能アップの必要性も高まっているはずだ。しかし、収益が出るほどまでユーザー数が増えていなければ、つまり性能を早急に上げる必要がないと判断されれば、6カ月後は、他のHosting Serviceが提供する環境に移すことを考えている。

 $100/Monthの金額、つまり月1万円以下。企業ユーザーなら、課長さんのレベルの判断で決定できるぐらいの額だ。しかも、その額、自分でサーバを立ち上げて、ネット接続環境をと唱えるのにかかる費用と比較して、確かに安いのだろう。しかし、私のように『趣味の開発から、あわよくば大規模サイト』と考えている向きには少し高すぎる。

スワップスクエアが使う外部インターフェイス

 次にスワップスクエアの作りについて少し。プログラムのアーキテクチャや構造を説明すると、長くなるので、アマゾンのWeb serviceと、本に印刷されているISBN情報のバーコードを読み取ってくれる、Katanshiバーコードリーダについて書く。

アマゾンのWeb service

 スワップスクエアでは、書籍の情報はアマゾンが提供するWeb serviceの1つ、“Product Advertize API”を利用している。これを使い、ISBNコードを入力して直接アマゾンから書籍情報を取得して、その情報をスワップスクエアに登録するか、それともキーワードから検索してヒットする書籍の中から該当するものを選択して、それを登録するかのどちらかが可能だ。

 スワップスクエアの収益源の一部として期待しているものに、アマゾンのアフィリエイトがある。Webサイトからアマゾン上の商品へのリンクを貼り、そのリンクからアマゾン上の商品の購入に至った時、売上の何パーセントかが、報酬としてアマゾンから提供されるのが、アフィリエイトだ。それを実現するためにはリンクに、リンク元の情報が含まれていないと行けない。Product APIで取得するリンクにはその情報が含まれており、スワップスクエアからアマゾンへのリンクにはすべてそのリンクを使用している。結果、スワップスクエア経由でアマゾンに至り、そこからアマゾンでの商品購入に至ったユーザーが増えると、アフィリエイトの収益が増えることになる。実際どのくらいの収益になるのか。そこら辺りは、まだ分かっていない。多分、それほど期待できないだろう。

Katanshi バーコードリーダ

 スワップスクエアを作るか否か迷っていた時、一番の課題だったのが、ISBNコードを入力する手間だった。ISBNコードを手入力しなければいけないようでは、手間がかかり過ぎる。そこで、ユーザーに市販のバーコードリーダを購入してもらい、それを使ってISBNコードを入れてもらうことを考慮した。しかし、普通には簡単には手に入らないバーコードリーダを、普通のユーザーが気軽に手に入れてくれるかと思うとそれも疑問があった。

 そして、もしかしたらウェブカムからバーコードの画像情報を読み取って、それからバーコードを出力してくれるソフトウェアがあるのではないかと思い、ネット上のいくつかのソフトを試した。ほとんどは反応が遅すぎるなど、とても実用的に使えるものはなかった。そんな時に、見つけたのがこのKatanshiバーコードリーダ。Far East Russia(極東ロシア)に会社があるらしい。ウラジオストックか、ナホトカか? と思いを馳せたが、そんなことはどうでもいい。実に素早く正確にバーコードを読みとってくれる。しかも無料。ということで、Katanshiのお陰で問題をクリア。開発をスタートさせることができた。

Comment(2)

コメント

スワップスクエアですが、私の方で、Azureの課金に関して勘違いがあったため、7月3日までですが、24時間稼働できません。7月3日までは、平日は19:00-25:00 ぐらい。土日は11:00-25:00ぐらいで運用します。今のところほとんどアクセスがありませんので、問題はあまりにないと思いますが、もしアクセスしようとして、できなかったら、そういう理由です。東電ではありませんが、「計画停止」でし。東電と違って、かなりの確実で停止させます。

7/3、本日より、再び24時間稼働させます。よろしく。

コメントを投稿する