集中と分散 スマートフォンとクラウド連携の アプリ開発と分業の実際
1 like1,621 views
タイトル： 集中と分散 スマートフォンとクラウド連携の アプリ開発と分業の実際 講演： RIAアーキテクチャ研究会 第3回セミナー 2012-03-10
集中と分散 スマートフォンとクラウド連携の アプリ開発と分業の実際
- 1. 集中と分散 スマートフォンとクラウド連携の アプリ開発と分業の実際 カブドットコム証券 社長付 IT戦略担当 谷口有近 / たにぐちありちか @arichika / Facebook?Google+ 実名で ※本公演および資料についての免責、商標、ライセンスについては最後のページをご覧下さい。
- 2. 本日のセッション概要 セッション概要/アプリの概要 KC/10m. スマフォ×クラウドにおけるUXとは？ クラウサービス特有のUX的解 2FC/30m. Azureにハイトランザクションをたたき 込む！の事例 金融系アプリにみるUXの重要度と 分業最適化への期待 KC/20m. 2
- 3. ちょっとだけ 本題に入る その前に 3
- 4. 技术动向10年 （あれ、RIAの話…は？） ユーザー企業の 時代認識 4
- 5. 技術的バズワードの変遷 | ’96 | ’97 | ’98 | ’99 | ’00 | ’01 | ’02 | ’03 | ’04 | ’05 | ’06 | ’07 | ’08 | ’09 | ’10 | ’11 | w95OSR2 w98 w2k wXP wVista w7 IE3 IE4 IE5 IE6 IE7 IE8 IE9 .NET1.0 .N2.0 .N3.0 .N3.5 .N4.0 NN3 NC4.5 N6 N7 FF1 N8 FF3 FF4-7 <HotJava GC1 GC2-8- GC14 CSS1 Gecko CSS2 jQuery CSS2.1,3 Dynamic HTML LOVE LETTER Nimda SQL Slammer/Blaster Ajax(JS+XML) HTML5 Draft ePUB HTML4.01 DeNA NASDAQ DeNA????? BigData Web2.0 Hadoop ^DJI mixi GOOG Cloud(us) Cloud(jp) Cloud Foundry GREE <AMZN twitter マッシュアップ Azure SaaS Salesforce Facebook Heroku G.AppEng. WP7.5 BlackBerryJP BlackBerry Mac OS X iTunes iPhone Android WP7 iPad Connectix Virtual PC → MS NK225 Hyper-V L2広域/SDN VMware WS VMware ESX VMware GSX → Server Cisco UCS ‘88 メインフレームPR/SM 月刊アスキー廃刊 MS独禁法NSDAQ急落 ライブドアショック L.B. ショック ITバブル崩壊 米)???????? 米)代替市場ATS 欧)?????????? 米)NMS施行 米)NYSE Linux 日)東証新シス 米)????台頭 日)B.B.元年 - - - - - - - いざなみ景気（第14循環） - - - - - -- - 日)株式委託手数料自由化 日)????話題 日)金商法?PTS 5
- 6. 技术を概念で整理してみる 機能拡張 → WebAPI UI → UX 独自仕様 vs.業界標準 標準仕様化 疎結合 高度化?高速化 既存体験/業務の 新しい事を CGM SNS Web化 Webで 音楽?書籍 音楽データ 書籍データ 物理所在の流通???化 流通???化 流通???化 タブレット モバイル体験 家族PC/会社PC 個人/ノートPC マルチ 携帯→スマホ デバイス SaaS/ASP パッケージ PaaS IaaS IA仮想化 汎用機的IA 汎用機 エミュレート → hypervisor 自作IA → PCサーバ 物理回帰 Grid?IA分散高度化 ルール変更 客層変化 競争力変化 情勢把握 自由化 個人投資家 スピード/規模 監視強化 6
- 7. 7
- 8. 時代認識の共有：別の切り口… 法人/家族毎 個人毎 デバイス毎 百貨店的 コンビニ的 通販的 共有的 数値を見る 統計を見る 相関を見る 要求コスト/単価 物流革命 情報革命 モノ→情報 権利革命 機械化の模索 品揃え(≒個性)の模索 個性を創造 要求規模 計画通り 未体験を +速く創る 造る 創る 速く辞める 8
- 9. 9
- 10. 10
- 11. 金融を支える技術の米日比較 | ’96 | ’97 | ’98 | ’99 | ’00 | ’01 | ’02 | ’03 | ’04 | ’05 | ’06 | ’07 | ’08 | ’09 | ’10 | ’11 | Hadoop BigData Cloud(us) Cloud(jp) 米)???????? 米)代替市場ATS 欧)?????????? 米)NMS施行 米)NYSE Linux 日)東証新シス 米)????台頭 日)株式委託手数料自由化 日)????話題 日)金商法?PTS 11
- 12. 12
- 13. 坚いと噂の金融业界どうよ （RIA…） 金融業界の 時代認識 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. （実は先端の）国内金融をサマる 元来、銀行さんは勘定系の共同利用が主体 今でいう ”クラウド” に実は近い。メインフレーム /IAの違いとも。 勘定系については Wikipedia が良く纏まってる http://ja.wikipedia.org/wiki/%E5%8B%98%E5%AE%9A%E7%B3 %BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0 SIer と 大手銀行 が作成した馬鹿高いシステムを複 数の地銀が共同利用する事でエコシステムを形成 “証券システム” も同様 NRI「THE STAR」/ DIR「SONAR」等 中小証券各社はいくつかのシステムにぶら下がる 18
- 19. 国内金融の変化 金融システムの自製化 UNISYSオープン勘定系 Windows 2003 + COBOL の Bank Vision セブン銀行の Bank Start も同様 参考：UNISYS技評 28-1 通巻96 カブドットコム証券 取引システム?勘定系 取引 Windows NT / 勘定系 Solaris で開業 オープン基盤で自社構築 → Windows が 99% 新生銀行勘定系、ATM等 Windows 2000 で勘定系を構築 SBI証券発注システム Linux ベースでNRIと再構築 19
- 20. 20
- 21. 全部じゃないですよ さすがに 21
- 23. 谷口 有近 / たにぐち ありちか / @arichika 2000年 ホットリンク社 勤務 2001年 カブドットコム証券 入社 インフラ基盤の改善、構築に主に従事 2005年 マイクロソフトMVP （だったw） Infrastructure Architect → 消滅した！ 2006年 課長代理→ 2007年 課長職 へ 運用面、基盤面を中心に現場職と管理職に従事 2009年 ITプロフェッショナルエバンジェリスト 開発と運用の垣根を越えた最適化や情報提供、広報活動 2011年 社長付IT戦略担当 <= いまココ 部門を超えて、R&Dの側面でIT業界の動向を調査 新規案件のFSやシステム部に寄らない開発等 23
- 24. 24
- 25. で 本 題 25
- 26. 今 ”当社” に足りないもの 変化に追従 できる開発運用体制 それはつまり ”フレームワーク” と ”インフラ” “クラウドコンピューティング” のコア技術の理解 スケールアウト前提ミドルウェアで、開発生産性の 向上と運用の標準化がどうしても必須 お客様の 想像を超える“アイデア” お客さまの体験が豊かになるにつれて、競合他社製 品の使い勝手、品質だけでなく、別の世界の経験 （iPhoneアプリ/FX）と比較 され始めている UX設計視点の開発力が勝負に 26
- 27. 27
- 28. Azure と Windows Phone 7 Microsoft Azure 基盤が目指してる世界 ＝エンタープライズで使える “PaaS クラウド” “開発生産から運用までのライフサイクル”で最適化 Windows DNA の事実上の直系 構築ノウハウって結構な勢いで違うらしい Windows Phone 7.5 が目指してる世界 iPhoneとは違う ”新しい” 体験にチャレンジ アプリベースからオブジェクト/ステートベースへ ＝情報の表現を変える事で誰にでも優しく Windows 8 へのフィードバックも期待 28
- 29. 時代背景を再確認 金融情報系にも 変化の胎動 株式の世界は “深く“ のアプローチが優勢だった アローヘッド?アルゴで ”知覚” で拾えない時代 データ量と描画速度の問題を超えられるか 新しい UXを支える技術 背景 Apple, Google, Twitter, facebook (←UIは未だ にタコだがAPIとデバイスの相性を再確認), etc. 高速応答前提のモデル?基盤設計 Zapping 向きの大量高速な情報表示も現実的に 29
- 30. 【再掲】技术を概念で整理してみる 機能拡張 → WebAPI UI → UX 独自仕様 vs.業界標準 標準仕様化 疎結合 高度化?高速化 既存体験/業務の 新しい事を CGM SNS Web化 Webで 音楽?書籍 音楽データ 書籍データ 物理所在の流通???化 流通???化 流通???化 タブレット モバイル体験 家族PC/会社PC 個人/ノートPC マルチ 携帯→スマホ デバイス SaaS/ASP パッケージ PaaS IaaS IA仮想化 汎用機的IA 汎用機 エミュレート → hypervisor 自作IA → PCサーバ 物理回帰 Grid?IA分散高度化 ルール変更 客層変化 競争力変化 情勢把握 自由化 個人投資家 スピード/規模 監視強化 30
- 31. 31
- 32. 32
- 33. 33
- 34. 慣れないと複雑な市場の ”モデル” 高値時刻(HHMMSS) 株価収益率 安値 純資産倍率 TSE 安値時刻(HHMM) 株主資本利益率 安値時刻(HHMMSS) 決算月日 売買高 貸株金利(年率) 売買高時刻 非危険利子率 最良売気配 売買高加重平均価格 OSE 最良買気配 日通し売買代金 最良売気配数量 単元株数 最良買気配数量 銘柄コード 最良売気配数量 銘柄略称 前日終値 銘柄略称（英語） 前日終値時刻 取引所コード 当日建玉残高 所属部 計算用現値 IV モデル整合性 計算用現値時刻 デルタ QUICK 現値前値比較 SQ日 騰落率 出来高 残存日数 売気配?価格 誤認勧誘 日通し売買代金 売気配?時刻(HHMMSS) システム障害 時価総額 買気配?価格 Reuter 配当利回り 買気配?時刻(HHMMSS) 事務処理ミス １株配当 インプライドボラティリティ … ほんの一例 法令違反 発注が関係すると、 もともっと大変になる 免責事項はあるが 考慮する事多し。 それぞれ、更新頻度,更新タイミングは、意味とソースに応じて変わる 34
- 35. 35
- 36. 36
- 38. Two Projects “kanna”, “kappa” Windows Phone 7 Application Codename “kanna” Scalable Application Platform based on “Microsoft Windows Azure” Application Platform Codename “kappa” On-Premises DataCenter 38
- 39. kanna Project Why “kanna” （カンナ）？ 10月（神無月）はプロジェクト山場（だったはず） 私の誕生月でもあったりする kanna の挑戦 株価情報系アプリに ありがちな既存UIに × まだ見ぬUXにチャレンジ UI/UX Lab チャンネル としての役割を担って欲しい 39
- 40. kanna Concepts メトロUIが提供する体験 とは？ 機能や対象に注目していたこれまでの ”アイコン”から脱 却 、対象物のステートを表現し、情報への到達を簡略化。 → People Hub のように、ザッピング感を強く表現する アプリを使う=機能を使う から、情報をクロールする先 に機能がある、という順序の変更 この発想は金融商品と相性が良いはず ユーザーは金融商品のアクティビティ（値動き）や ステート（価値）に興味がある。売買機能やニュー ス表示機能に直接興味があるわけではない 快適に情報をクロールする事への挑戦 40
- 41. kappa Project Why “kappa” （カッパ）？ Kabu.com Application “Powerful Platform” on Azure で KAPPA … ギリシャ語10番目で超ひも理論的で大変すてき kappa の挑戦 App Fabric を全力利用し金融 PaaS の限界を見る PaaS の構築運用ノウハウを理解する ハイトランザクションにチャレンジ 株式のリアルタイム（に近い）フィードをクラウド で提供って、まだ聞いた事がない 41
- 42. kappa Concepts クラウド～オンプレ連携を情報系から パフォーマンスならオンプレHPC / 可用性ならクラウド Azure という区切りは、ごちゃ混ぜになる事確実 情報系という PaaS クラウドと相性が良い領域で、PaaS のシステム構築ノウハウの獲得に積極的にチャレンジ クラウド経由のMVC/MVVMのノウハウ 守るべき部分は技術を使って高速化や高可用性にチャレン ジし、モバイルデバイス向けのデータセット（=View） をいかに高速に扱う事が可能かを、金融クオリティで整理 していく 快適なUXを実現するデータ提供基盤への挑戦 42
- 43. MVC-MVVM by Cloud-base REST API MVVMの図： http://blogs.msdn.com/b/erwinvandervalk/archive/2009/08/14/the-difference-between- model-view-viewmodel-and-other-separated-presentation-patterns.aspx より引用 REST/JSON API MVCの図： http://msdn.microsoft.com/ja-jp/asp.net/ff191275 より引用 43
- 44. 44
- 45. 45
- 47. 日本のお客さま、大変に拘る チャートには拘ります皆さま！ ローソク足の幅、間隔、フレーム、 色は変えてもいいけど拘りは強い 0点の位置とか 描画のZ軸とか 数字の位置とか 転換点の判定とか マウスの判定とか 同じでないと ご納得 いただけない 47
- 48. クラウドに持ってくだけなら簡単…だよね？ オンプレミス、実はかなりのチューニング 物理的な経路、WindowsのTCP/IPスタック等 経由する機器を減らすとか普通にやる もうマジでガチガチにやります クラウドでも同品質確保ってねぇ…無理… 48
- 49. クラウディアさん、ちょっと遠恋やわぁ… 60～100ms の TCP遅延 Window Sizre 次第で10Mbps～100Mbps ちなみに東証～うちの間は100Mbpsで、 3msの情報配信を上場3600銘柄でやる 細切れパケットで… UDP？ 専用線ならねぇ… しかも http か… アップロード無料で よかったねホント… http://www.microsoft.com/japan/presspass/detail.aspx?newsid=4076 より引用 49
- 50. kappa / kanna Infrastructures Azure Storage Table Worker role Worker role Web role Web role App Fabric Cache Updater. Updater Reader Reader REST full API Azure Storage Queue REST REST REST WCF API REST full API Generate resources by Real-time feeds. On-premises. Multi Devices. 50
- 51. 51
- 52. 52
- 53. Azure 側実装苦労話 開発者が天才変人なので F# 選んだw 関数型最高！らしい でも確かにいい（Mかも） 画像生成速度を確保するための設計 当初はあらかじめ大量の画像を生成しようとしてた 実装してみたらコードでの単体生成がかなり速くアドホッ ク生成に変更 もともとのコードも F# で画像生成 オンプレ認証情報のキャッシュに AppFabric Cache を利用 当初（意図的に）生成画像のキャッシュ用（メモリ 上のデータプールの意図）として AppFabric Cache を使おうとしたがライフサイクル管理で不適 切 → 結局オンプレ認証ハッシュの一時保存として 53
- 54. Azure 側実装苦労話 オンプレ→Azure への非同期アップロード パフォーマンス目標に達しない試験結果 日本だと業務データでのハイトランザクションへのチャレ ンジが出てこず、MS さんとも MTG 実施しまくり Entity Group Transactions (EGT) トランザク ション で 500件のデータを一括でアップロード 複数型のフィールド?データを持つオブジェクトを複数配 列として ProtoBuf でバイナリ化しキュー送信 Azureで取り出し戻してオブジェクトを処理、EGTで 500entity を一括 Upsert 結果、CPU 負荷激増したが目標達成 単発データ＋ Async.Prallel とかも試した（別の機会） データのバランスで性能が結構かわる まぁ結局インフラの事理解してないとダメだったね w 54
- 55. クラウドのデザインパターン とにかく極力非同期でやんなさい 昨日のOSは今日のOSと違うと思え 起動してきたら初期化コマンド無しで動くべき コマンドを投げるノード間通信も、データのやりと りも、とにかくTableなりQueueなりで非同期化 通信（ソケット）も切れるもの だから http という Azure データ投入はとにかく並列化意識 データをオンプレミス側でバッファし、まとめて投 入する仕組みで改善出来る ストレージアカウントを追加して対応することも出 来る オンプレミスの処理概念→大規模分散へシフト 55
- 56. 56
- 57. 【再掲】技术を概念で整理してみる 機能拡張 → WebAPI UI → UX 独自仕様 vs.業界標準 標準仕様化 疎結合 高度化?高速化 既存体験/業務の 新しい事を CGM SNS Web化 Webで 音楽?書籍 音楽データ 書籍データ 物理所在の流通???化 流通???化 流通???化 タブレット モバイル体験 家族PC/会社PC 個人/ノートPC マルチ 携帯→スマホ デバイス SaaS/ASP パッケージ PaaS IaaS IA仮想化 汎用機的IA 汎用機 エミュレート → hypervisor 自作IA → PCサーバ 物理回帰 Grid?IA分散高度化 ルール変更 客層変化 競争力変化 情勢把握 自由化 個人投資家 スピード/規模 監視強化 57
- 58. 58
- 59. 59
- 60. 60
- 61. 付録 ライセンス 本資料は、各項にて特段の捕捉が無い限り、CC-BY 2.1 JP ライセン スによって許諾されています。ライセンスの内容を知りたい方は http://creativecommons.org/licenses/by/2.1/jp/ でご確認くださ い。 資料中の引用文献?引用資料については、上記対象外です。 商標 カブドットコム証券株式会社の登録商標または商標についての情報 は ”知的財産権に関する情報” http://kabu.com/company/disclosure/ip_report.asp をご覧くださ い。 その他、記載されている会社名、製品名は、各社の登録商標または商 標です。 免責 本公演は事例紹介としての情報提供のみを目的としており、特定の金 融商品等について好意的否定的を問わずその価値判断について、情報 提供者の見解を述べるものではありません。 情報の内容につきましては万全を期しておりますが、その内容を保証 するものではありません。万一この情報に基づいて被ったいかなる損 害についても、情報提供者は一切の責任を負いかねます。 61
- 62. Thank you. 62