Windows Azureの検討と採用
そして、SalesforceやAWSと並行して検討していたのが、当時正式リリースされたばかりのWindows Azureだ。
今さら説明するまでもないが、Windows AzureはPaaSプラットフォームであり、ハードウェアやOSに加えてアプリケーション開発基盤も含まれている。SaaSのSalesforceとIaaSのAWSのちょうど中間に位置するため、「アプリケーションに注力」しつつも「ある程度の信頼性と拡張性を持った基盤」を求める本プロジェクトとしては、最も相性が良かった。
また、基本的には.NETとSQLServerという既存技術が適用できるため、既存のナレッジや技術者の調達面でも心配が少なかった。こうして、Windows Azureを最有力候補としてさらに調査を進めることになった。
難航した技術調査
しかし、2010年春時点でWindows Azureの情報は非常に限られており、具体的なアーキテクチャ検討を進める中で多くの不明点や課題が発生してしまうことになった。まだ関連書籍は数冊しか出ておらず、Webサイトにも概要レベルの情報しかない状況であったため、技術調査には相当苦労することになった(当時、頼りにしていたのはMSDNのブログや、主に海外の先行利用ユーザの断片的なレポートやQAを元に試行錯誤する、という状況だった)。
ただし前述のように、Windows Azureの基礎技術は.NETやSQLServerであるため、全てが手探りというわけではなく、Azure特有の技術差分のみを調査対象とすれば良い点では比較的ハードルは低かった。最終的には、マイクロソフトの技術者から直接サポートを受ける機会を得ることができたこともあり、比較的短い期間(約2週間)で致命的な課題は解決した。
SQL Azureの存在
選定理由として最も大きいのがSQL Azure 在である。
パブリッククラウドでのデータベースはKVS(Key-Value Store)が主流であるが、トランザクション処理を必要とする業務アプリケーションと相性は良くない。Windows Azureでは、ほぼ、オンプレミスのSQL Serverと同様に利用可能なRDBMSである「SQL Azure」が提供されている。透過的データ暗号化 (TDE)に対応していない等、未サポートの機能は少なからずあるが、SQL Serverでの開発経験があればSQL Azureであることをほとんど意識する必要がなかった。
また、格納されたデータ型に互換性があるため、オンプレミスのSQL Serverへのデータ移行はシームレスに行うことができる。一般的にデータ整合性の不備は、システムにとってもプロジェクトにとっても致命傷となり得る。とくに今回は、基幹システムの周辺システムという位置づけのため、クラウドとオンプレミスの連携が大きな焦点となる。非互換リスクに対する安心感は大きく、この点が最終的にWindows Azure採用の決定打となった。
料金体系と事務手続き面での親和性
Windows Azureはユーザ数課金ではないため、今回のプロジェクト要件(ユーザ数が数百人から数千人)に適合していた(利用方法によって異なるが、利用料はサーバインスタンス数台と50GBまで格納できるSQL Azureを合わせて月額数万円)。
また、海外のパブリッククラウドのサービスにありがちなクレジットカード払いが、Windows Azureでは必須ではなく、請求書を発行してもらえるという点も(ただし一定ボリュームの契約が必要)、事務手続き面でのハードルを下げるという意味では採用の後押しになった。
オンプレミスとの統合も視野に
本プロジェクトは、今後の拡張要求次第ではシステムの位置づけや信頼性が基幹システムと同様のレベルになる可能性がある。そのため、一旦パブリッククラウド上で構築はするものの、将来的には基幹システムの一部としてオンプレミス環境に統合することも視野に入れている。
単純にオンプレミス環境に載せ替えられると考えるほど楽観的ではないが、基本的なアーキテクチャは.NET+SQLServerであるため、それほど困難ではないと想定している。
* * *
本プロジェクトでは結果的にWindows Azureを採用することになったが、それは、対象業務も含めたプロジェクトの要求と環境が適合していたからである。決して新しい技術だからとか低コストで導入できるからだけが導入の理由ではない。検討プロセスにおいて最も重要なのは、プロジェクトの要求と候補となるソリューション(アーキテクチャ)との適合性である。
今回は、パブリッククラウド導入までの検討経緯を中心に紹介した。次回は、Windows Azureを具体的にどのように利用しているか、技術的なトピックも交えて紹介したい。