既存サイトのスマートフォン対応とjQuery Mobile

iPhoneやAndroid等の携帯電話やタブレット端末向けのweb画面を作成するツールとして注目を集めているjQuery Mobileがついに11月に1.0版をリリースして正式版となりました。
正式版では、画面表示のスピードが大幅に改善されたとのこと。またカスタマイズしたデザインを簡単に作成するためのツールも公開されました。
「既存サイトのスマホ対応」というのが、今年は様々なところで聞かれた話題でしたが、jQuery Mobileはその課題を簡単にクリアできるツールとして初期のβ版のころから注目を集めていました。(弊社の既存サイトのスマホ対応のためにも、いろいろと研究というか、活用させていただいておりました)
AdobeのDreamweaverCS5.5が、html5およびcss3対応、さらにはβ版のjQuery Mobile対応ということでCS5からマイナー(?)ヴァージョンアップで発表されたのも今年の春でした。
jQuery Mobileの正式版のリリースで、既存サイトのスマホ対応がさらに促進されそうです。

既存サイトのスマホ対応を考える場合に、PC向けの画面をベースにするか、フィーチャーフォン向けの画面をベースにするかは、様々意見があるようですが、シンプルな作りで、開発のスピードを優先するならば、フィーチャーフォン向け画面をベースにした方が、やはり良さそうです。
またスマホ版を利用するユーザーの多くが、それまでフィーチャーホンで利用してきた既存ユーザーであるのであれば、UIを大きく変更せず、スムーズに移行して利用してもらうことにもメリットがありそうです。
そして、実際にスマホ版サイトを作成し、テストをして公開して実感することとして、概ねjQuery Mobileの機能に感謝しつつ、やはりAJAXの機能などに不安があることや、閲覧する環境(スマホで利用するブラウザの種別や設定)によって完全に同じ動作をしてくれるのかが不安な点があることも、実運用上は無視できません。
十分な開発期間と、多種多様な環境を用意して十分にテストができるなら、使える限りの機能を使いまわし、フィーチャーホンではとても実現できない高機能なUIを実現するというトライも考えられますが、まずは既存サイトのスマホ対応ということであれば。。。やはりこういう判断になるのかなーと。

以上、ひとりごとでした。

性能診断分析サービス事例 その3

シーマークすずきです.

最近,つけ麺にハマっています.自分的には約7年周期でつけ麺がマイブームになる,という事実...

さて,性能診断分析サービスの事例,第3段となります.今回は,性能向上です.

■サイト利用者から「ページが遅い」の声

あるコンシューマ向けWebサイトを運営しているお客様の事例です.その会社の事業部の責任者は,「ページが遅い」というサイト利用者からの意見が多くなってきていることを課題の一つとして認識していました.実際に,自分でブラウザで試してみても,時々詰まったような遅いページがあったり,特定のページが極端に遅い,という経験を実際に体感していたのです.サービス責任者としては,お客様のニーズに応えることが最も重要です.Webサイトとしてニーズに応えることに加えて,リーズナブルな応答時間内に,という性能観点の目標もあるのです.そこで,サービス責任者は「ページが遅い」というサイト利用者からの声に対して何らかの改善策を具体的に検討することになりました.

 

■暗中模索

まず,開発パートナー会社さんとインフラを提供しているインフラ会社さんに現行システムの性能向上のための施策案を検討してもらいました.しかし,開発パートナー会社さんからは,簡単に云えば「マシンが遅いからだと思う」や「DBが遅いから仕方ない」とか「デザインが重いから」という様なポイントが出てきて,インフラ会社さんからは,「アプリが遅いからどうしようもない」とか「DB側は遅いSQLが無いので問題ではない」という指摘が出てきてしまい,お客様のサービス責任者の方も困ってしまいました.「取り合えず,自分たちじゃない」という反応だったからです.現行システムを請け負っている会社としては,仕事を増やしたくないとか責任範囲外なので,ということをお客様に伝えたい気持ちがあるのでしょう.一種の自己防衛本能です.

サービス担当者は,暗闇の中で何かを探すような感じで,手がかりが分からないままに「手探り」状態でなんとかして問題を解決しなければなりません.そんな文字通り暗中模索の頃にお客様からご連絡を頂きました.

 

■まずは現状把握

まずは状況を正確に把握しなければ,対策案もでてきません.そこで性能診断分析サービスのアプリケーションの挙動を数値で計測する技術が活きてきます.本番環境で数値で計測した結果は何よりも説得力があります.仮に改善内容の方法にアプリの改修が絡んだ場合でも,開発パートナー会社さんも計測した数値で説明すると,「なるほど,これは改修の効果が期待できますね」ということでご納得してタスク化してもらえます.逆に,開発会社様からは,「本番サービス環境下では,このメソッドがこんなに時間がかかっているのですね.意外だなぁ.」と新たな発見をしてもらえることもあります.ともかく,本番サービス環境のアプリケーションの挙動を数値で計測することから作業を開始しました.

 

■課題は何か?

次は,課題は何か?です.お客様のWebサイトにはたくさんのメニューやコーナーがあります.まずは,そのメニューやコーナー事に時間毎応答回数や平均応答時間をまとめました.予めお客様から頂いていた,このWebサイト内のビジネス上の重要度が高いメニューやコーナー,重要シナリオ(ページ遷移)と見比べてみると,課題が明確になってきました.どうやら,以下の2つが優先的に対処すべき課題でした.

  • 検索メニューの応答性能が10秒以上になることが多々ある.
  • お申し込みメニューの平均応答時間が遅い.

サイト全体のプログラムを分析するのはそれはそれで時間と手間がかかりますが,ある程度絞って注力することで,深い診断と分析が可能となり,結果としてスピーディに成果を得ることができます.

お客様と相談し,改めて今回の課題に対する目標は,

  • 検索メニューの応答性能が悪化する原因を特定し,対策案を検討し,提案する.目標は平均処理時間30%短縮.
  • お申し込みメニューの平均応答時間を20%短縮.

となりました.

■処理内容の詳細分析

本番サービス環境で実際に稼動しているアプリーケーションの稼動状況を映し出すことにより,様々なことがわかってきます.

まずは,「検索メニュー」の方のリクエスト状況の分析です.特に,平均応答時間だけで見ているとスパイクして遅い応答リクエストが見えにくくなります.つまり,リクエスト回数が多いサイトでは,リクエスト数である分母が非常に大きいため,平均することで,時々発生している遅いリクエストが見えなくなってしまいます.性能診断分析チームが分析する際には,「平均値とは丸められた値である」ということを強く意識し,その計測区間の最大値(その計測区間内で一番遅かったリクエスト応答時間)も一緒にプロットするようにします(下図).こうすることで,実態が見えてきます.実際には10秒以上の応答時間だったリクエストは多発していることがハッキリしました.

 

更に,一回の検索リクエストの処理内容の内訳を以下の様に横軸が時間の図化することで,どのような処理に時間がかかっているのかが分かります.

この見える化は強力です.ここの事例とは別のお客様の例では,Webの1ページの画面を処理するために,アプリケーションから同等SQLが300回実行されている実態がこの図化によって明らかになったこともありました.一回のSQLが50ミリ秒だとしても,300回×50ミリ秒で15000ミリ秒,つまり,15秒です.しかも,よくよく分析してみると実は,1回のSQLで十分だったいうことがありました.既存のDAOコンポーネントを部品化した開発を行い,ループ中からDAOを呼出す作りだったのです.SQLは”表”で結果が取れるにもかかわらず...インフラ側のDB管理者は遅いSQLはチェックしていることが多いですが,流石に1アクセスの処理で大量にSQLを発行しているのか,複数リクエストにより1発づつ発行されているかは意識していません.

さて,話を戻します.図中のsearch()が横に細い時は全く問題ありません.しかし,横に長くなるケース,要は,処理時間が延びてくる現象が確認されました.塵も積もれば山となります.図から推察するに,search()はループ中で必要な処理回数呼ばれる様です.図では80回前後呼び出されている絵です.search()メソッドが10ミリ秒なのか20ミリ秒なのかは,高々10ミリ秒の差ですが,比率では2倍の差になります.つまり,大量に発行されている場合は,全体が3秒だった処理が2倍の6秒になる訳です.しかもその呼出回数が多数であるならば,さらに時間がかかります.遅くなっている原因は,カットオーバー後,取り扱いデータ量が増え,search()メソッドが順次遅くなってきているためでした.開発側と相談し,該当ソース箇所をレビューした結果「四重ループ」が確認されました.

 

■多重ループに注意

プログラムでループ処理を書くことは簡単です.もちろん,ループ処理の中でループを書くこともできます.更に,一番内側の処理で別のメソッドを呼出し,呼出したメソッドの中で別のループを実装する.簡略化すると以下の様なコードでした.

※実際のコードはもちろん,もっと処理内容があります.

このsomeMethod()メソッドのコードは四重ループです.二重ループの内側で二重ループを持つメソッドを呼び出しているのです.性能的に危険なループです.経験豊富なプログラムならば臭うことでしょう.

上の簡略ソースの変数outer,innerのいずれも10ならば1ミリ秒以下.あっという間です.

outer,innerいずれも100として,私の作業PC上でsomeMethod()メソッドの応答時間は50ミリ秒程度でした.これも問題ないです.

outer=100,inner=1000ならば,6秒程度.ちょっと遅い.

outer,innerいずれも1000になれば,10分は返ってきません.しかも,その間ハードウェア的に1コアはCPU100%になります.

そもそも変数outerやinnerが10000になる可能性があるならば,設計段階で実現不能なロジックとして除外しなければなりません.ブラウザーで検索ボタンを押してから,10分待っている利用者はいないでしょうから,outer/innerが1000でもWebアプリケーションとしては既に現実的とは云えないでしょう.

少し脱線しますが,forループやwhileループとして見えないループもあります.再帰呼出です.再帰呼出で有名なフィボナッチ数列を例にします.

フィボナッチ数列のJavaプログラムは,以下の様な再帰呼出が典型的な実装コードです.

さて,質問です.Nがいくつぐらいまでが現実的でしょうか?最近の高速なCPUを搭載したマシンでもN=50でfibonacci()関数は現実的な時間で終了しません.高々N=50です.forループは1個しか見えないのに.

話しを戻します.多重ループは指数的に処理時間が延びることを理解しなければなりません.事例では,四重ループの内側の処理効率を見直して改善することで劇的に応答時間が改善しました.

■チューニングの鉄則

プログラムをチューニングする際の鉄則は,チューニング効果の高い箇所から手を入れる,ことです.例えば,全体が10秒のリクエストであれば,その処理時間の内訳が大きい箇所をチューニングするのが効果を得やすい訳です.元々1秒しかかかっていないメソッドを一生懸命チューニングして処理時間を半分にしても,0.5秒しか短縮できませんが,元々8秒かかっている場所を半分にできれば,4秒の短縮なのです.

性能診断分析サービスの性能向上を目的とした現場の場合は,「もっとも少ない工数で,もっとも高い効果」が得られる対策案を提案しなければなりません.そのためには,どうしても本番サービス環境でアプリケーションの挙動を数値で計測する必要があったのです.

 

■もうひとつの課題

「お申込みメニューの20%短縮」の方です.Webサイトの場合,検索して,購入する,又は,申し込みをする,ことが一般的です.利用者に検索してもらうのは,次のアクションとして購入や申し込みをしてもらうためです.一般にWebサイトの最重要機能は「申し込み」と云っても過言ではないでしょう.注文も申し込みの一種です.最近だと「申し込み」の後に「共有」することも大切な機能になってきているようです.つまり,SNSなどに購入した事をツブヤき,お友達と買った事実を共有するという機能です.このサイトは共有はありませんでしたが,「申し込み」機能は重要な機能でした.直接,売上に影響するトランザクションです.この画面遷移を詳細にモニターしました.

申し込みの一連のリクエストの前後で大量のXMLファイルのI/OとXMLパース処理が見つかりました.開発会社様に確認すると,マーケティングデータの収集のための処理でした.それにしても,ファイルから都度読みだしているし,しかも,XMLパースを毎度行っています.その後,更にバックエンドにXML電文を作成し,http通信でそのXMLを数回投げています.応答もXML形式で返ってきて,その返信をパースして解釈後,ログ記録用XMLを作成してログ出力していました.

ディスクからの読みだしはOSキャッシュに載れば性能はある程度確保できますが,ディスクへの出力は極力避けたい訳です.詳しく出力ファイルの場所を確認すると,悪い事に,NFS上への出力でした.高負荷でないWebサイトなら特に問題ではありません.しかし,高負荷サイトの場合は気にしなければなりません.複数台のWEBアプリケーションサーバが水平分散できないからです.また,NFSサーバの障害で,全てのWEBアプリケーションサーバに影響をおよぶことも問題なのです.言い換えれば,ビジネスの停止になってしまうリスクがあるからです.

以下に挙げる2つの主な対策案を提示しました.

1)WEBアプリのファイル出力はローカルファイルへ.

開発会社とインフラ会社が別々だと,インフラ会社さんの運用の手間が楽な方の設定にされてしまうことがあります.設定ファイルの変更で入力パスを変更可能な場合,多くの場合は,一か所の変更で反映できる,という理由からNFS上に置かれる事が多々あります.性能的な観点は全く考慮されません.入力ファイルはNFS上に置き,出力ファイルはローカルディスクに設定変更を提案しました.

2)キャッシュの利用

バックエンドに数回投げているXMLのうち,数回は履歴を紹介する電文でした.これは「履歴」ですから,過去の記録です.後から追加はありますが,変更される内容ではありません.従って,キャッシュが効果的に機能します.memcacheやredisなどのKVSを利用し,オブジェクトをキャッシュする仕組みをご提案しました.キャッシュ機能は機能的には単純です.後から機能を追加することは比較的容易です.効果は非常に高いです.

■目標達成.更にもっと.

ご提案した内容を対策後,後日,本番環境で効果測定を行いました.2つの課題箇所の両方とも目標を達成していました.お客様も喜んでいました.喜んでいるのも束の間,応答時間が速くなることを知ってしまったため欲が出たのでしょう.「更にもっと速くしたいのですが,どうすればよいでしょうか?」と相談を受けました.文章が長くなってしまったので,今回はここまでとします.次回は高負荷,高性能を実現するためのサーバ側の対策案についていくつかご紹介していきたいと思います.

システム性能課題への取り組み

シーマークすずきです.

弊社では,これまでたくさんの性能分析診断サービス案件を行ってきています.ここでは,性能分析診断サービスの紹介をしつつ,これまでの経験から培った様々なシステム性能課題への取り組みや事例から得たTIPSなどをご紹介していきたいと思います.

今回は,初回なので導入編です.

■性能分析診断サービスって何をするのか?

性能分析診断サービスは,2005年頃から正式に開始したサービスです.特にWebアプリケーションの性能課題に対応するケースが多くあります.大規模なコンシューマ向けのサービスや基幹システムのお客様からの依頼がほとんどです.当然,費用をかけてまで性能課題を解決するに値するお客様にとって非常に重要なシステムです.性能分析診断サービスの現場は,時には,本番サービス障害時やリリース直前の緊張感の高い現場が数多くあります.多くのケースは,お客様のシステムで以下のいずれかの状況になっています.

  • 予期せず突然スローダウンが起きる

– 本番サービス中に不定期にサーバー応答が極端に遅くなる

– アプリケーションも一切変更していないし,何が原因かわからない

  • 予定していた性能がでない

– カットオーバー又は納品前の性能試験を実施したら,予定していた処理性能がでない

– 早急に対策して,性能向上しなければならない

  • 新しいバージョンのWEBアプリケーションを配備したら,業務開始後,CPU高騰が発生し,慌てて前バージョンに戻した

– テスト環境では発生しない症状

– 新バージョンを配備したいが,再度同じ症状が発生すると業務にならないため,安心して配備する方策を検討したい.

 

性能分析診断サービスは,簡単に云えば,お客様のアプリケーション(C/C++,Java,PHP,Rubyなどで開発されたアプリケーション)が抱える上記の様な性能に関する問題事象を改めて定義し,その問題事象を観測,分析して,原因を明らかにし,当然,それに対する対策案を提案します.提示した対策案に依っては,直ぐに実施可能であれば,対策効果も計測し提示します.「そんなことできるの?」と聞こえてきそうですが,確かに難しいことです.でも,私たちは取り組んできました.今となっては,実は,このサービスを実践してきた経験そのもの,つまり,切磋琢磨して積み重ねた事例が私たちの”強み”になっていると思います.ある意味,こんなに多くの大規模システムに関する性能問題に直面した経験がある会社はなかなか存在しないのではないでしょうか.これまでのお客様との性能問題への取り組み経験は「豊富な失敗事例の立合い経験」というのもヘンな話しですが,貴重な経験をさせて頂いたという訳です.お客様にとっては,初めて遭遇する問題事象でも,私たちは「似たような症例」を経験している,ということもあります.時には,応急処置を行い,後から,抜本的に対策,治療を施す,と云ったことをする場合もあります.個人的には,このサービスの比喩としては,軍医の様なイメージです.「お客様のビジネスバトルフィールド(戦場)に出向き,お客様の痛みを,除去又は緩和する」という意味です.「より早く,効果的に治療する」という局面がほとんどですから,「救急治療チーム派遣サービス」なのかもしれません.

次回は,実際にどう取り組んでいくのかを載せたいと思います.