3つの対策(2) - オンプレミスとのデータ連携

業務システムはほとんどの場合、他システムとのデータ連携が必要となる。本プロジェクトは基幹システムの周辺ツールを開発するのが目的であったため、顧客情報や社員情報などのマスタデータは基幹システムのOracleデータベースのデータを共有することが必須要件となった。

そこで、まずオンプレミスとの連携ツールとして提供されている「SQL Azure Data Sync」が候補に挙がった。これが利用できればデータ連携の作り込みがほぼ不要となるはずだったのだが、まだ正式リリース前のCTP版(コミュニティテクニカルプレビュー版)であったため、残念ながら候補から外さざるを得なかった。

最終的に採用したのは、SQL Server製品に付属している「SQL Server Integration Services(以下SSIS)」だ。採用に至った最大の理由は、豊富なデータ形式をサポートしていた点だ。基幹システムのOracleにも比較的容易に接続でき、SQL Azureへの接続も当時からサポートされていた。

業務システムのクラウド化ではほとんどのケースでシステム連携が必要となるはずだ。利用するクラウドサービスがどのようなデータ連携方式に対応しているかがアーキテクチャ検討上の重要なポイントとなるだろう。

図1 : SSIS設定画面(SQL Azureへの接続設定)

3つの対策(3) - 複数インスタンスへの対応

本プロジェクトでは潜在的な利用ユーザ数が最大で数千人に上ることが想定されたため、Web Roleインスタンスを複数に分散させる必要があった。また、Windows Azureの外部接続に対するSLA(99.95%)は、Web Roleを複数インスタンスに展開しなければ適用されない。この点も複数のインスタンスを稼働させなければならない理由であった。

一般的にWebサーバを分散させる場合、サーバ間でセッション情報を共有させる仕組みが必要となる。本プロジェクトでもユーザのログイン情報やセッションタイムアウトの管理等で、Web Role間でのセッション情報の共有が必要であった。しかし、Windows Azureは物理的なサーバインスタンスを特定することができないため、セッション共有を実現するには何らかの対処が必要となる。

今となっては、セッション共有を実現する「Windows Azure AppFabric Caching Service」がマイクロソフトから正式リリースされている(有償)が、開発当時は自分達でセッション共有の仕組みを構築するしか選択肢はなかった。

開発当時はMSDN Blog等に記載されているいくつかの方法を中心に試行錯誤を行い、最終的には検証結果が最も安定していた「SQL Azureを使ったセッションステートの管理」を応用してセッション共有を実現した。

今後の開発では正式にサポートされているWindows Azure AppFabric Caching Serviceを使うのが自然だと思われるが、費用面を考慮するとSQL Azureを使う方法もまだ選択肢に入るだろう。