なぜ、Windows Azure Platformを採用したのか

一方、Google App EngineやAmazon EC2など、さまざまなクラウド・プラットフォームが提供されている。その中で、今回Azureを採用したのは下記の理由からである。

  • マイクロソフト自身が提供しているプラットフォームなので、当然の事として既存の技術との互換性や親和性が高いだろう事を推測した事と共にそれに期待した事(実際に使ってみると細かな差異は様々あるが、それらは十分許容範囲内であった)
  • 上記を鑑み、特別な教育コストや教育期間などを必要とせず、既に筆者らが保有する技術・知識等を活用した、開発・運用が行えるだろう事を推測した事と共にそれに期待した事
  • データストアの選択肢としてSQL Serverと互換性があるといわれていた、SQLAzureサービスが提供されていた事
  • Googleは、.NET Frameworkを用いた開発が行えない事から候補から除外
  • Amazonは、Windows ServerをIaaSで提供している為、それに伴う様々な運用管理等の発生が予想された事から候補から除外
  • その他の"クラウド"と名付けられたサービス類は、既存のホスティングサービスとの差異が感じられなかった事から候補から除外

なぜ、SQL Azureサービス及びBLOBサービスを採用したのか(テーブルサービスは駄目?)

また、前段でAzure を採用した理由として、SQL Azureサービスの提供をあげたが、他にデータストアの選択肢としてAzure ストレージのBLOB及びテーブルサービスが存在する。その中で、SQL Azureサービス及びBLOBサービスを採用した理由は以下のとおりだ。

  • 通常の開発・運用においてSQL Serverを標準的に使用しているので採用に当たってリスクが相対的に低いと判断した事(筆者が行っている実際の運用については改めて紹介させて頂く)
  • SQL Azureサービスでは、作成できるDBサイズ(検討時は1GB又は10GBであった)に制限があるが、今回開発したシステムでは必要十分なサイズだと判断した事(現在は50GBまで作成可能。なお近い将来、水平分散等の機能強化で実質的なサイズ及びスケーラビリティが向上する模様である)
  • テーブルサービスではトランザクション数(大まかに言えば1回の読書毎)に応じた課金が発生するが、SQL Azureサービスにはトランザクションに対する課金は無い事
  • SQL AzureサービスのDBにも、SQL Server同様バイナリデータ(ファイルや画像など)を格納する事が可能であるが、その方式を採用した場合には明らかな容量不足が予測された事からバイナリデータ用のデータストアとして永続性のあるBLOBサービスが必要と判断した事(例えば、Webロール自体のローカルファイルシステムに保存すれば良いのでは? と思われるかも知れないが、システム修正等による再配置やAzure Platformバージョンアップ等に伴う再初期化[ReImage]等のタイミングで、全て初期化されてしまい永続性が確保できない。また、複数インスタンス(オンプレミス的に言えばそれぞれが違う物理サーバー相当)で実行した場合には、それぞれに分散してしまい整合性が取れなくなる)
  • テーブルサービスは事実上サイズが無制限と考えられるが、今回の案件ではそこまでのスケールは必要無いと判断した事。また、開発・運用方法等については全く未知数であり、採用するにあたっての相対的なリスクが高いと判断した事
  • これは筆者のリサーチ不足かも知れないが、テーブルサービスについては、SQL Azureのように手軽にデータ編集作業等を行えるツール類を見つける事が出来なかった事(実際の運用に当たっては、必ずアドホックなデータメンテナンス作業等が発生する物である。その都度、メンテナンス用のプログラム等を作成するのは手間もかかるし負担も大きい)

*　　*　　*

以上、今回はWindows Azure Platformの採用を決めるまでに行った検討の内容を簡単に紹介した。可能であればもう少し詳しく説明したかったが、所定の文字数をオーバーしてしまったため、今回はここまでとさせていただく。

理由を整理しただけではあったが、導入時に比較/検討した各種サービスやシステム形態についてまとめたので、参考にしていただけると思う。また、筆者とは要件の異なる案件に携わるITProにおいても、検討事項を整理する際などにご活用いただけたらうれしい。

次回は、今回の案件の開発・運用面を中心に、具体例を挙げて紹介していきたい。