アーキテクチャ・ジャーナル 積極的で現実的なクラウドの利用法 Eugenio Pace、Gianpaolo Carraro 2009/08/03
Page1 Page2 Page3 Page4

■エンタープライズにおける LOtSS - Big Pharma

　LOtSS をどのようにエンタープライズ環境に適用できるでしょうか。架空の製薬会社である Big Pharma を例に考えてみましょう。

　Big Pharma は、臨床試験と分子研究という 2 つの分野で、競合他社より優位にいます。しかし、同社は IT 予算の 80% を、戦略的とはいえない資産（電子メール、CRM、ERP など）に費やしています。もちろん、これらの機能はビジネスを遂行するうえで欠かせません。しかし、いずれの機能も Big Pharma が競合他社に差をつける点では役立ちません。Thomas 博士（Big Pharma の架空の CEO）がよく言うとおり、「優良な ERP システムを持っていたからといって、競争には勝てない。勝敗の鍵は、我々の分子研究にある」のです。

　したがって、Thomas 博士はコストを抑えられる業界標準のサービスを採用することにしました。そういうわけで、Big Pharma は同社の IT をさらに最適化できる“クラウド製品”を検討しています。目指すのは、コモディティ サービスで規模の経済性を追求しながら、コア機能で完全な制御を維持できるハイブリッド アーキテクチャを構築することです。この場合、課題は企業の境界を越えて IT 資産をスムーズに運用および管理することです。LOtSS の観点から見ると、Big Pharma は規模の経済性を実現できる場合に限ってクラウドを使用することで、IT を最適化しようとしているわけです。この目標を実現するにあたって、Big Pharma は“積み替え”コスト、つまり企業ファイアウォールの通過にかかるコストを最低限に抑える必要があります。

　検討の結果、Big Pharma は所有するデータ センターの CRM と電子メールという 2 つの機能を移行することにしました。これらの機能は、ベンダーからサービスとして提供されている業界標準の機能が利用できます。“業界で標準的な機能”が、必ずしも“低品質”を意味するわけではない点に注意してください。それらのサービスは、ただコモディティ化されているにすぎず、Big Pharma のニーズを十分に満たせる機能が備わっています。プロバイダーはそれらの機能を大量の顧客に提供することで、規模の経済性を実現しています。Big Pharma はこの規模の経済性を活用し、各機能の TCO を抑えることができます。

　一方、Pharma の ERP は高度にカスタマイズされていて要件が複雑なため、SaaS ISV 製品ではそのニーズを満たすことができません。そこで、Big Pharma は ERP をデータ センターの外部にホストすることで、異なったレベルでの機能性を最適化することにしました。つまり、Big Pharma は依然 ERP ソフトウェア自体を所有していますが、運用、ハードウェaア、A/C、および電源はすべてホスト プロバイダーが担当するというものです（図 1 を参照）。

図 1: Big Pharma のオンプレミス、ホストされた“コモディティ”サービス（コア ビジネス以外の機能用）、クラウド サービス（クリティカル ソフトウェア用）の棲み分け

• 教訓 4: 最適化はさまざまなレベルで行える。企業は、選択的にある機能全体（この例では CRM や電子メール）をその分野に特化したベンダーにアウトソーシングしたり、アプリケーションのある側面のみ（ERP の運用やハードウェアなど）をアウトソーシングしたりできる。

　これらのシステムを Big Pharma の企業境界外に移動することに伴う結果は無視できません。境界を越えて、一般的な IT 分野であるセキュリティ、管理、および統合を実装すると、膨大な積み替えコストが発生する場合があります。

　アクセス制御の面については、Big Pharma はホストされた各サービスに異なるユーザー名/パスワードを使用することを避け、Active Directory の既存のロール階層を活用して、従業員に対する承認ルールを引き続き集中管理したいと考えています。さらに、サービスのプロバイダーやホストされている場所にかかわらず、すべての従業員がシングル サインオンできることを望んでいます（図 2 を参照）。

図 2: ID フェデレーションとクラウド STS によるシングル サインオン

　複数ドメイン間の認証および承認で生じる“積み替えコスト”を抑える点で実績のあるソリューションは、ID フェデレーションとクレームベースの承認です。これらのソリューションは、よく知られた標準ベースのテクノロジで、複数ドメイン間の認証および承認を効率的に実装できます。

• 教訓 5: 現在のセキュリティ システムは、さまざまなアドホック ソリューションを組み合わせたものである。通常、企業は複数の ID 管理システムを実装している。Big Pharma などの企業は、標準ベースの認証および承認システムを実装するソリューションを望んでいる。これらのソリューションにより、積み替えコストを抑えることができる。

　システム管理の面については、Big Pharma は専用の IT スタッフを配置し、合意した SLA ですべての機能が提供されていることを確認します。また、CRM、ERP、または電子メールで問題を抱える従業員が、引き続き Big Pharma のヘルプ デスクに連絡し、問題を解決できるようにします。したがって、IT 資産が社内と社外のどちらで展開されているかにかかわらず、IT スタッフがそれらの資産を管理できることが重要です。このことから、ホストされた各システムは、Big Pharma IT の持つ既存の管理ツールに統合可能な管理 API を提供/公開する必要があります。たとえば、電子メールに関する問題について Big Pharma の従業員がチケットを開くと、電子メール サービス プロバイダー側の別のチケットが自動的に開かれます。問題が電子メール サービス プロバイダーによって閉じられると、Big Pharma に通知が送信され、同様に従業員側の問題が閉じます（図 3 を参照）。

図 3: Big Pharma は管理 API によってクラウド サービスを監視および制御する

• 注意: 組織の境界を超えて対応可能なシステム管理の標準（WS-Management など）が次々に登場していますが、それらはまだ普及していません。つまり、“コンテナ化”は進行していますが、完成しているわけではありません。

　では、Big Pharma が最も投資したい分野である分子研究と臨床試験について考えてみましょう。分子研究は、Big Pharma のビジネスの中心である、売れ筋の薬品開発に直結しています。分子研究の一般的な要件は、モデリングとシミュレーションです。モデリングには、高度な専用ソフトウェアを実行するハイエンドのワークステーションが必要です。Big Pharma は、このソフトウェアをオンプレミスで実行することにしました。このソフトウェアには非常に複雑なビジュアル化要件が存在するうえに、社内科学者との高度な対話機能が必要であり、ソフトウェアの一部をクラウドで実行することはほとんど不可能なためです。しかし、これらの抽象モデルのシミュレーションには、膨大なコンピューティング リソースが必要です。しかも、必要となるコンピューティング リソースは、膨大なだけでなく変動します。Big Pharma の科学者は、コンピューター 2000 台/日に相当する計算が必要なモデルを扱うこともあれば、結果を分析する数週間、シミュレーションを行わないこともあります。この場合、Big Pharma はピーク時に合わせて投資することもできます。しかし、必要になるコンピューティング リソースの量が大きく変動するので、大量の CPU を準備してもそれらの平均使用率はきわめて低くなります。一方、中程度の処理量に合わせて投資すると、ピーク時の処理に対応できなくなります。そこで、Big Pharma はコンピューティング リソースのみを提供するサービスを契約することにしました。これらのコンピューターの割り当てと構成は、Big Pharma のモデリング ソフトウェアでオンデマンドに行うことができ、プロバイダーは最新のハードウェアとネットワーキングの提供を保証します。シミュレーションでは大量の情報が生成されるため、Big Pharma はストレージ サービスも契約することにしました。これにより、社内でハイエンドなストレージ システムを構築するよりはるかに安いコストで、きわめて大量のデータを処理することができます。クラスターによって生成された生データの一部は必要に応じて Big Pharma のオンプレミス システムにアップロードされ、分析やモデリング ツールへのフィードバックが行われます。

　このハイブリッド アプローチにより、2 つのメリットを実現できます。十分なコンピューティング リソースでシミュレーションを実行できることと、使った分だけ料金を払うことでコストを抑制できることです（図 4 を参照）。

図 4: Big Pharma の科学者はオンプレミスのソフトウェアで分子をモデリングし、シミュレーション ジョブをオンデマンドのクラウドに送信する

　もちろん、この方法が本当に有用なものになるには、積み替えコスト（この場合は、クラウドベースのシミュレーション プラットフォームと社内のモデリング ツールを橋渡しする機能）の管理が必要です。積み替えコストを管理できないと、ユーティリティ プラットフォームによるメリットはすべてこのコストで帳消しになってしまいます。

　Big Pharma のもう一つの重要なシステムは、臨床試験システムです。モデリングとシミュレーションを行った後、治験薬は有効性と副作用を調べるために実際の患者に投与されます。これらの臨床試験に参加する患者は、あらゆる健康指標やその他のさまざまな情報（患者の活動、所在地、気分など）を Big Pharma に報告する必要があります。患者は、収集した情報をシミュレーション クラスターと、Big Pharma が治験を追跡するために使用する専用のオンプレミスのソフトウェアの両方に送信します。

　分子モデリング ソフトウェアと同様、臨床試験システムには高度に専門化したニーズがあるため、Big Pharma はこのシステムを社内で開発しています。しかし、Big Pharma は、既に何度も LOtSS を適用してきたのではないでしょうか。確かに、患者が自分の治験結果を共有できる治験ソフトウェア通信サブシステムは、数年前の自動 FAX システムから、現在のセルフサービスによる Web ポータルへと進化し、患者がデータを直接送信できるようになりました。

　治験に参加する患者は、電話、Web、個人用健康管理システムなど、さまざまなデバイスを使って Big Pharma と対話します。したがって Big Pharma は、優れた SLA を実現する信頼性の高いセキュアな通信を提供するために、高度に専門化したクラウドベースのメッセージング システムを採用することにしました。しかし、このようなシステムを自社だけで構築するにはコストがかかります。Big Pharma にはそのようなシステムを開発/運用するための専門知識がないうえに、クラウド サービスであれば活用できる規模の経済性のメリットもありません。

　この点、インターネット サービス バス（ISB）は、Big Pharma が非常に洗練されたパターンを使用して患者と対話することを可能にします。たとえば、デバイスで実行されているソフトウェアの更新を、特定の患者グループにブロードキャスト送信することができます。また、何らかの理由で Big Pharma の臨床試験ソフトウェアが使用できない場合、ISB は保留しているメッセージを保存し、システムが再度使用できるようになるとそのメッセージを転送します（図 5 を参照）。

図 5: Big Pharma の臨床試験に参加する患者は、臨床試験システムとシミュレーション クラスターにデータを送信する

　一方、患者は Big Pharma の従業員ではないので、Big Pharma のディレクトリに含まれません。Big Pharma は、患者の ID を社内のセキュリティ システムと統合するために、フェデレーションを使用しています。患者は、Microsoft LiveID などの既存の Web ID を使用し、認証を受けます。クラウド ID サービスは、患者と対話するサービスが識別できる形式に、それらの認証トークンを変換します。

　ここまで、この簡略化されたシナリオを通じて、Big Pharma が IT 環境で実現できる最適化について説明してきました。最適化は、特化したクラウド サービスを選択的に活用し、規模の経済性を実現することで可能になります。完成したサービス（電子メール、CRM、ERP）から、他の機能との関連でのみ生じるサービス構成要素（クラウド コンピューティング、クラウド ID サービス、クラウド ストレージ）に至るまで、さまざまな抽象化レベルで、このような選択が可能です。

INDEX
	［アーキテクチャ・ジャーナル］
	積極的で現実的なクラウドの利用法
	1．序論
	2．エンタープライズにおけるLOtSS - Big Pharma
	3．LOtSSのLitwareHR への適用／UIおよびデータ層におけるクラウド・サービス
	4．クラウドにおける認証と承認／細分化、最適化、そして再構成

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）