HTML5のWeb Workersを追加してさらに高速仕訳入力

Cloud SQLで学ぶ業務・基幹系アプリ再入門（3）

ネットワーク送信のスピードアップとセキュリティモードでのデータ送受信

SPDY（SPeeDY=スピーディ）

　連載の前回と今回では、Cloud SQLを基本とするWebシステム構成での処理スピード向上に焦点を当てて見てきました。Cloud SQLはGoogleのPaaSクラウドApp Engine上で稼働しますが、GoogleはWebの高速化にこれまで意欲的に取り組んできており、その成果としての新たなネットワークプロトコルにSPDYがあります。SPDYはGoogle Chromeではすでに有効化されており、ChromeでGoogle検索やGmailなどのGoogleサービスにアクセスすると自動的にSPDYを利用した通信が行われています（注1）。また、GAEにはサーバプッシュのChannelサービスがあり連載でも紹介する予定ですが、Channelサービスでの送受信ともにSPDYは使用できます。

注1：Google検索でのSPDY使用

図9　Google検索画面でのSPDY使用

　ChromeでGoogle検索の画面を表示すると、図9のように、スキームにhttpsが指定され、画面右に緑色でのマークが表示されます。このマークが「緑色」の状態がSPDYでネットワーク通信を行っていることを示しています。

SPDYによる高速化の仕組み

　HTTPセッションでは、先に送ったリクエストに対するレスポンスが返ってこないと次のリクエストが送れない、という基本的な制限があります。これに対してSPDYでは1本のHTTPSセッションの上で、複数のリクエストを多重化するというアプローチを採用しており、高速かつ低コストでのネットワークが実現されます。また、トラフィックを下げるためにHTTPヘッダを圧縮するなど、それ以外にも高速化のための工夫がされています。

　ところで、複数のリクエストを1つのセッションで多重化するのはHTML5のWeb Socketでも実現されており、違いは何なのかという疑問もでてきます。これについて、高速のための技術的アプローチは、SPDYとWebSocketであまり違いはなく、決定的な違いは使用するための容易さです。 つまり、SPDYの方が圧倒的に容易に使用することができます。例えば、WebSocketで多重通信を行うためには、そのためのコードをWebクライアント側のJavaScriptおよびサーバ側の両方で書かなければなりません。これに対してSPDYでは追加のコード記述を行わないで使用することができます。

図10　SPDYによるHTTPセッションのリクエスト多重化

　なお、SPDYに関する公式文書は英文ですが下記サイトに掲載されています。

• 「SPDY: An experimental protocol for a faster web」

仕訳データ登録でスピーディを使ってみる

　次に連載の仕訳データ登録画面での処理をSPDYモードで実行してみます。前に触れたように、SPDYモードでアプリケーションを実行するための特別なコード記述は必要ありません。サンプルはGAE上で稼働していますが、簡単な設定の変更だけで使用することができます。

図11　SPDYモードの仕訳データ登録画面

　連載ではブラウザにSPDY対応のChromeを使用しています。この場合SPDYを有効にするためには、GAEの管理者画面から、表示するアプリケーションをデフォルトバージョンに指定し、後は図11のようにバージョン指定なしの「https」指定で画面を表示するだけです。プログラムの変更はまったく必要ありません。SPDYモードが有効になると画面右上にグリーンでのマークが表示されるので、これで確認することができます。

図12　SPDYモードでの勘定科目表示

　次にSPDYモードで借方コードから勘定科目を表示してみます。SPDYでネットワーク送信速度を確認する訳ですから、ここは当然画面右上で「クラウドストレージ」を選択して実行しますが、図12のように385ミリ秒で勘定科目が表示されています。

図13　SPDYを使用しない勘定科目表示

　次にSPDYを使用しないで勘定科目を表示してみます。これはhttpsをhttpに変えるだけで済み、図13右上のSPDYマークの色がグレーに変わります。図のようにSPDYを使用しない場合は440msでSPDYにより12%～13%ほどスピードアップされていることが分かります。ただしこの比率は、実行のたびにかなり変わる場合があり、ほとんど変わらない時もあります。これは、SPDYはSSL（TYL）モードでのみ使用できますが、SSL自身がセキュリティ機能実行のためのオーバヘッドがあり、SPDYによる高速化の効果が相殺されてしまうためです。

　なお、仕訳データの登録ではテストを行っていませんが、SPDYの効果は検索時（下り）に発揮され、クライアントからクラウドサーバへの送信時（上り）には効果がありません。

SSL

　SSL（Secure Socket Layer）を使用したhttpsリクエストは、GAEのデフォルトドメイン名（appspot.com）では以前から使用できましたが、2012年6月にリリースされたversion 1.7.0からユーザが指定するカスタムドメイン名でも使用できるようになっています（有料）。

　クラウド導入に否定的な意見として、クラウドはセキュリティに弱いということがよく言われます。この場合、セキュリティという言葉は多面的な意味で使われていますが、ユーザ認証でのセキュリティという点では、GAEクラウドのセキュリティは弱いとは言えません。SSLは銀行のオンライン・バンキングと同じ強固な（パスワードや送受信データの盗聴・解析が事実上不可能な）セキュリティレベルです。

最後に

　前回と今回の2回に渡って、仕訳データ登録での処理スピード向上について見てきました。最後に紹介したSPDYのようなネットワーク送信での機能改良によってもある程度のスピードアップ効果は見られますが、それよりWeb StorageやWeb Workersを使用したクライアントとサーバの連携、ストレージアクセスのパターンを変えてしまう方が比較にならないほど処理スピードが向上します。しかし今回紹介したやり方はすべてのUIで適用可能とは限らないでしょう。一方SPDYは汎用的に使用できるので、その場合はSPDYの利用も検討する必要がでてくるでしょう。今回のサンプルはほんの一例ですが、これからのシステム設計では、このようにいくつかの最新テクノロジーを組みわせて検討することも必要になってくると思われます。

　次回は、最近ユーザ数が急激に増え、業務処理用としての使用も進んでいるスマートフォンとCloud SQLの連携を、在庫管理のサンプルで見ていく予定です。