Contenu connexe Similaire à Intalio japan special cloud workshop (20) Plus de Daisuke Sugai (20) Intalio japan special cloud workshop5. Why?
• 今回お話をする内容は、MKI様より以下のリクエストがPOC実施時にありました。
• Object Builderを利用し、テーブル定義がほぼ同一のアプリケーションを構築する場合、毎
回同じ属性を入力しなくともよい仕組み
• 当時の実現方法としては、以下の通りでした。大規模のシステム構築では一般的です。
• 現在のステータスは、開発側は1年間何も進展がない為、廃止されております。
1.設計書作成
ユーザー Excel
SQL文
2.マクロ実行 3.手動でコピー
Intalio Cloud
5
6. Weak Point
• Object Builderに対する改善は、以下の通りになります。
• プレビュー画面がない
• 設定する項目が多いと時間がかかる
• Object Builder全体の機能が不明
• 不要な共通項目を毎回、削除せず、自ら定義したい
• テンプレートとなる設計書が存在しない
• 一度作成したObjectのコピーができない
• 開発側に要望を出していますが、実現するか否か不明です。
• 設計書→画面の自動作成の仕組みは、既に他社製品では実現済になります。
• 開発側の対応が待つ=ビジネスに取り残される事になり、どのようにすればよいか?
6
7. Resolution
• 開発者が開発時に何をするのか、という視点で、日本側がWeak Pointを解消するツール作成
• Cloud環境にデプロイする前に、プレビュー画面で確認
• システム開発は特定の人が全てを決定するのではなく、ユーザーが自らシステム開発に参
加が可能なツールを提供
• ユーザーが対応できない詳細なデータベース設計等はシステム開発者が対応
• 設計書→ソースコードの自動化を実現し、開発コストを削減
• 自社のテンプレートとなる仕組みの提供
• 将来、ソースコード→設計書の仕組みも考慮
• プログラミング言語はVBA, ExtJS, Rubyというメジャーな言語を利用し、将来は誰もが改良できる
構成を考慮(英語版への対応はなし)しています。
• ユーザーがシステム開発に参加する場合、以下の点のみ理解すればよい、と考えています。
• 表示したい項目は何か?
• 画面に表示する項目の配置は?
• 一覧画面に表示する項目は?
7
8. Overview
1.設計書作成 2.マクロ実行
ユーザー
ExtJS
Excel プレビュー
*シュミレーション
3.提供 同一ファイル
Ruby Intalio
Excel XSPファイル
Cloud
SI
4.マクロ実行 6.スクリプト
5.設計書追加 実行
8
9. Overview
• 設計書の構成は、以下の通りです。
• 画面に表示する項目
• 画面に表示する項目の詳細
• オプションリスト等に定義する項目の設定
• リレーションシップの設定
• 画面に表示する項目の配置
• 高度検索・一括更新画面の作成と定義
• 一覧画面に表示する項目とルール
• ボタンバーに表示する項目
• アコーディオンバーに表示する項目
• システム共通にて使用する項目・画面の設定変更
• システム開発者はExcelのシートを再表示する事で上記の項目の参照が可能です。
• ユーザーとのヒアリング時・ユーザーに提供して記述する等、どちらも対応が可能です。
9
16. Roadmap
1.設計書作成 2.マクロ実行
ユーザー
ExtJS
Excel プレビュー
*シュミレーション
2011年1月より開発着手予定
3.提供 同一ファイル 2011年5月より開発着手予定
Intalio Developers
Ruby Intalio
Excel XSPファイル
Cloud
SI
4.マクロ実行 6.スクリプト
5.設計書追加 実行
ExtJSがNode.js(サーバーサイドJ
avaScript)より呼出
16
18. Google App Engine
• WebアプリケーションをGoogleのインフラ上に作成する事が可能
• Googleがインフラの構築、維持、管理等を行い為、インフラの知識は不要
• PythonとJavaが現在はサポート(JVMで稼働するJruby, Scala, Groovyも稼働)
• Googleに登録した後、無料で利用する事が可能(一定の基準以内)
SI ユーザー
Google
18
19. Why?
• これから説明しますアプリケーション「Idea Packet(アイディアパケット)」は、三重県へ出張中にコンセプト
をまとめました。
• 単純なパターン化した仕事のシステム化
• 自分専用のコピーロボットを作成し、インターネット経由でアクセス
• 業務フローを可視化する為に、マジカ!を利用し、記述し、当時、スターロジック(現在、マジカジャパン)
を訪問した際、羽生様・可世木様にマジカ!の利用方法を確認しました。
• 全体のフローの問題点はなし
• 当時、レンタルサーバーと契約しており、レンタルサーバー上での稼働を考慮したが、無料でアプリケー
ションをデプロイが可能な環境(=Cloud)が存在する事を発見しました。
Personal
知らない言葉 メールで送信
Googleで検索
知らない単語 後で確認
Team, Group
メールで送信
後で確認
19
20. What is Magica?
• 実際に記述しましたマジカ!のシートを本日は持ってきております。
• UMLでお客様と打合せをした結果を記述する事は可能ですが、お客様に渡す時、お客様側にUMLの知
識が求められます。BPMNについても、同様です。学習コストを最小限にし、お客様が理解できるツール、
現時点ではマジカ!が一番上記の条件を満たしていると考えております。
• 最近はお客様がシステム開発に自ら参加したい、という傾向は強いです。しかし、お客様が参加できる場
所は現状では打合せのみ、設計書等のレビューのみ、というケースが多いと思います。お客様自身が参
加できる為のツール、Object-genについても同様のコンセプトで考えております。
• 楽ができる所は楽をする
• 委譲できる所は委譲する
• ヒアリングでの対応を減らす
• 入力と記述、両方を比較した時、記述した方が印象が残っており、思い出しやすい、という事もあります。
20
21. Requirement
• 自分の行動を考慮すると、以下のAPIが必要であると判断しました。
• Google
• Yahoo
• Amazon
• 楽天
• Twitter (Public Timelineではなく、絞り込みが必須)
• YouTube (未対応)
ユーザー Application
GoogleAPI メールで送信
YahooAPI メールで送信
Request
選択可能
AmazonAPI メールで送信
楽天API メールで送信
21
22. Comparison
• 以下の図は、当時調査した各Cloudの調査結果です。
• サポートは一切使用せず、無料で構築するという観点から判断しています。
• 結論として、Google App Engineが調査時点では一番良く、かつTwitterを利用する事で有志の方々に質
問も可能である点も考慮しました(実際は、自力で解決)。
Stax.net Force.com Google App Engine
参考文献(書籍は全てなし) ×(Wiki) ○ ○
メーリングリスト/ブログでの状況 × △ ○
アプリケーション構築への知識 DB △ ○ ×(BigTable)
アプリケーション構築への知識 アプリ ○ ×(Apex) ○
管理コンソール関連 △ △ ○
開発ツールの提供 ×(コマンド) ○ ○
Cloud環境への申請時間 ×(遅い) ○ △(面倒)
Cloud環境へのデプロイ △(コマンド) ○(Eclipse) ○(Eclipse)
22
23. Public Cloud Development Strong Point
• Cloudでアプリケーションを開発する場合、開発に向いているアプリケーション・向
かないアプリケーションが存在する事は理解していますか?
• 向いているアプリケーション
• 開発者が5人以下のシステム(1人でも可能)
• 簡単, コスト安, 短期間で作成するシステム(→将来は大きく育てる)
• ユーザーの意向<開発の意向、であるアプリケーション(レスポンスタイム等の制約)
• 向いていないアプリケーション
• レガシーシステム
• バッチプログラム(ネットワークへの負荷)
• RDBで作成したアプリケーションのリプレース(Key-Value型)
• 開発者が5人以上になるシステム
• 集計・フィルター等がSQL文で簡単に実行できない為、リアルタイムで集計処理が多いシステム(開
発工数は、通常のアプリケーション以上にコストがかかる)
23
24. New Development Style Service
• 初期費用0円、月々15万円というプランでサービスを構築する会社が存在し、注目されています。
• 対象範囲は、ExcelやAccessで利用しているシステムの置換えを焦点にしております。
24
25. Java Developer Survival
• 景気状況が良くなく、特にJavaの開発者が余剰である会社が多いです。
• Javaの開発者、特にレガシーシステムのみ経験した開発者は、現在の知識のみでは、プラットフォーム・
基盤開発を担当しない限り、今後明るい未来はありません。
• Google App EngineやMicrosoft Azureはギグーな人だけが対応可能なプラットフォームではありません。
• Google App Engineは2009年4月に公開され、2年間も経ていなく、HTML5等の技術を組み合わせる事で、
新たな可能性を秘めております。
• Google App Engine/Microsoft Azure, 共にデータベースはKey Value型(KVS)である為、新たにマスターし
なければならない事がありますが、勉強した分が成果となって現れてくる可能性が高いです。
Java Developer
Key value 型(KVS)
開発時の様々な制約回避
Google App Engine Microsoft Azure
25
26. Intalio Cloud and Google App Engine
• Global IP addressで接続が可能なIntalio CloudとGoogle App Engineとの接続は可能です(×VPN)。
• Intalio Cloud, Force.com共通のweak point はUIで、UIを自由度が高いGoogle App Engineを利用し、作成
します。
• Google App Engine側にあるBig Tableは検索スピードが速い為、Cache的な役割として考え、外部に公開し
ないデータはIntalio Cloud等のプライベートクラウド側に保存します。
1.簡単に作成
2.公開/非公開データ判別
3.非公開データ移行
Google App Engine Intalio Cloud
From GAE to Intalio Cloud
•Remote API/published Mashup
From Intalio Cloud to GAE
•?
26
27. Intalio Cloud and Google App Engine
• Intalio Cloudからのデータを直接取込む場合、Intalio側の変更により、影響を受ける可能性が高い為、ラ
ッパーを用意する事を推奨します。
• ラッパー内ではIntalio Cloud特有の処理を記述し、Google App Engineの開発者にはIntalio Cloudの構成
等を隠蔽し、詳細を理解しなくとも、実行可能な仕組みを構築する必要があります。
Google App Engine Intalio Cloud
Wrapper programming
1.公開済のMashup
前提条件: 実行時: 2.IN:Mashupのパラメーター
1.UIを用意 1.登録したMashup呼出 3.OUT:Mashupの実行結果
2.Mashup登録 2.実行結果取得
3.同時に、関連情報登録 3.パーサーを利用
4.Entityへ格納
(Reflection未使用)
27
28. Progress
• 実際、構築しましたアプリケーションの話を進めていきます。
• 開発実施期間
• 7月下旬~9月下旬まで
• 週末にコーディング、平日の移動時間にアーキテクチャーの確認・技術調査
• フロント・バック
• フロントは未対応(来年、jQuery等のJavaScriptのフレームワークを利用し作成)
• バックはChannel APIに対応予定(来年に実装予定)
• ソースコード提供・共同開発も視野に入れております。
28
29. Development
• 環境 ローカル
• フレームワーク:Slim3 (http://sites.google.com/site/slim3appengine/)
• OS:Windows7
• IDE:Eclipse 3.5
• Plug-in:Google plug-in
• JDK:1.6
• 環境 Google
• デプロイ先のアプリケーション設定
29
32. Framework
• Slim3
• Seaser2 チーフコミッターである比嘉さんが作成し、コミッターが増加中
• Google App Engine用のMVCフレームワーク
• 特に、BigTableに対しての処理をラッピングしている点が他にない
• Antを実行し、スケルトン+Unitテストのコードを自動生成
• 学習コストも非常に低く、使いやすい
• 理由:
• SAStruts, S2JDBCを利用した開発経験あり
• BigTableについて詳細に調査する時間がなく、フレームワークを利用する事でデータベース関係を
フレームワークに依存
• 参考書籍:
32
33. Architecture
Front Back
• 一般的なフロー
UI Controller Service Model
• Google App Engine上でのフロー
Meta
UI Controller Service Model
TaskQueue Memcache
Cron
33
34. Notes
• 30秒ルール
• 現象:
Google App Engine上では30秒以内にトランザクションを完了しない場合、タイムアウトが発生
外部のAPIを呼出、ループにて複数の検索を実行する為、30秒以内でトランザクションが
完了しないケースが発生(Google App Engineではスレッド処理は不可)
• 解決策:
上記を解決する方法として、Cacheに実行結果を一時的に格納
格納した結果をTaskQueueより取得し、メール処理を実行
• メール送信数制約
• 現象:
Google App Engine上ではメールを送信する時、1分間に20通のみメールを送信する事が可能
検索結果を1通に1検索結果にした場合、制限オーバーが発生
• 解決策:
メールを送信する際、TaskQueueを利用すると同時に、メールを送信する件数、スリープ時間を
設定し、3秒間に1通のメールが送信できるように制御
34
35. Notes
• 30秒ルール回避方法
①
Request Service BigTable
データ ②
登録
Memcache
②
③ ④
TaskQueue Service API
外部 ⑤
データ ① API
取得
Cron 2minites Memcache
②
③ ④
TaskQueue Service Send mail
メール ① ⑤
送信 BigTable
Cron 1minites
35
36. Notes
• インスタンス数/キュー
• 現象:
ユーザーからのリクエスト後、リクエスト→Queue→Instanceの割当が実施
大量にリクエストすると、1秒以上処理がかかり、インスタンスの上限を超える現象発生
Queueに大量のデータが格納されると、Instanceに割り当てる事ができず、トランザクションの
処理前にタイムアウトが発生
• 解決策:
TaskQueueを利用し、一連の処理を短い時間で処理が可能なアーキテクチャーを考慮
処理を細かく定義し、1秒以上かからない仕組み
1秒以上
Google
Request Queue Instance Transaction
制限 制限
30秒タイムアウト(サーブレットが起動してから)
10秒タイムアウト 30秒タイムアウト
36
37. Notes
• ログ・メールの実行結果
• 現象:
ローカルの環境では、メール送信のテストが不可
System.out.printlnがUnitテスト以外(アプリケーション実行中)では出力されない
• 解決策:
Google App Engine上にデプロイし、テストを実行する必要が発生
Google App Engine上にはテスト・開発用のアプリケーションを作成し、運用しなければ
ならない為、開発者がデプロイする時、気を付けなければならない
• BigTable
• 現象:
Google App Engine上ではRDBではなく、BigTableを利用している為、今までのRDBの知識では
太刀打ちできない
• 解決策:
ISID社が提供するSlim3(=フレームワーク)を利用
BigTableについては英語圏のサイトを参照する事で理解する事が可能
リトルソフト社が提供するBigTableをRDBでラッピングする仕組みを利用
37
38. Notes
• スレッド不可
• シングルスレッドのみ CPUリソース等リソースオーバーを懸念
• ファイル書込不可
• ファイル読込は可能 スケールアウトした場合のファイルの保存先が不明
• ファイルアップロード数と量の制限
• 10M以内/3000ファイルまで
• リクエスト・レスポンスのサイズ制限
• 10M以内
• Javaクラスの制限
• SwingやClassLoader等、JRE標準でサポート(稼働)しない処理が存在
38
40. Strong Point
• Cron
• メール処理
• リクエスト作事処理
• ユーザーからのリクエスト処理(API呼出)
• TaskQueue
• 各処理結果を格納
40
41. Strong Point
• Query実行結果の確認
• Model=Entityとなり、レコードの削除等が可能
• API提供(以下を利用)
• Users API(Gmail認証)
• Mail API
• Memcache
• Task Queue
41
44. Roadmap
• フロント
• jQuery取込
• jQueryは実案件では利用した事がない為、かつ情報も多い為、利用予定
• jQTouch(スマートフォン・モバイル向け)
• HTML5取込
• スマートフォンでの利用を考慮
• バック
• ChannelAPI実装
• サーバープッシュ型の機能(Jettyに存在するCometdと同様)
• 新規API追加
• Idea Packetのフロントからのリクエストを処理ができるAPIがあれば、取込予定
44
45. 最後に
• Force.comはチュートリアルは実施しましたが、Apexを新しくマスターする為に、学習コストがかか
る為、詳細な調査は行っておりません。VMForce利用後に再度、調査する予定です。
• Window Azureについては、来年調査する予定です。既に構築するアプリケーションの構想は存在
し、かつWindows7環境に開発環境は、用意できております。参考文献等にて、詳細を確認後、実
施します。是非、参考になるURL等がございましたら、情報交換ができれば、と考えています。
• Cloud環境では、対象ユーザー、要件、期間、コスト等、制約事項が存在する為、今まで以上に
ユーザーから正確に要件の詳細をヒアリングする必要があります。
• つまり、Cloud環境、Cloud以外の環境等、実行環境を含めた要件定義書を作成する事が必須に
なります。
• Twitterからのデータ取得、というConsumer向けのアプリケーションをGoogle App Engine上で開発
した事例は勉強会に参加した時に聞きました。アクセス量が増加した時、料金を支払う事でス
ケールアウトができる点に注目をしている技術者が多いです。
45
46. 本日は、
ありがとうございました
ご質問・リクエストがありましたら、
Intalio Cloud Expertにご連絡をお願いします
mailto: sawada@intalio.com
mailto: sugai@intalio.com
46