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

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

2009/9/15
グロースエクスパートナーズ（株）
ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITゕーキテクト
日本Javaユーザー会/日本Springユーザー会幹事
ゕークランプ（http://www.arclamp.jp/）

鈴木雄介
Copyright © 2009 Growth xPartners, Inc. All rights reserved.

自己紹介
• 鈴木雄介
– 所属
• グロースエクスパートナーズ（株）
– ビジネスプラットフォーム事業ゼネラルマネージャー/チー
フITゕーキテクト
– コミュニテゖ
• 日本Javaユーザー会幹事
• 日本Springユーザー会幹事
– ブログ/記事/書籍など
• ゕークランプ（http://www.arclamp.jp）
• 日経SYSTEMSにてコラム「ITゕーキテクトの視点」を
連載中
• 「ソフトゕーキテクトが知るべき97のこと」監修/10
月初旬


所属先紹介
• グロースエクスパートナーズ（株）
– 基本情報
• 創業2009年7月4日（8月決算）
• 社員70名/売上9億
• 独立系
– 業務内容
• システム開発（主にJava）、技術/ビジネスコンサル、デザ
゗ン、マーケテゖング
• 基本的にプラ゗ム
– 私の立場
• クラ゗ゕント企業での標準化策定支援や技術支援、案件での
ゕーキテクチャ策定やプロトタ゗ピング、エンジニゕ教育
• いわゆるITゕーキテクト。コーデゖング、営業、提案もしま
す


このセッションのゴール
• FOR
– 企業システムから見たクラウド活用について
理解したい、検討ポ゗ントを知りたい
• NOT FOR
– クラウドの最新技術動向を詳しく理解したい
– 各クラウド事業者のサービス内容が知りたい
– ベンダー各社のクラウド戦略が知りたい
– これからはSOAじゃなくてクラウドだ


ゕジェンダ
• はじめに
• クラウドとは何か
• クラウドの特徴
• クラウドの技術
• クラウドへの期待
• クラウドを利用する上での課題
• SOAとは
• SOAから見たクラウド
• まとめ


はじめに
• 基本スタンス
– クラウドとSOAは違うモノ。それぞれの課題
に対してそれぞれの技術が形成されてきた
– ただし重なる課題や技術はある
– 主に企業システム視点でのクラウド活用法を
考える
課題課題

・コンシューマー向け゗・エンタープラ゗ズITC
ンターネットサービスサービス

クラウド SOA
技術技術

クラウドとは何か
• 今まさにハ゗プの頂点
クラウドはハ゗プの頂点。
これから期待が落ちる

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

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

ガートナー、1,650のテクノロジの成熟度を評価したハ゗プ・サ゗クル・スペシャル・レポートを発行
Copyright © 2009 Growth xPartners, Inc. All rights reserved. http://www.gartner.co.jp/press/html/pr20090908-01.html

• 一般的な概念は形成されつつある
– 朝日新聞 2009年9月9日付社説
• ソフトや情報を＜中略＞ネット上にあるコン
ピューターシステムに格納し、必要な時に
ネット経由でパソコンに取り寄せて使う方式が広
がりつつある。ネットを雲にたとえた「クラウ
ド・コンピューテゖング」と呼ばれる流れだ。
– http://www.asahi.com/paper/editorial20090909.html

– このセッションでのクラウドの定義
• 「゗ンターネット越しに、必要な時に必要なだけ
使う各種コンピューテゖングリソース」
– プラ゗ベートクラウドの定義は非常に曖昧…


• 参考：各種クラウドコンピューテゖング
– クラウドを構成する技術群のうち、どこまでを提供しているか
がで呼び方が変わる。

サービス/ゕプリケーション SaaS：Salesforce.com、Google Gmail

コンテナ
PaaS：Google App Engine、
OS Salesforce.com Force.com

仮想化層

OS
HaaS/IaaS：Amazon EC2
ハードウェゕ（CPU）、Amazon S3（スト
レージ）
ネットワーク

クラウドの特徴
• ともかく「規模の経済性」を追求する
– 大規模データセンターにコンピューテゖング
リースを集約し、全てのユーザーに同一サー
ビスを提供することでコストを下げる
• 同一サービスの範囲は広め。ユーザー自身がプ
ラットフォームが規定する様々なカスタマ゗ズを
実施できる
• 1つのバージョンを全てのユーザーに提供する
（例：Salesforce.comのユーザーは全てv30を
使っている）
• マルチテナント型でサーバ資源、データ領域など
も全ユーザーで共有される


クラウドの特徴
• サービスは超大規模化していく
– コンシューマー向けクラウドサービスの規模感
• 例：Gmail
– 自分のメール：21608件で、7369MB 中 515MB (6%) 使
用。100%だと約30万件
– 3700万UU（全米/2009年7月）YahooMailは1億600万UU
– 兆の単位も見えてくる？
• 例：twitter（ツ゗ッター）
– もう少しで40億つぶやき
– UU4450万人（全世界/2009年8月）※ツールは含まない
– リゕルタ゗ムで処理量をみてみる
» つぶやき：http://www.twitpocalypse.com/
» 写真：http://twicsy.com/#realtime
– 一般的な企業システムとは桁が100倍～1000倍
ぐらい違う


クラウドの技術
• 規模の経済をいかに実現するか
– コンピューテゖングリソースはハードウェゕ構成に
制限をうける。いかに複数のハードウェゕを1つの
サービスに見せるか
– スケールゕップでは不可能。スケールゕウトを実現
するための各種の技術
• 例：MapReduce、仮想化技術
– スケールゕウトを実現するために失うものもある。
• CAP定理
• ACID特性よりもBASE特性

ハードウェゕの限界

<スケールゕップ> <スケールゕウト>

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

・・・・・
・ MAP ・ SHUFFLE ・ REDUCE ・・
・・・・・
・・・・・
・・・・・
・・・・・
・・・・・


• CAP定理による整理
– CAP定理：共有データについて次の3つの特性のうち、2つだけ
しか同時には達成できない
– データの整合性：Consistency
– システムの可用性：Availability
– ネットワークの分断：Partition
– 超大規模データを扱うためには、データ整合性を犠牲にするし
かない（犠牲にしない方法がないわけでないが、あまりにコス
トがかかる）

C A C A

P P

エンタープラ゗ズ的な発想：クラウド的な発想：
データ整合性と可用性は絶対。それ分散は前提。可用性がなくては使え
ほど規模がいらないので分散しないないため、整合性を捨てるしかない

• ACID特性
– エンタープラ゗ズでは、ACID特性を実現するために、データ
ベーストランザクション処理を利用するのが一般的。
• Atomic(原子性)
– トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行され
ないことを保証する性質
– 失敗した場合はロールバックで、すべての処理がなかったことになる
• Consistent(一貫性)
– トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保
証する性質
– テーブルやリレーションの制約条件
• Isolated(独立性)
– トランザクション中に行われる操作の過程が他の操作から隠蔽される性知る
– あるセッションによる処理が実行中は、他のセッションからは変更されている
データが見えない
• Durable(永続性)
– トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的と
なり、結果が失われない性質
– データベースエンジン自体が異常終了してもログを利用して処理を戻す
– 分散トランザクションでは、ツーフェーズコミットが行われる。

http://ja.wikipedia.org/wiki/ACID_(コンピュータ科学)

• BASE特性
– クラウドでは、システム全体としてBASE特性を実現する。
• Basically Available（基本的に可用）
– キュー、楽観的排他制御、レプリケーション
• Soft-State（柔軟な状態管理）
– あるノードの状態は、その内部に埋め込まれた情報によって決まるのではなく、
外部から、送られた情報によって決まる性質
– あるノードの状態が、いったん、失われても、定期的に状態情報を取得すれば、
状態は復元される。
• Eventual Consistency（最終的な一貫性）
– システム内に、一時的に一貫性でない状態が生まれても、ある期間の後には、一
貫性ある状態になるような性質
– 簡単に考えると「一時的にはデータの整合性がない」「ダメ
だったらやり直せばいい」
– ACID特性を否定するものではない。BASE特性と組み合わせて
利用することが可能。マシン間は完全なBASEで、マシン内は
ACIDなど。
• バッチ処理やフゔ゗ル転送などはBASE特性といえる
• 実はエンタープラ゗ズでも良く活用している手段


クラウドへの期待
• 真のユーテゖリテゖコンピューテゖングが実
現するのではないか
– 必要な時に必要なだけ使える
• ニコラス・G・カー「クラウド化する世界」
– 「電力供給において自家発電が中央発電所に置き換わっ
た」ようにクラウドはユーテゖリテゖコンピューテゖング
を実現する
– コンセントにさせば電気が従量課金が使えるように、コン
ピューテゖングリソースが得られる
– ITサービスにも同じコトがおきる
• もはや自家発電は緊急設備、過疎地、工事現場にしか
なくなってしまった
• 同じように自社システムがなくなり、巨大なクラウド
に飲み込まれていくのかもしれない
• ガバナンスの問題は時間が解決する



– 『巨大な発電装置を可能にしたのは、発電装置、トランス
ミッション、電気モーターなど、工業化学全般における
数々の発明だった。しかし、こうした成功を確実にしたの
は、技術ではなく経済だった。中央の発電装置から多くの
消費者まで電気を供給することで、発電所はエネルギー製
造において、個人工場が到底かなわない「規模の経済」を
確立した。』
– ニコラス・G・カー「クラウド化する世界」
UNIX magazine 2009年4月号クラウド特集
Copyright © 2009 Growth xPartners, Inc. All rights reserved. 「クラウドは企業ユーザーに受け入れるのか？」

• とはいえ「過度な期待」
– コンピューテゖングリソースは電力ではない
• 電力は純粋にエネルギーであり、その利用形態は利用
者側に託される（掃除機、冷蔵庫…）
• コンピューテゖングリソースはサービスであり、利用
形態は提供者側に縛られる（Amazon EC2とGAEと
Salesforce.comは互換性がない）
– ゗ンフラサービスについては利用形態（いわばコンセント
の形状）について標準化策定が進んでいる
• 電力は送電（ダウンロード）されてユーザーの元に届
く
• コンピューテゖングリソースを利用するには情報を送
信（ゕップロード）する必要がある
• ただし、適合する事例も存在する
– 「必要な時に必要なだけ」


• エコポ゗ントの交換申請サ゗ト
– 主体は環境省、経済産業省、総務省
– 「想定申請件数2000万件、仕様書/発注予算曖昧、
7月1日稼働必須、システム稼働期間10ヶ月」
– という電話が5月28日に来た
• そもそも公募時期が5月中旬

「エコポ゗ント」の情報システムがわずか３週間で完成した理由
Copyright © 2009 Growth xPartners, Inc. All rights reserved. http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT31000026082009

• エコポ゗ントの交換申請サ゗ト
– システム概要：エコポ゗ントの登録と交換用申請
書の印刷
• いくつかのベンダーでの見積もりは数百億円～1000億
円。10ヶ月しか使わないシステムにそこまではかけら
れない
– そこでSalesforce.comに相談
• 要求定義は走りながら考えた。構築は正味3週間
– 官公庁案件でありながらの採用
• “今回は、まさに、官公庁の人が、メンタル・ハザード
を越えて、実質的な効果を選択してくれたことです。
間違いなく、一番安く実現したことも事実です。” 宇
陀栄次
「エコポ゗ント」の申し込み画面はクラウド上に。開発期間わずか1カ月？－ Blog on Publickey
http://www.publickey.jp/blog/09/1.html


クラウドを利用する上での課題
• コスト
– 長期利用前提であまり利用量が変わらないならオン
プレミス（自社所有）の方がTCO（総保有コスト）
的に安くあがる可能性が高い
• 自家用車とレンタカーの関係と同じ
• Amazon S3はストレージ１GBあたり月額15セント、つまり
約15円。1TBのデータを１ヶ月保管すると15000円＋デー
タ転送料
• １TBのエンタープラ゗ズ・ストレージ約20万円。TCO推定
は60万円（ハードウェゕ価格はTCOの30%程度）。ラ゗フ
サ゗クルを5年とすると月額10000円で転送料金不要で高速
– クラウドコンピューテゖングは安上がりではない
– http://blogs.itmedia.co.jp/kurikiyo/2009/01/post-3c62.html

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


• セキュリテゖリスク
– 他者に情報を委託することに発生するもの
• 1. 特権ユーザーによるゕクセス
• 2. コンプラ゗ゕンス関連
• 3. データの保管場所
• 4. データの隔離
• 5. データの復旧
• 6. 調査に対する協力姿勢
• 7. 長期にわたる事業継続性
– クラウド・コンピューテゖングが抱える7つの“セキュリテゖ・リスク”
– http://www.computerworld.jp/topics/saasw/114209.html

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



– 前述の朝日新聞社説より
• 半面、クラウドが抱える問題点も膨らむ。グーグ
ルに対しては、ネットを通じて世界中から集めた
利用者の情報を囲い込む「情報支配」への懸念が
以前から指摘されてきた。プラ゗バシーは守られ
るのか。利用者が不利な立場に追い込まれないか。
• そうした懸念を解くためにクラウドの巨人をどう
監視するかは、両社が本社を置く米国はもちろん、
国際的にも議論していく必要がある。


ここまでのまとめ
• 本セッションにおけるクラウドの定義
– 「゗ンターネット越しに、必要な時に必要なだけ使う各種
コンピューテゖングリソース」
• 特徴
– 規模の経済性
– 超大規模
• 技術
– スケールゕップよりスケールゕウト
– CAP定理。ACID特性よりもBASE特性
• 期待
– 過度な期待ではあるが適用事例はある
• 利用上の課題
– ガバナンス上のリスクあり
– TOCでは安くはないが形態にメリットはある


SOAとは
• まずは企業の現状を整理
– 不況を背景にした（古くて新しい）課題
• ともかくコストを安く
• 既存/新規システムの再利用性を高めたい
• ビジネス環境の変化への追随性を高めたい
• これまで人手でやっていた業務を効率化したい（管理
の厳密化）
– テーマ
• 社内外で求められる多様なシステムを全体最適化する
• 自社IT資産のポートフォリオをきちんとマネジメント
していきたい
– 技術的な注目点
• いかにしてシステムを統合していくのか？


SOAとは
• システムの統合をいかに実現するか
– 必要に合わせて結合度を調整することが重要
• 密であれば統合コストはさがる。大量一括処理が可能
• 疎であれば統合コストはあがる。逐次処理が可能
• なんにせよデータベーススキーマが共通化されていて変換コ
ストを低くすることは重要

密疎

ビジネスプロセス
データベース共有マネジメント

フゔ゗ル転送

RPC
レプリケーション Solving Integration Problems using Patterns サービスバス
Copyright © 2009 Growth xPartners, Inc. All rights reserved. http://www.eaipatterns.com/Chapter1.html

SOAとは
• 企業の現状からみたSOA
– ハ゗プ曲線では”啓蒙活動期”にあり、改めて定義の整
理が行われている段階
• 狭義には「業務上の一処理に相当するソフトウェゕの機能を
サービスと見立て、そのサービスをネットワーク上で連携さ
せてシステムの全体を構築していくことを指す言葉」
– http://ja.wikipedia.org/wiki/サービス指向ゕーキテクチャ
– 広義には「多様なゕプリケーションを疎に統合する
ための様々な手法」
• ESB ：Enterprise Service Bus
• BPM ：Business Process Management
• MDM：Master Data Management
– SOA製品が必要なわけじゃない。大事なのは「疎に
統合する」という概念
• 多くのSOA製品が密結合の手法についてもサポートしている


SOAから見たクラウド
• 両者の背景的な違い
– クラウド：規模の経済性。より多くのユーザーに
サービスを届ける
– SOA：全社最適。多様なサービスをどうマネジメ
ントするのか
• 両者の技術的な違い
– クラウド：サービスの水平スケール
– SOA：サービスの疎統合
• 企業システムから見たクラウド
– VS オンプレミス
– レンタカーと自家用車の使い分け


• クラウドは全社最適化手段の1つ
– エコポ゗ントを最適化として考える
• 所有するよりもコストが安く上がる
• 資産（BS）ではなく経費（PL）
• ただしガバナンスの問題は別
• クラウドを導入する場合は、既存システムの
連携が課題
– クラウドを利用するためには基幹システムとの連
携が必要であり、そこでSOAを活用することがで
きる
– SOAであれば交換コストを低減しておくことがで
きる
– 適切な事例は出てきていないが既に存在する

• クラウドへの接続は大きくは問題なし
– APIが提供されていれば、それを利用可能
• Salesforce.com
– Force.com WebサービスAPI
– Force.comメタデータAPI
– ない場合は自力で作ればいい（そもそも゗ン
ターネットに接続できるのだから）
• VPN接続サービスもはじまっている
– いずれにせよ標準的な接続手法で利用可能
• クラウド側からの接続については制限がある場合
も


• クラウドの使いどころ
– 最も効果的な適用箇所
• 大量処理で短期保有。長くとも5年（一般的な償却期
間）以内
– サービスごとに使い分けは必要
• Amazon EC2/S3
– サーバのCPUとストレージを利用する。様々なOSやミドル
ウェゕを利用可能
• Google App Engine
– Googleプラットフォーム（MapReduce、Key-Value
Store）を利用したゕプリケーションプラットフォーム
（Python/Java）
• Salesforce.com/Force.com
– 簡易リレーショナルデータオブジェクトを作成し、独自言
語（Apex）でUIやトリガーを実装していくゕプリケーショ
ンプラットフォーム。データ中心的


• クラウドを使う場合の注意事項
– 利用における制限
• データ転送量の制限が大きい（コストではなく時間）
– 日本では太平洋がボトルネック。Amazon EC2では、だいたい
400-500KB/sなので10GB転送に7時間弱。DWHなど大量データ
が必要になる場合にはデータ転送量がボトルネックになる
• クラウド側のサービス形態に制限を受ける
– Salesforce.comの場合、組み込みのデータスキーマが既定されお
り、それを変えることができない。階層化されたリレーションは1
段階までなど細かい制約
• ガバナンスは言うまでもなく問題
– ただし時間が解決する問題もあるかも
• 直接ハードデゖスクを送付する形でのデータ入出力を可能に
する「AWS Import/Export」
• VPN接続を行う「Amazon Virtual Private Cloud」


まとめ
• クラウドは過度な期待の中にあるが、「゗ン
ターネット越しに、必要な時に必要なだけ使う
各種コンピューテゖングリソース」という定義
はウソではない
• 企業システムの全体最適はより重要な課題に
• SOAはシステムの疎結合を実現する手法
• 企業システムでクラウドを活用する場合にSOAは重
要な役割を果たす
– 全体最適は、これからも課題でありつづけるが、
銀の弾丸は存在しない
• ハ゗プ曲線に影響されずに技術を見極めて自社シス
テムのポートフォリオ管理を


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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (13)

More from Yusuke Suzuki

More from Yusuke Suzuki (20)

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