スケーラビリティや可用性を重視するアプリケーションはクラウドへ

実際にクラウド用のアプリケーションを作る上でのポイントとして「スケーラビリティや可用性をできるだけ高め、なおかつ開発・本番環境の準備を短時間で済ませたい場合には非常に有効といえます。その一方で、2フェーズコミットなどのトランザクション整合性を重視するようなアプリケーションは、今のところクラウドに不向きといえるでしょう」と語る砂金氏。

クラウドに不向きな具体的としてはリアルタイム性の高いマスタや、集計表のUpdate処理を必要とするものなどが挙げられる。ただし、トランザクション単位をできるだけ小さくし、整合性の重視度を緩和した状態にカスタマイズすれば問題はないようだ。

また、商用サービスが開始されていない現時点ではいくつかの制約や注意事項も存在している。例えば、Windows Azure開発ポータルへのアクセスに必要なLive IDが、Windows Azure上に配置するプロジェクトと1対1の関係になっていることだ。個人でアプリケーションを試作する場合はこれでも構わないが、複数人で1つのアプリケーションを作ろうとすると問題が生じてくるだろう。そこで当座の回避策として、個人のLive IDではなく開発プロジェクト専用のLive IDを新規取得して使ってもらうという手段を挙げた。今後は1対nやn対nの関係に改善されるはずだが、現在のところ未定だという。

また、アプリケーションを開発する際はクライアント側の偽装環境でテストが行えるが、実際にはWindows Azure上にデプロイしなければ分からないことも存在する。そこで、砂金氏は「デバッグで最終的に頼れるのはプログラムコードから呼び出したログなので、デプロイやデバッグでクラウド上へ移す際にはログをしっかりと出力することが重要です」とアドバイスする。

最後に砂金氏は、SQL Azureをどのように活用するべきかについて「現在所有しているアプリケーションのデータアクセス部分をTABLEやBLOBなどに書き換えるのが手間ではない場合は、ぜひそのままクラウドのアプリケーションに移行してください。また、アプリケーションに手を加えたくない場合は無理にデータアクセス部分を書き換えず、SQL Azureへの移行をお勧めします」と語る。

ストレージを多く使うような処理が多い場合は、その領域から順番にKey ValueストアやBLOBへと置き換えていくようなアプリケーションの改変を行うと、非常にスムーズに進むそうだ。初期段階でSQL Azureを選択した場合、Key Valueストアを使うよりもランニングコストが若干高くなるが、BLOBやTABLEを使うたびに少しずつストレージのコストが下がっていく。こうした使い方をすれば、クラウド上へのアプリケーション移行に躊躇することもなくなるという。