他に実施した対策

本プロジェクトで対処したポイントを3つ紹介したが、これ以外にもいくつか工夫した点があるので、概要だけ紹介しておきたい。

アプリケーションログ出力

業務システムの場合、社内規定の制約によってアプリケーションのログを一定期間保管しなければならないケースが多い。Windows Azureでは、アプリケーションの操作ログや詳細なエラーログは、明示的に出力・保存する仕組みを導入する必要がある。

本プロジェクトでは、オープンソースのロギングサービス「Apache log4net」を利用して、トレースログをWindows Azure Storageに転送する仕組みを構築した。なお、ログの閲覧やcsv形式でのログ出力には、サードパーティの有償ツールである「Azure Diagnostic Manager」を利用している。

図2 : Azure Diagnostic Manager(Trace logの確認画面)

帳票出力

業務システムの場合、帳票出力が必須要件となることが多いが、(筆者が知る限りでは)Windows AzureでPDF出力を行う正式なサービスは存在しない。そのため、本プロジェクトでは一時的な回避策として、Windows Azureに対応しているRTF出力ライブラリ「Telerik Reporting」を利用している。日本国内の業務システムでは帳票出力の需要が高いと思われるため、今後のサービス・ツールの拡充に期待したい。

ユーザインタフェース

ユーザインタフェースの開発に関しては、Azure特有の対処はほとんど行っていない。言い換えると、オンプレミスと同様の技術や対処がそのまま通用したということだ。

本プロジェクトでも、ASP.net MVC2をベースにJQuery UI やTelerik Extensions for ASP.NET MVCといったオンプレミスのUIソリューションを活用している。

UI設計に関して苦労した点は、社内の標準ブラウザがInternet Explorer 6(IE6)であったことだ。IE6は近年のWebアプリケーションで主流のAjaxの処理に問題が多く、正しく快適に動作させるにはJavaScriptのチューニングが相当必要になる。しかも難解な問題が多いため、開発コストにも無視できない影響がある。よほどの理由がない限り、IE6でのAjax UIは避けるべきだと助言しておきたい。

最後に

今回のプロジェクトで実施した対策は以下の図のようになる。

図3 : 実施した対策とコンポーネントの関係

今回のプロジェクトから得た、業務システムをWindows Azureで開発する際の考慮事項を以下にまとめておく。

  • データベース(SQL Azure)の暗号化
  • オンプレミスとのデータ連携
  • Web Role分散配置時のセッション共有
  • アプリケーションログ出力・保管
  • 帳票出力

これらは全ていわゆる「アプリケーションアーキテクチャ」に関する検討事項である。逆に言えばインフラ設計にはほとんど時間をかける必要はない。これはまさにPaaSクラウドの恩恵だと言える。Windows Azureの世界は広がっており、Full IISやVMRole等のインフラ寄りのサービスも提供され始めている。しかし業務システムをクラウド環境で構築するのであれば、PaaSに軸足を置き、アプリケーションアーキテクチャに設計リソースを集中させること。それがクラウドのメリットを享受するための近道だと感じている。