今回は、最後の「インテグレーション」について触れてみたいと思います。
インテグレーションに対する考慮点
「エンタープライズ向け」にフォーカスすると、全システムをすべて同じタイミングでクラウドへ移行するというシナリオはあまり現実的ではありません。
システム移行の予算の関係であったり、移行スケジュールの関係であったりもしますし、そもそもクラウドに移行することが許されないアプリケーションシステムが存在することも想定されます。
こうした場合、クラウドへ移行するアプリケーションシステムとオンプレミスに残るアプリケーションシステムの2通りの運用が必要となります。
各アプリケーションシステムが完全に独立して稼働している場合は移行が比較的容易ですが、たいていの場合システム間でデータを共有していたり、ワークフローなどでシステム間連携が実現されていたり、、、と完全分離が困難なケースが間々あります。
こうした場合、クラウドへのアプリケーション展開の検討時においてシステム統合戦略を策定すると良いでしょう。
主な戦略には以下のものがあります。
・データの統合
同じスキーマ定義を持つデータベースをオンプレミス＆クラウドの双方で持合い、レプリケーションなどによってデータを統合するパターンがこれにあたります。
マスターデータなど、クラウドでの利用頻度が高く更新の頻度が低いようなデータはレプリカを持ち合うといったアプローチを検討する価値があります。
また、クラウドで利用されたデータを適宜オンプレミスにダウンロードしてバックアップとして保持したり、社内システムのインプットに利用したりすることも可能です。
・直接的呼出しによる統合
WCFサービスやWeb-APIなどを介して直接的な統合をするパターンです。
このアプローチにはVPNを構築して社内ネットワークの一部としてコミュニケーションを図る方式とインターネットを介してコミュニケーションを図る方式の2通りがあります。セキュリティレベルにより適宜使い分ける必要があります。
・ミドルウェアによる統合
オンプレミス＆クラウド双方の連携を仲介するミドルウェアを介してアプリケーション統合するアプローチがこれに当たります。
従来のSOAによる連携はこのパターンに相当します。メッセージ中継やEAIを実現するミドルウェアを利用することで、より確実なデータ転送とアプリケーション連携を実現することができます。
続いて、Windows Azure で提供されている統合機能についてみていきましょう。
Windows Azureは発表当初よりエンタープライズにおける利用を想定したサービス群であるため、オンプレミスとの統合機能が多く存在します。
サービス提供開始の初期からあるサービスとして、サービス バスがあります。サービス バスはWCFによる連携を中継する「リレー」機能と高信頼メッセージングのインフラである「キュー」、パブリッシュ＆サブスクライブ型の1:nコミュニケーションをサポートする「トピック」で構成されています。リレー機能は、双方のエンドポイントを隠蔽しつつ、アウトバウンドのポートのみを利用してメッセージを中継します。これによって、オンプレミスにおいてNATやファイアウォールが介在する環境においてもメッセージの中継が可能になります。仮想ネットワークを構築できないネットワークとのコミュニケーション方法として選択することができます。
キューおよびトピックは永続化されたメッセージングポストを利用し、確実にメッセージを受信者に送信できるサービスです。AMQP 1.0の標準プロトコルにも対応しているため、同プロトコルに準拠した他のメッセージキューとの連携も可能です。
もし、オンプレミスとWindows Azureの間にVPNを構築することが可能であるならば、仮想ネットワークを利用するソリューションが選択可能です。
仮想ネットワークは、オンプレミスークラウド間を IPSec で接続し、セキュアなVPNを構築することが可能です。
また、VPNの種類にはサイト間ネットワーク、ポイント対サイトの2種類があります。
サイト間ネットワークを構築する際には、専用のVPNルーターが必要となりますが、仮想ネットワークが完全にオンプレミスのネットワークの一部として見えるため、DNSを統合することも可能です。
また、Active Directoryドメインに仮想ネットワーク上のインスタンスを参加させることも可能です。
Active Directoryの統合にはもう１つ、Windows Azure Active Directory(WAAD)による統合があります。これはオンプレミスのADとWAADの同期を設定することでADの統合を実現します。また、WAADはOffice 365のアカウント管理にも利用されるため、Office 365とオンプレミス、Windows Azureアプリケーション間のシングルサインオンを実現することも可能です。
シングルサインオンに関するソリューションには、WAADの一機能である「アクセス制御」を利用することも可能です。
アクセス制御はADFSによるオンプレミスADとのシングルサインオンを実現する以外に、Facebook, Google, Twitter, Microsoftアカウントなどといったソーシャルアカウントを用いてサインインを実現することが可能です。B to C 向けアプリケーションのように、広くユーザに開放したいシステムを構築する際に利用できます。
もし、オンプレミス内にLinux環境が存在するならば、仮想マシンを用いてクラウドに展開することが可能です。仮想ネットワークと組み合わせることで、BCP対策としても利用できます。
こうした連携が可能になっている背景には、Windows Azureはオープンな標準規格を積極的に採用していることがあります。
このようなWindows Azureの機能を活用するためにも、アプリケーションデザインの段階で、以下のポイントを検討することをお勧めします。
・疎結合の適用
密結合による統合は、しばしばパフォーマンスのボトルネックになったり、障害点を作り出したりという問題を引き起こします。そこで、メッセージングやBizTalkサービスの適用などを活用し、疎結合のシナリオを作るようにしてください。また、この際はリトライポリシーや有効期間などといった、ロングトランザクションを実現するためのルールを決定することを推奨します。
・露出の最小化
統合は極力必要最小限にとどめるべきです。システムの独立性を高めるためにも、システム間の依存関係を極力排除しつつ統合を実現させることを推奨します。たとえば、データはそれぞれレプリカを持ち合い、データ統合レベルで一貫性を確保するというような例があります。
・統合機能の分離
アプリケーションレベルで統合機能をインプリメントしてしまうと、同様の統合が必要となった際に、個別対応する形になります。そうではなく、サービス バスの適用を検討したりBizTalkサービスを利用したりするなど、統合機能を外出ししておけば他サービスも共通の仕組みを利用できます。
・セキュアな設計
インターネットを介するコミュニケーションでは特にセキュアなメッセージングが求められます。可能であれば、仮想ネットワークでVPNを構築し、IPSecによるコミュニケーションを実現することを検討してみてください。また、外部ネットワークを利用する際には受け渡しデータの暗号化などを検討してください。
・標準規格の採用
統合時に利用するプロトコルやデータフォーマットはできるだけ標準化されたものを利用してください。たとえば、AMQPによりメッセージングやJson形式のデータフォーマットなどの適用などを検討してください。ここで重要なのは「独自仕様を作らない」という点です。独自仕様を作り上げてしまったがために移行を断念する事態も想定されます。特に日本のシステムインテグレーターは独自仕様を作りたがります。しかし、クラウドにおいては標準化されたオープンな規格を適用することがアプリケーションのライフサイクルを伸ばす手段でもあります。
以上で、クラウドファーストなアーキテクチャデザインに関するポイントのご紹介は一通り終了です。
今後、もう少し時間をかけて説明させていただく場を設けさせていただくかもしれません。その際にも、このポストを思い出していただけると幸いです。
Comments are closed here.