Experts.jp日本に、もっとエキスパートを。Network,パフォーマンス,パフォーマンス・バジェット2017年1月18日0click0470こんにちは、編集長の白石です。部長などを歴任されている竹洞陽一郎さん(エキスパートNo.54)にお話を伺ってきました。竹洞さんはWebパフォーマンスについて10年以上従事しており、現在でも年間200サイト以上を計測・分析・評価しているという、その道のエキスパート。テクノロジーの知識はもちろんのこと、アカデミックな話題から業界動向まで幅広く押さえていらっしゃる竹洞さんに、「竹洞さんにしか語れないパフォーマンスの話」を聞いてきました。「ADN」や「パフォーマンス・バジェット」など、Webパフォーマンス業界の最新動向の話も盛りだくさん!めちゃくちゃ面白くて歯ごたえのあるインタビューに仕上がったと思います。根本的な話から言うと、Webサイトがある、ってことは伝えたいメッセージがあるわけですよね。多くのサイトは複数のページにまたがっているわけですが、それは伝えたいメッセージが複数ある、もしくは複数に分けているということ。Webサイトを高速に表示するということは、それらのメッセージを高速に伝えるということにつながるわけです。UX業界で著名なロバート・ヤコブソンによると、1秒以上のインタラプトが入ると人間は思考を中断されてしまうといいます。このインタラプトは、可能な限り避けなくてはなりません。それによって、ユーザーを「フロー状態」に導くことを作り手としては目標にすべきであり、それがパフォーマンスを重視する理由となります。したフロー状態にユーザーを導くことが、営利企業にとってはビジネス上も大きなアドバンテージになるということですね。GoogleやYahoo!が出しているデータはあるのですが、あらゆる業界をおしなべて平均化してしまっているので、正直それほど使えるデータだとは思っていません。業界によって、業務上のKPIって全然違ってきますからね。なると、業界や企業ごとの事例になってくるのですが、そういう点でまとまったデータは今のところ存在しません。モデルもできていない。Amazonだと0.1秒パフォーマンスを改善すると売上が1%上がる、といったデータが示されたこともありますが、これも「Amazonだから(特別なんだろう)」の一言で済まそうと思えば済まされてしまう。私が担当している仕事でなら、具体例はいくらでも挙げられるんですけどね。あるメディアは、表示に6秒かかっていたところを3秒にしたことでPVが倍になったり、売上が3倍になった会社もあります。うーん、エンジニア界隈にはそれなりに浸透しているとは思うのですが、全体でいうと2割くらいの浸透度じゃないですかね...。「浸透していない」というのは、「パフォーマンスの重要性に確信が持てなくて投資に至らない」というレベルではありません。単純に「知らない」ということが多いです。パフォーマンスについて考えたこともない、という。「パフォーマンス大事」という認識を広めたいところではありますね。この記事が多少なりともそのお役に立つといいんですけど。パフォーマンスが大事だという前提に立って、パフォーマンスの問題を解決しようとしたら、まずは原因の調査からですよね。具体的に言えば測定という話になりますが、竹洞さんは統計に関する知識を学ぶべき、と普段からおっしゃってますよね。パフォーマンスの原因を調べるにあたっては、「先入観を持たない」ことが重要なんです。私の経験から言うと、パフォーマンスの問題を抱えたお客様は、まず「データベースが原因だと思う」と必ずおっしゃいます。調べてみると違ってみたりする。統計学を学ぶと、こういう「バイアス」との付き合い方も学びますので、先入観を持って事に当たることが少なくなります。あと、統計を学ばずにデータに当たると、「データに騙されちゃう」ということが往々にしてあるんですね。「データは何も語らない。」という言葉があるんですが、データを解釈して行動に繋げるのは人間なのです。統計について学んでおくと、そこで誤った判断をする可能性を下げることができる。そもそもデータが正しいのか、という問題もある。正しくないデータに基づいても、有意な判断は下せないわけです。ここで一つ重要なのは、「真の値」を知ることなんてそもそもできないわけですよ。いろんなゆらぎもありますから、一意に定まるわけがない。その、神様しか知り得ない「真の値」から、得られたデータがどれだけズレているのかを推測し、それも含めて判断が必要になるわけです。データをただ(グラフなどに)記述して扱うことを「記述統計」と言います。推測統計まで行うことが望ましいってことですね。いえ、まずそもそものデータを信頼度高く取るに越したことはない。そのために、近代統計学の確立者で、実験計画法という手法を編み出したロナルド・フィッシャーは、「3つの原則」を打ち出しています。その原則とは、以下の3つです。反復...長期間に渡り、繰り返し採取する。ランダム...単純無作為抽出を行い、計測を行った値同士が影響を及ぼさないようにする層別...変数を局所化し、影響を見たい変数だけ可変にするこういう知識があるのとないのとでは、データやグラフに対するスタンスが全然違ってきます。「バイアスを排除して、先入観を持たない」「正確性の高いデータに基づき、精度の高い判断を行う」といったスタンスを身につけるためにも、統計をきちんと学ぶことはお勧めしています。Analyticsとかでは、パフォーマンスを正確に計測できない、と以前からおっしゃっていますね。GAで「遅い」という問題に気付けたとしても、原因追求ができないんです。原因となりうる要因が多すぎるし、絞り込むこともできない。一つは、欠損値が多いことです。遅いということはそもそもGAのスクリプトが読み込まれていないことも多い。いうのが全てデータから抜けてしまうんですね。遅いなーと思ってリロードしたり、途中で離脱したりしちゃうと、そもそもそれがデータから漏れてしまうんだ。その影響は実は大きくて、データにバイアスがかかってしまうんですよ。本来注目すべき「遅い」データが見えなくなってしまう。その状態でデータを眺めると、問題が隠蔽されてしまう。なると、アメリカの鉄道と同じです。アメリカの鉄道が廃れた理由って、遅延やサービスの低品質に利用客も慣れてしまい、不満が上がってこなかったことにあると言われているんです。不満が上がってこないから、企業は「顧客は満足している」と判断し、更にコストカットなどを進めてしまう。その結果、鉄道が衰退してしまった。GAで欠損値が出るだろう、というのは想像できていたことではありますが、それが経営判断を誤る一因にまでなりうるということですね。catchpointやdynatraceとか。いったサービスは、実際のユーザー群に近い環境を国ごとに構築していて、継続的にデータを収集してくれます。したサービスで得たデータと、GAで得られるパフォーマンスデータって実際にかなり開きが出てくるので、面白いですよ。具体的に、パフォーマンスボトルネックの原因や改善方法についてお話を伺っていきたいと思います。Webサービスのネットワーク遅延の原因は、フロントエンド、ネットワーク、バックエンドに分かれると思いますが、バックエンドの話は原因も多岐に渡りそうですし、時間もないので、今回はフロントエンドとネットワークに絞ってお話を聞かせてください。フロントエンドからいきましょうか。はい、ではまずは前回の座談会でもお話したとおり、Webページの遅延原因の80%はサードパーティから読み込むリソースにあります。jQueryのJavaScriptファイルを読み込むとか、ソーシャルボタンとか、広告とかいろいろありますよね。言うならやはり広告とかですかね。広告のパフォーマンスを見てみると、サーバーのDBがボトルネックになってるんだろうなあ...とは推測しています。なると、こちらでは手が出しようがないんですよね。広告を配信している企業に直接改善を要求するしかない。パフォーマンスの観点から言うと、やはり広告はボトルネックになりやすいと。ソーシャルボタンも遅いですよ。ソーシャルボタンのスクリプトって、キャッシュの時間も15分くらいと短いものが多いので、ネットワークアクセスが増加する一因にもなりますしね。CDNについては...いろいろあるので、あとでじっくり語らせてください(笑)。ちなみに、アメリカだとサードパーティのスクリプトと言えども、速いんですよ。遅いと(ユーザー企業に)呼び出されるから(笑)。!アメリカだとユーザー企業の意識も高いんですかねえ。逆に言うと、日本の企業はそこまでパフォーマンスに対する意識が高まってなくて、結局遅いサイトが多数を占めるようになってしまってる、ってことなんでしょうか。あとはフロントエンドで言うと、画像じゃなくてもいいものを画像にしてる、ってのがすごく多いです。秘密の資料お見せしますけど、ほら。誰でも知ってるような企業のサイトなんですが...。HTML5やCSS3のおかげで、Webのポテンシャルってすごく広がりましたけど、そもそもそのポテンシャルが全然理解されてないんです。次は、ネットワークのパフォーマンスについてのお話を聞かせていただければと思います。話に分けられると思います。転送量の話からいきましょうか。あ、一つだけいいですか?実際のところ、実はスクリプトのミニファイとかって、あんまり必要ないんです。ええっ!そうなんですか?そこを頑張ってるエンジニアたち、ぼくも含めていっぱいいると思うんですけど。やらないよりはやったほうがいいですけど、パフォーマンス全体から言うと、あまり効果のある施策ではありません。そこに開発コストを投じるべきかどうかは疑問ですね。それよりもやはりネットワークアクセスの回数、もっと厳密に言えばTCPの3ウェイハンドシェイクの回数の方が重要。HTTP/2は、1本のTCP接続内で複数のHTTPメッセージのやり取りを可能にする)。ちなみに私としては、HTTP/1.1とHTTP/2は、Webサーバのリソース特性や配信対象地域などを分析した上で、適切に使い分けてほしいですね。え、そうなんですか?全部HTTP/2にすればいいのかと思ってました。近所のスーパーに車で行くか、自転車で行くかってなると、自転車のほうが速い場合も多いわけじゃないですか。それと同じで、条件によっては、実はHTTP/1.1の方が速い場合も存在します。ネットワーク距離、リソース配信サーバ数、オブジェクト数、転送容量などですね。ネットワーク距離の観点では、HTTP/1.1は近いほど、HTTP/2は遠いほど有利です。リソース配信サーバ数の観点では、HTTP/1.1は多いほど、HTTP/2は少ないほど有利です。単純にオブジェクト数だけを考えると、HTTP1.1は少ないほど、HTTP/2は多いほど有利です。先ほどから話に上がってるサードパーティのスクリプトなんかは、ドメインもバラバラだし、アクセスはほとんど1回こっきりだし、HTTP/1.1が活きてくる分野かもしれませんね。Network)についてもお話いただきましょうか。CDNについては、実際のところを知ると、皆さん驚かれると思いますよ。実は、CDNはもう速くないんです。えっ...!そうなんですか?ちょっと意味がよくわからない。ネットワークに対する投資額の規模を表した図としては、こういうものがよく使われます。上がファーストマイル、事業者に最も近い部分で、サーバーやクラウドに代表されるレイヤーです。ユーザーに最も近い部分ですね。この図を見てわかる通り、ラストマイルとファーストマイルには多くの投資が行われてきました。エンドユーザーに近い部分のネットワークは、相当高速化されてきている。以前はCDNは、ラストマイルを高速化するためのサービスとして有力でした。業界全体でラストマイルに多くの投資が行われた結果、CDNの有用性そのものが薄れてしまいました。CDNに置くよりも自前で配信したほうが速いという状態が一般的になっているのです。CDNが速くないなんて...。CDNのベンダーは速度じゃなくてロバストネス、堅牢性をウリ文句に変えるところも出てきています。それは、第一世代のCDNと言われていたサービスの話です。Presense:CDNのサーバーを物理的に配置する位置)を最適化するというアプローチで、大きくこの分野を前進させました。今、この分野は第三世代に入ろうとしています。Network」と呼んでいますね。ひとことで言うと、非常にインテリジェントなのです。サーバー側では、機械学習を用いて基地局ごとに最適な経路を割り出すので、非常に動的な最適化が行える。クライアントとサーバーがコミュニケーションしながら、リソース取得の最適化を図ります。具体的には、クライアント側に「ナノバイザー」と呼ばれるJavaScriptのエージェントを走らせます。ブラウザ側の仮想マシンと言ってもいい。そのナノバイザーが、サーバーと様々な情報を常にやり取りしながら、リソースの最適な取得方法を探るわけです。