Cloud First時代のITアーキテクト視点（３）～ モダンアプリケーションの典型的なアーキテクチャと技術の適用例

  • Article

前回はモダンアプリケーションが提供するビジネス機会として、以下の３つを挙げました。
1. 顧客エクスペリエンスの向上
2. 新しい市場への進出を含む顧客リーチの拡大
3. ビジネスパフォーマンスの向上

これらを実現するアプリケーションの典型的なアーキテクチャとはどのような特徴を持つのでしょうか？
私は以下の図のように考えています。

image
図１：モダンアプリケーションの典型的なアーキテクチャ

考察の出発点は、やはりデバイス類が多様化かつ高性能になったということです。ほんの少し前の時代のPCより高性能なスマートフォンも珍しくなくなった現在、シンクライアント時代のようにサーバー側でロジックを処理し、その結果を表示用データとともに生成し、デバイス側はレンダリングだけ、といったスタイルではせっかくのスマートデバイスの能力が活かせません。むしろ、デバイス側でできる処理に必要なデータを提供し、加工や表示データの生成などのタスクを行わせることでデバイス本来の性能を活かすことができるはずです。最近ではBootstrapのようなレスポンシブなUIを実装しやすい技術も出てきて、デバイスの種類や画面サイズに応じて最適な表示を行うことが簡単にできるようになったため、サーバー側の負荷も減らすことができる上に対応デバイスの追加にも柔軟に対応することができます。そしてカメラやGPS、ジャイロセンサー、加速度センサー、光センサーなどのセンサー類を活かして、よりリッチなユーザー体験を提供できるようになりました。

言わばデバイス側がリッチクライアント化しつつあるために、バックエンドのサーバーとオフライン状態になっても多くのタスクを問題なくこなすことができるようになってきています。もう１つ、クライアントとサーバー間のインターフェイス業界標準プロトコルを利用することで、デバイスとプラットフォーム間が疎結合化され、一方の変更がもう一方へ悪影響を与えるリスクがかなり減りました。

しかしながら、情報の流れはクライアントからサーバーへの一方通行とは限りません。例えば株価や在庫の変動、ニュース速報などサーバー側で起きたイベントを適切なタイミングでクライアント側に通知したい状況も多くなってきています。従来なら定期的にクライアント側からサーバー側へポーリングを行っていたでしょうが、それでは無駄にデバイスのバッテリーを消費してしまいます。そのような場合サーバー側からクライアント側にプッシュ通知することで、サーバー側の変更を素早く反映できます。また、オフライン状態にあったクライアントがつながり次第サーバー側の変更を同期することもできます。

こうやって見ると、クライアントとサーバーとの間のタスクの分担がクライアント側に寄った分、サーバー側の負担が軽くなったような感じがします。このようなアーキテクチャは「Thin Client」に対して「Thin Server」と呼ばれることがあります。WindowsストアアプリはまさにこのThin Serverアーキテクチャを採用していると言えます。（Thin Serverアーキテクチャについては丸山 不二夫先生のFacebook「ノート」に詳しい考察が載っています。）

では、今まで議論してきたモダンアプリケーションのアーキテクチャにマイクロソフト技術を適用してみます。

アーキテクチャを検討するに当たっては、どのような制約があるかを意識する必要があります。制約の内容によっては適用される技術が変わってきます。また、アーキテクチャを決定するためにその他の重要な要素としては、シナリオ、品質要件（非機能要件）がありますが、今回のシナリオは、顧客との関係を深めるためのキャンペーン用Webサイトを構築する、とします。

制約としては以下のようなものが考えられます。
. スマートフォン、タブレット、PCなど、ほとんどどのデバイスからでもアクセスできる。
. Facebook、Twitter などとのSNS連携に対応する。
. 顧客情報など秘匿性の高いデータはクラウドに保存しない。
. クラウドからオンプレミス環境のシステムへ安全にアクセスできる。
. 従業員は社内システムのアカウントを使って、クラウドへのシングルサインオンに対応する。
. 顧客から興味のあるキーワードを聞いておき、関連する情報やニュースを一斉に配信する。

これらの要件を満たすための技術選択についてまとめてゆきます。

1. マルチデバイス対応
マルチデバイス対応には、Webとネイティブアプリの両方の選択肢があります。ネイティブアプリには、各デバイスの機能を100%活用できる反面、配布の問題があります。今回はキャンペーンでもありますので、Webアプリ形式にします。表示はASP.NET MVCでレスポンシブデザインに対応します。また、データのやり取りはASP.NET Web APIを使いRESTベースでBLOBデータ以外は基本的にJSON形式で行います。またキャンペーン中にアクセスが急増した場合の対策としてAzure Web Sitesにアプリケーションをホストし、オートスケーリング機能を活用します。

2. ハイブリッド対応
顧客情報はオンプレミス環境に従来から顧客データベースがあるので、こちらと連携することにします。VPN環境を構築することも考えられますが、期間限定のためあまり環境を変えたくないことと、AzureホストサービスとしてWeb Sitesを選択したので、Hybrid Connectionsの採用を決定しました。（注：2014/9/30現在Hybrid Connectionsはプレビュー版のため、参考情報あるいは評価目的にてご利用ください。）

3. 認証
Webサイトを提供する企業の従業員は、既に自社内のActive Directoryで認証されています。その資格情報を同じく自社内のADFS（Active Directory Federation Services）を使ってSAMLなどクラウドで利用可能なセキュリティトークンに変換し、Azure Active Directoryでシングルサインオンさせます。顧客に対しても同じくAzure Active DirectoryでFacebookやTwitterアカウントで認証可能です。

4. 通知
サーバーからの情報をリアルタイムに漏らさず通知したいのならSignalRが適切と考えられますが、今回のシナリオではNotification Hubのほうが合っているでしょう。マイクロソフト、Apple、Googleがそれぞれ持っている既存の通知インフラを活用できるのも、マルチデバイス対応の点で優れていると考えられます。

これまでの技術選択を反映した初期アーキテクチャを以下に描いてみます。

image 図２：キャンペーンWebサイトの初期アーキテクチャ

この初期アーキテクチャをベースにスケーラビリティ、可用性、パフォーマンスなどの品質要件、新たな機能要件などを検討しながら徐々に洗練させてゆきます。

マイクロソフトでは、代表的なシナリオパターンにおける参照アーキテクチャを公開しているので、こちらを参考に自分なりの初期アーキテクチャを描いてみてはどうでしょうか。