ページ表示要求 セッション ID Webアプリケーションの応答性と 開発効率を向上させるページ構築手法 ページ破棄 ①ページ要求 セッション ID 再接続 再接続 初期化処理 ユーザー Web サーバ ブラウザ ブラウザ DB 図1．Web サイト表示までの流れ ̶ ブラウザからのページ要求を契機に， データ検索からページ構築までをWebサーバで行います。 Web サーバ ユーザー 図 3．HTTPストリーミングの仕組み ̶ HTTP での切断を可能な かぎり遅延させ，切断が発生するまでの間は，Webサーバから任意の タイミングでデータを送信できます。切断後はすぐに再接続し，接続 状態を維持します。 WebSocket への ブラウザ アップグレード DB ごとの SQL に変換 検索要求 接続が維持され続けるため， 常にデータ送信が可能 ページ送信 ページ破棄 実的となりました。しかし，既存のWebアプリケーショ SQL 無害化 検索結果 ページ構築 以内に表示するようなアプリケーションのWeb 化が現 DB SQL の解析 データ応答 変化するデータを可視化しながら，障害発生を一定時間 Web サーバ 拡張 SQL 接続 とが可能になりました。監視制御システムなどで，刻々と ブラウザ 図 5．ブラウザでのページ構築実行によるページ遷移時間の削減 ̶ Webサー バで行われていたページ構築をブラウザ側で実行させ，既存のページやデータを 活用して更新領域を狭め，ページ遷移時間を削減するとともに更新方法の柔軟性 を向上させました。 データ要求 でのデータ変更を，即座に低負荷でブラウザに伝えるこ ネイティブ アプリケーション＊ ページ遷移時間 無応答時間 テーブルの 見せ方の設定 ブラウザに見せるテーブル 初期化処理 ンフレームワークからの恩恵を受けにくく，開発効率の低 拡張部分の処理 下やアプリケーションの応答性に問題がありました。 ページ表示 ユーザー そこで東芝は，ページ構築方法の最適化とブラウザから ブラウザ ブラウザ Web サーバ ける必要がありました。 Web サーバ Web サーバ DB 図 2．実現できない処理の流れ ̶ HTTP では， ブラウザからのページ要求 なしに，DB 上のデータ変更に応じて Webサーバからブラウザにページを送信し， 表示を変化させることはできません。 くなり，開発効率が低下するという問 図 4．WebSocket の仕組み ̶ HTTP での接続後，WebSocket プロトコルへアップグレードして接続を維持し続けます。接続が維持 されるためデータ変更を即座に通知できます。また，セッションIDも 不要です。 けを送信するように変更しました。 DB ＊端末内で直接実行可能なアプリケーション 図 6．ブラウザからの SQL 発行 ̶ DB 上のテーブルに対して簡単に SQLを発 行できる仕組みを構築しました。これにより，多くの部分は簡単な設定だけで Webサーバ側のアプリケーションを開発でき，開発効率が向上しました。 アプリケーションの多様な要求に応え 取得したり変更したりすることが可能 る柔軟性を持ち，かつセキュリティ上の になりました。またSQLでは記述困難 問題がないものでなければなりません。 な処理については，SQLを拡張し対応 社会インフラシステムの監視制御シ 題があります。また，ページ遷移（ページ この場合，ブラウザでのページ構築 Webサイトの表示は，図1に示すよ ステムでは，刻々と変化するデータを可 移動やページの部分的変更）が高頻度 には時間を要しますが，表示中のペー うに，ブラウザからWebサーバにペー 視化し続けるとともに，障害発生を一 で発生するため，低頻度では問題とな ジやデータを流用できます。それらを 監視制御システムの場合には，そのシ ジ要求を送信（①），Webサーバがデー 定時間以内に表示できなければなりま らなかった無応答時間（ページ初期化 可能なかぎり再利用することで，個々 ステム要件から，多くの場合単純なDB タベース（DB）のデータを検索しページ せん。このため，Webサーバ側にペー などに伴いユーザーへの応答ができなく のページ遷移における更新領域を狭め 問合せ言語のSQLをブラウザから発行 を構築（②），構築したページをブラウ ジ 要 求 を 繰り返 すことに なり，Web なる時間）への対策が必要です。 るとともに，多くの初期化処理を省略し できるAPIがあれば必要十分なことが ザに送信（③），ブラウザがページを表 サーバの負荷が増大します。 た結果，転送データ量を削減できまし わかりました。しかしブラウザからSQL Webアプリケーション開発をより効率的 た。これにより，処理全体としてのペー を発行する場合，見せてはならないテー に行うためのフレームワークを開発してい 示（④），という手順で行われます。 この 手 順 では，手 順 ① を省 略し， この問題に対処するため，HTTPを 拡張したHTTPストリーミング（注1） （図3） ページ構築をブラウザ側に 移植し無応答時間を短縮 今回の開発によって得た知見を元に， ブルにアクセスされるなどのおそれがあ ま す。 より多 様 なアプリケーション の Web 化にも対応できるよう機能拡充を行 ブラウザで動作するJavaScript 間も短縮できました。また，この方式 り，セキュリティ上の問題が発生します。 送信してブラウザに表示させることは いWebSocket（図4）などの新しいプロ はシングルスレッドで逐次的に動作する では Webサーバがデータ表示方法に依 そこで図 6 に示すように，Webサー できません（図 2）。これはブラウザ トコルが標準化されています。 ため，処理中はユーザーに対し応答でき 存しないため再利用性も高まりました。 バでSQLを解析し，不正なテーブルや， とWebサーバ間の通信プロトコルで これら新しいプロトコルを使用する ません。無応答時間の削減には，個々 あるHTTP（Hypertext Transfer 場合は，これまでの HTTPとの差異が のページ遷移に要する時間を減らす必要 Protocol）の制約によるものです。こ 大 き い た め，既 存 のWebアプリケー があります。そこで，図 5に示すように， の制約のため，DB 側のデータ変更に ションフレームワークの恩恵を受けにく Webサーバで行っていたページ構築を サ ー バ は ブラウザ に API（Application ブラウザで実行するように移植し，Web Programming Interface）を提供す これにより，簡単な設定だけで DB サーバはページ構築に必要なデータだ る必要があります。このAPI は，Web 上のデータを，ブラウザからセキュアに （注1） 投稿サービスのストリーミングAPI な どに使用。 今後の展望 ジ遷移時間は大幅に減少し，無応答時 と呼ばれるプロトコルや，より負荷の軽 は，ブラウザからページ要求を出し続 しています。 （†） Webサーバ側のタイミングでページを 応じてブラウザの表示を変化させるに 52 無応答時間 ページ表示 切断を遅延 ID：Identifier 策定された新しい通信プロトコルなどにより，Webサーバ Webアプリケーションの課題 データ応答 データ送信 ページ構築 切断 データ要求 ④ページ表示 HTML5（Hypertext Markup Language 5）で 仕組みの構築により，応答性と開発効率を向上させました。 ページ遷移 時間 接続が維持されている間， データを送信 ②ページ構築 セッション ID SQL（Structured Query Language）を発行できる 切断 切断を遅延 ③ページ送信 ページ遷移に伴う無応答時間を短縮し， Webサーバの開発効率を向上 非同期データ要求 接続が維持されている間， データを送信 データ要求 データ応答 ページ遷移時間 無応答時間 ページ表示要求 切断を遅延 接続 東芝レビュー Vol.69 No.12（2014） ブラウザからのSQL 発行を可能に ページ構築をブラウザで行う場合，Web カラム，レコードなどにアクセスしてい ないことを保障するとともに，テーブル うとともに，広く普及に努めていきます。 ・ JavaScriptは，Oracle Corporation及びその子会社， 関連会社の米国及びその他の国における登録商標 又は商標。 名やカラム名などのテーブル構造を隠 蔽できる仕組みを導入しました。 Webアプリケーションの応答性と開発効率を向上させるページ構築手法 古城 仁士 ソフトウェア技術センター 先端ソフトウェア開発担当 53
© Copyright 2024 ExpyDoc
