35
Copyright © 2009 Growth xPartners, Inc. All rights reserved. 1A-3 SOAから見た,クラウド時代のアーキテクチャ 2009/9/15 グロースエクスパートナーズ(株) ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITゕーキテクト 日本Javaユーザー会/日本Springユーザー会幹事 ゕークランプ(http://www.arclamp.jp/鈴木雄介

20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Copyright copy 2009 Growth xPartners Inc All rights reserved

自己紹介

bull 鈴木雄介ndash 所属

bull グロースエクスパートナーズ(株)ndash ビジネスプラットフォーム事業ゼネラルマネージャーチー

フITゕーキテクト

ndash コミュニテゖbull 日本Javaユーザー会 幹事bull 日本Springユーザー会 幹事

ndash ブログ記事書籍などbull ゕークランプ(httpwwwarclampjp)bull 日経SYSTEMSにてコラム「ITゕーキテクトの視点」を連載中

bull 「ソフトゕーキテクトが知るべき97のこと」監修10月初旬

Copyright copy 2009 Growth xPartners Inc All rights reserved

所属先紹介

bull グロースエクスパートナーズ(株)ndash 基本情報

bull 創業2009年7月4日(8月決算)

bull 社員70名売上9億

bull 独立系

ndash 業務内容bull システム開発(主にJava)技術ビジネスコンサルデザ

ンマーケテゖング

bull 基本的にプラム

ndash 私の立場bull クラゕント企業での標準化策定支援や技術支援案件での

ゕーキテクチャ策定やプロトタピングエンジニゕ教育

bull いわゆるITゕーキテクトコーデゖング営業提案もします

Copyright copy 2009 Growth xPartners Inc All rights reserved

このセッションのゴール

bull FOR

ndash 企業システムから見たクラウド活用について理解したい検討ポントを知りたい

bull NOT FOR

ndash クラウドの最新技術動向を詳しく理解したい

ndash 各クラウド事業者のサービス内容が知りたい

ndash ベンダー各社のクラウド戦略が知りたい

ndash これからはSOAじゃなくてクラウドだ

Copyright copy 2009 Growth xPartners Inc All rights reserved

ゕジェンダ

bull はじめに

bull クラウドとは何か

bull クラウドの特徴

bull クラウドの技術

bull クラウドへの期待

bull クラウドを利用する上での課題

bull SOAとは

bull SOAから見たクラウド

bull まとめ

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 2: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

自己紹介

bull 鈴木雄介ndash 所属

bull グロースエクスパートナーズ(株)ndash ビジネスプラットフォーム事業ゼネラルマネージャーチー

フITゕーキテクト

ndash コミュニテゖbull 日本Javaユーザー会 幹事bull 日本Springユーザー会 幹事

ndash ブログ記事書籍などbull ゕークランプ(httpwwwarclampjp)bull 日経SYSTEMSにてコラム「ITゕーキテクトの視点」を連載中

bull 「ソフトゕーキテクトが知るべき97のこと」監修10月初旬

Copyright copy 2009 Growth xPartners Inc All rights reserved

所属先紹介

bull グロースエクスパートナーズ(株)ndash 基本情報

bull 創業2009年7月4日(8月決算)

bull 社員70名売上9億

bull 独立系

ndash 業務内容bull システム開発(主にJava)技術ビジネスコンサルデザ

ンマーケテゖング

bull 基本的にプラム

ndash 私の立場bull クラゕント企業での標準化策定支援や技術支援案件での

ゕーキテクチャ策定やプロトタピングエンジニゕ教育

bull いわゆるITゕーキテクトコーデゖング営業提案もします

Copyright copy 2009 Growth xPartners Inc All rights reserved

このセッションのゴール

bull FOR

ndash 企業システムから見たクラウド活用について理解したい検討ポントを知りたい

bull NOT FOR

ndash クラウドの最新技術動向を詳しく理解したい

ndash 各クラウド事業者のサービス内容が知りたい

ndash ベンダー各社のクラウド戦略が知りたい

ndash これからはSOAじゃなくてクラウドだ

Copyright copy 2009 Growth xPartners Inc All rights reserved

ゕジェンダ

bull はじめに

bull クラウドとは何か

bull クラウドの特徴

bull クラウドの技術

bull クラウドへの期待

bull クラウドを利用する上での課題

bull SOAとは

bull SOAから見たクラウド

bull まとめ

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 3: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

所属先紹介

bull グロースエクスパートナーズ(株)ndash 基本情報

bull 創業2009年7月4日(8月決算)

bull 社員70名売上9億

bull 独立系

ndash 業務内容bull システム開発(主にJava)技術ビジネスコンサルデザ

ンマーケテゖング

bull 基本的にプラム

ndash 私の立場bull クラゕント企業での標準化策定支援や技術支援案件での

ゕーキテクチャ策定やプロトタピングエンジニゕ教育

bull いわゆるITゕーキテクトコーデゖング営業提案もします

Copyright copy 2009 Growth xPartners Inc All rights reserved

このセッションのゴール

bull FOR

ndash 企業システムから見たクラウド活用について理解したい検討ポントを知りたい

bull NOT FOR

ndash クラウドの最新技術動向を詳しく理解したい

ndash 各クラウド事業者のサービス内容が知りたい

ndash ベンダー各社のクラウド戦略が知りたい

ndash これからはSOAじゃなくてクラウドだ

Copyright copy 2009 Growth xPartners Inc All rights reserved

ゕジェンダ

bull はじめに

bull クラウドとは何か

bull クラウドの特徴

bull クラウドの技術

bull クラウドへの期待

bull クラウドを利用する上での課題

bull SOAとは

bull SOAから見たクラウド

bull まとめ

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 4: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

このセッションのゴール

bull FOR

ndash 企業システムから見たクラウド活用について理解したい検討ポントを知りたい

bull NOT FOR

ndash クラウドの最新技術動向を詳しく理解したい

ndash 各クラウド事業者のサービス内容が知りたい

ndash ベンダー各社のクラウド戦略が知りたい

ndash これからはSOAじゃなくてクラウドだ

Copyright copy 2009 Growth xPartners Inc All rights reserved

ゕジェンダ

bull はじめに

bull クラウドとは何か

bull クラウドの特徴

bull クラウドの技術

bull クラウドへの期待

bull クラウドを利用する上での課題

bull SOAとは

bull SOAから見たクラウド

bull まとめ

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 5: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

ゕジェンダ

bull はじめに

bull クラウドとは何か

bull クラウドの特徴

bull クラウドの技術

bull クラウドへの期待

bull クラウドを利用する上での課題

bull SOAとは

bull SOAから見たクラウド

bull まとめ

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 6: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

bull 基本スタンス

ndash クラウドとSOAは違うモノそれぞれの課題に対してそれぞれの技術が形成されてきた

ndash ただし重なる課題や技術はある

ndash 主に企業システム視点でのクラウド活用法を考える

はじめに

課題 課題

エンタープラズITCサービス

コンシューマー向けンターネットサービス

クラウド技術

SOA技術

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 7: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 今まさにハプの頂点

SOAは5年以内にメンストーリムに

クラウドはハプの頂点これから期待が落ちる

ガートナー1650のテクノロジの成熟度を評価したハプサクルスペシャルレポートを発行httpwwwgartnercojppresshtmlpr20090908-01html

ハプのピークにある言葉を定義するのは非常に難しい

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 8: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 一般的な概念は形成されつつあるndash 朝日新聞 2009年9月9日付社説

bull ソフトや情報を<中略>ネット上にあるコン

ピューターシステムに格納し必要な時にネット経由でパソコンに取り寄せて使う方式が広がりつつあるネットを雲にたとえた「クラウドコンピューテゖング」と呼ばれる流れだ

ndash httpwwwasahicompapereditorial20090909html

ndash このセッションでのクラウドの定義bull 「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」

ndash プラベートクラウドの定義は非常に曖昧hellip

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 9: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドとは何か

bull 参考各種クラウドコンピューテゖングndash クラウドを構成する技術群のうちどこまでを提供しているか

がで呼び方が変わる

ハードウェゕ

ネットワーク

OS

仮想化層

コンテナ

サービスゕプリケーション

OS

PaaSGoogle App EngineSalesforcecom Forcecom

SaaSSalesforcecomGoogle Gmail

HaaSIaaSAmazon EC2(CPU)Amazon S3(ストレージ)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 10: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull ともかく「規模の経済性」を追求するndash 大規模データセンターにコンピューテゖングリースを集約し全てのユーザーに同一サービスを提供することでコストを下げるbull 同一サービスの範囲は広めユーザー自身がプラットフォームが規定する様々なカスタマズを実施できる

bull 1つのバージョンを全てのユーザーに提供する(例Salesforcecomのユーザーは全てv30を使っている)

bull マルチテナント型でサーバ資源データ領域なども全ユーザーで共有される

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 11: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの特徴

bull サービスは超大規模化していくndash コンシューマー向けクラウドサービスの規模感

bull 例Gmailndash 自分のメール21608件で7369MB 中 515MB (6) 使

用100だと約30万件ndash 3700万UU(全米2009年7月)YahooMailは1億600万UUndash 兆の単位も見えてくる

bull 例twitter(ツッター)ndash もう少しで40億つぶやきndash UU4450万人(全世界2009年8月)ツールは含まないndash リゕルタムで処理量をみてみる

raquo つぶやきhttpwwwtwitpocalypsecomraquo 写真httptwicsycomrealtime

ndash 一般的な企業システムとは桁が100倍~1000倍ぐらい違う

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 12: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull 規模の経済をいかに実現するかndash コンピューテゖングリソースはハードウェゕ構成に

制限をうけるいかに複数のハードウェゕを1つのサービスに見せるか

ndash スケールゕップでは不可能スケールゕウトを実現するための各種の技術bull 例MapReduce仮想化技術

ndash スケールゕウトを実現するために失うものもあるbull CAP定理

bull ACID特性よりもBASE特性

ltスケールゕップgt ltスケールゕウトgt

ハードウェゕの限界

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 13: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

MAP SHUFFLE REDUCE

「Googleの大規模分散技術の中核 MapReduceについて」早稲田大学 丸山不二夫

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 14: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull CAP定理による整理

ndash CAP定理共有データについて次の3つの特性のうち2つだけしか同時には達成できない

ndash データの整合性 Consistency

ndash システムの可用性 Availability

ndash ネットワークの分断 Partition

ndash 超大規模データを扱うためにはデータ整合性を犠牲にするしかない(犠牲にしない方法がないわけでないがあまりにコストがかかる)

A

P

C A

P

C

エンタープラズ的な発想データ整合性と可用性は絶対それほど規模がいらないので分散しない

クラウド的な発想分散は前提可用性がなくては使えないため整合性を捨てるしかない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 15: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull ACID特性ndash エンタープラズではACID特性を実現するためにデータ

ベーストランザクション処理を利用するのが一般的bull Atomic(原子性)

ndash トランザクションに含まれるタスクが全て実行されるかあるいは全く実行されないことを保証する性質

ndash 失敗した場合はロールバックですべての処理がなかったことになる

bull Consistent(一貫性)ndash トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保

証する性質ndash テーブルやリレーションの制約条件

bull Isolated(独立性)ndash トランザクション中に行われる操作の過程が他の操作から隠蔽される性知るndash あるセッションによる処理が実行中は他のセッションからは変更されている

データが見えない

bull Durable(永続性)ndash トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的と

なり結果が失われない 性質ndash データベースエンジン自体が異常終了してもログを利用して処理を戻す

ndash 分散トランザクションではツーフェーズコミットが行われる

httpjawikipediaorgwikiACID_(コンピュータ科学)

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 16: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドの技術

bull BASE特性ndash クラウドではシステム全体としてBASE特性を実現する

bull Basically Available(基本的に可用)ndash キュー楽観的排他制御レプリケーション

bull Soft-State(柔軟な状態管理)ndash あるノードの状態はその内部に埋め込まれた情報によって決まるのではなく

外部から送られた情報によって決まる性質ndash あるノードの状態がいったん失われても定期的に状態情報を取得すれば

状態は復元される

bull Eventual Consistency(最終的な一貫性)ndash システム内に一時的に一貫性でない状態が生まれてもある期間の後には一

貫性ある状態になるような性質

ndash 簡単に考えると「一時的にはデータの整合性がない」 「ダメだったらやり直せばいい」

ndash ACID特性を否定するものではないBASE特性と組み合わせて利用することが可能マシン間は完全なBASEでマシン内はACIDなどbull バッチ処理やフゔル転送などはBASE特性といえるbull 実はエンタープラズでも良く活用している手段

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 17: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull 真のユーテゖリテゖコンピューテゖングが実現するのではないかndash 必要な時に必要なだけ使える

bull ニコラスGカー「クラウド化する世界」ndash 「電力供給において自家発電が中央発電所に置き換わっ

た」ようにクラウドはユーテゖリテゖコンピューテゖングを実現する

ndash コンセントにさせば電気が従量課金が使えるようにコンピューテゖングリソースが得られる

ndash ITサービスにも同じコトがおきるbull もはや自家発電は緊急設備過疎地工事現場にしかなくなってしまった

bull 同じように自社システムがなくなり巨大なクラウドに飲み込まれていくのかもしれない

bull ガバナンスの問題は時間が解決する

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 18: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

ndash 『巨大な発電装置を可能にしたのは発電装置トランスミッション電気モーターなど工業化学全般における数々の発明だったしかしこうした成功を確実にしたのは技術ではなく経済だった中央の発電装置から多くの消費者まで電気を供給することで発電所はエネルギー製造において個人工場が到底かなわない「規模の経済」を確立した』

ndash ニコラスGカー「クラウド化する世界」UNIX magazine 2009年4月号クラウド特集「クラウドは企業ユーザーに受け入れるのか」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 19: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull とはいえ「過度な期待」ndash コンピューテゖングリソースは電力ではない

bull 電力は純粋にエネルギーでありその利用形態は利用者側に託される(掃除機冷蔵庫hellip)

bull コンピューテゖングリソースはサービスであり利用形態は提供者側に縛られる(Amazon EC2とGAEとSalesforcecomは互換性がない)

ndash ンフラサービスについては利用形態(いわばコンセントの形状)について標準化策定が進んでいる

bull 電力は送電(ダウンロード)されてユーザーの元に届く

bull コンピューテゖングリソースを利用するには情報を送信(ゕップロード)する必要がある

bull ただし適合する事例も存在するndash 「必要な時に必要なだけ」

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 20: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash 主体は環境省経済産業省総務省ndash 「想定申請件数2000万件仕様書発注予算曖昧

7月1日稼働必須システム稼働期間10ヶ月」ndash という電話が5月28日に来た

bull そもそも公募時期が5月中旬

「エコポント」の情報システムがわずか3週間で完成した理由httpitnikkeicojpbusinessnewsindexaspxn=MMIT31000026082009

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 21: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドへの期待

bull エコポントの交換申請サトndash システム概要エコポントの登録と交換用申請

書の印刷bull いくつかのベンダーでの見積もりは数百億円~1000億円10ヶ月しか使わないシステムにそこまではかけられない

ndash そこでSalesforcecomに相談bull 要求定義は走りながら考えた構築は正味3週間

ndash 官公庁案件でありながらの採用bull ldquo今回はまさに官公庁の人がメンタルハザードを越えて実質的な効果を選択してくれたことです間違いなく一番安く実現したことも事実ですrdquo 宇陀栄次

「エコポント」の申し込み画面はクラウド上に開発期間わずか1カ月 - Blog on Publickeyhttpwwwpublickeyjpblog091html

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 22: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull コストndash 長期利用前提であまり利用量が変わらないならオン

プレミス(自社所有)の方がTCO(総保有コスト)的に安くあがる可能性が高いbull 自家用車とレンタカーの関係と同じbull Amazon S3はストレージ1GBあたり月額15セントつまり

約15円1TBのデータを1ヶ月保管すると15000円+データ転送料

bull 1TBのエンタープラズストレージ約20万円TCO推定は60万円(ハードウェゕ価格はTCOの30程度)ラフサクルを5年とすると月額10000円で転送料金不要で高速

ndash クラウドコンピューテゖングは安上がりではないndash httpblogsitmediacojpkurikiyo200901post-3c62html

ndash クラウドにすることでのメリットbull 資産(BS)ではなく経費(PL)になるbull ンフラ保守に人的リソースをかけなくてすむbull 利用量の増加リスクが高い場合にヘッジできる

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 23: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

bull セキュリテゖリスクndash 他者に情報を委託することに発生するもの

bull 1 特権ユーザーによるゕクセス

bull 2 コンプラゕンス関連

bull 3 データの保管場所

bull 4 データの隔離

bull 5 データの復旧

bull 6 調査に対する協力姿勢

bull 7 長期にわたる事業継続性ndash クラウドコンピューテゖングが抱える7つのldquoセキュリテゖリスクrdquo

ndash httpwwwcomputerworldjptopicssaasw114209html

ndash 当然ながらガバナンス上での判断になるので一概に良い悪いではない

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 24: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

クラウドを利用する上での課題

ndash 前述の朝日新聞社説より

bull 半面クラウドが抱える問題点も膨らむグーグルに対してはネットを通じて世界中から集めた利用者の情報を囲い込む「情報支配」への懸念が以前から指摘されてきたプラバシーは守られるのか利用者が不利な立場に追い込まれないか

bull そうした懸念を解くためにクラウドの巨人をどう監視するかは両社が本社を置く米国はもちろん国際的にも議論していく必要がある

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 25: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

ここまでのまとめ

bull 本セッションにおけるクラウドの定義ndash 「ンターネット越しに必要な時に必要なだけ使う各種

コンピューテゖングリソース」

bull 特徴ndash 規模の経済性ndash 超大規模

bull 技術ndash スケールゕップよりスケールゕウトndash CAP定理ACID特性よりもBASE特性

bull 期待ndash 過度な期待ではあるが適用事例はある

bull 利用上の課題ndash ガバナンス上のリスクありndash TOCでは安くはないが形態にメリットはある

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 26: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull まずは企業の現状を整理ndash 不況を背景にした(古くて新しい)課題

bull ともかくコストを安くbull 既存新規システムの再利用性を高めたいbull ビジネス環境の変化への追随性を高めたいbull これまで人手でやっていた業務を効率化したい(管理の厳密化)

ndash テーマbull 社内外で求められる多様なシステムを全体最適化するbull 自社IT資産のポートフォリオをきちんとマネジメントしていきたい

ndash 技術的な注目点bull いかにしてシステムを統合していくのか

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 27: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull システムの統合をいかに実現するかndash 必要に合わせて結合度を調整することが重要

bull 密であれば統合コストはさがる大量一括処理が可能bull 疎であれば統合コストはあがる逐次処理が可能bull なんにせよデータベーススキーマが共通化されていて変換コ

ストを低くすることは重要

Solving Integration Problems using PatternshttpwwweaipatternscomChapter1html

密 疎

データベース共有

レプリケーション

ビジネスプロセスマネジメント

サービスバス

フゔル転送

RPC

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 28: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAとは

bull 企業の現状からみたSOAndash ハプ曲線ではrdquo啓蒙活動期rdquoにあり改めて定義の整

理が行われている段階bull 狭義には「業務上の一処理に相当するソフトウェゕの機能を

サービスと見立てそのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉」

ndash httpjawikipediaorgwikiサービス指向ゕーキテクチャ

ndash 広義には「多様なゕプリケーションを疎に統合するための様々な手法」bull ESB Enterprise Service Busbull BPM Business Process Managementbull MDMMaster Data Management

ndash SOA製品が必要なわけじゃない大事なのは「疎に統合する」という概念bull 多くのSOA製品が密結合の手法についてもサポートしている

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 29: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull 両者の背景的な違いndash クラウド規模の経済性より多くのユーザーに

サービスを届ける

ndash SOA全社最適多様なサービスをどうマネジメントするのか

bull 両者の技術的な違いndash クラウドサービスの水平スケール

ndash SOAサービスの疎統合

bull 企業システムから見たクラウドndash VS オンプレミス

ndash レンタカーと自家用車の使い分け

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 30: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドは全社最適化手段の1つndash エコポントを最適化として考える

bull 所有するよりもコストが安く上がる

bull 資産(BS)ではなく経費(PL)

bull ただしガバナンスの問題は別

bull クラウドを導入する場合は既存システムの連携が課題ndash クラウドを利用するためには基幹システムとの連

携が必要でありそこでSOAを活用することができる

ndash SOAであれば交換コストを低減しておくことができる

ndash 適切な事例は出てきていないが既に存在する

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 31: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドへの接続は大きくは問題なしndash APIが提供されていればそれを利用可能

bull Salesforcecomndash Forcecom WebサービスAPI

ndash ForcecomメタデータAPI

ndash ない場合は自力で作ればいい(そもそもンターネットに接続できるのだから)bull VPN接続サービスもはじまっている

ndash いずれにせよ標準的な接続手法で利用可能bull クラウド側からの接続については制限がある場合も

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 32: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドの使いどころndash 最も効果的な適用箇所

bull 大量処理で短期保有長くとも5年(一般的な償却期間)以内

ndash サービスごとに使い分けは必要bull Amazon EC2S3

ndash サーバのCPUとストレージを利用する様々なOSやミドルウェゕを利用可能

bull Google App Enginendash Googleプラットフォーム(MapReduceKey-Value

Store)を利用したゕプリケーションプラットフォーム(PythonJava)

bull SalesforcecomForcecomndash 簡易リレーショナルデータオブジェクトを作成し独自言

語(Apex)でUIやトリガーを実装していくゕプリケーションプラットフォームデータ中心的

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 33: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

SOAから見たクラウド

bull クラウドを使う場合の注意事項ndash 利用における制限

bull データ転送量の制限が大きい(コストではなく時間)ndash 日本では太平洋がボトルネックAmazon EC2ではだいたい

400-500KBsなので10GB転送に7時間弱DWHなど大量データが必要になる場合にはデータ転送量がボトルネックになる

bull クラウド側のサービス形態に制限を受けるndash Salesforcecomの場合組み込みのデータスキーマが既定されお

りそれを変えることができない階層化されたリレーションは1段階までなど細かい制約

bull ガバナンスは言うまでもなく問題

ndash ただし時間が解決する問題もあるかもbull 直接ハードデゖスクを送付する形でのデータ入出力を可能に

する「AWS ImportExport」

bull VPN接続を行う「Amazon Virtual Private Cloud」

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 34: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

まとめ

bull クラウドは過度な期待の中にあるが「ンターネット越しに必要な時に必要なだけ使う各種コンピューテゖングリソース」という定義はウソではない

bull 企業システムの全体最適はより重要な課題にbull SOAはシステムの疎結合を実現する手法

bull 企業システムでクラウドを活用する場合にSOAは重要な役割を果たす

ndash 全体最適はこれからも課題でありつづけるが銀の弾丸は存在しないbull ハプ曲線に影響されずに技術を見極めて自社シス

テムのポートフォリオ管理を

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介

Page 35: 20090915 Xdev 1 A 3 Soaから見た、クラウド時代のアーキテクチャ.Pptx

Copyright copy 2009 Growth xPartners Inc All rights reserved

1A-3SOAから見たクラウド時代のアーキテクチャ

2009915

グロースエクスパートナーズ(株)ビジネスプラットフォーム事業ゼネラルマネージャーチーフITゕーキテクト

日本Javaユーザー会日本Springユーザー会幹事

ゕークランプ(httpwwwarclampjp)

鈴木雄介