インタ ネット証券における インターネット証券における マルチクライアント開発事例 福岡ソリューション開発部 上席テク カルエンジ ア 上席テクニカルエンジニア 中野 裕隆 2014年11⽉11⽇ 講演内容 1. サーバサイドから⾒たシステムのマッシュアップと インターネット対応の事例紹介 2. 2 多様化するクライアント端末の開発現場 3. 肥⼤化するクライアント開発保守にどう向き合うか 1 第１章 サーバサイドから⾒たシステムのマッシュ アップとインタ ネット対応の事例紹介 アップとインターネット対応の事例紹介 2 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 ご紹介事例の概要 弊社が提供するオンライントレ 弊社が提供するオンライントレードシステム（B2B2C） ドシステム（B2B2C） 同時利⽤者は数万⼈ インターネット上にさまざまなデバイスに対してアプリケーションを提供 ① PCリッチクライアント ② Webブラウザ W bブラウザ ヘビーユーザー・⼀般ユーザ向け リッチクライアント ⼀般ユーザー向け ④ デジタルサイネージ 対⾯⽀店設置⽤ 3 ⑥ RSS (EXCEL Real time Spread Sheet) ③ スマートフォン/ タブレットクライアント ⼀般ユーザ向け 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 システムが企画された2005年当時の状況 店頭端末 ロイタ Q C 社 ロイター・QUICK社 等の情報端末 ＴＰモニター通信 受発注システム 取引所 売買システム 専⽤線バイナリ通信 投資情報システム ビデオ配信 ビデオシステム 4 リアルタイム情報 システム 取引所 相場報道 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 情報系機能と受発注機能のマッシュアップ ①システムの性能の差異 求められた情報系機能と受発注機能のマッシュアップ 発注 各システムで想定している利⽤者数や レスポンス時間が異なる 履歴 情報 インタ ネ ト インターネット 多種のオンライン トレーディングクライアント ④クライアントの複雑性 クライアントが各システムに対して 同時に多様な通信が⾼頻度で発⽣ ③多種多様なプロトコル通信 多種多様なクライアントとの通信を⾏うた め、インターネット上で利⽤できるプロト コル（通信フォーマット）が必要 5 銘柄 情報 ﾁｬｰﾄ ﾃﾞｰﾀ 板 ﾃﾞｰﾀ 受発注システム 投資情報システム リアルタイム情報 システム 取引所 売買システム ②多⼤なPush通信 相場報道データが送信頻度が⾼く （約10万件/s）、その更新に中継 サーバ サ バ、及びクライアントCPUを 及びクライアントCPUを 圧迫してしまう 取引所 相場報道 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 受発注システム（アクセスを集中させない仕組み） Ｒ／Ｒサ バ Ｒ／Ｒサーバ Cacheサーバ Cacheサ バ 受発注システム 証券取引所への発注 や投資家の取引履歴 データを持つ デ タを持 証券 取引所 銘柄のマスタや株価データな どヒストリカル情報を持つ 弊社投資情報 システム 多種のクライアント Topicサーバ Ｐ／Ｓサーバ 6 Feedサーバ 最新の株価データを フィード配信する 弊社リアルタイム 情報システム Cacheサーバのメモリキャッ シュを検索。存在しない場合 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 は受発注システムへ 受発注システム（アクセスを集中させない仕組み） Ｒ／Ｒサ バ Ｒ／Ｒサーバ Cacheサーバ Cacheサ バ 受発注システム 注⽂情報取得の リクエスト 証券 取引所 Cacheサーバでそのデータを キャッシングし、R/Rに返却 多種のクライアント Topicサーバ Ｐ／Ｓサーバ 7 取得対象のデータをDBから 取得し、Cacheサーバに返す 弊社投資情報 システム Feedサーバ 弊社リアルタイム 情報システム 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 受発注システムから Cacheサーバのメモリキャッ C h サ バのメモリキ 受発注システム（アクセスを集中させない仕組み） シュを更新 データを取り直す Ｒ／Ｒサ バ Ｒ／Ｒサーバ Cacheサーバ Cacheサ バ 受発注システム リアルタイム発注情報 証券 取引所 マルチキャスト 送信 多種のクライアント 各種クライアント にデータをPush Topicサーバ Ｐ／Ｓサーバ 8 弊社投資情報 システム Feedサーバ 弊社リアルタイム 情報システム 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 投資情報システム（アクセスを集中させない仕組み） Ｒ／Ｒサ バ Ｒ／Ｒサーバ 別途クライアントからのデータ取 得リクエストに対して、R/Rサー バのキャッシュから返す さらに、R/Rサーバ起動時にも 予めFeedサーバから現在の最新 Cacheサーバ Cacheサ バ 受発注システム 断⾯データをキャッシュ Feedサーバ起動時に予め現在の 最新断⾯データをキャッシュ 弊社投資情報 システム 多種のクライアント Topicサーバ Ｐ／Ｓサーバ 9 証券 取引所 Feedサーバ 弊社リアルタイム 情報システム 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 リアルタイム情報システム（CPU利⽤率を抑える仕組み） Ｒ／Ｒサ バ Ｒ／Ｒサーバ Cacheサーバ Cacheサ バ 受発注システム メモリキャッシュ の内容を更新 証券 取引所 マルチキャスト 送信 多種のクライアント 各種クライアント にデータをPush Topicサーバ Ｐ／Ｓサーバ メモリキャッシュの内容を更新 内 して、Topicサーバに送信 10 弊社投資情報 システム リアルタイム情報 ・最新株価 ・板情報（気配） など… Feedサーバ 弊社リアルタイム 情報システム 数msec単位でバッファリ 数 単位 バ ングして間引き処理 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 多種多様なプロトコル通信 ①リクエスト/リプライ ・XML・CSV ・HTTP GET/POST・HTML JSON JSON ・JSON・JSON ②Push通信 ・バイナリ ・CSV WebSocket ・WebSocket ・SPDY 開発時期やクライアントの開発フレームによって、 通信プロトコルの変遷を強いられてきた 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 多種多様なプロトコル通信 デバイスの画⾯の⼤きさにより⼀度に表⽰できるデータが デバイスの画⾯の⼤きさにより 度に表⽰できるデ タが 異なるため、必要になるデータも異なる ※株価ボードを例として、クライアントが表⽰する情報を表に⽰す。 銘柄ｺｰﾄﾞ 現値 銘柄名 始値 ⾼値 安値 出来⾼ 前⽇⽐ 値幅上 限下限 PC版 ○ ○ ○ ○ ○ ○ Web版 ○ ○ ○ ○ ○ ○ 携帯W b 携帯Web ○ ○ ○ ○ ｽﾏｰﾄﾌｫﾝ ○ ○ ○ ○ ○ 信⽤ 情報 ○ ﾌｧﾝﾀﾞ ﾒﾝﾀﾙ ○ ○ ○ ○ ○ ○ ○ Excel 全てのデータを返すことは⾮効率的であり 全てのデータを返すことは⾮効率的であり、CPUや CPUや メモリの圧迫につながる。 デバイスに合わせたデ タを返すべき デバイスに合わせたデータを返すべき 12 ※上記の表は、実際我々が開発しているのものとは多少異なります。 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 多種多様なプロトコル通信 • 変換フィルターを介してレスポンスを返す – ビジネスロジックは全デバイスで共⽤ – アスペクトを適⽤することにより、電⽂プロトコルの変換と電⽂ 適 ⽂プ 変換 ⽂ 量の調整のロジックをビジネスロジックから分離 R/Rサーバ サ バ プロトコル変換 フィルタ 情報量調整 フィルタ 共通ビジネス ロジック 多種のクライアント 13 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 クライアントの複雑性 • デバイスの画⾯サイズやユーザの設定によって画⾯レイアウトが異な るため、同⼀のタイミングで取得する情報の単位も異なる • それぞれの画⾯要素は同⼀であっても、組み合わせは無数となり、BL の数が膨⼤にな てしまう の数が膨⼤になってしまう 銘柄⼀覧 板・ その他銘柄情報 その他銘柄情報 銘柄⼀覧 関連ニュース 歩み値 関連ニュース 14 同⼀のタイミングで複数種類のデータ取得を、様々な チャ ト チャート チャート 組み合わせで取得しなければならない 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 クライアントの複雑性 • IoC（Inversion of Control） 画⾯の組み合わせ分のサーバActionを作る冗⻑性を回避するための 仕組み ① １回のリクエストで要求するBLの組み合わせを クライアント主導で動的にコマンドを作成して送信 ② クライアントより渡されたコマ ンドに従ってBLをコールする。 ビジネス ロジックA IoC （クライアントにコン トロールされる制御の 逆転機構） 多種のクライアント 15 ③ 動的なレスポンスとしてそれぞれ のデータセットへ適⽤ ビジネス ロジックB ビジネス ロジックC 1. サーバサイドから⾒たシステムのマッシュアップとインターネット対応の事例紹介 第１章のまとめ マッシュアップの問題点とアプロ チ マッシュアップの問題点とアプローチ ①各システムの性能の差異 ⇒ ・キャッシュの利⽤ ・ネットホップの削減 ②多⼤なPush通信 ⇒ ・マルチキャストによりサーバからネット機器へCPU利⽤量を移管 ・断⾯データの間引き ③多種多様なプロトコル通信 ⇒ ・アスペクトの利⽤により、BLとプロトコルを分離 ④クライアントの複雑性 ⇒ IoCにより、要素単位のBLと呼び出しアクションを分離 16 第２章 多様化するクライアント端末の開発現場 17 クライアント開発における開発⾔語選択の観点 ①開発対象の機能要件が満たせる事 ②実⾏時の軽快性（省CPU,省メモリ） ③⽣産性、再利⽤性の⾼さ ④開発要員、保守要員の確保、教育の容易さ ①、② ③、④ 常にトレ ドオフな関係にある 常にトレードオフな関係にある。 18 各種クライアントの利⽤技術 弊社が提供するクライアント、デバイスの利⽤技術 主な利⽤技術 MS系技術 NET ・.NET ・Silverlight クライアントの種類 Win PC版 汎⽤Web版 汎⽤W b版 MS Excel RSS デジタルサイネージ HTML5 Objective-C 19 汎⽤携帯端末版 IPone/IPad版 対象OS Windows Windows、MacOSなど Wi d M OSなど Windows（Excel） Windows Android端末、iOS端末など iOS .NETによるアプリケーション 対象デバイス ■PC版 ・Windows ■Web版（Silverlite版） ・Windows、MacOS ■MS Excel RSS版 ・Windows ・MS Excel ■デジタルサイネージ版（Silverlite版） ・Windows 20 .NETによる開発 ⼦ウィンドウ（分析チャート） ⼦ウィンドウ（分析チャ ト） メイン画⾯ ⼦ウィンドウ（SS発注） 21 .NETによる開発 22 .NET（Silverlight）による開発 メイン画⾯ 23 チャート画⾯ .NET（Silverlight）による開発 24 MS Excel RSS MS Excelに⼀覧を作成し、リアルタイム⾃動更新させることが出来る さらに 当⽇の注⽂情報や約定情報の取得 注⽂も可能 さらに、当⽇の注⽂情報や約定情報の取得、注⽂も可能 25 MS Excel RSS 26 デジタルサイネージ 27 .NET版の動作概要 DataSetの変更箇所か ら⾃動で画⾯ｺﾝﾎﾟｰﾈﾝ ⾃動 ﾄに反映 クライアントプログラム 初めの取得のみ サーバプログラム .NETランタイム NETランタイム 画⾯ ｺﾝﾎ ｰﾈﾝﾄ ｺﾝﾎﾟｰﾈﾝﾄ 変更を受けイベントを発 変更を受けイベントを発 ⽣、更新箇所を光らせる ⽣して、値の描画。この 描画を⾏う。 とき、値が⼊った箇所を 光らせる描画を⾏う ・このとき、CPU利⽤率 このとき CPU利⽤率 の削減のために、バッ ファリングして光らせる イベントの発⽣を抑える。 28 ⾃ 動 バ イ ン ド DataSet (Bean) D t S tへの反映 DataSetへの反映 更新 処理 Push 受信部 Push受信 ・全く同じ値のPushの場合 にはセットしない ・⾃動バインドにより、ModelとViewの完全分離 ・C⾔語やC++⾔語に⽐べソースコードの量も少なくて済む （約3分の1程で済んでいる） .NET版 CPU利⽤率 CPU利⽤率をほぼ ５％以内で抑えられ 以内 抑えられ ている。 最も激しいときで、 ⼀時的に１３％程度 29 .NET版の開発現場 ⾼⽣産性 開発ツール ・Visual Studio vs 性能問題 プロファイラツール ・ ANTS（Red Gate社） 開発 ・.NETコンポーネント .NETコンポ ネント ・オブジェクト指向⾔語 開発 ・⼀部 Win32API ・⼀部、Win32API 30 .NETによる開発のメリット、デメリット メリット ●⽣産性・再利⽤性が⾼い ●要員削減が可能、要員確保が容易 ●その他 ・WEB版は、SilverlightのランタイムがFlashなどに⽐べ軽い WEB版は Sil li htのランタイムがFl hなどに⽐べ軽い ・PC版、WEB版、RSS、デジタルサイベージで共通コードの 流⽤が可能 デメリット ●軽快性の確保には専⾨的知識や⼯夫を要する 31 HTML5による開発 対象デバイス iOS端末（IPh IP d） ・iOS端末（IPhone、IPad） ・Android端末（スマートフォン、タブレット） 発注 チャート 32 リアルタイム株価 HTML5による開発 33 HTML5によるアプリケーションの動作環境 配布⽅式 ・アプリケーションとして提供 HTMLの確実な動作を保障 ・HTMLの確実な動作を保障 端末 ネイティブAPL ③次の動作時に、 デプロイサーバ デプロイサ バ Versionを確認 Version 情報 HTML5 ｱﾌﾟﾘｹｰｼｮﾝ ①まずは、ネイティブAPLを ダウンロード 34 ②初めのときにDL HTML5 ｱﾌﾟﾘｹｰｼｮﾝ ④今あるVirsionより新しい場合 ④今あるVi i より新しい場合 は、いったんキャッシュ内のア プリを削除して最新をDL HTML5版の動作概要（開発フレームワークの変遷） 「Sencha」を利⽤ ・View、Model、Controlの分離が不⼗分 ・⾃動バインド機構がないため、Pushの実装が不可能 ⾃動バインド機構がないため、Pushの実装が不可能 （リソース⾯で） クライアントプログラム 画⾯ ｺﾝﾎ ﾈﾝﾄ ｺﾝﾎﾟｰﾈﾝﾄ マ ッ ピ ン グ ②更新されたデータ を画⾯ｺﾝﾎﾟｰﾈﾝﾄに マッピング DataSet (Bean) ③描画更新 35 更新 処 処理 ①ポーリング（定期 的なデータ更新） サーバプログラム HTML5版の動作概要（開発フレームワークの変遷） 「AngularJS」に移⾏中 ・⾃動バインドの機構がある ・ View、Model、Controlの分離開発が可能 View Model Controlの分離開発が可能 ・「SPDY」を⽤いたPushが可能 HTML5でも.NET版と同様のア キテクチャで実装可能に ⇒HTML5でも.NET版と同様のアーキテクチャで実装可能に クライアントプログラム 画⾯ ﾎ ﾈ ﾄ ｺﾝﾎﾟｰﾈﾝﾄ ③DataSetの変更箇所から ⾃動で画⾯ｺﾝﾎﾟｰﾈﾝﾄに反映 ⾃ 動 バ イ ン ド DataSet (Bean) ①初めの取得のみ サーバプログラム 更新 処理 Push 受信部 ②SPDYによる Push受信（検討中） 36 HTML5版の開発現場 ⾼⽣産性 37 vs 性能問題 機能実現性 開発ツール ・Webstone ・Visual Vi l St Studio di デバッガ、プロファイラ ・Google Crome 開発 ・HTML5 HTML5 ・JavaScript ・フレームワーク 開発 ・画⾯コンポ ネントはほぼ⾃作 ・画⾯コンポーネントはほぼ⾃作 （JSの肥⼤化） ・ネイティブコードの利⽤ （デバイス特有のUIの実装） HTML5による開発のメリット、デメリット メリット ●⽣産性・再利⽤性が⾼い ●要員削減が可能、要員確保が容易 デメリット ●軽快性に問題が⽣じる場合がある ●機能要件が満たせない場合もある ●その他 ・⾔語仕様的にタイプセーフでない ・実装フレームワークが成⻑途上である 38 Objective-C（ネイティブ⾔語）による開発 機能要件として、「実⾏時の軽快性」や「デバイスUIをフル活⽤ 機能要件として 「実⾏時の軽快性」や「デバイスUIをフル活⽤ すること」が第⼀に求められた場合 全て、ネイティブ⾔語で作成という選択 対象デバイス ・iOS端末（IPhone IPad） ・iOS端末（IPhone、IPad） 39 チャート 板 発注 Objective-C（ネイティブ⾔語）による開発 IPhone版 40 Objective-C（ネイティブ⾔語）による開発 IPad版 41 Objective-Cによるアプリケーションの動作要件 電波状況によりPush通信の動作を動的に変更 ・３G：⾃動更新なし ・LTE：ポーリング（定期的な更新） LTE：ポ リング（定期的な更新） ・wifi：Pushによる更新 デバイス固有のUI動作を反映 ・縦や横に傾けたときの表⽰切換え 「スワイプ」による銘柄切換え ・「スワイプ」による銘柄切換え ・「ロングタップ」による設定画⾯の表⽰ ・「シェイク」による画⾯遷移 ・⾳声⼊⼒ ⾳声 ⼒ 42 Objective-C版の動作概要 ３G接続時、LTE接続時 ３G接続時はクリックなどの 動作をトリガーとして最新値 動作をトリガ として最新値 をサーバから再取得 クライアントプログラム 画⾯ ｺﾝﾎﾟｰﾈﾝﾄ 反 映 サーバプログラム コレクション （Bean） 更新 処理 LET接続時はポ リング LET接続時はポーリング wifi接続時 コレクションの変更箇所を画⾯ｺﾝ ﾎﾟｰﾈﾝﾄに反映させ部分的に再描画 クライアントプログラム 画⾯ ｺﾝﾎﾟｰﾈﾝﾄ 43 反 映 コレクション （ （Bean） ） （内部で定期的に⾃動更新） 初めの取得のみ 更新 処理 Push 受信部 CSVによる Push受信 サーバプログラム Objective-C版の開発現場 ⾼⽣産性 vs 開発ツール ・Xcode 開発 ・Objective-C ・フレームワーク「Cocoa」 フレ ムワ ク「 」 44 性能問題 デバッガ、プロファイラ ・Xcode 開発 部分的にC⾔語によるコ ディング ・部分的にC⾔語によるコーディング ・画⾯デザインに専⽤のエディタを使 うと動作が重くなる →UIコンポーネントも⾃作 UIコンポ ネントも⾃作 →データバインディング部分も⾃作 ネイティブ⾔語による開発のメリット、デメリット メリット ●実⾏時の軽快性の確保が容易 ●難しい機能要件にも対応できる デメリット ●⽣産性・再利⽤性が落ちる ●要員確保が困難 教育にも⼿間がかかる ●要員確保が困難、教育にも⼿間がかかる ●その他 低レベル⾔語のため、メモリリークなど安定動作のためのテ スト観点が増える 45 第３章 肥⼤化するクライアント保守にどう向き合うか 46 ３.肥⼤化するクライアント保守にどう向き合うか • クライアント技術と携帯端末には流⾏り廃りがあり、移り変わりが激しい クライアント技術と携帯端末には流⾏り廃りがあり 移り変わりが激しい • さらに、それら要素技術にはバージョンアップ（仕様変更）が⼊ることもよくある 2000年 ＰＣ （クライアント技術） 2005年 2010年 クライアント/サーバ アプリ型 リッチクライアント W bﾌﾞﾗｳｻﾞ型 Webﾌ ﾗｳｻ 型 リッチクライアント 携帯端末 携帯電話 iPhone iPad スマートフォン（Android搭載） その他 汎⽤技術 • 47 タブレット （Android搭載） HTML5 また、クライアントの数が増えると開発⾔語や技術が異なるため、 それぞれにおける開発要員や保守要員の確保、教育 開発要員や保守要員の確保、教育が必要となる。 ⾔語統⼀への動き HTML5で、.NETと同じアーキテクチャでの実装が可能 ⇒ 各ランタイム⾔語のHTML5化が今後⾏われるのでは！？ ⾔語統⼀に向けた動きの⼀例 .NET 書き直し (ActionScript) i i コンパイル ンパイル JavaScript 48 Flash ・Microsoftが開発したスクリプト⾔語 ・オープンソース ・オ プンソ ス ・タイプセーフな⾔語 ・オブジェクト指向⾔語 ・.NETやFlashのActionScript等に近い⾔語 ・現在、VisualStudio2012、2013に追加イン ストールにより利⽤が可能 .NET開発者による 開発者によるTypeScript TypeScript開発 yp p 開発が ・.NET 今後の主流になる可能性も ・全てのクライアントがこのTypeScriptで開 発され、開発⾔語の統⼀が可能かも？ ⾔語統⼀を妨げるもの 新ツールの向上 ・IDE ・プロファイラ プロファイラ 新フレームワーク 向上する デバイスリソース 軽快なプロトコルの 提唱 新⾔語 ・⾼レベル⾔語 ⾼レベル⾔語 ・フレームワーク VS ネイティブ⾔語 新デバイスの登場 ・OSバージョンアップ ・wearable化 不⾜する デバイスリソ ス デバイスリソース 肥⼤化する 機能要件 ⻑期的には ⾔語統 の⽅向に向かうだろうが ⻑期的には、⾔語統⼀の⽅向に向かうだろうが・・・ 49 ３.肥⼤化するクライアント保守にどう向き合うか ① サーバサイドのアーキテクチャの設計 ・レスポンス応答の⾼速性 ⼤量アクセスへの対応 ・⼤量アクセスへの対応 ・プロトコル変換の⾃由度 ・BLの再利⽤性の向上 ② クライアントアーキテクチャの統⼀ ・MVC＋⾃動バインド機構の導⼊ ③ 開発⾔語の統⼀化 ・開発要員、保守要員の確保、教育の容易性 ・開発ノウハウの共通化 ・⽣産性の向上 50 51
© Copyright 2024 Paperzz
